Every cross-functional program has dependencies. Some are visible: shared systems, common deployment windows, sequential handoffs that everyone recognizes. These appear in project plans and architecture diagrams, and they get managed because everyone knows about them. The dependencies that cause execution collisions are the ones that live in the mind of a single person. Engineering knows about technical debt that will slow a migration the operations team is counting on. Finance knows about a budget constraint that hasn’t been communicated to the program team. A business unit leader knows about a customer commitment that restricts when a system change can occur. Each dependency is known to someone; none have been compiled into shared visibility. The Cross-Functional Dependencies section of the Stakeholder Map is the mechanism that reveals them, taking what the one-on-ones uncover and structuring it into a form the planning team can act on before roadmap sessions begin.
What a Stakeholder List Tells You (and What It Cannot)
A stakeholder list tells the team who is involved in the initiative. It names the people, their functions, and their roles. Some lists add a RACI designation. The list answers the question: who needs to be in the room? It does not answer: who depends on whom, and which dependencies are invisible to the people who will be affected by them? Two categories of dependencies go undocumented when the planning process stops at the stakeholder list: Asymmetric dependencies. Function A depends on Function B for a deliverable, but Function B doesn’t know. The dependence is visible in one direction and invisible in the other. These asymmetries are common in cross-functional programs because each function plans within its own boundary. The planning team assumes dependencies will emerge during architecture sessions, but by then the workstream scoping may already reflect assumptions that the unidentified dependency would invalidate. Temporal and external dependencies. A deliverable from one workstream must be completed before another workstream can begin, but the timing hasn’t been coordinated. The dependency isn’t about what one team needs from another but about when. Temporal dependencies are invisible in stakeholder lists because they require understanding both teams’ sequencing, which only becomes visible when someone asks each team independently about their timelines. External dependencies (i.e., a customer commitment, a regulatory deadline, a vendor contract, or a shared infrastructure team whose capacity is already allocated) originate outside the program boundary and are invisible to the program team because they exist in a different organizational context. The one-on-ones uncover both categories. Dependency Discovery through structured interviews is the mechanism that pulls invisible constraints into shared visibility. By asking each stakeholder “What do you need from other teams that you’re not confident you’ll get?” and “What constraints does your team hold that the program may not know about?”, we pull the invisible dependencies into the open.
What the Cross-Functional Dependencies Section Contains
For each dependency uncovered during the one-on-ones, the section captures:
- The dependency itself. What one function needs from another, stated with enough specificity to be actionable.
- Who sees it. Which stakeholder identified it, and whether other stakeholders are aware of it.
- The consequence of missing it. What happens during execution if this dependency isn’t managed: a delayed deliverable, a deployment collision, a resource conflict, or a broken handoff.
The quality bar: if the dependency list only contains what everyone already knows, the one-on-ones haven’t done their job. The value is in the asymmetries (i.e., dependencies visible to one function and invisible to others), because these are the dependencies that will produce surprises during execution. The synthesis question: What is going to surprise the team during execution if it isn’t identified now? The narrative takeaway names the highest-risk dependencies: the ones where one function holds a constraint that another function’s plan depends on, and neither knows about the other’s position.
How Invisible Dependencies Become Execution Collisions
The distance between a stakeholder list and a Cross-Functional Dependencies section produces predictable execution-stage failures. The handoff that nobody scheduled. Workstream A’s milestone depends on a deliverable from Workstream B, but Workstream B was never told. The deliverable doesn’t appear on Workstream B’s plan because the dependency was invisible to them. The collision appears when Workstream A reaches the milestone and discovers the input doesn’t exist; recovery requires compressing Workstream B’s timeline or delaying Workstream A’s, neither of which was planned for. The resource conflict that was foreseeable. Two workstreams both need the same infrastructure team during the same sprint. The infrastructure team has capacity for one. Both workstream leads planned independently and neither knew about the other’s request. The conflict appears when the infrastructure team receives both requests simultaneously and escalates. The resolution requires executive arbitration on priority (i.e., a decision that should have been made during planning, not during execution). The external constraint that invalidated the timeline. A customer contract restricts when a system change can occur. A regulatory filing deadline creates a blackout window. A vendor’s implementation schedule doesn’t align with the program’s deployment plan. Each constraint was known to someone; none were identified during planning because the planning process didn’t include a mechanism to ask. Programs that failed with good plans frequently trace the failure to dependencies that were known to someone but never compiled. The plans were internally sound. The collisions occurred at the boundaries between plans, where one team’s assumptions intersected with another team’s constraints.
What “Complete” Looks Like
A complete Cross-Functional Dependencies section passes four tests:
- Every dependency has been confirmed by both sides. If Function A says it depends on Function B, we’ve verified with Function B that they’re aware of the dependency and have planned for it. If Function B wasn’t aware, that asymmetry is flagged.
- Invisible dependencies are distinguished from known ones. The section marks which dependencies were already in shared visibility and which were identified for the first time through the one-on-ones. The newly identified ones carry higher risk because they haven’t been factored into existing plans.
- Consequences are specific. “This could cause delays” isn’t actionable. “If this dependency is missed, Workstream A’s Wave 1 deployment will be delayed by 3-4 weeks because the data migration requires the infrastructure upgrade to be complete” gives the planning team a basis for prioritization.
- The section feeds forward into the Architecture Blueprint. The dependency list is an input to workstream boundaries, handoff contracts, and the dependency diagram in Beat 3. If the dependencies live only in the Stakeholder Map and aren’t carried forward into the architecture, they’ll be forgotten.
Most programs build their architecture on assumptions about how functions interact rather than evidence. The cost of a missed dependency is measured in weeks of delay during execution, when the options for recovery are fewest.
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 → Want us to build this with you? Book a consultation →
Keep Reading
New to the Stakeholder Map? Start with the foundations:
Ready to benchmark your work against best-in-class? See what excellence looks like: