Almost every software project budget is agreed before anyone knows enough to be accurate. That is not a failure of discipline, it is the nature of the work. What separates well-run projects is not better forecasting, it is how quickly the gap becomes visible.
This article sets out what the research shows about software project budget overruns, the three causes that repeat, and the practices that keep a project honest.
In this article
- What the research says about software project budget overruns
- Three causes that repeat
- Practices that keep a software project budget honest
- Questions to ask at the start
- What to do when a project is already over
- Frequently asked questions
What the research says about software project budget overruns
McKinsey, working with the University of Oxford, studied more than 5,400 IT projects. Large projects ran on average 45% over budget and 7% over time, and delivered 56% less value than predicted.
The third number is the one that deserves attention. Cost and time overruns are at least visible. Delivering less value than promised often goes unmeasured, because nobody wrote down what the value was supposed to be.
Other studies point the same way. The Standish Group’s CHAOS Report puts the share of software projects that finish on time, on budget and to expectation at roughly 31%. Stripe’s Developer Coefficient report found developers spend around 42% of their time on maintenance and dealing with poor code, which is budget that was spent long before anyone noticed.
Three causes that repeat
1. Scope grows without a recorded price
Each individual request against the agreed software project budget is small and reasonable. An extra field, a second report, one more user role. The problem is not the requests, it is that nobody writes down what each one costs in time at the moment it is agreed. By the end, the project is weeks late and no one can reconstruct why.
2. The estimate comes from the deadline
Someone needs it by a conference, a funding round or a quarter end. The estimate is then built backwards from that date rather than forwards from how long similar work has actually taken. Everyone in the room knows it, and nobody says it.
3. Slippage stays hidden until it cannot
Weekly status stays green because reporting amber invites questions nobody wants. The variance was knowable in week three and gets acknowledged in week eleven, when the only remaining options are expensive.
Practices that keep a software project budget honest
- Milestones that produce something runnable. Two to four weeks each. A demo cannot be faked the way a percentage-complete figure can.
- A change log with time attached. Every scope change recorded with its cost in days, agreed at the moment it is requested, not at the end.
- Estimates anchored to past work. Compare with what similar features actually took in your own history, not what the team hopes.
- Early bad news treated as good practice. If raising a risk costs someone politically, you have bought silence, and silence is the most expensive line item in the project.
- A named owner for the value, not just the delivery. Somebody has to answer what the project was supposed to change in the business.
The estimation side deserves its own treatment. Our note on software project estimation covers where numbers usually go wrong before work even starts.
Questions to ask at the start
- What is the first milestone that produces something we can actually use, and when is it?
- Who records scope changes, and where does that record live?
- What similar work have you delivered, and how did the final cost compare to the original estimate?
- How will we know in week three that we are behind, rather than in week eleven?
- What business number should change once this ships?
These questions sit alongside the broader selection criteria in our guide to choosing business software that gets used.
When a software project budget is already over
Most advice about the software project budget assumes you are at the start. Often you are not. Three moves are worth more than any recovery plan written in a hurry:
Re-baseline honestly, once. Produce a single revised estimate built from what the team has actually delivered so far, not from the remaining wish list. A second optimistic plan costs more credibility than the first overrun.
Cut scope, not quality. Reducing testing or review to hit a date moves the cost into maintenance, where it is larger and harder to see. Remove features instead, and write down which ones.
Decide whether the value still exists. If the reason for the project has changed, stopping is a legitimate and often correct outcome. The money already spent cannot be recovered by spending more of it.
Whether to continue is easier to answer with a measurement framework in place. Our 90-day method for measuring software ROI sets one out.
How a software project budget drifts, week by week
Overruns rarely announce themselves. A typical twelve-week engagement drifts in a pattern worth recognising, because every stage has a cheap intervention available.
Weeks one to three. The team is learning the domain and the existing systems. Progress looks slow but the plan still says green, because the first milestone is far enough away that nobody has to admit anything. The cheap intervention here is a deliberately small first deliverable, so reality arrives in week three rather than week eight.
Weeks four to seven. Scope requests begin. Each one is small, each is agreed verbally, and none are costed. This is where most of the eventual overrun is created, and it is created in conversations that nobody writes down. The intervention is a one-line change log entry with days attached, agreed in the room.
Weeks eight to eleven. The team knows the date is at risk. Reporting stays green because amber invites scrutiny. Everyone works longer hours instead, quality drops, and defects start accumulating in work already marked done. The intervention is cultural rather than procedural: the first person to raise the risk has to be thanked, visibly, or the silence continues.
Week twelve. The overrun becomes official, and the available options are all expensive: pay for more time, cut quality, or ship something that does not do the job. The cost of acting in week four would have been a conversation. The cost of acting in week twelve is a renegotiation.
Who should own the software project budget
In most companies the software project budget is owned by whoever signed the contract, and the delivery is owned by whoever runs the team. The gap between those two people is where overruns live, because neither of them owns the question of whether the work is still worth doing.
A better arrangement names one person accountable for the business outcome, not the deliverable. That person approves scope changes, sees the change log, and has the authority to stop the project. Without that authority the role is reporting, not ownership.
One practical test: ask who would have to approve stopping the work tomorrow. If that answer takes more than a few seconds, accountability is spread across enough people that nobody holds it.
For a smaller company this is usually the founder or the head of the function that asked for the system. The important part is not seniority, it is that the person can say no to a scope request without needing permission.
Frequently asked questions
How much do software projects typically go over budget?
Research by McKinsey with the University of Oxford across more than 5,400 IT projects found large projects run on average 45% over budget and 7% over time, while delivering 56% less value than predicted.
What causes a software project budget to overrun?
Three causes repeat: scope that grows without anyone recording the cost, estimates built from a desired deadline rather than past delivery data, and status reporting that hides slippage until the final weeks.
How do you keep a software project on budget?
Break the work into two-to-four week milestones that each produce something runnable, record the cost of every scope change at the moment it is agreed, and make early bad news normal rather than punished.
In short: a software project budget rarely fails in a single moment. It drifts, quietly, while reporting stays green. The practices that help are unglamorous: short milestones, recorded changes, and permission to say the number is wrong. If you are pricing work now, our published software outsourcing rates in Vietnam give a reference point before any vendor conversation.
