Trong dự án xây dựng, tiến độ thường được nhìn như một bảng ngày bắt đầu, ngày kết thúc và phần trăm hoàn thành. Cách nhìn này khiến tiến độ dễ bị biến thành một tài liệu để báo cáo hơn là một công cụ để điều hành. Một bản tiến độ có thể rất đẹp, có hàng nghìn công việc và được cập nhật đều đặn, nhưng vẫn không giúp ban điều hành trả lời được những câu hỏi quan trọng nhất: công việc nào thực sự đang quyết định ngày hoàn thành, điều kiện nào đang làm suy giảm khả năng thực hiện, sai lệch hiện tại sẽ lan truyền đến đâu và dự án cần can thiệp vào đâu trước.

Bài “Quản lý dự án xây dựng: Từ kế hoạch tổng thể đến kiểm soát thực thi tại công trường” đã đặt tiến độ trong hệ thống kiểm soát dự án; Bài “AI có thể dự báo chậm tiến độ dự án xây dựng như thế nào?” đi sâu vào khả năng nhận diện sớm nguy cơ chậm bằng AI. Nội dung bài này chúng ta sẽ quay trở lại nền tảng cốt lõi: nếu bản tiến độ không phản ánh đúng phạm vi, logic thực hiện và dữ liệu hiện trường, mọi lớp phân tích phía trên — từ bảng điều hành đến AI — đều có nguy cơ cho ra một bức tranh sai. Vì vậy, quản lý tiến độ phải được hiểu là một vòng liên tục gồm lập kế hoạch, phê duyệt đường cơ sở, ghi nhận thực tế, tính lại dự báo, phân tích sai lệch và tổ chức hành động.

Điểm khó của quản lý tiến độ không nằm ở thao tác phần mềm. Nó nằm ở việc biến một dự án phức tạp thành mô hình đủ rõ để điều hành, sau đó giữ cho mô hình đó liên tục phản ánh thực tế. Khi làm được điều này, tiến độ trở thành ngôn ngữ chung giữa chủ đầu tư, tư vấn, nhà thầu, bộ phận thiết kế, mua sắm và hiện trường.

1. Tiến độ thi công thực chất là mô hình logic của dự án

Một bản tiến độ tốt trước hết phải trả lời được dự án sẽ được thực hiện theo logic nào. Ngày tháng chỉ là kết quả của logic đó. Khi một công việc có thời lượng mười ngày, người lập tiến độ phải hiểu mười ngày được hình thành từ khối lượng, năng suất, số tổ đội, ca làm việc và điều kiện mặt bằng nào. Khi một công việc bắt đầu sau công việc khác, quan hệ đó phải phản ánh một phụ thuộc kỹ thuật hoặc tổ chức thực sự, chứ không phải chỉ để phần mềm tạo ra một biểu đồ nhìn hợp lý.

Ví dụ, công tác trát tường không thể chỉ được nối với xây tường bằng một quan hệ máy móc. Ở từng khu vực, nó còn phụ thuộc vào thời gian chờ kỹ thuật, hoàn thành các phần cơ điện âm tường, nghiệm thu và khả năng bàn giao mặt bằng. Nếu những điều kiện này không được thể hiện hoặc quản lý ở một cấp kế hoạch phù hợp, tiến độ tổng thể có thể cho thấy công việc ‘đủ điều kiện bắt đầu’ trong khi hiện trường chưa thể thi công.

Vì vậy, chất lượng tiến độ phải được đánh giá từ bốn lớp: phạm vi có đầy đủ không; quan hệ trước–sau có đúng bản chất không; thời lượng có cơ sở không; và các mốc có phản ánh cam kết thực tế không. Một bản tiến độ thiếu một trong bốn lớp này có thể vẫn chạy được trên phần mềm nhưng giá trị điều hành sẽ giảm mạnh.

Hình 1. Tiến độ là mô hình logic của cách dự án được thực hiện

2. Muốn lập tiến độ tốt phải bắt đầu từ phạm vi và cấu trúc phân rã công việc

