Mở đầu — vì sao bài này quan trọng
Ở Bài 21, bạn đã học cách nhận diện (identify) rủi ro — nghĩa là lập được một danh sách dài các rủi ro có thể xảy ra với dự án, ghi vào Risk Register. Nhưng ở đây có một vấn đề rất thực tế: danh sách đó thường dài đến mức choáng ngợp. Một dự án phần mềm cỡ trung bình dễ dàng có 40–80 rủi ro trong sổ đăng ký. Nếu bạn cố gắng xử lý tất cả với cùng một mức độ nghiêm túc, bạn sẽ đốt cháy toàn bộ thời gian và ngân sách chỉ để phòng ngừa những chuyện gần như không bao giờ xảy ra, trong khi bỏ sót vài "quả bom" thực sự có thể làm nổ tung dự án.
Đây chính là lúc Qualitative Risk Analysis (Phân tích rủi ro định tính) bước vào. Đây là bước sàng lọc và sắp xếp thứ tự ưu tiên (prioritize) cho rủi ro, dựa trên hai yếu tố cốt lõi: xác suất xảy ra (probability) và mức độ ảnh hưởng (impact). Điểm mấu chốt — và cũng là điểm khiến nhiều bạn Project Manager (PM) mới hiểu lầm — là bước này không cần số liệu chính xác. Bạn không tính "rủi ro này gây thiệt hại đúng 237 triệu đồng" (đó là việc của Quantitative Analysis ở Bài 23). Ở đây, bạn chỉ cần đánh giá tương đối: rủi ro này Cao hay Thấp, Nghiêm trọng hay Nhẹ.
Nghe có vẻ đơn giản, nhưng đây là kỹ năng phân biệt một PM nghiệp dư với một PM chuyên nghiệp. Người giỏi biết cách nhanh chóng tách ra 5–7 rủi ro thực sự đáng lo trong hàng chục cái, để đội ngũ tập trung năng lượng vào đúng chỗ. Bài này sẽ dạy bạn làm điều đó một cách có hệ thống.
Khái niệm cốt lõi
Qualitative Risk Analysis là gì?
Qualitative Risk Analysis là quá trình đánh giá và ưu tiên hóa các rủi ro đã được nhận diện, bằng cách kết hợp xác suất xảy ra và mức độ ảnh hưởng lên mục tiêu dự án (thời gian, chi phí, phạm vi, chất lượng). Kết quả đầu ra là một danh sách rủi ro được xếp hạng — từ "cần hành động ngay" đến "chỉ cần theo dõi".
Chữ "định tính" (qualitative) là chìa khóa. Bạn dùng các thang đo mô tả như Rất thấp – Thấp – Trung bình – Cao – Rất cao, thay vì con số tuyệt đối. Điều này khiến bước phân tích trở nên nhanh, rẻ, và có thể làm được ngay cả khi bạn chưa có nhiều dữ liệu — điều rất phù hợp với đa số dự án ở Việt Nam vốn thường thiếu dữ liệu lịch sử.
Hai trục đánh giá: Probability và Impact
Probability (Xác suất) — Khả năng rủi ro thực sự xảy ra là bao nhiêu? Ta thường quy về thang 5 mức và gán một khoảng phần trăm tương đối để đội ngũ dễ đồng thuận:
- Rất thấp (1): dưới 10%
- Thấp (2): 10–30%
- Trung bình (3): 30–50%
- Cao (4): 50–70%
- Rất cao (5): trên 70%
- Rất thấp (1): trễ dưới 1 ngày
- Thấp (2): trễ 1–3 ngày
- Trung bình (3): trễ 1 tuần
- Cao (4): trễ 2–4 tuần
- Rất cao (5): trễ trên 1 tháng, ảnh hưởng cột mốc chính
Probability × Impact Matrix
Đây là công cụ trực quan nhất của bước này — ma trận xác suất và ảnh hưởng. Ta nhân điểm Probability với điểm Impact để ra điểm rủi ro (Risk Score), rồi tô màu theo vùng.
Impact → RThấp(1) Thấp(2) TB(3) Cao(4) RCao(5)
Prob ↓
RCao (5) 5 10 15 20 25
Cao (4) 4 8 12 16 20
TB (3) 3 6 9 12 15
Thấp (2) 2 4 6 8 10
RThấp(1) 1 2 3 4 5
Cách đọc ma trận theo màu:
- Vùng Đỏ (điểm 12–25): Rủi ro cao. Cần lập kế hoạch ứng phó chi tiết (xem Bài 24), phân công người chịu trách nhiệm (risk owner), theo dõi sát.
- Vùng Vàng (điểm 6–10): Rủi ro trung bình. Cần chuẩn bị phương án dự phòng, theo dõi định kỳ.
- Vùng Xanh (điểm 1–5): Rủi ro thấp. Đưa vào "watch list" — chỉ theo dõi, chưa cần hành động tốn kém.
Các yếu tố bổ sung: không chỉ có P×I
Một PM giỏi không dừng ở điểm P×I. Còn hai yếu tố nên cân nhắc:
- Urgency (Tính cấp bách): Rủi ro sắp xảy ra trong 1 tuần khác hẳn với rủi ro có thể xảy ra sau 6 tháng, dù điểm P×I bằng nhau. Rủi ro gần cần được đẩy lên ưu tiên. Sự kết hợp P×I và urgency đôi khi được gọi là criticality.
- Data Quality Assessment (Chất lượng dữ liệu): Đánh giá của bạn dựa trên thông tin đáng tin đến đâu? Nếu bạn đoán mò, hãy đánh dấu để sau này rà lại khi có thêm dữ liệu.
Tình huống thực tế
Ví dụ 1 — Dự án e-commerce của Tiki (giả định hợp lý)
Một đội tại Tiki triển khai tính năng "thanh toán trả góp qua thẻ tín dụng" trước mùa sale 11/11, với deadline cứng là ngày 1/11 để kịp kiểm thử. Risk Register có 34 rủi ro. PM tổ chức một buổi workshop 2 giờ để phân tích định tính. Ba rủi ro nổi bật:
- R1 — Đối tác ngân hàng chậm cung cấp API sandbox: Probability = Cao (4, vì lịch sử ngân hàng này thường chậm), Impact = Rất cao (5, vì không có sandbox thì không thể tích hợp). Risk Score = 20 → Đỏ.
- R2 — Nhân sự backend chủ chốt xin nghỉ phép cưới đúng tuần cao điểm: Probability = Rất cao (5, đã có đơn xin nghỉ), Impact = Cao (4). Score = 20 → Đỏ.
- R3 — Giao diện màn hình trả góp bị lệch trên một số dòng điện thoại cũ: Probability = Trung bình (3), Impact = Thấp (2). Score = 6 → Vàng.
Bài học: Cảm giác trực giác về rủi ro thường sai. Ma trận buộc đội nhìn vào bằng chứng thay vì cảm xúc, và nhờ đó phân bổ nguồn lực đúng chỗ.
Ví dụ 2 — Dự án gia công phần mềm tại một công ty outsourcing ở TP.HCM
Một công ty gia công (giả định tên VinaSoft) nhận dự án xây dựng hệ thống quản lý kho cho khách hàng Nhật Bản. PM người Việt lập Risk Register nhưng gặp vấn đề kinh điển: mỗi thành viên đánh giá impact theo cảm tính riêng. Bạn dev trẻ đánh "yêu cầu thay đổi liên tục" là Impact = Thấp (vì cậu ấy code nhanh), trong khi bạn QA đánh Rất cao (vì cứ đổi là phải test lại toàn bộ).
PM giải quyết bằng cách trước tiên thống nhất bảng định nghĩa mức Impact: quy định rõ "Impact Cao = phải làm lại trên 3 ngày công". Sau khi có thước đo chung, rủi ro "khách hàng thay đổi yêu cầu do khác biệt văn hóa giao tiếp" được đánh Probability = Rất cao (5, đặc thù khách Nhật rất kỹ và hay tinh chỉnh), Impact = Cao (4). Score = 20 → Đỏ.
Diễn giải: Rủi ro này được đưa lên hàng đầu. Đội quyết định phản ứng bằng cách chốt yêu cầu theo từng sprint ngắn và có một Bridge SE (kỹ sư cầu nối biết tiếng Nhật) làm việc sát khách hàng.
Bài học: Qualitative Analysis chỉ đáng tin khi cả đội dùng chung một thước đo. Nếu không, "định tính" sẽ biến thành "cảm tính". Việc đầu tiên PM cần làm không phải là chấm điểm, mà là thống nhất định nghĩa thang đo.
Ví dụ 3 — Dự án xây dựng chi nhánh ngân hàng
Một PM tại một ngân hàng thương mại ở Hà Nội quản lý dự án khai trương 5 chi nhánh mới trong quý. Có rủi ro "giấy phép phòng cháy chữa cháy (PCCC) chậm được cấp". Đánh giá: Probability = Trung bình (3), Impact = Rất cao (5, vì không có giấy phép thì tuyệt đối không được khai trương — đây là ràng buộc pháp lý). Score = 15 → Đỏ.
Điều thú vị: một rủi ro khác, "băng-rôn khai trương giao trễ", có Probability = Cao (4) nhưng Impact = Rất thấp (1). Score = 4 → Xanh. Dù xác suất trễ cao, hậu quả nhỏ (có thể in gấp chỗ khác trong 1 ngày).
Diễn giải: PM tập trung nguồn lực vào việc theo dõi hồ sơ PCCC, thậm chí thuê đơn vị tư vấn chuyên trách, trong khi rủi ro băng-rôn chỉ để một thực tập sinh theo dõi.
Bài học: Impact thường quan trọng hơn Probability trong việc quyết định mức ưu tiên. Một rủi ro xác suất thấp nhưng impact "chết người" (như vấn đề pháp lý, an toàn) luôn cần được coi trọng hơn một rủi ro hay xảy ra nhưng vô hại.
Hướng dẫn từng bước
Đây là quy trình thực hiện Qualitative Risk Analysis mà bạn có thể áp dụng ngay:
- Chuẩn bị đầu vào: Lấy Risk Register từ bước Identification (Bài 21) và Risk Management Plan (nếu có). Đảm bảo mỗi rủi ro được mô tả rõ ràng theo cấu trúc "Nếu [nguyên nhân] thì [sự kiện] dẫn đến [hậu quả]".
- Định nghĩa thang đo trước khi chấm: Viết ra bảng định nghĩa 5 mức Probability và 5 mức Impact cho từng mục tiêu (tiến độ, chi phí, chất lượng). Thống nhất với đội. Đây là bước quan trọng nhất và hay bị bỏ qua nhất.
- Đánh giá xác suất cho từng rủi ro: Với mỗi rủi ro, cả nhóm cùng gán điểm Probability (1–5). Nên dùng kỹ thuật đồng thuận nhóm để tránh thiên kiến cá nhân.
- Đánh giá ảnh hưởng cho từng rủi ro: Gán điểm Impact (1–5). Nếu một rủi ro ảnh hưởng nhiều mục tiêu, lấy điểm cao nhất hoặc mục tiêu quan trọng nhất.
- Tính Risk Score và đặt lên ma trận: Nhân P × I, xác định vùng màu Đỏ/Vàng/Xanh.
- Xét thêm urgency và data quality: Điều chỉnh ưu tiên nếu có rủi ro cấp bách hoặc dữ liệu đánh giá đáng ngờ.
- Phân nhóm và xếp hạng: Sắp xếp toàn bộ rủi ro theo thứ tự ưu tiên. Lọc ra Top 5–10 rủi ro Đỏ để tập trung xử lý.
- Cập nhật Risk Register: Ghi lại điểm số, xếp hạng, phân loại. Đây là đầu vào cho Risk Response Planning (Bài 24).
- Lên lịch rà soát lại: Qualitative Analysis không phải làm một lần. Hãy lặp lại định kỳ (ví dụ mỗi sprint hoặc mỗi cột mốc) vì rủi ro thay đổi theo thời gian.
Lỗi thường gặp & mẹo
Lỗi 1 — Chấm điểm mà chưa định nghĩa thang đo. Đây là lỗi số một. Không có định nghĩa chung thì "Cao" của người này là "Trung bình" của người kia. Mẹo: Luôn dành 15 phút đầu buổi để thống nhất bảng định nghĩa.
Lỗi 2 — Chỉ nhìn vào Probability, quên Impact. Nhiều người bị hút vào những rủi ro "hay xảy ra" mà quên rằng một rủi ro hiếm nhưng thảm khốc mới đáng sợ. Mẹo: Khi hai rủi ro cùng điểm, ưu tiên cái có Impact cao hơn.
Lỗi 3 — Thiên kiến nhóm và hiệu ứng người có tiếng nói to. Trong buổi workshop, ý kiến của sếp hoặc người nói nhiều thường lấn át. Mẹo: Dùng chấm điểm ẩn danh (mỗi người ghi điểm riêng trước, rồi so sánh) để giảm thiên kiến.
Lỗi 4 — Làm một lần rồi bỏ. Risk Register bị "đóng bụi" sau khi phân tích. Mẹo: Đặt lịch rà soát rủi ro cố định trong nhịp làm việc của dự án.
Lỗi 5 — Nhầm lẫn với Quantitative Analysis. Cố gán con số tiền chính xác ở bước này là sai phạm vi. Mẹo: Ở bước định tính, chỉ cần trả lời "cao/thấp"; con số cụ thể để dành cho Bài 23.
Lỗi 6 — Bỏ qua rủi ro tích cực (opportunities). Rủi ro không chỉ là chuyện xấu; cơ hội cũng cần được phân tích và ưu tiên. Mẹo: Dùng cùng ma trận cho các cơ hội, ưu tiên khai thác những cơ hội có P×I cao.
Bài tập thực hành
Hãy tưởng tượng bạn là PM một dự án phát triển ứng dụng giao đồ ăn cho một startup ở Đà Nẵng, deadline ra mắt trước Tết. Bạn có 5 rủi ro sau:
- Nhà cung cấp bản đồ (map API) tăng giá đột ngột.
- Một trong hai lập trình viên chính có thể nghỉ việc (đã ngỏ ý).
- Máy chủ quá tải khi lượng đơn tăng vọt dịp Tết.
- Logo bị một số người dùng thử phản hồi là khó nhìn.
- Quy định mới về an toàn thực phẩm có thể yêu cầu thêm tính năng.
a) Tự định nghĩa bảng thang đo 5 mức Probability và 5 mức Impact (tiến độ + chi phí).
b) Gán điểm P và I cho từng rủi ro, tính Risk Score.
c) Đặt 5 rủi ro lên Probability × Impact Matrix và tô màu Đỏ/Vàng/Xanh.
d) Xếp hạng và chọn ra 2 rủi ro cần xử lý ưu tiên nhất, giải thích lý do (có xét thêm urgency).
Gợi ý: Chú ý rủi ro số 3 — impact rất cao vì rơi đúng cao điểm doanh thu; và rủi ro số 2 — vừa cao xác suất vừa cao ảnh hưởng. So sánh với rủi ro số 4 (impact thấp) để thấy sự khác biệt.
Tóm tắt
Qualitative Risk Analysis là bước biến một danh sách rủi ro hỗn độn thành một thứ tự ưu tiên rõ ràng, giúp đội ngũ tập trung năng lượng vào đúng chỗ. Ba điểm cần nhớ:
- Hai trục đánh giá là Probability và Impact, dùng thang mô tả (Rất thấp đến Rất cao) chứ không cần con số chính xác. Nhân hai điểm ra Risk Score và đặt lên ma trận màu Đỏ/Vàng/Xanh.
- Việc đầu tiên và quan trọng nhất là thống nhất định nghĩa thang đo trước khi chấm điểm — nếu không, "định tính" sẽ biến thành "cảm tính".
- Impact thường quyết định ưu tiên hơn Probability; và đừng quên xét thêm urgency cùng chất lượng dữ liệu. Đây là bước lặp lại định kỳ, không phải làm một lần rồi thôi.