Dự án, chương trình và danh mục: chọn cách làm, dựng quản trị và canh rủi ro (Phần 1/6)

Đăng ngày 23/10/2026

Tóm tắt và điều cần nhớ

Phần một là bài mở đầu của tập hai trong loạt quản trị cấp cao, loạt gồm sáu phần. Lời tựa của tài liệu nguồn xếp bộ ba tập theo ba chặng, từ dẫn dắt bản thân sang dẫn dắt đội rồi hệ thống; tập hai nói về dự án, đổi mới và xung đột. Phần này bàn về dự án, chương trình và danh mục: người điều hành cần chọn việc đáng làm, cách làm, người chịu trách nhiệm và rủi ro phải để mắt. Bài đọc độc lập.

• Dự án hỏi làm cho đúng, chương trình hỏi các dự án có cộng lại thành lợi ích không, danh mục hỏi có chọn đúng việc không.
• Cách làm tuần tự, linh hoạt hay lai được chọn theo việc yêu cầu đã ổn định chưa, thay đổi muộn tốn bao nhiêu và đội có được tự quyết không.
• Quản trị dự án là vai trò, cổng duyệt, đường báo sự cố và chỉ số rõ ràng; PMO có ích khi hỗ trợ, hỏng khi thành cảnh sát.
• Rủi ro cần người đứng tên và rà soát đều đặn; vài dự án hỏng rất nặng mới là mối nguy, không phải mức vượt trung bình.
• Bên liên quan được xếp theo quyền lực và mức quan tâm, mỗi nhóm một cách trao đổi.

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

Mỗi phòng ban hay dùng một chữ cho một ý khác nhau, nên cuộc họp về dự án dễ mở đầu bằng cãi nhau về từ ngữ. Sáu khái niệm sau cần chốt cách hiểu một lần, vì phần còn lại của bài dựa vào chúng.

• Dự án: nỗ lực có điểm đầu và điểm cuối nhằm tạo một kết quả cụ thể, như một ứng dụng hay một cơ sở mới.
• Chương trình: nhóm dự án liên quan được điều phối chung; lợi ích được tạo ngay trong vòng đời chương trình, khác với dự án đơn lẻ thường chỉ có lợi ích sau khi đóng [1].
• Danh mục: toàn bộ dự án và chương trình đang chạy hoặc đề xuất, được phân tích tập trung để chọn đúng việc và cân đối nguồn lực [2].
• Cổng duyệt: điểm kiểm tra định trước, nơi dự án phải chứng minh đáng đi tiếp theo tiêu chí đã rõ.
• Sổ rủi ro: bảng ghi rủi ro cùng xác suất, tác động, cách ứng phó và người chịu trách nhiệm.
• PMO: bộ phận trung tâm đặt chuẩn, hỗ trợ và theo dõi để các dự án làm việc nhất quán.

Bốn pha của dự án và câu hỏi dành cho người điều hành

Dự án nào, từ xây nhà máy đến ra mắt ứng dụng, cũng đi qua bốn pha: khởi động, lập kế hoạch, thực hiện và đóng. Mỗi pha có một câu hỏi thuộc về người điều hành. Khởi động hỏi có nên làm không; điều lệ ngắn nêu mục đích, phạm vi, mốc thời gian, rủi ro chính và người chịu trách nhiệm, kèm kiểm tra khả thi về tiền, người, thời gian, là đủ để trả lời. Lập kế hoạch hỏi làm thế nào và hết bao nhiêu; hãy để chính người sẽ làm cùng viết kế hoạch, vì họ cam kết nhiều hơn.

Thực hiện hỏi dự án có đang đi đúng hướng không, gồm theo dõi tiến độ, báo cáo đều đặn và điều chỉnh khi có bất ngờ. Đóng hỏi đã học được gì. Nhiều đội nhảy sang việc mới mà bỏ nghiệm thu, giải phóng nguồn lực và tổng kết bài học, nên lỗi cũ lặp lại ở dự án sau. Hình 1 gom bốn câu hỏi ấy.

Chọn cách làm: ba câu hỏi trước khi bàn phương pháp

