Bài 5

Thực thi, Theo dõi & Rủi ro

Kế hoạch chỉ có giá trị khi được theo dõi và điều chỉnh. Bài này tập trung vào ba việc cốt lõi trong giai đoạn vận hành dự án: đo tiến độ một cách trung thực, quản trị rủi ro một cách chủ động, và giao tiếp đủ rõ để mọi người cùng nhìn về một hướng.

Theo dõi tiến độ — chỉ số Agile

Đo đúng để điều chỉnh kịp

Trong môi trường Agile, tiến độ không đo bằng "đã làm xong bao nhiêu trang tài liệu" mà bằng lượng giá trị thực sự bàn giao được qua từng vòng lặp. Một vài chỉ số nền tảng:

Velocity là số story point (hoặc số hạng mục) mà nhóm hoàn thành trọn vẹn trong mỗi sprint. Lấy trung bình velocity của 3–5 sprint gần nhất, ta dự báo được nhóm có thể cam kết bao nhiêu cho sprint tới và còn bao nhiêu sprint nữa để xử lý hết backlog. Velocity là chỉ số nội bộ để lập kế hoạch — không nên dùng để so sánh nhóm này với nhóm khác hay làm thước đo năng suất ép tiến độ.

Burndown chart biểu diễn khối lượng công việc còn lại theo thời gian: trục đứng là số point/giờ chưa xong, trục ngang là ngày trong sprint. Đường lý tưởng đi thẳng từ tổng scope xuống 0 vào ngày cuối; đường thực tế nằm trên đường lý tưởng nghĩa là đang chậm, nằm dưới nghĩa là đang nhanh hơn dự kiến. Đường gần như đi ngang vài ngày liền là dấu hiệu công việc bị tắc.

Burnup chart vẽ hai đường: đường "đã hoàn thành" đi lên dần và đường "tổng scope". Ưu điểm so với burndown là nhìn thấy ngay scope creep: khi đường tổng scope đột nhiên nhảy lên, tức là phạm vi vừa bị thêm việc. Burndown gộp cả hai yếu tố này nên dễ giấu việc phình scope, còn burnup tách bạch rõ ràng.

Cumulative Flow Diagram (CFD) dành cho Kanban: là biểu đồ vùng (stacked area) thể hiện số hạng mục ở từng trạng thái (To Do / In Progress / Done) theo thời gian. Đọc CFD: dải "In Progress" phình to dần báo hiệu nghẽn cổ chai (WIP quá cao); khoảng cách dọc giữa các đường cho biết lead time và lượng tồn đọng; các dải chạy song song đều đặn là dòng chảy công việc khỏe mạnh.

Lưu ý: các biểu đồ này là công cụ để nhóm tự soi và cải tiến, không phải để "chấm điểm" cá nhân. Khi chỉ số bị dùng làm vũ khí, nhóm sẽ học cách làm đẹp số liệu thay vì làm tốt công việc.

Earned Value Management (EVM)

Đo cùng lúc chi phí và tiến độ

EVM là phương pháp kinh điển (mạnh trong dự án predictive/waterfall) giúp trả lời câu hỏi: "Với số tiền đã tiêu, chúng ta thực sự làm được bao nhiêu, và đang nhanh hay chậm?". Tất cả dựa trên ba giá trị nền:

Ký hiệu	Tên	Ý nghĩa
PV	Planned Value	Giá trị (chi phí) công việc lẽ ra đã hoàn thành tính đến thời điểm này theo kế hoạch
EV	Earned Value	Giá trị công việc thực sự đã hoàn thành, quy theo ngân sách dự kiến
AC	Actual Cost	Chi phí thực tế đã bỏ ra để làm khối lượng đó

Từ ba giá trị trên, ta tính được các chỉ số sai lệch và hiệu suất (viết dạng text):

SV  (Schedule Variance) = EV - PV
CV  (Cost Variance)     = EV - AC
SPI (Schedule Perf. Index) = EV / PV
CPI (Cost Perf. Index)     = EV / AC
EAC (Estimate At Completion) = BAC / CPI

Diễn giải nhanh: với SV/CV, số dương là tốt (vượt kế hoạch / dưới ngân sách), số âm là xấu. Với các chỉ số tỷ lệ: SPI < 1 nghĩa là đang chậm tiến độ, CPI < 1 nghĩa là đang vượt chi (tiêu nhiều hơn giá trị làm ra); bằng 1 là đúng kế hoạch, lớn hơn 1 là tốt hơn kế hoạch. EAC = BAC/CPI ước tính tổng chi phí khi hoàn thành dựa trên đà chi tiêu hiện tại (BAC là Budget At Completion — tổng ngân sách ban đầu).

