Dependency Tracking Deep Dive

Dependency types

Hard dependencies

Work cannot begin or continue without the deliverable. Example: cannot start frontend integration until the API contract is finalized. These require the most rigorous tracking.

Soft dependencies

Work can proceed with a workaround, but the final deliverable needs the dependency. Example: can build against mock data while waiting for the real data pipeline. Track these but with lower urgency.

External dependencies

Deliverables from outside your organization - vendor APIs, third-party approvals, regulatory decisions. These carry the highest uncertainty because you have the least control. Always have a fallback plan.

Internal cross-team dependencies

Deliverables from other teams within your organization. These are the most common source of project delays. The key risk is priority misalignment - your critical dependency may be their low-priority backlog item.

Dependency documentation template

For each dependency, capture:

Dependency ID: D-XXX
Description: [What exactly is needed]
Source team: [Who needs it]
Target team: [Who provides it]
Deliverable: [Specific artifact - API endpoint, library version, design spec, etc.]
Due date: [When it's needed by]
Buffer: [How many days of float before it blocks critical path]
Status: [Unconfirmed / Confirmed / In Progress / Delivered / Late / Blocked]
Confirmation date: [When the target team acknowledged the commitment]
Target contact: [Primary person]
Backup contact: [Secondary person]
Fallback plan: [What to do if it's late]
Last checked: [Date of most recent status check]

Cross-team coordination protocols

Dependency handshake

When establishing a new dependency:

1. Write the dependency spec (what, when, acceptance criteria)
2. Send to the target team lead with a request for confirmation
3. Get explicit acknowledgment with their committed date (may differ from your requested date)
4. If dates misalign, escalate immediately - do not wait
5. Document the confirmed date and add to both teams' tracking systems

Weekly dependency check

Every week, for each active dependency:

1. Contact the target team's designated contact
2. Ask three questions: Is it still on track? Any blockers on your side? Any scope changes?
3. Update the dependency log with the response and date
4. If status changed, update the risk register accordingly

Escalation triggers

Escalate a dependency when any of these conditions are true:

• Target team has not confirmed the dependency within 5 business days of request
• Status check reveals a slip of more than 2 days on a critical-path dependency
• Target team's contact is unresponsive for more than 3 business days
• Scope of the deliverable has changed without agreement
• The dependency is within 1 week of due date and not yet in progress

Dependency visualization

Simple text-based dependency chain

Phase 1: Foundation
  [T1: Schema design] --(feeds)--> [T2: API implementation]
  [T3: Auth setup] --(feeds)--> [T2: API implementation]

Phase 2: Integration
  [T2: API implementation] --(feeds)--> [T4: Frontend integration]
  [T5: Design specs] --(feeds)--> [T4: Frontend integration]

Phase 3: Validation
  [T4: Frontend integration] --(feeds)--> [T6: E2E testing]

Critical path: T1 -> T2 -> T4 -> T6 (shortest: 8 weeks)
Float: T3 has 2 weeks float, T5 has 1 week float

Dependency health dashboard

Health rules:

• GREEN: Confirmed, on track, more than 5 days of buffer
• AMBER: Confirmed but less than 5 days of buffer, or minor scope questions
• RED: Unconfirmed, late, blocked, or contact unresponsive
• DONE: Delivered and accepted

Managing blocked work

When a dependency blocks progress:

1. Immediately log it as an Issue (not just a Risk) in the RAID log
2. Quantify the impact: which tasks are blocked, how many person-days are idle
3. Activate the fallback plan if one exists
4. Redirect blocked team members to non-blocked work (pull forward future tasks, pay down tech debt, improve test coverage)
5. Escalate with impact data: "Team X is blocked. 3 engineers idle. Costing 15 person-days per week. Need [dependency] by [date] or we slip milestone by [N days]."

Common dependency anti-patterns

Risk Management Deep Dive

Risk identification techniques

Pre-mortem analysis

Assume the project has already failed. Ask each team member independently to list reasons for failure. Aggregate and deduplicate. This technique bypasses optimism bias and surfaces risks people are reluctant to raise in normal planning.

Assumption mapping

List every assumption the plan relies on. Rate each assumption's certainty (Confirmed/Likely/Uncertain/Unvalidated). Any assumption rated Uncertain or Unvalidated becomes a risk candidate. Common hidden assumptions: API stability, team availability, third-party SLA compliance, approval timelines.

Dependency risk scan

For each external dependency, ask: What happens if this is 1 week late? 2 weeks late? Never delivered? If any answer threatens a milestone, create a risk entry with the dependency as the trigger.

Historical pattern review

Check post-mortems from similar past projects. Common recurring risks by project type:

Quantitative risk assessment

3x3 risk matrix

Score each risk on Likelihood (1-3) and Impact (1-3). Multiply for a Risk Score (1-9).

Impact -->    Low(1)    Medium(2)    High(3)
High(3)    |  3(M)   |   6(H)    |   9(C)   |
Medium(2)  |  2(L)   |   4(M)    |   6(H)   |
Low(1)     |  1(L)   |   2(L)    |   3(M)   |

• Critical (7-9): Requires immediate mitigation plan and weekly review. Escalate to sponsor.
• High (5-6): Requires mitigation plan. Review biweekly.
• Medium (3-4): Monitor. Review monthly.
• Low (1-2): Accept. Review quarterly or at milestones.

Expected delay calculation

For schedule risks, estimate: Expected Delay = Probability x Days of Impact. Sum expected delays across all open risks for a risk-adjusted timeline. If risk-adjusted completion exceeds the deadline, the plan needs intervention now, not later.

Mitigation strategy patterns

Avoid

Eliminate the risk by changing the plan. Example: if a dependency on Team X's API is risky, build an internal adapter that removes the dependency entirely.

Transfer

Shift the risk to another party. Example: use a managed service instead of self-hosting to transfer operational risk to the vendor.

Mitigate

Reduce likelihood or impact. Example: cross-train a second engineer to reduce the impact of a key-person dependency. Add integration tests early to reduce likelihood of late-discovered bugs.

Accept

Acknowledge the risk and prepare a contingency plan. Use when mitigation cost exceeds expected impact. Document the acceptance decision and the trigger conditions for the contingency plan.

Buffer

Add explicit time buffers to the schedule for high-uncertainty tasks. A common formula: add 20% buffer to any task with Medium+ risk. Add 40% buffer to tasks with High risk and external dependencies.

Risk review cadence

Risk register maintenance rules

1. Every risk has exactly one owner - never "the team"
2. Review date is updated every time the risk is discussed, even if nothing changes
3. Closed risks stay in the register with a resolution note - they inform future projects
4. New risks can be added by anyone at any time - do not gate risk identification
5. Risk scores change as the project progresses - a Low risk in week 1 may become High in week 6

Stakeholder Communication Deep Dive

Stakeholder mapping

Influence-Interest matrix

                    High Interest           Low Interest
High Influence   | MANAGE CLOSELY     |  KEEP SATISFIED    |
                 | (Sponsor, PM)      |  (VP, Legal)       |
Low Influence    | KEEP INFORMED      |  MONITOR           |
                 | (Dev team, QA)     |  (Other teams)     |

• Manage closely: Direct, frequent, detailed updates. Include in decisions. These stakeholders can make or break the project.
• Keep satisfied: Executive summaries. Proactive on bad news. Do not overwhelm with detail but never surprise them.
• Keep informed: Regular broadcast updates. Invite input on their areas. They care and want to know.
• Monitor: Minimal communication. Include in broad announcements only.

Stakeholder profile template

For each key stakeholder, document:

Name: [name]
Role: [title/function]
Quadrant: [Manage closely / Keep satisfied / Keep informed / Monitor]
Primary concern: [What they care most about - deadline, quality, cost, scope]
Communication preference: [Email / Slack / 1:1 / Document]
Update frequency: [Daily / Twice weekly / Weekly / Biweekly / Monthly]
Decision authority: [What decisions they can make]
Known preferences: [Prefers data over narrative / Wants options not problems / etc.]

Communication templates

Weekly status update (executive)

Subject: [Project Name] Weekly Status - [Date] - [RAG STATUS]

TL;DR: [One sentence summary of the week. Lead with the most important thing.]

## Status: [GREEN/AMBER/RED]
[If AMBER or RED: One sentence on why and what's being done about it.]

## Key progress
- [Achievement 1 - tied to a milestone]
- [Achievement 2]

## Next week
- [Priority 1]
- [Priority 2]

## Decisions needed
- [Decision] by [date] from [person] - [context in one line]

## Risks (top 3)
1. [Risk] - [RAG] - [Mitigation in progress]

Escalation communication

Subject: [ESCALATION] [Project Name] - [Issue in 5 words]

## The problem
[One paragraph. What happened, when, and the immediate impact.]

## Impact
- Timeline: [X days/weeks delay to milestone Y]
- Cost: [additional resources, vendor costs, opportunity cost]
- Quality: [any quality implications]

## Options

### Option A: [Name]
- Description: [What we'd do]
- Timeline impact: [+X days]
- Cost: [$$]
- Trade-off: [What we give up]

### Option B: [Name]
- Description: [What we'd do]
- Timeline impact: [+X days]
- Cost: [$$]
- Trade-off: [What we give up]

### Option C: [Name] (Recommended)
- Description: [What we'd do]
- Timeline impact: [+X days]
- Cost: [$$]
- Trade-off: [What we give up]
- Why recommended: [Brief rationale]

## Decision needed
[What decision, from whom, by when]

Milestone completion announcement

Subject: [Project Name] - Milestone [N] Complete: [Milestone Name]

## Summary
[What was delivered. 2-3 sentences.]

## Key deliverables
- [Deliverable 1] - [status: complete/partial]
- [Deliverable 2] - [status]

## Metrics
- Planned completion: [date]
- Actual completion: [date]
- Variance: [+/- N days]

## Next milestone
- [Milestone name] - Target: [date]
- Key focus: [1-2 sentences]

## Acknowledgments
[Call out teams or individuals who made notable contributions]

Communication cadence by project phase

Difficult conversation playbooks

Delivering bad news to a sponsor

1. Pre-wire before the meeting: Never surprise a sponsor in a group setting. Send a brief heads-up message: "I want to flag something before our meeting - [one sentence on the issue]. I have options to discuss."
2. Lead with the impact: "We are at risk of missing the April 15 deadline by approximately 2 weeks."
3. Own it: Do not blame. "I should have flagged this earlier" builds more trust than "Team X dropped the ball."
4. Present options immediately: Never deliver bad news without a path forward.
5. Ask for what you need: Be specific. "I need a decision on scope reduction by Friday" is better than "What should we do?"

Negotiating a scope change

1. Frame as a trade-off, not a failure: "To hit the April date, I recommend we move feature Y to Phase 2."
2. Quantify what you're giving up and what you're protecting.
3. Show the alternative: "If we keep full scope, the new date is [X]. Here's why."
4. Get explicit sign-off. A verbal "yeah, okay" is not enough. Send a follow-up email documenting the agreed change.

Handling stakeholder disagreement

1. Identify the root cause of disagreement: different priorities, different information, or different risk tolerance.
2. If different information: share the data and align on facts first.
3. If different priorities: escalate to the person who can arbitrate (usually the sponsor).
4. If different risk tolerance: make the risk explicit and let the decision-maker decide.
5. Document the decision and the reasoning. Revisiting settled decisions wastes time.

RAG status definitions

Define these at project start and apply them consistently:

Rules for RAG changes:

• Moving from GREEN to AMBER requires a mitigation plan within 48 hours
• Moving from AMBER to RED requires an escalation within 24 hours
• Moving from RED to GREEN requires evidence, not just optimism
• Never skip AMBER - going directly from GREEN to RED indicates a tracking failure