Project Risks: Không Phải Sợ Rủi Ro - Mà Sợ Không Có Kế Hoạch Cho Rủi Ro
Planning cho dự án là điều tuyệt vời, planning cho những gì sai sót có thể xảy ra còn tuyệt vời hơn
Trong nhiều năm làm việc ở vị trí Project Manager, mình có cơ hội tiếp xúc và làm việc với rất nhiều người - từ các bạn nhân viên mới vào nghề, các bạn chuyên viên kỹ thuật, cho đến quản lý cấp trung, cấp cao và lãnh đạo doanh nghiệp.
Một điều mà mình nhận ra rất rõ đó là càng ở cấp độ cao, mọi người càng dành nhiều sự quan tâm đến việc quản lý rủi ro (risk management). Mình từng đặt câu hỏi cho họ và điều mình nhận được nhìn chung đều là không phải vì họ sợ đối mặt với rủi ro mà vì họ hiểu được sức nặng của những thứ có thể xảy ra.
Nếu ở cấp nhân viên, đa phần chỉ tập trung vào deadline, task và delivery cụ thể thì ở cấp quản lý, đặc biệt ở cấp chiến lược điều họ quan tâm sẽ là:
Điều gì có thể làm chậm toàn bộ kế hoạch?
Nếu một vendor thất bại, plan B sẽ là gì?
Làm sao để không lặp lại sai lầm cũ?
Lúc đó, Risk không còn là khái niệm lý thuyết mà trở thành công cụ tư duy giúp chúng ta đưa ra các phương án xử lý trong các tình huống thực tế. Bài viết này mình sẽ chia sẻ những kinh nghiệm thực tế và phương pháp quản trị rủi ro hiệu quả mà mình đã học được theo tiêu chuẩn của PMP®, không chỉ để bạn xử lý tình huống khi rủi ro xảy ra - mà quan trọng là nhìn thấy chúng trước cả khi người khác nhận ra.
Hiểu đúng về Risk trong Quản lý Dự án
Hãy tưởng tượng bạn đang lên kế hoạch tổ chức một buổi chạy với các thành viên trong công ty vào cuối tuần nhé, mọi thứ đã được chuẩn bị chu đáo từ giày, nước, đồng phục, route chạy. Nhưng có một yếu tố nằm ngoài tầm kiểm soát: đó là thời tiết, cụ thể hơn là trời mưa.
Bạn có thể chọn lờ đi dự báo thời tiết hoặc lên plan B cho trường hợp này. Rõ ràng rủi ro không phải điều xấu, đó là một phần tất yếu. Vấn đề không phải là có rủi ro hay không mà là bạn đã lường trước và chuẩn bị cho nó hay chưa.
Trong PMBOK định nghĩa rủi ro dự án như sau:
“An uncertain event or condition that, if it occurs, has a positive or negative effect on one or more project objectives.”
Tức là:
Không chắc chắn
Có thể ảnh hưởng đến mục tiêu dự án (project objectives) bao gồm time, cost, quality, scope và value.
Có thể là mối đe doạ (threat) hoặc cơ hội (opportunity).
Điều thú vị có thể thấy đó là không phải tất cả rủi ro đều là tiêu cực, có những rủi ro tích cực trong dự án.
Ví dụ, gần đây mình vừa làm buổi demo với client, sau buổi demo đó, client nhận ra có thể bỏ vài tính năng phức tạp, thay vào đó là giải pháp đơn giản hơn.
Vì thế, risk opportunity ở đây đó là giảm được độ phức tạp của hệ thống, rút ngắn timeline và tăng khả năng release đúng hạn. Do đó, không phải risk lúc nào cũng xấu đâu nhé, phải xem nó là threat hay opportunity đã.
Cấu trúc của một rủi ro
Theo một cấu trúc chuẩn từ PMP, một risk có thể được mô hình hoá như sau:
Nguyên nhân (Cause) → Sự kiện rủi ro (Risk Event) → Tác động đến mục tiêu (Impact)
Ví dụ:
Do thiếu tài liệu kỹ thuật chi tiết (cause), việc tích hợp API có thể bị trễ (event), dẫn đến kéo dài tiến độ project (impact).
Đó các bạn thấy rất đơn giản, chúng ta có thể định hình được risk dựa trên cấu trúc trên từ đó chúng ta cần quan tâm tới các tiêu chí sau:
Probability: tức là xác suất sẽ xảy ra risk, ví dụ như 70% cuối tuần này sẽ mưa.
Impact tức là mức độ ảnh hưởng, ví dụ như nếu trời mưa thì sự kiện chạy bộ của chúng ta sẽ bị huỷ.
Proximity tức là mức độ cấp bách, bao lâu thì rủi ro này có thể xảy ra.
Thường thì khi đánh giá risk mọi người đa phần chỉ dựa vào Probability và Impact là chính, thường bỏ qua Proximity, đây là yếu tố mà cá nhân mình thấy quan trọng vì nó quyết định có nên phản ứng sớm hay không.
Đánh giá và trực quan rủi ro bằng Risk Matrix
Trong thực tiễn, mình thường dùng Probability & Impact Matrix để phân loại rủi ro theo trục:
Probability hoặc Likelihood (Xác suất)
Impact (Mức độ ảnh hưởng)
Thường thì nên phân loại theo 5 cấp độ cho mỗi tiêu chí, từ đó sẽ vẽ ra Risk Appetite Line, hiểu là ngưỡng chịu đụng rủi ro của tổ chức. Những rủi ro nằm trên hoặc dưới đường này sẽ cần ưu tiên xử lý ngay (ví dụ mình vẽ đường ngay làn ranh của của màu vàng và cam) thì những risk bên dưới sẽ cần xử lý ngay còn phía trên có thể được chấp nhận hoặc giám sát.
Từ đó xây dựng nên Risk Register để quản lý toàn bộ các Risk trong dự án.
Thông thường sẽ nên quản lý theo dạng bảng để tiện theo dõi:
Risk Description: mô tả về risk
Impact Description: mô tả về khả năng ảnh hưởng như thế nào
Impact Level Score, Probability Level Score: các chỉ số đánh giá level như mình chia sẻ ở trên, hai chỉ số này nhân nhau sẽ có Risk Score
Planned Response: tức là phương án ứng phó với Risk, mình sẽ chia sẻ trong phần kế tiếp.
Owner: người chịu trách nhiệm phụ trách risk đó.
Các Risk Response được sử dụng để ứng phó với Risk
Sau khi chúng ta định nghĩa được các risk, điều quan trọng đó chính là lên kế hoạch response với risk đó khi nó xảy ra. Đây là điều cực kỳ quan trọng và hữu ích, nó sẽ giúp bạn không bị bất ngờ khi risk đó xảy ra, và luôn có phương án xử lý trong mọi tình huống. Một số chiến lược phổ biến:
Avoid
Loại bỏ nguyên nhân gây rủi ro hoặc điều chỉnh kế hoạch để rủi ro không còn tồn tại.
Ví dụ như bạn đang làm việc với một vendor mà thường xuyên chậm trễ giao hàng, ảnh hưởng đến các dự án trước của bạn → giải pháp chính là không hợp tác với họ ngay từ đầu và chọn một vendor uy tín hơn.
Mitigate
Giảm xác suất xảy ra hoặc tác động trong dự án.
Ví dụ trong dự án phần mềm, bạn lo ngại rằng API integrate có thể lỗi do thiếu tài liệu → nên bạn bắt buộc có buổi technical discussion giữa team và bên đối tác ngay từ đầu, đồng thời chuẩn bị sẵn bộ tài liệu kỹ thuật mẫu.
Transfer
Đưa trách nhiệm xử lý rủi ro cho bên thứ ba, thường bằng contract hoặc bảo hiểm.
Ví dụ bạn mua bảo hiểm hosting cloud để giảm rủi ro downtime của hệ thống khi có sự cố.
Accept
Đồng ý rằng rủi ro có thể xảy ra, nhưng không hành động trừ khi nó xảy ra, hoặc có kế hoạch ứng phó nếu nó xảy ra.
Ví dụ bạn biết việc deployment lên production có thể trễ 1-2 tiếng do thời gian kiểm thử kéo dài, nhưng team vẫn quyết định giữ kế hoạch như cũ và chuẩn bị plan B nếu phải rollback.
Risk Response cho Opportunities
Ngoài ra, đối với risk response thì sẽ có một số response như:
Exploit: thay đổi kế hoạch để đảm bảo rủi ro tích cực chắc chắn xảy ra.
Enhance: tăng cường xác suất hoặc tác động cơ hội.
Share: hợp tác với đối tác để cùng nhau nắm bắt cơ hội.
Accept: không chủ động hành động, nhưng sẵn sàng hưởng lợi nếu có cơ hội xảy ra.
Nhìn chung thì thường phần opportunities mọi người cũng sẽ ít define ra, nhưng cũng nên biết để hiểu rõ risk response cho Threat và Opportunities nhé. Dưới đây sẽ là chiến lược response cho hai loại.
Một số kinh nghiệm ứng dụng quản lý rủi ro thực tế
Trong quá trình áp dụng quản lý rủi ro thực tế, mình nhận thấy nhiều dự án thất bại không phải vì rủi ro quá lớn mà vì chúng không được nhìn thấy hoặc xử lý kịp thời, mình có một số kinh nghiệm muốn chia sẻ thực tế cho các bạn.
Bắt đầu lập Risk Register ngay từ giai đoạn Initiation
Ngay từ khi khởi tạo dự án định hình scope, stakeholder và budget thì các risk đều đã xuất hiện. Hãy tạo Risk Register và liệt kê các high-level risk như:
Thiếu cam kết từ stakeholder
Budget chưa rõ ràng
Scope chưa thống nhất
Tổ chức Risk Identification trong mỗi Sprint
Risk không cố định, nó có thể thay đổi theo từng giai đoạn, hãy biến việc nhận diện risk thành một phần của team. Có thể tổ chức Risk check-in vào cuối sprint planning, mình hay đặt câu hỏi cho team sau khi planning “Mọi người đánh giá thử có vấn đề nào có thể xảy ra làm chúng ta trễ sprint này không?” từ đó để cho mọi người chủ động input thông tin và bạn sẽ có thể cập nhật các risk và response cho nó.
Một chút thói quen nhỏ nhưng có thể tạo nên tác động lớn, nếu nhận định risk sớm thì giải pháp lại càng đơn giản.
Risk Owner không phải là Project Manager
Có một điều mọi người hay nhầm lẫn, risk owner không phải lúc nào cũng là Project Manager mà có thể là bất kỳ thành viên nào trong team, thậm chí external stakeholder. Việc gán Risk Owner là bắt buộc trong project vì người này sẽ:
Theo dõi diễn biến risk
Chủ động cập nhật trạng thái
Đề xuất giải pháp ứng phó
Vì thế hãy chọn người phù hợp chứ không phải người cao nhất.
Trực quan hoá risk để giúp stakeholder dễ ra quyết định
Thay vì chỉ gửi danh sách khô khan, mình nghĩ có thể sử dụng Risk matrix để hiển thị cấp độ rủi ro. Vẽ các biểu độ như Bubble Chart hay gắn Risk Appetite Line để thể hiện ngưỡng chịu đựng.
Và chia sẻ cho họ thấy các risk nào quan trọng để có phương án xử lý sớm nhất có thể.
Tích hợp cập nhật rủi ro vào báo cáo và họp định kỳ
Có một điều chúng ta tạo ra risk register xong sau đó lại bỏ quên nó, trong mỗi buổi họp status nên có mục nhỏ để review lại nó:
Có rủi ro nào mới phát sinh không?
Rủi ro nào cần update status
Có rủi ro nào đã thành issue hay không?
Chúng ta nên có cái nhìn real time về risk thay vì phát hiện khi mọi chuyện đã quá muộn.
Kết luận
Chắc chắn rằng dự án nào cũng có rủi ro dù lớn hay nhỏ, dù truyền thống hay agile nhưng đó không phải là điều lo lắng và sợ hãi. Thực tế, biết nhìn nhận, phân tích và chuẩn bị kế hoạch quản lý rủi ro là một trong những yếu tố then chốt để đảm bảo dự án thành công cũng như nhận định được một Project Manager xuất sắc.
Khi bạn chủ động quản lý rủi ro thì bạn sẽ xây dựng được niềm tin với stakeholder, bạn bảo vệ được tiến độ, budget và quality dự án. Và quan trọng nhất, bạn dẫn dắt đội ngũ đi qua những điều chưa chắc chắn một cách vững vàng.
Hãy biến risk thành công cụ chiến lược, luôn được cập nhật và hữu ích cho mọi quyết định trong hành trình quản lý dự án.