"How much will it cost and when will it be done?" The head of a software company answers that question almost every week – to a client, an investor or themselves. And almost everyone has learned that reality turned out differently. This is not an individual failure. The data show that estimating software is systematically hard, which is why it needs a system, not better intuition.
How wrong IT projects get
McKinsey, together with the University of Oxford, analysed more than 5,400 large IT projects. On average they ran:
- 45% over budget,
- 7% over schedule,
- and delivered 56% less value than predicted.
The second finding matters even more. Bent Flyvbjerg and Alexander Budzier of Oxford studied 1,471 IT projects and found that the average cost overrun (27%) is not really the main problem. The problem is the extremes: roughly one project in six was a so-called "black swan", with an average cost overrun of 200% and a schedule overrun of almost 70%. The McKinsey study reports the same figure – 17% of IT projects go so badly they can threaten the very existence of the company.
For a small software company this means one thing: do not plan for an "average" delay. Plan for the possibility that one of your projects goes completely off the rails, and make sure it cannot take the company down with it.
Why estimates fail
1. The cone of uncertainty. Barry Boehm and later Steve McConnell showed that at the start of a project the actual effort can be up to four times higher or four times lower than the estimate. Uncertainty only shrinks as you learn more about the project and make decisions – about scope, architecture, priorities. If scope is reopened later, the cone widens again.
2. The planning fallacy. People estimate from the "inside view" – they imagine how the project will go if everything goes to plan. Daniel Kahneman called this the planning fallacy, and Flyvbjerg built reference class forecasting on it (see below).
3. Big batches. The larger the chunk of work, the more hidden dependencies it has and the later problems surface. Both Oxford studies recommend splitting large projects into smaller phases with short delivery cycles.
Practices that work
Estimate from what already happened (reference classes)
Instead of asking "how long will this project take?", ask: "how long did similar projects we have already done take, and how far did they drift from the original estimate?" This is called reference class forecasting. If you know your e-commerce integrations have historically taken 40% longer than promised, add that 40% up front. There is just one condition: you need data on how much work your projects actually took.
Talk in probabilities, not dates
Instead of a single date ("done on 15 November"), give a range with a probability. The Monte Carlo method helps: take the team's historical throughput (how many tasks or story points it completed per sprint), simulate many times how fast it burns through the remaining backlog, and you get a distribution of possible delivery dates. Expedia Group's engineering blog shows a typical result: a 50% chance of finishing by one date and an 85% chance by a date several weeks later. The client gets an honest answer, and you know how much buffer to keep in the contract.
Make tasks smaller
Small tasks with clear acceptance criteria are estimated more accurately, finish faster and surface problems earlier. They also give you more data points for Monte Carlo – twenty small finished tasks say more about a team's pace than two big ones.
Track dependencies as dependencies
Many delays come not from slow work but from waiting – on the client, on another team, on a decision. When blocking relationships between tasks are recorded explicitly rather than buried in a description, you see in time what is holding the project back.
Plan for the black swan
Flyvbjerg and Budzier suggest a simple stress test: could the company survive if one large project cost four times as much and delivered only half the benefits? If not, split the project, add a validation phase or change the contract model (for example, a fixed price only for the first phase).
Putting it into practice
- Record the estimate and the actual for every task – without both you have nothing to learn from.
- After every project, calculate the actual / estimate ratio and use it as a multiplier for your next quote.
- Communicate deadlines as a range with a probability.
- Split large contracts into phases and offer a fixed price only for the phase you can estimate well.
- Review blocked tasks every week – they are the most common hidden source of delay.
Where mcptask.online helps
mcptask.online started as a tool for running a software company, and it collects exactly this data as you work. You estimate tasks in scrum points (S, M, L, XL…) and the system turns them into an hour estimate automatically. Actual time is logged straight from commits (for example "#Task-47 2h"), and timesheets (JSON, CSV, PDF) let you compare estimates with reality per project and per sprint. Dependencies between tasks are real blocker links – a blocked task drops out of the queue and comes back on its own once the blocker is done. And if you hand some routine tasks to an autonomous AI developer, its work is tracked the same way as everyone else's.
Want to estimate from your own data instead of gut feeling? Sign up at mcptask.online – the first 30 days are free, no credit card required.
Sources
- McKinsey & Company, University of Oxford: Delivering large-scale IT projects on time, on budget, and on value
- Bent Flyvbjerg, Alexander Budzier: Why Your IT Project May Be Riskier Than You Think (Harvard Business Review; full text on arXiv)
- Bent Flyvbjerg: Five Things You Should Know about Cost Overrun
- Bart Masters, Expedia Group Technology: Monte Carlo Forecasting in Software Delivery
- Cone of uncertainty (Boehm, McConnell)