Phân tích đường găng (Critical Path): Hướng dẫn dành cho nhà quản lý dự án

Hãy thử tưởng tượng bạn là PM và team của bạn đã sẵn sàng training khách hàng, nhưng tài liệu hướng dẫn chưa được pháp chế duyệt. Dù là một điểm nghẽn nhỏ nhưng lại làm chậm cả chuỗi công việc phía sau. Điều đó cho thấy việc xác định và kiểm soát các yếu tố ảnh hưởng đến tiến độ vẫn là thách thức với nhiều đội ngũ.

Câu trả lời ngắn: nếu muốn biết dự án nhanh nhất có thể hoàn thành khi nào, và việc nào thật sự quyết định deadline, nhà quản lý cần dùng Critical Path Method (CPM). Đây là cách phân tích tiến độ dựa trên phụ thuộc công việc nhằm biết chính xác đâu là những hạng mục cần ưu tiên và đâu là những phần việc có thể linh hoạt.

Định nghĩa ngắn: Critical Path Method (CPM) là gì?

Critical Path Method là phương pháp xác định chuỗi công việc quan trọng nhất, tức chuỗi công việc có tổng thời lượng dài nhất và ảnh hưởng trực tiếp đến thời gian hoàn thành dự án. Nếu một công việc trên chuỗi này bị chậm, toàn bộ dự án có thể bị chậm theo.

Chuỗi công việc đó được gọi là đường găng (critical path). Đây là cơ sở để xác định thời gian ngắn nhất mà dự án có thể hoàn thành. Không phải mọi công việc đều nằm trên đường găng; CPM chỉ tập trung vào những công việc ảnh hưởng trực tiếp đến tiến độ.

Để xác định đường găng, CPM sử dụng các thông tin như quan hệ phụ thuộc công việc và độ trễ cho phép (còn gọi là float). Float là khoảng thời gian một công việc có thể chậm mà không làm lùi ngày kết thúc dự án. Các công việc có float bằng 0 thường nằm trên đường găng và cần được theo dõi sát nhất vì không có khoảng đệm thời gian.

CPM thường bị nhầm với biểu đồ Gantt. Gantt hữu ích để hiển thị lịch và giao tiếp tiến độ. CPM là lớp phân tích logic: việc nào phụ thuộc việc nào, tổng thời lượng tối thiểu là bao nhiêu, và nếu trễ ở đâu thì deadline bị ảnh hưởng ra sao.

Vì sao quy trình lập tiến độ thường bị sai hoặc gãy?

Lỗi đầu tiên là danh sách task (công việc) không đủ chi tiết. Kế hoạch ghi “hoàn thiện hệ thống”, “chuẩn bị go-live”, “triển khai khách hàng” nghe có vẻ đầy đủ, nhưng quá lớn để ước lượng và theo dõi. Khi task bị gộp như vậy, bạn sẽ không thấy phụ thuộc nằm ở đâu và ai đang chặn ai.

Lỗi thứ hai là ước lượng thời gian theo cảm tính. Nhiều team lấy số ngày dựa trên kinh nghiệm mơ hồ hoặc cam kết bán hàng, chứ không dựa trên năng lực người làm, số lượng đầu việc song song, thời gian chờ phản hồi hay các ràng buộc phê duyệt.

Một vấn đề khác là không cập nhật khi dự án thay đổi. Quy mô đổi, nhân sự đổi, nhà cung cấp (vendor) giao chậm, khách hàng phản hồi chậm đều có thể làm thay đổi tiến độ. Nếu mạng lưới công việc không được cập nhật, đường găng ban đầu nhanh chóng mất giá trị.

Hãy lấy một ví dụ đơn giản. Một công ty lên kế hoạch tổ chức hội thảo trong 4 tuần và tạo một task chung là "chuẩn bị hội thảo". Đến 5 ngày trước sự kiện, đội ngũ mới phát hiện địa điểm vẫn chưa ký hợp đồng và diễn giả chính chưa xác nhận tham gia. Dù báo cáo tiến độ cho thấy công việc đã hoàn thành 80%, sự kiện vẫn có nguy cơ bị hoãn vì các phụ thuộc quan trọng đã bị che khuất trong một task quá lớn và không được cập nhật kịp thời.

Bảng lập kế hoạch đường găng: mốc, đệm, phụ thuộc

Nhập email của bạn để nhận hướng dẫn chi tiết từng bước

Tôi xác nhận rằng tôi đã đọc và hiểu Chính sách quyền riêng tư Bitrix24

Quy trình 7 bước phân tích và theo dõi đường găng trong dự án

Để phân tích đường găng hiệu quả, dự án cần thực hiện một số bước từ xây dựng mạng lưới công việc đến tính toán và theo dõi đường găng.

Bước 1: Liệt kê toàn bộ công việc cần để hoàn thành dự án

