Luận Văn Quản Lý Dự Án CNTT

GIỚI THIỆU Mục tiêu của giáo trình là trang bị cho sinh viên những kiến thức và kỹ năng quản lý dự án công nghệ thông tin một cách hệ thống, từ giai đoạn lập dự án đến kết thúc, đáp ứng chuẩn đầu ra của chương trình đào tạo đại học. Nội dung giáo trình được trình bày trong 6 chương, cụ thể như sau: Chương 1. Giới thiệu về quản lý dự án: Chương này cung cấp các khái niệm cơ bản về dự án và quản lý dự án CNTT, các thuộc tính của dự án, biểu đồ phân vai, thành phần tổ chức dự án, tiêu chí lựa chọn nhân sự và mẫu tổ chức dự án phù hợp. Đây là nền tảng lý thuyết giúp người học hình dung toàn cảnh về quản lý dự án CNTT. Chương 2. Xác định dự án: Hướng dẫn cách xác định mục đích và mục tiêu dự án, xây dựng bản tuyên bố công việc (Project Charter) và tổ chức dự án. Người học sẽ nắm vững các bước đầu tiên trong việc triển khai một dự án CNTT hiệu quả. Chương 3. Lập kế hoạch dự án: Chương này tập trung vào lập kế hoạch chi tiết, bao gồm: Lập kế hoạch phạm vi dự án và cấu trúc phân chia công việc (WBS); Ước lượng thời gian, phân bố lực lượng và chi phí; Lập tiến độ thực hiện; Lập kế hoạch phòng ngừa và hạn chế rủi ro giúp sinh viên có khả năng dự báo và chuẩn bị toàn diện cho việc triển khai dự án. Chương 4: Thực hiện dự án: Chương này hướng dẫn các phương pháp giám sát, kiểm soát và đánh giá tiến độ công việc, tổ chức họp, kiểm soát thay đổi tích hợp, kiểm soát chất lượng và quản lý rủi ro. Đây là phần thực hành quan trọng, giúp sinh viên hiểu cách biến kế hoạch thành hành động thực tế. Chương 5: Các công cụ quản lý dự án: giới thiệu các công cụ hỗ trợ quản lý dự án CNTT, bao gồm: thủ tục dự án, hồ sơ quản lý, biểu mẫu, báo cáo, thư viện dự án, văn phòng dự án, cũng như phần mềm quản lý dự án. Phần này giúp người học nắm vững các công cụ cần thiết để quản lý dự án hiệu quả. Chương 6: Kết thúc dự án: Chương cuối cùng trình bày quy trình kết thúc dự án, gồm: chuẩn bị kết thúc, xác định lại phạm vi dự án, bàn giao kết quả và tổng kết rút kinh nghiệm. Đây là bước quan trọng để đảm bảo bài học kinh nghiệm được ghi nhận và áp dụng cho các dự án tiếp theo.

Luận Văn Quản lý dự án CNTT

Luận Văn Quản lý dự án CNTT

CHƯƠNG 1 – GIỚI THIỆU VỀ QUẢN LÝ DỰ ÁN CNTT

1 Khái niệm cơ bản

1.1 Dự án là gì?

 Là một nỗ lực tạm thời, có mục tiêu cụ thể, thời gian bắt đầu – kết thúc xác định.

 Tạo ra một sản phẩm, dịch vụ hoặc kết quả duy nhất.

 Trong lĩnh vực CNTT, dự án có thể là: xây dựng phần mềm, triển khai hệ thống ERP, phát triển ứng dụng di động, nâng cấp hạ tầng mạng,…

Ví dụ:mô hình tổng quan: Input → Process → Output cho một dự án CNTT xây dựng

phần mềm.

1.2 Quản lý dự án là gì?

 Là quá trình lập kế hoạch, tổ chức, điều phối và kiểm soát các nguồn lực để đạt mục

tiêu dự án

 Bao gồm quản lý phạm vi, thời gian, chi phí, chất lượng, nhân sự, rủi ro, truyền thông,…

Ví dụ : Xây dựng website thương mại điện tử

Mục tiêu: tạo trang web bán hàng online Đầu ra: website có giỏ hàng, thanh toán, quản lý sản phẩm

2 Thuộc tính của dự án CNTT

Dự án CNTT thường có các đặc trưng:

 Tính độc đáo của sản phẩm: mỗi yêu cầu, mỗi hệ thống có tính đặc thù.

 Nhiều thay đổi: yêu cầu khách hàng có thể thay đổi liên tục.

 Phụ thuộc công nghệ: công nghệ thay đổi nhanh, đòi hỏi cập nhật liên tục.

 Độ phức tạp cao: nhiều module, nhiều bên liên quan.

 Rủi ro lớn: đặc biệt về tiến độ và yêu cầu.

3 Biểu đồ phân vai trong dự án

Biểu đồ phân vai giúp:

 Xác định ai làm gì.

 Tránh chồng chéo trách nhiệm

 Thông thường dùng ma trận RACI:

o R – Responsible: Người thực hiện.

o A – Accountable: Người chịu trách nhiệm cuối cùng.

o C – Consulted: Người tư vấn.

o I – Informed: Người cần được thông báo.

 Nhóm triển khai – vận hành (Deployment/DevOps).

 Các bên liên quan khác: nhà cung cấp, chuyên gia tư vấn,…

Tùy quy mô dự án, số lượng thành viên có thể tăng/giảm

5 Tiêu chí lựa chọn nhân sự cho dự án

Khi chọn người tham gia dự án, cần xét:

 Năng lực chuyên môn (kỹ năng lập trình, phân tích, kiểm thử…).

 Kinh nghiệm thực tế với công nghệ liên quan.

 Kỹ năng mềm: giao tiếp, làm việc nhóm, quản lý thời gian.

 Khả năng chịu áp lực và thích nghi.

 Tinh thần trách nhiệm và thái độ làm việc.

6 Mẫu tổ chức dự án phù hợp

Tùy tính chất dự án, có thể chọn mô hình:

 Tổ chức chức năng: nhân sự nằm trong phòng ban chuyên môn → phù hợp dự án nhỏ.

 Tổ chức dự án thuần túy: tập trung 100% vào dự án → phù hợp dự án lớn, độc lập.

 Tổ chức ma trận (yếu – cân bằng – mạnh): kết hợp linh hoạt nhân sự giữa dự án và

phòng ban → phổ biến trong doanh nghiệp CNTT

