The schedule said six months. But it never takes six months, always longer.

This is the scheduling problem that nobody talks about, because it feels too structural and too human to fix with a better Gantt chart or a new P6 template.

Most infrastructure program schedules are built on optimistic estimates. Not because the schedulers are incompetent. Not because the project managers are dishonest. Because optimism is the path of least resistance in a scheduling environment where challenging an estimate feels like challenging the person who gave it — and where the schedule is under political pressure from the moment someone puts a date in a business case.

The result is a schedule that looks like a plan but is more like a dream or aspiration. If wishing only made it so! A schedule that, as everyone in a major water, electricity or transport program knows, doesn’t survive first contact with a wet site, a constrained supply chain, or a contractor variation.

I’ve spent almost 20 years working in and around government and infrastructure projects, and a good portion of that time has been spent pushing back on optimistic schedules. Trying to convince management that realism isn’t pessimism. That just because a schedule can be drawn, doesn’t mean it reflects how the work will actually unfold.
What’s interesting is what happens next — or more accurately, what doesn’t. The slippage is rarely challenged. No one is really held accountable. Instead, the narrative shifts to risks, unforeseen events, external factors — anything except the underlying issue, which is that the schedule was built on optimism from the start.

That pattern is so common it’s almost invisible.

Most infrastructure schedules are built on optimistic estimates. Not because the schedulers are incompetent. Because optimism is the path of least resistance in a scheduling environment where challenging an estimate feels like challenging the person who gave it.

Does this look familiar?

The unachievable schedule that nobody truly believes announces itself in specific, recognisable ways. Most program managers on large infrastructure rollouts will see themselves in at least three of these.
The milestone that has been two weeks away for two months.

The schedule shows substantial completion next fortnight.It showed the same thing last fortnight. The fortnight before that it was the fortnight after this one. The date moves but the distance never closes.

The status report where everything is amber. Not red, never red — red requires an explanation and an escalation. Amber requires a note. So everything sits in amber, progressing, on track to recover, being managed. The schedule has become a risk management tool for the program manager, not a delivery management tool.

The schedule that gets updated after the fact. Progress is recorded when it happens. Dates are adjusted to reflect what actually occurred. The schedule is a diary of the past dressed up as a plan for the future. Nobody uses it to make a decision about what to do next week.

The contractor whose schedule and your schedule tell different stories. Your master schedule shows Package C at 60% complete. The contractor’s schedule, submitted last Friday, shows 47%. Neither of them matches what the site supervisor said on Tuesday. All three numbers are being reported upward with equal confidence.
The estimate nobody challenged.

An activity was estimated at six weeks in the planning phase. Nobody asked why six weeks. Nobody asked what assumptions sat underneath it, what risk allowance was built in, or whether the estimator had done this activity before in this type of environment. Six weeks went into the schedule. Six weeks became the baseline. Fourteen weeks later the activity is still in progress.

Why optimism wins every time and why that’s a system problem

The scheduling literature has a name for what’s happening: optimism bias. The tendency for people to estimate how long something will take based on how long they’d like it to take, rather than how long it is likely to take given the realistic range of outcomes.

On major infrastructure programs, optimism bias isn’t just a cognitive quirk. It’s structurally rewarded.

The business case that promises delivery in three years gets approved. The one that says four years, honestly accounting for sovereign risk, supply chain constraints, weather windows and contractor capacity, gets sent back for a revised scope. So the business case says three years.

The project manager or contractor who says the schedule is achievable gets the program. The one who says it needs six more months of contingency gets told to sharpen their pencil.

The scheduler who challenges the engineer’s estimate for the civil works package gets a reputation for being difficult. The one who takes the number as given and builds the schedule around it gets along fine.

None of this is a failure of individual character. It’s a system that selects for optimism at every decision point, then expresses surprise when the schedule fails to materialise.

The practical consequence is a schedule that has been optimism-biased at the activity level, the package level, the program level, and the portfolio level. By the time the master program schedule reaches the steering committee, it is carrying accumulated optimism at four or five distinct levels of the planning hierarchy. Nobody has stress-tested any of it. Nobody has challenged the assumptions. Nobody has asked “what’s your confidence interval on that estimate?”

And this is why the schedule gets ignored. Not because the people reading it are unsophisticated. Because they’re experienced enough to know, instinctively, that the numbers aren’t real.

The stress-testing gap

Here is the scheduling practice that separates high-performing infrastructure program offices from the rest: they contest the schedule before they baseline it.

Not aggressively, not combatively — but rigorously. They ask the questions that the schedule’s author needs someone to ask.

