Menu
ESC

Nhập từ khóa để tìm kiếm

↑↓ Di chuyển
Enter Mở
ESC Đóng

Đang tải...

Bài 52 — Project Governance & Steering Committee

Project Management Fundamentals Bài 52/60

Mở đầu — vì sao bài này quan trọng

Bạn đã bao giờ rơi vào tình huống này chưa: dự án đang chạy, đến giữa chừng thì có một quyết định lớn cần chốt — ví dụ có nên tăng ngân sách thêm 30% để cứu tiến độ hay không. Bạn, với tư cách Project Manager (PM), báo cáo lên. Nhưng rồi ai là người có quyền quyết? Sếp trực tiếp bảo "để hỏi anh Giám đốc". Giám đốc lại bảo "cái này phải để bên Tài chính duyệt". Bên Tài chính bảo "chúng tôi chỉ giải ngân khi có phê duyệt của Ban lãnh đạo". Và thế là quyết định treo lơ lửng ba tuần, trong khi đồng hồ dự án vẫn chạy và tiền vẫn cháy.

Đó chính xác là cái giá của việc thiếu governance — thiếu một khung quản trị rõ ràng. Governance không phải là thứ hào nhoáng hay được ca ngợi như Agile hay AI, nhưng nó là bộ xương sống quyết định dự án của bạn có được điều hành một cách có kỷ luật hay không.

Trong bài này, chúng ta sẽ đi sâu vào hai khái niệm gắn liền nhau: Project Governance (quản trị dự án) và Steering Committee (Ban chỉ đạo/Ban điều hành dự án). Đây là chủ đề mà nhiều PM Việt Nam chỉ hiểu mơ hồ, thường nhầm lẫn giữa "quản lý" (management — việc PM làm hàng ngày) và "quản trị" (governance — cách tổ chức trao quyền và giám sát dự án). Hiểu rõ khác biệt này là bước ngoặt để bạn từ một PM "chạy việc" trở thành một PM biết vận hành quyền lực trong tổ chức.

Khái niệm cốt lõi

Project Governance là gì?

Project Governance là khung (framework) xác định quyền ra quyết định (decision rights) và trách nhiệm giải trình (accountabilities) cho một dự án. Nói đơn giản, nó trả lời ba câu hỏi nền tảng:

  • Ai được quyền quyết định cái gì? (Ví dụ: PM được duyệt chi tiêu dưới 50 triệu, trên mức đó phải trình Steering Committee.)
  • Ai chịu trách nhiệm về kết quả cuối cùng? (Không phải "cả team chịu chung", mà phải chỉ đích danh.)
  • Thông tin đi lên và quyết định đi xuống theo con đường nào? (Escalation path — đường leo thang xử lý vấn đề.)
Hãy phân biệt rõ hai từ dễ lẫn:

  • Management (quản lý) là việc thực thi — PM lập kế hoạch, phân công, theo dõi tiến độ, xử lý rủi ro hàng ngày. Đây là "làm việc đúng cách".
  • Governance (quản trị)khung định hướng và giám sát đứng bên trên — đảm bảo dự án đang "làm việc đúng" (doing the right project), phù hợp chiến lược tổ chức, và có người chịu trách nhiệm khi có sự cố. Governance không làm thay PM; nó tạo ra luật chơi cho PM.
Một cách ví von: nếu dự án là một chuyến xe, PM là tài xế (management), còn governance là hệ thống luật giao thông, biển báo, và người ngồi ghế trên quyết định điểm đến và ngân sách xăng.

Ba trụ cột của Governance

Một khung governance tốt luôn có ba trụ cột:

  • Cấu trúc (Structure): Ai ngồi ở đâu — Sponsor, Steering Committee, PMO, PM, team. Sơ đồ tổ chức dự án và các vai trò.
  • Con người & vai trò (People/Roles): Quyền hạn và trách nhiệm của từng vai trò được viết ra rõ ràng, thường bằng ma trận RACI (Responsible, Accountable, Consulted, Informed).
  • Quy trình & thông tin (Process/Information): Nhịp họp, luồng báo cáo, ngưỡng phê duyệt (approval thresholds), và cơ chế escalation.

