The failure rate hasn’t improved in forty years — despite better methodologies, better tools, and better-trained PMs. The explanation lives in cognitive science, not in project management or another dev model.
The statistics on IT project failure have been stable for forty years. Seventy percent of IT projects experience some level of failure. New methodologies have been developed. New certifications have proliferated. Agile replaced waterfall. DevOps changed delivery. The tooling has gotten dramatically better. The failure rate hasn’t moved.
When a problem persists at the same rate across four decades of methodological change, that’s a signal worth taking seriously. We believe understanding the neuroscience of how humans communicate gives us the explanation that has been missing from the standard narrative about IT project failure.
The Brain’s Efficiency Problem
The human brain is extraordinarily efficient. It processes an enormous amount of information by taking shortcuts — pattern recognition, assumption filling, contextual filtering — that allow it to function without consciously processing every detail. These shortcuts are features, not bugs. But they create a specific, predictable failure mode in complex communication. And requirements gathering is extremely complex communication.
Contextual filtering suppresses information the brain codes as “obvious given what the listener knows.” The experienced department manager doesn’t mention that order volume spikes 300 percent in November and December because anyone who knows their business knows that. Except IT doesn’t know their business.
Expert compression encodes large amounts of operational knowledge into implicit assumptions. The stakeholder who says “the system needs to handle returns” has compressed ten years of return-processing experience — hundreds of edge cases and policy nuances — into four words.
Future projection bias causes stakeholders to describe requirements filtered through their current mental model, meaning unusual cases and future-state requirements are systematically under-specified.
None of this is conscious. Stakeholders aren’t choosing to withhold information. Their brains are doing exactly what human brains are designed to do: communicating efficiently, by omitting what feels obvious. The problem is twofold. First, what’s obvious to you may not be obvious to me. Second, efficient human communication and complete IT requirements are fundamentally incompatible.
The IT Team’s Mirror Problem
When IT team members receive requirements, they’re running their own pattern recognition and assumption-filling processes. They hear a business description, pattern-match it to technical solutions they’ve implemented before, and begin mentally designing the implementation. That mental design reflects their own implicit assumptions and biases — baked into architecture decisions before anyone has verified that they match the business reality.
Why Documentation Doesn’t Fix This
Documentation helps at the margins. But the requirements that don’t get captured because they’re obvious to the business stakeholder don’t appear in more detailed documentation — they were never said, because the brain filtered them before they reached conscious awareness. Sign-off confirms that both parties have read and agreed to the same document. But it doesn’t confirm that their mental models of what the document means are the same.
What Actually Counteracts the Neuroscience
Structured elicitation counteracts contextual filtering. Moving systematically through every component of a business process forces the stakeholders to consciously engage with areas of knowledge that contextual filtering would otherwise leave implicit.
Simulation counteracts expert compression. When stakeholders actually perform a simulated business scenario, the compressed experiential knowledge that doesn’t survive verbal description gets surfaced.
Shared modeling counteracts interpretation divergence. When both business and IT work from a shared, explicit model of the business, the translation gap between what was said and what was understood gets significantly smaller.
Iterative validation counteracts future projection bias. Regular exposure of partial implementations to business stakeholders — for genuine “does this match what you need?” testing — surfaces requirements that the abstract specification never does.
The Practice Element: Why Knowing Isn’t Enough
Cognitive science research on skill acquisition is consistent: reading about a skill produces declarative knowledge — you know what good requirements elicitation looks like. It doesn’t produce procedural skill — the ability to do it effectively under real-world conditions. Procedural skill requires deliberate practice in realistic conditions, with feedback.
Most requirements training produces declarative knowledge. Project managers learn what good requirements look like, but they don’t develop the procedural skill to execute those techniques under the actual cognitive and social pressures of a real requirements session. This is why even organizations with well-trained project managers and business analysts still have requirements problems. The training didn’t develop the right kind of capability.
→ We’ve spent decades developing this methodology — drawn from psychology and neuroscience research, refined through hundreds of real-world projects, translated into a training program that develops genuine procedural skill rather than just conceptual knowledge. The program includes process audit interviews that develop elicitation skills through practice. If the neuroscience of requirements failure resonates with what you’ve seen on your own projects, we’d invite you to explore whether our course is the right fit for your team.
Explore the course → bridgingbusinessit.com/the-course/