What’s the basis of this estimate? Is it analogous estimating from a similar project, parametric estimating from a model, or bottom-up from first principles? Each basis has different reliability and different risk.

What are the assumptions embedded in this duration? Continuous resource availability? Favourable weather? Contractor delivery timeframes? Naming the assumptions makes them visible and makes the risk discussable.

What does the range look like? Not just the point estimate, but the realistic optimistic case and the realistic pessimistic case. If the optimistic case is fourteen weeks and the pessimistic case is twenty-six weeks, scheduling against fourteen weeks is a deliberate choice, not a neutral one. It should be made consciously.

What has this activity cost in duration on comparable programs? Reference class forecasting — using the actual outcomes of similar past activities as a check on new estimates — is one of the most effective scheduling tools available and one of the least used. The data exists inside most infrastructure organisations. It rarely gets applied.

What happens if this activity slips two weeks? If the answer is “it’s not on the critical path,” fine. If the answer is “it delays three successor activities and pushes the commissioning date by six weeks,” that needs to be in the schedule risk register, not discovered at the two-week mark.

These questions aren’t sophisticated. They don’t require advanced scheduling software. They require a culture where the schedule is treated as a living argument about the future — one that should be challenged, defended, and improved — rather than a bureaucratic artefact that gets submitted and filed.

What incremental improvement actually looks like

Here’s the most important thing to say about fixing this problem: you can’t fix it and build a perfect schedule overnight. It is more cultural than procedural.

You fix it incrementally, over time, by building scheduling disciplines that gradually shift the estimates from optimistic to realistic, and by creating the conditions and environment where challenging an estimate is a professional norm rather than a personal affront.

The organisations that make this shift don’t do it through a scheduling transformation programme or a new project controls platform or a consultancy engagement that runs for eighteen months and produces a framework document. They do it through a series of small, consistent changes in how scheduling conversations happen.

They start requiring estimate basis documentation. Not a detailed methodology paper for every activity — a brief note on how the estimate was derived and what assumptions it rests on. This alone changes the quality of estimates because it makes the estimator think explicitly about their basis rather than producing a number from instinct.

They introduce schedule risk analysis as a standing practice. Not a one-off Monte Carlo simulation at business case stage, but a regular discipline where the program schedule is tested against a range of scenarios. What does the schedule look like if the top five risks materialise? If three of them materialise simultaneously? The answer is almost always “worse than the baseline,” and knowing that changes how contingency is set and how progress is reported.

They use the schedule as a management tool, not a reporting tool. The schedule should inform almost all decisions about the management of the project. It needs to be on hand and consulted in all decisions. What will this decision do to the schedule? What is the schedule telling us about the future that will help inform this decision?

They build a reference class library. Actual durations from completed activities on previous programs in the same sector. Ground conditions assessments that took eight weeks rather than four. Procurement processes that ran to sixteen weeks because that’s what procurement processes in this agency actually take. The library builds slowly and becomes more valuable over time. It’s one of the highest-return investments a mature PMO can make.

They train the people who build and read schedules. Not just schedulers — program managers, project managers, engineers with activity ownership, and the PMO staff who review and report on schedule performance. A schedule is only as good as the people interpreting it, and most of the people who rely on infrastructure schedules every day have never had formal training in how to read one critically.

None of these changes are revolutionary. None of them requires a new platform or a major organisational restructure. Each one makes the schedule incrementally more trusted. A schedule that is twenty percent more trusted than it was six months ago is a material improvement in how your program is run — not because twenty percent is a big number, but because a schedule that program managers actually use to make decisions is categorically different from one they ignore.

Where capability fits into this

The scheduling confidence gap in Australian infrastructure programs is not primarily a methodology problem or a tooling problem. It is a capability problem.

Most of the scheduling failures above trace back to people who were not formally trained in scheduling practice doing their best with the skills they had. Engineers estimating civil works durations by feel. Project managers building schedules in MS Project without a working understanding of critical path logic. PMO analysts reporting schedule variance without the skills to assess whether the variance is real or an artefact of how the schedule was built.

Closing the gap doesn’t require every person on the program to become a certified scheduler. It requires the people with schedule accountability — program managers, project controls leads, PMO staff — to have enough scheduling literacy to ask the right questions, read a schedule critically, and distinguish between a plan and a fiction.

That’s an achievable capability target. And it’s a much more productive starting point than waiting for the perfect scheduling system, the perfect data, or the perfect team before beginning.
The schedule your program deserves isn’t a perfect document. It’s a trusted one. And the distance between the schedule you have and the schedule you need is almost always shorter than it looks — if you know where to start.

Talk to us about building scheduling capability in your team.