Bắt đầu bằng việc chia dự án thành các đầu việc đủ nhỏ để có thể ước lượng, giao trách nhiệm và xác định trạng thái hoàn thành. Nếu một task mất ba tuần, có ba người cùng làm nhưng không ai mô tả rõ đầu ra, task đó vẫn quá lớn.

Một cách làm thực tế là đi từ đầu ra (deliverable) ngược lên. Ví dụ, để “go-live hệ thống CRM”, bạn cần tích hợp dữ liệu, kiểm thử người dùng, đào tạo, cấu hình phân quyền, tích hợp email, duyệt bảo mật. Từ mỗi hạng mục, tiếp tục bóc tách đến mức có thể giao cho một người chịu trách nhiệm chính (owner) cụ thể.

Đồng thời, mỗi công việc nên có hai thông tin tối thiểu: điểm bắt đầu và đầu ra hoàn thành. Đây cũng là giai đoạn nhiều team đưa kế hoạch lên các nền tảng quản lý tác vụ như Bitrix24 để dễ theo dõi trách nhiệm và thông tin cụ thể.

Trước khi chuyển sang bước tiếp theo, hãy tạo một checklist ngắn rà soát lại toàn bộ công việc:

• Mỗi task có owner cụ thể chưa?
• Đã có tiêu chí hoàn thành rõ ràng chưa?
• Task này có thể ước lượng thời lượng tương đối đáng tin chưa?
• Có task nào thực chất là cột mốc phê duyệt không?
• Có dữ liệu nào bị trùng lặp, mơ hồ hoặc chồng lấn không?
• Có phần việc nào bị bỏ sót vì thuộc về nhà cung cấp (vendor), khách hàng hoặc bộ phận khác không?

Bước 2: Xác định phụ thuộc và vẽ mạng lưới công việc

Sau khi có danh sách việc, bước tiếp theo là xác định quan hệ phụ thuộc: việc nào bắt buộc phải xong trước, việc nào có thể chạy song song, và việc nào chỉ cần một phần đầu ra để bắt đầu.

Bạn có thể bắt đầu bằng sơ đồ đơn giản, trong đó mỗi nút đại diện cho một công việc và các mũi tên thể hiện mối quan hệ trước - sau. Mục tiêu là giúp dự án nhìn thấy toàn bộ luồng công việc thay vì chỉ theo dõi một danh sách đầu việc riêng lẻ.

Đặc biệt, hãy kiểm tra các phụ thuộc “do thói quen”. Ví dụ, training có thể bắt đầu sớm hơn dựa trên bản draft ổn định 80%, thay vì chờ toàn bộ tài liệu hoàn tất.

Bước 3-5: Ước lượng thời lượng, tính đường găng và xác định độ trễ cho phép

Tiếp theo là gán thời lượng cho từng công việc. Đừng lấy số ngày kiểu “chắc khoảng 2-3 ngày” nếu bạn chưa xét năng lực thực tế, lịch nghỉ, thời gian chờ phản hồi, hoặc việc người đó đang ôm nhiều dự án cùng lúc. Thời lượng trong CPM nên phản ánh điều kiện thực tế của dự án.

Nguồn ước lượng tốt nhất là dữ liệu lịch sử từ các dự án tương tự. Nếu chưa có, hãy lấy ý kiến owner trực tiếp và buộc họ tách phần việc đủ rõ trước khi chốt số. Với hạng mục rủi ro cao, nên ghi chú giả định đi kèm.

Sau đó, thực hiện hai bước tính cơ bản:

1. Tính xuôi (Forward pass): tính thời điểm sớm nhất mỗi công việc có thể bắt đầu và kết thúc, dựa trên các phụ thuộc trước đó.
2. Tính ngược (Backward pass): đi ngược từ mốc hoàn thành dự án để tính thời điểm muộn nhất mỗi công việc có thể bắt đầu và kết thúc mà không làm trễ toàn dự án.

Từ đây, bạn tính được float cho từng công việc:

Float = Late Start - Early Start hoặc Late Finish - Early Finish

Trong đó:

• Early Start (ES): Thời điểm sớm nhất có thể bắt đầu.
• Early Finish (EF): Thời điểm sớm nhất có thể hoàn thành.
• Late Start (LS): Thời điểm muộn nhất có thể bắt đầu mà không làm trễ dự án.
• Late Finish (LF): Thời điểm muộn nhất có thể hoàn thành mà không làm trễ dự án.

Nghe có vẻ phức tạp, nhưng có thể hình dung qua ví dụ dưới đây:

Giả sử dự án bắt đầu từ ngày 0. Khi tính xuôi, task A hoàn thành vào ngày thứ 3. Vì cả B và C đều phụ thuộc vào A nên hai công việc này có thể bắt đầu từ ngày thứ 3. B hoàn thành vào ngày thứ 8, C hoàn thành vào ngày thứ 7. Cứ như vậy, thời gian hoàn thành sớm nhất của dự án là 14 ngày.

