When a software project fails, the post-mortem blames the obvious thing. A missed deadline. A technical problem. A difficult vendor. But those are symptoms, not causes. The real reasons were sitting there from the very start, in plain view of anyone who knew where to look. And the same handful keep repeating, across every industry and every budget size.
The numbers aren’t pretty either. The Standish Group’s long-running CHAOS research finds only about a third of software projects fully succeed, while roughly half land late, over budget, or under scope, and the rest fail outright (Standish, via InfoQ). And the bigger the project, the worse the odds. McKinsey, with Oxford, studied more than 5,400 large IT projects and found they run 45% over budget, deliver 56% less value than promised, and that 17% go so badly they threaten the company itself (McKinsey).
Here’s the part that surprises people. Most of it is decided before anyone writes a line of code.
I’ve put the six usual causes on one chart, ranked by how much damage they do, and split into two groups. The big ones at the top happen before the build: you aimed at the wrong thing, you never really understood the requirements, and nobody owned the result. The smaller ones below happen during the build: integration and data bite harder than planned, problems get hidden instead of surfaced, and the plan can’t bend when reality shows up. Notice the shape. The earliest causes are the biggest.
Before a line of code: where most of the damage is already done.
1. You solved the wrong problem, beautifully. The most expensive failures aren’t badly built. They’re the wrong thing built well. It traces back to a fuzzy, unchallenged idea of what the project was even for. A vendor will build exactly what you specified. Whether that’s what you needed is on the spec, not on them.
2. The requirements were never really understood. Start a project on vague or assumed requirements and it drifts, swells, and misses. Getting at what people actually need, not just what they say first, is a real skill. Skip it and you’ve guaranteed yourself a pile of rework.
3. Nobody owned the outcome. Split responsibility between a business that “owns the requirements” and a vendor that “owns delivery,” and the gap between them is exactly where projects die. Someone has to own the result, the whole way through.
During the build: where the rest of it goes wrong.
4. Integration and data got underestimated. The plan assumed clean data and friendly existing systems. Reality handed over neither, and the timeline never recovered. This is the single most under-budgeted part of enterprise delivery, every time.
5. Problems got hidden, not surfaced. On a troubled project, bad news travels slowly. Status stays green right up until it can’t, and by the time the truth comes out, the cheap window to fix it has already closed.
6. The plan couldn’t absorb change. Requirements always change. A plan and an architecture rigid enough to snap under that change were going to fail the moment reality arrived. Which it always does.
Look at the chart again and the pattern is hard to miss. Most failure is decided early, in how the problem is framed, how requirements are understood, and who genuinely owns the result, long before any code exists. The technical execution is rarely the root cause.
And that’s actually good news. Projects that start with a sharply defined problem, requirements you really dug into, clear ownership, and an honest view of integration risk mostly succeed. The failure modes are knowable, so they’re avoidable.
A project drifting toward trouble, or planning one you can’t afford to get wrong? SDCG reviews troubled projects honestly and helps de-risk new ones before they start. We own outcomes end to end, so our advice has to hold up in the real world, not just on a slide. Book a free 30-minute review.
Sources
- The Standish Group CHAOS research (InfoQ summary)
- McKinsey & University of Oxford: Delivering large-scale IT projects on time, on budget, and on value