Tech project estimates: give the board a range
Take the board a cost range with review triggers, not a single number. In a study of 1,471 IT projects, cost overran by 27% on average, but the average hides the risk: about one in six projects overran by 200%. A single number promises a precision the record does not support.
Why is a single number the wrong format?
Because it turns an estimate into a promise. When you say "$240,000" and the project lands at $300,000, the conversation stops being about what changed and becomes about who got it wrong. Many boards have seen this happen and discount the number before hearing the rest.
A range changes what is under discussion. It shows where the estimate is firm and where it is not, and what the difference could cost. Someone who presents a range with written assumptions shows they know the risk instead of hiding it.
What does the data say about technology project overruns?
It says the problem sits in the tail, not the average. Bent Flyvbjerg and Alexander Budzier, of the Saïd Business School at the University of Oxford, analyzed 1,471 IT projects and published the result in Harvard Business Review in 2011. The average overrun was 27%. About one in six projects, though, had a cost overrun averaging 200%, with a schedule overrun of almost 70%.
In 2022, Flyvbjerg and five other authors widened the base to 5,392 IT projects, in the Journal of Management Information Systems. Their finding is that overruns follow a power law: many projects with small deviations and a few with extreme ones. Anyone who plans as if error were symmetric around an average underestimates the chance of a large overrun. The authors propose, with simulation, that interdependence among technology components helps explain the tail: a problem in one component sets off others.
One limit is worth stating plainly. The 2011 sample is made of large projects, with an average cost of $167 million per project, and 92% of them came from public agencies. The percentages are not a forecast for a project your size. What you take from them is the shape of the risk: a few projects concentrate most of the overrun, and the average does not tell you which one will be yours.
The UK Treasury reaches the same conclusion from the public-sector side. Its supplementary Green Book guidance on optimism bias says that appraisers tend to be too optimistic and that costs, benefits and durations should be adjusted explicitly, based on past or similar projects. The guidance attached to that page gives uplift percentages by generic project category, for use when better primary data is missing, and we do not reproduce them here.
How do you build a range the board can approve?
With three decisions: split the project into stages, write the assumptions for each one, and define in advance what forces a new decision.
The first is splitting. Flyvbjerg and Budzier's own recommendation is to break large projects into parts of limited size, complexity and duration, and each part limits how much an overrun can cost. Each stage has to deliver something that works on its own, so the board can stop there without losing what it has already paid for.
The second is writing the assumptions. The range for each stage depends on things you have not yet verified, such as the quality of the data to be migrated and the number of integrations. List each one. When one fails, the trigger fires for a reason everyone already knew, not as a surprise.
The third is the trigger. Agree beforehand when the project returns to the board: when the stage's accumulated cost passes the top of the range, when an assumption proves false, or when scope appears that was not in the request. Without that rule, the range becomes an excuse to spend more.
The range comes from your own record when you have one. If the company has delivered similar projects, compare the original estimate with the final cost of each and use the spread as a base. If there is no record, the range should be wider and the first stage smaller, so the first project produces the data that is missing.
A practical example: a request for a production order system
This scenario is hypothetical, and the figures are illustrative, not measurements. A packaging manufacturer with 120 employees wants to replace its production order control, today split between spreadsheets and the ERP, with an internal system. The innovation manager has two ways to take the request to the board.
In the first, she presents a budget of $240,000. If the bill closes at $300,000, the discussion will be about her error.
In the second, she presents three stages, each with a range and its main assumption written down. Stage 1, the core of orders and production logging, runs from $60,000 to $85,000 and assumes the product master data is clean. Stage 2, the integration with the ERP and shipping, runs from $90,000 to $130,000 and assumes the ERP exposes the data needed. Stage 3, the management dashboards and the customer portal, runs from $60,000 to $85,000. The sum is a range of $210,000 to $300,000.
The immediate request is only stage 1, capped at $85,000. Before approval, she asks the board one simple question: if stage 1 costs double, does the company carry on? The question is ours, not a rule from the studies, but it applies their idea of testing whether the company can absorb an overrun. If the answer is no, the problem is the size of the stage, and the stage shrinks before it starts.
The trigger is also agreed: if the accumulated cost of stage 1 passes $85,000, or if the product master data turns out worse than assumed, the project returns to the board before stage 2 begins. The stage 1 data becomes the record that narrows the range of the stages that follow.
Delivering in stages is not theory for us. In the UniTrust case, a US insurance IMO, Yowpi was hired in August 2022 and had the first system live within two weeks. The platform evolved on that base over the following years.
Where the range fits among the request's other arguments
The range settles the cost question, and the request still needs its other arguments. Delaying a tech project has a cost covers the other side of the ledger: what the company pays while it waits. And Justify technology investment to the board shows how to tie the request to a result the board already tracks. The cost range keeps both from being contradicted by the first overrun.
Frequently asked questions
I cannot justify the investment right now. Does a range weaken the request?
Not necessarily. The range shows that the risk was considered, and a small first commitment, stage 1 alone with a cap, is easier to approve than a whole fixed-price project. What weakens the request is a range without assumptions.
The implementation will take too much of the team's time. How do stages help?
They limit how much time you ask for at once. Instead of reserving the team for months, you ask for the hours of stage 1 and use what it shows to estimate the next one. The review at the trigger is short: accumulated cost against the range, and the state of the assumptions.
I do not see how to measure the result. Does the range change that?
It changes when you measure. Define in stage 1 which indicator will show the gain, and measure the baseline before you start. Then, at the review, the board sees cost and result together, and the decision to move to stage 2 rests on data, not expectation.
The next step
If your investment request is tied to a single number today, the Operational Architecture Diagnostic, a 30-minute conversation, is an invitation to design the stages, assumptions and triggers before you take the project to the board: talk to Yowpi.
Related case studies
Did you recognize your operation in this article?
Book the Operational Architecture Diagnostic: 30 minutes to map where your operation's bottleneck is. No proposal in the first conversation.
Book a diagnostic