Construction scheduling: how to build a programme that is actually worth something
A construction programme is the representation in time of how a project will be executed: which activities, in what order, with what durations and with what dependencies between them. It is the reference everything else is measured against —progress, delay, extensions of time, price adjustment—.
It is also the document that most projects have and fewest projects use. It is built for the tender, printed, pinned up in the site office and never looked at again.
Why most of them are useless
Four concrete reasons.
It was built to win, not to execute. Optimistic durations because the programme was an evaluation criterion. Everyone knows it and nobody says it.
It has no dependency logic. The activities are placed in time but not linked to each other. When one moves, the rest do not move with it, and the programme stops reflecting reality at the first surprise.
It is either too aggregated or too detailed. “Structure: 120 days” lets you control nothing. Four thousand activities does not either, because nobody updates them.
It never gets updated. Without updating, by week six it is fiction, and so is everything calculated against it —progress, delay.
The three concepts you have to understand
Dependencies
An activity cannot start until another finishes, or until another has progressed far enough. That linkage is what turns a list of tasks into a programme.
Without dependencies, moving one activity moves nothing else, and the programme cannot answer the only question that matters: if this slips, what else slips?
Critical path
It is the longest chain of linked activities in the project. It determines the total duration.
The practical consequence: an activity on the critical path that slips one day delays the project by one day. One that is not on the critical path can slip with no effect on the completion date, until its float is used up.
It is why “we are behind on partitions” can be irrelevant and “we are two days behind on the level 3 pour” can be serious.
Float
It is how much an activity can slip without affecting the final date. Activities on the critical path have zero float.
And it is what decides an extension of time. If the work face they failed to release belonged to an activity with fifteen days of float and the hold-up was ten, there was no effect on the completion date, and the supervisor will review it in exactly those terms.
That is why the support for an extension is not just evidence of the event: it is the programme analysis that demonstrates the effect.
How it is built, in order
1 · Break down the scope. Split the project into identifiable work packages, at a level of detail that lets you assign an owner, a duration and resources.
2 · Define dependencies. For each activity, what has to be finished first. It is the step most often skipped and the one that makes everything else useful.
3 · Estimate durations with your own output rates. The quantity of the item divided by the output of the crew you are actually going to have. Not the output from the manual: yours.
4 · Assign resources and check availability. A programme that requires three masonry crews at once when you have two is not a programme, it is a wish.
5 · Identify the critical path and the float.
6 · Test it against real constraints. Permits, access, working windows, the rainy season, availability of critical suppliers.
7 · Freeze it as the baseline. And keep it. With no frozen, dated baseline there is no way to demonstrate afterwards what moved and why.
The right level of detail
The rule of thumb that works: each activity should last between one and three weeks.
Any shorter and the programme becomes unmanageable. Any longer and it does not let you catch deviations in time, because a two-month activity can be in trouble from week two and go unnoticed until week eight.
For the fine detail of the coming week the tool is a different one: a short, disposable weekly plan of work faces that does not touch the master programme.
The update, which is where the value lives
A programme is worth what its updating is worth, not what its building was.
Minimum frequency: weekly. Record the real progress of each activity, recalculate, and see what moved.
Keep every version, dated. It is what later lets you demonstrate the effect of an event on the critical path. Without the programme before and after, an extension of time has no technical support.
Tell rescheduling apart from correcting. If the cause of the delay is removable, you correct it and the programme stands. If it is structural, you reschedule and you say so. Mixing the two produces programmes nobody believes.
Where the data comes from
Here is the link with daily operations, and it is what makes a programme live or die.
Updating a programme weekly requires knowing, every week, how far each activity advanced. If that figure is reconstructed from memory on Fridays, the update is approximate and the programme loses credibility fast.
If instead progress is recorded the day it happens, by item and by work face, updating the programme is automatic: it is reading what is already recorded.
It is the same discipline that holds up billing, output and claims. One daily record that pays off on four different fronts.
Frequently asked questions
- Do I need scheduling software?
- On small projects, a well-built spreadsheet is enough. Past a certain complexity, software that computes the critical path saves a lot of time and prevents mistakes. What no tool replaces is defining the dependencies properly.
- How often should I reschedule?
- Update, weekly. Reschedule —change the baseline— only when there is a structural change: a modification of scope, a prolonged suspension, an approved extension. Rescheduling every month destroys any possibility of measuring against something.
- What do I do if the contract programme was never realistic?
- Reschedule with real output rates as soon as possible and present the scenario with evidence behind it. The later that conversation happens, the worse for everyone. A delay flagged in week 6 is management; the same one in week 30 is a crisis.
- Does the critical path change during the project?
- Yes, and often. An activity with float that slips far enough can become critical. That is why it has to be recalculated, not assumed to be the one from the start.
- How do I estimate durations with no history of output rates?
- With the output rate from your budget as a starting point, adjusted for the conditions you already know on the project. And start measuring from day one: in two months you have your own data, which is worth infinitely more than any table.
Chilean, designing for Latin America. Field research surfaces what actually matters to clients, and that becomes products non-technical people adopt on their own — legal, education, accounting — and that show up in productivity from week one.
See all their articles →
