When a construction project starts falling behind, the master programme will usually show it.
Activities finish later than planned. Float gets consumed. Successors move and eventually a key milestone starts coming under pressure.
The programme is doing its job.
The problem is that by the time the deterioration becomes obvious, the conditions that caused it may have been developing on site for days or even weeks. And on a large project, there can be another delay that gets far less attention: the time it takes to collect everything that has happened on site and get it back into the programme.
That distinction matters.
CPM can only calculate from the information it has. If the information reaching the programme is already several steps behind what’s happening on site, even a well-maintained programme can give the project team an accurate picture that’s already out of date.
The master programme is essential to managing a construction project. It establishes the sequence of work, dependencies between activities, key milestones and the overall path towards completion. As progress is reported, it calculates how changes today could affect what happens next.
What it can’t do on its own is see the problems developing around upcoming work.
Take an activity due to start next week. According to the programme, everything might look fine. The predecessor is progressing, the planned start hasn’t moved and there may still be float available.
Talk to the people actually delivering the work and you might hear something different.
A drawing is still waiting for approval. Materials haven’t arrived. Access to the area isn’t ready. Another trade needs to finish first, and the team already knows they’re struggling to meet their date.
At that point, the activity isn’t technically late.
But the conditions for a delay are already there.
That creates a gap between what the programme currently says and what the people closest to the work already know.
This is the part that often gets overlooked.
The programme doesn’t update itself every time something changes on site. Somebody has to get that information back into it.
On a large project, that can mean a planner gathering progress and delay information from multiple contractors, all reporting in different ways.
One contractor sends marked-up PDFs. Another maintains an Excel tracker. Someone provides updates through meetings or emails. Subcontractors may maintain their own programmes, which don’t always align neatly with the main contractor’s programme.
The planner then has to make sense of it all.
Only after that information has been gathered, checked and reconciled can it be properly reflected in P6.
That takes time.
And while the planner is doing all of this, the project hasn’t stopped.
Work is still progressing. New constraints are appearing. Activities are finishing. Others are slipping. Contractors are making new commitments and site conditions continue to change.
So the programme can be getting more accurate about where the project was, while becoming less representative of where the project is.
Take a monthly programme update as an example.
The reporting period closes at the end of the month. The planner then begins gathering the information needed to update the master programme and produce the associated monthly report for the client.
On a large project, that process might take another two or three weeks.
By the time the updated programme and report are issued, the information inside them describes the project as it stood weeks earlier.
A lot can happen on a construction site in three weeks.
Activities that appeared ready to start may now be delayed. Work that was behind may have recovered. New constraints may have appeared. Access conditions may have changed. Contractors may have revised their plans and new decisions may have affected the sequence of remaining work.
The programme can therefore be technically correct for the reporting cut-off while already being out of date on the day people receive it.
That creates a practical problem for the construction team.
If they’re trying to use that programme to forecast the start and finish dates of remaining work, they’re planning today using a picture of the project that may be several weeks old.
The dates are calculated correctly.
The information underneath them is simply behind reality.
That delay isn’t necessarily the planner’s fault.
In many cases, the planner is stuck in the middle of an information-gathering process that consumes a huge amount of time.
A typical week can become a cycle of chasing contractors for basic information, updating P6 with whatever progress has been collected, piecing together delay information from daily logs and separate platforms, and then producing the weekly report.
By Friday, the process begins again.
That’s exactly what the accompanying “Planner Typical Week” visual illustrates. The planner spends Monday chasing contractors, Tuesday updating P6, Wednesday piecing together delays, Thursday producing the weekly report and Friday starting the chase again.
The problem isn’t a lack of planning expertise.
It’s the amount of administrative work required before the planner can actually use that expertise.
Instead of analysing what’s happening and advising the project team on what needs attention next, a significant part of the role can become finding information about what has already happened.
Construction projects don’t change once a week when somebody updates the programme.
And they definitely don’t change once a month.
They change every day.
A subcontractor discovers something unexpected. An approval takes longer than expected.
Access to an area changes. Materials don’t arrive when promised. A trade finishes most of its work but leaves behind the one thing preventing the next team from starting.
The information about those changes usually exists somewhere.
Someone knows the drawing hasn’t been approved.
Someone has spoken to the supplier.
Someone knows the area won’t be handed over on Thursday.
Someone has already told another contractor that their planned start is at risk.
But there’s a difference between information existing on the project and information being available to the programme.
When progress, delays and commitments are spread across PDFs, spreadsheets, separate subcontractor programmes, meetings and conversations, there’s inevitably work required to bring everything back together.
Every step takes time.
When a schedule starts deteriorating, it’s easy to focus on the programme itself.
Was the logic right? Was progress updated properly? Do we need more frequent programme reviews?
Those are fair questions.
But they can miss the bigger issue.
If an activity finishes late, CPM will calculate the consequences. Successors may move.
Float may be consumed. The critical path may change. Eventually, a project milestone could move with it.
The calculation has done exactly what it was supposed to do.
What CPM can’t know by itself is that the drawing needed for next Thursday is still awaiting approval.
It doesn’t know that a delivery expected on Monday hasn’t arrived.
And it doesn’t know that the subcontractor responsible for an upcoming activity no longer believes the planned start is realistic.
Someone on the project probably does.
The challenge is getting that information into the planning process quickly enough for it to be useful.
This is why looking at the programme alone doesn’t always tell you enough about the health of upcoming work.
An activity doesn’t need to be late to be at risk.
Imagine there are seven days until a planned start and a critical prerequisite still isn’t ready.
On the programme, nothing has necessarily changed yet. The start date hasn’t been missed. There may be no delay to report.
But those seven days are valuable.
Find the problem on day one and the team has time to respond. Find it on day four and the options start narrowing. Wait until the activity is supposed to begin and suddenly everyone is talking about recovery.
The underlying issue could be exactly the same in all three cases.
What changes is how much time the team has to deal with it.
That’s why one of the most useful questions a project team can ask isn’t simply, “Are we on programme?”
It’s “What could stop us delivering the programme?”
This is where the speed of the update cycle really matters.
A master programme should help the project team understand where the project is heading and plan the work still to come.
But if the information required to update it takes weeks to gather and reconcile, its role starts to change.
Instead of being something the construction team can confidently use to forecast upcoming start and finish dates, it becomes increasingly useful as a historical record of where the project stood at a particular reporting cut-off.
That record still matters.
But it’s a different job.
The construction team needs to make decisions today.
The answer isn’t to replace the master programme.
And it isn’t simply to ask planners to update P6 faster.
If the planner still has to spend days chasing and reconciling fragmented information, increasing the reporting frequency can simply increase the administrative burden.
The bigger opportunity is to shorten the distance the information has to travel.
Progress should be captured closer to where the work happens.
Constraints should be visible against the activities they threaten.
Weekly commitments should connect back to the programme.
And the people responsible for delivering the work should be able to provide information without creating another round of emails, spreadsheets and manual updates for the planner to decipher.
That changes the planner’s role too.
Instead of spending the week chasing information, updating P6, piecing together delays and producing another report before starting the cycle again, more time can go towards analysing performance, understanding risk and advising the team on what needs to happen next.
That’s a much better use of a planner.
The master programme still provides the strategic direction. It tells the project what needs to happen, in what sequence and by when.
But for that programme to remain useful operationally, the information flowing into it needs to keep pace with the project.
When the update cycle is too slow, the programme can tell you exactly where the project was.
What the team really needs is a clearer view of where it’s going.
The programme isn’t necessarily wrong.
Uconia connects Primavera P6 with the day-to-day execution of work on site, helping progress, constraints and weekly commitments reach the planning process closer to the point where that information is created.
Instead of planners spending their week chasing updates across contractors, PDF mark- ups, Excel trackers and separate reporting processes, information can be captured at source and connected back to the master programme.
The goal isn’t to replace P6 or the planner.
It’s to give the planner better information, sooner, so more time can be spent understanding performance and advising the project team rather than reconstructing what happened weeks ago.
Because the faster site reality reaches the programme, the sooner the project can do something about it.