Kết luận

Chương 1 cung cấp nền tảng lý thuyết giúp người học:

 Hiểu bản chất của dự án & quản lý dự án CNTT

 Nắm được vai trò, cấu trúc tổ chức, và cách bố trí nhân sự

 Là cơ sở để tiếp tục các chương chuyên sâu hơn như lập kế hoạch, quản lý rủi ro, quản lý tiến độ, chi phí,…

CHƯƠNG 2 : XÁC ĐỊNH DỰ ÁN

2.1 Xác định mục đích và mục tiêu của dự án

🔶 a Mục đích dự án (Project Purpose)

Mục đích trả lời câu hỏi “Tại sao phải thực hiện dự án?”

Đây là lý do cốt lõi khiến dự án tồn tại

✔ Cách xác định:

 Phỏng vấn khách hàng / ban lãnh đạo

 Đánh giá vấn đề hiện tại của doanh nghiệp

 Xác định mong muốn cải thiện (năng suất, doanh thu, hiệu quả…)

 Ghi rõ lợi ích tổng quát (tăng hiệu quả, cải thiện trải nghiệm người dùng…)

🔶 Ví dụ (CNTT – xây dựng website bán hàng):

“Mục đích của dự án là tạo ra kênh bán hàng trực tuyến nhằm tăng doanh thu, mở rộng phạm vi tiếp cận khách hàng và tối ưu hóa hoạt động bán hàng của doanh nghiệp.”

🔶 b Mục tiêu dự án (Project Objectives)

Mục tiêu trả lời câu hỏi “Dự án sẽ đạt được điều gì?”

✔ Cách viết mục tiêu theo SMART:

 “Xây dựng website bán hàng có ít nhất 50 sản phẩm trong vòng 3 tháng.”

 “Tích hợp thanh toán trực tuyến (MoMo, ATM, Visa) trước ngày 30/11.”

 “Đạt 95% mức độ hài lòng khách hàng qua giai đoạn UAT.”

🔶 c Công cụ hỗ trợ xác định mục tiêu

 Use Case sơ bộ (các chức năng chính)

 User Stories (dạng: “Là một … tôi muốn … để …”)

⚠ Đây là tài liệu quan trọng nhất trong giai đoạn khởi tạo dự án.

🔶 B Nội dung Project Charter (chuẩn PMBOK mở rộng)

b 7 Thời gian dự kiến & mốc chính (Milestones)

Mốc Ngày dự kiến Nội dung

M1 10/01 Hoàn thành phân tích yêu cầu

M2 25/02 Hoàn tất phát triển phiên bản Beta

M3 15/03 Kiểm thử hoàn chỉnh

M4 01/04 Bàn giao sản phẩm

b 8 Các bên liên quan (Stakeholders)

Gồm khách hàng, PM, BA, Dev, QA,…

b 9 Giả định & ràng buộc

 Giả định: Khách hàng cung cấp dữ liệu đầy đủ

 Ràng buộc: Ngân sách không vượt quá 300 triệu

b 10 Rủi ro ban đầu

 Khách hàng thay đổi yêu cầu liên tục

 Thiếu nhân lực kỹ thuật

b.11 Phê duyệt

Chữ ký Ban lãnh đạo & PM

Mẫu Project Charter ngắn gọn (có thể dùng ngay)

PROJECT CHARTER

1 Tên dự án: Hệ thống Quản lý Kho phiên bản 2.0

2 Mục đích: Tự động hóa quy trình quản lý kho và giảm lỗi tồn kho.

8 Stakeholders: PM, Dev team, QA team, khách hàng

9 Rủi ro: Thay đổi yêu cầu; thiếu thiết bị test.

* Mô hình chức năng (Functional Organization)

 Dựa trên cơ cấu phòng ban

 PM (Project Manager) có quyền hạn thấp

 Nhân sự dự án thuộc quyền quản lý của trưởng bộ phận

 Phù hợp với: dự án nhỏ, mang tính chuyên môn cao

*Mô hình dự án thuần túy (Projectized Organization)

 Tất cả nhân sự tập trung toàn thời gian cho dự án

 PM có quyền lực cao, ra quyết định nhanh

 Phù hợp với: dự án lớn, yêu cầu tiến độ nhanh

*Mô hình ma trận (Matrix Organization)

Gồm 3 loại:

 Ma trận yếu: gần giống chức năng, PM quyền thấp.

 Ma trận cân bằng: PM và trưởng bộ phận chia sẻ quyền lực.

 Ma trận mạnh: PM quyền cao hơn, giống mô hình dự án.

→ CNTT thường dùng mô hình ma trận.

Ví dụ : Một công ty công nghệ đang phát triển hệ thống đặt vé online cho một hãng hàng không Công

việc gồm backend, frontend, UI/UX, kiểm thử…

Trong mô hình ma trận mạnh:

 PM quyết định phân công công việc hằng ngày

 Thành viên từ các phòng ban (Dev, QA, UX) báo cáo trực tiếp cho PM trong thời gian dự án

 Ưu tiên dự án > ưu tiên công việc của phòng ban

Trong ma trận mạnh, PM có quyền quyết định những việc như:

 Chọn ai từ phòng Dev tham gia dự án

 Quyết định người nào làm task quan trọng nhất

 Điều chuyển nhân sự từ nhóm này sang nhóm khác khi tiến độ thay đổi

✔ Ví dụ về mô hình ma trận mạnh trong dự án CNTT

Trong dự án xây dựng hệ thống đặt vé online cho hãng hàng không, PM có quyền phân bổ nhân sự trực

tiếp.

PM quyết định chọn một security engineer tham gia dự án và giao họ phụ trách bảo mật giao dịch.

Trong quá trình triển khai, security engineer báo cáo trực tiếp cho PM thay vì trưởng bộ phận bảo mật,

thể hiện rõ rằng PM có quyền cao và ưu tiên dự án là số 1 — đúng đặc điểm của mô hình ma trận

mạnh.

Bước 2 – Xác định nhân sự cho các vai trò chính

 PM – Điều phối toàn dự án

 BA – Phân tích & làm việc với khách hàng

 Dev Lead – Lập trình, code review

 Tester/QA – Đảm bảo chất lượng

 UI/UX Designer – Thiết kế sản phẩm

 DevOps – Triển khai và vận hành

Bước 3 – Xây dựng sơ đồ tổ chức (Organization Chart)

