Phương pháp nền tảng của quản lý dự án: thác nước, đường găng, PERT, Scrum, Kanban, Lean (Phần 1/2)

Đăng ngày 23/10/2026

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

Bài này mở đầu chuỗi hai bài về khung và phương pháp quản lý dự án. Phần này bàn về các phương pháp nền tảng; mỗi phương pháp giải một câu hỏi riêng: làm theo thứ tự nào (thác nước), bao giờ xong (đường găng), ước lượng bất định ra sao (PERT), đang đi đúng hướng chưa (Scrum), việc có chảy đều không (Kanban), đâu là phần thừa (Lean). Phần hai bàn về khung lai, khung theo ngành và văn phòng quản lý dự án.

• Thác nước hợp khi yêu cầu chốt được từ đầu; điểm yếu là phản hồi thật đến muộn.
• Đường găng là chuỗi việc dài nhất nên quyết định ngày xong; nhánh chỉ dư vài ngày mới là chỗ hay trượt.
• PERT thay một con số bằng ba ước lượng, nhưng nếu chỉ xét từng nhánh riêng thì vẫn lạc quan.
• Scrum học qua sprint ngắn, Kanban giữ dòng việc chảy nhờ giới hạn việc dở dang, Lean bỏ phần không tạo giá trị.
• Không phương pháp nào thay được kỷ luật cơ bản: mục tiêu rõ, mỗi việc một người chịu trách nhiệm, vài số đo đơn giản.

Chọn phương pháp là chọn lúc nào sai lầm lộ ra

Phương pháp quyết định ba thứ cụ thể: sai lầm lộ ra lúc nào, ai được đổi hướng và thước đo nào được coi là tiến độ thật. Dựng nhà theo bản vẽ đã duyệt thì sai ở móng lộ muộn mà sửa rất đắt, nên cần kiểm soát từ đầu. Làm ứng dụng khi chưa biết khách thích gì thì nguy cơ lớn nhất là làm đúng đặc tả một thứ không ai cần, nên phải cho người dùng xem sớm.

Phương pháp tốt không làm dự án bớt bất định; nó chỉ quyết định bạn phát hiện sai lầm vào tuần thứ hai hay tháng thứ tám.

Cách tiếp cận, phương pháp và kỹ thuật: các tầng hay bị gộp làm một

Phương pháp luận (methodology) là bộ nguyên tắc, quy trình, công cụ cho biết việc gì làm trước, việc gì làm sau; khung (framework) là cấu trúc rộng hơn để tổ chức tự lấp chi tiết. Nhiều tài liệu xếp tất cả vào một danh sách “phương pháp” dù chúng khác tầng: Scrum tự gọi là khung nhẹ [1], thác nước là mô hình vòng đời, đường găng và PERT là kỹ thuật lập lịch, Kanban và Lean là cách tối ưu dòng công việc (Hình 1). Một ranh giới khác chạy xuyên suốt bài: dự đoán (predictive) là lập kế hoạch gần đủ rồi làm, thích ứng (adaptive) là lập kế hoạch ngắn rồi sửa theo phản hồi.

Thác nước: làm đúng thứ tự khi yêu cầu đã chốt

Thác nước (waterfall) đi tuần tự qua sáu bước: thu thập và phân tích yêu cầu, thiết kế, xây dựng, kiểm thử, đưa vào dùng, bảo trì; chỉ khi bước trước được duyệt thì bước sau mới bắt đầu. Cái được là đường cơ sở rõ về phạm vi, chi phí, tiến độ, tài liệu đủ dày để bàn giao cho người hay nhà thầu, và cột mốc dễ đo. Cách này hợp khi yêu cầu ổn định, hợp đồng hoặc quy định buộc chốt trước, và sửa muộn đắt hơn nhiều so với sửa sớm.

