Dependency Mapping
Dependency Mapping is a one-hour team session that lists every system and team a project touches, the risks those dependencies create, and how each risk will be handled. It then sets up regular check-ins with the owners concerned. The version described here follows the Atlassian Team Playbook and produces a three-part worksheet: systems impacted, risks and mitigations, and feedback loops.
Facilitation script
- 1
Set the stage: explain the three worksheet sections and the goal of the session.
5 min - 2
Systems impacted: list upstream and downstream systems with owner, impact type and description.
20 min - 3
Silent risk brainstorm, one risk per note.
5 min - 4
Share and discuss risks; record impact level, mitigation and owner for each.
15 min - 5
Management plan: stakeholders, review rhythm and actions for each dependency. Agree who shares the map and when it is next reviewed.
15 min
Tips
Read 'system' broadly: other teams, vendors, approval processes and shared data count as much as software.
Ask about downstream effects explicitly, because teams list what they need from others far more readily than what they will break for others.
Give every dependency a named person as owner; a team name is not someone you can call.
Keep to the timeboxes and leave detailed mitigation design to the owner afterwards.
Common pitfalls
Listing only upstream dependencies. The team protects its own delivery and overlooks the teams it is about to disrupt, who then find out in production.
Naming a team as owner instead of a person. When the dependency slips there is nobody specific to contact and the check-in never happens.
Rating every risk as high. The worksheet no longer helps anyone decide where to spend attention.
Mapping without the dependency owners ever seeing the result. The team's assumptions about other teams go unchecked and are often wrong.
Treating the map as a kick-off artefact. Dependencies shift as the project moves, and an unreviewed map hides the new ones.
Variations
Remote: fill a shared digital worksheet while one person screen-shares, and use hidden notes for the silent risk round. Large programmes: have each workstream map its own dependencies first, then merge the worksheets and look for systems that appear more than once. Visual version: draw the project in the middle of a whiteboard with upstream systems on the left and downstream on the right before moving the content into the table. Extended documentation: add columns beyond the template when stakeholders need more context to understand an entry.
Where it fits
When to use it
A project is starting that needs work, data or approval from teams outside its own
A change will alter a system other teams build on and they have not been told yet
Earlier projects were delayed by another team's schedule or a surprise from a vendor
Several teams are planning the same period and need to see where their work collides
A project has changed scope and its original assumptions about other teams may no longer hold
When not to use it
The project sits entirely inside one team with no external systems. A Premortem covers its risks better
You need to understand people's interest and influence rather than technical or delivery links. Use a Stakeholder Map
The question is who does which task. A RACI Matrix answers that directly
The project is so early that scope is undefined. Write a Project Poster or charter first so there is something to map dependencies from
Nobody will own the follow-up. A map without check-ins is out of date within weeks and gives false comfort
Related methods
Frequently asked questions
What is Dependency Mapping?▾
Dependency Mapping is a team session that identifies the systems and teams a project depends on or affects, the risks those links create, and how they will be managed. In the Atlassian Team Playbook version it takes about an hour and produces a worksheet with three sections: systems impacted, risks and mitigations, and feedback loops.
What is the difference between upstream and downstream dependencies?▾
Upstream dependencies are things your project needs from others, such as an API, a dataset or an approval. Downstream dependencies are the systems and teams that will be affected by what your project changes. A useful map covers both directions.
How long does Dependency Mapping take and who should attend?▾
The play is set at 60 minutes for 2 to 12 people. Include team members who know the technical and organisational links in detail, and send the worksheet in advance so the session starts with ideas on the table. Dependency owners from other teams review the result afterwards.
How is Dependency Mapping different from a premortem?▾
A premortem imagines the project has failed and collects every possible cause, internal or external. Dependency Mapping looks only at the links to other systems and teams, records them systematically and adds a review rhythm with their owners. The two fit well together at kick-off.
How often should the dependency map be updated?▾
Set the rhythm per dependency during the session: weekly for volatile, high-impact ones, monthly or quarterly for stable ones. Also revisit the whole map whenever scope changes or a new team becomes involved.
Plan your next workshop with AI
Workshop Weaver helps you combine methods like Dependency Mapping into a complete, timed agenda in minutes.
Try it freeMethod descriptions on Workshop Weaver are original content written by our team, based on established facilitation practices. This method was inspired by work from Atlassian Team Playbook.