Most software projects fail — and it's almost never the code. Why scope is what sinks them.

There is a comforting story owners tell themselves when a software project goes wrong: the developers were not good enough. Hire a better team, the thinking goes, and the next build will land. The data does not support the story. Across 50,000 projects studied by the Standish Group, only 31 percent succeeded — meaning they shipped on time, on budget, with the features promised. Half were "challenged" (delivered, but over budget, late, or with features cut), and 19 percent were cancelled outright [1]. Two out of three software projects, in other words, do not deliver what they set out to. That is not a talent shortage. It is something structural.

And it gets worse as the stakes rise. The same body of research shows small projects succeed roughly 90 percent of the time, while large ones succeed less than 10 percent [1][5]. A separate study of more than 5,400 large IT projects by McKinsey and the University of Oxford found they ran, on average, 45 percent over budget and delivered 56 percent less value than predicted — with 17 percent going so badly they threatened the existence of the company that commissioned them [2]. The pattern is consistent: the bigger the swing you take in one go, the lower the odds it lands.

So if it is not the code, what is it? When you trace failed projects back to their root cause, the wound is almost always upstream of the first line written. Nearly half — 47 percent — of unsuccessful projects fail because of inaccurate requirements [3], and 52 percent of all projects suffer scope creep, the slow, unbudgeted swelling of what was supposed to be built [4]. This piece is about that upstream wound: where it comes from, why "we will figure out the details as we go" is the most expensive sentence in software, and how a project gets commissioned so it actually ships.

Start with the number that reframes everything: only 31 percent of projects in the Standish data succeed on the strict definition — on time, on budget, with the agreed features ^[1]. The largest slice, 50 percent, is "challenged": the software exists, but it arrived late, cost more than planned, or shipped with half the promised scope quietly dropped to make the deadline. The remaining 19 percent are simply cancelled, often after real money is spent ^[1]. For an owner, the practical lesson is that "it failed" is rarely a clean binary. The common outcome is not a crash — it is a slow, partial disappointment that still drained the budget and the calendar. That is the modal result of commissioning software, and it is the one most people do not plan for.

The size effect is the single most actionable finding in the field. Small projects succeed around 90 percent of the time; large ones succeed less than 10 percent ^[1][5]. This is not because large teams are worse — it is because large scope hides more unknowns, more dependencies, and more places for the original brief to be wrong. The McKinsey–Oxford study of 5,400 large IT projects puts a price on it: 45 percent average cost overrun, 56 percent less value than promised, and a long tail of "black swan" projects — 17 percent — that overran badly enough to put the business itself at risk ^[2]. The takeaway is not "never build anything big." It is "never build anything big in one undivided swing." A large outcome reached through small, shipped slices behaves like a series of small projects, which is to say it behaves like the 90-percent column.

Now the root cause. When researchers ask why the challenged and cancelled projects went wrong, the answer is overwhelmingly upstream of engineering. The Project Management Institute found that 47 percent of unsuccessful projects fail to meet their goals because of inaccurate requirements management — the brief was wrong, incomplete, or never truly agreed ^[3]. The same body of work found 52 percent of all projects experience scope creep: the steady, unbudgeted expansion of "could you also just add…" that turns a three-month build into a year ^[4]. Notice what is absent from the top of that list: bad code, slow servers, the wrong programming language. Those are real, but they are rarely what sinks the project. What sinks it is a target that moved, or was never clearly drawn.

Why does the brief go wrong so reliably? Because the moment of maximum ignorance about a system is the moment you are asked to fully specify it — the very beginning. Nobody knows less about what the software needs to do than on day one, and yet day one is when the fixed scope and fixed price get signed. The honest response to that ignorance is not a longer requirements document; it is a short, paid discovery phase that turns assumptions into a tested plan before the expensive build commits, and a delivery rhythm that ships a usable slice every few weeks so the brief can be corrected against reality instead of defended against it. The projects that succeed are not the ones with the most detailed up-front spec. They are the ones built in increments small enough that being wrong is cheap and fixable.

For an operator, this resolves into a short checklist that has nothing to do with how clever the developers are. Was there a real discovery phase, or did building start on a vague brief and a fixed quote? Is the work sliced so that something usable ships in weeks, not at the end of a six-month dark tunnel? Is there a single named owner of scope on your side who can say no to "while we are at it"? Can you see working software early and often, or only a status report? Get those four right and you have moved your project out of the two-in-three that disappoint and into the column that ships — not by hiring better engineers, but by refusing to commission the kind of project the data says fails. The code was never the risk. The scope always was.