Nhiều người coi thác nước đã lỗi thời, nhưng thực tế phức tạp hơn. Bài báo năm 1970 của Winston Royce, thường được dẫn như sơ đồ chính thức đầu tiên của mô hình này, coi việc dồn kiểm thử về cuối là rủi ro và đề xuất thêm năm bước để giảm rủi ro; tên gọi “waterfall” có thể xuất hiện sớm nhất trong một bài năm 1976 của Bell và Thayer [2]. Gốc rễ không phải là có kế hoạch mà là phản hồi thật đến quá muộn. Cách chữa không nhất thiết là bỏ nó: đưa phần rủi ro nhất lên trước bằng bản mẫu, mời người dùng thật vào các cổng duyệt, chia sản phẩm thành vài đợt bàn giao.

Đường găng: bao giờ xong và việc nào không được trễ

Phương pháp đường găng (CPM, Critical Path Method) do Walker của DuPont và Kelley của Remington Rand tạo ra năm 1957 để lập lịch các dự án bảo trì lớn [3]. Bạn liệt kê việc, xác định thứ tự trước sau, ước lượng thời lượng rồi vẽ sơ đồ mạng. Lượt đi tính mốc sớm nhất mỗi việc có thể bắt đầu và kết thúc; lượt về tính mốc muộn nhất mà dự án chưa trễ; chênh lệch giữa hai mốc là độ dư (float), tức số ngày việc đó được trễ mà không làm trễ cả dự án. Việc có độ dư bằng không nằm trên đường găng, tức chuỗi việc nối tiếp dài nhất; độ dài chuỗi này quyết định thời gian ngắn nhất để xong cả dự án; các nhánh song song không cộng thêm.

Ví dụ giả định về mở một cửa hàng. Thiết kế mất 5 ngày, rồi ba nhánh chạy song song: thi công 10 ngày, xin giấy phép 12 ngày, đặt và nhận thiết bị 6 ngày. Lắp đặt 3 ngày cần thi công xong và thiết bị về; nghiệm thu 2 ngày cần cả giấy phép lẫn lắp đặt. Chuỗi thiết kế, thi công, lắp đặt, nghiệm thu dài 20 ngày nên là đường găng; nhánh giấy phép dài 19 ngày, dư 1 ngày; nhánh thiết bị dài 16 ngày, dư 4 ngày. Giấy phép chậm thêm 2 ngày thì nhánh đó thành đường găng mới và dự án mất 21 ngày (Hình 2).

Muốn rút ngắn dự án, chỉ rút việc trên đường găng mới có tác dụng: thêm người hay tiền cho việc găng (crashing), hoặc cho các việc vốn nối tiếp chạy gối đầu nhau (fast-tracking) với cái giá là nguy cơ làm lại; mỗi lần rút, đường găng có thể chuyển nhánh nên phải tính lại. Kỹ thuật này mặc định nguồn lực đủ, trong khi hai việc song song cần cùng một người thì không song song được thật.

PERT: nói thật về độ bất định của ước lượng

PERT (Program Evaluation and Review Technique, tức kỹ thuật đánh giá và rà soát chương trình) do một nhóm thuộc Cục Dự án Đặc biệt của Hải quân Mỹ phát triển cho chương trình tên lửa Polaris vào cuối thập niên 1950 [3][4]; một bài tổng quan của PMI nhận xét khác biệt đặc thù giữa PERT và CPM đã phần lớn biến mất [3]. Mỗi việc có ba ước lượng: lạc quan (O), khả dĩ nhất (M), bi quan (P). Thời gian kỳ vọng là (O + 4M + P) / 6, độ lệch chuẩn xấp xỉ (P - O) / 6; công thức dựa trên phân phối beta điều chỉnh nên chỉ là xấp xỉ [4].

Ví dụ giả định: O là 6 ngày, M là 9, P là 18. Kỳ vọng là (6 + 36 + 18) / 6 = 10 ngày, độ lệch chuẩn là 2 ngày. Kỳ vọng dài hơn con số khả dĩ nhất vì đuôi chậm dài hơn đuôi nhanh, điều mà lời hứa 9 ngày đã lờ đi. Nếu coi các việc nối tiếp là độc lập, cộng kỳ vọng và phương sai dọc đường găng rồi dùng xấp xỉ chuẩn, hạn bằng kỳ vọng cộng một độ lệch chuẩn cho xác suất xong khoảng 84%.

