29 July 2026

Information Lag Is Where Australian Infrastructure Projects Lose Control

Consider a representative scene from owner-side advisory work. A director receives the contractor's updated programme on Monday morning. Her planner spends two days importing it into P6, comparing it to the baseline, checking the logic, and drafting a schedule health summary. By Wednesday the analysis is ready.

In those same two days, the contractor submitted three RFIs and one change order. At least one of them touches the critical path.

The analysis is accurate. It is also already partially irrelevant.

This is the information lag problem. On major Australian infrastructure programmes, it is not a minor inefficiency. It is where control quietly breaks down.

The Baseline Condition No One Wants to Say Out Loud

Schedule instability is not the exception on Australian government infrastructure projects. It is the norm.

Infrastructure Australia's 2026 Annual Performance Statement found that only 48% of Australian Government infrastructure projects by value had no change to time-to-completion in Budget 2024-25. That figure improved to 69% in Budget 2025-26 following governance reforms. Progress, yes. But nearly one in three projects by value is still showing schedule change, even after the reforms were applied.

Think about what that means for advisory firms on the owner side. They are not operating on a stable programme with occasional variation. They are working inside persistent, rolling instability. The critical path keeps shifting. The contractor's view of the world updates faster than the review cycle allows.

The commercial exposure from acting on stale analysis in that environment is real. A change order that crosses the critical path on Tuesday does not wait for Wednesday's programme review to matter.

What the Blowouts Are Actually Telling Us

The headline numbers from Australia's largest infrastructure programmes are well documented. The West Gate Tunnel has risen to $10 billion against an original estimate of $5.5 billion, running at least two years behind schedule. The Sydney Metro overran by at least $12 billion against its initial estimate. The bulk of near-term Victorian infrastructure funding now represents tail funding or previously unfunded cost overruns for projects including the Melbourne Metro Tunnel, North East Link and the West Gate Tunnel itself.

The instinct is to call these planning failures. Insufficient scope definition, optimism bias in early estimates, procurement risk transfer that never actually transferred the risk. All of that is partly true.

But planning failures do not compound in isolation. They compound because information and controls failures sit underneath them. A cost overrun that is visible at month three but not acted on until month seven is not a planning problem anymore. It is an information problem. The gap between the signal and the decision is where the money goes.

McKinsey research cited by SmartPM finds that 98% of megaprojects suffer cost overruns exceeding 30% and 77% finish at least 40% late. These same dynamics repeat at the $20 million commercial build and the $150 million healthcare facility. Scale amplifies the problem, but the mechanism is the same: by the time a cost overrun appears in a formal report, the window to correct it has already closed.

The Assumption Worth Challenging

Here is the belief most advisory firms hold without examining it: rigorous analysis requires time, and a two to three day turnaround on a programme review is professionally appropriate.

That belief conflates two different activities.

One activity is data assembly. Importing the contractor's programme, reconciling it against the baseline, extracting cost actuals, pulling earned value data from the project management information system, and reformatting everything to match last month's report structure. Earned value measures how much planned work has actually been completed against what was spent, so it sits at the centre of every cost and schedule health report. Data assembly is real work. It takes real hours. But it is not analysis. It is preparation for analysis.

The other activity is interpretation. Reading the schedule health indicators, forming a view on the contractor's logic, identifying where float has been consumed faster than progress warrants, and deciding what the client needs to act on this week versus next month. Float is the amount of time an activity can slip before it delays the project finish date. Interpretation is the judgement the client is actually paying for.

When data assembly consumes more than half the total hours on a programme review, the bottleneck is not the analyst. It is the process.

Nearly 40% of engineering firms experience document inefficiencies that lead to rework, miscommunication and compliance risks. Most teams are still moving information across shared drives, email attachments and separate platforms that do not talk to each other. Financial data, project controls, field inputs and reporting tools routinely sit apart, and the manual reconciliation between them creates the lag.

Controls leads across the industry describe the same pattern: rebuilding the reporting deck from scratch because the actuals moved again, spending three days pulling cost data from four spreadsheets to produce one slide, knowing the information is somewhere in the system but not being able to find it fast enough to matter.

This is not a description of an underskilled team. It is a description of a process designed for a slower information environment that has not been rebuilt for the one that actually exists.

Where the Lag Bites Hardest

The places where information lag creates the most commercial and legal exposure are predictable once you look for them.

Change order assessment is the most obvious. A contractor submits a change order on Tuesday. It references three RFIs and claims a critical path impact of eleven days. Your team needs to respond with a substantiated position. If the most recent schedule analysis your team holds is from Wednesday last week, you are assessing that claim against a baseline that predates some of the events the contractor is relying on. That is not a strong position.

Time extension assessments are worse. A contractor's extension of time claim will reference a sequence of delays. Some were flagged in weekly reports. Some were not. If programme reviews have been running two to three days behind the contractor's submissions throughout the project, there is a documentation problem that runs across months, not just the current claim.

And then there is the early warning function that project controls is supposed to provide. Poor information handling drives 26% of all construction rework through miscommunication and a further 14 to 22% through bad or inaccurate data. That combined failure rate exceeds every other single cause of rework, including workmanship. The controls function exists to catch problems before they become rework. It can only do that if the information is current.

What a Different Process Looks Like

The shift is not about replacing analysts with software. It is about reassigning where the hours go.

When data assembly is handled by a system built around the team's existing tools and formats, the analyst starts Wednesday with a populated comparison, not a blank import. The hours that previously went to reformatting go to interpretation instead. The client gets a schedule health summary that reflects Tuesday's submissions, not last week's programme. The change order assessment is grounded in current data.

This is not a theoretical posture. Version confusion, conflicting document iterations and hours lost searching for the right file are engineering firm problems in 2026. The technology to reduce them exists. What has not changed yet is the process sitting around it.

The advisory firms that will hold their position on major programmes are the ones that give their best analysts more time on interpretation and less time on assembly. Not because it sounds efficient. Because the programmes they are advising on are too commercially exposed for the alternative.

What to take back to work

Take the next major programme review your team produces and measure the hours honestly. Total time on data assembly, import, reconciliation and formatting. Total time on interpretation, narrative and recommendation.

If assembly takes more than half the total hours, the bottleneck is the process, not the person. That ratio is the number worth knowing before you decide whether the answer is more headcount or a different approach to the work.

One diagnostic question for this week: how many days passed between the contractor's most recent programme submission and the date your team's analysis was available to the client? If the answer is more than one business day on a programme generating RFIs and change orders continuously, the lag is already affecting your commercial position.

By Pedro Avila· Cerebro