| name | dependency-mapping |
| description | Build the cross-team dependency graph and derive the critical path — every handoff gets a producer, consumer, due date, and interface contract; cycles and single points of failure get flagged. Use when a program spans multiple teams and you need to know what actually decides the date. |
Skill: Dependency mapping
Make the invisible cross-team handoffs visible, then compute what actually drives
the program date. A program is its dependencies, not its tasks.
When to use
- A program spans ≥2 teams and the date feels unknowable.
- Two teams are building toward an integration with no agreed contract.
- You need to know which slips matter (critical path) and which don't (slack).
Procedure
- Enumerate cross-team deliverables. For each, record: producer team,
consumer team, due date, and the interface contract (schema / API / event /
doc) at the seam. A handoff with no named interface is the highest-risk kind.
- Build the graph. Nodes are deliverables; edges are "X must finish before Y
can start." Use the
dependency-map template.
- Derive the critical path. Find the longest chain of gated handoffs — that
chain is the date. Compute slack on every other chain.
- Flag cycles (A waits on B waits on A): break with a stub/mock or a phased
contract. Flag single points of failure: one under-resourced team on the
critical path is a key-person risk.
- Make every seam contract-first. Where two teams meet, agree the interface
before either builds. Route unowned seams to the TPM to assign an owner.
Output
A dependency map, the critical path, the slack on non-critical chains, and a list
of flagged cycles/SPOFs feeding the RAID log.
Anti-patterns
- A "dependency list" that's really a task list (no producer→consumer edges).
- A date asserted with no critical path to defend it.
- An interface seam with no owner and no contract.
