Rủi ro dự án nào đáng báo cáo Ban điều hành? Nhìn từ tác động kinh doanh

Dịch sự kiện kỹ thuật thành hậu quả kinh doanh

Một mô tả như tích hợp có thể thất bại mới nói về sự kiện. Cần nối sự kiện với công việc bị ảnh hưởng: đơn hàng không được xác nhận, dữ liệu thanh toán không đối soát được hoặc nhân viên phải quay về quy trình thủ công. Từ đó xác định hậu quả đối với khách hàng, chi phí, kiểm soát và mục tiêu đầu tư. Không nên mặc định mọi lỗi kỹ thuật đều gây cùng mức tác động.

Cách diễn đạt hữu ích gồm nguyên nhân, sự kiện chưa chắc xảy ra và hậu quả. Chẳng hạn, vì chưa thử tải với dữ liệu đại diện, hệ thống có thể không đáp ứng khi mở rộng, khiến doanh nghiệp phải hạn chế tiếp nhận giao dịch. Nếu hệ thống đã không đáp ứng trong thử nghiệm, đó là vấn đề đã xuất hiện, cần kế hoạch xử lý; rủi ro còn lại là khả năng biện pháp sửa không đạt trước mốc vận hành.

Chủ nghiệp vụ phải tham gia xác nhận hậu quả. IT có thể đánh giá khả năng phục hồi kỹ thuật, nhưng quản lý vận hành biết khoảng gián đoạn nào khiến khách hàng bị ảnh hưởng. Năng lực lãnh đạo dự án IT thể hiện ở việc kết nối các góc nhìn này. Khi hậu quả đã rõ, việc lựa chọn rủi ro cần báo cáo mới có cơ sở ngoài màu trạng thái.

Trình cấp điều hành khi tác động vượt khả năng xử lý của dự án

Một nguy cơ đáng trình có thể vượt hạn mức ngân sách, làm mất lợi ích trọng yếu, ảnh hưởng nhiều đơn vị hoặc đòi hỏi chấp nhận rủi ro ngoài ủy quyền. Ngược lại, một vấn đề gây nhiều công sức nhưng còn xử lý được trong kế hoạch không nhất thiết cần Ban điều hành chốt. Nếu báo cáo mọi chi tiết, những quyết định thực sự cần lãnh đạo sẽ khó được nhận ra.

Doanh nghiệp cần thống nhất ngưỡng theo loại tác động. Có thể dùng giới hạn tài trợ, mốc chiến lược, mức gián đoạn hoặc trách nhiệm dữ liệu, tùy tổ chức. Không lấy một tỷ lệ chi phí hay số ngày trễ bất kỳ làm chuẩn chung. Ngoài mức tác động, cần xem thời gian còn lại để phản ứng: một rủi ro trung bình nhưng quyết định phải có ngay có thể cần được trình trước rủi ro lớn còn nhiều lựa chọn.

Bảng dưới đây là công cụ gợi ý để sàng lọc nội dung trình điều hành. Người sử dụng cần đối chiếu với quyền hạn và cơ chế rủi ro của doanh nghiệp.

Cần đọc cả tác động tích lũy. Vài thay đổi nhỏ có thể cùng tiêu thụ nguồn dự phòng, còn nhiều dự án có thể cùng phụ thuộc một nhà cung cấp. Sổ rủi ro riêng lẻ sẽ khó thấy sự tập trung này. Khi trình, Project Manager nên chỉ rõ mối liên hệ thay vì cộng những điểm số không cùng ý nghĩa thành một con số tổng.

Đánh giá phần rủi ro còn lại bằng hiệu lực kiểm soát

Một rủi ro có biện pháp xử lý chưa đồng nghĩa đã được kiểm soát. Cần biết biện pháp đã được thực hiện, được kiểm tra và có đủ năng lực duy trì hay chưa. Kế hoạch phục hồi viết xong khác với kết quả thử phục hồi; bố trí người hỗ trợ khác với người đã được hướng dẫn và có lịch thực tế. Báo cáo nên phân biệt các trạng thái này để tránh giảm mức rủi ro quá sớm.

The Orange Book của HM Treasury đặt quản lý rủi ro trong hoạt động lãnh đạo và ra quyết định của khu vực công Anh. Một nguyên tắc có thể tham khảo là đánh giá cả sự bất định và hiệu lực biện pháp kiểm soát. Doanh nghiệp cần áp dụng theo bối cảnh của mình, thay vì xem tài liệu này như quy định bắt buộc cho mọi tổ chức.

Đối với rủi ro dữ liệu hoặc truy cập, cần người có chuyên môn xác nhận phạm vi kiểm tra. Năng lực quản lý bảo mật thông tin giúp làm rõ phần này. Nếu bằng chứng còn yếu, báo cáo cần nêu điều chưa biết và hoạt động làm rõ, không dùng một ước lượng xác suất quá chính xác để che sự thiếu dữ liệu.

Mỗi rủi ro trọng yếu phải dẫn tới lựa chọn cụ thể

Ban điều hành cần nhìn những lựa chọn còn khả thi: bổ sung nguồn lực, giảm phạm vi, đổi thời điểm, thử nghiệm thêm hoặc chấp nhận phần rủi ro còn lại trong giới hạn cho phép. Mỗi phương án cần chi phí, tác động tới lợi ích và điều kiện thực hiện. Một đề nghị chỉ nói cần hỗ trợ sẽ để lãnh đạo tự tìm phương án trong khi không có đủ chi tiết.

