git:20260829.3b7c308 to git:20260829.2464776

---

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 materialising 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

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 materialised, at which point it is a status report.

## 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.