Điểm yếu lớn nhất là thiên lệch tại nơi các nhánh hội tụ: dự án chỉ xong khi mọi nhánh xong, nhưng PERT chỉ nhìn đường găng và bỏ qua các nhánh gần găng; bài tổng quan của Mosaic Projects kết luận dự báo của PERT luôn lạc quan [4]. Trong ví dụ cửa hàng, nhánh 20 ngày và nhánh 19 ngày cùng đổ vào bước nghiệm thu, nên xác suất xong trong 20 ngày thấp hơn xác suất của từng nhánh xét riêng.

Scrum: kiểm tra hướng đi sau mỗi nhịp ngắn

Scrum dựa trên ba trụ cột của quy trình thực nghiệm: minh bạch, kiểm tra, thích ứng [1]. Công việc chia thành các Sprint, nhịp cố định dài tối đa một tháng, chứa mọi sự kiện khác [1]. Theo Scrum Guide 2020, các sự kiện gồm lập kế hoạch Sprint, Scrum hằng ngày 15 phút cho các Developers, rà soát Sprint với các bên liên quan và nhìn lại Sprint để cải tiến; với Sprint một tháng, ba sự kiện không diễn ra hằng ngày dài tối đa lần lượt 8, 4 và 3 giờ [1].

Đội Scrum gồm ba vai trò, thường không quá 10 người và không có đội con hay thứ bậc [1]. Product Owner (chủ sản phẩm) chịu trách nhiệm tối đa hoá giá trị sản phẩm và quản lý danh mục việc; đó là một người, không phải ủy ban [1]. Scrum Master chịu trách nhiệm thiết lập Scrum đúng như hướng dẫn [1]. Developers cam kết tạo ra mọi phần của một bản sản phẩm dùng được mỗi Sprint; cả đội tự quản lý, tức tự quyết ai làm gì, khi nào, ra sao [1].

Mỗi vật phẩm đi kèm một cam kết để khỏi mơ hồ: danh mục việc sản phẩm (Product Backlog) có mục tiêu sản phẩm, danh mục việc của Sprint (Sprint Backlog) có mục tiêu Sprint, bản tăng trưởng (Increment) có định nghĩa “xong” [1]. Ví dụ giả định cho một chuỗi gara làm ứng dụng đặt lịch bảo dưỡng xe: mục tiêu sprint đầu là khách đặt được một lịch thử ở hai gara; định nghĩa “xong” gồm đã chạy trên hai loại điện thoại và nhân viên tiếp nhận ở gara đã dùng thử. Scrum yếu đi khi đội phân tán, người quyết định ưu tiên vắng mặt hoặc nhiều đội phụ thuộc nhau mà thiếu điều phối.

Kanban: giữ dòng việc chảy bằng cách giới hạn việc dở dang

Kanban gốc là tấm thẻ tín hiệu cho phép sản xuất hoặc rút hàng trong hệ thống kéo; tiếng Nhật nghĩa là “biển hiệu” [5]. Trong công việc tri thức, Kanban Guide bản tháng 5/2025 nêu ba thực hành: xác định và trực quan hoá luồng công việc, chủ động quản lý các mục trong luồng, cải tiến luồng [6]. Bảng Kanban chỉ là hình thức: cột là chặng quy trình, thẻ là việc, làn bơi tách loại việc hay mức ưu tiên.

Bốn số đo cốt lõi: WIP (work in progress, việc đang làm dở) là số việc đã bắt đầu nhưng chưa xong; thông lượng (throughput) là số việc xong trong một đơn vị thời gian; thời gian chu trình (cycle time) tính từ lúc bắt đầu đến lúc xong; tuổi việc (work item age) tính từ lúc bắt đầu đến hôm nay [6]. Khi WIP xuống dưới mức kiểm soát nhóm đã đặt, đó có thể là tín hiệu để chọn việc mới [6].

