The Standish Group has been tracking software project outcomes since 1994. Their research, known as the CHAOS Report, is probably the most referenced body of work in the industry on this topic. The numbers have shifted over the years, but the story has stayed roughly the same.
of software projects are fully delivered on time, on budget, and as scoped - according to the most recent Standish CHAOS data spanning 50,000 projects1
Stop and sit with that for a second. Fewer than one in three projects fully deliver on what they set out to do. The other 71% are either late, over budget, missing features, or canceled outright.
The natural reaction is to assume this is a technology problem. Bad code. Wrong stack. Underqualified developers. That's almost never what it is.
The Usual Suspects
The research is pretty consistent on what actually drives failure. Requirements problems - unclear, incomplete, or constantly changing - show up at or near the top of every serious study on this topic.2
of project failures trace back to a lack of clearly defined objectives and milestones. The single biggest cause of failure identified in project management research3
The Project Management Institute found that scope creep, almost always a symptom of poor requirements, affects roughly 52% of projects.4 McKinsey put it even more bluntly in their research on large-scale digital transformations: 70% of those efforts fail to meet their objectives.5
These aren't outliers. This is the industry.
And when you dig into the case studies behind the statistics, the pattern is almost always the same. Not a technology failure. A communication and clarity failure. Someone built something. It just wasn't the right something.
What This Looks Like in Practice
The classic failure mode isn't dramatic. It doesn't announce itself. It starts with a kickoff meeting where everyone is nodding along, and nobody is quite sure they're nodding at the same thing.
The client knows what problem they have. They may not know how to articulate it precisely, and they definitely don't know how it maps to a technical solution. So they describe what they think they want. The development team hears what they think the client said. Both parties leave the meeting feeling good about it.
Six months later, the software is done. It does exactly what was specified. And the client looks at it and says, "this isn't what I needed".
Nobody lied. Nobody was incompetent. The requirements just never accurately described the actual problem.
The gap between what a client asks for and what they actually need is where most projects quietly fall apart - long before a line of code is written.
The other common failure mode is the slow drift. A project starts with a clear scope. Then a stakeholder asks for one small addition. Then another. Each individual ask seems reasonable. Nobody wants to be the person who says no to something small. But small additions compound. Timelines stretch. Budgets blow out. By the end, the project barely resembles what was originally planned, and it took twice as long and cost twice as much to get there.
Scope creep rarely feels like scope creep while it's happening. It feels like being helpful. That's what makes it dangerous.
The Standish research specifically calls out lack of stakeholder involvement and unclear requirements as the top two contributors to project failure, and they've been saying that since 1994. The industry has known this for thirty years and keeps making the same mistakes.
Why It Keeps Happening
The uncomfortable answer is that doing requirements well is hard. Not technically hard. It doesn't require any special software or methodology. It's hard because it requires slowing down before you start, which feels unproductive when everyone is eager to build something.
It requires asking questions that feel too basic, having conversations that feel repetitive, and documenting things that seem obvious. It requires someone to say "I don't think we understand this well enough yet" when the pressure is to just get started.
Most projects skip or rush this phase. They treat requirements gathering as a checkbox. Something you do once at the beginning to satisfy a process. Rather than as the most important investment you can make in the project's outcome.
The other piece is that requirements don't just live at the start of a project. A good requirements process is ongoing. The Standish research found that shorter, iterative delivery cycles, getting working software in front of users early and often, significantly improved success rates. Because the fastest way to discover what the requirements actually are is to show someone something real and let them react to it.
What You Can Do About It
If you're about to kick off a software project, the highest-return thing you can do before writing a single line of code is invest real time in making sure the problem is genuinely understood.
Start by asking: if we built exactly what you just described, would that solve the problem? The answer is almost always more complicated than a yes.
That means being willing to ask obvious questions. What does success look like, exactly? What does failure look like? How do you do this today, and what specifically is broken about it?
It means getting the people who will actually use the software into the conversation early, not just the people who approved the budget. The Standish data consistently shows that user involvement is one of the strongest predictors of project success.
And it means being honest when things are unclear. Ambiguity at the start of a project doesn't disappear when you start building - it just gets more expensive.
The statistics on software project failure are genuinely alarming. But the causes are well understood and the solutions aren't mysterious. Most of the time, the gap between a project that succeeds and one that doesn't comes down to how seriously everyone involved took the work of understanding the problem before they started solving it.
Standish Group, CHAOS Report: Beyond Infinity (2020). Study of 50,000 projects. Full report is behind a paywall; success/failure figures widely cited in industry literature. See also: Henny Portman's public review. ↩
Escrow London, 5 Reasons Why Software Development Projects Fail (2023), citing Standish Group CHAOS Report 2021. ↩
PMI, Scope Patrol - Pulse of the Profession 2018. The 37% figure for unclear objectives as the leading cause of failure is cited across multiple PMI research publications. ↩
PMI, Pulse of the Profession 2018. Scope creep affected 52% of projects completed in the prior 12 months, up from 43% five years earlier. ↩
McKinsey & Company, Common pitfalls in transformations (2022). Research shows transformation efforts fail approximately 70% of the time. ↩
Want to work together?
If you're building something and need help making it great, we'd love to hear about it.
Start a project