Dependency
A dependency is something one team needs from another party — work, a decision, data, an environment or a person — before it can complete its own work. It is tracked with a supplying party, a receiving party, a needed-by date, a committed date and a confidence level. Dependencies are the commitments a project relies on but does not control.
The defining feature of a dependency is that it crosses a boundary. Within a team, a sequence of tasks is simply a plan. Once the work sits with another team, another programme, a vendor or a shared service, delivery relies on a commitment rather than on a schedule the project manager can change.
Dependencies have a direction. An inbound dependency is something this project is waiting for. An outbound dependency is something another party is waiting on from this project. Both need to be logged: outbound dependencies are the ones that make a project the cause of somebody else's delay, and they are almost always under-recorded.
What it contains
| Field | What it records |
|---|---|
| Dependency ID | Reference used across both parties' plans and reports |
| Direction | Inbound or outbound |
| Description | What is needed, specifically enough that delivery is unambiguous |
| Supplying party | The team, programme or vendor providing it, with a named contact |
| Receiving party | The team that cannot proceed without it, with a named contact |
| Needed-by date | The date the receiving side requires it |
| Committed date | The date the supplying side has agreed to, which is the field that reveals the gap |
| Confidence | How firm the commitment is: agreed in writing, verbally agreed, assumed |
| Criticality | What happens if it arrives late — slippage, workaround, or a stopped workstream |
| Escalation route | Who is asked when the two dates diverge |
| Status and last confirmed | Open, at risk, delivered, and the date it was last checked with the supplier |
How it is used
A dependency log is only useful if both sides recognise the entry. The usual mechanism is a confirmation cycle: the receiving party logs the dependency, the supplying party accepts it with a committed date, and the entry is re-confirmed at an agreed interval. Anything not re-confirmed reverts to assumed.
At programme level the same information is often presented as a matrix rather than a list, showing which teams depend on which, so clusters of mutual dependency are visible. The Decision Log & Dependency Matrix holds that view for governance reporting, and the dependency tracking guide covers the fields that make a slipping commitment visible before the needed-by date arrives.
Where it goes wrong
The single most common failure is a dependency logged by one party and unknown to the other. It looks managed on the report and is not managed at all. The second is the missing committed date: a log that records only what the project needs, with no date the supplier has agreed to, is a wish list.
The third is stale confirmation. A dependency agreed in January and never re-checked will be reported green until the week it is needed. The fourth is outbound blindness — projects track what they are waiting for and not what others are waiting for from them, so their own slippage propagates without warning.
The fifth is a log kept at the wrong level. Recording every task handover between two teams that sit in the same room produces a register nobody reads, while the three commitments that genuinely constrain the plan are lost inside it. A dependency log is worth keeping only for the commitments that cross a boundary the project manager cannot reach across, and for those it needs a date, a name and a confirmation cycle.
Related terms
See also RAID log, issue log and cutover plan.
Questions
What is the difference between an inbound and an outbound dependency?
An inbound dependency is something this project waits for; an outbound one is something another party waits on from this project. Both belong in the log.
Who owns a dependency?
Two people: a named contact on the supplying side who commits to the date, and a named contact on the receiving side who chases it and escalates when it slips.
Is a dependency the same as a risk?
No, but an unconfirmed dependency is usually logged as a risk as well, because reliance on an uncommitted date is a risk to the schedule.
How often should dependencies be re-confirmed?
At an interval agreed with the supplying party, and always before the point where a late delivery could no longer be absorbed.