Giới hạn WIP có lý lẽ toán học đơn giản. Định luật Little (John Little chứng minh năm 1961) nói rằng với hệ thống ổn định, số mục trung bình trong hệ thống bằng tốc độ vào nhân với thời gian trung bình mỗi mục ở lại [7]. Áp vào công việc, thời gian chờ trung bình xấp xỉ WIP chia thông lượng (suy luận của bài). Ví dụ giả định: bộ phận xử lý đơn xong 6 việc mỗi tuần và giữ 18 việc dở dang thì mỗi việc mất khoảng 3 tuần; giữ WIP ở 12, thông lượng vẫn 6, còn 2 tuần.

Kanban hợp với việc đến liên tục và ưu tiên đổi hằng ngày như hỗ trợ khách, bảo trì, xử lý đơn, vì không phải chờ hết sprint mới đổi hướng; đổi lại, nó không tự cho cam kết ngày giao. Bảng chỉ có giá trị khi trung thực: thẻ bị chặn phải ghi rõ lý do.

Lean: tìm và bỏ phần việc không tạo giá trị

Lean là cách nghĩ về tạo ra giá trị cần thiết với ít nguồn lực và ít lãng phí hơn, luôn bắt đầu từ khách hàng [8]. Lãng phí (muda) là hoạt động tốn nguồn lực mà không tạo giá trị cho khách [9]; khái niệm này gắn với hệ thống sản xuất Toyota, nơi một trụ cột là nguyên lý đúng lúc: chỉ làm thứ cần, vào lúc cần, với số lượng cần [10]. Tám dạng lãng phí thường gặp, đặt vào bối cảnh dự án:

• Chờ đợi: việc nằm chờ duyệt hay chờ thông tin.
• Tồn đọng: việc dở dang chất đống, tài liệu soạn sớm hơn cần.
• Làm thừa: tính năng hay báo cáo không ai yêu cầu.
• Xử lý thừa: tầng duyệt hay chi tiết vượt nhu cầu khách.
• Lỗi và làm lại: sửa sai, họp lại.
• Chuyển giao: mỗi lần giao việc dễ mất ngữ cảnh.
• Thao tác thừa: nhập lại dữ liệu giữa các công cụ không nối nhau.
• Bỏ phí năng lực: giao việc trái chuyên môn.

Công cụ trung tâm là sơ đồ chuỗi giá trị (value stream mapping): vẽ từng bước từ khi nhận yêu cầu đến khi giao kết quả, ghi thời gian làm thật và thời gian chờ, loại bước không tạo giá trị, thiết kế trạng thái mong muốn rồi theo dõi. Ví dụ giả định: một đề nghị mua sắm mất 15 ngày từ lúc gửi đến lúc duyệt nhưng người duyệt thực làm việc 2 ngày; 13 ngày còn lại là chờ, nên bớt một tầng duyệt hiệu quả hơn việc giục người duyệt.

Đi kèm là 5S (sàng lọc, sắp xếp, sạch sẽ, chuẩn hoá, duy trì), sự kiện kaizen ngắn, quy trình chuẩn và quản lý trực quan. Cái giá là đào tạo ban đầu và đổi thói quen; Lean phản tác dụng khi chỉ là đợt dọn dẹp do cấp trên phát động rồi bỏ dở.

Cách áp dụng từng bước

Ba câu hỏi đủ để chọn điểm xuất phát: yêu cầu chốt được đến đâu, sửa muộn đắt đến mức nào, việc đến theo dự án hay theo dòng liên tục. Hình 6 đặt bốn cách tiếp cận cạnh nhau; dự án thật thường dùng nhiều thứ cùng lúc nên các bước dưới đây chỉ là trình tự gợi ý.

