Monthly portfolio review. The project you presented two weeks ago as 'on budget' now shows up on the next slide 18% over plan. The commitment is already spent. There's no way to recover, because the spend that caused the variance happened weeks earlier, not in the last two.
The steering committee looks at the numbers, then looks at you. You reported reassuring figures that turned out to be false, even though you followed the reporting process exactly as designed. The report was formally up to date. Control, in substance, had already slipped weeks before.
Many think budget overruns are a forecasting problem. In reality they're an information-latency problem: most organizations compare plan versus actual on periodic cycles, monthly or at milestone close, instead of continuously. By the time the report lands, the spend has already happened and can no longer be recovered.
It's not that project managers estimate costs poorly. It's that the control system shows spend weeks after it was incurred. The gap isn't a skills gap. It's a structural timing gap in the data-collection cycle.
Why the gap forms
Cost is incurred when a supplier issues a purchase order, a team logs hours, or a subcontractor invoices. But that data only enters the project system after the accounting close cycle, often monthly, sometimes tied to a milestone close. In between, the project keeps spending without anyone seeing it against the plan.
According to the ZipDo Project Management Statistics Report (page updated June 2026), 55% of organizations don't track actuals against plan in real time. ZipDo aggregates data from multiple sources and doesn't publish the original methodology behind this figure in detail, so it should be read as an indication of how widespread the problem is, not as a precision measurement.
The intuitive fix that doesn't work
The most common reaction after an episode like the one in the opening scene is to ask for more frequent reporting: weekly instead of monthly. But if cost data sits unprocessed for weeks before it reaches the accounting system, a weekly report will simply show the same stale picture, more often.
The critical factor isn't reporting cadence. It's the upstream data latency, the time between when finance or the ERP records the cost and when that data reaches the project system. Changing reporting frequency without changing this latency doesn't fix anything, it just moves the problem further right on the calendar.
A simulation to see the mechanism
To illustrate the mechanism with different numbers from the opening scene, here's a separate simulation, explicitly declared as such.
Simulation: Subcontractor Cost Latency on an R&D Milestone — Simulated scenario
An R&D project has a milestone budget of €240,000. Actual subcontractor costs enter the accounting system 5 weeks after the spend actually occurs. With a monthly comparison cycle, the 22% variance on the Cost Performance Index is only detected at the second month's close, by which point the remaining budget no longer covers the next milestone. With an actuals feed updated weekly, even if not instantaneous, the same variance would be visible roughly 3 weeks earlier, leaving real room to reallocate resources or renegotiate scope.
The difference between the two scenarios isn't the quality of the initial forecast. It's the number of days between the spend and its appearance in the plan-versus-actual comparison. That time gap determines whether a decision is still possible or only a post-mortem remains.
What actually helps, and what it costs
Reducing upstream latency means getting an actuals feed from finance or the ERP on a weekly cadence, not quarterly or monthly. It's an organizational prerequisite before a technical one: it requires partial accounting close cycles to become a shared practice, not just an option in the project tool.
Trade-off
- Benefit: A weekly actuals feed shrinks the window between spend and visibility, leaving real room to act before the remaining budget becomes insufficient.
- Cost: It requires finance to produce more frequent partial extracts, adding operational load compared to a standard monthly close.
- Risk: Incomplete or provisional weekly data can trigger false alarms if it isn't clearly labeled 'partial estimate' versus 'consolidated actual.'
- Prerequisite: You need an integration between ERP/finance and the project system that supports weekly extracts, not just a change in reporting frequency.
- Limit: This mechanism shortens the time to detect a variance, but it doesn't remove the upstream causes: scope creep, supplier delays or optimistic initial estimates remain separate problems to solve.
The point of view
The instinctive reaction after being exposed in front of a steering committee is almost always 'let's check more often.' But checking a stale number more frequently just produces more confirmations of the same delay, not more time to act. The useful question isn't 'how often do we look at the budget,' it's 'how many days pass today between the spend and its visibility in our system.' Changing that second thing takes organizational work with finance, not just a new dashboard.
Where AI fits in, and where it doesn't
In ControlRoom, cost actuals connect to the EVM baseline deterministically: CPI, SPI and EAC are mathematical calculations, not estimates produced by a language model. AI steps in only after that calculation, to translate an already-quantified variance into an explanation a non-technical stakeholder can read, linking it to evidence already present in the system, such as change orders, supplier delays or scope notes.
Trade-off
- Benefit: AI turns an already-calculated CPI/SPI deviation into plain language, automatically linking it to existing evidence, cutting the time needed to prepare an explanation for the committee.
- Cost: It only works if the evidence, change orders, delay logs, scope notes, is already recorded in the system; AI doesn't invent it and doesn't go looking for it elsewhere.
- Risk: The main risk is misunderstanding: AI doesn't calculate the KPI, it explains it. Presenting it as an authoritative calculation engine for CPI would be a conceptual error, not just a communication one.
- Prerequisite: The upstream EVM calculation must already run on actuals updated with manageable latency; without that, AI would still be explaining old data, just more clearly.
- Limit: It doesn't compensate for upstream data latency: if actuals arrive late, the explanation arrives clear but late.
Checklist: How latent is your control cycle
- How many days pass, on average, between a cost being incurred (a purchase order, an invoice, logged hours) and it appearing in the project system?
- Does the plan-versus-actual comparison you present to the committee reflect last week's spend, or spend from 4-5 weeks earlier?
- If you increased reporting frequency without changing the accounting close cadence, would the displayed data actually change, or would it just stay stale longer?
- Who in finance could provide weekly partial extracts, and what would it take organizationally to make that a recurring practice?
- Is the evidence that would explain a variance, change orders, delays, scope changes, already recorded somewhere, or does it only exist verbally?
The real question to ask
An analysis published by Master of Project on March 19, 2026, based on HBR research, estimates an average overrun of 27% on complex projects, with a 'long tail' of overruns well above that average. The article states it draws on a dataset of more than 1,471 projects; we haven't independently verified the original study, so this figure should be treated as a widely cited industry estimate, not a measurement we've certified ourselves.
Many think budget overruns are a forecasting problem. In reality they're an information-latency problem: as long as the time between spend and visibility stays measured in weeks, any forecast, however accurate, will arrive after the fact.
Next step
Before you change your reporting cadence, map how many days currently separate spend from its visibility in your process. Compare that cycle against the pattern described here, and against a concrete case on evaluating progress in innovation contexts: read 'How to Evaluate Progress in an Innovation Project' to see how the same principle applies to status-progress KPIs, not just budget.