Tranh luận về phương pháp dễ thành chuyện sở thích. Cách bớt cảm tính là hỏi ba điều: yêu cầu đã ổn định chưa, thay đổi muộn tốn bao nhiêu, và đội có quyền tự quyết việc của mình không. Ba câu trả lời ấy nghiêng về một trong ba cách: tuần tự, linh hoạt hoặc lai.

Cách tuần tự chạy theo chuỗi pha nối tiếp, từ chốt yêu cầu, thiết kế, làm ra sản phẩm, kiểm thử đến bàn giao và bảo trì, và hiếm khi quay lại pha trước. Nó hợp với việc có yêu cầu cố định hoặc ràng buộc pháp lý và an toàn, như xây cầu hay hợp đồng nhà nước, vì thay đổi muộn rất đắt. Tài liệu nguồn gọi đây là phương pháp gốc, nhưng bài báo năm 1970 của Winston Royce, hay được gắn với mô hình này, coi việc chỉ kiểm thử ở cuối là rủi ro và thêm các vòng phản hồi; chữ waterfall có thể xuất hiện lần đầu trong một bài năm 1976 [3].

PMBOK là bộ chuẩn của Viện Quản lý Dự án (PMI), không phải một quy trình cố định. Khung năm nhóm quy trình và mười lĩnh vực kiến thức mà tài liệu nguồn trình bày thuộc bản thứ sáu, xuất bản tháng 9/2017; bản thứ bảy năm 2021 thay mười lĩnh vực ấy bằng các nguyên tắc [4]. Bản thứ tám, ra tháng 11/2025, có sáu nguyên tắc và bảy lĩnh vực thực hành: bên liên quan, quản trị, nguồn lực, rủi ro, phạm vi, tiến độ và tài chính [5]. Khi thuê đào tạo hay tư vấn, hãy hỏi họ dùng phiên bản nào.

Cách linh hoạt và cách lai: dùng khi nào, hỏng ở đâu

Cách linh hoạt giao từng phần nhỏ thật sớm, lấy phản hồi rồi điều chỉnh. Bản tuyên ngôn Agile ra đời năm 2001 xếp theo thứ tự ưu tiên chứ không phủ nhận phần còn lại, như đặt cá nhân và tương tác trước quy trình và công cụ, ứng phó thay đổi trước bám theo kế hoạch [6]. Hướng dẫn Scrum 2020 mô tả nhóm gồm một Scrum Master, một Product Owner và các Developers, làm theo Sprint dài tối đa một tháng; Sprint Review là buổi làm việc chung chứ không đơn thuần là trình diễn [7].

Kanban đi bằng bảng việc và giới hạn việc dở dang, hợp với công việc liên tục như hỗ trợ khách hơn là dự án có hạn chót. Nhìn chung, cách linh hoạt chạy tốt khi yêu cầu còn đổi, khách góp ý đều và đội được tự quyết; nó vướng khi hợp đồng đòi chốt phạm vi và giá từ đầu.

Cách lai dùng cả hai trong một dự án, có chủ đích: chốt phạm vi, ngân sách và tuân thủ theo kiểu tuần tự ở hai đầu, còn thiết kế và xây dựng chạy theo vòng ngắn ở giữa. Ví dụ giả định về một đại lý du lịch làm ứng dụng đặt tour: hợp đồng với cổng thanh toán và quy định bảo mật dữ liệu khách chốt từ đầu, còn màn hình đặt tour thử với khách hai tuần một lần. Cách lai hỏng khi không ai biết quy tắc nào áp dụng ở đâu, hoặc lãnh đạo đòi biểu đồ Gantt khi đội chạy Sprint; bảng phân vai RACI cho từng hạng mục giúp tránh điều đó.

Chương trình: nối các dự án với lợi ích

Dự án giao một kết quả cụ thể; chương trình gom nhiều dự án liên quan để đạt kết quả rộng hơn cho tổ chức, và người điều phối phải quản các phụ thuộc giữa chúng [1]. Người quản lý dự án nhìn gần, người quản lý chương trình nhìn xa: họ giữ mục tiêu chung, cách báo cáo thống nhất, rủi ro chạy xuyên dự án và việc đo lợi ích có thật.

