Cost Overrun: Causes and How to Prevent Them

What causes cost overruns in projects?

Cost overruns are caused by decisions made before and during delivery that understate cost or add work without adding budget. Four causes explain most of the damage, and they reinforce each other: a low estimate wins approval, thin reserves absorb the first surprise, scope creeps in through small requests, and late reporting hides all of it until recovery is expensive. Contract terms then decide who pays.

Optimistic estimates and the planning fallacy

Estimates are usually built from the inside out: list the tasks, ask the people who will do them, add a percentage for “unknowns”. This method systematically fails because it ignores how similar projects actually finished. The team is not lying; it is imagining the project going well, which is the planning fallacy in its purest form.

A useful test: ask whether the estimate would survive contact with your own last three comparable projects. If your last three integrations finished 30% over, a 10% contingency on the fourth is not caution — it is a decision to repeat the result.

Scope creep and unpriced change

Scope creep is not one big change request. It is forty small ones, each justified on its own, none priced against the baseline. A report field here, an extra integration there, a stakeholder demo that turns into a requirement.

The mechanism matters more than the label. When a change has no cost attached at the moment it is accepted, it does not disappear; it moves into the delivery team’s overtime, into rework, or into the next estimate. The cost is real either way, but only one path puts it on the record.

Thin, or already-spent, risk reserves

A contingency reserve is supposed to absorb identified risks. Two failures are common. The first is arithmetic: the reserve is sized as a flat 10% because 10% feels defensible, not because anyone modelled the risk exposure. The second is behavioural: the reserve gets treated as available budget, so the first three variances consume it before the risky phase even starts.

Once the reserve is gone, every subsequent surprise becomes an overrun by definition, even if total spending is still reasonable.

Reporting lag and cost blindness

Many projects measure cost monthly, in a report produced by reconciling three systems that disagree. By the time the variance appears, the commitment has already been made: subcontracts are signed, materials are ordered, and the team is three weeks into a workaround.

Cost blindness has a second cost — it removes the option to choose. A 5% variance caught in week three can be fixed by re-sequencing. The same variance caught in month five can only be paid for.

Contract terms decide who pays

Fixed-price contracts transfer cost risk to the seller, until the seller discovers the scope was misunderstood and the change orders begin. Cost-plus contracts do the opposite: they make the overrun visible but leave the buyer holding it. Neither form prevents overruns; only clarity about what is included and who pays for a delayed decision does.

How large are cost overruns in the real world?

Large-sample evidence shows overruns are the norm rather than the exception, and that the size depends heavily on project type. Bent Flyvbjerg’s database of transport projects — 258 projects across 20 countries — found that nine out of ten exceeded budget, with a clear ranking by category.

Those averages hide enormous spread. Flyvbjerg’s wider database now covers more than 16,000 projects, and later work with Dan Gardner across 25 project types reports mean overruns from about 1% to 238%, with the Olympic Games averaging around 157% and IT projects around 73%.

For smaller, ordinary projects the numbers are less dramatic but the direction is the same. A study of 1,471 IT projects by Alexander Budzier and Flyvbjerg found an average overrun of 27%, and one in six overran by an average of 200%, with schedule slips near 70%.

The practical message: your project is not special, and “this time will be different” is the most expensive sentence in project planning.

Why is bad luck rarely the real explanation?

Bad luck explains individual events. It does not explain a pattern that repeats across countries, decades, and industries. When nine of ten projects overrun, the cause is structural, and the research points to two mechanisms that operate before construction even starts.

Optimism bias is the cognitive version: planners genuinely believe the project will go better than comparable projects did. Strategic misrepresentation is the political version: the estimate is deliberately low because a realistic number would not be approved. Both produce the same artefact — a business case that cannot survive delivery.

This is why overruns cluster in the pre-construction phase. Dutch research on transport projects found that each additional year of pre-construction activity added roughly five percentage points to the overrun, while the length of the construction phase barely mattered. The money is lost while the project is still a document.

There is a fair counter-argument: some researchers argue that optimism bias has become the explanation of convenience, and that execution factors — ground conditions, supply chain shocks, contract disputes, inflation — carry more weight than the bias literature admits. Both matter. Bias corrupts the baseline; execution converts it into money.

What does an overrun cost beyond the extra money?

An overrun costs more than the variance. It usually brings delay, and delay is expensive in its own right. Flyvbjerg’s transport research measured roughly 4.64 percentage points of additional cost overrun for every year of delay after the decision to build.

Three worked examples make the arithmetic concrete.

Example 1: the software migration. A migration is approved at $480,000 over six months. At month three, earned value is $210,000 and actual cost is $250,000 — a cost performance index of 0.84. If that efficiency continues, the final cost is 480,000 ÷ 0.84 = $571,428, an overrun of $91,428 or 19%. Nobody approved that; it emerged.

Example 2: the fixed-fee agency project. A $40,000 website build absorbs 52% scope creep, the rate PMI’s Pulse of the Profession survey reported for projects generally. At the survey’s average 27% overrun, the agency loses about $10,800 of margin — the entire profit on the job, and then some. The client never saw a change order.