Không thể lập tiến độ đáng tin cậy nếu phạm vi dự án chưa được phân rã đủ rõ. Cấu trúc phân rã công việc (Work Breakdown Structure – WBS) là cách chia dự án thành những phần có thể quản lý được, chẳng hạn theo công trình, khu vực, tầng, bộ môn, gói thầu hoặc giai đoạn. Mục tiêu không phải tạo ra một cây mã thật phức tạp, mà tạo ra một cấu trúc đủ ổn định để tiến độ có thể liên kết với khối lượng, chi phí, hợp đồng và trách nhiệm.

Một lỗi thường gặp là chia tiến độ theo cách thuận tiện cho người lập kế hoạch nhưng không trùng với cách hiện trường tổ chức thi công. Khi đó, cán bộ hiện trường khó cập nhật; khối lượng nghiệm thu khó gắn vào công việc; còn báo cáo chi phí lại phải tổng hợp theo một hệ mã khác. Hệ quả là mỗi kỳ báo cáo cần nhiều bước quy đổi thủ công, làm tăng sai lệch và giảm khả năng truy nguyên.

Mức độ chi tiết cũng cần vừa đủ. Công việc quá lớn che giấu sai lệch: một hoạt động kéo dài ba tháng với phần trăm hoàn thành chung không cho biết khu vực nào đang tắc. Ngược lại, chia thành hàng chục nghìn công việc quá nhỏ khiến tiến độ nặng nề, khó cập nhật và dễ tạo ra dữ liệu giả chính xác. Quy tắc thực tế là mức chi tiết phải đủ để giao trách nhiệm, đo kết quả và phát hiện sai lệch, nhưng không vượt quá khả năng thu nhận dữ liệu thực tế của dự án.

3. Xây dựng logic trước–sau: phần khó nhất nhưng thường bị xem nhẹ

Quan hệ trước–sau là xương sống của tiến độ. Nếu logic yếu, việc tính đường găng, thời gian dự phòng và ngày hoàn thành sẽ thiếu tin cậy. Quan hệ kết thúc–bắt đầu thường dễ hiểu nhất: công việc sau chỉ bắt đầu khi công việc trước hoàn thành. Tuy nhiên, xây dựng có nhiều trường hợp chồng lấn, nên có thể cần các quan hệ bắt đầu–bắt đầu hoặc kết thúc–kết thúc. Điều quan trọng là mỗi quan hệ phải có lý do kỹ thuật rõ ràng.

Cần thận trọng với việc dùng thời gian chờ hoặc độ trễ để ‘ép’ ngày. Nếu một khoảng chờ thực sự là một quá trình có thể quản lý — chẳng hạn bảo dưỡng bê tông, phê duyệt hồ sơ, gia công thiết bị — việc biểu diễn nó thành một công việc riêng thường minh bạch hơn. Khi ẩn quá nhiều thời gian trong các quan hệ, người quản lý khó nhìn thấy nguyên nhân khi tiến độ thay đổi.

Tương tự, các ràng buộc ngày cứng chỉ nên dùng khi có một cam kết bên ngoài thực sự như ngày bàn giao bắt buộc hoặc thời điểm cấm thi công. Nếu dùng ràng buộc để giữ cho biểu đồ không bị dịch chuyển, bản tiến độ có thể che mất tác động của chậm trễ và tạo cảm giác sai rằng mốc vẫn an toàn. Tiến độ tốt phải cho phép logic phản ánh hậu quả thực, kể cả khi kết quả đó không đẹp.

4. Ước lượng thời lượng phải dựa trên khối lượng, năng suất và điều kiện thực hiện

Thời lượng không nên được chọn theo kinh nghiệm chung rồi điền vào phần mềm. Với các công việc có thể đo khối lượng, một cách tiếp cận tốt là bắt đầu từ khối lượng cần thực hiện, năng suất dự kiến, số tổ đội, số ca và điều kiện thi công. Cùng một khối lượng nhưng thi công ở tầng điển hình, tầng kỹ thuật hay khu vực hạn chế tiếp cận có thể cần thời lượng khác nhau.

Điểm quan trọng là phải phân biệt năng suất kế hoạch với năng suất thực tế. Năng suất kế hoạch là giả định dùng để xây dựng lịch; năng suất thực tế là bằng chứng dùng để kiểm tra giả định. Khi dự án đã chạy, nếu năng suất thực tế thấp hơn liên tục, phần thời lượng còn lại phải được đánh giá lại. Giữ nguyên thời lượng chỉ vì ‘đó là kế hoạch đã duyệt’ sẽ khiến dự báo ngày hoàn thành mất ý nghĩa.

Đối với các công việc không dễ quy đổi trực tiếp bằng khối lượng, doanh nghiệp có thể sử dụng dữ liệu lịch sử, ý kiến chuyên gia và các dự án tương tự. Nhưng mọi giả định quan trọng nên được ghi nhận để sau này có thể giải thích vì sao kế hoạch khác thực tế và cải thiện dữ liệu cho các dự án tiếp theo.

5. Đường cơ sở: chuẩn so sánh phải được bảo vệ nhưng không được thần thánh hóa

Sau khi phạm vi, logic, thời lượng, nguồn lực và các mốc đã được xem xét, dự án cần phê duyệt một đường cơ sở (baseline). Có thể hiểu đây là ảnh chụp của kế hoạch đã được chấp thuận tại một thời điểm, dùng làm chuẩn để so sánh với quá trình thực hiện. Tài liệu Oracle Primavera cũng mô tả đường cơ sở như trạng thái của dự án tại một thời điểm để đánh giá hiệu quả khi dự án tiến triển.

Giá trị của đường cơ sở nằm ở việc giữ lại ‘lời hứa ban đầu’. Nếu mỗi khi dự án chậm lại sửa đường cơ sở cho trùng với thực tế, tổ chức sẽ mất khả năng phân biệt giữa thay đổi mục tiêu và thực hiện kém. Tuy nhiên, đường cơ sở cũng không phải bất biến tuyệt đối. Khi phạm vi hoặc cam kết đã thay đổi hợp lệ và được phê duyệt, doanh nghiệp có thể cần một đường cơ sở điều chỉnh theo quy trình kiểm soát thay đổi.

Điều cần quản trị là lịch sử. Người dùng phải biết đường cơ sở ban đầu là gì, thay đổi nào đã được phê duyệt, phiên bản hiện hành dùng cho điều hành là gì và sự khác nhau giữa chúng. Nhờ vậy, báo cáo không chỉ cho biết ‘đang lệch bao nhiêu ngày’ mà còn cho biết lệch so với cam kết nào.

Hình 2. Từ tiến độ tổng thể đến kế hoạch có thể thực thi

6. Tiến độ tổng thể phải được phân rã thành kế hoạch có thể thực thi tại hiện trường

Một tiến độ tổng thể dù chính xác vẫn không đủ để điều hành công trường hàng ngày. Khoảng cách giữa một hoạt động cấp cao như ‘hoàn thiện tầng 10’ và nhiệm vụ của tổ đội là quá lớn. Dự án cần các lớp kế hoạch trung gian: kế hoạch giai đoạn, kế hoạch nhìn trước (look-ahead plan), kế hoạch tuần và kế hoạch ngày.

Kế hoạch nhìn trước có vai trò đặc biệt quan trọng vì nó kiểm tra khả năng sẵn sàng trước khi công việc bước vào cửa sổ thi công. Với mỗi công việc, nhóm dự án cần xác định các điều kiện như bản vẽ, vật tư, mặt bằng, biện pháp, nhân lực, thiết bị và công việc tiền nhiệm. Một công việc chỉ nên trở thành cam kết tuần khi các ràng buộc quan trọng đã được tháo gỡ hoặc có phương án xử lý đáng tin cậy.

Nhờ đó, tiến độ không còn là cơ chế ‘đẩy ngày’ từ trên xuống mà trở thành chuỗi cam kết từ chiến lược đến hiện trường. Nếu kế hoạch tuần liên tục không đạt, dự án cần tìm nguyên nhân ở chất lượng chuẩn bị, độ ổn định của nguồn lực hoặc tính thực tế của tiến độ tổng thể, thay vì chỉ yêu cầu tổ đội tăng tốc.

7. Cập nhật tiến độ không phải là nhập phần trăm hoàn thành

Một kỳ cập nhật đúng nghĩa bắt đầu bằng ngày dữ liệu (data date) — mốc thời gian phân chia giữa điều đã thực sự xảy ra và phần việc còn lại phải dự báo. Tất cả trạng thái cần phản ánh thông tin có thật đến ngày đó. Oracle Primavera khuyến nghị cập nhật thông tin hoạt động định kỳ và dịch ngày dữ liệu theo từng kỳ cập nhật để theo dõi công việc đang diễn ra.

