INFOCHIEF ACADEMY · PROJECT MANAGER KNOWLEDGE SERIES

Thiết lập Project Governance: Phân định quyền quyết định giữa Sponsor, Steering Committee và Project Manager.

Quản trị dự án cần bắt đầu từ loại quyết định và quyền được giao. Phân định Sponsor, Steering Committee và Project Manager giúp dự án chốt đúng việc, đúng cấp, với trách nhiệm và bằng chứng rõ ràng.

Biên soạn: Infochief Academy · Chuyên đề: Giám đốc dự án IT – Project Manager

← Trở về thư viện bài viết

Minh họa biên tập: sponsor và ban chỉ đạo thảo luận quyền quyết định cùng quản lý dự án trong phòng họp sáng.

Cuộc họp Steering Committee kết thúc với lời đề nghị đội dự án tiếp tục làm rõ. Tuần sau, cùng vấn đề lại xuất hiện: một phòng ban muốn thêm chức năng, tài chính chưa đồng ý ngân sách, còn Project Manager không biết mình được phép chốt đến đâu. Trong tình huống giả định ấy, dự án có đủ người dự họp nhưng vẫn thiếu một cơ chế quyết định.

Project Governance, hay quản trị dự án, thường được thể hiện bằng sơ đồ vai trò và lịch họp. Những thứ đó chỉ hữu ích khi trả lời được câu hỏi thực tế: loại quyết định này thuộc ai, người ấy cần bằng chứng gì và phải quyết định trước thời điểm nào? Nếu chưa trả lời, tổ chức chỉ đang chuyển vấn đề từ cuộc họp này sang cuộc họp khác.

Phân quyền hiệu quả không có nghĩa đưa mọi việc lên cấp cao nhất. Nó tạo không gian cho Project Manager điều hành, đồng thời bảo đảm những đánh đổi về đầu tư, lợi ích và rủi ro được chốt ở đúng cấp.

Bắt đầu từ quyết định thay vì từ chức danh

Các doanh nghiệp có thể dùng cùng tên Sponsor, Steering Committee và Project Manager nhưng trao quyền rất khác nhau. Sponsor là người bảo trợ; Steering Committee là ban chỉ đạo; Project Manager quản lý việc triển khai. Trong một số tổ chức, giám đốc dự án quản lý cả nhiều Project Manager. Vì vậy, chức danh không đủ để suy ra ai được duyệt thay đổi hoặc ai chịu trách nhiệm về lợi ích.

Nhóm nên liệt kê những quyết định thực sự xảy ra: duyệt mục tiêu, cấp ngân sách, thay phạm vi, chấp nhận sản phẩm, cho phép vận hành và giải quyết tranh chấp nguồn lực. Với mỗi loại, xác định người chuẩn bị đề xuất, người được tham vấn và người có quyền chốt. Không để chữ chịu trách nhiệm chung che khuất quyền phê duyệt cụ thể.

RACI có thể giúp phân công người thực hiện, người chịu trách nhiệm cuối cùng, người tham vấn và người nhận thông tin. Nhưng RACI không tự quy định hạn mức ngân sách, cách biểu quyết hay xử lý khi người phê duyệt vắng mặt. Những nội dung này cần được đưa vào điều lệ quản trị hoặc hồ sơ ủy quyền, cùng cơ chế thay thế.

Tư duy này gắn với năng lực quản trị của Giám đốc dự án IT. Khi phân quyền xuất phát từ quyết định, dự án có thể kiểm tra hiệu lực bằng công việc thực tế, thay vì đánh giá một sơ đồ trông có vẻ đầy đủ.

Sponsor giữ mục tiêu và điều kiện tạo lợi ích

Sponsor cần có đủ vị trí và khả năng huy động những bộ phận quyết định thành công của dự án. Người bảo trợ không chỉ ký lúc khởi động hoặc xuất hiện khi dự án trễ. Họ phải giữ lý do đầu tư, hỗ trợ giải quyết những phụ thuộc ngoài quyền đội dự án và bảo đảm có người sở hữu lợi ích sau chuyển giao.

