Project rescue

My software project is over budget and late. What now?

Last updated 9 October 2026

The honest starting point: there is no reliable published figure for how often private software projects overrun in the UK. Every page that gives you one is quoting a survey that has been taken apart in peer review. What does exist is the government’s own data about its own projects, and it is more useful than the folklore.

What the official data actually says

Two caveats that make this more useful rather than less. The assessing body itself says a red rating “does not mean failure – it signals that significant issues need urgent attention”. And this is a three-point scale: if you read a page quoting five bands including amber-red, it is quoting an edition from before 2022.

Narrowed to ICT specifically: 22 projects, down from 28 the year before, with a whole-life cost of £42.5bn and an average of 10.7 years to deliver. That last number is worth sitting with if your build is six months late.

The one official overrun percentage that exists

That is from the National Audit Office, January 2025. It is the only official UK digital-specific overrun percentage I could find, and it covers five named programmes rather than a population — so it is a worked set of examples, not a rate. Note the spread: 18% to 68%. A project does not overrun by an average amount.

About those famous failure statistics

You will have seen them: roughly a third of projects cancelled, half delivered at nearly twice the estimate, only some small fraction succeeding. They come from a commercially licensed survey series whose underlying data is not public, and the headline numbers in circulation originate in the mid-1990s.

More importantly, the methodology has been taken apart in peer review. Analysis published in IEEE Software found that defining success as adherence to the initial forecast of cost, time and functionality means the figures largely measure estimation bias. The authors put it bluntly: “Some organizations tend to overestimate while others underestimate, so their success and challenge rates are meaningless.”

Their worked examples are the convincing part. One organisation with genuinely accurate forecasts scored badly. Another that padded its estimates heavily — half its projects deviating by more than 233% — scored the highest success rate in the study. A company that forecast minimum durations scored 6%; inverting the same data would have scored it 94%.

So when someone tells you most software projects fail, they are repeating a number that rewards padding the estimate. It tells you nothing about yours.

What actually causes it, according to the people who audit it

The National Audit Office’s lessons report is refreshingly direct: “There is rarely a single, isolated reason which causes critical programmes to fail.” The problems it names are shifting business requirements, over-optimism, and supplier performance — and then it goes somewhere most commentary does not:

“Many of the problems stem from the inability of senior decision-makers to engage effectively.” The Comptroller and Auditor General has described failure as stemming from “decisions on technology being taken too early, before the business problem is properly understood”.

If that lands, it changes what you do next. A project that is late because the build is slow is a different problem from one that is late because the thing being built was never settled. Only one of those is fixed by changing supplier.

The decision, and what your contract allows

Sunk cost is not a reason to continue and it is not a reason to stop. The two questions worth answering honestly are whether the underlying problem is now properly understood, and what your contract actually permits.

Which of those you have depends on evidence you either started keeping in month one or did not. That is the real lesson for the next contract.

What a well-structured contract looks like

The UK government publishes its Model Services Contract free, and its architecture is a decent checklist even at a fraction of the scale: an implementation plan with named milestones; testing procedures where achievement is marked by a milestone achievement certificate; a rectification plan process engaged when a milestone fails; delay payments as a pre-agreed remedy; separate termination rights; and an exit management schedule.

The useful idea there is delay payments. A late milestone with a pre-agreed price attached is a commercial event. A late milestone with nothing attached is an argument.

In the background, the Supply of Goods and Services Act 1982 implies into a business services contract that the supplier will act with reasonable care and skill, and where no time was fixed, that it will perform within a reasonable time — with what is reasonable being a question of fact. That is a floor, not a remedy, and it is a poor substitute for milestones you can test.

Sources. Portfolio and ICT figures: NISTA Major Projects Annual Report 2025-26, published 13 July 2026, data as at 31 March 2026. NISTA took on the Infrastructure and Projects Authority’s functions on 1 April 2025. The five-programme overrun table: National Audit Office, Government’s approach to technology suppliers: addressing the challenges, HC 543, published 16 January 2025, Figure 4. Causes: NAO, The challenges in implementing digital change, HC 575, published 21 July 2021. The critique of the failure statistics: J. L. Eveleens and C. Verhoef, “The Rise and Fall of the Chaos Report Figures”, IEEE Software, January/February 2010. Contract structure: Cabinet Office Model Services Contract v2.2(A), buyer guidance last updated 1 September 2025. Implied terms: Supply of Goods and Services Act 1982, sections 13 and 14. All retrieved 9 October 2026. There is no official UK statistic on private-sector software project overruns; the figures above are about government projects and are presented as such. Not legal advice.