• Bước 1: Viết ra mục tiêu, ngày kết thúc cứng nếu có và các ràng buộc không đổi được như hợp đồng, giấy phép, ngân sách.
• Bước 2: Tách phần đã rõ khỏi phần nhiều ẩn số; phần rõ đi theo kế hoạch, phần ẩn số chia thành các vòng thử ngắn.
• Bước 3: Với phần có ngày cứng, lập sơ đồ mạng gồm cả việc duyệt, cấp phép, thanh toán; tính đường găng và đánh dấu nhánh chỉ dư vài ngày.
• Bước 4: Với vài việc rủi ro nhất, xin ba ước lượng từ người trực tiếp làm, hỏi con số bi quan trước để khỏi neo vào con số đẹp.
• Bước 5: Chọn nhịp cho phần nhiều ẩn số: Scrum khi có đội ổn định và một người quyết định ưu tiên; Kanban khi việc đến liên tục.
• Bước 6: Mỗi tuần chỉ xem ba số đo: độ dư của đường găng, số việc dở dang cùng thời gian chu trình, tỷ lệ việc làm lại.
• Bước 7: Cuối mỗi sprint hoặc hai tuần, họp nhìn lại và chọn một lãng phí để bỏ.

Ví dụ quốc tế: PERT, tiếng tăm và thực tế ở chương trình Polaris

Bài tổng quan “Understanding PERT” của Mosaic Projects ghi nhận PERT được ca ngợi là đã tiết kiệm hai năm cho chương trình Polaris, nhưng cũng cho biết kỹ thuật này không được dùng rộng trong chính chương trình mà được quảng bá mạnh để người đứng đầu quản lý môi trường bên ngoài [4]. Bài không kiểm chứng con số hai năm. Bài học: tiếng tăm chưa chứng minh hiệu quả; hãy tự đo trên dự án của bạn.

Tình huống áp dụng tại Việt Nam

Về tiến độ xây dựng, một nghiên cứu trên Tạp chí Khoa học và Công nghệ Trường Đại học Thành Đông (số 9, 2023) dùng khảo sát và phương pháp Delphi năm vòng để tìm nguyên nhân chậm tiến độ của dự án đầu tư xây dựng tại Việt Nam [11]. Sau các vòng Delphi còn 46 nguyên nhân, trong đó 12 thuộc nhóm triển khai thi công; 34 nguyên nhân khác nằm ở pháp lý, thiết kế, hợp tác giữa các bên, nghiệm thu, thanh toán và yếu tố khách quan [11]. Bài không nêu số chuyên gia tham gia và không xếp hạng ảnh hưởng; suy ra của bài: đưa duyệt pháp lý, thiết kế, nghiệm thu, thanh toán vào sơ đồ mạng như việc có thời lượng và người chịu trách nhiệm.

Về Agile trong phát triển phần mềm tại Việt Nam, một luận văn năm 2014 của Đại học Khoa học Ứng dụng Lahti (Phần Lan) phỏng vấn bán cấu trúc ở một số công ty được chọn: động lực lớn nhất là hạn chế của quy trình cũ; trở ngại khó nhất là kiến thức nhân viên, hợp tác và giao tiếp trong đội, cùng vấn đề quản lý; quá trình áp dụng gồm bốn giai đoạn quyết định, lập kế hoạch, đào tạo, thử nghiệm [12]. Tóm tắt không nêu cỡ mẫu.

Về Lean, trang VCCI ngày 4/4/2026, dẫn lại Báo Công Thương, thuật lại Công ty May Hưng Nhân: sau 6 tháng triển khai, hàng tồn trên chuyền giảm 75%, thời gian xử lý đơn rút ngắn, năng suất tăng khoảng 25-30% [13]. Hàng tồn trên chuyền chính là dạng lãng phí tồn đọng. Bài không nêu cách đo, nhưng nêu lý do cải tiến hay thất bại: thiếu chuẩn bị, lãnh đạo thiếu cam kết hoặc làm quá ngắn hạn [13].

Về cải tiến liên tục, ông Nguyễn Văn Tuấn, Phó Tổng giám đốc Tổng công ty Đức Giang, cho Tạp chí Công Thương (13/9/2019) biết năm 2013 đơn vị lập Ban cải tiến để triển khai Lean; những năm đầu áp dụng, năng suất tăng 15-25%, nay duy trì 5-10% mỗi năm [14]. Số liệu do lãnh đạo tự nêu và đã cũ, nhưng khớp với hình dạng quen thuộc của kaizen: bước nhảy đầu lớn, sau đó nhỏ mà đều.