Ví dụ, dự án cần phòng kinh doanh dành thời gian chuẩn hóa dữ liệu khách hàng. Project Manager có thể đưa việc đó vào kế hoạch và theo dõi, nhưng khó tự điều chuyển nhân sự bán hàng. Sponsor phải phối hợp với lãnh đạo nghiệp vụ để biến sự đồng ý thành cam kết về người và thời gian. Nếu cam kết không khả thi, cần xem lại phạm vi hoặc lịch.

Sponsor cũng không nên thay Project Manager điều phối từng công việc. Can thiệp trực tiếp vào việc giao nhiệm vụ có thể tạo hai luồng chỉ đạo, làm mất khả năng nhìn tổng thể của người quản lý dự án. Một cơ chế tốt xác định việc nào Sponsor quyết định, việc nào yêu cầu giải trình và việc nào đã ủy quyền cho đội triển khai.

Hướng dẫn về Senior Responsible Owner của Chính phủ Anh là một nguồn tham khảo về trách nhiệm lãnh đạo và quan hệ giữa các vai trò. Đây là hướng dẫn trong khu vực công của Anh, không phải quy định áp dụng mặc nhiên cho doanh nghiệp Việt Nam. Giá trị tham khảo nằm ở việc xác định trách nhiệm rõ và phù hợp với quyền được giao.

Ban chỉ đạo giải quyết đánh đổi vượt ranh giới phòng ban

Steering Committee cần một điều lệ ngắn: mục đích, thành viên, thẩm quyền, điều kiện đủ để quyết định và cách ghi nhận quyết định. Nếu ban chỉ đạo chỉ nghe cập nhật, những vấn đề liên phòng ban sẽ chưa có nơi giải quyết. Ngược lại, nếu mọi thay đổi nhỏ đều cần ban chỉ đạo, dự án sẽ tắc ở lịch họp.

Ban chỉ đạo có thể cân nhắc thay đổi lớn về lợi ích, tài trợ, mốc chiến lược hoặc nguồn lực liên đơn vị trong phạm vi được tổ chức trao quyền. Không nên giả định ban luôn có quyền quyết định tất cả. Những vấn đề vượt ủy quyền vẫn phải trình cấp đầu tư hoặc điều hành có thẩm quyền, với một đường trình rõ ràng.

Bảng sau là ví dụ phân quyền đề xuất, cần được xác nhận theo cơ cấu của từng doanh nghiệp. Một tổ chức có thể giao quyền khác mà vẫn vận hành tốt nếu ranh giới rõ và không xung đột.

Loại quyết định	Người chuẩn bị	Cấp chốt đề xuất
Điều phối trong kế hoạch đã duyệt	Đội dự án	Project Manager trong ủy quyền
Thay đổi ảnh hưởng lợi ích chính	Project Manager và chủ nghiệp vụ	Sponsor hoặc cấp đầu tư
Xung đột nguồn lực liên phòng ban	PMO và các quản lý chức năng	Ban chỉ đạo trong thẩm quyền
Chấp nhận sản phẩm nghiệp vụ	Đội kiểm thử và chủ quy trình	Người được chỉ định nghiệm thu
Cho phép vận hành với rủi ro còn lại	IT, nghiệp vụ và chủ rủi ro	Cấp được giao quyền Go-live

Điều cần đọc từ bảng là sự khác nhau giữa nghiệm thu sản phẩm và chấp nhận rủi ro vận hành. Người xác nhận một chức năng hoạt động chưa chắc được phép cho hệ thống vận hành với lỗi còn mở. Tách hai quyền giúp dự án tránh dùng chữ ký nghiệm thu để thay cho một quyết định rủi ro chưa được thực hiện.

Project Manager cần quyền điều hành tương xứng

Một Project Manager phải chịu trách nhiệm về tiến độ nhưng không được thống nhất thứ tự công việc, không được giữ nguồn lực đã cam kết và không biết hạn mức thay đổi sẽ khó điều hành. Doanh nghiệp cần ghi phạm vi ủy quyền theo loại việc và điều kiện. Chẳng hạn, được điều chỉnh trình tự công việc nếu không ảnh hưởng mốc được bảo vệ và không tạo rủi ro mới vượt mức chấp nhận.