Steering Committee — trái tim của governance

Steering Committee (SteerCo) là nhóm các lãnh đạo cấp cao được lập ra để định hướng, giám sát và ra quyết định trọng yếu cho dự án. Đây không phải nơi bàn chi tiết kỹ thuật, mà là nơi chốt những vấn đề vượt thẩm quyền PM.

Thành phần điển hình (Composition):

  • Chủ tịch (Chair) — thường là Project Sponsor: người bỏ tiền/bảo trợ dự án, có quyền lực và ngân sách cao nhất. Sponsor chủ trì SteerCo và là người "accountable" cuối cùng.
  • Đại diện các phòng ban chủ chốt (Business owners): ví dụ Giám đốc Vận hành, Giám đốc Tài chính, Giám đốc CNTT — những người mà dự án tác động trực tiếp đến bộ phận họ.
  • Đại diện người dùng cuối / khách hàng (Senior User): đảm bảo sản phẩm giải quyết đúng nhu cầu.
  • PM (thường tham dự nhưng KHÔNG phải thành viên biểu quyết): PM trình bày tình hình, đưa khuyến nghị, nhưng quyền quyết định thuộc về committee.
  • Đôi khi có PMO đóng vai trò thư ký, chuẩn bị tài liệu và ghi biên bản.
Theo mô hình PRINCE2, cấu trúc này gọi là Project Board, gồm ba vai trò cân bằng: Executive (đại diện lợi ích kinh doanh — thường là Sponsor), Senior User (đại diện người dùng), và Senior Supplier (đại diện đơn vị cung cấp/thực thi). Ba góc nhìn này cân bằng lẫn nhau để tránh quyết định lệch.

Vai trò của Steering Committee:

  • Phê duyệt các mốc lớn (phase gates), thay đổi phạm vi/ngân sách vượt ngưỡng, và Project Charter.
  • Xử lý các vấn đề escalate lên (issues, risks vượt thẩm quyền PM).
  • Gỡ rào cản về nguồn lực, chính trị nội bộ, ưu tiên giữa các dự án.
  • Đưa ra quyết định "go/no-go" tại các gate quan trọng, kể cả quyết định dừng dự án.
  • Bảo vệ dự án khỏi các thay đổi vô lý và giữ dự án bám chiến lược.

Tần suất và nhịp vận hành

SteerCo thường họp định kỳ — với dự án lớn là hàng tháng, dự án nóng thì hai tuần một lần. Ngoài ra có các cuộc họp bất thường (ad-hoc) khi có quyết định khẩn. Nguyên tắc vàng: SteerCo càng cấp cao, họp càng ngắn gọn và tập trung vào quyết định, không sa đà chi tiết vận hành.

Tình huống thực tế

Tình huống 1 — Dự án ERP tại một tập đoàn sản xuất ở Bình Dương

Một tập đoàn sản xuất nội thất xuất khẩu (khoảng 2.500 nhân viên) triển khai hệ thống ERP SAP, ngân sách 42 tỷ đồng, thời gian 18 tháng. Ban đầu, dự án được giao cho một PM giỏi kỹ thuật nhưng không có Steering Committee. Mọi quyết định lớn PM phải "chạy" từng lãnh đạo phòng ban riêng lẻ.

Diễn biến: Đến tháng thứ 6, phòng Kế toán muốn giữ quy trình cũ, phòng Sản xuất lại muốn thay đổi hoàn toàn theo chuẩn SAP. Hai bên mâu thuẫn. PM không có thẩm quyền phân xử. Dự án đình trệ gần hai tháng, chi phí đội thêm khoảng 3,5 tỷ đồng do đội tư vấn nước ngoài vẫn tính phí theo ngày.

