Why so many software projects go over budget

More than half of all projects go over their original budget. The cause is rarely where people look for it. It lies in the way the price was set at the start: a list of features, an estimate for each one, a sum.

Software project cost overruns: what the numbers say

You may know the scenario. A signed quote, an agreed schedule. Then, between the second and the sixth month, a first amendment that nobody had foreseen. Then a second.

This is not an isolated case. 52.1% of projects, all types combined, exceed their estimated budget, according to Flyvbjerg, How Big Things Get Done, 2023 (16,000 projects). IT projects fare worse: the average overrun reaches 80% over the quote, according to Flyvbjerg et al., JMIS 2022 (4,677 IT projects). In the same sample of 16,000 projects, across all sectors, only 0.5% of large projects meet budget, schedule and expected benefits all at once.

One project in two is no longer bad luck. Nor is it a project manager who did a poor job. At this scale, the method is at fault: the way the price of an IT project is calculated.

How the industry prices a software project

The method is the same at IT services firms, agencies and freelance developers, and it seems reasonable. The features are listed. Each one is estimated: so many days for this one, so many for that one. The estimates are added up, stacked like blocks. And out comes a budget, accurate to the day.

It looks like science. The figures are precise, the spreadsheet is tidy, the total is correct. But every line of the spreadsheet is a guess, and a sum of guesses is not a measurement. It is pseudo-science: it has the form of a calculation, not what makes a calculation reliable.

Adding up tasks to predict a duration is an idea that comes from mechanical engineering. It is Taylorism, industrial engineering: break the work down into tasks, plan everything before building anything at all, deliver once the plan is complete. A century later, software is still managed like an assembly line. But software engineering is not mechanical engineering. In software development, adding up tasks brings no predictability.

Science has been saying so for a long time: the whole is not the sum of its parts. In 1972, the physicist Philip Anderson (Nobel Prize in Physics, 1977) published “More is Different” in Science. His thesis: at each level of complexity, new properties emerge that cannot be predicted by studying the parts in isolation. Software development is not a sum of tasks.

P.W. Anderson, “More is Different”, Science, 177(4047), 393–396, 1972.

Software estimation: an estimate is still a guess

There is currently no scientific tool for reliably estimating development time: estimates are nothing more than very rough guesses, based on a list of features whose usefulness is still unknown to everyone.

This sentence says two things, and they add up.

The first: nobody knows how to estimate. Work that is repeated identically becomes predictable, and in fact it ends up being automated. Software, on the other hand, is always developed for the first time. Otherwise, it would be installed.

The second: the list itself. The specification is written before the software exists. And when Microsoft measures the effect of its ideas through controlled experiments, only one in three improves the target metric. One third has no effect, one third makes it worse (Kohavi and Thomke, Harvard Business Review, 2017). So when a specification is priced line by line, the two thirds that will not deliver the expected value are priced too. Nobody knows yet which ones they are.

Some teams say they have stopped estimating. In practice, they count the work completed over a period, take the average and project that pace onto what comes next. That is more honest than guesswork. But it is still a prediction. A guess about the future has been replaced by an extrapolation from the past. And if these teams have ended up there, it is because the people around them keep asking for forecasts.

Setting a price on a guess

Setting a price on these guesses creates the extra cost that many projects never recover from. And the software is still not usable during the months of development.

A price set on a list of features treats the project as a single block, to be delivered at the end. But software is not a group of frozen features. It is a set of features that can each be used on their own, and delivered one by one. The block means planning everything in advance, then waiting for everything until the end.

When the price and the list of features are fixed at the same time, all the risk falls on one of the two parties. And nobody can adapt any more. Every discovery made along the way becomes an amendment. Every amendment widens the gap with the quote. Managing the project ends up coming down to one thing: defending a list written on the day everyone knew the least.

Meanwhile, your teams wait. They discover the software when the budget has already been spent. And that is when you learn what they really needed. Not before.

How much does custom software cost?

The cost of developing custom software depends on the time you decide to invest in developing it and in adjusting it day to day to keep pace with your business, weighed against what its absence costs you.

You already know what its absence costs you. The same information entered into several tools that do not talk to each other. The errors this produces. The one person in the company who keeps all of it up to date. The expensive software your teams use only part of, and whose vendor does not make the adjustments you ask for. That is the figure to compare the investment with. Not an estimate.

The life of a piece of software begins in production. Treating it as a delivered project, then cutting maintenance to the minimum, is what turns it into a money pit instead of an asset. It also costs three to four times more to maintain than to develop (Applied Software Measurement, Capers Jones). So the project’s end date matters fairly little. What counts is what you invest over its whole lifetime.

To find out what developing your software would cost with our approach, where it is usable within a month, contact us.

Deciding how much time to invest, month by month

Before starting a development, you probably expect a duration and a price. That is what is usually given. As if everything could be foreseen. We do not know everything in advance. We prefer to say so. Giving a duration anyway would mean giving you a rough guess, which our profession wrongly calls an estimate. We do not do that.

The adaptive approach predicts what is predictable: the monthly budget and the development days per month. It does not try to predict the unpredictable: what your users will do with a feature before they have it in their hands. It asks a single question: what is the most useful thing to do now? And it answers it with what is known at that moment. Not with what was imagined on the day of the quote.

Nor does it look for the complete solution before delivering. That search has no end: “wanting to solve a problem completely or perfectly is the promise of a lead time that will tend towards infinity” (Frédéric Leguédois, talk “Éloge de la simplicité” (in French)). An incomplete solution is accepted, put in your teams’ hands as early as possible, and adjusted according to what they say about it.

This is how we work. We develop your custom application on a fixed budget, invoiced at the end of each month for the work done. It is usable within a month. Usable does not mean finished: your teams use it from the first month, and that use decides what we develop the following month. After that, we adjust it as your needs evolve for as long as you wish. The budget does not move. What we develop, on the other hand, follows what your teams learn by using it.

Your budget buys work on this problem, not its resolution. Each month you see what comes out of it, and you decide whether to continue.

And so that what worked last month still works this month, we apply the Zero-Regression Guarantee: every regression is fixed and covered by an automated test so that it does not come back, at no extra cost.

A trial period of up to 15 working days in the first month, and the deliverables belong to you as soon as you pay.

There is no longer an estimate to overrun. There is a budget you chose, and software your teams are already using.

Why so many software development projects go over their original budget