Handle a high-dependency delivery
Treat coordination as real work: make dependencies visible, assign owners, define handoff quality, and avoid pretending the schedule is local when the delivery is not.
- Situation
- A delivery depends on many teams, systems, or approval paths.
- Goal
- Increase delivery predictability when success depends on multiple actors beyond one team.
- Do not use when
- the work is mostly local but the team is over-formalizing it
- Primary owner
- delivery lead
- Roles involved
delivery leadtech leadprogram or project lead if presentowners of each dependencysponsor when escalation power is needed
Context
The situation
Deciding whether to reach for this playbook: when it fits, and when it doesn't.
Use when
Conditions where this playbook is the right tool.
- Multiple teams must change in sequence or parallel
- Approvals or external providers materially affect timeline
- Critical integrations or contracts are involved
- The delivery path crosses ownership boundaries repeatedly
Stakes
Why this matters
What this playbook protects against, and why skipping or half-running it tends to be expensive.
Many deliveries fail because dependency work is treated as incidental overhead rather than as the true delivery system. What is not mapped early becomes surprise delay later.
Quality bar
What good looks like
The observable qualities of a team or system that is actually doing this well. Not just going through the motions.
Signs of the playbook done well
- The dependency graph is visible and current
- Each dependency has an owner and expected decision or output
- Handoff quality is defined, not assumed
- Blockers are surfaced before critical-path failure
- Status reflects dependency reality, not only local progress
Preparation
Before you start
What you need available and true before running the procedure. Skipping this is the most common reason playbooks fail.
Inputs
Material you'll want to gather first.
- Delivery objective
- List of participating teams or providers
- Expected handoffs
- Contracts and approvals
- Timeline constraints
Prerequisites
Conditions that should be true for this to work.
- Clear delivery objective
- Named stakeholders and participating owners
- Ability to escalate unresolved dependencies
Procedure
The procedure
Each step carries its purpose (why it exists), its actions (what you do), and its outputs (what you produce). Read the purpose. It's what keeps the step from degenerating into checklist theatre.
Map the dependency system
Turn vague coordination into visible structure.
Actions
- List each team, system, approval, and contract dependency
- Classify each as technical, organizational, operational, or external
- Show the sequence and coupling between them
Outputs
- Dependency map
Define what each dependency owes
Replace soft assumptions with explicit expectations.
Actions
- Name the required output, decision, or availability from each dependency
- Define acceptance quality for handoffs
- Set owner and due signal for each item
Outputs
- Dependency contract sheet
Separate critical from supporting dependencies
Protect the path that actually drives delivery.
Actions
- Mark which dependencies block the next major milestone
- Identify which can be parallelized, deferred, or buffered
- Focus coordination effort on critical-path items first
Outputs
- Critical dependency set
Create a coordination rhythm
Keep dependency reality fresh.
Actions
- Run a light but regular cross-owner check-in
- Review only blockers, changes, and handoff quality
- Escalate changes immediately when critical items slip
Outputs
- Dependency review cadence
Re-plan around dependency movement
Keep the plan connected to reality.
Actions
- Update milestones when dependencies shift materially
- Remove fake confidence from local plans when external inputs move
- Record major dependency changes and decisions
Outputs
- Updated delivery plan
- Dependency decision log
Judgment
Judgment calls and pitfalls
The places where execution actually diverges: decisions that need thought, questions worth asking, and mistakes that recur regardless of good intent.
Decision points
Moments where judgment and trade-offs matter more than procedure.
- Which dependencies are truly critical path?
- Which dependencies can be buffered or decoupled?
- Where is the bottleneck technical versus organizational?
- When does a dependency issue require sponsor escalation?
Questions worth asking
Prompts to use on yourself, the team, or an AI assistant while running the procedure.
- What does each dependency actually owe us?
- Which dependencies are critical path versus distracting noise?
- What changed upstream that should already have changed our plan?
Common mistakes
Patterns that surface across teams running this playbook.
- Tracking only tasks, not dependencies
- Assuming all dependencies are equal
- Holding large coordination meetings without explicit dependency outputs
- Maintaining local green status while critical external blockers go red
Warning signs you are doing it wrong
Signals that the playbook is being executed but not landing.
- Teams discover blockers late and act surprised each cycle
- Dependency discussions focus on general updates instead of decisions and outputs
- The delivery plan remains unchanged even when key dependencies move
- Nobody can say who owns a blocked handoff
Outcomes
Outcomes and signals
What should exist after the playbook runs, how you'll know it worked, and what to watch for over time.
Artifacts to produce
Durable outputs the playbook should leave behind.
- Dependency map
- Dependency contract sheet
- Critical dependency set
- Dependency decision log
Success signals
Observable changes that mean the playbook landed.
- Cross-team blockers are visible earlier
- Handoff expectations become clearer and less emotional
- Schedule changes are tied to real dependency movement
- Teams use the same dependency picture
Follow-up actions
Moves that keep the playbook's effects compounding after it finishes.
- Look for structural ways to reduce dependency count in future work
- Promote repeated handoff patterns into explicit contracts or platform capabilities
- Review which dependencies were real versus historically inherited
Metrics or signals to watch
Longer-horizon indicators that the underlying problem is receding.
- Late dependency discovery rate
- Blocked-by-external ratio
- Handoff rejection or rework rate
- Critical dependency age
AI impact
AI effects on this playbook
How AI-assisted and AI-driven workflows help execution, and the ways they can make it worse.
AI can help with
Where AI tooling genuinely reduces the cost of running this playbook well.
- Extracting dependency references from tickets, docs, and repos
- Drafting dependency tables and handoff summaries
- Highlighting likely missing consumers or approval paths
AI can make worse by
Distortions AI introduces that make the underlying problem harder to see.
- Producing plans that look comprehensive without capturing social or approval reality
- Encouraging false completeness in dependency lists
- Making summaries cleaner than the actual commitments
Relationships
Connected playbooks
Failure modes this playbook tends to address, decisions behind the situation, red flags that motivate running it, and neighboring playbooks.