Dependency map

Dependency map

Finds the stuff that will silently kill a project — a decision someone else owes us, a service we depend on that's about to change, a team whose work blocks ours that we haven't synced with. The point is visibility, not solving.

What this maps

Five kinds of dependencies:

1. Internal work — one team's task depends on another team's task
2. Decisions — we're waiting on a call from someone (leadership, a peer team, a customer)
3. External services — third-party APIs, vendors, partners
4. People — someone specific whose knowledge or approval is critical (single-point-of-failure risk)
5. Artifacts — we need a doc, a design, a legal review, a cleared dataset

Workflow

1. Scope

From $ARGUMENTS:

• One project name → single-project dependency map
• "all" → portfolio view, only cross-project dependencies (within-project details skipped)
• A list → focused map of those projects and the dependencies between them

2. Pull

For each project in scope:

• Notion project page — declared dependencies, blockers, "waiting on" notes
• Slack project channels — recent "blocked by", "waiting on", "still need from" messages in the last 30 days
• Risk log — dependency-category risks (especially single-point-of-failure people, vendors, decisions)
• Open decision log entries — decisions someone owes us
• GitHub (if enabled) — PRs blocked on review, issues tagged as blocked

3. Build the map

For each dependency found, capture:

• Type — work / decision / service / person / artifact
• Source — which project or team needs it
• Target — who or what owns the thing being depended on
• Status — resolved / in flight / not yet raised / blocked
• Criticality — is this on the critical path? Can work proceed in parallel without it?
• Age — how long has this been open?

4. Classify

Three bands of severity:

• Silent — a real dependency that nobody outside the source team knows about. Especially dangerous if the target isn't informed.
• Known but open — tracked, understood, but unresolved. OK if being worked; risky if aging.
• Managed — actively coordinated, clear path to resolution.

5. Find the critical path

If scoped to one project, the critical path is the longest chain of hard dependencies from "start" to "done." Anything on it slips the project.

If scoped to a portfolio, there may be multiple critical paths. Highlight the one with the most cross-team dependencies — that's usually the most fragile.

6. Output

# Dependency map — <project or portfolio> — <date>

**Projects in scope:** <list>
**Total dependencies tracked:** N
**Silent (unknown to target):** N  ·  **Open known:** N  ·  **Managed:** N

## Critical path
<For single-project: the longest chain of hard dependencies. For portfolio: the most fragile one, highlighted.>

1. <item> → <item> → <item>

If any item here slips, every downstream item slips.

## Silent dependencies (high risk)
These are depended-upon by our teams but the targets don't know. Each needs to be surfaced.
- **<dep>**: <source team> needs <thing> from <target>. Target not informed. Suggested action: <draft Slack/email using `/role-pgm:nudge-owner` or `/team-core:draft-email`>

## Known open dependencies
| Dep | Source | Target | Status | Age | Action |
| --- | --- | --- | --- | --- | --- |
| <thing> | <project> | <person/team> | <in flight / blocked> | <N days> | <what to do> |

## Managed (no action needed)
<Short list — just so the PgM knows what's already being tracked.>

## Single-point-of-failure risks
- <person or service> is on the critical path for <N projects>. If they're out / fail, here's what breaks.

## External services at risk
- <service> — <what depends on it> — <known changes, deprecations, outages to track>

## Proposed next steps
1. <specific action: ping X, file risk entry, raise with lead on Y, escalate Z>
2. ...

7. Publish

Show the map. Common edits:

• Reclassify dependencies the PgM has more context on
• Add dependencies the system didn't surface
• Drop ones that are already resolved

On approval:

• Save to Notion under the project management path
• If silent dependencies exist, offer to draft notifications via /role-pgm:nudge-owner or /team-core:draft-email
• If single-point-of-failure risks exist, offer to open risk log entries via /role-pgm:risk-log add

Don't

• Don't treat every "waiting on" Slack message as a dependency. Filter to ones that are material — i.e., would slip real work.
• Don't surface silent dependencies without also drafting a plan to resolve them. Visibility without action is anxiety.
• Don't auto-nudge people whose names show up as targets. Names on a dependency map are information; outreach is a separate decision.
• Don't try to track within-task dependencies at portfolio scale. "All" mode is for cross-project only — zoom in for detail.