Mở đầu — vì sao bài này quan trọng
Trong hầu hết các dự án mà tôi từng đồng hành cùng học viên, có một cuộc tranh cãi lặp đi lặp lại trong phòng họp: "Cái này là risk hay là issue?" Nghe thì có vẻ chỉ là chuyện chữ nghĩa, nhưng cách bạn phân loại một vấn đề sẽ quyết định bạn xử lý nó ở đâu, bằng công cụ nào, do ai chịu trách nhiệm và với mức độ khẩn cấp ra sao.
Nhầm lẫn giữa Risk và Issue là một trong những lỗi kinh điển của PM mới. Có người ghi tất tần tật mọi thứ vào Risk Register, kể cả những việc đang cháy nhà. Có người thì ngược lại, coi mọi lo lắng mơ hồ về tương lai là "issue" và đưa lên báo cáo tuần khiến sếp hoảng loạn không cần thiết. Cả hai kiểu đều làm loãng khả năng ra quyết định của cả team.
Ở các bài trước trong khóa học này, bạn đã học khá kỹ về Risk Management — từ nhận diện (Bài 21), phân tích định tính (Bài 22), định lượng (Bài 23) đến lập kế hoạch ứng phó (Bài 24). Bài này KHÔNG lặp lại các kỹ thuật đó. Thay vào đó, chúng ta tập trung vào một ranh giới rất cụ thể mà nhiều tài liệu bỏ qua: sự khác biệt bản chất giữa Issue và Risk, cơ chế "chuyển hóa" từ risk thành issue, và cách vận hành hai công cụ song song là Risk Register và Issue Log sao cho không giẫm chân nhau. Nắm chắc ranh giới này, bạn sẽ điều hành cuộc họp status gọn gàng hơn và ra quyết định nhanh hơn hẳn.
Khái niệm cốt lõi
Risk — điều CHƯA xảy ra
Risk (rủi ro) là một sự kiện hoặc điều kiện KHÔNG chắc chắn, nếu xảy ra sẽ tác động (tích cực hoặc tiêu cực) đến mục tiêu dự án. Đặc trưng cốt lõi của risk:
- Chưa xảy ra — nó nằm ở thì tương lai.
- Xác suất < 100% — luôn có khả năng nó không bao giờ thành hiện thực.
- Có thể chủ động phòng ngừa — vì còn thời gian, bạn có thể lên kế hoạch giảm xác suất hoặc giảm tác động.
Issue — điều ĐANG xảy ra
Issue (vấn đề) là một sự kiện hoặc điều kiện ĐÃ xảy ra hoặc ĐANG diễn ra, đang gây tác động thực tế lên dự án và cần được giải quyết. Đặc trưng cốt lõi:
- Đã/đang xảy ra — nó nằm ở thì hiện tại.
- Độ chắc chắn 100% — không còn là "nếu", nó là sự thật.
- Cần phản ứng (react) — không phải phòng ngừa, mà là khắc phục hậu quả và giải quyết.
Ranh giới then chốt: xác suất
Nếu phải chọn MỘT tiêu chí duy nhất để phân biệt, đó là xác suất. Risk có xác suất trong khoảng lớn hơn 0% và nhỏ hơn 100%. Issue có xác suất bằng 100% — nó đã thành sự thật. Khi một risk "hiện thực hóa" (xác suất chạm 100%), nó không còn là risk nữa; nó trở thành issue. Khoảnh khắc chuyển hóa này gọi là risk becoming an issue hoặc risk trigger fired.
Hãy nhớ hình ảnh này: Risk là đám mây đen trên bầu trời — có thể mưa, có thể không. Issue là khi mưa đã rơi và sàn nhà đang ướt. Với đám mây, bạn chuẩn bị áo mưa (phòng ngừa). Với sàn ướt, bạn lấy giẻ lau ngay (khắc phục).
Bảng so sánh nhanh
| Tiêu chí | Risk | Issue |
|---|---|---|
| Thời điểm | Tương lai | Hiện tại/quá khứ |
| Xác suất | > 0% và < 100% | 100% |
| Hành động | Proactive (phòng ngừa) | Reactive (khắc phục) |
| Công cụ quản lý | Risk Register | Issue Log |
| Chủ thể | Risk Owner | Issue Owner / Assignee |
| Chỉ số | Probability × Impact | Priority × Severity |
| Câu hỏi trọng tâm | "Nếu nó xảy ra thì sao?" | "Nó đang xảy ra, giờ làm gì?" |
Hai công cụ song song: Risk Register và Issue Log
Đây là chỗ nhiều PM lúng túng. Bạn cần vận hành đồng thời hai sổ:
Risk Register ghi các risk kèm probability, impact, risk score, response strategy (avoid/mitigate/transfer/accept), risk owner và trigger. Nó nhìn về phía trước.
Issue Log ghi các issue kèm mô tả, mức độ nghiêm trọng (severity), độ ưu tiên (priority), người được giao (assignee), ngày phát hiện, ngày mục tiêu đóng và trạng thái (open/in-progress/resolved/closed). Nó xử lý hiện tại.
Điểm nối quan trọng: khi một risk trong Risk Register hiện thực hóa, bạn KHÔNG xóa nó khỏi register một cách vô danh. Bạn đánh dấu risk đó là "occurred/materialized", kích hoạt contingency plan đã chuẩn bị (nếu có), và tạo một entry mới trong Issue Log tham chiếu ngược về risk ID gốc. Cách làm này giúp bạn về sau đo được: có bao nhiêu % issue của dự án đến từ risk đã lường trước, bao nhiêu % là issue bất ngờ hoàn toàn — một chỉ số cực kỳ giá trị để đánh giá chất lượng công tác risk management.
Escalation — khi issue vượt tầm PM
Không phải issue nào PM cũng tự giải quyết được. Mỗi issue nên có một ngưỡng escalation: nếu không đóng được trong X ngày, hoặc tác động vượt quá ngưỡng ngân sách/lịch nhất định, issue phải được đẩy lên Steering Committee hoặc sponsor. Đây là lý do Issue Log cần cột "escalation level". Chúng ta sẽ không đi sâu vào governance ở đây (đó là Bài 52), nhưng bạn cần hiểu escalation là một phần không thể thiếu của issue management.
Tình huống thực tế
Tình huống 1 — Dự án e-commerce của một startup TP.HCM
Một startup bán lẻ mỹ phẩm ở TP.HCM triển khai website bán hàng mới cho mùa cao điểm cuối năm, hạn go-live là 15/11 để kịp chiến dịch 11/11 và Black Friday.
Trong giai đoạn planning, PM ghi vào Risk Register: "R-07: Nếu lượng truy cập ngày sale vượt 3 lần dự kiến, hệ thống có thể sập do hạ tầng chưa được load test. Probability: Trung bình. Impact: Cao. Response: Mitigate — thuê thêm auto-scaling trên cloud và chạy load test trước 5/11. Risk owner: Tech Lead."
Đây là một risk đúng nghĩa: chưa xảy ra, xác suất chưa chắc chắn, còn thời gian phòng ngừa.
Nhưng đến ngày 10/11, đội dev báo rằng việc tích hợp cổng thanh toán VNPay bị lỗi callback, đơn hàng thanh toán thành công nhưng hệ thống không ghi nhận. Việc này đang xảy ra, khách thật đã bị trừ tiền mà không có đơn. Đây là issue — không phải risk. PM lập tức tạo "I-12: Lỗi callback VNPay khiến đơn thanh toán thành công không được ghi nhận. Severity: Critical. Assignee: Backend Lead. Target close: 12/11. Escalation: nếu chưa xong 12/11, đẩy lên sponsor để cân nhắc lùi campaign."
Bài học rút ra: Cùng một dự án, cùng một khoảng thời gian, nhưng risk và issue tồn tại song song và được xử lý ở hai nơi khác nhau. R-07 vẫn nằm trong Risk Register chờ ngày sale để nghiệm chứng; I-12 đã ở Issue Log và đang được xử lý gấp. PM nhầm hai loại này sẽ hoặc coi nhẹ I-12 (đưa nhầm vào risk và để "theo dõi"), hoặc làm loạn Issue Log bằng những lo lắng tương lai chưa thành sự thật.
Tình huống 2 — Khi risk hiện thực hóa thành issue tại một công ty outsourcing
Một công ty phần mềm outsourcing tại Đà Nẵng nhận dự án cho khách hàng Nhật, đội có 12 người. Ngay từ đầu, PM nhận diện risk: "R-03: Nếu chuyên gia domain duy nhất (anh Minh, người hiểu nghiệp vụ bảo hiểm của khách) nghỉ việc, tiến độ phân tích yêu cầu sẽ bị ảnh hưởng nặng. Probability: Thấp. Impact: Rất cao. Response: Mitigate — yêu cầu anh Minh viết tài liệu domain và pair với một BA thứ hai. Trigger: anh Minh nộp đơn xin nghỉ hoặc xin nghỉ phép dài ngày. Risk owner: PM."
Ba tháng sau, trigger nổ: anh Minh nộp đơn nghỉ việc, báo trước 30 ngày. Ngay khoảnh khắc đó, R-03 chuyển hóa thành issue. PM làm đúng quy trình:
- Đánh dấu R-03 trong Risk Register là Materialized ngày phát sinh.
- Kích hoạt contingency đã chuẩn bị — may thay, việc pair với BA thứ hai và tài liệu domain đã hoàn thành 70%.
- Tạo "I-08: Chuyên gia domain nghỉ việc, còn 30 ngày để chuyển giao. Severity: High. Assignee: PM + BA2. Target: hoàn tất chuyển giao trong 25 ngày."
Bài học rút ra: Đây là minh họa hoàn hảo cho vòng đời "risk trở thành issue". Chính vì risk được quản lý tốt từ trước, khi nó thành issue thì thiệt hại nhỏ đi rất nhiều. Nếu PM chỉ ghi risk vào register rồi để đó không làm gì (register kiểu "trang trí"), thì lúc issue nổ ra sẽ trở tay không kịp. Risk management tốt được đo lường chính xác nhất ở khoảnh khắc issue xảy ra.
Tình huống 3 — Nhầm lẫn khiến báo cáo mất giá trị
Một PM tại dự án chuyển đổi ERP của một doanh nghiệp sản xuất ở Bình Dương có thói quen gộp tất cả vào một danh sách "Risks & Issues" duy nhất trên Excel. Trong cuộc họp Steering Committee, danh sách này có 40 dòng: từ "có thể thiếu nhân sự tester vào tháng sau" (risk) lẫn với "server staging đang down từ sáng nay" (issue) đến "lo ngại người dùng phản đối hệ thống mới" (mơ hồ, không rõ risk hay issue).
Hậu quả: Steering Committee không biết đâu là việc cần quyết ngay, đâu là việc theo dõi. Cuộc họp 90 phút mà không ra được quyết định nào rõ ràng. Sponsor bực bội vì "báo cáo dài mà không hành động được".
Sau khi được cố vấn, PM tách làm hai: Risk Register 25 dòng (đưa vào phần "cần chú ý và theo dõi") và Issue Log 15 dòng (đưa vào phần "cần quyết định và hành động ngay"). Cuộc họp sau đó, Steering chỉ tập trung 20 phút vào 3 issue Critical đang mở, quyết được ngay hướng xử lý.
Bài học rút ra: Phân loại đúng không phải để làm màu tài liệu — nó trực tiếp cải thiện chất lượng ra quyết định của cấp trên và tiết kiệm thời gian họp. Trộn lẫn risk và issue là cách nhanh nhất khiến báo cáo của bạn bị coi là "ồn ào, thiếu tập trung".
Hướng dẫn từng bước
Khi một vấn đề xuất hiện trong dự án, hãy chạy quy trình phân loại và xử lý sau:
Bước 1 — Đặt câu hỏi vàng: "Nó đã xảy ra chưa?" Nếu câu trả lời là "chưa, nhưng có thể" → đó là risk, đưa vào Risk Register. Nếu câu trả lời là "rồi, đang diễn ra" → đó là issue, đưa vào Issue Log. Đây là bộ lọc đầu tiên và quan trọng nhất.
Bước 2 — Với risk: định lượng và lên kế hoạch ứng phó. Gán probability, impact, tính risk score, chọn chiến lược (avoid/mitigate/transfer/accept), chỉ định risk owner và — cực kỳ quan trọng — xác định trigger: dấu hiệu nào cho biết risk sắp/đang hiện thực hóa. (Chi tiết kỹ thuật xem lại Bài 21-24.)
Bước 3 — Với issue: đánh giá severity, gán assignee, đặt deadline. Ghi rõ mô tả sự thật (không phải "nếu"), gán mức độ nghiêm trọng (Critical/High/Medium/Low), người chịu trách nhiệm giải quyết, ngày mục tiêu đóng, và ngưỡng escalation.
Bước 4 — Theo dõi trigger của risk. Trong mỗi cuộc họp status, rà lại các trigger. Nếu một trigger đã nổ, đừng ngần ngại: kích hoạt cơ chế chuyển hóa ở Bước 5.
Bước 5 — Chuyển hóa risk → issue khi trigger nổ. Đánh dấu risk là "Materialized", kích hoạt contingency plan (nếu có), tạo issue mới trong Issue Log có tham chiếu ngược risk ID. Đừng để risk "biến mất" một cách vô danh.
Bước 6 — Đóng issue và ghi nhận. Khi issue được giải quyết, chuyển trạng thái sang Resolved rồi Closed, ghi lại cách giải quyết. Những issue đã đóng là nguyên liệu quý cho Lessons Learned (Bài 37) và Retrospective (Bài 43).
Bước 7 — Báo cáo tách bạch. Trong status report và họp Steering, luôn để Risk và Issue ở hai mục riêng: Risk là "theo dõi & phòng ngừa", Issue là "quyết định & hành động".
Lỗi thường gặp & mẹo
Lỗi 1 — Gộp chung Risk và Issue vào một danh sách. Như tình huống 3 đã cho thấy, việc này phá hủy khả năng ra quyết định. Luôn giữ hai công cụ riêng biệt, dù chỉ là hai sheet Excel khác nhau.
Lỗi 2 — Ghi issue bằng ngôn ngữ điều kiện "nếu". Nếu bạn viết một dòng trong Issue Log mà có chữ "nếu... thì...", 90% khả năng đó thực ra là risk bị đặt nhầm chỗ. Issue phải mô tả sự thật hiện tại.
Lỗi 3 — Risk Register kiểu "trang trí". Ghi risk rồi để đó, không có trigger, không ai theo dõi. Khi risk nổ, bạn không có contingency và trở tay không kịp. Mẹo: mỗi risk quan trọng phải có trigger cụ thể và người chịu trách nhiệm theo dõi trigger đó.
Lỗi 4 — Không có ngưỡng escalation cho issue. Issue bị assignee "ôm" mãi không giải quyết được mà không ai biết để can thiệp. Mẹo: mỗi issue Critical/High phải có SLA — bao nhiêu ngày không đóng thì tự động escalate.
Lỗi 5 — Nhầm issue với "task thường ngày". Không phải mọi việc cần làm đều là issue. Issue là vấn đề ngoài kế hoạch, đang gây cản trở. Việc trong kế hoạch bình thường thuộc về task/backlog, không nên làm phình Issue Log.
Mẹo vàng: Trong mỗi cuộc họp tuần, dành riêng 5 phút cho câu hỏi "Có risk nào đã hoặc sắp trở thành issue tuần này không?". Câu hỏi đơn giản này giúp team không bị bất ngờ và giữ cho hai công cụ luôn được đồng bộ.
Bài tập thực hành
Bài 1 — Phân loại. Với mỗi phát biểu sau, xác định đó là Risk hay Issue và giải thích ngắn gọn:
- "Nhà thầu cung cấp server có thể giao trễ vào tháng sau."
- "Tester chính đã nghỉ ốm từ hôm qua, hai test case bị chặn."
- "Nếu tỷ giá USD tăng mạnh, chi phí license phần mềm sẽ vượt ngân sách."
- "Khách hàng vừa từ chối nghiệm thu giai đoạn 2 sáng nay."
- "Đội frontend có thể thiếu kinh nghiệm với framework mới được chọn."
Bài 2 — Chuyển hóa. Chọn một risk từ bài 1 (ví dụ số 1 hoặc số 5). Giả định trigger của nó vừa nổ. Hãy viết: (a) cách bạn đánh dấu risk trong register, (b) contingency bạn sẽ kích hoạt, (c) một entry Issue Log hoàn chỉnh gồm severity, assignee, target close và escalation.
Bài 3 — Thiết kế công cụ. Lấy một dự án bạn đang hoặc từng tham gia. Tạo hai bảng: một Risk Register (tối thiểu 5 risk, đầy đủ cột: ID, mô tả, probability, impact, response, owner, trigger) và một Issue Log (tối thiểu 3 issue, đầy đủ cột: ID, mô tả, severity, assignee, ngày phát hiện, target close, trạng thái, escalation level). So sánh: có risk nào trong register mà bạn dự đoán sẽ sớm thành issue không?
Tóm tắt
- Risk là điều CHƯA xảy ra (xác suất > 0% và < 100%), xử lý bằng cách phòng ngừa chủ động trong Risk Register. Issue là điều ĐÃ/ĐANG xảy ra (xác suất 100%), xử lý bằng cách khắc phục phản ứng trong Issue Log.
- Tiêu chí phân biệt cốt lõi là xác suất và thì thời gian: câu hỏi vàng là "Nó đã xảy ra chưa?".
- Khi trigger của một risk nổ, risk chuyển hóa thành issue. Hãy đánh dấu risk là "Materialized", kích hoạt contingency, và tạo issue mới tham chiếu ngược risk ID.
- Vận hành hai công cụ song song — Risk Register nhìn về tương lai, Issue Log xử lý hiện tại — và giữ chúng tách bạch trong mọi báo cáo.
- Mỗi issue cần severity, assignee, deadline và ngưỡng escalation. Đừng để issue "vô chủ" hay không có SLA.
- Phân loại đúng không phải chuyện chữ nghĩa — nó trực tiếp quyết định tốc độ và chất lượng ra quyết định của cả dự án.