The harder direction isn’t IT explaining tech to the business. It’s helping the business articulate what it needs completely enough that IT can actually build it.
One of the most underappreciated skills in IT project management is the ability to translate between technical and business thinking. Most project managers focus on the first direction: explaining IT concepts to business stakeholders. The more consequential skill is the second: helping business stakeholders communicate what they need completely enough that IT can build the right thing.
Why Business-to-IT Communication Fails
Business stakeholders suffer from what researchers call the “curse of knowledge” — the cognitive phenomenon where expertise makes it hard to remember what it was like not to have that expertise, and therefore hard to communicate the things that expertise has made automatic. When you’ve been running month-end close for fifteen years, you don’t think about it as something that requires explanation. The IT team builds a system that works fine for eleven months of the year.
IT teams have the parallel problem: technical expertise creates assumptions about what “obvious” solutions look like, which get imported into the design before the business has confirmed they fit.
Creating a Shared Language
Every business operates through a relatively small set of fundamental components: the things it knows about (entities), the things it does (processes), the rules that govern those activities (business rules), and the people and systems involved (actors and interfaces). A model built around those components can be understood and validated by business stakeholders while being directly translatable into technical requirements.
Practical Techniques for Better Requirements Conversations
Use scenarios, not abstractions. “Walk me through exactly what happens when a customer wants to return a product they bought online six weeks ago” generates the specifics that make requirements implementable. Abstract requirements generate abstract technical responses.
Ask about what goes wrong, not just what goes right. Systematically asking “what can go wrong, and what should happen when it does?” surfaces requirements that stakeholders know but don’t think to report.
Separate what from how. “We need a button that sends an email to the customer” is a how. “We need to notify the customer when their order status changes” is a what. The what allows IT to determine the best implementation.
Document decisions, not just requirements. Requirements conversations generate decisions — choices between alternatives, resolutions of conflicts. Documenting the decision alongside the requirement preserves the reasoning when the requirement is revisited months later.
Communicating Technical Constraints Back to the Business
Technical constraints need to be translated into business terms. “We can’t do real-time updates because the source system only exports data nightly” is a constraint stated in business language. “We can’t do real-time updates because of database limitations” is technically accurate but gives the business nothing actionable.
Building Communication Habits That Scale
Individual techniques help. But the highest-leverage investment is in building organizational habits — systematic approaches to business-IT communication that don’t depend on individual skill. That means establishing a requirements process that includes structured elicitation, explicit conflict resolution, and a common model framework that teams use consistently across projects.
→ If you’re interested in building that capability — in yourself and your team — our course walks through the complete methodology for business-IT requirements communication, practiced in realistic simulations with coaching from experienced practitioners.
Explore the course → bridgingbusinessit.com/the-course/