A forecast that never moves is not stable, it is unexamined

Plot the forecast final cost of a capital programme, month by month, from sanction to today. Not the approved budget. The forecast.

On a healthy programme the line moves. It moves in both directions, in small amounts, continuously, because it is being revised by people who are learning things.

On a great many programmes the line does something else. It is flat for a long period, then steps, then is flat again at the new level. The step is reported as a deterioration and investigated as an event.

It was not an event. The information existed throughout the flat period, distributed across people who each knew part of it. What was missing was permission for the forecast to carry it.

Why the flat line is the finding

A forecast is an estimate of the outcome given what is now known. If what is known changes and the forecast does not, one of two things is true: either the new information was not material, or the forecast is not a forecast.

The second is far more common than the first, and the mechanism is mundane rather than sinister. Forecasts are produced by people who report, directly or eventually, to whoever is accountable for the number. Moving the forecast is therefore an act with consequences for the person doing it. Holding it costs nothing until the evidence becomes undeniable, at which point the accumulated movement arrives at once and is attributed to whatever happened most recently.

Nobody decides to suppress a forecast. It is suppressed by the ordinary operation of a reporting line, one reasonable deferral at a time.

Which is why the shape of the line is more diagnostic than its level. A programme forecasting a twelve per cent overrun that has been reporting it for six months is in better control than one forecasting four per cent that has reported four per cent since sanction.

The baseline underneath it

The second number is harder to get and more revealing.

Take the baseline currently being reported against, and reconcile it to the baseline that was sanctioned. Not approximately. In one continuous chain, with each movement between the two identified and approved.

On a large programme this frequently cannot be done, and the inability is itself the finding. Programmes rarely lose the baseline in a single visible event. It goes in a series of re-baselines, each individually reasonable, each properly approved, none wrong on its own terms. What nobody is looking at is the cumulative movement, because no report shows it: every report compares performance to the current baseline, which is precisely the thing that moved.

The related question is what was removed. Scope quietly descoped to hold a cost line will show up as an underspend against budget, which reads as good news in a monthly report and as a problem some years later when somebody looks for the thing that was deleted. Comparing current forecast against the original sanction figure, rather than against the most recent baseline, is usually the only number in the pack that surprises anybody.

Change that never reaches the change register

Change control works well on changes that enter it. Its weakness is definitional rather than procedural: it can only govern what somebody classified as a change.

The consequential ones frequently are not. They are reclassified, in good faith, as clarifications, as design development, as a site instruction, as a technical query resolved. Each of those routes is legitimate and each bypasses the register that was built to catch exactly this.

So the examinable question is not whether change control is being followed. It almost always is. It is whether anything that altered cost, programme or operating characteristics travelled by another route, and that requires sampling instructions and queries rather than reading the register.

A related test costs nothing: how many changes were approved after implementation rather than before. The retrospective approval rate tells you what the control actually is, as distinct from what the procedure says it is.

Why examining each package separately misses this

Contingency, read against progress

One more comparison, and it is the earliest legible warning available on most programmes.

Plot contingency drawn down against scope completed. Contingency is set to cover risks that are expected to occur but cannot yet be identified individually, and it is usually sized to give roughly equal probability of overrun and underrun. It should therefore deplete at broadly the rate the programme completes.

Where it depletes faster, the programme is consuming its allowance for future unknowns on present known problems. That is not necessarily wrong, and it is always worth knowing, because it means the remaining work is proceeding with less cover than it was priced with. It shows up long before the forecast moves, which is the point.

It also depends on somebody having recorded the confidence level the contingency was set at. Where nobody can say whether the estimate was a P50 or a P80, the drawdown cannot be interpreted, and an organisation treating a P50 estimate as a ceiling has misunderstood what it commissioned.

What the estimate declared about itself

Why so much delivery assurance returns so little

None of the above is difficult and none of it is expensive. The reason it is uncommon is that delivery is the stage where assurance is most abundant, and abundance is the problem.

There is a cost report every month, a schedule update every month, a risk register, a change register, an earned value calculation, a dashboard, and a steering committee. Every one of those is a genuine artefact and every one of them is easy to review. An assurance function with limited time will examine the artefacts, because they are there, because they can be sampled, and because examining them produces findings that can be written down.

The three tests above are different in kind. Each compares something against something else that the reporting pack does not put next to it: current baseline against sanctioned baseline, forecast movement against time, contingency against completion. None of them can be answered by reading any single document, which is exactly why none of them appears in a document.

The framework for this stage sets out all six domains, including the two this article deliberately leaves alone, interface coverage and the competence of whoever is doing the examining, both of which have their own arguments elsewhere.

Sources. AACE International Recommended Practice 56R-08, cost estimate classification for the building and general construction industries, revision of 7 August 2020, and 18R-97 for the process industries, for estimate classification and the treatment of contingency. ISO 21502:2020, guidance on project management, Clause 7, covering planning, scope, schedule, cost and change control. PMBOK Guide, Eighth Edition, November 2025, which carries scope, schedule and finance among its seven performance domains. ISO 55001:2024, Clause 8.2 on control of change and Clause 6.3 on planning of changes, ISO standard 83054. Standards published behind a paywall are cited without a link.