De-risking Your Next Technology Programme: The Losses Nobody Budgets For

Most technology programmes are planned as if the future will be roughly like the plan: a little late, a little over budget, but basically on course. The evidence says otherwise. Programmes do not fail by a little. A small number fail by a lot, and those few account for most of the money lost.

This article sets out the three predictable ways programmes lose money, what the research says about each, and why a short, disciplined Discovery at the start is one of the best-value decisions a leader can make. There is a calculator to test it against your own programme.

Programmes don’t fail by a little

In a study of 1,471 IT projects, Bent Flyvbjerg and Alexander Budzier found an average cost overrun of 27%. That sounds manageable. But the average hid the real story: one project in six was a “black swan”, with an average cost overrun of 200% and a schedule overrun of almost 70% Harvard Business Review. A later analysis of 5,392 IT projects found that overruns follow a power law, a distribution with a fat tail, and that assuming they are roughly normal “grossly underestimates” the risk of extreme outcomes JMIS.

That changes how to think about risk. Contingency of 10–20% protects you against the average. It does nothing against the tail, and the tail is where the money goes.

The three losses

1. Rework

Effort spent redoing work that was wrong first time. Boehm and Basili’s summary of the evidence put avoidable rework at 40–50% of effort on typical software projects IEEE Computer. Later research found a wider range, falling to 10–20% in more mature organisations, which is itself the point: how much you lose to rework depends on how well you understood the problem before you started.

What drives it is well documented. A survey of 228 companies in ten countries found that incomplete or hidden requirements was the only problem consistently ranked among the top three, alongside communication flaws and underspecified requirements Empirical Software Engineering.

2. Runaway costs

The black swans. They are rare enough that every programme believes it will not be one, and common enough, one in six in Flyvbjerg’s data, that a portfolio of programmes almost certainly contains several. The UK public sector has its share: in 2019 the National Audit Office reported that the Emergency Services Network was forecast to cost £9.3 billion, £3.1 billion (49%) more than planned, with the old system’s switch-off three years late NAO.

3. Benefits that never arrive

This is the largest loss and the least visible, because it never appears on an invoice. In research with the University of Oxford covering more than 5,400 IT projects, McKinsey found that large IT projects ran 45% over budget and 7% over time on average, and delivered 56% less value than predicted McKinsey.

A programme that comes in on time and on budget can still lose most of its value, by building things people do not need. Product analytics data from one vendor found that 80% of features in the average software product are rarely or never used. It is vendor data, not peer-reviewed, but anyone who has looked at a usage log will recognise the pattern Pendo.

Why it keeps happening

The National Audit Office has reviewed 25 years of government digital programmes and found a “consistent pattern of underperformance”, often the result of “decision makers fixing on technology solutions before fundamental aspects” of the change “are sufficiently thought through” NAO. Its guide to digital transformation identifies “poor assessment of the complexities of the baseline starting point” as a key factor NAO.

None of this is unique to government. It is what happens anywhere a solution is chosen before the problem is understood, and then defended because so much has been invested in it.

Discovery: buying the right to change your mind

A Discovery is a short phase before you commit to building anything, to understand the problem, the people it affects and the constraints, and to test the riskiest assumptions. The GOV.UK Service Manual describes it as having no set length, with four to eight weeks typical, and is explicit that deciding not to proceed is a legitimate outcome GOV.UK. The Home Office has written about exactly that: deciding not to build a new service, and why stopping can be the right result Home Office Digital.

That last point is the one most often missed. The usual case for a Discovery counts the rework it avoids. Its biggest value is that it lets you change course, or stop, while that is still cheap. It is an option, not an insurance policy, and options are worth most when uncertainty is high, which is exactly when programmes are most tempted to skip them.

Other industries learned this long ago. In capital projects, research by the Construction Industry Institute links better definition before the investment decision with lower cost growth, schedule growth and change orders CII. Software is not construction, so treat it as an analogy, but the principle that Flyvbjerg and Gardner call “think slow, act fast” applies to both: planning is cheap, and building is where mistakes get expensive.

The economics

Take a £5 million programme expected to deliver £12 million of benefits, and apply the research above: 30% rework (conservative, between the classic figure and the mature-organisation figure), a one-in-six chance of a 200% overrun, and a 56% shortfall in benefits. On those figures, a programme like this one can expect to lose:

Loss	Expected
Rework	£1,500,000
Runaway costs, allowing for how often they happen	£1,700,000
Benefits that never arrive	£6,720,000
Total	£9,920,000

The three overlap a little, and no one can know exactly how much a Discovery will prevent. So the honest question is not “what is the ROI?” but “how much does it have to prevent to be worth it?”

A Discovery costing 3% of the budget, £150,000, pays for itself if it prevents 1.5% of those losses. If it prevents 15%, it saves over £1.3 million. The bar is so low that the real risk is not spending too much on Discovery; it is skipping it.

How to run one well

A Discovery is not a long study or a requirements document. It is a few weeks of a small team asking hard questions:

1. Frame the problem, not the solution. Ask “why?” until you reach the outcome the organisation actually needs, and write it down as a problem statement.
2. Understand the people. Talk to and observe the people who will use the service and the people who run it today. Map how the work really happens.
3. Map the territory. Assess existing systems, data, contracts and constraints, especially the ones nobody wants to talk about. This is where “the complexities of the baseline” get found.
4. Test the riskiest assumptions. List what has to be true for the programme to succeed, and test the ones that would sink it, cheaply and quickly.
5. Make it tangible. Use simple prototypes, not documents, so people can react to something real.
6. Recommend, and mean it. Proceed, change course or stop, with the evidence for each, and a clear view of what success would look like and how it will be measured.

What to do on Monday

1. Look at your portfolio, not your programme. If you run six or more, assume one is a black swan in the making. Which one?
2. Ask where the benefits will come from. For each programme, who will use what, and what will change? If nobody can answer, that is the Discovery.
3. Make stopping safe. Agree in advance that a Discovery recommending “don’t build” is a success, and reward it.
4. Put a price on the losses. Use the calculator with your own numbers, and see how little a Discovery needs to achieve.

If you are about to commit to a major programme and would like an independent view first, talk to us.

Sources

1. Flyvbjerg, B. and Budzier, A. (2011). Why your IT project may be riskier than you think. Harvard Business Review.
2. Flyvbjerg, B., Budzier, A. and others (2022). The empirical reality of IT project cost overruns: discovering a power-law distribution. Journal of Management Information Systems, 39(3).
3. Bloch, M., Blumberg, S. and Laartz, J. (2012). Delivering large-scale IT projects on time, on budget, and on value. McKinsey & Company, with the University of Oxford.
4. Boehm, B. and Basili, V. (2001). Software defect reduction top 10 list. IEEE Computer, 34(1).
5. Méndez Fernández, D. and others (2017). Naming the pain in requirements engineering: contemporary problems, causes, and effects in practice. Empirical Software Engineering, 22.
6. National Audit Office (2019). Progress delivering the Emergency Services Network.
7. National Audit Office (2021). The challenges in implementing digital change.
8. National Audit Office (2024). Digital transformation in government.
9. GOV.UK Service Manual. How the discovery phase works.
10. Home Office Digital (2025). Deciding not to build a new service: why stopping can be the right outcome.
11. Pendo (2019). The 2019 feature adoption report.
12. Flyvbjerg, B. and Gardner, D. (2023). How Big Things Get Done. Macmillan.