Dependency Tracking: Managing What You Don't Control

How to track cross-team and cross-project dependencies — the fields that matter, how to spot the ones that will slip, and why dependency logs fail.

A dependency tracker is the register of things a project needs from parties outside its control, and things it owes to others, each with a needed-by date, a committed date and a named counterparty on both sides. It is the artefact for the risk that most often causes a missed date.

Most projects that miss their date do not miss it because of work the team owns. They miss it because something arrived late from somewhere else — another team, another programme, a vendor, a shared environment.

A dependency tracker is the artefact for that risk. It differs from a plan in one important way: you cannot instruct the other side. You can only make the commitment visible and chase it.

The fields that matter

• ID — stable reference for escalation
• Direction — inbound (you need it) or outbound (they need it from you). Outbound gets forgotten and is how you become someone else's blocker.
• Description — the specific deliverable, not the topic. "Signed interface specification for the payments API" rather than "payments integration".
• Provider — the named individual on the other side. Not a team.
• Receiver — the named person on your side who is waiting
• Needed by — the date you need it, derived from your plan
• Committed date — the date they have actually agreed to. When this differs from needed-by, you have your risk list.
• Confidence — high / medium / low, your judgement of whether the committed date will hold
• Status — not started / in progress / delivered / at risk / breached
• Impact if late — what specifically stops, and what that does to your critical path
• Escalation route — who you go to when chasing stops working
• Last confirmed — the date you last had contact. Anything unconfirmed for a month is unknown, whatever the status column says.

Spotting the ones that will slip

Needed-by earlier than committed date. Obvious, and routinely left sitting in the log unaddressed because the gap is small at the time it is logged.

No named individual. Dependencies owned by a team slip more often, because no single person feels the obligation.

No plan entry on their side. If the other team cannot point to the task in their own backlog or plan, the commitment is verbal only. This is the strongest single predictor of a missed dependency.

Long-dated with no interim checkpoint. A deliverable due in four months with no contact until then will be late, and you will find out in month four. Add interim confirmation dates.

Different priority. Your critical dependency may be the other team's nice-to-have. Check where it sits on their priority list, not yours.

Making it work in practice

Review it fortnightly. Filter to anything due in the next six weeks plus anything marked at risk, and go through only those. A full review of every entry every time takes too long, so people stop doing it.

Confirm rather than assume. A dependency status is only as good as the last conversation. The "last confirmed" column makes staleness visible in a way that a status column never does.

Escalate on the date, not after. Agree in advance the point at which an unconfirmed dependency goes to the steering committee. Escalating late is what turns a dependency into a schedule change.

Show the outbound ones to the people waiting on you. It builds the reciprocity that makes chasing possible.