Giải pháp: Ban Tổng giám đốc lập một Steering Committee do Phó Tổng phụ trách vận hành làm Chủ tịch, gồm Giám đốc Tài chính, Giám đốc Sản xuất, Giám đốc CNTT, họp hai tuần/lần. Ngay cuộc họp đầu tiên, committee ra quyết định: "Theo chuẩn SAP, chỉ tùy biến khi có lý do pháp lý bắt buộc." Mâu thuẫn kéo dài hai tháng được chốt trong 90 phút.

Bài học: Không phải PM kém, mà thiếu một cơ chế trao quyền quyết định ở cấp đủ cao. Steering Committee tồn tại chính là để phá vỡ những thế bế tắc mà PM không đủ thẩm quyền giải quyết.

Tình huống 2 — Ngân hàng số triển khai Mobile App mới

Một ngân hàng thương mại cổ phần tại TP.HCM triển khai ứng dụng mobile banking thế hệ mới. Họ thiết lập SteerCo bài bản: Sponsor là Phó Tổng phụ trách Khối Ngân hàng số (Chair), thành viên gồm Giám đốc Khối CNTT, Giám đốc Khối Bán lẻ (đại diện người dùng cuối), Giám đốc Rủi ro, và Giám đốc Tuân thủ. Họ quy định ngưỡng: PM tự quyết thay đổi dưới 200 triệu; từ 200 triệu đến 1 tỷ cần Sponsor duyệt; trên 1 tỷ hoặc ảnh hưởng tiến độ go-live phải đưa ra SteerCo.

Diễn biến: Ở tháng thứ 4, đội phát triển đề xuất tích hợp thêm eKYC bằng AI, chi phí phát sinh 2,8 tỷ và trễ go-live 6 tuần. Vượt xa thẩm quyền PM. PM chuẩn bị một tờ trình một trang: bối cảnh, ba phương án (làm ngay / làm sau go-live / không làm), tác động chi phí–tiến độ–rủi ro của từng phương án, và khuyến nghị. SteerCo họp, chọn phương án "làm sau go-live" vì Giám đốc Rủi ro lo ngại eKYC AI chưa đủ chín để ra mắt cùng lúc.

Bài học: Governance tốt không làm chậm dự án — nó làm quyết định nhanh và có trách nhiệm hơn. Nhờ có ngưỡng rõ ràng và tờ trình chuẩn, một quyết định 2,8 tỷ được chốt trong một buổi họp thay vì tranh cãi hàng tháng. Và quan trọng: khi có sự cố sau này, ai đã quyết được ghi rõ trong biên bản.

Tình huống 3 — Steering Committee "hình thức" tại một dự án chuyển đổi số công

Một Sở tại một tỉnh miền Trung triển khai cổng dịch vụ công trực tuyến. Có Steering Committee đúng nghĩa trên giấy, do một Phó Giám đốc Sở làm Chủ tịch. Nhưng thực tế, các cuộc họp SteerCo biến thành nơi... nghe PM báo cáo tiến độ suốt 2 tiếng, rồi giải tán, không ai quyết gì. Các vấn đề escalate lên đều được trả lời "để xem xét thêm".

Diễn biến: Vì SteerCo không thực sự ra quyết định, các vấn đề tồn đọng chồng chất. Đến hạn nghiệm thu, phát hiện phạm vi đã trôi (scope creep) do không ai kiểm soát thay đổi. Dự án phải gia hạn thêm 5 tháng.

Bài học: Một SteerCo tồn tại trên giấy nhưng không ra quyết định thực chất còn nguy hiểm hơn không có, vì nó tạo ảo giác có governance. Committee phải là nơi quyết, không phải nơi nghe báo cáo. Nếu buổi họp SteerCo của bạn chỉ toàn slide tiến độ, bạn đang dùng sai công cụ.

Hướng dẫn từng bước

Đây là cách thiết lập governance và Steering Committee cho một dự án từ con số không:

