The failure rate hasn’t changed in thirty years. The reason why reveals something most project managers have never been taught.
The statistics haven’t improved. For decades, the industry has tracked IT project failure rates, commissioned studies, built new methodologies, invented new certifications — and the number has barely moved.
Seventy percent of IT projects fail. Ninety-five percent of the large ones.
If you’ve been a project manager for more than a year, you’ve probably lived inside at least one of those failures. You’ve watched a project that seemed solid on paper slowly unravel — missed milestones, surprise scope expansions, stakeholders who suddenly have new requirements six months in, a final delivery that nobody’s quite happy with.
The conventional wisdom says the culprits are budget overruns, unclear timelines, poor risk management, or technology choices that didn’t pan out. Those explanations aren’t wrong. But they’re downstream of something more fundamental — a root cause that gets far less attention than it deserves.
In this post, we’re going to look at what the data actually says about why IT projects fail, and what our 300+ combined years in the industry have taught us about the one mistake that drives most of those failures.
What the Research Actually Says
Let’s start with the numbers, because the scale of the problem is important to understand before we can talk about solutions.
McKinsey research on large IT projects found that on average, they run 45 percent over budget and 7 percent over time, while delivering 56 percent less value than predicted. Those aren’t edge cases. Those are averages.
The Project Management Institute’s Pulse of the Profession report found that organizations lose an average of $97 million for every $1 billion invested in projects due to poor performance. The 2025 edition noted that while roughly 80 percent of enterprise projects met their stated business goals, one in five still did not — and that’s before accounting for GenAI projects, where a separate MIT study found a 95 percent failure rate when defining failure as not delivering measurable financial returns within six months.
The Standish Group’s CHAOS Report, which has been tracking software project outcomes since 1994, consistently finds that less than 35 percent of IT projects are completed on time, on budget, and with the originally planned features. These aren’t numbers from a single bad period or a single industry. They are persistent, cross-sector, cross-decade. Something structural is going wrong.
The Usual Suspects (And Why They’re Not the Real Problem)
When project post-mortems happen — when they happen at all — they tend to identify familiar culprits.
Technology choices. The platform didn’t scale. The integration was more complex than estimated. The vendor’s roadmap shifted.
Timeline pressure. Leadership set an unrealistic deadline. The team was under-resourced. There wasn’t enough buffer for testing.
Scope creep. The requirements kept expanding. Stakeholders kept adding features. Nobody said no firmly enough.
Communication breakdowns. The business team and the IT team weren’t aligned. Different departments had different expectations.
All of these are real. All of them contribute to project failure. But here’s what decades of work on both sides of the business-IT divide has shown us: these aren’t the root causes. They’re symptoms.
Scope creep doesn’t appear from nowhere. It appears because the original scope wasn’t defined completely enough to hold. Timeline pressure doesn’t cause projects to fail on its own. It accelerates failures that were already baked in during the requirements phase. Communication breakdowns between business and IT are almost always about one thing: the business couldn’t fully articulate what it needed, and the IT team couldn’t fully surface what it was missing.
The Real Culprit: Requirements That Were Never Right
The most rigorous research into IT project failure consistently points to the same root cause: requirements.
PMI’s research found that 37 percent of organizations cite inaccurate requirements as the primary reason for project failure. An Info-Tech Research Group study found that 70 percent of digital transformation failures trace back to requirements issues. Combining those two data points: nearly half of all digital transformation projects fail specifically because of requirements problems.
A study in the project management literature found that 50 percent of rework — the expensive, morale-destroying work of rebuilding something that wasn’t right the first time — is directly attributable to requirements issues. This is the number that should stop any project manager cold: half of all rework. Not technology problems. Not timeline pressure. Requirements that were incomplete, unclear, or simply wrong from the start.
Why does this keep happening? If we know requirements are the problem, why haven’t we fixed it?
The Neuroscience Behind the Failure
This is where most conversations about IT project failure stop. They identify requirements as the problem and prescribe better requirements gathering processes — more workshops, more documentation, better templates. Those solutions help. But they don’t address the underlying reason requirements keep failing even when teams are trying to get them right.
The human brain is not wired to surface requirements completely.
Neuroscience research has established that humans are cognitively optimized to recognize patterns and fill gaps automatically. When a business stakeholder describes what they need, they are describing the parts that feel salient to them — the parts that are new, different, or that they’re consciously thinking about. The parts that are obvious, assumed, or habitual? Those get filtered out before they’re ever spoken.
This isn’t negligence. It isn’t laziness. It’s how human cognition works. Experts in any domain systematically underreport requirements in areas where they have deep expertise, because those things feel so obvious they don’t feel like requirements at all.
The result is that every requirements gathering process, no matter how thorough it seems, is structurally incomplete. The business team has told IT what they consciously know they need. They haven’t — can’t, without intervention — told IT what they need but don’t know they need.
What Fixing It Actually Looks Like
Understanding the neuroscience of requirement failure changes how you approach the solution. It’s not enough to ask better questions. It’s not enough to run longer workshops or create more detailed documentation. The solution requires a structured methodology that systematically surfaces the requirements that human cognition naturally suppresses.
That means engaging stakeholders in ways that bypass the pattern-recognition shortcuts that cause them to omit requirements. It means using simulation and practice — not just documentation — to expose the gaps between what was said and what was meant. It means building a shared model of the business that both sides of the business-IT divide can read fluently.
We’ve spent decades building and refining that methodology, drawing on research from psychology, neuroscience, and hundreds of real-world projects across organizations ranging from Fortune 500 companies to healthcare systems to government agencies.
The Cost of Not Fixing It
If your organization runs five significant IT projects per year, and 70 percent of them fail or significantly underdeliver, that’s three and a half failed projects annually. If each costs $1 million in direct spend — conservative for anything of real organizational significance — that’s $3.5 million in value destruction per year. That’s before you account for the indirect costs: the organizational energy spent on rework, the opportunity cost of delayed capabilities, the erosion of trust between business and IT that makes every subsequent project harder.
This is not an abstract problem. It has a specific dollar amount, and it’s larger than most organizations want to acknowledge.
→ The good news is that the failure rate for IT projects is not a law of nature. It’s a consequence of a specific, identifiable, fixable mistake. We’ve built a comprehensive training program for project managers that addresses the root cause directly — teaching the methodology that actually gets requirements right, practiced in real-world simulations with experienced coaches.
Explore the course → bridgingbusinessit.com/the-course/
