Almost anyone who has ever owned a software project knows the pattern. The kickoff is euphoric, the timeline ambitious, the budget "realistic." Six months later, half the money is gone, half the features are missing, and nobody is entirely sure anymore what was supposed to be built in the first place. What feels like individual bad luck is, in fact, the statistical norm. The data behind it has been remarkably stable for decades — and it points fairly precisely to where the problem lies.
Failure Is the Rule, Not the Exception
The best-known long-running study of IT project outcomes is the Standish Group's CHAOS Report. In its 2012 analysis (published in the CHAOS Manifesto 2013), only 39% of projects were rated successful, 43% were "challenged" — completed, but late, over budget, or with fewer features than planned — and 18% failed outright, meaning cancelled or never used.
As sobering as that sounds, it's actually an improvement. In the first major CHAOS survey back in 1994, the success rate was a mere 16%. Over nearly two decades it climbed from 29% (2004) to 39% (2012) — and stubbornly stayed below the halfway mark. More than a decade of methodology improvements, the agile wave, and better tooling has not pushed the baseline odds of a software project going cleanly to plan beyond "roughly two in five."
One fair caveat, because serious readers deserve it: the Standish methodology is contested in academic circles (e.g. Eveleens & Verhoef, IEEE Software, 2010). The criticism is that "success" is defined narrowly around hitting the original estimate. Read the figures as an order of magnitude, then, not as a measurement to two decimal places. It doesn't change the direction of the finding — other sources arrive at the same picture independently.
Late, Expensive, and Less Than Promised
If "challenged" feels abstract, the overrun figures make it concrete. In the 2012 Standish data, 74% of projects were not delivered on time, 59% exceeded their cost estimate, and on average only 69% of the originally planned features were actually delivered. Put differently: even when a project doesn't officially fail, the organization on average doesn't get about a third of what it paid for — later and more expensively than budgeted.
Just how wide the gap between promise and result can get is captured by a heavily-cited large-scale study from McKinsey together with the University of Oxford. Across more than 5,400 IT projects, large initiatives ran on average 45% over budget, 7% over schedule — and delivered 56% less value than originally predicted (McKinsey & University of Oxford, 2012). Not 56% fewer features — 56% less value. That is the heart of the problem: it doesn't just get more expensive and slower, it frequently ends up building the wrong thing.
That waste carries a price you can put a number on. The Project Management Institute (PMI) calculates that 9.9% of every dollar invested is lost to poor project performance — $99 million for every $1 billion (PMI Pulse of the Profession, 2018). For a small or mid-sized company without eight-figure budgets to absorb the hit, that share is often the difference between "worth it" and "we should have left it alone."
The Cause Is Almost Always the Same
The most striking thing in the data is not that so many projects fail, but why — because the answer is consistent across sources. It's rarely the technology. It's the requirements, and the communication around them.
In the CHAOS Report, the top causes for "challenged" projects are lack of user input, incomplete requirements, and changing requirements — separated from one another by only fractions of a percentage point.
The success factors tell the same story in reverse: the three biggest reasons a project succeeds are, per Standish, user involvement (15.9%), executive management support (13.9%), and a clear statement of requirements (13.0%).
PMI quantifies the same root cause even more directly: nearly half (47%) of unsuccessful projects fail to meet their goals because of inaccurate requirements management (PMI, 2014). And PMI explicitly notes that unclear requirements aren't one cause among many — they're the common source of several classics at once: scope creep, poor communication, weak stakeholder involvement, inadequate sponsorship.
Translated out of statistics-speak, it's simply this: the most common reason software turns out expensive, late, and disappointing is that at the outset nobody really knew — or precisely articulated — what was actually supposed to be built. Not out of incompetence, but because specifying what you want is itself the hardest task in the whole project. The business side thinks in workflows; engineering thinks in data models and edge cases; and between the two sits a gap nobody takes seriously in the first few weeks — and that gets more expensive to close every single week thereafter.
Scope Creep: The Target Moves While You're Building
When it isn't clear at the start what should be built, it gets "refined" during the build — and that, too, is measurable. According to PMI, 52% of all projects completed in a given year experienced scope creep — uncontrolled growth in scope — a marked rise from 43% five years earlier (PMI Pulse of the Profession, 2018).
PMI's ranking of failure causes reads accordingly (multiple answers allowed): change in organizational priorities (39%), change in project objectives (37%), inaccurate requirements gathering (35%), followed by inadequate vision (29%) and poor communication (29%). The top three all describe the same phenomenon: the target was never sharp enough to stay still.
This is the genuinely frustrating part. Scope creep always feels reasonable in the moment — each individual change has a good justification. In aggregate, though, that's exactly the mechanism that turns a six-month project into a fourteen-month one. And it bites hardest when the original specification was vague: where nothing precise is written down, anything can be "clarified" in.
The Good News Is in the Data Too — and It Favors Smaller Companies
So far this reads like an inescapable law of nature. It isn't. The same Standish dataset that produces the sobering headline numbers also contains perhaps the single most important lever there is — and it's tailor-made for small and mid-sized companies.
Project size is the strongest single predictor of success. Small projects (under roughly $1M of effort) have a success rate above 70% — in 2012 specifically 76% successful, only 4% failed. Large projects (over $10M) managed just 10% success that same year — and they're roughly ten times more likely to fail outright than small ones.
That's no accident; it's a direct consequence of the requirements problem. In a small, clearly bounded effort, you can still grasp what you want. The distance between the business side and engineering is short, feedback happens in days rather than months, and a misunderstanding costs a week, not a quarter. That advantage — small, sharply defined, quickly verifiable units — is something smaller companies have structurally, while large enterprises have to manufacture it at great cost. For context: at the level of large enterprise transformations, BCG puts the success rate at just around 30%, with up to 70% failing to meet their objectives (BCG, 2023). Sheer size is not protection — it's a risk.
The lever for a smaller company, then, isn't "more tooling" or "more project-management overhead." It's this: establish clarity about what you actually want before you start building, and keep the scope small and concrete.
Where It All Leads
Put the findings together and a remarkably clear picture emerges. Across multiple independent sources, three decades, and tens of thousands of projects, the most important determinant of success or failure is not the choice of framework, vendor, or methodology. It's whether, at the outset, it is precisely, completely, and understandably established what the software is actually supposed to do — and whether that scope is small enough to stay manageable.
It's also the step that gets the least investment today. The requirements phase is the least popular phase of any project: tiring, abstract, seemingly unproductive because "nothing is running yet." So it gets cut short — and that is precisely what produces the 47% requirements-driven failures, the 52% scope creep, and the 9.9% of budget that simply burns away.
Which raises an uncomfortable but obvious question for anyone who owns software projects: why do we still leave the single most success-critical step — cleanly and completely deciding what should be built — to the chance of free-form conversations, gut feel, and unstructured briefings? It's the one part of the process demonstrably decisive for success or failure, and simultaneously the least structured. Make that step as systematic, guided, and verifiable as everything else in the project — turn "what exactly do we want?" into a clear, deliberate decision before the first line of code exists — and you aren't addressing just any source of failure. You're addressing the single most common one.
Sources
- Standish Group, CHAOS Manifesto 2013 (2012 data)
- Standish Group, CHAOS Report 1994
- McKinsey & University of Oxford, Delivering large-scale IT projects on time, on budget, and on value (2012)
- Project Management Institute, Requirements Management: A Core Competency for Project and Program Success (2014)
- Project Management Institute, Pulse of the Profession 2018
- BCG, Five Ways to Beat the Odds on Digital Transformation (2023)
- Methodology critique: Eveleens & Verhoef, The Rise and Fall of the Chaos Report Figures, IEEE Software (2010)