Ngược lại, khi tính ngược từ mốc hoàn thành dự án là ngày thứ 14, task E phải bắt đầu chậm nhất vào ngày thứ 12. Do D mất 4 ngày để thực hiện và phải hoàn thành trước E, D phải bắt đầu chậm nhất vào ngày thứ 8. Cách tính này giúp xác định mỗi công việc còn bao nhiêu thời gian dự phòng trước khi bắt đầu ảnh hưởng đến tiến độ chung.

Trong ví dụ này, chuỗi A → B → D → E là đường găng vì tất cả các công việc đều có float bằng 0. Nếu một trong các công việc này bị chậm, ngày hoàn thành dự án cũng sẽ bị lùi theo. Ngược lại, task C có float bằng 2 ngày nên có thể chậm tối đa 2 ngày mà chưa ảnh hưởng đến tiến độ chung.

Tuy nhiên, float không đồng nghĩa với việc có thể trì hoãn tùy ý, đặc biệt khi các công việc sử dụng chung nguồn lực hoặc phụ thuộc lẫn nhau.

Bước 6-7: Tối ưu lịch, theo dõi thay đổi và cập nhật đường găng

Khi đã biết đường găng, bạn mới có cơ sở để rút ngắn tiến độ có chủ đích. Hai kỹ thuật thường gặp là crashing (bổ sung thêm nguồn lực hoặc chi phí để giảm thời lượng thực hiện) và fast-tracking (thực hiện chồng lấn một số đầu việc thay vì theo trình tự tuần tự).

Tuy nhiên, hai kỹ thuật này đều đi kèm những đánh đổi nhất định. Chẳng hạn, việc bổ sung thêm nhân sự để giảm thời gian triển khai có thể làm tăng chi phí phối hợp và phát sinh thêm lỗi. Ví dụ, để rút ngắn một hạng mục từ 20 ngày xuống còn 15 ngày, dự án có thể phải tăng số lập trình viên từ 2 lên 4 người. Tiến độ được cải thiện ~25%, nhưng chi phí nhân sự gần như tăng gấp đôi.

Như vậy, chỉ nên tối ưu trên các công việc đang nằm trên đường găng hoặc có khả năng trở thành đường găng mới. Đẩy nhanh một task có float lớn thường không giúp dự án về đích sớm hơn.

Sau khi dự án chạy, nên thiết lập nhịp cập nhật cố định: theo tuần với dự án vừa, theo ngày hoặc 2–3 ngày với giai đoạn cao điểm. Mỗi lần cập nhật, cần kiểm tra ba điểm:

• Thời lượng thực tế có lệch nhiều so với ước lượng không?
• Có phụ thuộc mới phát sinh hoặc thay đổi thứ tự thực hiện không?
• Đường găng hiện tại có còn giống kế hoạch gốc (baseline) không?

Lúc này CPM trở thành công cụ ra quyết định. Chẳng hạn, nếu vendor giao chậm API 5 ngày và task đó chuyển thành điểm găng, PM có thể ưu tiên phương án tạm như đổi thứ tự triển khai hoặc đẩy nhanh khâu kiểm thử ở nhánh khác để đảm bảo deadline.

Trong phần lớn trường hợp, dự án chỉ cần cập nhật tiến độ và đảm bảo đường găng. Tuy nhiên, nếu xuất hiện những thay đổi lớn như mở rộng phạm vi, điều chỉnh mốc nghiệm thu, thay đổi cam kết hợp đồng hoặc tăng/giảm đáng kể về nhân sự, nên cân nhắc thiết lập lại kế hoạch gốc (re-baseline) để tính lại đường găng và phản ánh đúng trạng thái mới của dự án.

"Bitrix24 là phần mềm phù hợp nhất cho nhu cầu của chúng tôi."

Vice Director, Mr. Pham Xuan Tung

IT Dept., Saigon Newport Corporation

Đăng ký miễn phí

3 sai lầm thường gặp và lưu ý để duy trì CPM hiệu quả khi dự án mở rộng quy mô

Lỗi hay gặp nhất là coi gần như mọi việc đều là găng. Khi team gắn nhãn ưu tiên cao (critical) cho quá nhiều task, CPM mất tác dụng ưu tiên. Đường găng phải được xác định bằng logic thời gian và phụ thuộc, không phải bằng mức độ lo lắng của từng bộ phận.

Lỗi thứ hai là bỏ qua milestone phê duyệt. Trong nhiều dự án tại Việt Nam, thời gian chờ ký duyệt, phản hồi khách hàng, xác nhận từ bảo mật hoặc mua sắm có thể dài hơn cả phần thực thi. Nếu không đưa các điểm chờ này vào mạng lưới công việc, lịch sẽ sai ngay từ đầu.

