Every asset owner has sat through the same post-mortem. The program slipped, the contractor is blamed, a claims consultant gets engaged, and everyone moves on to the next project with the same procurement approach that produced the last slip. The pattern repeats because the real cause of most program overruns isn't sitting on site — it's sitting in decisions made months before construction ever starts.
The program is locked before the risk is understood
Most capital works programs are built and approved at the point of least information — during tender, before anyone has verified site conditions, confirmed long-lead delivery times against current market conditions, or tested design assumptions against what's actually there. That program then becomes the baseline everything is measured against, even though it was built on the thinnest information the project will ever have.
The fix isn't a better scheduling tool. It's accepting that a program built pre-construction is a hypothesis, not a commitment, and building in a formal re-baseline point once early works or site verification confirm — or contradict — the assumptions it was built on. Asset owners who treat the tender program as gospel are the ones most surprised when it doesn't hold.
Float gets consumed before construction even starts
Programs are typically issued with float built in — two or three weeks here, a buffer there. In practice, that float is often gone before the first excavator arrives. Approvals take longer than planned. Procurement of a critical item slips two weeks because the market has changed since the estimate was built. A design query sits with a consultant for ten days because nobody owns turnaround times on RFIs.
None of this looks like a program problem in isolation. Collectively, it means the "float" reported at financial close was never real contingency — it was already spent covering pre-construction inefficiency, and construction inherits zero buffer against genuine site risk.
Design interfaces are treated as fixed, not live
On multi-package or multi-discipline capital works, the program usually assumes each design package is final at the point construction planning begins. On brownfield and live-operational projects in particular, that's rarely true — mechanical, electrical and civil interfaces keep moving as each discipline responds to site conditions the others didn't know about.
A program that doesn't have an explicit mechanism for absorbing interface changes — a standing coordination review, a documented process for re-sequencing when one package shifts — will show every one of those changes as a program slip, even when the underlying work hasn't actually grown. The slip is a symptom of poor interface management, not scope creep.
"Monitoring tells you the date has moved. Management asks why, whether the cause is systemic, and what needs to change in the next four weeks to stop it happening again."
Nobody actually owns the program once it's approved
This is the one we see most often, and the one that's easiest to fix. A program gets built and approved during tender or design development, and then ownership quietly disappears. The contractor updates their own construction program. The asset owner's team tracks milestones from a dashboard. Nobody is actively interrogating whether the baseline program still reflects reality, because nobody has been given clear responsibility for that question.
Program management is not the same as program monitoring. On most capital works programs that slip badly, there was a point — often early — where the trend was visible and nobody with authority was actively acting on it.
What asset owners can do differently
A few practical shifts change this pattern without adding bureaucracy.
- Build a formal re-baseline gate after early works or site verification, rather than treating the tender program as fixed for the life of the project. This isn't giving the contractor licence to move dates — it's acknowledging that the first program was built on the least information available and should be tested, not defended.
- Separate float that's genuinely available from float that's already been consumed by pre-construction friction, and report that distinction honestly to your stakeholders. A program showing three weeks of contingency that's actually already spent is worse than a program showing zero — at least the second one is honest.
- Assign clear, named ownership of the program to someone with the authority to ask hard questions of both the design team and the contractor, and the time to actually do it. On smaller capital works programs, this is often the single most valuable role that gets left out of the budget.
The bottom line
Program slippage is rarely a single dramatic failure. It's the accumulation of small, unmanaged decisions made before construction starts — a program locked too early, float quietly spent, interfaces left to sort themselves out, and nobody with clear authority watching the trend. None of that shows up on a compliance checklist. All of it shows up in the completion date.
Get program governance in place before the trend becomes a crisis.
S3NTEC works alongside asset owners and councils on program governance and delivery assurance — the ongoing discipline that catches a slipping program while there's still time to do something about it, rather than at the post-mortem.
Talk to Us →