---
name: dependency-and-risk-management
description: Manages delivery risk and cross-team dependencies — identifying, sizing, mitigating and escalating what could stop the work. Use this to build a risk register that gets used, manage dependencies between teams, decide what to escalate and when, or work out why the same risks keep materializing unmanaged.
---

# Dependency and risk management

This is delivery risk: what could prevent this work from landing. Enterprise risk — the framework,
appetite and register at company level — is `legal-risk:enterprise-risk`, and the two should not be
merged.

## Dependencies are commitments or they are wishes

A dependency in your plan that the owning team has not agreed to, with a date they have committed
to, is a wish. Most plans contain several.

For each: what exactly is needed, from whom by name, by when, and what happens if it is late. Then
confirm it with the owning team in a way they would recognize as a commitment — an item on their
plan, not a mention in a meeting.

Track dependencies both ways. Teams reliably track what they are owed and forget what they owe, which
is why everyone believes they are being let down.

The dangerous ones are **transitive**: your dependency has a dependency you cannot see. Trace at
least one hop further than feels necessary, particularly where a shared specialist or a single team
appears repeatedly.

## A risk register people actually use

Most registers are written once for a gate and never opened. What makes one useful:

- **Specific.** "Integration delay" is a topic. "Vendor's API v2 is not released until March; our
  migration starts in February" is a risk you can act on.
- **Sized on both axes** — likelihood and impact — because the response differs entirely between a
  likely nuisance and an unlikely catastrophe.
- **Owned by someone who can act**, not by the project manager who can only report.
- **Carrying a decision date** — the point past which mitigation is no longer possible. This is the
  field most often omitted and the one that makes the register operational rather than decorative.

Review by exception: what changed, what is approaching its decision date. Reading the whole register
aloud is how registers stop being read.

## Mitigate, or accept explicitly

Four responses: avoid by changing the plan, reduce likelihood or impact, transfer to someone better
placed to carry it, or accept. Acceptance is legitimate and must be explicit, with a named accepter
— an unacknowledged acceptance is just an unmanaged risk.

Distinguish mitigation from contingency. Mitigation lowers the chance; contingency is what you do
when it happens anyway. Serious risks need both, and contingency needs to be prepared before it is
required.

## Escalate early and specifically

An escalation naming the decision needed, the options, and the date by which it is needed gets
resolved. A general expression of concern gets acknowledged and nothing happens.

Escalate when the decision exceeds your authority or the decision date is approaching — not when the
risk has already materialized, at which point it is a status report.

## Sources

`references/sources.md` in this skill lists the outside authorities that settle the questions
here — what each one is authoritative for, and what you may do with it. Check them before
answering on anything they cover, and cite what you used. Most are free to read and not free
to reproduce; the use note on each is binding.

## Never

- Carry a dependency the owning team has not committed to.
- Log a risk without an owner who can act on it.
- Accept a risk without naming who accepted it.
- Escalate a concern without naming the decision required.