Ví dụ giả định về một trường dạy lái xe mở cơ sở thứ hai, gồm bốn dự án: thuê và sửa mặt bằng, mua xe tập, tuyển và đào tạo giáo viên, quảng bá tuyển sinh. Xe tập và giáo viên là nguồn lực dùng chung; quảng bá chạy trước khi giáo viên sẵn sàng thì học viên đăng ký xong phải chờ. Không dự án nào trễ nặng mà chương trình vẫn hỏng, nên người điều phối nhìn mốc của cả bốn và đo bằng số học viên bắt đầu học đúng hẹn.

Chương trình thường hỏng vì các dự án theo mục tiêu khác nhau, đội làm riêng nên trùng việc, chỉ đo từng dự án đúng hạn mà không đo lợi ích, và coi nhẹ thay đổi ở phía người dùng. Công cụ chỉ hỗ trợ quyết định, không thay người ra quyết định.

Danh mục: làm đúng việc, không chỉ làm việc đúng

Lúc đầu chủ doanh nghiệp tự làm mọi việc; về sau có thêm cơ sở, sản phẩm, đối tác, và khi số dự án vượt khả năng nhớ, câu hỏi chuyển từ làm thế nào sang nên làm cái nào. Quản trị danh mục là phân tích tập trung các dự án đang chạy hoặc đề xuất để chọn đúng việc và cân đối nguồn lực [2]. Thiếu nó, thường gặp quá nhiều dự án tranh cùng một nhóm người, dự án được ai đó quý vẫn có vốn dù đóng góp chiến lược thấp, hai phòng làm trùng việc, và nhóm giỏi nhất bị giao việc ít quan trọng nhất.

Công cụ không cần phức tạp: bảng chấm điểm theo vài tiêu chí như độ khớp chiến lược, lợi nhuận kỳ vọng, rủi ro, nhu cầu nhân lực và độ gấp; bảng điều khiển trạng thái; cổng duyệt định kỳ nơi dự án biện minh để được cấp vốn tiếp. Quy tắc nên có: dự án không nối được với mục tiêu chiến lược nào thì không vào danh mục, và danh mục có quyền tạm dừng hoặc dừng.

Ở tổ chức làm linh hoạt, danh mục đổi dạng chứ không biến mất: lập kế hoạch theo quý hoặc cuốn chiếu, cấp vốn cho dòng giá trị thay vì từng dự án, quản trị nhẹ để quyết nhanh, giữ mục tiêu khớp nhau bằng OKR. Hai cái bẫy ngược nhau là phân tích đến tê liệt và tập trung hoá đến mức đội hết quyền tự quyết. Khi dừng một dự án được yêu thích, hãy giải thích lý do thay vì chỉ thông báo.

Quản trị dự án và PMO: quy tắc rõ để quyết định nhanh hơn

Quản trị dự án trả lời năm câu hỏi: ai quyết định, khi nào dự án phải xin phép đi tiếp, sự cố lên cấp nào, thành công đo bằng gì và rủi ro được theo dõi ra sao. Câu trả lời thành vai trò rõ cho nhà tài trợ, ban chỉ đạo và quản lý dự án, cổng duyệt có tiêu chí, đường báo sự cố, chỉ số và quy trình rủi ro. Mục tiêu không phải thêm thủ tục mà tránh bất ngờ đắt giá. Bản thứ tám của PMBOK đặt quản trị thành một lĩnh vực riêng và mở rộng phần về PMO [5].

PMO có ba mức can thiệp: hỗ trợ bằng mẫu biểu, đào tạo, lời khuyên; kiểm soát bằng cách đòi tuân thủ chuẩn; chỉ đạo bằng cách trực tiếp điều hành dự án. Doanh nghiệp nhỏ thường chỉ cần một người giữ mẫu biểu, danh sách dự án và nhịp họp. Trong môi trường linh hoạt, PMO chuyển từ kiểm soát sang tháo gỡ: điều phối phụ thuộc giữa các đội và theo dõi kết quả ở cấp danh mục.

