In plain English: Across the biggest documented IT failures, the coders are rarely the problem. Inaccurate requirements and poor communication between business and build team sink far more projects than bad code ever does. Fix the brief, not the bench.
In February 2005, FBI officials told the US Senate that their Virtual Case File system had "probably failed." Three-plus years and $170 million in, agents were still filing evidence on paper because the software meant to replace their 1980s mainframe never worked well enough to switch on.
The obvious villain is easy to cast: useless programmers, over budget, over time, nothing to show for it. The Justice Department's own inspector general looked for that villain and didn't find it. Their testimony pointed instead at poorly defined, constantly shifting design requirements, weak contractor oversight and a schedule nobody believed in from day one. Nowhere in the record does anyone say the code itself was badly written — it's hard to write good code against a specification that's a different document every quarter.
That pattern repeats everywhere a large software project collapses. The story we tell ourselves is "bad developers." The story the evidence tells is almost always something else.
The myth: it's a talent problem
Ask a manager why a project slipped and you'll often get a shrug and "the dev team struggled." It's a comfortable answer. It locates the problem outside the room where the decisions got made — the scope meetings, the sign-offs, the "can we also just add" conversations — and inside a team that, conveniently, isn't in the room to argue back.
It's also rarely what the data shows. Large, well-documented IT failures get picked apart by auditors, regulators and the press precisely because so much public money is at stake, and those post-mortems consistently land somewhere else: unclear requirements, weak communication between the people who want the thing and the people building it, and governance that nobody was really in charge of.
What the numbers actually say
McKinsey and the University of Oxford studied more than 5,400 large IT projects — the kind with price tags over $15 million — and found that, on average, they ran 45% over budget and 7% over schedule, while delivering 56% less value than promised. Roughly half of large IT projects blow their budgets dramatically. The research frames the fix around four areas: strategy and stakeholders, technical scope, team dynamics and core project management — not raw coding ability (McKinsey & Company).
The Project Management Institute's research on requirements management puts a sharper number on one slice of that: nearly half — 47% — of unsuccessful projects fail to meet their goals because of inaccurate requirements management. PMI links that straight to scope creep, weak stakeholder involvement and inadequate sponsor support — all things decided before anyone opens an IDE (PMI). A separate PMI Pulse of the Profession report, from 2013, found poor communication was a contributing factor in 56% of projects that failed outright.
| What actually breaks the project | Reported share |
|---|---|
| Inaccurate or unclear requirements | 47% of unsuccessful projects (PMI) |
| Poor communication business ↔ build team | Contributing factor in 56% of failed projects (PMI, 2013) |
| Average cost overrun on large IT projects | 45% (McKinsey/Oxford, 5,400+ projects) |
| Average value shortfall vs. plan | 56% less value delivered than predicted |
Four numbers, one pattern. Nobody's measuring "developer skill" as the leading cause, because when auditors go looking, it's rarely what they find.
A second data point: the NHS
Britain's National Programme for IT is the UK's own version of the same lesson, at a much larger scale. Commissioned to digitise patient records across the NHS, it was dismantled in 2011 after swallowing roughly £10 billion. The National Audit Office and the Public Accounts Committee's conclusions, summarised repeatedly in the trade press, read like a checklist of everything except coding quality: the programme was specified centrally before anyone had properly understood what hospitals and trusts actually needed, the trusts that had to use the system had little say in its design, and the work was split across several suppliers whose contracts were, in one reviewer's words, "aggressively drafted but poorly specified." One supplier spent nine years and £3 billion to deliver working software to three hospitals.
Nobody serious argues the engineers on that programme couldn't code. The project was unmanageable before a single line of it was written, because the people who'd actually use the system weren't asked what they needed, and the people who signed the contracts didn't specify it clearly enough for anyone to build against.
So what does actually sink a project?
Pull the threads from both cases and the research, and three culprits show up again and again:
- Requirements nobody pinned down. Not "we'll figure it out as we go" — a written description of what the thing needs to do, that both sides signed off on, before serious money got spent.
- No one person owns the decisions. When "the business" is twelve stakeholders with twelve opinions and no tie-breaker, scope drifts until the budget runs out.
- The users weren't in the room. Specs written for people, not with them, miss the one requirement that actually mattered and only surfaces three weeks before go-live — usually phrased as "wait, it doesn't do that?"
None of these show up on a CV. You can hire the best engineers in your market and still lose to all three, because they're decided in meetings your developers aren't invited to.
Why the same mistake gets more expensive every week
Here's the bit that makes requirements worth obsessing over: the cost of a wrong assumption doesn't stay flat, it compounds.
Say a stakeholder realises in week two that the client portal also needs to show order history, not just invoices. Caught then, it's a conversation and a line added to the backlog. Caught in week twelve, after the data model was built around invoices only, it's a migration. Caught after launch, when customers are already logging in and asking "where's my order history?", it's an emergency sprint, an apology email and a feature that gets bolted on instead of designed in. Same requirement, wildly different bill — purely a function of when someone said it out loud. (Illustrative example, not a client project.)
That's the real argument for a discovery phase and a prototype before the expensive part starts: not bureaucracy for its own sake, but moving the moment of discovery as early — and as cheap — as it can possibly be.
The checklist that would have saved all of the above
Before you sign off on the next software project — yours, or one you're buying from an agency — run it past this:
- Is there a single named owner who can make a scope decision in under 48 hours, not a committee?
- Are the requirements written down, not living in someone's head or a Slack thread from March?
- Have the actual end users seen a prototype before serious development money is spent — not just the sponsors who commissioned it?
- Is scope frozen for each phase, with changes going through a visible, costed process instead of sliding in as "small asks"?
- Does the team ship something reviewable every couple of weeks, so a wrong assumption costs two weeks, not two years?
That last point is why a proper discovery phase and a clickable prototype — before anyone commits to the full build — earns its keep. It's cheaper to find out your requirements were wrong in week three than in year three, and it costs a fraction of a contingency budget. It's also, not coincidentally, how we structure custom software projects: a fixed-scope discovery sprint and a prototype people can click through, before the meter on full development starts running.
When it genuinely is the developers
Honesty check: sometimes the code really is the problem — no tests, no code review, a stack nobody on the team actually knows, technical debt nobody paid down. It happens, and it's worth asking about directly: how do they test, how do they handle changes, can they show you a handover from a past client. But even then, look one level up first. Teams without time for tests are usually teams that were never given a realistic schedule to work to in the first place — which, again, is a decision made above the keyboard.
If you're deciding between buying software off the shelf, bending what you already have, or commissioning something custom, our framework for that decision is the companion piece to this one — because a chunk of "failed" projects were really the wrong option chosen for the job, built perfectly.
Not sure whether your next project is set up to survive contact with reality? The free Digital Readiness Scorecard takes three minutes and flags exactly this kind of risk before you sign anything.
Founder & Chief Unicorn Officer at VEONIO. Leads every engagement personally. Still can’t say no to a good idea.