Both sides think the other isn’t listening. The real problem runs deeper than communication style — and the fix isn’t what most teams try.
There’s a conversation that happens on virtually every significant IT project. The business stakeholder says: “We need a system that makes it easy for our customers to track their orders.” The IT team says: “Got it.” They build a system that makes it easy for customers to track their orders. Six months later, during user acceptance testing, the business stakeholder looks at what was built and says: “This isn’t what we asked for.”
Both sides are right. The business asked for something. The IT team built exactly what they understood. And somehow, what was asked for and what was built are not the same thing.
This scenario isn’t a failure of intelligence on either side. It isn’t a failure of effort. It’s a failure of communication — specifically, a failure rooted in how human beings transmit and receive information. Understanding that failure is the first step to preventing it.
The Assumption Gap
When a business stakeholder describes what they need from an IT system, they describe it from inside their own mental model of how their business works. That mental model contains enormous amounts of implicit knowledge — how the business operates, what the edge cases are, what “easy” means in the context of their customers, what other systems this will need to integrate with, what happens at the end of the month when volume spikes, what regulatory constraints apply.
Almost none of this gets said explicitly. It doesn’t get said because the stakeholder doesn’t experience it as information to transmit — it’s just the water they swim in. It’s so fundamental to their understanding of the business that it doesn’t feel like a requirement. It feels like the obvious backdrop against which the requirements exist.
The IT team, working from a completely different background and mental model, hears what was said and fills the gaps with their own assumptions. Those assumptions are reasonable, technically sound, and completely wrong in ways that won’t become visible until the system is built and someone actually tries to use it.
What Neuroscience Tells Us About Communication
The human brain is extraordinarily efficient. It achieves that efficiency by automating pattern recognition and suppressing information that seems obvious or redundant. When you walk into a room, you don’t consciously process every object, every light source, every potential obstacle. Your brain filters all of that — you only consciously perceive what’s new, changed, or relevant to what you’re doing.
The same mechanism operates when people communicate. When a business stakeholder describes a requirement, their brain automatically filters out everything that feels obvious — the assumed context, the habitual processes, the things that would “obviously” be part of any reasonable solution.
The problem is that what’s obvious to someone with ten years in a specific business role is not obvious to someone building software. The filter that makes communication efficient creates systematic incompleteness in requirements. This isn’t fixed by asking stakeholders to be more thorough. The filtering happens below the level of conscious awareness.
The IT Team’s Parallel Problem
Technical professionals bring deep expertise in systems, architecture, and implementation. That expertise comes with its own set of implicit assumptions — about what’s technically feasible, what’s standard, what the “right” way to solve a class of problems looks like.
When IT teams hear requirements, they translate them through this technical lens. They hear what the business asked for, they map it to known technical patterns, and they start solving. The mapping process is not neutral — it introduces the IT team’s own implicit assumptions about what the business must mean. By the time anyone compares the business’s original intent to the IT team’s implementation, months of work have gone into a gap that was created in the first conversation.
Why Traditional Solutions Don’t Work
The standard prescription for business-IT communication problems is documentation: write more detailed requirements, create user stories, build wireframes, get sign-off at every stage. These interventions help. But they don’t close the gap — they give you more opportunities to catch it after it has already formed.
The requirement that was left implicit because the business stakeholder didn’t know to say it is still implicit in the detailed requirements document. Sign-off confirms that both parties agree on what’s been documented — not that what’s been documented is complete. More documentation doesn’t solve the problem because the problem isn’t a lack of documentation. It’s a structural incompatibility between how humans communicate and what a successful IT project requires.
What Actually Bridges the Gap
It requires a universal business model. There is a model that every business person already knows — a framework for understanding how any business operates that is intuitive to non-technical people and translatable to technical specifications. This model, when applied deliberately, creates a shared language between business and IT that doesn’t require either side to become fluent in the other’s technical domain.
It requires simulation, not just documentation. Simulations — structured exercises in which teams work through how the new system will actually function in real business scenarios — surface the gaps that documents miss.
It requires practice at a team level. Business-IT communication is a skill, not a deliverable. You get better at it by practicing the methodology with your actual team, against your actual project, with coaching from people who have done this across hundreds of projects.
It requires accounting for cognitive bias. Expert blindness needs to be explicitly counteracted through structured elicitation techniques designed to surface the assumed and habitual, not just the new and unusual.
The Organizational Dimension
Poor business-IT communication isn’t just a project risk. It’s an organizational pattern that compounds over time. Every project where the gap wasn’t bridged leaves behind a system that doesn’t quite fit how the business works. Organizations with persistent business-IT communication problems have a progressively harder time defining what they need from IT at all, because the gap between their systems and their actual business processes has grown so large that articulating requirements requires first mapping and reconciling decades of accumulated divergence.
→ If you recognize your organization in this description, the first step is acknowledging that the problem isn’t solvable with better documentation or more meetings. We’ve spent our careers building the methodology that addresses the root causes of business-IT communication failure. Our course is designed specifically for project managers who’ve seen good projects fail because of communication gaps.
Explore the course → bridgingbusinessit.com/the-course/