Giới hạn này có thể dùng ngưỡng về chi phí, thời gian, tác động hoặc tổ hợp các yếu tố. Ngưỡng do doanh nghiệp xác lập, không lấy một tỷ lệ bất kỳ làm chuẩn cho mọi dự án. Quan trọng là xem xét tác động tích lũy: nhiều thay đổi nhỏ riêng lẻ có thể làm tổng phạm vi và chi phí vượt giới hạn.

Trong phạm vi được trao, Project Manager cũng phải giữ minh bạch. Các điều chỉnh cần được phản ánh vào kế hoạch, nhật ký quyết định và dự báo. Quyền chủ động không đồng nghĩa quyền âm thầm thay mục tiêu. Nền tảng quản lý dự án CNTT giúp chuyển ủy quyền thành cách điều hành có thể kiểm tra.

Hồ sơ quyết định ngắn hơn báo cáo nhưng rõ hơn

Một báo cáo dài chưa chắc giúp lãnh đạo quyết định. Hồ sơ trình nên xác định việc cần chốt, lý do cần chốt lúc này, các lựa chọn và tác động của mỗi lựa chọn. Nêu khuyến nghị cùng điều chưa biết, thay vì dồn toàn bộ chi tiết kỹ thuật để người dự họp tự tìm ra vấn đề.

Quyết định phải được ghi người chốt, ngày hiệu lực, điều kiện và người thực hiện. Khi phê duyệt có điều kiện, cần biết ai kiểm tra điều kiện đã đạt trước khi chuyển bước. Không thể ghi đồng ý với điều kiện hoàn thành kiểm thử rồi để đội dự án tự hiểu rằng được triển khai dù kết quả còn thiếu.

Đường trình khẩn cấp cũng cần được thiết kế. Có thể dùng cuộc họp bất thường hoặc phê duyệt bằng văn bản theo cơ chế nội bộ, nhưng không dùng tính khẩn cấp để xóa trách nhiệm. Trường hợp người quyết định vắng mặt phải có người thay thế đúng ủy quyền. Thời gian phản hồi nên phù hợp với cửa sổ ra quyết định của dự án.

Năng lực chuẩn bị thông tin cho cấp điều hành liên hệ với lãnh đạo công nghệ, trong khi việc giữ cam kết của đội chức năng cần sự hỗ trợ từ quản lý bộ phận IT. Hai mối liên hệ này cho thấy quản trị dự án không thể tách khỏi cách doanh nghiệp phân bổ quyền và nguồn lực.

Chạy thử cơ chế trước khi dự án phải dùng nó

Tình huống minh họa giả định: trong dự án tích hợp ERP, phòng vận hành yêu cầu đổi cách ghi nhận trạng thái giao hàng. Thay đổi ít công lập trình nhưng ảnh hưởng đối soát doanh thu. Nếu đội dự án xem đây là chỉnh sửa kỹ thuật nhỏ, họ có thể bỏ qua chủ quy trình và tài chính. Nếu ban chỉ đạo phải duyệt mọi chi tiết, tiến độ lại bị chậm không cần thiết.

Nhóm có thể chạy thử đường quyết định: chủ nghiệp vụ mô tả tác động; tài chính kiểm tra đối soát; Project Manager xác định ảnh hưởng kiểm thử, dữ liệu và mốc; cấp có quyền chốt thay đổi. Bài tập này làm lộ những điểm thiếu trong điều lệ quản trị mà không cần chờ tranh chấp thật xuất hiện.

Sau một thời gian vận hành, nên rà soát số quyết định còn mở, thời gian chờ, vấn đề bị trình nhiều cấp và quyết định phải làm lại vì thiếu thông tin. Những chỉ số này hỗ trợ cải tiến cơ chế. Không nên đánh giá governance chỉ bằng số cuộc họp hoặc tỷ lệ tham dự, vì một ban chỉ đạo họp đều vẫn có thể không chốt được việc.

Bước khởi đầu có thể rất nhỏ: chọn năm loại quyết định quan trọng nhất của dự án, ghi người chốt cùng bằng chứng và giới hạn ủy quyền. Sau đó dùng một tình huống đang vướng để kiểm tra. Khi quyền quyết định được vận hành rõ, cuộc họp ban chỉ đạo sẽ kết thúc bằng hành động có chủ trách nhiệm, thay vì bằng một lời đề nghị tiếp tục làm rõ.