PMO thất bại vì bốn lý do quen thuộc: thủ tục nhiều hơn quyết định nên đội né; không có lãnh đạo đứng sau nên không ai nghe; một quy trình cỡ chung cho mọi dự án; và hình ảnh cảnh sát dự án khiến người ta không mời nó sớm. Phép thử đơn giản là đội có chủ động tìm PMO khi gặp khó không.

Rủi ro: quy trình năm bước và cái đuôi dài

Rủi ro là sự kiện chưa xảy ra nhưng có thể xảy ra; đã xảy ra thì thành vấn đề. Quy trình gồm năm việc: nhận diện cùng đội, nhà cung cấp, khách và bài học dự án cũ; đánh giá theo xác suất và tác động; lập phương án ứng phó; theo dõi bằng sổ rủi ro; thông báo cho các bên. Ma trận xác suất và tác động giúp xếp ưu tiên: thấp cả hai thì theo dõi, xác suất cao tác động thấp thì để mắt, xác suất thấp tác động cao thì chuẩn bị dự phòng, cả hai cao thì xử lý ngay (Hình 4).

Với mối đe doạ có bốn cách ứng phó: tránh bằng cách đổi kế hoạch, giảm xác suất hoặc tác động, chuyển cho bên thứ ba như bảo hiểm hay thuê ngoài, hoặc chấp nhận và theo dõi. Mỗi rủi ro cần một người đứng tên, và sổ rủi ro phải được xem lại ở họp tuần hay mốc quan trọng, vì bản lập từ ngày đầu sẽ lạc hậu sau vài tuần. Danh sách chỉ có giá trị khi dẫn đến quyết định, như chỗ cần thời gian đệm hay nhà cung cấp dự phòng.

Người điều hành nên hỏi thêm về cái đuôi. Flyvbjerg và Budzier phân tích mẫu 1.471 dự án công nghệ thông tin: chi phí vượt trung bình 27%, nhưng cứ sáu dự án có một dự án vượt trung bình 200% và chậm gần 70% [8], tức là mức trung bình che giấu vài dự án hỏng rất nặng. Đó là mẫu công nghệ thông tin, không nên áp nguyên cho ngành khác, nhưng câu hỏi nếu dự án này rơi vào phần xấu nhất thì doanh nghiệp có chịu được không đáng đặt ra trước khi duyệt vốn.

Bên liên quan: xếp theo quyền lực và mức quan tâm

Bên liên quan là mọi người chịu tác động từ dự án hoặc có thể làm kết quả đi lệch: nhà tài trợ, khách, đội, nhưng cũng là người dùng cuối, nhà cung cấp, cơ quan quản lý và cộng đồng. Hãy lập sổ bằng bốn câu hỏi: ai cấp nguồn lực, ai dùng kết quả, ai bị tác động, ai có thể cản trở. Rồi xếp họ theo quyền lực và mức quan tâm: cao cả hai thì quản chặt, quyền lực cao quan tâm thấp thì giữ hài lòng, quyền lực thấp quan tâm cao thì báo tin, còn lại thì theo dõi (Hình 5).

Kế hoạch truyền thông chỉ cần ngắn: nói gì, khi nào, qua kênh nào, ai nhận gì. Lãnh đạo cần bản tóm tắt, kỹ sư cần chi tiết. Tham gia khác báo tin: mời góp ý sớm, nói thẳng về rủi ro và chậm trễ, làm đúng điều đã hứa, chừa chỗ cho phản hồi kể cả chỉ trích. Hệ thống nội bộ có thể đúng về kỹ thuật mà không ai dùng, nếu không ai hỏi người dùng họ cần gì.

Cách áp dụng trong 30 ngày

Sáu việc dưới đây dồn nội dung trên vào một tháng, ngay cả ở doanh nghiệp chỉ vài chục người. Mỗi việc kết thúc bằng một thứ cầm lên xem được, như danh sách, bảng điểm hay trang giấy, để người khác dễ kiểm lại.