Bước 1 — Xác định mức độ governance phù hợp. Không phải dự án nào cũng cần SteerCo. Dự án nhỏ (dưới vài trăm triệu, một phòng ban) chỉ cần một Sponsor và checkpoint đơn giản. Dự án lớn, liên phòng ban, rủi ro cao thì cần SteerCo đầy đủ. Đừng "đao to búa lớn" quá mức — governance thừa cũng gây quan liêu.

Bước 2 — Chọn đúng Sponsor. Sponsor phải là người có thực quyền về ngân sách và ảnh hưởng, thực sự quan tâm đến kết quả, và sẵn sàng dành thời gian. Một Sponsor bù nhìn là dấu hiệu dự án sẽ chết yểu.

Bước 3 — Thiết kế thành phần SteerCo. Chọn đúng người: mỗi thành viên phải đại diện cho một nhóm lợi ích bị dự án tác động và có thẩm quyền quyết định thay bộ phận mình. Giữ committee gọn (5–7 người là lý tưởng); quá đông sẽ không quyết được gì.

Bước 4 — Viết Terms of Reference (TOR) — điều lệ hoạt động. Tài liệu này ghi rõ: mục đích committee, thành viên và vai trò, quyền quyết định, ngưỡng phê duyệt (approval thresholds), nhịp họp, và quy tắc ra quyết định (đồng thuận hay Chair quyết cuối). Đây là "hiến pháp" của SteerCo.

Bước 5 — Định nghĩa escalation path. Vẽ rõ: vấn đề nào PM tự xử, vấn đề nào lên Sponsor, vấn đề nào lên SteerCo. Kèm ngưỡng cụ thể theo tiền, thời gian, và mức rủi ro.

Bước 6 — Lập ma trận RACI cho các quyết định trọng yếu. Với mỗi loại quyết định (duyệt ngân sách, đổi phạm vi, chốt go-live...), xác định ai Responsible, ai Accountable, ai Consulted, ai Informed. Nhớ: mỗi quyết định chỉ có một người Accountable.

Bước 7 — Thiết lập nhịp và định dạng họp. Chuẩn hóa agenda SteerCo: (1) quyết định cần chốt hôm nay, (2) rủi ro/vấn đề escalate, (3) tình hình tổng quan (dashboard 1 trang), (4) quyết định và hành động. Ưu tiên phần "quyết định" lên đầu.

Bước 8 — Ghi biên bản và theo dõi quyết định. Mọi quyết định của SteerCo phải được ghi lại (ai quyết, quyết gì, ngày nào) và theo dõi việc thực thi. Biên bản chính là "bảo hiểm trách nhiệm" cho cả PM lẫn committee.

Lỗi thường gặp & mẹo

Lỗi 1 — Biến SteerCo thành buổi báo cáo tiến độ. Đây là lỗi phổ biến nhất (như tình huống 3). Mẹo: đặt phần "quyết định cần chốt" lên đầu agenda, gửi báo cáo trạng thái trước buổi họp để đọc, dành thời gian họp cho việc quyết.

Lỗi 2 — Committee quá đông hoặc sai người. 15 người thì không ai chịu trách nhiệm, và cuộc họp thành sân khấu chính trị. Mẹo: giữ 5–7 người có thực quyền; người không quyết được thì mời với vai trò "Informed" qua email, đừng cho vào phòng họp.

Lỗi 3 — Không có ngưỡng phê duyệt rõ ràng. Khi mọi thứ đều phải lên SteerCo, dự án tê liệt; khi không có ngưỡng, PM tự quyết cả những thứ vượt tầm rồi vỡ trận. Mẹo: định lượng ngưỡng bằng con số (tiền, ngày trễ, % scope) ngay từ đầu trong TOR.

Lỗi 4 — Nhầm Accountable với Responsible. Nhiều tổ chức để "cả committee chịu trách nhiệm" — nghĩa là không ai chịu. Mẹo: mỗi dự án và mỗi quyết định lớn phải chỉ đích danh một người Accountable (thường là Sponsor).