Chỉ số	Công thức	Đọc ra sao
SV	EV − PV	> 0 vượt kế hoạch; < 0 chậm
CV	EV − AC	> 0 tiết kiệm; < 0 vượt chi
SPI	EV ÷ PV	< 1 chậm; = 1 đúng hẹn; > 1 nhanh
CPI	EV ÷ AC	< 1 vượt chi; = 1 đúng ngân sách; > 1 tiết kiệm
EAC	BAC ÷ CPI	Tổng chi phí dự kiến khi xong theo đà hiện tại

Ví dụ số: Dự án tổng ngân sách BAC = 100 triệu. Theo kế hoạch tới hôm nay phải xong 50% → PV = 50 triệu. Thực tế mới xong 40% → EV = 40 triệu. Tiền đã tiêu AC = 60 triệu. Khi đó SV = 40 − 50 = −10 (chậm), CV = 40 − 60 = −20 (vượt chi), SPI = 40/50 = 0,8 (chậm 20%), CPI = 40/60 ≈ 0,67 (rất vượt chi). EAC = 100/0,67 ≈ 150 triệu — nếu cứ đà này, dự án sẽ tốn gấp rưỡi ngân sách.

Quản trị rủi ro (Risk Management)

Chủ động thay vì chữa cháy

Rủi ro là sự kiện chưa chắc xảy ra nhưng nếu xảy ra sẽ tác động đến mục tiêu dự án (xấu hoặc tốt). Quản trị rủi ro là một vòng lặp liên tục, không phải việc làm một lần đầu dự án:

Nhận diện (Identify): liệt kê mọi rủi ro tiềm tàng — qua brainstorm, phỏng vấn chuyên gia, bài học từ dự án cũ, checklist. Càng sớm và càng rộng càng tốt.
Phân tích (Analyze): Định tính — chấm mỗi rủi ro theo ma trận Xác suất × Tác động để xếp ưu tiên. Định lượng — quy ra con số (ví dụ giá trị tiền kỳ vọng = xác suất × thiệt hại), dùng cho rủi ro lớn cần phân tích sâu.
Lập kế hoạch ứng phó (Respond): với mỗi rủi ro ưu tiên cao, chọn chiến lược và giao người chịu trách nhiệm (risk owner).
Theo dõi (Monitor): rà soát định kỳ — rủi ro nào đã hết, rủi ro nào tăng mức, rủi ro mới nào xuất hiện; cập nhật risk register.

Ma trận định tính chấm điểm rủi ro theo hai trục, kết quả ra mức ưu tiên:

Xác suất \ Tác động	Thấp	Trung bình	Cao
Cao	Trung bình	Cao	Cao
Trung bình	Thấp	Trung bình	Cao
Thấp	Thấp	Thấp	Trung bình

Ma trận rủi ro — Xác suất x Tác động Scroll / zoom · Mở draw.io ↗

Đọc ma trận: ô góc dưới-trái (xác suất thấp x tác động thấp) là vùng xanh ít nguy hiểm; càng lên góc trên-phải (xác suất cao x tác động cao) càng chuyển sang vàng → cam → đỏ. Số trong mỗi ô là tích Xác suất x Tác động (1–25) dùng để xếp ưu tiên xử lý.

Với rủi ro tiêu cực (threat), có bốn chiến lược ứng phó:

Chiến lược	Bản chất	Ví dụ
Avoid (Né)	Loại bỏ nguyên nhân để rủi ro không thể xảy ra	Bỏ một tính năng quá rủi ro khỏi phạm vi
Mitigate (Giảm)	Giảm xác suất hoặc mức tác động	Làm prototype sớm, thêm kiểm thử, dự phòng tài nguyên
Transfer (Chuyển)	Chuyển hậu quả sang bên thứ ba	Mua bảo hiểm, thuê ngoài, ký hợp đồng fixed-price
Accept (Chấp nhận)	Không hành động trước, chỉ chuẩn bị (có thể lập quỹ dự phòng)	Chấp nhận rủi ro nhỏ, để dành contingency reserve

Với rủi ro tích cực (cơ hội / opportunity), cũng có bốn chiến lược tương ứng:

Chiến lược	Bản chất
Exploit (Khai thác)	Làm mọi cách để cơ hội chắc chắn xảy ra
Enhance (Tăng cường)	Tăng xác suất hoặc lợi ích của cơ hội
Share (Chia sẻ)	Bắt tay đối tác giỏi hơn để cùng nắm bắt cơ hội
Accept (Chấp nhận)	Sẵn sàng tận dụng nếu cơ hội đến, nhưng không chủ động theo đuổi

Risk register (sổ rủi ro) là nơi ghi tập trung tất cả: mã rủi ro, mô tả, xác suất, tác động, mức ưu tiên, chiến lược ứng phó, người chịu trách nhiệm và trạng thái. Đây là tài liệu sống, cập nhật suốt vòng đời dự án.

Risk vs Issue: risk là việc chưa xảy ra (mang tính dự phòng), còn issue là việc đã xảy ra và đang cần xử lý ngay. Khi một rủi ro thành hiện thực, nó chuyển từ risk register sang issue log. Đừng nhầm lẫn hai khái niệm này khi báo cáo.

