The program had fourteen stakeholders across five functions, each with its own plan, and each plan referenced the other functions in passing (e.g., “pending alignment with Technology on integration timeline”) without mapping what that alignment required. The stakeholder one-on-ones surfaced what the plans didn’t: three dependencies shared across multiple workstreams, none of them tracked anywhere.
The Three Dependencies
The first was a data migration that three workstreams assumed would be complete before their work could start. Technology had it on their roadmap for Q2. Operations had built their pilot sequence around a Q1 completion. Merchandising hadn’t specified a date at all because they assumed Technology would handle it. Three teams, three different assumptions about the same deliverable, and zero shared documentation.
The second was a store systems integration that required joint testing between Technology and Operations. Technology’s release calendar had the integration scheduled for a two-week window in March; Operations had that same window blocked for annual inventory counts across the pilot store group. Neither team knew about the other’s constraint because their planning happened in separate rooms.
The third was a training curriculum that Change Management was building for store partners. The curriculum depended on finalized process designs from Operations and finalized system configurations from Technology. Neither was scheduled to be complete until four weeks after the training was supposed to start. Change Management had flagged this in a status update two months earlier. The flag went into a meeting summary that nobody acted on.
What the Dependency Map Showed
We built a dependency map during the stakeholder mapping phase. Each one-on-one surfaced pieces: a constraint here, an assumption there that somebody had raised but never resolved. The map compiled those fragments into a single view.
The view was uncomfortable: three critical-path dependencies, each with a timing conflict, each invisible to at least two of the teams involved. The program had been running for eight weeks with execution scheduled to begin in six. If the dependencies had surfaced during execution instead of during planning, the program would have hit all three conflicts within a thirty-day window.
The dependency map didn’t fix anything by itself, but it changed the conversation. Instead of five workstream leads presenting their individual status, the steering committee was looking at a shared picture of where the program’s real risks lived. The discussion shifted from “are we on track” to “which of these three conflicts do we resolve first, and who has the authority to make that call.”
What Changed After the Map
The data migration got a single owner and a single date that all three workstreams agreed to. The previous state (i.e., three implicit assumptions about someone else’s deliverable) was replaced with an explicit commitment and a named escalation path if the date slipped.
The store systems integration window moved. Operations couldn’t move their inventory counts, so Technology adjusted the release window and compressed the testing phase. That tradeoff required the VP of Technology and the VP of Operations to agree in a room together. Before the dependency map, that conversation had no forum.
The training timeline got restructured. Change Management built a phased curriculum: foundational content that didn’t depend on finalized configurations first, system-specific training second. The four-week gap didn’t disappear, but the team designed around failure instead of discovering it during rollout.
Why This Keeps Happening
The fourteen stakeholders in this program were experienced operators. The dependencies went unmapped because the organization’s planning process didn’t have a step that required mapping them. Each function planned in its own context, presented its own roadmap, and assumed that alignment would happen through existing meetings and escalation channels.
It doesn’t. Alignment at the dependency level requires a specific artifact: a map that shows where one team’s work depends on another team’s output, with dates, owners, and constraints visible in a single view. Without that artifact, dependencies live in meeting notes, sidebar conversations, and individual assumptions. They become visible when they become problems. The stakeholder mapping step exists to surface the dependencies that exist only in people’s heads and build that artifact together before execution starts.