Đối với công việc đã bắt đầu, cần ghi nhận ngày bắt đầu thực tế, khối lượng hoặc phần công việc đã hoàn thành, thời lượng còn lại và các điều kiện ảnh hưởng. Đối với công việc hoàn thành, ngày kết thúc thực tế phải phản ánh đúng thời điểm đạt tiêu chí hoàn thành đã thống nhất. Đối với công việc chưa bắt đầu, dự án cần đánh giá liệu ngày dự kiến có còn khả thi dựa trên các ràng buộc hiện tại hay không.

Điểm dễ sai nhất là phần trăm hoàn thành. Nếu mỗi cán bộ tự ước lượng theo cảm nhận, con số 70% có thể mang ý nghĩa khác nhau giữa các gói việc. Với công việc có khối lượng, nên ưu tiên tỷ lệ khối lượng hoàn thành hoặc nghiệm thu. Với công việc theo mốc, có thể quy định trọng số theo các bước rõ ràng. Mục tiêu là biến tiến độ từ ý kiến chủ quan thành dữ liệu có thể kiểm chứng.

Sau khi cập nhật thực tế, hệ thống phải tính lại phần việc còn lại theo logic. Đây là lúc ngày hoàn thành dự báo, đường găng và thời gian dự phòng có thể thay đổi. Nếu người lập tiến độ chỉnh tay ngày để giữ kết quả giống kỳ trước, toàn bộ ý nghĩa của cập nhật bị phá vỡ.

Hình 3. Một chu kỳ cập nhật tiến độ đúng nghĩa

8. Kiểm soát tiến độ phải phân tích cả sai lệch, xu hướng và nguyên nhân

So sánh hiện tại với đường cơ sở là bước đầu tiên. Dự án cần biết công việc nào bắt đầu muộn, kết thúc muộn, mốc nào bị dịch chuyển và thời gian dự phòng đã thay đổi ra sao. Nhưng sai lệch tại một thời điểm chưa đủ để kết luận. Một công việc chậm hai ngày nhưng đang phục hồi khác hoàn toàn một công việc chưa chậm nhưng mỗi tuần mất thêm ba ngày dự phòng.

Vì vậy, kiểm soát cần nhìn xu hướng qua nhiều kỳ. Lịch sử thay đổi ngày, tốc độ tiêu hao dự phòng, tỷ lệ hoàn thành kế hoạch tuần, số ràng buộc mở và năng suất là những tín hiệu cho thấy sức khỏe của tiến độ. Đây cũng chính là lớp dữ liệu mà Bài #10 đã chỉ ra là cần thiết cho cảnh báo sớm: chậm tiến độ thường hình thành qua một chuỗi tín hiệu trước khi xuất hiện thành sai lệch chính thức.

Sau khi phát hiện sai lệch, nhóm dự án phải truy nguyên. Chậm do bản vẽ, vật tư, mặt bằng, năng suất, nhà thầu, thay đổi hay quyết định? Nguyên nhân có tính cục bộ hay có khả năng lan sang nhiều công việc? Ai có quyền xử lý? Nếu không gắn sai lệch với nguyên nhân và trách nhiệm, báo cáo tiến độ sẽ chỉ lặp lại vấn đề mà không tạo ra hành động.

Hình 4. Kiểm soát tiến độ phải đi từ sai lệch đến nguyên nhân

9. Đường găng và thời gian dự phòng phải được hiểu như tín hiệu quản trị, không phải màu trên biểu đồ

Phương pháp đường găng (Critical Path Method – CPM) xác định chuỗi công việc mà sự chậm trễ có thể tác động trực tiếp đến ngày hoàn thành theo logic hiện tại. Oracle mô tả đường găng là các hoạt động mà nếu bị chậm có thể khiến dự án vượt ngày kết thúc dự kiến. Tuy nhiên, đường găng không phải một danh sách cố định từ đầu đến cuối dự án; nó có thể thay đổi khi thực tế, logic và thời lượng còn lại thay đổi.

