The first cross-functional session is where a planning engagement gains momentum or loses it. We walk in with an agenda, a set of exercises, and a room full of leaders who have agreed to spend collaborative time building something together. What happens next depends on whether we know what the room thinks before the room convenes. Three patterns recur in programs that skip the Stakeholder Map. Each traces back to information that was known to someone in the organization but was never compiled into a form the planning team could act on.
Pattern 1: The False Consensus That Collapsed in Week 3
The program was a digital transformation across four business units. The sponsor described the leadership team as “aligned.” The charter documented shared goals. The kickoff session went smoothly because everyone agreed at the surface level: modernize the platform, improve the customer experience, reduce operational complexity. The alignment collapsed during the third week, when the roadmap session required the team to sequence workstreams. The VP of Customer Experience wanted to prioritize front-end changes that would improve satisfaction scores within six months. The VP of Operations wanted to prioritize back-end consolidation that would reduce operational cost within twelve months. The CTO wanted to prioritize infrastructure modernization that would enable both but required eighteen months before either could begin. All three leaders had been “aligned” on the program’s goals. They had never discussed sequencing, trade-offs, or what to build first. The alignment was real at the level of aspiration and nonexistent at the level of execution. A Perspective Map would have surfaced this gap before the roadmap session by documenting each leader’s definition of success and their assumptions about timeline and priority. We would have entered the room knowing the divergence existed and designed the session to address it. Instead, the roadmap session became a priority negotiation conducted under time pressure. The team lost two weeks of collaborative time re-establishing the sequencing assumptions that could have been established in pre-work. Programs where alignment was assumed but never verified follow this pattern: the room discovers during planning what the one-on-ones would have revealed before planning began.
Pattern 2: The Landmine Nobody Mentioned
The program was an operating model redesign at a Fortune 500 manufacturer. The engagement required merging three regional operations teams into a single global function. The consulting team had a clear mandate from the CEO and strong support from the SVP of Global Operations. What the consulting team did not know was that the three regional leaders had fought this consolidation for two years. The prior attempt, led by a different consulting firm, had been canceled after the regional leaders collectively escalated to the board, arguing that centralization would destroy the local market expertise their teams had built. The CEO overrode their objections this time, but the regional leaders had not changed their view. They had changed their strategy: instead of opposing the initiative publicly, they would comply minimally and let the implementation fail on its operational merits. This history was known to the CHRO, who had mediated the prior escalation. It was known to the SVP’s chief of staff, who had been in the room. It was known to the regional leaders themselves. It was not known to the consulting team, because nobody asked. An Organizational Landmines section would have surfaced this dynamic in the first week. The one-on-one with the CHRO would have revealed the prior escalation. The one-on-ones with the regional leaders, conducted with the right questions and explicit confidentiality, would have revealed their concerns about centralization. The consultants could have designed the architecture sessions to address those concerns directly, i.e., by building in regional autonomy provisions rather than presenting a purely centralized model. Instead, the consulting team designed a centralized operating model, presented it in a collaborative session, and watched the room shut down. The regional leaders did not object. They agreed to everything. And then they returned to their teams and continued operating under the prior model. The program stalled in month four when adoption metrics showed single-digit compliance in two of three regions. Fourteen stakeholders with zero visibility into each other’s positions produced a plan that technically had full agreement and operationally had none.
Pattern 3: The Dependency Nobody Saw Coming
The program was a supply chain integration following an acquisition. Two companies were merging their logistics operations. The consulting team conducted standard intake: documents, org charts, system inventories. They mapped the functional landscape and identified the integration points. They designed the program architecture around three workstreams: warehouse consolidation, transportation network optimization, and technology platform migration. What they missed was a dependency that lived in the mind of one person: the acquired company’s VP of Logistics. That VP knew that the acquired company’s largest customer had a contractual clause requiring 48-hour notification of any change to the fulfillment network. The clause had been negotiated during a prior supply disruption and was buried in an amendment to the master services agreement. The warehouse consolidation workstream proceeded on schedule. During Wave 1, two distribution centers were merged, changing the fulfillment routing for the largest customer. Nobody notified the customer because nobody on the integration team knew about the clause. The customer invoked the penalty provision. The financial exposure was significant enough to pause the entire integration for six weeks while legal teams negotiated. A Cross-Functional Dependencies section, built from one-on-ones with the acquired company’s leadership, would have surfaced this constraint. The VP of Logistics knew about the clause. Nobody asked. The dependency was invisible to everyone except the one person who held it, and it became visible only when it caused a collision during execution. This is the pattern the Stakeholder Map is designed to prevent: dependencies that are known to someone in the organization but never compiled into shared visibility. Programs that failed with good plans frequently trace the failure to exactly this: information that existed, that was held by a specific person, and that was never surfaced because the planning process did not include a mechanism to identify it.
What the Three Patterns Share
All three failures trace back to the same structural gap: the planning team entered collaborative sessions without knowing what the room thought. The information existed. In every case, someone in the organization held the perspective, the history, or the constraint that would have changed the plan. The information was never compiled because the planning process did not include a step designed to compile it. The Stakeholder Map is that step. The Leadership Roster identifies who holds power. The Perspective Map identifies where beliefs diverge. The Organizational Landmines section captures what history the room carries. The Cross-Functional Dependencies section pulls invisible constraints into shared visibility. Together, the four sections ensure we walk into the first session knowing what the room thinks, not just who is in it. The question is whether your planning process includes a mechanism to reveal what the room thinks before the room convenes: or whether you discover the perspectives, the history, and the constraints during execution, when the cost of surprise is measured in weeks of delay rather than hours of conversation.
Go Deeper: The Stakeholder Map
This article covers one dimension of the Stakeholder Map, the second of nine artifacts in the Planning & Roadmapping method. The Stakeholder Map answers the board question: “Who sees what?” Explore the full Stakeholder Map →
Keep Reading
Ready to close specific gaps in your Stakeholder Map? These articles show you how: