A site can be busy every day, every crew can have work, every weekly report can say "in progress" — and the building can still hand over three months late. At that point the project manager asks the obvious question: late where? That question only has an answer if you know what the critical path is and have been tracking the programme against it from the start.
This article explains it on a single townhouse, then lists the five reasons construction schedules slip that the Institute's lecturers meet most often on real projects. After that comes the weekly tracking routine, and how to report progress to a client so that the report is worth reading.
The critical path, shown on one building
The critical path is the longest unbroken chain of dependent activities from the start of the project to the end. Nothing on that chain has any float: a day late is a day late on the completion date. Activities off the chain have float, and can slip within it without moving handover at all.
Take a four-storey townhouse, cut down to a handful of activities:
| Activity | Duration | Must follow |
|---|---|---|
| A. Piling, excavation, foundation | 20 days | — |
| B. Concrete frame, four storeys | 60 days | A |
| C. Blockwork | 25 days | B (starts once the second floor is cast, overlapping) |
| D. Concealed services | 15 days | C, floor by floor |
| E. Render, tiling, paint | 35 days | D |
| F. Doors, fittings, final clean | 10 days | E |
| G. Gate, yard, fence | 12 days | A (can run alongside the frame) |
The chain A → B → C → D → E → F is the longest: that is the critical path. Blockwork overlaps the frame, but the top-floor walls cannot go up until the top-floor frame is cast, so C still finishes after B and both stay critical. Activity G only has to finish before F starts, so it carries close to a hundred days of float. If the gate crew runs a week late, nothing happens. If the reinforcement crew on B runs a week late, handover moves a week.
Three consequences follow.
- Put resources on the chain. Short of labour, move people from an activity with float (G) onto one on the chain (B), not the other way round.
- You shorten a project by shortening that chain. Overtime for the gate crew does not bring the finish date forward. Overtime for the concrete crew does. And once B is short enough, the longest chain can shift elsewhere, which then has to be recalculated.
- The chain moves over time. An activity off it that eats all its float becomes critical. Today's chain is not next month's, which is why it has to be updated.
Beyond a few dozen activities, finding the critical path by hand stops being practical; that is what scheduling software such as Microsoft Project is for. What is MS Project? explains how the software calculates the chain and marks it in red once the dependencies are declared properly. Building a programme with real dependencies and reading which chain is critical is the core of the Institute's MS Project course.
Five reasons construction schedules slip
This list comes from projects that students on the Institute's scheduling course bring to class to be picked apart. None of the five is "the weather" or "cash flow" — both real, but rarely the root cause.
1. The programme has no dependencies. A coloured spreadsheet, each activity given a span of its own, with no "B follows A". A programme like that has nothing marked critical, so nobody knows which activity matters. When it slips, everything is urgent — which means nothing is.
2. Durations set by wish, not by output. "Four-storey frame in 45 days" because the contract needs it, while a crew of eight turns out one floor every fifteen days — sixty days for four storeys, as in the table above. The programme slips in week one, and every later update simply records how far behind it has fallen.
3. Invisible activities left out. Concrete curing to strength, material approvals, shop drawing approvals, imported equipment delivery, stage inspections. A few days each, several weeks together — and they usually sit right on the chain.
4. Resources double-booked. One masonry crew laying blockwork on the third floor and rendering the first in the same week; one crane serving two zones. The programme works on paper and not on site, because nobody assigned resources for the software to flag the overload.
5. No updates, or updates with no baseline saved. The programme is issued to the client and filed. When the job runs late, nobody can say which activity started it, how far behind the original plan it is, or what downstream work it drags with it.
What the five have in common: every one is a planning and control failure, not a construction failure. And every one is visible in the first week if the programme has the chain identified and gets updated.
Controlling progress: the weekly routine
Progress control is a weekly habit, not a document. The routine the Institute's lecturers recommend for small and medium projects:
Friday or Saturday — collect the facts. The site engineer records, for each activity in progress: actual start, percentage complete measured by quantity rather than by feel, and expected finish. For anything not started that is already past its planned date: the reason.
Enter it in the software. Load the data and let the software recompute the expected finish of everything downstream, and the new chain. Compare against the saved baseline: how many days ahead or behind is the project, and because of which activity.
Ask three questions. Which critical activity is behind? Which non-critical activity has eaten most of its float and is about to become critical? Is any resource overloaded next week?
Decide and assign. For each critical activity running late: add resources, overlap it, change the method, or accept it and tell the client early. The decision goes into the weekly meeting minutes with a name against it and a date to check.
Save the version. One programme version per week, so that later you can trace when the slippage started and what was decided. This is also the evidence you need in any dispute about an extension of time.
The whole loop takes two to three hours a week on a programme of 100–200 activities, provided the programme was built properly in the first place.
Reporting progress to the client
The commonest weak progress report reads like this: "This week we completed the fifth-floor slab reinforcement, we are erecting sixth-floor formwork, and we expect to pour next week." All true, and all useless: the client cannot tell whether the project is ahead or behind, or by how much handover would move.
A report that earns its place answers four questions on one page.
- Where is the project against the baseline? Ahead or behind by how many days; percentage complete by quantity against the planned percentage for this date.
- Which critical activity is the cause? Name the activity. Not "because of the weather".
- What does it do to the next milestone and to handover? A number, which the software produces.
- What is the contractor doing, and what does the client need to decide? Overtime, a change of method, or a fast approval on a document that is blocking the critical path.
Attach a Gantt chart with that chain in red and the baseline greyed behind it, printed from the software, plus a table of critical activities running late. A report in this shape builds more confidence than a vague one even when the project is behind, because the client can see the contractor knows exactly where the problem is. It is also the record that supports a claim for an extension of time. What construction payment and settlement records must contain covers the role of the site diary and progress reports in the wider file.
On larger projects, progress reporting increasingly comes with 4D simulation on the BIM model — see what Navisworks is used for — but the four questions do not change.
Frequently asked questions
What is the critical path in one sentence?
The longest chain of dependent activities in a project, which sets the completion date; a day lost on it is a day lost on handover.
Can more than one chain be critical?
Yes. When two chains are equally long, both are critical; and shortening one can make another critical. That is why it has to be recalculated after every change.
Can you manage the chain without software?
On a programme of twenty or thirty activities, by hand, yes. On a real project, no. Scheduling software finds the chain in a second once the dependencies are declared.
Where should overtime go when a project is behind?
Only on activities on the critical path, and only where the activity is not blocked by something else such as materials or an approval. Overtime on an activity with float costs money and shortens nothing.
Does a late programme entitle a contractor to an extension of time?
It depends on the cause and on the contract. Causes on the client's side — late possession of the site, late approvals — are usually grounds for an extension if the contractor can prove them with an updated programme and site records. That is the reason for saving a programme version every week.