|

QA Team

Bước 4 – Xác định trách nhiệm (RACI Matrix)

Dùng bảng RACI để đảm bảo không chồng chéo vai trò.

Bước 5 – Họp Kick-off để thống nhất cơ cấu

 Trình bày mục tiêu

 Giới thiệu nhân sự

 Công bố Project Charter

 Xác nhận phạm vi và cách làm việc

Tóm tắt quy trình khởi đầu dự án CNTT

1 Thu thập thông tin → 2 Xác định mục đích

3 Viết mục tiêu SMART → 4 Xây dựng Project Charter

5 Lập sơ đồ tổ chức dự án → 6 Xây dựng RACI

7 Họp Kick-off → 8 Chính thức bắt đầu dự án

CHƯƠNG 3:LẬP KẾ HOẠCH DỰ ÁN

A Lập kế hoạch phạm vi dự án (Project Scope Planning)

A.1 Xác định phạm vi dự án (Project Scope Statement)

Nội dung chính bao gồm:

a.Mục tiêu của dự án : Xác định dự án cần đạt được điều gì, thể hiện rõ kết quả mong

đợi sau khi dự án hoàn thành

 Tài liệu hướng dẫn sử dụng

 Môi trường triển khai

 Báo cáo, dữ liệu chuyển đổi

 Tài liệu thiết kế, test case,…

📌 Ví dụ

 Ứng dụng web quản lý kho

 API tích hợp hệ thống ERP

 Bộ tài liệu: SRS, thiết kế, test report

 Hệ thống được cài đặt trên server thật

Đây là căn cứ để nghiệm thu dự án

c Các yêu cầu chức năng và phi chức năng

c.1 Yêu cầu chức năng (Functional Requirements)

Mô tả hệ thống cần làm gì.

📌 Ví dụ:

 Người dùng đăng nhập bằng tài khoản cá nhân

 Hệ thống quản lý nhập – xuất – tồn kho

 Tạo báo cáo tự động theo ngày/tháng/năm

c.2 Yêu cầu phi chức năng (Non-functional Requirements)

Mô tả hệ thống phải vận hành như thế nào.

📌 Ví dụ: Gồm:

 Hiệu năng: 2 giây/phản hồi

 Bảo mật: Mã hóa dữ liệu, xác thực 2 lớp

 Ngân sách không vượt quá 300 triệu

 Giao diện phải dựa trên template đã có

 Dự án phải hoàn thành trước ngày 31/12

 Công nghệ bắt buộc: Java Spring + React

Constraints giúp PM lập kế hoạch thực tế và tránh vượt phạm vi

 Khách hàng cung cấp dữ liệu đầy đủ đúng thời hạn

 Môi trường server phát triển sẽ sẵn sàng sau 2 tuần

 Đội ngũ Dev đủ 4 người trong suốt dự án

Nếu giả định sai → phải cập nhật kế hoạch và phạm vi

Bản mô tả phạm vi là nền tảng để xây dựng kế hoạch và kiểm soát dự án

A.2 Xác định các hạng mục công việc (mở rộng cho tài liệu dự án)

Dựa trên phạm vi dự án đã phê duyệt, nhóm dự án tiến hành phân rã công việc nhằm xác định đầy đủ các gói sản phẩm, yêu cầu kỹ thuật và tiêu chí nghiệm thu Việc xác định này nhằm đảm bảo phạm vi được kiểm soát chặt chẽ, các đầu ra được định nghĩa rõ ràng và việc nghiệm thu được thực hiện nhất quán theo chuẩn của dự án

a Danh sách các gói sản phẩm (Deliverables)

Ví dụ áp dụng cho dự án phát triển hệ thống phần mềm:

1 Tài liệu phân tích yêu cầu

2 Thiết kế kiến trúc hệ thống

3 Thiết kế giao diện (UI/UX)

4 Phát triển chức năng lõi

5 Tích hợp hệ thống

6 Kiểm thử phần mềm

7 Hệ thống triển khai bản Production

8 Tài liệu hướng dẫn sử dụng

9 Tài liệu vận hành & bảo trì

b Các yêu cầu kỹ thuật

Ví dụ:

 Hệ thống phải hỗ trợ tối thiểu 500 người dùng đồng thời.

 Thời gian phản hồi < 2 giây cho 95% giao dịch.

 Giao diện tuân thủ chuẩn Material Design.

 API giao tiếp qua RESTful, sử dụng JSON, có cơ chế xác thực OAuth 2.0.

 Cơ sở dữ liệu phải sao lưu tự động mỗi 12 giờ.

 Ứng dụng chạy được trên trình duyệt Chrome, Firefox, Edge.

c Tiêu chí nghiệm thu

Ví dụ:

 Tất cả tính năng đạt tỷ lệ kiểm thử passed ≥ 98%.

 Không còn lỗi nghiêm trọng (Severity 1) hoặc quan trọng (Severity 2).

 Giao diện thực hiện đúng theo bản thiết kế UI/UX đã duyệt.

 Hiệu năng đạt yêu cầu theo SLA.

 Tài liệu đầy đủ: hướng dẫn sử dụng, hướng dẫn cài đặt, hướng dẫn vận hành.

 Demo nghiệm thu đạt yêu cầu và được khách hàng ký biên bản nghiệm thu.

d.Bảng WBS mẫu (lever1-3)

(Ví dụ cho dự án phát triển hệ thống phần mềm)



1 Khởi động dự án Thành lập nhóm, xác định phạm vi Quyết định khởi động 1.1 Xác định phạm vi Thu thập thông tin, làm rõ mục tiêu Tài liệu Scope

1.2 Kế hoạch dự án Xây dựng timeline, ngân sách Project Plan

Mã WBS Hạng mục / Công việc Mô tả Deliverables

2 Phân tích yêu cầu Thu thập & mô hình hóa yêu cầu SRS

2.1 Thu thập yêu cầu Workshop, phỏng vấn stakeholder Biên bản yêu cầu 2.2 Đặc tả yêu cầu Chuyển yêu cầu thành tài liệu kỹ thuật SRS

3 Thiết kế hệ thống Kiến trúc + giao diện Architecture, UI Design 3.1 Thiết kế kiến trúc Phân lớp, CSDL, API Architecture Doc 3.2 Thiết kế UI/UX Prototype, mockup UI Kit