Sai lầm thường gặp, giới hạn và khi nào không nên dùng

• Dùng thác nước cho phần còn nhiều ẩn số rồi coi thay đổi là lỗi của khách.
• Tính đường găng một lần rồi không cập nhật, hoặc lập sơ đồ mạng chỉ gồm việc thi công, bỏ duyệt, cấp phép, thanh toán.
• Dùng ba ước lượng nhưng cộng kết quả như thể các nhánh độc lập.
• Gọi là Scrum nhưng không có người quyết định ưu tiên, hoặc coi sprint là kế hoạch thác nước cắt nhỏ.
• Đặt giới hạn WIP quá thấp, hoặc lách bằng cách thêm cột và để thẻ bị chặn nằm im.
• Làm Lean như dọn dẹp bề mặt, không đo thời gian chờ, thiếu cam kết của lãnh đạo.

Kế hoạch thử nghiệm 2 đến 4 tuần

• Tuần 1: Chọn một dự án đang chạy; lập danh sách việc, thứ tự trước sau, thời lượng (có thể dùng mẫu cấu trúc phân rã công việc và lịch Gantt trong bộ biểu mẫu in đi kèm tài liệu nguồn); tính đường găng và các nhánh dư dưới vài ngày.
• Tuần 2: Xin ba ước lượng cho ba việc rủi ro nhất; so con số kỳ vọng với con số đội vẫn hứa.
• Tuần 3: Dựng bảng Kanban cho nhóm việc hay tắc nhất; đặt giới hạn việc dở dang và đo thời gian chu trình.
• Tuần 4: Họp nhìn lại; chọn một lãng phí để bỏ và ghi con số nào đã làm đổi một quyết định.

Kết luận

Sáu công cụ trong phần này giải những bài toán khác nhau nên bổ sung hơn là thay thế nhau: thác nước và đường găng giữ thứ tự và ngày kết thúc, PERT làm lộ bất định, Scrum và Kanban giữ phản hồi và dòng chảy, Lean bớt phần thừa. Phần tiếp theo bàn về tầng cao hơn: khung lai như PRINCE2 và PMBOK kết hợp Agile, khung theo ngành như ITIL, COBIT, xây dựng, y tế, văn phòng quản lý dự án, cách chọn khung bằng bảng chấm điểm và cách triển khai.

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

Bài này là tổng hợp và phân tích có hỗ trợ trí tuệ nhân tạo, được diễn đạt lại bằng lời riêng, không phải bản dịch hay bản tóm tắt theo chương. Kiến thức khung dựa trên tài liệu Project Management Frameworks (Super Guide của Daniel Pereira, The Business Model Analyst, 2022), phần đầu từ trang 1 đến trang 79, cùng bộ biểu mẫu in Printable Project Management Sheets của The Biz Sheets đi kèm; các phép tính minh hoạ, đối chiếu với Scrum Guide 2020 và Kanban Guide 2025, cách phân tầng và các ví dụ do bài bổ sung. Bạn nên tìm tài liệu gốc để đọc đầy đủ.

Các nguồn web được truy cập ngày 20/10/2026. Điều chưa kiểm chứng: lịch sử mô hình thác nước và vai trò của Royce lấy từ một trang tổng hợp, chưa đọc bài gốc năm 1970; năm ra đời chính xác của PERT các nguồn không thống nhất nên bài chỉ nêu cuối thập niên 1950; con số tiết kiệm hai năm của Polaris chỉ được thuật lại; số liệu của hai công ty may do báo đăng, không rõ cách đo; luận văn năm 2014 chỉ đọc phần tóm tắt; nghiên cứu năm 2023 không nêu cỡ mẫu; mọi ví dụ có số trong phần ước lượng, Scrum, Kanban và Lean là giả định.