Dependency Map

Cross-Team Dependency Map

Overview

Dependency tracking for multi-team initiatives: who is blocking whom, what is on the critical path, what is at risk, and what to coordinate this week. The output is a Mermaid dependency diagram, a critical-path list, a risk-ordered blocker list, and a weekly cross-team sync agenda -- all generated from a single JSON file you maintain instead of a sprawling spreadsheet.

Most cross-team programs fail at dependency management, not execution. The teams individually do good work; the gaps are at the seams. This skill makes those seams visible, prioritizes them by criticality, and produces the communication artifacts that keep them visible week over week. The underlying model uses the Critical Path Method (CPM, Kelley and Walker, 1959) for sequencing, optional DSM (Design Structure Matrix) thinking for cluster identification, and Conway's Law (Conway, 1968) framing for the organizational source of recurring dependency patterns. All outputs follow the six standard PM formats per SHARED_OUTPUT_SCHEMA.md.

Core Capabilities

• Dependency capture — a six-field model (from/to team, description, needed-by, expected-delivery, status) maintained as one JSON file.
• Critical-path analysis — CPM computation of the longest zero-slack chain plus near-critical siblings.
• Risk ordering — slack and status combine into a risk-ranked blocker list.
• Visualization & comms — Mermaid graph LR rendering plus a weekly cross-team sync agenda.
• Org diagnosis — Conway's Law framing for recurring team-pair dependencies.

When to Use

• Multi-team feature -- A feature requires platform, mobile, and data teams to coordinate.
• Program management -- Tracking 5-20 dependent workstreams across a quarter (see program-manager/).
• Release coordination -- A launch depends on legal review + DevOps capacity + design assets all converging.
• Quarterly planning -- Identifying which dependencies threaten quarterly OKR commitments.
• Org-design diagnosis -- Recurring dependencies between the same two teams may signal a structural problem (Conway's Law).

When NOT to use: single-team backlogs (use wwas/ or job-stories/), pure technical dependencies inside one codebase (use Git), or stakeholder relationships (use senior-pm/stakeholder_mapper.py).

Clarify First

Before mapping dependencies, confirm these inputs. If any is unknown or vague, ASK — do not assume:

• Teams / workstreams in scope — the from/to pairs become the nodes; the wrong set produces a graph that maps the wrong program
• Needed-by and expected-delivery dates per dependency — these drive slack, so they determine the critical path and the entire risk ordering
• Current status of each dependency — not-started / in-progress / at-risk / done drives the risk-ordered blocker list and the weekly sync agenda
• Named owner per dependency — an ownerless dependency cannot be walked weekly; owners populate the sync agenda

Stop rule: ask only the 2-3 that most change the output. If the user says "just draft it," proceed and list your assumptions at the top of the artifact.

Quick Start

python scripts/dependency_graph.py --input deps.json --format markdown   # full report
python scripts/dependency_graph.py --input deps.json --format mermaid     # graph LR for README/Notion/Confluence
python scripts/dependency_graph.py --demo --format markdown               # sample output, no input

Populate deps.json from assets/dependency-template.json, run the analyzer, give every critical-path item a named owner, and walk it weekly with assets/weekly-sync-agenda.md. Update the JSON before each sync.