• Tuần 1: liệt kê mọi dự án đang chạy, kể cả dự án nhỏ, ghi người đứng tên, ngày kết thúc dự kiến và nguồn lực dùng chung.
• Tuần 2: chấm điểm từng dự án theo ba đến năm tiêu chí và chọn ít nhất một dự án để tạm dừng hoặc dừng.
• Tuần 3: với dự án lớn nhất, viết điều lệ một trang và sổ mười rủi ro, mỗi rủi ro có người đứng tên.
• Tuần 4: lập sổ bên liên quan, xếp vào lưới quyền lực và mức quan tâm, đặt nhịp báo cáo riêng cho từng nhóm.
• Mỗi dự án: ghi rõ chạy theo cách tuần tự, linh hoạt hay lai, và quy tắc nào áp dụng ở đâu.
• Cuối tháng: họp rà danh mục, ghi quyết định giữ, dừng hay tăng nguồn lực kèm lý do.

Trước khi thêm dự án mới, hãy trả lời bốn câu hỏi. Dự án này gắn với mục tiêu chiến lược nào? Việc gì đang chạy sẽ phải nhường người cho nó? Nếu rơi vào phần xấu nhất của chi phí thì doanh nghiệp có chịu được không? Ai nhận kết quả và đã được hỏi ý chưa?

Tình huống áp dụng tại Việt Nam: chương trình cao tốc và nguồn vật liệu dùng chung

Dự án đường bộ cao tốc Bắc – Nam phía Đông giai đoạn 2021 đến 2025 có cấu trúc của một chương trình thực tế tại Việt Nam. Theo VOV ngày 12/3/2025, tuyến dài 721,2 km, chia thành 12 dự án thành phần vận hành độc lập với 25 gói thầu xây lắp; sản lượng khi đó khoảng 66.966 tỷ đồng, đạt 70,3% giá trị hợp đồng [9]. Báo Nhân Dân ngày 31/10/2023, viết về dự án giai đoạn II, cho thấy chỗ nghẽn nằm ở tầng chương trình: mười dự án thành phần cần gần 9,7 triệu m3 cát, trong đó 4,95 triệu m3 lấy từ 77 mỏ đang khai thác; các mỏ ấy đủ trữ lượng nhưng công suất mới đạt 1,66 triệu m3 mỗi năm [10].

Bài ấy còn nêu nhu cầu đất đắp hơn 47 triệu m3, gần 42 triệu m3 trong đó lấy từ 71 mỏ mới, và 14 mỏ đất đã đăng ký nhưng thủ tục chuyển mục đích sử dụng rừng chưa xử lý dứt điểm; có mỏ nêu giá 1,8 tỷ đồng mỗi ha trong khi giá Nhà nước bồi thường khoảng 300 triệu đồng mỗi ha [10]. Nhìn bằng con mắt quản trị, đó là nguồn lực dùng chung và bên liên quan cần thương lượng, loại việc một nhà thầu riêng lẻ khó tự giải. Theo bài báo, bộ chủ quản đã đề nghị bộ khác hướng dẫn cụ thể và giảm bớt thủ tục [10].

Hơn một năm sau, VOV cho biết với hai dự án thành phần đoạn Cần Thơ – Cà Mau, công tác đắp gia tải trong tháng 2/2025 còn thiếu khoảng 2 triệu m3 vật liệu, gồm 1,6 triệu m3 cát và 0,4 triệu m3 đá; công suất khai thác khoảng 35.000 m3 mỗi ngày so với nhu cầu khoảng 69.000 m3 [9]. Bài học cho người điều hành là lập bản đồ nguồn lực dùng chung từ đầu, giao một người nhìn toàn bộ phụ thuộc và đo cả năng lực cung ứng, không chỉ phần trăm giá trị hợp đồng. Bài không theo dõi kết cục sau các bản tin.

Doanh nghiệp tại Việt Nam không cần quy mô ấy để gặp cùng cấu trúc: một đội thợ, một kho hay một chuyên gia dùng chung cho nhiều dự án. Hãy hỏi ai điều phối nguồn lực đó và dựa trên số liệu nào.

Sai lầm thường gặp và giới hạn của bài

