Mở đầu — vì sao bài này quan trọng
Hãy hình dung bạn là PM cho một dự án xây dựng phần mềm quản lý kho cho một chuỗi bán lẻ ở TP.HCM. Deadline go-live đã chốt với ban giám đốc, ngân sách đã duyệt, team đã ngồi vào bàn. Ba tháng sau, dự án trễ sáu tuần vì lập trình viên chủ chốt nghỉ việc giữa chừng, và không ai từng nghĩ tới khả năng đó. Đây không phải xui rủi — đây là một rủi ro hoàn toàn có thể nhìn thấy trước, nếu ai đó chịu ngồi xuống và hỏi: "Điều gì có thể sai ở đây?"
Đó chính là tinh thần của Risk Identification — bước đầu tiên và quan trọng bậc nhất trong toàn bộ quy trình quản lý rủi ro. Nếu bạn không nhận diện được một rủi ro, bạn không thể phân tích nó, không thể lập kế hoạch ứng phó, và chắc chắn không thể kiểm soát nó. Mọi công cụ phân tích tinh vi ở các bài sau (định tính, định lượng, EMV, cây quyết định) đều vô nghĩa nếu danh sách rủi ro ban đầu của bạn nghèo nàn và thiếu sót.
Trong bài này, chúng ta chỉ tập trung vào một việc: làm sao để phát hiện và ghi nhận rủi ro một cách có hệ thống, đầy đủ, ngay từ sớm. Đây là kỹ năng phân biệt một PM "chữa cháy" cả đời với một PM chủ động dẫn dắt dự án. Người mới thường coi rủi ro là thứ "xảy ra rồi mới biết". Người chuyên nghiệp coi rủi ro là thứ được săn tìm có chủ đích, trước khi nó kịp gây hại.
Khái niệm cốt lõi
Risk là gì — Uncertainty đi kèm Impact
Định nghĩa chuẩn theo PMBOK: Risk là một sự kiện hoặc điều kiện bất định (uncertain), mà nếu xảy ra sẽ có tác động (impact) tới ít nhất một mục tiêu của dự án — thường là scope, schedule, cost, hoặc quality.
Hai từ khóa cần khắc cốt ghi tâm: bất định và tác động.
- Nếu một sự kiện chắc chắn xảy ra (100%), nó không phải rủi ro — nó là một sự thật, một ràng buộc (constraint), và bạn phải lập kế hoạch cho nó như một phần công việc bình thường. Ví dụ: "Tết Nguyên đán team sẽ nghỉ 9 ngày" — đó không phải rủi ro, đó là lịch nghỉ đã biết.
- Nếu một sự kiện bất định nhưng không có tác động gì tới mục tiêu, nó cũng không đáng gọi là rủi ro của dự án.
Risk có thể là Threat (tiêu cực) hoặc Opportunity (tích cực)
Đây là điểm nhiều học viên hiểu sai. Trong tư duy PM chuyên nghiệp, rủi ro không đồng nghĩa với "điều xấu". Rủi ro có hai chiều:
- Threat (mối đe dọa) — rủi ro tiêu cực, nếu xảy ra sẽ gây hại: chậm tiến độ, vượt ngân sách, giảm chất lượng. Ví dụ: "Nhà cung cấp API thanh toán có thể trễ hạn tích hợp."
- Opportunity (cơ hội) — rủi ro tích cực, nếu xảy ra sẽ mang lại lợi ích: hoàn thành sớm, tiết kiệm chi phí, tăng giá trị. Ví dụ: "Nếu team áp dụng được thư viện mã nguồn mở mới, có thể rút ngắn 2 tuần phát triển."
Nguồn gốc của rủi ro — Internal vs External
Để nhận diện đầy đủ, bạn cần biết rủi ro thường "trốn" ở đâu. Phân loại theo nguồn gốc là cách rà soát hiệu quả nhất.
Rủi ro nội tại (Internal) — nằm trong tầm kiểm soát hoặc ảnh hưởng của tổ chức/dự án:
- Con người & kỹ năng: thành viên chủ chốt nghỉ việc, team thiếu kỹ năng cho công nghệ mới, nhân sự bị chia sẻ giữa nhiều dự án (over-allocation).
- Kỹ thuật: kiến trúc chưa được kiểm chứng, nợ kỹ thuật, tích hợp phức tạp giữa các hệ thống cũ.
- Quy trình & quản lý: yêu cầu (requirement) mơ hồ, scope creep, ước lượng quá lạc quan, thiếu quy trình kiểm thử.
- Nhà cung cấp/đối tác: vendor giao hàng trễ, chất lượng API bên thứ ba không ổn định.
- Thị trường & khách hàng: khách hàng thay đổi ưu tiên, đối thủ ra sản phẩm cạnh tranh.
- Pháp lý & môi trường: quy định mới (ví dụ Nghị định về bảo vệ dữ liệu cá nhân), biến động tỷ giá USD/VND với dự án outsourcing, thiên tai, dịch bệnh.
Các kỹ thuật nhận diện rủi ro
PMBOK liệt kê nhiều kỹ thuật, dưới đây là những cái bạn sẽ dùng thường xuyên nhất:
- Brainstorming: họp team, đưa ra càng nhiều rủi ro càng tốt, chưa vội phán xét. Nhanh, dễ, nhưng dễ bị chi phối bởi người nói to nhất.
- Checklist Analysis: dựa trên danh sách rủi ro chuẩn từ các dự án trước hoặc từ ngành. Rất hiệu quả với dự án lặp lại, nhưng rủi ro là bỏ sót cái ngoài checklist.
- Interviews (phỏng vấn chuyên gia): hỏi riêng các chuyên gia, stakeholder giàu kinh nghiệm — họ thường biết những "cái bẫy" mà tài liệu không ghi.
- Delphi Technique: thu thập ý kiến chuyên gia ẩn danh qua nhiều vòng để tránh hiệu ứng đám đông và tránh người có chức vụ áp đảo.
- SWOT Analysis: phân tích Strengths–Weaknesses (nội tại) và Opportunities–Threats (bên ngoài) — đặc biệt tốt vì nó ép bạn nghĩ cả về opportunity.
- Root Cause Analysis & Assumption Analysis: soi các giả định (assumption) của dự án. Mỗi giả định là một rủi ro tiềm ẩn — nếu giả định sai thì sao?
- Document Review: rà kế hoạch, hợp đồng, Project Charter, lessons learned từ dự án cũ.
Sản phẩm đầu ra — Risk Register
Kết quả của quá trình identification là Risk Register (Sổ đăng ký rủi ro) — tài liệu sống, được cập nhật suốt vòng đời dự án. Ở bước này, mỗi rủi ro tối thiểu cần: ID, mô tả rủi ro, nguồn gốc/danh mục, loại (threat/opportunity), và người phụ trách (risk owner). Các cột như xác suất, mức tác động, điểm ưu tiên sẽ được điền ở bước phân tích (Bài 22, 23).
Một mẹo viết mô tả rủi ro chuẩn là dùng cấu trúc nhân–quả: "Do [nguyên nhân], có thể xảy ra [sự kiện bất định], dẫn đến [tác động lên mục tiêu]." Ví dụ: "Do lập trình viên senior đang bị chia cho 2 dự án, có thể module thanh toán không kịp code trong sprint 4, dẫn đến trễ go-live 2 tuần." Cách viết này biến một rủi ro mơ hồ thành một mệnh đề rõ ràng, có thể hành động.
Tình huống thực tế
Ví dụ 1 — Dự án e-commerce của một startup bán lẻ tại Hà Nội
Một startup thương mại điện tử (gọi là ShopViet) triển khai website bán hàng mới, deadline 4 tháng, ngân sách 1,2 tỷ đồng. PM tổ chức một buổi brainstorming risk identification kéo dài 2 giờ với dev, designer, và đại diện marketing. Team liệt kê được 23 rủi ro, trong đó có ba rủi ro sau này chứng minh là then chốt:
- (Internal) "Do team chưa từng làm tích hợp cổng thanh toán, việc kết nối VNPay/Momo có thể mất gấp đôi thời gian ước lượng."
- (External) "Do phụ thuộc vào nhà cung cấp hosting, nếu server không chịu được tải ngày khai trương, website có thể sập."
- (Opportunity) "Nếu tận dụng được template có sẵn của nền tảng, có thể tiết kiệm 3 tuần thiết kế giao diện."
Bài học: Risk identification không chỉ để phòng thủ. Khi bạn nhìn thấy cả threat lẫn opportunity, bạn có thể điều phối nguồn lực thông minh hơn nhiều so với việc chỉ chạy theo deadline.
Ví dụ 2 — Dự án outsourcing của một công ty phần mềm Đà Nẵng cho khách Nhật
Một công ty outsourcing (gọi là TechDN) nhận dự án phát triển ứng dụng cho khách hàng Nhật Bản, giá trị hợp đồng khoảng 400.000 USD, kéo dài 8 tháng. PM ban đầu chỉ brainstorming nội bộ với team dev. Danh sách rủi ro chủ yếu xoay quanh kỹ thuật. Kết quả: đến tháng thứ 3, dự án gặp khủng hoảng vì hai rủi ro không hề xuất hiện trong register:
- Rào cản ngôn ngữ/văn hóa: các cuộc họp bằng tiếng Nhật khiến team hiểu sai yêu cầu, phải làm lại nhiều lần.
- Biến động tỷ giá JPY/VND làm lợi nhuận thực tế của hợp đồng cố định bằng JPY sụt giảm đáng kể.
Diễn giải: Rủi ro nguy hiểm nhất thường không phải rủi ro kỹ thuật — mà là rủi ro nằm ngoài "vùng nhìn" của người nhận diện. Một buổi brainstorming chỉ gồm dev sẽ chỉ tìm ra rủi ro của dev.
Bài học: Đa dạng góc nhìn khi identification là vũ khí chống điểm mù. Luôn kéo stakeholder từ nhiều lĩnh vực — tài chính, kinh doanh, pháp lý, khách hàng — vào cuộc chơi nhận diện rủi ro.
Ví dụ 3 — Dự án chuyển đổi số của một chuỗi nhà hàng
Một chuỗi nhà hàng (gọi là FoodChain) triển khai hệ thống POS mới cho 30 chi nhánh. PM áp dụng Checklist Analysis dựa trên lessons learned từ một dự án rollout trước đó của công ty. Checklist giúp họ bắt ngay được rủi ro "nhân viên chi nhánh chống đối công nghệ mới, cần đào tạo và change management" — một rủi ro mà nếu chỉ brainstorming thuần kỹ thuật, dễ bị bỏ qua.
Tuy nhiên, checklist cũng có mặt trái: team quá tin vào nó và bỏ qua một rủi ro mới hoàn toàn — quy định mới về hóa đơn điện tử của cơ quan thuế thay đổi giữa dự án, buộc phải điều chỉnh hệ thống. Rủi ro pháp lý này không có trong checklist cũ vì thời điểm dự án trước chưa có quy định đó.
Diễn giải: Checklist là công cụ tuyệt vời để không quên bài học cũ, nhưng nó nhìn về quá khứ. Rủi ro mới, rủi ro của bối cảnh hiện tại, cần các kỹ thuật hướng tương lai như PESTLE hoặc assumption analysis bổ sung.
Bài học: Đừng bao giờ dựa vào một kỹ thuật duy nhất. Kết hợp checklist (kinh nghiệm quá khứ) với brainstorming/PESTLE (bối cảnh hiện tại) để phủ được cả hai chiều thời gian.
Hướng dẫn từng bước
Đây là quy trình thực hành để chạy một buổi risk identification hiệu quả:
- Chuẩn bị đầu vào: Thu thập Project Charter, danh sách stakeholder, WBS, kế hoạch tiến độ và ngân sách sơ bộ, hợp đồng, và đặc biệt là lessons learned/risk register của các dự án tương tự đã qua.
- Chọn và mời đúng người: Không chỉ team kỹ thuật. Mời đại diện từ các bên liên quan chính — khách hàng, kinh doanh, tài chính, vận hành, và một chuyên gia có kinh nghiệm với loại dự án này. Đa dạng góc nhìn chống điểm mù.
- Chọn tổ hợp kỹ thuật: Thông thường bắt đầu bằng brainstorming để mở, sau đó dùng checklist để soát lại các danh mục hay bị quên, và assumption analysis để soi các giả định. Với dự án lớn, thêm interview/Delphi cho các mảng chuyên sâu.
- Quét theo danh mục (RBS/PESTLE): Đi lần lượt từng nhóm — con người, kỹ thuật, quy trình, nhà cung cấp, thị trường, pháp lý, môi trường. Ép mình hỏi ở mỗi nhóm: "Điều gì có thể sai? Điều gì có thể tốt hơn?" Cách quét có cấu trúc này bắt được nhiều rủi ro hơn là brainstorming tự do.
- Viết mô tả chuẩn: Với mỗi rủi ro, dùng cấu trúc "Do [nguyên nhân] → có thể [sự kiện] → dẫn đến [tác động]". Ghi rõ loại (threat/opportunity) và danh mục nguồn gốc.
- Gán risk owner: Mỗi rủi ro cần một người chịu trách nhiệm theo dõi. Rủi ro không có chủ là rủi ro bị bỏ rơi.
- Ghi vào Risk Register: Nhập tất cả vào sổ với ID, mô tả, loại, danh mục, owner. Chưa cần đánh giá xác suất/tác động ở bước này — đó là việc của bài phân tích tiếp theo.
- Lên lịch rà soát định kỳ: Identification không phải việc làm một lần. Đặt lịch review register mỗi sprint hoặc mỗi cột mốc, vì rủi ro mới xuất hiện suốt vòng đời dự án.
Lỗi thường gặp & mẹo
Lỗi 1 — Coi identification là việc làm một lần rồi thôi. Nhiều PM họp một buổi đầu dự án, ra register, rồi cất tủ. Rủi ro là thứ động: rủi ro cũ biến mất, rủi ro mới xuất hiện. Mẹo: đưa "risk review" thành mục cố định trong họp định kỳ.
Lỗi 2 — Chỉ nhận diện threat, quên opportunity. Tư duy phòng thủ khiến bạn bỏ lỡ cách tăng giá trị dự án. Mẹo: với mỗi vòng brainstorming, dành riêng 15 phút chỉ để hỏi "điều gì có thể tốt hơn dự kiến?"
Lỗi 3 — Mô tả rủi ro quá mơ hồ. Viết "rủi ro về nhân sự" thì không ai làm gì được với nó. Mẹo: luôn dùng cấu trúc nguyên nhân → sự kiện → tác động để rủi ro trở nên cụ thể và có thể hành động.
Lỗi 4 — Nhầm lẫn rủi ro với nguyên nhân hoặc với tác động. "Team thiếu kinh nghiệm" là nguyên nhân, "trễ dự án" là tác động — bản thân chúng chưa phải rủi ro. Rủi ro là sự kiện bất định ở giữa. Mẹo: tách rạch ròi ba thành phần khi viết.
Lỗi 5 — Buổi họp bị một người áp đảo. Người có chức vụ cao nói, mọi người gật. Mẹo: dùng kỹ thuật ẩn danh (viết ra giấy/công cụ trước, đọc sau) hoặc Delphi để mọi tiếng nói được nghe.
Lỗi 6 — Đội hình nhận diện thiếu đa dạng. Chỉ dev thì chỉ ra rủi ro của dev. Mẹo: luôn mời ít nhất một người ngoài team lõi — khách hàng, tài chính, hoặc chuyên gia domain.
Mẹo vàng: Xây và duy trì một checklist rủi ro của riêng tổ chức dựa trên lessons learned tích lũy. Đây là tài sản trí tuệ quý giá — mỗi dự án đóng góp thêm, và PM mới thừa hưởng cả kho kinh nghiệm thay vì phải học lại từ đầu.
Bài tập thực hành
Bài tập 1 — Nhận diện có cấu trúc. Chọn một dự án bạn đang hoặc sắp làm (nếu chưa có, dùng tình huống giả định: "Xây app đặt lịch cắt tóc cho một chuỗi salon 10 chi nhánh, deadline 3 tháng"). Quét qua 6 danh mục: con người, kỹ thuật, quy trình, nhà cung cấp, thị trường, pháp lý. Với mỗi danh mục, viết ít nhất 2 rủi ro theo cấu trúc "Do... → có thể... → dẫn đến...". Mục tiêu: tối thiểu 12 rủi ro.
Bài tập 2 — Săn opportunity. Từ dự án ở bài 1, cố tìm ra ít nhất 3 rủi ro tích cực (opportunity). Ép mình trả lời: nếu điều gì đó diễn ra tốt hơn dự kiến, dự án có thể hưởng lợi ra sao?
Bài tập 3 — Phân biệt. Cho danh sách sau, hãy đánh dấu đâu là nguyên nhân, đâu là rủi ro, đâu là tác động: (a) "Vượt ngân sách 20%"; (b) "Nhà cung cấp API có thể ngừng dịch vụ giữa dự án"; (c) "Yêu cầu chưa được khách hàng chốt rõ"; (d) "Team phải làm lại toàn bộ module". Sau đó viết lại (b) thành một mệnh đề rủi ro hoàn chỉnh gồm cả nguyên nhân và tác động.
Bài tập 4 — Lập Risk Register mini. Lấy 5 rủi ro quan trọng nhất từ bài 1, đưa vào bảng gồm các cột: ID, Mô tả, Loại (Threat/Opportunity), Danh mục nguồn gốc, Risk Owner. Đây sẽ là đầu vào cho bài phân tích rủi ro tiếp theo.
Tóm tắt
Risk Identification là bước nền móng của quản lý rủi ro: không nhận diện được thì không thể quản lý. Rủi ro là sự kiện bất định có tác động tới mục tiêu dự án, và nó có hai chiều — threat (đe dọa) và opportunity (cơ hội). PM chuyên nghiệp săn tìm cả hai một cách chủ động, không đợi đến khi sự cố xảy ra.
Để nhận diện đầy đủ, hãy quét rủi ro theo nguồn gốc — internal (con người, kỹ thuật, quy trình) và external (nhà cung cấp, thị trường, pháp lý, môi trường) — bằng tổ hợp nhiều kỹ thuật: brainstorming, checklist, interview, Delphi, SWOT, assumption analysis. Không dựa vào một kỹ thuật duy nhất và không để đội hình nhận diện thiếu đa dạng góc nhìn, vì rủi ro nguy hiểm nhất thường nằm ở điểm mù.
Sản phẩm cuối là Risk Register — tài liệu sống, mỗi rủi ro viết theo cấu trúc nguyên nhân → sự kiện → tác động, có phân loại và có chủ sở hữu. Và nhớ: identification không phải việc làm một lần. Rủi ro xuất hiện suốt vòng đời dự án, nên hãy rà soát định kỳ. Khi bạn đã có một register vững chắc, bạn đã sẵn sàng cho bước tiếp theo — phân tích định tính để xếp thứ tự ưu tiên các rủi ro này.