Quản lý thay đổi (Change Control)

Giữ baseline khỏi trôi

Thay đổi trong dự án là điều bình thường, nhưng thay đổi không kiểm soát mới là nguy hiểm. Một quy trình change control chuẩn gồm các bước:

Change Request (Yêu cầu thay đổi): mọi đề xuất thay đổi phải được ghi nhận chính thức bằng văn bản, không xử lý kiểu "nói miệng rồi làm luôn".
Đánh giá tác động: phân tích thay đổi ảnh hưởng thế nào đến scope, thời gian (time) và chi phí (cost) — cùng cả rủi ro và chất lượng. Đây là bước then chốt để ra quyết định có cơ sở.
Phê duyệt: Change Control Board (CCB) — hội đồng có thẩm quyền — xem xét và quyết định chấp thuận, từ chối hay hoãn.
Cập nhật baseline: nếu được duyệt, cập nhật lại baseline về scope/lịch/ngân sách và truyền đạt cho toàn nhóm để mọi người làm theo bản mới.

Kiểm soát scope creep: scope creep là phạm vi phình ra từng chút một mà không qua phê duyệt — cộng dồn lại đủ làm vỡ tiến độ và ngân sách. Quy trình change control chính là hàng rào: mọi việc thêm vào đều phải đi qua cửa "đánh giá tác động → phê duyệt".

Giao tiếp & Stakeholder

Phần lớn công việc của PM

Người ta thường ước tính một quản lý dự án dành phần lớn thời gian (khoảng 80–90%) cho việc giao tiếp — chứ không phải ngồi vẽ Gantt. Giao tiếp tốt là yếu tố quyết định thành bại nhiều hơn cả công cụ.

Kế hoạch giao tiếp (communication plan) trả lời gọn bốn câu hỏi cho từng bên liên quan: ai cần thông tin – cần gì (nội dung, mức chi tiết) – tần suất bao lâu một lần – và qua kênh nào (email, họp, dashboard, chat). Mỗi nhóm stakeholder cần liều lượng khác nhau: ban lãnh đạo cần bản tóm tắt cấp cao theo tháng, đội kỹ thuật cần chi tiết hằng ngày.

Status report định kỳ nên ngắn và nhất quán: tiến độ so kế hoạch, các mốc sắp tới, rủi ro/vấn đề nổi bật, và những việc cần quyết định. Một mẫu phổ biến dùng màu đèn giao thông (Xanh/Vàng/Đỏ) cho từng hạng mục.

RAID log là công cụ theo dõi gộp bốn nhóm thông tin quan trọng:

Chữ	Nhóm	Nội dung
R	Risks	Rủi ro tiềm tàng chưa xảy ra
A	Assumptions	Giả định đang dựa vào (nếu sai sẽ thành rủi ro)
I	Issues	Vấn đề đã xảy ra, cần xử lý
D	Dependencies	Phụ thuộc vào bên/việc khác

Họp hiệu quả: mỗi cuộc họp cần có mục tiêu rõ, agenda gửi trước, đúng người tham dự, kết thúc bằng các action item có người phụ trách và hạn chót. Họp mà không ra quyết định hay hành động là họp lãng phí.

Chất lượng & Đóng dự án

Làm đúng, rồi khép lại tử tế

Quản lý chất lượng có hai mặt dễ nhầm:

Khái niệm	Trọng tâm	Cách làm
Quality Assurance (QA)	Hướng vào quy trình — ngăn lỗi ngay từ cách làm	Chuẩn hóa quy trình, audit, review, cải tiến cách thức làm việc
Quality Control (QC)	Hướng vào sản phẩm — phát hiện lỗi ở đầu ra	Kiểm thử, đo lường, nghiệm thu từng sản phẩm bàn giao

Khi sản phẩm hoàn thành, nghiệm thu là bước khách hàng/chủ đầu tư xác nhận sản phẩm đạt tiêu chí chấp nhận (acceptance criteria) đã thống nhất — đây là cơ sở để công nhận hạng mục đã "Done" thật sự.

Đóng dự án (closing) không chỉ là "làm xong rồi nghỉ". Cần thực hiện đầy đủ: tổng kết bài học kinh nghiệm (lessons learned), đóng hợp đồng với nhà cung cấp/đối tác, bàn giao sản phẩm và tài liệu cho bên vận hành, giải phóng nguồn lực và lưu trữ hồ sơ dự án.

Retrospective / Lessons learned: sau mỗi sprint (retrospective) hay cuối dự án (lessons learned), nhóm cùng nhìn lại điều gì tốt, điều gì cần cải thiện và cam kết một vài hành động cụ thể. Đây là cơ chế để tổ chức học hỏi và liên tục cải tiến — đừng để buổi này trôi qua hình thức.