Risk và Issue khác nhau thế nào? Cách nhận diện và xử lý đúng trong dự án

1. Risk và Issue khác nhau thế nào? Câu trả lời ngắn

Cách phân biệt thực dụng nhất là hỏi: “Việc này đã xảy ra chưa?” Nếu chưa xảy ra và còn bất định, đó thường là Risk. Nếu đã xảy ra hoặc tác động đã hiện hữu, đó là Issue.

Tuy nhiên, chỉ phân loại đúng tên gọi chưa đủ. Người quản lý dự án còn phải chuyển từ nhận diện sang hành động:

• Với Risk: phân tích xác suất, mức tác động, chủ sở hữu, trigger và chiến lược ứng phó.
• Với Issue: xác định mức độ khẩn cấp, nguyên nhân, người chịu trách nhiệm, phương án giải quyết, thời hạn và điểm cần escalation.

2. Risk là gì trong quản lý dự án?

Risk không đồng nghĩa với “điều xấu chắc chắn sẽ đến”. Risk tồn tại vì dự án luôn có mức độ bất định. Một nhà cung cấp có thể giao chậm; một chuyên gia chủ chốt có thể nghỉ việc; tỷ giá có thể biến động; nhưng cũng có thể xuất hiện cơ hội rút ngắn tiến độ hoặc giảm chi phí.

Một mô tả Risk tốt thường có ba thành phần:

• Nguyên nhân hoặc điều kiện: điều gì đang tạo ra bất định?
• Sự kiện không chắc chắn: điều gì có thể xảy ra?
• Tác động: nếu xảy ra, mục tiêu nào bị ảnh hưởng?

Risk được quản lý trước khi nó xảy ra. Công việc chính không phải dự đoán mọi thứ, mà là dành sự chú ý phù hợp cho những bất định quan trọng nhất. Để hiểu Risk trong bức tranh tổng thể của nghề quản lý dự án, bạn có thể đọc thêm bài PMBOK là gì?.

3. Issue là gì trong quản lý dự án?

Issue là vấn đề đã trở thành thực tế. Ví dụ: nhà cung cấp đã thông báo giao chậm 14 ngày; hệ thống đã thất bại trong kiểm thử bảo mật; thành viên chủ chốt đã nghỉ việc; khách hàng đã từ chối nghiệm thu.

Một Issue tốt cần được ghi rõ:

• vấn đề cụ thể là gì;
• tác động hiện tại và dự kiến;
• mức độ ưu tiên;
• người chịu trách nhiệm xử lý;
• hành động, thời hạn và trạng thái;
• quyết định hoặc hỗ trợ cần từ Sponsor/Steering Committee.

4. Bảng so sánh Risk và Issue

5. Ba ví dụ giúp phân biệt Risk và Issue

Ví dụ 1: Dự án phần mềm

Risk: API của đối tác có thể thay đổi trước ngày tích hợp. Issue: Đối tác đã phát hành phiên bản API mới và mã tích hợp hiện tại không còn hoạt động.

Ví dụ 2: Dự án xây dựng

Risk: Mưa lớn kéo dài có thể ảnh hưởng công tác nền móng. Issue: Công trường đã ngập và máy móc không thể hoạt động trong ba ngày.

Ví dụ 3: Dự án chuyển đổi số

Risk: Người dùng cuối có thể phản đối quy trình mới. Issue: Đại diện ba phòng ban đã từ chối tham gia UAT vì cho rằng quy trình mới làm tăng khối lượng công việc.

6. Quy trình 7 bước xử lý Risk và Issue

7. Risk Register khác Issue Log thế nào?

Risk Register là nơi quản lý các Risk đã nhận diện, phân tích, chỉ định Owner và lập response. Issue Log là nơi quản lý vấn đề đang tồn tại, quyết định xử lý và trạng thái giải quyết.

Trong dự án nhỏ, hai danh sách có thể nằm trong cùng một file, nhưng phải có trường phân loại rõ. Trong dự án lớn, nên tách riêng để tránh Issue khẩn cấp bị chìm trong hàng chục Risk chưa xảy ra.

8. Khi nào Risk trở thành Issue?

Risk trở thành Issue khi sự kiện không chắc chắn đã xảy ra hoặc tác động của nó đã bắt đầu xuất hiện. Khi đó, Project Manager cần:

