How do you track dependencies between workstreams?
Record each dependency with a giving team, a receiving team, what is being handed over, the date needed and the date committed. The gap between those two dates is the signal. Review them on a fixed cadence with both parties present, escalate when the gap opens rather than when the date is missed.
Why dependencies need their own treatment
A dependency is the one item type in a RAID log where the owner cannot fix it alone. Risks and issues sit inside a team's control often enough that assigning an owner is most of the management. A dependency has two parties by definition: someone who needs something and someone who has to provide it. Tracking it as a single-owner row is why dependencies slip quietly and then arrive as issues in the week they were needed.
The record
| Field | Contents |
|---|---|
| ID | D-014, referenced in reports and minutes |
| Description | The specific artefact or output being handed over |
| Giving team | Who owes it, with a named individual |
| Receiving team | Who needs it, with a named individual |
| Date needed | When the receiver needs it to hold their own plan |
| Date committed | When the giver has agreed to deliver it |
| Confidence | The giver's assessment, high / medium / low |
| Impact if late | What stops, and which milestone moves |
| Status | Agreed, at risk, breached, delivered |
| Last confirmed | When both parties last agreed the dates |
Two fields carry more than the rest. Two dates rather than one — because a single date column hides whether the commitment ever matched the need. A dependency where the need is 3 March and the commitment is 24 March is already broken, and it is broken now rather than in March. Last confirmed — because a commitment agreed eight weeks ago by someone who has since moved onto other priorities is not a commitment, it is a memory. The wider field set and how it behaves at scale is covered in the dependency tracking guide.
Description has to be specific
"Integration work from the platform team" is not trackable. Nobody can say whether it has been delivered. "Signed-off interface specification for the customer master API, including error handling" can be confirmed as done or not done by either party without a discussion. Vague descriptions are the most common reason a dependency is marked delivered by one side and outstanding by the other.
Acceptance criteria are worth a line where the handover is substantial: what condition the thing has to be in to count. A specification delivered as a draft for comment is not the same as a signed-off one, and the difference is usually two weeks.
The register and the matrix
Two views of the same data, doing different jobs. The register is the working list, sorted by date needed, and it is what the weekly review reads. The matrix — giving teams down one axis, receiving teams across the other — is what the governance pack shows, because it makes the structure visible at a glance: which team everyone is waiting on, which pair of workstreams has a dozen dependencies between them and probably needs a joint plan rather than a tracker.
The matrix is a presentation of the register, not a separate document. Maintaining them independently produces two versions of the truth within about a month; the decision log and dependency matrix deck exists for the presentation layer specifically because the underlying register lives elsewhere.
Cadence
Dependencies need a review with both parties present, which is what separates it from the rest of the RAID review. Many programmes run a short dependency clinic — thirty minutes, workstream leads, fortnightly — covering only three groups: anything due in the next four weeks, anything whose confidence has dropped, and anything newly raised.
The question asked of the giving team is not whether the dependency is on track. It is what has been completed towards it. "On track" from a team that has not started is the standard failure, and it holds until roughly two weeks before the date.
Between clinics, the tracker feeds the weekly status report — usually just the count at risk and any breach affecting a milestone. The rest stays in the register, referenced by ID.
Spotting the ones that will slip
- The commitment date sits after the need date and has done since it was logged.
- Confidence is high but nothing has been produced yet.
- The giving team's own plan does not contain the work.
- The named individual on the giving side has changed twice.
- The dependency has been re-dated more than once without the receiver re-planning.
- Neither party has confirmed the dates in over a month.
The re-dating pattern is the strongest signal. A dependency moved once is normal; moved three times, it is being deferred rather than delivered, and the receiving team's plan is fiction.
Escalation
Escalate when the gap opens, not when the date is missed. By the date, everyone's options have gone. The trigger that works in practice is the date committed moving past the date needed, or confidence dropping to low — either raises it to the programme level with the milestone impact attached.
Escalation is also the point where the difference between internal and external dependencies matters. Inside the programme, a manager can re-sequence. Outside it — another department, a vendor, a regulator — there is no shared plan and often no shared priority, so those are worth tracking separately with a named sponsor-level owner. A vendor commitment is a contractual question as much as a delivery one, which is why it usually ends up alongside the SOW milestones in the vendor tracker rather than in the delivery register.
The RAID Log & Program Governance Pack carries the dependency tracker as its own tab alongside the RAID log and action log, with the at-risk flags derived from the two dates; where dependencies drive a phased rollout, the wave planner holds the same relationships as a sequencing constraint. How this fits the reporting layer above it is covered in programme governance.
Questions
Should dependencies live in the RAID log or their own tracker?
Either, as long as the record carries two parties and two dates. Programmes with more than about thirty dependencies usually split them out, because the review needs both parties present.
What is the difference between a dependency and a risk?
A dependency is a commitment from someone else that currently stands. The risk is that it is not met. Many logs carry the dependency and raise a separate risk once confidence drops.
How do you track dependencies on external parties?
Same fields, separate view, and a named owner senior enough to have the conversation. External dependencies have no shared plan behind them, so the confirmation date matters more.
Who chairs the dependency review?
The programme manager or PMO, with workstream leads present. It only works with both sides of each dependency in the room, which is what makes it a different meeting from the RAID review.