Nhà quản lý cũng không nên chỉ quan tâm đến công việc có thời gian dự phòng bằng không. Các chuỗi gần găng với dự phòng thấp có thể nhanh chóng trở thành đường găng nếu phát sinh vấn đề. Vì vậy, cần theo dõi cả sự dịch chuyển của đường găng và tốc độ tiêu hao dự phòng.

Một dấu hiệu đáng lo khác là khi đường găng thay đổi liên tục mà không có giải thích rõ. Điều này có thể phản ánh dự án thực sự biến động, nhưng cũng có thể cho thấy logic tiến độ thiếu ổn định hoặc cập nhật không nhất quán. Kiểm soát tiến độ tốt phải phân biệt được biến động của công trường với biến động do chất lượng mô hình.

10. Khi chậm tiến độ xuất hiện, kế hoạch phục hồi phải là một bài toán có đánh đổi

Phục hồi tiến độ không đơn giản là yêu cầu ‘tăng nhân lực’. Một phương án rút ngắn thời gian có thể gồm tăng ca, bổ sung tổ đội, thay đổi trình tự, chia nhỏ mặt bằng, thi công song song, đổi biện pháp hoặc đẩy nhanh cung ứng. Mỗi lựa chọn đều có giới hạn kỹ thuật và chi phí riêng.

Ví dụ, tăng số người trong một khu vực chật có thể làm năng suất bình quân giảm do xung đột không gian. Thi công song song có thể tạo thêm giao diện an toàn và chất lượng. Đẩy nhanh vật tư có thể tăng chi phí vận chuyển. Vì vậy, phương án phục hồi phải tập trung vào những công việc thực sự chi phối mốc, đánh giá tác động tới chi phí và rủi ro, rồi lựa chọn tổ hợp hành động có hiệu quả nhất.

Sau khi phương án được chấp thuận, tiến độ phải phản ánh logic mới và tiếp tục được theo dõi. Một kế hoạch phục hồi chỉ tồn tại trong biên bản họp nhưng không được đưa vào mô hình tiến độ sẽ rất khó kiểm chứng hiệu quả.

11. Kiểm soát chất lượng của chính bản tiến độ

Một dự án không nên chỉ kiểm tra ‘tiến độ đang chậm hay không’ mà còn phải kiểm tra chất lượng của bản tiến độ. Các dấu hiệu cần chú ý gồm công việc không có quan hệ trước hoặc sau, quá nhiều ràng buộc ngày cứng, thời lượng quá dài, sử dụng độ trễ khó giải thích, phần việc đã qua ngày dữ liệu nhưng chưa được cập nhật, hoặc logic làm cho ngày tháng không phản ánh thực tế.

Chất lượng tiến độ cũng thể hiện ở khả năng truy nguyên. Khi một mốc bị dịch chuyển, người lập tiến độ phải giải thích được chuỗi công việc nào gây ra thay đổi. Khi một công việc được dự báo hoàn thành muộn, phải biết giả định nào đã thay đổi. Nếu câu trả lời chỉ là ‘phần mềm tính như vậy’, bản tiến độ chưa thực sự là một công cụ quản trị.

Doanh nghiệp nên xây một bộ quy tắc kiểm tra thống nhất cho các dự án, nhưng không nên biến nó thành thủ tục hình thức. Mục tiêu là phát hiện các cấu trúc có thể làm sai kết quả phân tích, từ đó nâng độ tin cậy của thông tin mà ban điều hành sử dụng.

12. Từ quản lý tiến độ bằng file đến hệ thống điều hành dựa trên dữ liệu

Ở nhiều doanh nghiệp, tiến độ vẫn được cập nhật trong một phần mềm riêng rồi xuất sang bảng tính, trình chiếu hoặc báo cáo. Trong khi đó, dữ liệu vật tư, hồ sơ, khối lượng, nhân lực và vấn đề hiện trường nằm ở những hệ thống khác. Cách làm này khiến cán bộ kế hoạch phải dành nhiều thời gian thu thập và đối chiếu hơn là phân tích.

