The Promise Column: A Separate Ledger for Delivery Dependencies
Photo: Foreign, Commonwealth & Development Office, CC BY 2.0, via Wikimedia Commons
Two records, two jobs
A risk register and a dependency ledger are often kept in the same spreadsheet because they are both concerned with things that might not go to plan. That convenience has a cost. The risk register answers a question about uncertainty: what might happen, how likely is it, and what would the effect be? A dependency ledger answers a narrower and more practical question: who has promised what to whom, by when, and what happens if the promise is not kept?
When dependencies are folded into the risk register, they acquire the language of probability and the habits of risk management. They are scored, reviewed monthly and often left with a nominal owner inside the delivery team. What they lose is the discipline of a commitment: a named provider, a named receiver, a date, an acceptance test and a consequence. The result is a familiar pattern in UK programmes. The plan shows a chain of work, the risk register shows a handful of amber items, and no single record shows that a supplier, another department or an internal specialist has actually agreed to deliver something by a particular date.
A separate dependency ledger does not replace risk management. It gives commitments their own record, so that they can be confirmed, chased and closed with evidence.
Why the risk register absorbs dependencies
Risk registers are designed to be broad. They accommodate technical uncertainty, resource pressure, regulatory change and supplier instability in one list. Dependencies are different in kind. They are bilateral. One party provides; another receives. They have a date that matters to a plan and a consequence that can be described in delivery terms. If the provider is late, the receiver cannot proceed as planned, and the effect should be visible without translating a risk score into a schedule impact.
Folding dependencies into the risk register also makes them hard to count. A programme may report twenty risks, but the delivery team may be waiting on fifteen commitments from six parts of the organisation. Without a separate ledger, those commitments are invisible as a portfolio. They cannot be aged, escalated or reviewed by counterparty. The team manages fear, but not the promises on which the plan depends.
There is a cultural point as well. Risk registers encourage speculation about causes. Dependency ledgers encourage confirmation of dates. In a formal delivery environment, that shift matters. It moves the conversation from what might go wrong to what has been agreed, what has been confirmed this fortnight and what remains unconfirmed.
The one-page ledger
The ledger should be short enough to review in a meeting and structured enough to support escalation. A single page with one row per commitment is usually sufficient. Each row should carry the following fields.
| Field | Question it answers |
|---|---|
| Dependency ID | How do we refer to this commitment consistently? |
| Description | What is being provided, in plain delivery terms? |
| Provider | Which person or organisation owes the commitment? |
| Receiver | Who needs it, and who accepts it? |
| Needed by | What date does the plan require? |
| Confirmed on | When did the provider last confirm the date? |
| Confidence | Is the date confirmed, probable or unconfirmed? |
| Acceptance test | What evidence will show that the commitment has been met? |
| Consequence if late | What work stops, moves or costs more? |
| Escalation trigger | At what point does this leave the delivery team? |
| Closure evidence | What has been received and accepted? |
Two fields do most of the work. The first is the confirmed date. A dependency without a recent confirmation is not a plan item; it is an assumption. The second is the consequence. If the team cannot state what would be affected by a slip, the dependency may be real but it is not yet material to delivery. Both fields force the conversation that the risk register tends to soften.
The ledger should distinguish between internal and external providers. Internal commitments are still commitments, but the escalation route is usually managerial rather than contractual. External commitments may sit with a supplier, a partner or another public body. The ledger does not need to reproduce contract terms, but it should show where the delivery team's influence ends and where formal escalation begins.
A fortnightly cadence that stays honest
A dependency ledger decays quickly if it is reviewed only at monthly governance. A fortnightly review, lasting no more than thirty minutes, keeps it current without turning it into a bureaucracy. The agenda should be fixed.
First, review every dependency that is overdue or due within the next thirty days. For each one, confirm the date with the provider and record the date of confirmation. Second, review every dependency marked unconfirmed. Decide whether it can be confirmed before the next review or whether it needs escalation now. Third, review closures. A dependency is closed only when the receiver has accepted the evidence, not when the provider says it has been sent. Fourth, review the consequence column. If a slip would no longer affect the plan, the dependency may be closed or downgraded; if a new consequence has appeared, the plan should be updated.
The review should produce decisions, not minutes. Each row should leave with one of four states: confirmed, unconfirmed, escalated or closed. That discipline prevents the ledger from becoming a passive list. It also gives the delivery team a simple measure of health: the proportion of material dependencies that have been confirmed within the last fortnight.
Escalation by trigger, not by mood
The ledger should specify in advance when a dependency leaves the delivery team. A typical trigger might be a commitment that remains unconfirmed within ten working days of the needed-by date, or a confirmed date that moves twice without a revised plan. The trigger should be agreed with the provider and the receiver, not invented at the point of failure.
This matters in UK delivery environments where escalation can be read as blame. A trigger makes escalation procedural. It is the ledger saying that a commitment has reached a defined point, not a manager making a judgement about a colleague. The ledger should record the escalation date and the revised commitment, so that the history remains visible.
What good looks like after a quarter
After a quarter of use, a dependency ledger should show four things. The number of open dependencies should be known. The age of unconfirmed dependencies should be visible. The slip rate by provider should be reviewable without personal commentary. And the plan should be traceable to commitments rather than assumptions.
None of this removes uncertainty. Risks still belong in the risk register, and they still need owners, scores and mitigation. But dependencies belong in their own record, with their own language of promises and dates. Separating the two gives delivery teams a clearer view of what they owe, what they are owed and what must be decided next.