1. cập nhật Risk là “triggered” hoặc “occurred”;
2. tạo Issue tương ứng và liên kết ID;
3. kích hoạt contingency plan nếu đã chuẩn bị;
4. đánh giá secondary risks phát sinh từ phương án xử lý;
5. cập nhật kế hoạch, Project Baseline hoặc change request khi cần;
6. ghi nhận Lessons Learned để cải thiện phản ứng trong tương lai.

9. Những sai lầm thường gặp khi quản lý Risk và Issue

9.1. Gọi mọi vấn đề là Risk

Khi một nhà cung cấp đã giao chậm nhưng vẫn ghi “Risk giao chậm”, team dễ trì hoãn hành động và báo cáo không phản ánh thực tế.

9.2. Chỉ ghi danh sách mà không có Owner

Một mục không có Owner thực chất chưa được quản lý. “Team sẽ xử lý” không phải là phân công trách nhiệm.

9.3. Đánh giá Risk một lần rồi bỏ

Xác suất và tác động thay đổi theo thời gian. Risk cần được rà soát theo milestone, thay đổi lớn và tín hiệu mới.

9.4. Không phân biệt response với workaround

Response được chuẩn bị cho Risk; workaround thường là phản ứng chưa được lập kế hoạch khi Issue bất ngờ xuất hiện.

9.5. Escalate quá sớm hoặc quá muộn

Escalation không phải đẩy trách nhiệm lên trên. Nó là đưa quyết định đến đúng cấp có thẩm quyền khi Project Manager không thể tự giải quyết.

10. Risk và Issue trong câu hỏi tình huống PMP

Trong câu hỏi PMP, từ khóa thời gian rất quan trọng. Nếu tình huống nói “có thể”, “có khả năng”, “được dự báo”, “một dấu hiệu cho thấy”, bạn đang đứng trước Risk. Nếu tình huống nói “đã xảy ra”, “vừa phát hiện”, “đang ảnh hưởng”, “đã bỏ lỡ”, đó thường là Issue.

Tư duy xử lý nên theo trình tự:

• đánh giá tình huống và tác động trước khi hành động vội;
• kiểm tra kế hoạch, register/log và response đã thống nhất;
• làm việc với team và Owner phù hợp;
• thực hiện response hoặc resolution;
• escalate khi vượt thẩm quyền;
• cập nhật tài liệu dự án và truyền thông với stakeholder.

11. Cách Project Manager tổ chức cuộc họp Risk và Issue hiệu quả

Không cần cuộc họp dài. Một nhịp rà soát 20–30 phút có thể theo cấu trúc:

1. Top 5 Risk theo exposure và proximity;
2. Risk mới, Risk thay đổi và trigger mới;
3. Issue đang chặn milestone hoặc quyết định;
4. hành động quá hạn;
5. mục cần Sponsor/Steering Committee quyết định;
6. Risk/Issue có thể đóng;
7. bài học hoặc thay đổi cần đưa vào kế hoạch.

Đối với Risk cluster của VNPMI, bạn nên đọc tiếp bài RBS là gì?, Risk Register là gì? và bài tổng quan quản trị rủi ro trong quản lý dự án. Khi cần đối chiếu cách Risk được đặt trong cấu trúc các phiên bản mới, xem thêm so sánh PMBOK 7 và PMBOK 8.

12. Câu hỏi thường gặp

Về tác giả

Master Lê Quyết Thắng là CEO và giảng viên chính của VNPMI, hoạt động trong lĩnh vực quản lý dự án, phát triển năng lực quản lý và AI ứng dụng.

Trong quản lý dự án và đào tạo PMP, Master Lê Quyết Thắng tập trung giúp người học phân biệt đúng giữa rủi ro chưa xảy ra và vấn đề đã phát sinh, thay vì chỉ ghi chép thuật ngữ vào biểu mẫu. Với chủ đề Risk và Issue, trọng tâm chuyên môn là kết nối từng sự kiện với Owner, thời điểm phản ứng, thẩm quyền quyết định và hành động cụ thể. Cách tiếp cận này giúp Project Manager chủ động chuẩn bị phương án cho bất định, đồng thời xử lý nhanh những vấn đề đang ảnh hưởng đến mục tiêu dự án.

Triết lý chuyên môn: “Không học để biết nhiều hơn. Học để suy nghĩ tốt hơn, quyết định đúng hơn và làm việc hiệu quả hơn.”

Xem thêm hồ sơ chuyên gia: Master Lê Quyết Thắng