Practice : Dependency Mapping and Resolution
Purpose and Strategic Importance
Dependency Mapping and Resolution is the practice of making cross-team and cross-system dependencies visible, actively managing them, and progressively reducing the number of hard dependencies that slow delivery. Dependencies are one of the most significant predictors of delivery delay — and they are almost always underestimated at the start of a planning cycle.
Leaders who treat dependency management as a delivery responsibility create the cross-boundary conversations and structural changes that reduce coordination overhead. Leaders who leave it to teams to manage informally create a hidden drag on every delivery.
Description of the Practice
- Dependencies are identified and documented at the start of every planning cycle.
- Each dependency has an owner, an expected resolution date, and a risk assessment.
- Cross-team dependency conversations happen at a regular cadence — not only when things are blocked.
- Leaders use their cross-boundary authority to escalate and resolve dependencies that teams cannot resolve themselves.
- Structural dependencies (architectural, organisational) are addressed at root over time, not just managed cycle by cycle.
How to Practise It (Playbook)
1. Getting Started
- At the start of the next planning cycle, explicitly ask: "What does this work depend on that we do not control?"
- Map the dependencies: external teams, systems, decisions, approvals, third parties.
- Assign an owner to each dependency and agree a review cadence.
- Identify which dependencies are on the critical path — these are the ones that need leader attention first.
2. Scaling and Maturing
- Introduce a dependency register visible to all teams involved.
- Build a regular cross-team dependencies forum — a brief, focused conversation on open dependencies and their status.
- Identify recurring dependency patterns: if the same cross-team dependency appears every cycle, explore whether it can be structurally eliminated.
- Track dependency resolution time as a flow metric — slow resolution is a signal of organisational friction worth addressing.
3. Team Behaviours to Encourage
- Teams raise dependencies early — days into a cycle, not when they are already blocking.
- Dependency owners are proactive: they update status and escalate early rather than waiting to be chased.
- Teams explore whether hard dependencies can be eliminated through better design, API contracts, or team reorganisation.
- Leaders are engaged when dependencies cross team or organisational boundaries.
4. Watch Out For…
- Dependencies that are invisible until they block: "we assumed [team X] would deliver [Y] but they haven't."
- Dependency lists that are maintained but not acted on — passive management does not resolve blockers.
- Leaders who leave cross-boundary dependencies to teams to resolve, when only the leader has the access to do so.
- Treating all dependencies as equally urgent — priority should follow critical path impact.
5. Signals of Success
- The number of unplanned dependency-related delays decreases cycle over cycle.
- Cross-team dependency conversations happen proactively, not in crisis.
- Structural dependencies are progressively reduced through architectural and organisational changes.
- Teams report feeling more in control of their delivery because dependencies are surfaced and managed.
- Leaders spend less time in emergency escalations because dependencies are resolved before they become blockers.