The Expiry Clause: Making Cross-Team Commitments Earn Their Place in the Plan
Photo: Foreign, Commonwealth & Development Office, CC BY 2.0, via Wikimedia Commons
Cross-team dependencies have a habit of outliving the conditions that justified them. A commitment made in a planning workshop — a team will supply a data feed, a supplier will complete an interface, a specialist will be available for testing — is entered into the plan and then treated as a fixed asset. Months later, the original owner has moved on, the supporting evidence has thinned and the receiving team is still forecasting against a promise nobody has revalidated. The dependency line remains; the certainty behind it has quietly expired.
That is not a failure of planning discipline alone. It is a failure to recognise that a dependency is a perishable commitment. It needs a shelf life, an owner and a test of current validity. Without those, a plan accumulates false confidence, and delivery slippage is discovered only when the dependency fails at the point of need.
A dependency is not a fixed asset
In UK delivery environments, dependencies often cross organisational boundaries: between programme workstreams, between a client and a supplier, or between a central function and a business unit. Each commitment depends on a set of conditions — funding, availability, priority, technical agreement — that can change without anyone updating the plan. The dependency record stays static while the underlying reality moves.
A dependency should therefore be treated less like a line in a schedule and more like an entry in a register of perishable stock. It has a use-by date. If it is not renewed with fresh evidence, it should not be relied upon. That simple shift in language helps teams stop asking whether a dependency is 'still on the plan' and start asking whether it is still valid today.
Three fields that change the conversation
Every cross-team dependency should carry three fields that are often missing: an expiry date, a named accountable owner and a validity test.
The expiry date is not the date by which the dependency must be delivered. It is the date by which the commitment must be revalidated or retired. Setting it deliberately — typically 30 to 90 days ahead, depending on the volatility of the work — prevents old promises from becoming permanent furniture.
The accountable owner is a person, not a team inbox or a governance forum. That person is responsible for bringing evidence to the review and for saying plainly whether the commitment still holds. Naming an individual changes behaviour; a collective owner usually means no owner at all.
The validity test is a short, evidence-based question that can be answered yes or no. It might be: has the receiving team confirmed the interface specification? Has the supplying team named the individual who will do the work? Has funding been approved in the current cycle? Has the date been accepted by the party that must meet it? The test should be specific enough that a renewal cannot be granted on the basis of optimism alone.
A practical dependency record
A useful record can be simple. The aim is not a new system but a disciplined minimum that can sit alongside the existing plan.
| Field | What it captures |
|---|---|
| Dependency ID and description | A short, unambiguous statement of what is needed and by whom |
| Provider and receiver | The teams or organisations on each side of the commitment |
| Need-by date | The date the receiver requires the dependency to be satisfied |
| Accountable owner | The named individual responsible for revalidation |
| Validity test | The evidence required to keep the dependency live |
| Expiry date | The date by which the commitment must be renewed or retired |
| Current status | Live, renewed, retired or escalated |
| Fallback | What the receiver will do if the dependency is not renewed |
The fallback column is important. A dependency without a fallback is a single point of failure dressed as a plan. Recording the fallback does not solve the problem, but it exposes the cost of carrying an unvalidated commitment.
The monthly expiry review
A monthly review, lasting 30 to 45 minutes, is enough to stop the register from going stale. It should be chaired by the delivery lead or PMO, with each accountable owner present for their items. The pre-read should list only dependencies expiring in the next 30 days, plus any already overdue.
A short agenda works well:
- Confirm the items in scope and check that each has a named owner.
- Test the evidence against the validity test — not the owner's confidence.
- Decide one of three outcomes: renew, retire or escalate.
- Record the decision, the new expiry date and any change to the fallback.
- Update the plan and dependency register on the same day.
The rules matter more than the format. No renewal without evidence. Retirement is a legitimate outcome, not a failure. Escalation should be reserved for a decision that cannot be made in the room, not used as a substitute for one. And the plan should be updated immediately; a review that produces minutes but no plan change is just another meeting.
What changes after a quarter
The first effect is usually a reduction in the number of dependencies carried. Some are retired because they were never truly commitments; others are merged because two teams were describing the same need. The second effect is clearer dates. A need-by date that has been tested against evidence is more credible than one inherited from an old schedule. The third is earlier escalation. Problems surface at the expiry review rather than at the point of failure, when options are narrower and more expensive.
None of this requires a heavy process. It requires the discipline to treat cross-team commitments as time-bound, owned and evidence-based. Dependencies do not age well. A plan that assumes otherwise is storing up slippage. An expiry clause is a small control that keeps the plan honest — and keeps delivery moving on facts rather than faded promises.
