Part I The decision: does it make sense?
Whether to build software at all, what it will cost over its whole life, and how you will know it paid off.
Chapter 1: Why software projects go over budget
On average, large IT projects run 45% over budget and deliver 56% less value than they promised McKinsey and Oxford, 2012. The main cause is not bad code but the first estimate, made at a point when you know almost nothing about the project. Waiting does not reduce the uncertainty; work does: a clear brief, a prototype, a data sample, and an estimate given as a range.
Overruns are not bad luck but the rule
McKinsey and the University of Oxford collected data on more than 5,400 IT projects. For large projects with an initial budget above USD 15 million, costs were 45% higher on average, delivery took 7% longer, and benefits were 56% lower than the business case promised. Every additional year of duration adds another 15% to the cost overrun. The average also hides extreme cases: 17% of IT projects go so badly that they threaten the very existence of the company. The authors call a budget overrun of more than 200% a “black swan” McKinsey and Oxford, 2012.
For planning, this leads to an unpleasant but useful conclusion: assume your project will not be the exception. What goes up for approval should be an estimate range and a contingency, not a single number. A four-year project is also riskier than four one-year stages, after each of which you decide whether to continue.
Why the first estimate can be off by a factor of four
At the idea phase (“we need a system for…”), the real cost can end up anywhere between a quarter and four times the first estimate. The upper bound is sixteen times the lower one. Once requirements are complete, the range is still 0.67× to 1.5×, and you only get to roughly ±10% after detailed design McConnell, 2006 and 2010. And that applies to experienced estimators. The cone below shows the best achievable accuracy. A real estimate can be even less accurate.
Imagine asking over the phone for a fixed price to renovate a house nobody has seen. You will get either a lowball quote followed by add-ons, or a price with a large buffer. Software is no different. It only makes sense to ask for a fixed price after analysis and a prototype (chapter 10).
A chart showing how far an estimate of cost and time can be off, depending on the project phase in which you make it. The cone narrows not with time but with decisions that remove sources of uncertainty McConnell, 2006 and 2010. An extra week of waiting will not make the estimate more accurate. A week spent on analysis, a prototype, or working with a data sample will.
Four traps customers set for themselves
Most problems are not caused by developers. In a 2014 PMI survey, 37% of organizations named inaccurate requirements as the main cause of project failure PMI, 2014. For Czech projects, the Supreme Audit Office (NKÚ) writes that the common denominator of failed eGovernment projects is underestimated business analysis NKÚ, 2026. Watch out above all for these four traps:
- A lowball estimate. The budget is fitted to what will get approved instead of being based on an estimate of the work. Test: does the internal estimate match exactly the money you have available? Then it is a wish, not an estimate.
- Absent management and users. IT writes the brief on its own and management only shows up at handover. Test: who from the business side will sign the brief and attend the demos?
- Ignored warnings. An architect or users warn about the deadline or complexity, and the warning disappears from the report. Test: do you know who raised a warning and who answered it?
- Not knowing your own processes and data. The data migration assumes clean data that nobody has seen. Test: are your processes documented, and have you seen a data sample?
The good news: you can prevent all four traps yourself. Start by asking yourself the questions above early.
Sometimes a low estimate is not a mistake but intentional: the project is underestimated so it gets approved. With Canada’s Phoenix payroll system, features were then cut instead of the budget being increased. A low internal estimate is as much a risk as a suspiciously cheap proposal.
How to narrow the cone before you sign
- Start with paid discovery: a small engagement that clarifies goals, scope, and risks and sharpens the estimate (chapter 14).
- Have a clickable prototype built and try it out with future users.
- Before issuing an RFP, prepare a sample of the data to be migrated and look at it.
- Ask for the estimate as a range, for example “most likely CZK 6 million, with 80% confidence under CZK 9 million,” and have the contingency approved separately.
- Compare the estimate with similar completed projects. Asking “how did others do?” is more honest than “it will be different for us.”
- Split a large project into stages. After each one, decide: continue, adjust, or stop.
| How it goes wrong | How to do it right |
|---|---|
| How it goes wrongThe budget is a single number from the first rough guess. | How to do it rightAn estimate range, with the contingency approved separately. |
| How it goes wrongA fixed price is requested at the idea phase. | How to do it rightPaid analysis and a prototype first, a fixed price only for a validated scope. |
| How it goes wrongIT writes the brief alone; management shows up at handover. | How to do it rightA product owner from the business and key users take part in the brief and the demos. |
| How it goes wrong“Our situation is unique, comparisons make no sense.” | How to do it right“Who has already done this, and how did it go?” Comparison with similar projects. |
| How it goes wrongWarnings from users and architects are treated as obstruction. | How to do it rightWarnings are recorded and have an owner who responds to them. |
| How it goes wrongThe data migration assumes clean data that nobody has seen. | How to do it rightA data sample, checked before the RFP goes out. |
| How it goes wrongOne large project spanning several years. | How to do it rightStages, each followed by a “continue, adjust, stop” decision. |
- The same applies, only mistakes cost more: a tender canceled by the Office for the Protection of Competition (ÚOHS), reduced grant funding, an NKÚ finding.
- NKÚ lists a low level of project and quality management and unmet objectives among the main barriers to the digitalization of the state NKÚ, 2026.
- You can narrow the cone even before the tender: through a preliminary market consultation under Section 33 of the Public Procurement Act (ZZVZ), or through a small contract for a working prototype (chapter 12).
- The digitalization of building permits shows where preparation leads when it is put off until a statutory deadline forces it (chapter 20).