A construction programme can look perfectly healthy on a screen.
The dates are there. Activities are linked. Completion is still showing where everyone expects it to be.
Then you walk the site.
And something doesn’t feel right.
There aren’t enough people working.
One trade hasn’t finished, but according to the programme the next trade should already be starting.
Materials that should be on site haven’t arrived.
An issue that was raised last week is still sitting there waiting for an answer.
The programme might not be showing a delay yet.
The site is.
I’ve worked in construction for over 20 years, and one thing I’ve learned is that keeping a project on programme isn’t just about looking at dates.
It’s about understanding what has to happen for those dates to remain possible.
Start With What Was Supposed to Happen
Before you can say a project is behind, you need to know what was supposed to happen.
That sounds obvious.
But I’ve been in enough meetings where people are discussing progress without really establishing what should have been completed by that point.
I want to know where we were supposed to be today.
What should have started?
What should have finished?
What should have been ordered?
What decisions should already have been made?
And what needs to happen next?
That gives you something real to measure against.
Don’t Manage the Programme From the Meeting Room
A progress meeting can tell you a lot.
But so can walking the job.
If the programme says ten properties should be completed and only six are physically finished, that tells you something.
If five operatives are needed to maintain output and there are only two working, that tells you something.
If the next phase is due to start but the previous work is still incomplete, that tells you something.
I like numbers.
But I also like looking.
The two need to agree.
Look Ahead, Not Just Behind
One of the easiest things to do in construction is explain why something happened.
The materials were late.
Access wasn’t available.
Another trade held things up.
A decision took longer than expected.
All of those things can be genuine.
But once the delay has happened, you’re explaining history.
Programme control should also be about what is coming.
What needs ordering now?
What information is outstanding?
Which properties still need access?
Which decision could hold up work in two weeks?
Is another trade going to be in the same area?
Is there enough labour to achieve the planned output?
A problem is much easier to deal with while it is still in front of you.
Small Delays Don’t Always Stay Small
This is where projects can catch people out.
One day doesn’t sound like much.
Neither does a missed appointment.
Or one material delivery turning up late.
Or one decision waiting until next week.
Individually, none of them may threaten the completion date.
But construction activities are connected.
If one trade finishes late, another trade starts late.
That can affect inspections.
Which can affect making good.
Which can affect completion.
Suddenly the one-day problem has travelled through several activities.
That is why I pay attention to the smaller things.
Not because every small delay is a crisis.
Because some of them are the beginning of a bigger one.
Ask What Recovery Actually Means
When a project slips, somebody will usually mention recovery.
That’s fine.
But saying a project will recover isn’t the same as having a recovery plan.
I want to know how.
More labour?
Different sequencing?
Additional working days?
Earlier material orders?
Working in more locations at the same time?
Removing whatever is blocking progress?
And most importantly, is it realistic?
If a contractor is completing six units a week and the recovery programme suddenly requires ten, something has to change.
You cannot recover four extra units just because a spreadsheet says you will.
Output Tells You a Lot
On repetitive programmes, output becomes particularly useful.
If you know what the team normally delivers each week, you start to understand what is realistic.
You also start noticing when something changes.
If output begins falling, I want to know why.
It could be labour.
Access.
Materials.
Quality issues.
Too many return visits.
Poor sequencing.
Or several small problems happening at the same time.
The number itself doesn’t give you the answer.
It tells you where to start looking.
Quality Is Part of the Programme
There is another mistake I see sometimes.
People treat progress and quality as if they are separate.
They’re not.
Work completed badly isn’t really complete.
If somebody has to return and put it right, you’ve used labour twice.
You may also hold up the next trade.
Then there is another inspection.
Another visit.
Possibly another appointment with the resident or client.
That all takes time.
Sometimes slowing something down and doing it properly once is quicker than rushing it and doing it twice.
Know What Is Actually Holding the Job Up
When a programme starts slipping, it is easy for everyone to have a different explanation.
The contractor says access.
The client says labour.
The site team says materials.
Someone else says design.
Sometimes they are all partly right.
The important thing is finding the constraint that is actually stopping progress.
Because that is where attention needs to go.
There is little value chasing ten different things if one unresolved issue is controlling everything behind it.
A Programme Should Help You Make Decisions
For me, that is ultimately what a programme is for.
It isn’t there simply because the contract requires one.
And it isn’t something that should only come out for the monthly meeting.
It should help you decide where attention is needed.
What needs chasing.
What needs escalating.
What can wait.
And what cannot.
A good programme tells you where the project intends to go.
Good programme management is making sure what is happening on site still gives you a realistic chance of getting there.
Because by the time the completion date moves on the programme, the project may have been telling you it was in trouble for weeks.
You just had to notice it.
Life. Construction. Legacy.
Marlon Amele MCIOB
