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.

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.