Lỗi 5 — PM tưởng mình là thành viên biểu quyết. PM trình bày và khuyến nghị, nhưng quyền quyết thuộc committee. Nếu PM tự quyết những thứ thuộc thẩm quyền SteerCo, khi có sự cố PM sẽ gánh trách nhiệm oan. Mẹo: luôn để SteerCo "ký" vào quyết định lớn, và ghi biên bản.

Mẹo vàng — Chuẩn bị "one-pager quyết định". Trước mỗi vấn đề escalate, PM nên chuẩn bị một trang: bối cảnh ngắn, các phương án, tác động (chi phí–thời gian–rủi ro), và khuyến nghị rõ ràng. Điều này giúp committee quyết trong vài phút thay vì tranh luận cả buổi — và làm bạn trông chuyên nghiệp trong mắt lãnh đạo.

Bài tập thực hành

Bài tập 1 — Thiết kế Steering Committee. Chọn một dự án bạn đang/đã tham gia (hoặc giả định: triển khai hệ thống CRM cho một chuỗi bán lẻ 50 cửa hàng, ngân sách 8 tỷ, 12 tháng). Hãy liệt kê:

  • Ai là Sponsor và vì sao chọn người đó?
  • 5–7 thành viên SteerCo, mỗi người đại diện lợi ích gì?
  • Nhịp họp đề xuất.
Bài tập 2 — Viết ngưỡng escalation. Với dự án trên, hãy đề xuất bảng ngưỡng phê duyệt 3 cấp (PM tự quyết / Sponsor duyệt / SteerCo quyết) theo ba chiều: tiền, số ngày trễ tiến độ, và thay đổi phạm vi. Ghi con số cụ thể.

Bài tập 3 — Ma trận RACI mini. Lập ma trận RACI cho 4 loại quyết định: (a) duyệt Project Charter, (b) duyệt thay đổi phạm vi lớn, (c) chốt go-live, (d) quyết định dừng dự án. Các vai trò gồm: Sponsor, SteerCo, PM, Business Owner, PMO.

Bài tập 4 — Chẩn đoán governance. Đọc lại tình huống 3 (dự án công). Hãy viết 3 khuyến nghị cụ thể để biến SteerCo "hình thức" đó thành một committee ra quyết định thực chất.

Tóm tắt

  • Project Governance là khung xác định quyền ra quyết địnhtrách nhiệm giải trình cho dự án — trả lời: ai quyết gì, ai chịu trách nhiệm, thông tin đi theo con đường nào.
  • Phân biệt rõ Management (PM thực thi hàng ngày) và Governance (khung định hướng và giám sát đứng bên trên).
  • Ba trụ cột governance: Cấu trúc, Con người/Vai trò, Quy trình/Thông tin.
  • Steering Committee là nhóm lãnh đạo cấp cao ra quyết định trọng yếu; Chair thường là Sponsor. Thành phần gồm đại diện các bên lợi ích chủ chốt; PM tham dự nhưng thường không biểu quyết. Mô hình PRINCE2 gọi là Project Board với ba vai trò Executive / Senior User / Senior Supplier.
  • SteerCo là nơi ra quyết định, không phải nơi nghe báo cáo tiến độ. Cần ngưỡng phê duyệt rõ ràng, escalation path cụ thể, và biên bản quyết định đầy đủ.
  • Mỗi dự án và mỗi quyết định lớn phải có một người Accountable — thường là Sponsor.
  • Công cụ đắc lực của PM: one-pager quyết định — bối cảnh, phương án, tác động, khuyến nghị — giúp committee quyết nhanh và đúng.
Governance không phải giấy tờ quan liêu. Nó là cách bạn đảm bảo rằng khi dự án gặp khúc quanh khó khăn, sẽ có đúng người, ở đúng vị trí, đưa ra đúng quyết định — đúng lúc.