Bốn lỗi dưới đây gặp nhiều khi doanh nghiệp bắt đầu quản trị dự án có hệ thống. Lỗi nào cũng sửa được sớm, nên đáng soát một lần trước khi mở thêm dự án, nhất là khi nhiều việc đang chạy cùng lúc.

• Chọn phương pháp theo thời thượng thay vì theo độ ổn định của yêu cầu và giá của thay đổi muộn.
• Nói là linh hoạt nhưng vẫn đòi chốt phạm vi, giá và hạn từ đầu, khiến đội chịu nhược điểm của cả hai cách.
• Chỉ đo từng dự án đúng hạn, đúng ngân sách mà không đo lợi ích chương trình mang lại.
• Giữ mãi dự án đã mất lý do tồn tại chỉ vì đã đầu tư nhiều công sức.

Bài có giới hạn rõ. Tài liệu nguồn viết ở mức nhập môn, nhiều số liệu không nêu nguồn nên bài không dùng. Nghiên cứu về cái đuôi dài lấy từ dự án công nghệ thông tin; ví dụ Việt Nam là hạ tầng công, khác doanh nghiệp tư nhân về thủ tục và vốn. Các khung ở đây là câu hỏi để thử, không phải bằng chứng rằng cách lai hay linh hoạt luôn tốt hơn.

Kết luận

Ba tầng nhìn dự án, chương trình và danh mục giúp người điều hành đặt đúng câu hỏi ở đúng chỗ: làm cho đúng ở dự án, làm cho cộng lại ở chương trình, làm đúng việc ở danh mục. Quản trị, rủi ro và bên liên quan là phần vận hành giữ cho ba tầng ấy chạy được. Phần hai của chuỗi đi xuống công cụ lập kế hoạch dự án như cấu trúc phân rã công việc, biểu đồ Gantt, đường găng và phần mềm, qua hai ca lớn là chương trình Apollo của NASA và máy bay chở khách Dreamliner của Boeing, rồi sang quản trị sản phẩm.

Nguồn và phương pháp

Bài là tổng hợp và phân tích có hỗ trợ AI, diễn đạt lại bằng lời riêng, không phải bản dịch. Nội dung dựa trên tài liệu "Top-Tier Management by Business Explained, Volume 2" của Business Explained (2025), phần mở đầu (trang 1 đến 84), kết hợp nghiên cứu bổ sung từ các nguồn web đánh số trong bài. Các nguồn web được mở và đọc trong khoảng từ ngày 20/10/2026 đến ngày 23/10/2026 theo giờ UTC.

Bài không dùng lại các thống kê của tài liệu nguồn khi chưa kiểm được, gồm tỷ lệ năng suất của Kanban, tỷ lệ dùng Scrum, dự báo của Gartner, tỷ lệ tổ chức dùng cách lai, số người có chứng chỉ PMP, cùng các ví dụ ẩn danh về PMO y tế, danh mục của công ty phần mềm và việc chuyển Office sang dịch vụ đăng ký. Dàn ý, các câu hỏi chọn cách làm, kế hoạch 30 ngày và ví dụ giả định là cách sắp xếp của bài này, không phải kết quả nghiên cứu thực nghiệm.

Điều chưa kiểm chứng: các định nghĩa chương trình, danh mục, lịch sử PMBOK và mô hình thác nước lấy từ Wikipedia, là nguồn thứ cấp; trang của PMI chỉ cho thông tin về bản thứ tám, còn bản thứ sáu và thứ bảy dựa vào Wikipedia. Số liệu của Flyvbjerg và Budzier đọc từ bản tóm tắt trên arXiv, chưa đọc toàn bài; bản đăng trên Harvard Business Review năm 2011 nằm sau cổng trả phí.

Điều chưa kiểm chứng về Việt Nam: các số liệu cao tốc lấy từ hai bản tin báo chí, chưa đối chiếu báo cáo của cơ quan quản lý và chưa biết kết cục cuối năm 2025. Chưa có ví dụ Việt Nam kiểm chứng về cách lai hay PMO ở doanh nghiệp tư nhân, nên bài không nêu.