Ví dụ giả định: kiểm thử chuyển dữ liệu chưa chứng minh có thể hoàn tất trong cửa sổ cuối tuần. Nhóm có thể đề xuất chia phạm vi chuyển, tăng thời gian ngừng dịch vụ hoặc lùi mốc để thử thêm. Lãnh đạo nghiệp vụ phải biết nhóm khách hàng nào chịu ảnh hưởng; đội vận hành phải xác nhận phương án quay lại. Không thể chốt chỉ từ ước lượng thời gian chạy của chương trình chuyển dữ liệu.

Hồ sơ trình cần nêu thời hạn và hậu quả nếu chưa quyết định. Khi hết cửa sổ đặt nguồn lực nhà cung cấp, một phương án có thể không còn khả thi dù lãnh đạo đồng ý sau đó. Năng lực lãnh đạo công nghệ giúp đặt quyết định dự án vào bối cảnh hoạt động doanh nghiệp. Tuy nhiên, quyền chốt và trách nhiệm chấp nhận hậu quả vẫn phải được ghi rõ.

Báo cáo biến động để lãnh đạo thấy nguy cơ đang tiến gần

Một danh sách giữ nguyên qua nhiều kỳ có thể khiến người đọc quen với rủi ro mà không thấy nó đang thay đổi. Cần báo cáo điều mới: giả định bị bác bỏ, biện pháp quá hạn, nguồn lực mất đi hoặc dấu hiệu kích hoạt đã xuất hiện. Nếu mức rủi ro không đổi, vẫn nên giải thích vì sao đánh giá còn phù hợp với bằng chứng hiện tại.

Chỉ báo cảnh báo phải liên quan cơ chế thất bại. Với dữ liệu, có thể theo dõi ngoại lệ chưa đối soát và mức hoàn thành kiểm tra mẫu. Với đối tác, có thể xem việc thay nhân sự chủ chốt hoặc những mốc trung gian liên tục không đạt. Một chỉ số trung bình của toàn dự án có thể che nhóm giao dịch trọng yếu đang có vấn đề. Vì vậy, báo cáo nên giữ phạm vi tác động đủ cụ thể.

Không cần đợi kỳ họp định kỳ khi rủi ro vượt ngưỡng khẩn cấp đã thống nhất. Đường trình ngoài kỳ cần có người tiếp nhận và cơ chế phản hồi. Project Manager cũng cần biết quyết định tạm thời nào được phép thực hiện để bảo toàn dịch vụ trong lúc chờ. Cơ chế này phải được thiết kế từ trước, tránh dùng tính khẩn cấp để vượt quyền hoặc tạo cam kết chưa được phê duyệt.

Báo cáo tốt không chỉ phản ánh tin xấu. Nếu thử nghiệm đã giảm một bất định quan trọng, cần cập nhật để lãnh đạo giải phóng nguồn lực hoặc cho phép bước tiếp theo. Việc kiểm tra thông tin thuộc nền tảng kiểm soát dự án CNTT. Giá trị nằm ở sự thay đổi hiểu biết và quyết định, không ở số lượng rủi ro được ghi nhận.

Giữ trách nhiệm đến khi tác động được kiểm tra lại

Sau cuộc họp, nhật ký cần ghi người chốt, lựa chọn, phạm vi chấp nhận, điều kiện và thời điểm xem lại. Quyết định chấp nhận rủi ro không phải phép bỏ mọi biện pháp kiểm soát. Nếu điều kiện đã thay đổi, chủ rủi ro phải được thông báo để đánh giá lại. Những rủi ro chuyển sang vận hành cũng cần người tiếp nhận, không tự đóng chỉ vì dự án kết thúc.

Project Manager phải kiểm tra tác động của quyết định lên lịch, ngân sách và cam kết của các bộ phận. Phê duyệt bổ sung người chưa tạo năng lực nếu người ấy chưa được bố trí; đồng ý giảm phạm vi chưa có hiệu lực nếu tiêu chí nghiệm thu vẫn giữ nguyên. Các hồ sơ cần cùng phản ánh một lựa chọn để đội thực hiện không tiếp tục theo kế hoạch cũ.

Có thể bắt đầu bằng ba rủi ro đang quan trọng nhất, viết lại mỗi rủi ro thành một chuỗi nguyên nhân, sự kiện và hậu quả kinh doanh. Sau đó xác định quyền cần huy động và thời hạn quyết định. Nếu chưa trả lời được, cần làm rõ thêm trước khi đưa lên cuộc họp. Nhờ vậy, Ban điều hành nhận được một đề nghị có thể hành động, thay vì một danh sách màu đỏ không chỉ ra việc phải chốt.

Bài viết liên quan

• Thiết lập Dashboard điều hành dự án IT phục vụ các cuộc họp Steering Committee.
• Quản trị thay đổi chiến lược trong quá trình triển khai dự án IT.
• Kiểm soát chất lượng sản phẩm bàn giao và xác định điều kiện nghiệm thu ở cấp quản trị.
• Tiến độ, ngân sách và chất lượng cùng bị đe dọa: Ra quyết định trong khủng hoảng

Nguồn tham khảo

1. UK Government — The Orange Book: Management of Risk
2. UK Government — Government Functional Standard GovS 002: Project Delivery
3. APM — What is governance?