Dependency Mapping
Table of Contents
Invisible dependencies kill dates - map who blocks whom before the Gantt looks green.
Key Concept
- Dependency mapping is naming who must finish what before your team can move - internal and external.
- Risk Register catches what might break; dependencies catch what must happen in order.
- Green timelines that ignore legal, data, or vendor deps are fiction until the first blocked standup.
Level 1 - Recognize
Dependency mapping means listing who must deliver what before your team can proceed.
Level 2 - Explain
Like relay handoffs drawn on paper - everyone sees whose baton you are waiting on.
Level 3 - Use
For the next milestone, write three external deps and three internal deps with named owners and need-by dates.
Level 4 - Connect
Steering With a Chart includes the map; Technical Enough helps spot hidden technical deps engineers forget to voice.
Level 5 - Create
Review deps at Weekly Planning Rhythm - stale green boards often mean the map was never drawn.
Examples
- Glad we mapped legal review before launch - marketing wanted the date green; the map showed two weeks of blocked wait.
- API team thought CMS was ready - dependency map showed content model still open; saved a false demo.
Note Relationships
| Relationship | Wikilink | Reason |
|---|---|---|
| extends | PM Mindset | Planning tool inside the hub |
| extends | Steering With a Chart | Chart includes handoffs |
| extends | Risk Register | Blocked deps become risks |
| extends | Complete the Cycle | Named owner per dependency |





