Practical working guide
A project dependency log that turns blockers into decisions
Track a project dependency as a named prerequisite with an owner, required date and evidence of readiness. If it blocks work, state exactly which task is affected and who must decide what happens next. “Waiting” without a dependency or decision owner is not an actionable status.
Use a prerequisite-to-task chain
| Prerequisite | Details |
|---|---|
| Surface preparation complete | Affected task: Install flooring Readiness evidence: Inspection accepted Decision owner: Site lead |
| Approved copy received | Affected task: Publish service page Readiness evidence: Current text signed off Decision owner: Content owner |
| Specified part delivered | Affected task: Repair equipment Readiness evidence: Part and specification checked Decision owner: Delivery coordinator |
A blocker needs a choice
Fictional example: the part will arrive after the planned visit. Log the supplier’s confirmed date, the blocked repair and the person who will choose between rescheduling and reviewing an alternative part. Do not treat “supplier chased” as resolution. A blocker closes when evidence proves the prerequisite is met or an authorised plan change removes it. Keep the original date alongside the revised one.
Review the critical dependencies
At planning reviews, sort by required date and affected commitment, not by the loudest reminder. Separate internal, supplier and customer dependencies so accountability is clear. Ask whether another task can proceed safely without implying the entire project is unblocked. Link customer-owned actions to a waiting-on-client record rather than copying conflicting due dates into several places.
If the required date changes, update the linked milestone with the decision reference. Do not let two lists silently disagree.