Hướng phát triển hợp lý không nhất thiết là đưa mọi thứ vào một phần mềm duy nhất, mà là tạo liên kết dữ liệu giữa tiến độ và các đối tượng thực thi. Công việc trên tiến độ cần biết nó thuộc khu vực nào, dùng bản vẽ nào, cần vật tư nào, do nhà thầu nào thực hiện và gắn với khối lượng nào. Khi đó, trạng thái của các điều kiện có thể trở thành tín hiệu tự động cho công tác kiểm soát.

Đây cũng là nền tảng cho bước tiếp theo của chuỗi nội dung: AI hỗ trợ tối ưu kế hoạch và điều phối nguồn lực công trường. Nhưng AI chỉ có thể tối ưu một kế hoạch đáng tin cậy. Nếu logic tiến độ sai hoặc dữ liệu cập nhật không phản ánh thực tế, thuật toán chỉ tối ưu hóa một mô hình sai nhanh hơn.

Hình 5. Vòng kiểm soát tiến độ liên tục

13. Một quy trình thực tế cho kỳ kiểm soát tiến độ hàng tuần

Một chu kỳ tuần hiệu quả có thể bắt đầu bằng việc chốt dữ liệu hiện trường tại thời điểm thống nhất. Cán bộ phụ trách xác nhận khối lượng, trạng thái, ngày thực tế, thời lượng còn lại và các ràng buộc. Sau đó người lập tiến độ chạy lại mô hình, kiểm tra logic, đường găng và các mốc thay đổi.

Bước tiếp theo không phải lập báo cáo ngay mà là phân tích. Nhóm dự án cần tập trung vào những thay đổi có ý nghĩa: mốc nào dịch chuyển; chuỗi nào mất dự phòng; công việc nào không đạt cam kết; nguyên nhân nào lặp lại; điều kiện nào có thể chặn kế hoạch hai đến sáu tuần tới. Chỉ sau khi hiểu nguyên nhân mới xác định hành động và người chịu trách nhiệm.

Cuộc họp tiến độ vì thế nên kết thúc bằng một danh sách quyết định và hành động có thời hạn, chứ không phải bằng một tập biểu đồ. Ở kỳ sau, hệ thống phải cho biết hành động nào đã hoàn thành và tác động đến dự báo ra sao. Khi vòng này được duy trì, tiến độ trở thành một cơ chế học hỏi liên tục của dự án.

Kết luận

Quản lý tiến độ thi công không phải là công việc cập nhật một biểu đồ Gantt cho đúng kỳ báo cáo. Đó là quá trình xây dựng và duy trì một mô hình logic về cách dự án sẽ được thực hiện, sau đó liên tục kiểm chứng mô hình ấy bằng dữ liệu hiện trường.

Một tiến độ đáng tin cậy cần bắt đầu từ phạm vi rõ, cấu trúc công việc hợp lý, quan hệ trước–sau có cơ sở và thời lượng gắn với năng suất. Đường cơ sở giữ lại cam kết; kế hoạch nhìn trước biến chiến lược thành công việc có thể thực thi; kỳ cập nhật đưa thực tế vào mô hình; còn phân tích đường găng, dự phòng, xu hướng và nguyên nhân giúp ban điều hành nhìn thấy nơi cần can thiệp.

Giá trị cuối cùng của tiến độ không nằm ở việc dự báo một ngày hoàn thành thật chính xác. Giá trị nằm ở việc tạo ra đủ sớm một bức tranh đáng tin cậy để dự án có thể thay đổi kết quả. Khi nền tảng này được thiết lập tốt, dữ liệu tiến độ mới đủ chất lượng để kết nối với chi phí, vật tư, nguồn lực và các công cụ AI ở những bước tiếp theo.

Tài liệu tham khảo

• Project Management Institute (PMI), PMP Examination Content Outline 2026 – nội dung về xây dựng, thiết lập đường cơ sở, thực thi kế hoạch quản lý tiến độ và phân tích sai lệch.
• Oracle Primavera Cloud, Schedule Management User Guide và hướng dẫn Managing Your Contract Schedule – nội dung về ngày dữ liệu, cập nhật hoạt động, đường cơ sở và so sánh tiến độ.
• Oracle Primavera P6 Professional User Guide Version 26 – hướng dẫn tạo và quản lý đường cơ sở.
• Autodesk Construction, các tài liệu về lập kế hoạch xây dựng, kế hoạch nguồn lực và quản lý tiến độ.