4.1 Module người dùng CRUD, đăng nhập Code + testcases 4.2 Module quản trị Dashboard, quản lý dữ liệu Code + testcases

5.1 Kiểm thử chức năng Unit, Integration test Test Result

5.2 Kiểm thử hiệu năng Tải, áp lực Performance Report

6 Triển khai Release bản production Release package

6.1 Cài đặt hệ thống Server, CSDL Deployment Guide 6.2 Chuyển giao & đào tạo Đào tạo người dùng Training Doc

7 Nghiệm thu Review với khách hàng Acceptance Report

WBS giúp:

 Chia nhỏ dự án thành các gói công việc (work packages) dễ quản lý, dễ kiểm soát.

 Xác định rõ phạm vi và trách nhiệm, tránh trùng lặp hoặc bỏ sót công việc.

 Hỗ trợ ước lượng thời gian, chi phí và nguồn lực một cách chính xác hơn.

 Làm cơ sở cho lập lịch, phân bổ nguồn lực, quản lý rủi ro và kiểm soát tiến độ.

 Tăng tính minh bạch giữa các bên liên quan nhờ phân rã công việc rõ ràng.

b.1 Nguyên tắc xây dựng WBS

.Tuân thủ phương pháp top-down (từ tổng thể xuống chi tiết).

.Phân rã công việc đến mức có thể ước lượng – phân công – theo dõi.

.Tập trung biểu diễn deliverables (đầu ra), không chỉ là danh sách các hoạt động.

.Các gói công việc cùng cấp phải không trùng lặp phạm vi (mutually exclusive).

.Bảo đảm toàn bộ WBS bao phủ đầy đủ phạm vi dự án (collectively exhaustive).

b.2 Ví dụ WBS tham khảo (Dự án phát triển hệ thống phần mềm)

Mã WBS Cấp độ Hạng mục / Gói công việc Mô tả

1 Level 1 Dự án phát triển hệ thống Phạm vi toàn dự án

1.1 Level 2 Khởi động dự án Scope, kế hoạch, nhóm dự án

1.1.1 Level 3 Xác định phạm vi Biên soạn tài liệu phạm vi

1.1.2 Level 3 Kế hoạch dự án Lập tiến độ, chi phí, rủi ro

1.2 Level 2 Phân tích yêu cầu Thu thập và đặc tả yêu cầu

1.2.1 Level 3 Thu thập yêu cầu Workshop, phỏng vấn

1.2.2 Level 3 Đặc tả yêu cầu Viết SRS

1.3 Level 2 Thiết kế hệ thống Kiến trúc và giao diện

1.3.1 Level 3 Thiết kế kiến trúc Modules, CSDL, API

1.3.2 Level 3 Thiết kế UI/UX Prototype, mockup

1.4 Level 2 Phát triển phần mềm Coding theo từng module

1.5 Level 2 Kiểm thử Unit test, system test

1.6 Level 2 Triển khai Install, migration

1.7 Level 2 Nghiệm thu & bàn giao Acceptance test, chuyển giao tài liệu

b.3 Lợi ích của WBS đối với quản lý dự án

 Quản lý tiến độ hiệu quả: Lập lịch (Gantt chart) dựa trên các work packages.

 Kiểm soát chi phí: Mỗi gói công việc có thể được dự toán độc lập.

 Giảm rủi ro: Dễ phát hiện công việc thiếu hoặc trùng lặp.

 Quản lý chất lượng: Mỗi gói công việc có tiêu chí nghiệm thu rõ ràng.

 Tăng khả năng giao tiếp: Các bên liên quan hiểu rõ cấu trúc công việc.

c Các bước xây dựng WBS

Quá trình xây dựng WBS (Work Breakdown Structure) thường được thực hiện theo phương pháp từ trên xuống (top–down), đảm bảo phân rã dự án thành các phần nhỏ dễ quản lý Các bướcthực hiện như sau:

c.1.Xác định các đầu ra chính của dự án (Project Deliverables)

 Xác định các sản phẩm, kết quả hoặc dịch vụ mà dự án cần cung cấp.

 Đây là cơ sở để phân rã công việc theo hướng “định hướng sản phẩm” oriented)

