Why Software Projects Fail — and What Predicts It
Quick takeaways
- Roughly 31% of software projects fully succeed. About half are late, over budget, or missing scope. Around 19% are cancelled outright.
- Project size is the strongest predictor. Small projects succeed about 90% of the time. Large ones succeed less than 10% of the time.
- Slow decisions are nearly as damaging as bad ones. Teams with high decision latency succeed 18% of the time; teams that decide quickly succeed 63% of the time.
- Large IT projects run 45% over budget while delivering 56% less value than predicted, according to McKinsey and Oxford research covering more than 5,400 projects.
- Every extra year of schedule adds about 15% to the cost overrun. Long projects don't just cost more — they cost disproportionately more.
- The most effective single intervention is building less at once. Everything else is secondary to scope.
Nobody can point to the week it went wrong.
That's the strange thing about failed software projects. There's rarely a disaster — no server catching fire, no engineer quitting mid-sprint. There's a slow accumulation of small delays, a scope that grew in increments nobody separately objected to, and a launch date that moved three times, each time for a reason that sounded fine.
Then someone adds it up.
The research on this is unusually good, because two organizations spent decades collecting it. What it shows is that failure is more predictable than most teams assume — and that the things predicting it are almost never technical.
Software Project Failure Rate Statistics
The Standish Group published its CHAOS Report from 1994 until its final edition in 2020, drawing on a database of roughly 50,000 delivery projects across 1,000 organizations.
The headline split from that final edition:
| Outcome | Share |
|---|---|
| Successful — on time, on budget, full scope | 31% |
| Challenged — late, over budget, or missing features | 50% |
| Failed — cancelled before delivery | 19% |
Roughly two-thirds of software projects do not fully succeed, which is where the widely quoted failure figure comes from.
One honest caveat about this data
You'll see these numbers cited as the "CHAOS Report 2024." The report's final publication was 2020. Sources quoting a 2024 edition are either repeating a secondary source's error or referencing a different Standish product.
The figures also vary by definition. The same report presents outcomes under several measures — traditional, modern, and its own "Bull's Eye" definition — which is why one report gets quoted with different success percentages depending on which measure a source picked up. The 31/50/19 split is the modern-resolution version and the one most widely used.
It has improved
Worth saying, because the picture isn't static. In the original 1994 CHAOS survey, only 16.2% of projects succeeded, 31.1% were cancelled before completion, and the remainder ran, on average, 189% over their original cost estimate.
Success has roughly doubled in three decades. Cancellations have fallen by a third. The industry got better — it just started from somewhere appalling.
What Causes Software Projects to Fail
Five factors show up consistently. Only one of them is about engineering.
Project Size Is the Strongest Predictor
This is the clearest signal in the data, and the gap is not subtle.
| Project size | Success rate |
|---|---|
| Small | ~90% |
| Large | <10% |
Think about what that means for a decision. A large build isn't slightly riskier than a small one — it's roughly nine times less likely to fully succeed. Every other intervention on this list is a rounding error next to scope.
It's also the factor most within your control. You can't make requirements magically clear or decisions instantly fast. You can absolutely decide to build one workflow instead of six.
Decision Latency and Project Failure
The finding that surprises people most. Standish's research found that teams with high decision latency achieve around 18% project success, compared to 63% for teams that make decisions quickly.
A 45-point gap, driven entirely by how long questions sit unanswered.
The mechanism is simple once you see it. A team waiting on a decision either stops — expensive but visible — or proceeds on an assumption. The assumption is usually reasonable and occasionally wrong, and when it's wrong you don't find out until the work is built. Then it gets rebuilt.
Multiply that across a six-month project and you've spent a meaningful share of your budget on work that was thrown away, without anyone ever making a bad decision. They just made slow ones.
Unclear Requirements
The failure mode isn't an absent specification. It's a specification that describes the process on paper rather than the process as performed.
The two diverge more than anyone expects. The documented approval flow has three steps; the real one has three steps plus a phone call plus a spreadsheet that one person maintains. Build the documented version and you've automated something nobody does.
This is why watching people work beats interviewing them about it. People describe their process accurately and leave out the workarounds, because the workarounds stopped registering as unusual years ago.
Project Duration
McKinsey's research with the University of Oxford, covering more than 5,400 IT projects, found that the longer a project is scheduled to last, the more likely it is to run over — with every additional year adding roughly 15% to the cost overrun.
Duration compounds. A twelve-month project isn't twice the risk of a six-month one; it's meaningfully worse than that.
Agile vs Waterfall Success Rates
Agile projects succeed at around 64% versus 49% for waterfall, and the gap widens with size — large agile projects succeed at about 27% against 14% for large waterfall.
A real difference, worth having. But notice what it doesn't do: large agile projects still fail roughly three times out of four. Agile doesn't rescue an oversized project. It just fails more visibly, which is genuinely better than failing invisibly — you find out in month two instead of month nine.
Anyone selling a methodology as the answer to failure rates is reading the data selectively.
The Cost of Failed Software Projects
The McKinsey-Oxford study put hard numbers on it. Across the 5,400 projects examined, total cost overruns came to $66 billion — more than the GDP of Luxembourg. On average, large IT projects ran 45% over budget and 7% over schedule, while delivering 56% less value than predicted.
Those two halves together are the real picture. It's not just that projects cost more than planned. They cost more and deliver less, and the second half is the part budgets never capture.
The study also found that around 17% of large IT projects go badly enough to threaten the existence of the company running them — overruns above 200%, which occur far more often than a normal distribution would predict.
How to Reduce Software Project Risk
Four things, in order of impact.
Build less at once
The highest-leverage decision available, and the easiest to resist.
Take the narrowest slice that delivers real value, ship it, and expand from what you learn. Not a prototype — working software that someone uses to do a real job. That's the entire argument behind MVP development, and scoping it properly is where the value comes from.
This converts one large project with sub-10% odds into a sequence of small ones at roughly 90% each. It also surfaces the requirements nobody articulated, while they're still cheap to handle.
Most organizations resist this because the full scope is what got budget approval. That's an internal politics problem, not an engineering one, and it's worth solving before the build rather than during it.
The same logic applies to replacing systems you already run. Legacy modernization done incrementally works for exactly this reason — it turns one large project into a series of small ones.
Name a decision-maker with real authority
Given the 18% versus 63% gap, this is the cheapest intervention on the list.
One person, available, empowered to settle questions about how the business actually works, with a response-time commitment. Not a committee. Not someone who has to check with three others.
Agree it before the project starts. Agencies rarely ask for this, and they should.
Watch the work before specifying it
Someone spends two days sitting with the people who do the job. Following a real case end to end. Noting every "the system can't do that, so I…"
Two days, early, against six figures of rebuild later. Not close.
Insist on working demos every sprint
Not a status report. Not a percentage. Software you can open and use.
This is the only progress update that can't be wrong. A team demonstrating running software every two weeks cannot hide a problem for long. A team sending written updates can hide one for months — usually without meaning to, because nobody in the room knows it's a problem yet.
Frequently asked questions
What percentage of software projects fail?
Around 19% are cancelled outright and 50% are challenged — delivered late, over budget, or missing features. Only about 31% fully succeed. Combined, roughly two-thirds don't meet their original objectives. Those figures come from the Standish Group's CHAOS Report, whose final edition was published in 2020.
What is the main cause of software project failure?
Project size is the strongest statistical predictor — small projects succeed around 90% of the time, large ones under 10%. The most common contributing cause is unclear requirements, specifically the gap between the process as documented and the process as actually performed. Technology is rarely the root cause.
Does agile prevent project failure?
It improves the odds without solving the problem. Agile projects succeed at around 64% versus 49% for waterfall, and the gap widens on larger projects. But large agile projects still succeed only about 27% of the time. Method matters less than scope.
How much do failed software projects cost?
McKinsey and Oxford found that large IT projects run 45% over budget on average while delivering 56% less value than predicted. Across the 5,400 projects they examined, total overruns came to $66 billion. Roughly 17% of large IT projects overrun by more than 200%, which is enough to threaten the company running them.
How can we reduce the risk on our project?
Build less at once, name a decision-maker with real authority and a response-time commitment, watch the work before writing the specification, and require working demos every sprint. The first of those matters more than the other three combined.
Are these statistics still accurate?
The underlying dynamics hold. The CHAOS Report stopped publishing in 2020 and the McKinsey study dates from 2012, but the factors they identified — scope, decision speed, requirement clarity, duration — aren't tied to a particular technology era. Success rates have improved slowly since 1994, and the relationship between project size and failure has stayed remarkably stable throughout.
Where this leaves you
The uncomfortable finding in three decades of data is that failure is mostly a scoping problem wearing a technical costume.
Not developer skill. Not the framework. Not the methodology, much. The things that predict whether your project joins the 31% or the other 69% are how much you try to build at once, how fast you answer questions, and whether anyone watched the work before writing it down.
All three are decided before a line of code exists.
Which is why the build-versus-buy decision matters more than the technical choices that follow it, and why the cost and timeline conversation should start with scope rather than with a feature list.
If you're planning a build and want an honest read on whether the scope is survivable, our custom software development team offers a free consultation. We'll usually recommend building less than you asked for — the data is fairly clear about why.