Example 3: the delay multiplier. An $8 million rail project running two years late carries roughly 2 × 4.64% ≈ 9.3% of additional overrun in constant prices, about $744,000, before direct delay costs are counted. Delay and overrun are not separate problems.

How do you prevent overruns before the estimate is approved?

Prevention starts with the estimate, because that is where the overrun is created. The strongest single tool is reference class forecasting: instead of building the forecast from the project’s own task list, you compare it against a distribution of similar completed projects and adjust for your project’s specific risk profile.

The method has three steps. Identify a reference class of genuinely comparable projects. Build the distribution of their outcomes. Then pick the uplift that matches your organisation’s risk appetite — the median (P50) if a coin-flip chance of overrun is acceptable, or the P80 if you want four-in-five confidence.

The evidence is not merely theoretical. When reference class forecasting was introduced into a national procurement programme, average cost overrun on total procurement fell from 38% to 5%. Countries that adopted the method produced more accurate forecasts than those that did not.

Two cautions. Reference class forecasting is only as good as the reference class; a database of motorways will mislead you about a hospital. And it corrects the baseline, not the behaviour.

How do you stop scope creep without stopping useful change?

You stop scope creep by making change visible and priced, not by refusing it. A workable process has four elements: a written scope baseline, a single intake path for requests, a mandatory impact statement, and decision thresholds that say who may approve what.

The thresholds do most of the work, because they remove the daily negotiation. A useful pattern:

• Changes with less than 5 days and less than $10,000 of impact: project manager approves, logged in the register.
• Changes between $10,000 and $50,000 or up to 15 days: sponsor approves.
• Anything above that, or anything touching a regulatory commitment: change control board, with the funding source named before approval.

Two rules keep this from becoming bureaucracy. No approval without a named funding source — “we’ll absorb it” is how reserves disappear. And a rejected request must be logged with the reason, so the same ask does not return in three weeks with a different sponsor.

How do you spot an overrun while there is still time?

You spot an overrun by comparing earned value with actual cost on a fixed cadence, at a granularity fine enough to show which work package is bleeding. Project-level totals hide the problem: ten healthy packages can mask one that has already spent 140% of its budget.

Three signals are worth watching weekly:

1. Cost performance index trend. One reading is noise; three consecutive declines is a pattern.
2. Reserve burn rate. If 40% of the contingency is gone at 20% completion, the reserve was mis-sized.
3. Cost-to-complete revisions. Every rise without a scope change is somebody discovering rework.

Keep a one-line note next to each reading explaining the driver. “CPI fell to 0.91 because the integration vendor started three weeks early and the data cleanup was underestimated by 120 hours” is worth more in a steering meeting than the number itself.

What do you do once the overrun has already happened?

Once an overrun is real, you have four honest options and one dishonest one. The honest options are to cut scope to the budget, find more money, re-baseline with a new approved figure, or stop the project. The dishonest option is to keep reporting against a baseline everyone now knows is fiction.

Whichever you choose, recalculate the to-complete performance index first: (budget − earned value) ÷ (budget − actual cost). If the answer requires the team to deliver the rest of the work 25% more efficiently than plan, the plan is the problem, not the effort level.

Which mistakes make an overrun worse?

• Hiding the variance until the quarterly review. The information always leaks; the only question is who controls the timing.
• Treating the contingency as a slush fund. Reserves are for identified risks, not the first inconvenient invoice.
• Re-baselining silently. Updating the baseline without an approval record turns a variance into a credibility problem.
• Blaming the team. Optimism is a process defect. If the process rewarded a low number, the team delivered it.

Where does software fit into this?

Most teams do not run a $500 million capital programme, but they repeat the same pattern at a smaller scale: an estimate in a spreadsheet, a budget in finance, a schedule in a Gantt chart, and time tracked somewhere else. The monthly reconciliation takes two days and produces a number nobody fully trusts.

Keeping planned value, actual cost, and progress in one workspace shortens that loop from days to minutes. That is the problem Doitify is built for — tasks, sub-tasks, owners, budgets and progress reporting in one place, with dashboards that compare planned against actual. Doitify is our product, so treat that as a description rather than an endorsement; for a single 40-task project, a well-maintained spreadsheet is genuinely sufficient.

Conclusion

A cost overrun is rarely a surprise event and almost always a predictable one. Estimates built without reference to history, scope accepted without a price, reserves sized by habit, and reporting that arrives after the commitment explain most of the gap between business case and final invoice.

The leverage sits in three places: replace the inside-view estimate with a reference class forecast, attach a cost and a funding source to every accepted change, and look at cost and progress together every week. Do those three things and you will still miss sometimes. You will simply miss early enough to choose your response instead of explaining it afterwards.

If this post on cost overrun was helpful, you might also enjoy Free RACI Matrix Template and Project Management Software for Consulting Firms.