(deliverable- Ví dụ: Tài liệu yêu cầu, phần mềm, hệ thống triển khai, báo cáo nghiệm thu.

c.2 Phân rã từng đầu ra thành các nhóm công việc chính (Major Work Groups)

 Đối với mỗi đầu ra, xác định những nhóm nhiệm vụ cần thiết để tạo ra đầu ra đó

 Đây thường là cấp độ 2 của WBS

 Ví dụ: Phân tích – thiết kế – phát triển – kiểm thử – triển khai.

Đầu ra chính Nhóm công việc cấp 2

SRS Thu thập yêu cầu, phân tích nghiệp vụ, viết SRS

Thiết kế Thiết kế UI/UX, thiết kế kiến trúc

Phát triển website Phát triển frontend, backend, tích hợp API

Kiểm thử Kiểm thử chức năng, kiểm thử hiệu năng

Triển khai & bàn giao Cài đặt hệ thống, chuyển giao đào tạo

c.3 Tiếp tục phân rã đến mức có thể quản lý được (Work Package Level)

 Phân rã đến mức công việc đủ nhỏ để

o dễ ước lượng thời gian

o dễ ước lượng chi phí

o có thể giao cho một người hoặc một nhóm chịu trách nhiệm

o có thể theo dõi tiến độ và kiểm soát chất lượng

 Không phân rã quá sâu để tránh làm WBS phức tạp

c.4 Gán mã WBS và mô tả các gói công việc (WBS Coding & Dictionary)

 Mã WBS cho phép định danh từng gói công việc (ví dụ: 1.3.2)

 Đối với mỗi work package, cần mô tả rõ:

 Đây là nội dung của WBS Dictionary.

Mã WBS Gói công việc Deliverable Tiêu chí nghiệm thu

1.1.1 Phỏng vấn khách

hàng Biên bản phỏng vấn Được khách hàng xác nhận

2.1.1 Mockup trang chủ File mockup Khách hàng phê duyệt

3.2.2 Xử lý đơn hàng Module backend Xử lý đúng quy trình nghiệp vụ5.1.2 Triển khai Production Website chạy thực tế Hoạt động ổn định, không lỗi nghiêm

Mã WBS Gói công việc Deliverable Tiêu chí nghiệm thu

trọng



c.5 Kiểm tra tính đầy đủ và không trùng lặp (MECE Check)

 Đảm bảo tất cả deliverables đều đã có work package tương ứng

 Không trùng lặp công việc giữa frontend và backend

 Đảm bảo không bỏ sót hoạt động như kiểm thử tích hợp, backup dữ liệu

 Nhờ các bên liên quan (khách hàng + đội phát triển) rà soát

C Ước lượng thời gian, nguồn lực và chi phí

C.1 Ước lượng thời gian (Time Estimation)

Các kỹ thuật phổ biến:

 Ước lượng theo chuyên gia (Expert Judgement)

Dựa vào kiến thức, kinh nghiệm và đánh giá của các chuyên gia trong lĩnh vực, trưởng nhóm kỹ thuật hoặc người đã từng thực hiện các dự án tương tự

Ưu điểm: Nhanh chóng, đơn giản Hiệu quả khi có chuyên gia giàu kinh nghiệm

Nhược điểm: Phụ thuộc nhiều vào kinh nghiệm chủ quan Có thể không chính xác nếu dự án quá mới

Khi sử dụng: Dự án tương tự đã từng làm Công việc rõ ràng và quen thuộc.

 Phương pháp tương tự (Analogous Estimating)

Ước lượng thời gian dựa trên dữ liệu của các dự án trước đó có tính chất tương tự

Ưu điểm: Nhanh và ít tốn công sức.Tốt cho ước lượng cấp cao (Initial estimate)

Nhược điểm: Độ chính xác không cao nếu dự án hiện tại khác biệt đáng kể Dựa trên dữ

liệu lịch sử – nếu lịch sử không tốt ⇒ kết quả sai

Khi sử dụng: Giai đoạn đầu, khi chưa có nhiều thông tin chi tiết Các dự án mang tính lặp lại

(website, báo cáo, module tương tự)

 Ước lượng từ dưới lên (Bottom-Up Estimating).

Ước lượng chi tiết cho từng gói công việc ở cấp độ thấp (Work Package), sau đó tổng hợp lên thành tổng thời gian dự án

Ưu điểm: độ chính xác cao nhất =>dùng tốt khi WBS đã hoàn chỉnh

Nhược điểm: tốn nhiều thời gian và công sức ⇒ cần nhiều dữ liệu chi tiết

Khi sử dụng: Khi đã hoàn tất WBS =>trong giai đoạn lập kế hoạch chi tiết (Planning

Phase)

Ví dụ:

Nếu WP 3.1.1 “Trang sản phẩm” cần 4 ngày → tổng thời gian frontend = tổng WP của

frontend.

 Phương pháp PERT ( Program Evaluation Review Technique).

Ước lượng dựa trên 3 giá trị:

O = Optimistic (Ước lượng tốt nhất)

M = Most Likely (Ước lượng khả dĩ nhất)

P = Pessimistic (Ước lượng tệ nhất)

Công thức PERT: TE = (O+4M+P)/6

Ưu điểm : Bao gồm cả yếu tố rủi ro => Phù hợp với công việc chưa rõ ràng hoặc độ biến thiên lớn

Nhược điểm : Cần nhập đủ 3 giá trị O–M–P.Cần sự tham gia của chuyên gia

Khi sử dụng: Giai đoạn đầu dự án:(Expert Judgement + Analogous) =>Giai đoạn lập

kế hoạch chi tiết(Bottom-Up) => Công việc có độ bất định cao(PERT) =>Nên kết hợp nhiều kỹ

thuật để tăng tính chính xác

C.2 Ước lượng nguồn lực

Ước lượng nguồn lực là quá trình xác định loại và số lượng nguồn lực cần thiết để thực hiện các công việc trong dự án Đây là bước quan trọng nhằm đảm bảo dự án có đầy đủ nhân lực, thiết bị

và điều kiện cần thiết để đáp ứng tiến độ và chất lượng đã đặt ra

Nguồn lực của dự án thường bao gồm:

Nhân lực : Xác định đội ngũ tham gia dự án và năng lực chuyên môn cần thiết cho từng gói côngviệc

Ví dụ:

 Quản lý dự án (PM)

 Business Analyst (BA)

 Developer (Frontend / Backend / Mobile)

 UI/UX Designer

 Tester / QA

 DevOps / IT Support

 Chuyên gia giải pháp (Solution Architect)

Yêu cầu ước lượng:

 Số lượng người cần thiết

 Số ngày công/giờ công

 Kỹ năng và năng lực (skillset)

 Thời điểm cần huy động

Thiết bị, vật tư (Equipment & Materials) :

Tùy theo loại dự án, cần xác định rõ các thiết bị hỗ trợ hoặc vật tư phục vụ thi công

Ví dụ:

 Máy tính, laptop cấu hình chuyên dụng

 Máy chủ vật lý hoặc ảo hóa

 Thiết bị kiểm thử (mobile device, tablet…)

 Vật tư tiêu hao (mạng, điện, văn phòng phẩm đối với dự án triển khai)

Yêu cầu ước lượng:

 Số lượng thiết bị

 Thời gian sử dụng

 Chi phí thuê/mua

 Kế hoạch bảo trì hoặc thay thế

Công nghệ và hạ tầng (Technology & Infrastructure)

Bao gồm các nền tảng, công cụ và môi trường cần thiết để triển khai và vận hành dự án

Ví dụ:

 Môi trường phát triển (Dev), kiểm thử (Test/UAT), sản xuất (Production)

 Các nền tảng cloud: AWS, Azure, GCP

 Hạ tầng mạng, lưu trữ, bảo mật

 Phần mềm bản quyền (IDE, tool CI/CD, server OS…)

Yêu cầu ước lượng:

 Nhu cầu tài nguyên: CPU, RAM, Storage

 Dung lượng sử dụng tối đa

 Chi phí thuê bao theo tháng hoặc theo năm

Năng lực nhà thầu (Contractor / Vendor Capability)

Nếu dự án có nhà thầu hoặc đối tác tham gia, cần ước lượng về năng lực đáp ứng

Các yếu tố đánh giá:

 Kinh nghiệm triển khai các dự án tương tự

 Năng lực kỹ thuật và đội ngũ triển khai

 Công nghệ và công cụ họ sử dụng

 Phương pháp quản lý dự án

 Cam kết SLA và khả năng đáp ứng tiến độ

 Năng lực tài chính và pháp lý

Yêu cầu ước lượng:

 Khối lượng công việc giao cho nhà thầu

 Nguồn lực mà nhà thầu sẽ cung cấp

 Đánh giá rủi ro liên quan đến năng lực của họ

C.3 Ước lượng chi phí (Cost Estimation)

Ước lượng chi phí là quá trình xác định tổng chi phí cần thiết để hoàn thành dự án dựa trên phạm

vi, nguồn lực và tiến độ đã được xác định Đây là cơ sở quan trọng để xây dựng ngân sách, lập

kế hoạch tài chính và kiểm soát chi phí trong suốt vòng đời dự án

* Phương pháp Tương tự (Analogous Estimating) :Sử dụng dữ liệu chi phí từ các dự án tương tự đã thực hiện để dự đoán chi phí cho dự án hiện tại

 Ước lượng sơ bộ (Rough Order of Magnitude)

*Dựa trên tham số (Parametric Estimating): Dựa trên các thông số đo lường (metrics) và mô hìnhthống kê để tính chi phí

Ví dụ: chi phí = đơn giá × khối lượng công việc Chi phí phát triển phần mềm: 200 USD / giờ ×

300 giờ.Chi phí xây dựng: 5 triệu/m² × diện tích sàn

Ưu điểm:

 Chính xác hơn nếu mô hình tham số đúng

 Dễ tính toán và tái sử dụng

Nhược điểm:

 Cần dữ liệu thống kê đáng tin cậy

*Phương pháp từ dưới lên (Bottom-Up Estimating).: Tính chi phí cho từng gói công việc nhỏ nhất (work package) trong WBS, sau đó cộng dồn lên thành chi phí tổng thể

Ưu điểm:

 Độ chính xác cao nhất

 Phù hợp giai đoạn lập kế hoạch chi tiết

Nhược điểm:

 Tốn thời gian.

 Yêu cầu WBS hoàn chỉnh

Ứng dụng:

 Khi yêu cầu, thiết kế và phạm vi đã rõ ràng

*Phân tích giá trị (Value Analysis) : Phân tích để tìm cách đạt được cùng giá trị/deliverable với chi phí thấp hơn hoặc tối ưu hơn (tối ưu hóa chi phí – tính năng)

Ví dụ:

 Thay đổi công nghệ hosting nhằm giảm chi phí vận hành.

 Tận dụng thư viện mã nguồn mở thay vì lập trình từ đầu.

 Tối ưu nguồn lực để giảm thời gian làm việc.

Ứu điểm:

 Giảm chi phí mà vẫn giữ chất lượng

 Tối ưu hóa hiệu quả đầu tư

Kết quả tạo ra:

*Dự toán chi phí (Cost Estimate) : Bao gồm:

 Chi phí trực tiếp (nhân công, thiết bị…)

 Chi phí gián tiếp (quản lý, hành chính)

 Chi phí dự phòng (contingency)

 Dự toán sơ bộ hoặc dự toán chi tiết

Tài liệu này dùng để ra quyết định đầu tư hoặc phê duyệt dự án

Mã WBS Hạng mục / Gói

công việc Đơn vị

Khối lượng Đơn giá Thành tiền

Ghi chú

công 10 1,500,000 =D3*E31.3 Thiết kế hệ thống ngày công 12 1,800,000 =D4*E4

1.4.1 Lập trình Frontend ngày

công 20 1,500,000 =D5*E51.4.2 Lập trình Backend ngày 25 1,700,000 =D6*E6

Mã WBS Hạng mục / Gói công việc Đơn vị lượng Khối Đơn giá Thành tiền Ghi chú

công

Tổng cộng (Cost



*Ngân sách dự án (Project Budget) : Được xây dựng từ Cost Estimate nhưng kèm:

 Phân bổ chi phí theo từng giai đoạn

 Dòng tiền (cash flow) theo tháng/quý

 Dự phòng rủi ro (Management Reserve)

 Kế hoạch kiểm soát và theo dõi chi phí (Cost Baseline)

Ngân sách dự án là cơ sở để:

 Quản lý chi phí

 Đánh giá chênh lệch (Cost Variance, CPI)

 Kiểm soát chi phí theo Earned Value Management (EVM)

1 Cost Estimate =SUM(F2:F8) Từ bảng trên

2 Contingency Reserve (5–15%) =B2*10% Dự phòng rủi ro kỹ thuật

3 Management Reserve (5%) =B2*5% Dự phòng cấp quản lý

4 Total Project Budget =B2 + B3 + B4 Tổng ngân sách dự án

D Lập tiến độ thực hiện dự án (Project Scheduling)

Lập tiến độ là quá trình xác định trình tự các hoạt động, thời gian thực hiện và phân bổ nguồn lực

để đảm bảo dự án hoàn thành đúng hạn Đây là một phần quan trọng của kế hoạch quản lý dự án,giúp kiểm soát thời gian, chi phí và nguồn lực

Các bước xây dựng tiến độ

1.Xác định các hoạt động trong WBS (Define Activities) : Từ các Work Package trong WBS,

phân rã tiếp thành các “hoạt động” (activities) đủ nhỏ để lập tiến độ

 Hoạt động phải rõ ràng, có thể đo lường và dễ ước lượng thời gian

 Mỗi hoạt động gắn với một đầu ra/deliverable cụ thể.

Ví dụ:

WP “Thiết kế giao diện” → Activities:

 Tạo mockup trang chủ

 Tạo mockup trang danh mục

 Review và chỉnh sửa với khách hàng

2.Xác định mối quan hệ giữa các hoạt động (FS, SS, FF, SF) (Determine Dependencies):

1 Ước lượng thời gian cho mỗi hoạt động

2 Xây dựng sơ đồ mạng (Network Diagram)

3 Tính toán đường găng (Critical Path)

4 Tạo biểu đồ Gantt

5 Phân tích chèn nguồn lực (Resource Leveling)

 Sử dụng 3 giá trị thời gian ước lượng:

o Optimistic (O) – Lạc quan

o Most likely (M) – Khả năng cao nhất

 Sơ đồ CPM => CPM Mục đích Xác định đường găng (critical path) – chuỗi hoạt động

quyết định thời gian dự án.Tính toán slack/float (thời gian nới lỏng)

✔ Ứng dụng

 Giúp PM biết công việc nào không được phép trễ, từ đó ưu tiên nguồn lực hợp lý.

✔ Minh họa PERT/CPM (dạng sơ đồ):

A -> B -> D

\ /

→→ C →→→→ E

 Đường A → B → D là đường găng nếu tổng thời gian lớn nhất

 Các công việc trên đường găng phải được kiểm soát chặt chẽ, vì bất kỳ sự trễ nào cũng làm trễ toàn dự án

 Gantt Chart (Biểu đồ Gantt)

✔ Mục đích

 Trực quan hóa tiến độ theo timeline

 Xác định công việc song song, phụ thuộc

 Theo dõi % hoàn thành

✔ Đặc điểm

 Dễ sử dụng, phổ biến trong mọi loại dự án

 Hiển thị bằng thanh ngang theo thời gian

 Phù hợp với dự án CNTT có nhiều nhiệm vụ nhỏ

VÍ DỤ MINH HỌA (DẠNG YÊU CẦU )

 Microsoft Project, Primavera, Jira, Trello

Microsoft Project(ASCII Diagram)

✔ Đặc điểm

 Phần mềm mạnh cho lập kế hoạch tiến độ

 Hỗ trợ Gantt Chart, PERT, CPM

 Theo dõi tài nguyên, chi phí, tải công việc

✔ Ưu điểm

 Phù hợp dự án lớn, nhiều phụ thuộc

 Tích hợp phân bổ tài nguyên (Resource allocation)

✔ Nhược điểm

 Khá phức tạp, yêu cầu người dùng có kỹ năng

 Không phù hợp nhóm làm việc linh hoạt/agile

 📌 Sơ đồ giao diện và cấu trúc Microsoft Project (ASCII Diagram)

 | Task List | Gantt Chart |Time |

 | (Danh sách công việc)| (Biểu đồ thanh tiến độ) |Scale |

 | Resource Sheet | Resource Graph |

 | (Danh sách tài nguyên) | (Biểu đồ tải tài nguyên) |

 | Task Details / Notes pane |

 | (Thông tin công việc: mô tả, liên kết, tài nguyên liên quan) |

| Lập kế | | Quản lý tiến | | Quản lý tài |

| hoạch | | độ (Schedule) | | nguyên (Resource)|

| dự án | | Gantt, CPM, PERT| | phân bổ, tải |

| Theo dõi & Báo cáo|

| Cost, Reports |

+ -+

Primavera (Oracle Primavera)

✔ Đặc điểm

 Công cụ cao cấp dành cho quản lý dự án quy mô lớn (ERP, xây dựng hệ thống hạ tầng…)

 Mạnh về phân tích rủi ro, chi phí, lịch biểu phức tạp

✔ Ưu điểm

 Xử lý dự án lớn tốt hơn Microsoft Project

 Quản lý nhiều dự án cùng lúc (project portfolio)

| Project | | Resource Mgmt | | Portfolio Mgmt |

| Planning | | Quản lý tài | | Quản lý danh mục |

| Lập tiến | | nguyên & phân | | dự án |

| độ, CPM | | bổ nguồn lực | | ưu tiên dự án |

 Quản lý dự án theo Agile/Scrum/Kanban

 Theo dõi backlog, sprint, user story, bug

✔ Ưu điểm

 Phù hợp dự án phần mềm

 Mạnh về workflow, quản lý issue

 Tích hợp với Confluence, Bitbucket, GitHub

✔ Nhược điểm

 Không mạnh về lập tiến độ dạng CPM/Gantt

 Cần thiết lập ban đầu khá phức tạp

✔ Đặc điểm

 Công cụ Kanban dạng kéo – thả

 Nhẹ, đơn giản, dễ tiếp cận

✔ Ưu điểm

 Dùng được ngay không cần cấu hình nhiều

 Hợp nhóm nhỏ, startup, freelancer

✔ Nhược điểm

 Không có quản lý tiến độ phức tạp

 Không phù hợp dự án lớn hoặc nhiều phụ thuộc

o Sơ đồ chức năng tổng quan Jira + -+

| JIRA | | (Atlassian Platform)|

+ -+ -+

| + -+ -+

| | | + -+ -+ + -+ -+ + -+ -+

| Issue | | Agile Boards | | Reporting & |

| Management | | Scrum / Kanban | | Dashboards |

| (Task, Bug, | | Sprint, Backlog | | Burndown, Velocity|

| Story, Epic)| + -+ -+ + -+ + -+ |

|

| Projects | Filters | Boards | Reports | Create Issue | + -+

Left Panel (Backlog View)

Main Panel (Board) -

| To Do | In Progress | Review | Done |

| -| -| -| -|

| • Implement Login UI | • API Authentication | | |

| • Design Dashboard | • Database Setup | • Code Rev | • Deploy|

| • Fix Bug #142 | | | | -

E Lập kế hoạch phòng ngừa và hạn chế rủi ro (Risk

Management Planning)

Quản lý rủi ro là một phần quan trọng trong quản lý dự án CNTT Mục tiêu của lập kế hoạch rủi

ro là định danh – phân tích – dự báo – phòng ngừa những vấn đề có thể ảnh hưởng đến tiến

độ, chi phí, chất lượng hoặc phạm vi dự án

E.1 Nhận diện rủi ro : là tiến trình xác định tất cả các rủi ro tiềm ẩn có thể xảy ra trong suốt

vòng đời dự án

Dưới đây là các nhóm rủi ro phổ biến trong dự án CNTT:

+ -+

| NGUỒN RỦI RO | + -+ -+ -+

| 1 Kỹ thuật | 2 Con người | 3 Tài chính | + -+ -+ -+

| 4 Pháp lý | 5 Môi trường | 6 Nhà cung cấp | + -+

Kỹ thuật Rủi ro kỹ thuật (Technical Risks)

Bao gồm rủi ro liên quan đến công nghệ, thiết kế, chất lượng sản phẩm:

 Công nghệ mới chưa ổn định

 Hệ thống phức tạp, khó tích hợp

 Thiếu tài liệu kỹ thuật

 Giải pháp không đáp ứng yêu cầu

 Bugs nghiêm trọng, lỗi performance

 Hạ tầng không đủ mạnh

Rủi ro con người (Human Risks)

Liên quan đến đội dự án và các bên liên quan:

 Thiếu nhân lực hoặc nhân sự nghỉ việc

 Kỹ năng không phù hợp với công nghệ

 Thiếu kinh nghiệm thực tế

 Giao tiếp kém, xung đột nhóm

 Quản lý yếu, phân công không rõ ràng

Rủi ro tài chính (Financial Risks)

Liên quan đến nguồn lực tiền, chi phí phát sinh:

 Ngân sách dự án bị cắt giảm

 Chi phí tăng do thay đổi yêu cầu

 Khách hàng chậm thanh toán

 Phát sinh công việc không dự đoán

Rủi ro pháp lý (Legal Risks)

 Vi phạm bản quyền phần mềm

 Quy định pháp luật thay đổi

 Vi phạm điều khoản hợp đồng

 Lưu trữ dữ liệu không tuân thủ Nghị định/chuẩn bảo mật

Rủi ro môi trường (Environmental Risks)

Bao gồm yếu tố khách quan bên ngoài:

 Thiên tai (ảnh hưởng data center)

 Thay đổi chính sách của quốc gia

 Dịch bệnh ảnh hưởng năng suất

 Yếu tố xã hội – văn hóa

Rủi ro nhà cung cấp (Vendor Risks)

Phát sinh khi dự án phụ thuộc nhà cung cấp:

 Nhà cung cấp giao hàng trễ

 Không hỗ trợ kỹ thuật đúng cam kết

 Thiết bị/hạ tầng không chất lượng

 Nhà cung cấp phá sản hoặc ngừng hoạt động

📌 Sơ đồ hóa quá trình nhận diện rủi ro

| 2 Phân loại rủi ro |

| (Tech, Finance, Human ) |

+ -+ -+

|

E.2 Phân tích rủi ro

Sau khi nhận diện rủi ro, bước tiếp theo là phân tích để hiểu mức độ nghiêm trọng và ưu tiên xử

lý

Có hai phương pháp chính:

 Phân tích định tính (Qualitative Risk Analysis)

Là phương pháp đánh giá mức độ ưu tiên của rủi ro dựa trên:

 Xác suất (Probability)

 Mức độ tác động (Impact)

 Mức độ cấp bách, xu hướng, mối liên quan

Đây là phương pháp nhanh, dễ thực hiện, và được dùng trong mọi dự án.

Sơ đồ các bước phân tích

+ -+

| 1 Đánh giá xác suất |

+ -+ -+

|

Sau khi nhận diện và phân tích rủi ro, bước tiếp theo là xây dựng kế hoạch ứng phó để:

 Giảm khả năng xảy ra rủi ro

 Giảm mức độ tác động khi rủi ro xảy ra

 Tối ưu thời gian và chi phí dự phòng

 Đảm bảo mục tiêu dự án không bị ảnh hưởng nghiêm trọng

Đây là bước bắt buộc trong quản lý rủi ro của dự án CNTT.

Các chiến lược:

 Tránh (Avoid)

→ Loại bỏ hoàn toàn rủi ro bằng cách thay đổi phạm vi, kế hoạch, yêu cầu hoặc phương pháp

Ví dụ:

 Yêu cầu quá phức tạp → loại khỏi phạm vi.

 Công nghệ mới quá rủi ro → dùng công nghệ ổn định hơn.

📌 Sơ đồ chiến lược Tránh (Avoid) │ Nhận diện rủi ro │

│ công nghệ, thiết kế hoặc quy trình │

└───────────────┬─────────────────────────┘ │

▼

┌─────────────────────────────────────────┐ │ Điều chỉnh kế hoạch dự án │

│ (thay đổi lịch, nguồn lực, giải pháp) │

└───────────────┬─────────────────────────┘ │

▼

┌─────────────────────────────────────────┐

│ Rủi ro đã được loại bỏ? │

└───────────────┬───────────────┬────────┘ │ │

Nếu Có ▼ ▼ Nếu Không

┌──────────────────────────┐

┌───────────────────────────┐

│ Tiếp tục triển khai dự án│ │ Kết hợp chiến lược khác │

│ (Risk Removed) │ │ (Mitigate / Transfer) │

└──────────────────────────┘

└───────────────────────────┘

 Giảm thiểu (Mitigate)

 Giảm khả năng xảy ra hoặc giảm mức độ ảnh hưởng

 Tăng nguồn lực, kiểm thử sớm, thêm dự phòng…

Ví dụ:

 Thêm nhân lực cho module phức tạp để giảm rủi ro trễ hạn.

📌 Sơ đồ chiến lược Giảm thiểu (Mitigate) ┌───────────────────────────┐

│ Nhận diện rủi ro │ └───────────────┬───────────┘

│ ▼ ┌───────────────────────────┐

│ Phân tích xác suất & │ │ mức độ ảnh hưởng │ └───────────────┬───────────┘

│ Rủi ro cao? ─────┼────→ Nếu Không → Accept hoặc Monitor

│ ▼ ┌──────────────────────────────┐

│ Lựa chọn chiến lược │ │ *Giảm thiểu (Mitigate)* │ └───────────────┬──────────────┘

│ ▼ ┌─────────────────────────────────────────┐

│ Xác định biện pháp giảm xác suất │

│ (đào tạo, kiểm thử, quy trình chuẩn )│

└───────────────┬─────────────────────────┘

│ ▼ ┌─────────────────────────────────────────┐

│ Xác định biện pháp giảm mức độ │ │ ảnh hưởng (tăng dự phòng, thêm nhân lực)│

└───────────────┬─────────────────────────┘

│ ▼ ┌─────────────────────────────────────────┐

│ Thực hiện các biện pháp giảm thiểu │ └───────────────┬─────────────────────────┘

│ ▼ ┌─────────────────────────────────────────┐

│ Đánh giá lại mức độ rủi ro sau giảm thiểu│

└───────────────┬──────────────┬─────────┘

│ │ Nếu đạt mức ▼ ▼ Nếu không đạt chấp nhận ┌───────────────────────────┐

┌─────────│ Tiếp tục triển khai │ │ │ (Risk Mitigated) │

│ └───────────────────────────┘

│ ▼

┌──────────────────────────────────────┐

│ Lựa chọn chiến lược khác (Avoid/ │

│ Transfer/Accept) nếu cần thiết │

└──────────────────────────────────────┘

 Chuyển giao (Transfer)

 Chuyển trách nhiệm rủi ro cho bên thứ ba

 Thường đi kèm chi phí: bảo hiểm, thuê ngoài, SLA với vendor

Ví dụ:

 Thuê nhà cung cấp hỗ trợ bảo mật thay vì tự làm

📌 Sơ đồ chiến lược Chuyển giao (Transfer)