Một lỗi nữa là không tính phụ thuộc ngoài nhóm dự án. Nhà cung cấp, đối tác tích hợp, khách hàng đầu mối, thậm chí ban giám đốc đều có thể tạo ra điểm nghẽn. Nếu lịch chỉ phản ánh phần việc nội bộ, CPM sẽ cho cảm giác kiểm soát giả.

Khi dự án lớn hơn, nên chuẩn hóa ba thứ:

• Cấu trúc phân rã công việc (WBS - Work breakdown structure): cùng một loại dự án nên có khung bóc tách việc tương đối thống nhất.
• Quy tắc đặt phụ thuộc: cần thống nhất cách xử lý các điểm phê duyệt, bàn giao hoặc phối hợp liên phòng ban.
• Chu kỳ cập nhật: quy định rõ ai cập nhật, cập nhật khi nào, và trạng thái nào được xem là hoàn thành.

Ở quy mô lớn, phần mềm quản lý dự án gần như là bắt buộc. Lựa chọn một công cụ phù hợp giúp lưu trữ kế hoạch, theo dõi sai lệch và tái tính đường găng khi dữ liệu thay đổi.

Cũng cần lưu ý rằng CPM không phải lúc nào cũng cho kết quả chính xác và hiệu quả. Phương pháp này hoạt động tốt nhất khi phạm vi công việc ổn định, các phụ thuộc được xác định rõ và dữ liệu được cập nhật thường xuyên. Ngược lại, kết quả tính toán sẽ dễ bị sai lệch hoặc không phù hợp với thực tế.

FAQ và kết luận: Những câu hỏi thực tế trước khi áp dụng CPM

Có thể quản lý đường găng bằng Excel không?

Excel vẫn đủ dùng cho các dự án nhỏ khi mới làm quen với CPM. Tuy nhiên, khi dự án có nhiều nhánh song song, vendor ngoài và nhu cầu cập nhật thường xuyên, nên chuyển sang công cụ chuyên dụng như Bitrix24 để tránh lỗi công thức và khó kiểm soát phiên bản.

Bao lâu nên cập nhật đường găng một lần?

Với dự án kéo dài vài tháng, cập nhật hàng tuần là mức tối thiểu. Giai đoạn sát go-live hoặc có nhiều phụ thuộc bên ngoài thì nên cập nhật thường xuyên hơn, chẳng hạn như 2-3 ngày/lần.

Nếu thiếu dữ liệu thời lượng thì ước lượng thế nào?

Có thể tham khảo dữ liệu từ các dự án tương tự, thời gian xử lý trong quá khứ hoặc ý kiến từ người trực tiếp thực hiện công việc. Nếu vẫn mơ hồ, ghi rõ giả định và cập nhật lại sau vài tuần đầu khi có thêm dữ liệu thực tế.

Dự án Agile có áp dụng CPM được không?

Có. CPM vẫn có thể được áp dụng trong các dự án Agile để quản lý các milestone hoặc phụ thuộc quan trọng như triển khai hạ tầng, mua sắm hoặc phê duyệt. Tuy nhiên, do Agile cho phép thay đổi ưu tiên và phạm vi công việc liên tục, CPM thường được sử dụng ở cấp độ kế hoạch tổng thể thay vì để quản lý chi tiết từng sprint.

Làm sao quản lý phụ thuộc với nhà cung cấp ngoài?

Đưa họ vào mạng lưới công việc như một phần của dự án. Mỗi đầu mục cần có người theo dõi, thời hạn cam kết, khoảng dự phòng hợp lý và cơ chế xử lý khi tiến độ bị chậm.

Khi nào nên tính lại đường găng từ đầu?

Khi có thay đổi lớn về quy mô, nguồn lực chủ chốt rời dự án, hoặc một phụ thuộc quan trọng bị trễ đáng kể. Khi đó, cần rà soát lại cả mạng lưới thay vì chỉ sửa vài task riêng lẻ.

Kết luận

Điểm đáng giá nhất của phương pháp phân tích đường găng (CPM) không nằm ở việc tạo ra một bản kế hoạch chi tiết, mà ở khả năng chỉ ra đâu là những công việc thực sự quyết định thời hạn hoàn thành dự án.

Nếu chưa từng áp dụng, hãy bắt đầu bằng một dự án nhỏ. Liệt kê công việc, xác định phụ thuộc, gán thời lượng và chọn một công cụ quản lý dự án linh hoạt như Bitrix24 để xây dựng kế hoạch đầu tiên. Chỉ cần thực hiện một lần nghiêm túc, bạn sẽ có cái nhìn rõ hơn về cách tiến độ thực sự vận hành thay vì chỉ theo dõi các mốc thời gian trên giấy.