Dependency Tracker

What this tool does

CM8-298 is a register for the dependencies that live between plans: the thing another team owes you, the decision somebody above you has to take, the environment a third party controls, the person you do not employ. You record what is needed, who must provide it, when it is needed, whether the provider has actually agreed, and what happens if it is late. The tool draws a timeline of what lands when, ranks the providers you depend on, measures how far things slip, and prints a register for a cross-team meeting. It runs inside this one file — no account, no upload, no network request of any kind.

Why cross-team dependencies fail differently from tasks

A task inside your own plan has an owner who reports to the same governance you do, sits in your update meeting, and can be reprioritised by a conversation. A cross-team dependency has none of that. It sits in the gap between two plans, and nobody owns a gap. In your plan it is a box with an arrow pointing off the page; in theirs — if it appears at all — it is one item competing with everything their own sponsor wants, and their sponsor is not your sponsor. Neither plan contains the whole thing, so neither planning process protects it.

The consequence is a characteristic failure shape. The receiving team finds out late, because nothing tells them the item is in trouble until the date passes and it does not arrive; the providing team has often not registered it as a commitment at all, and is genuinely surprised to be chased. By then the cheap options — resequencing, a workaround, a different supplier — have expired, and all that is left is escalation. Everything here exists to move that discovery earlier.

The confirmation rule

This is the heart of the tool. A dependency the provider has not agreed to is not a dependency. It is a hope.

It is remarkable how much of a typical register turns out to be hope once you ask directly. Somebody mentioned a date in a meeting; an email was sent and never answered; a name appeared on a slide. None of that is a commitment, and none of it will hold when the provider's priorities change — because from their side there was never anything to hold. The tick box means something narrow: a named person on the provider's side, with the authority to commit their team, has confirmed that this thing, in this form, arrives by this date. Not "is aware of it". Not "does not object". Confirmed.

Any open dependency without the tick shows Not agreed in red, and the critical and unconfirmed tile counts the ones where that combination is dangerous. Work those first, before the overdue ones: an overdue dependency is at least a known quantity, and an unconfirmed critical one is an unexploded assumption. Confidence records the same thing on a scale — high means confirmed and running to plan, medium means agreed but not yet demonstrated, low means not confirmed. Low confidence with the agreed box ticked is a contradiction, and the tool will not accept it.

Inbound and outbound in one register

Most teams track only what they are waiting for. Put both directions in the same register, because the outbound ones are what other people are chasing you for — and they are the ones you are most likely to break, since they are invisible in your own plan. An outbound item is somebody else's critical path running through your team; it deserves a date, an owner and the discipline you demand of your providers. Both together also show your position in the network: three inbound and eleven outbound means you are a provider more than a consumer.

Criticality and the impact sentence

Criticality is about consequence, not urgency. Critical means delivery stops without it; the rest is degrees of rework and inconvenience. Keep it scarce — a register where a third of the items are critical has no priority order, and providers learn to discount your labels.

The impact-if-late sentence does the real work, which is why the tool insists on one before accepting a critical dependency. Your dependency is one row in a backlog somebody is ordering against their own pressures. What moves it up that list is not the word "critical" — every requester writes that — but a specific, checkable consequence. "Needed urgently" changes nothing. "The racking crew is booked for one week only; with no power they stand down and rebook in about eight weeks" gives them a cost, a date and a decision. Write it as though the reader has never heard of your project, because they probably have not.

Needed, promised, delivered

Three dates, doing three jobs, and the discipline is keeping them apart.

• Date needed is the last date it can arrive without disrupting your plan — a constraint from your own sequence, not a preference. Asking for things three weeks early "to be safe" teaches providers that your dates are negotiable.
• Date promised is what the provider said. When it is later than the date needed you have a problem today, and the register shows that slip immediately rather than waiting for the thing to be late.
• Date delivered is when it actually arrived. Record it even when nobody is asking: it is the only way the on-time rate and the average slip mean anything.

Slip is measured against the date needed, not the promise — measuring against the promise lets a provider re-promise their way to a perfect record. Early delivery gives a negative slip and counts as on time, which is correct: early is good.

Chasing, and who owns it

Every dependency needs one named owner whose job is to chase it — not the project manager by default, but the person closest to the provider, who will notice the tone of an answer changing. Chasing is not nagging: it is a short, regular, specific conversation that keeps your item visible in somebody else's queue. The chase window in the settings, fourteen days by default, marks open dependencies as due; set it to a lead time long enough that a problem can still be worked around. Review the open list weekly, in date-needed order, and ask two questions per row: is the date still good, and has anything changed on your side?

When a critical dependency will not firm up

This is the situation that decides whether a register is useful: something is critical and the provider will not confirm it. The instinctive response — keep asking — is the one that fails, because a fourth request produces the same answer as the first three and burns the weeks in which you could still have acted. There are three real moves, all of which must be made early:

• Find a workaround. A stub, a manual process, a smaller version, a different supplier. Usually cheaper than the delay, and always cheaper than the delay discovered late.
• Change the sequence. Bring other work forward and push the dependent work back, so the date needed moves out and the provider's uncertainty stops costing you anything.
• Escalate to somebody who owns both sides. A genuine priority conflict between two teams can only be resolved above both of them. Escalate with the impact sentence and the date, and ask for a decision rather than for help.

Do one of the three and record which in the notes. A critical dependency left at low confidence with no action is the project quietly deciding to gamble.

What this is not

This register handles the dependencies between plans. The finish-to-start dependencies inside a single plan — this task cannot start until that one finishes, and here is the resulting slack — belong in a Gantt Chart Planner, which schedules them properly. The distinction is practical: inside one plan a dependency is a scheduling relationship you can calculate with; between plans it is a promise between two organisations that no calculation makes more reliable.

The spreadsheet workflow

Dependencies are usually first collected in a workshop or from several teams at once, and retyping them loses a day.

• Spreadsheet template saves a CSV whose headings are exactly this tool's column names, with a guidance row explaining what each expects — the date format and the accepted values for type, direction, criticality, confidence and status.
• Fill it in, one row per dependency, then delete the guidance row and save as CSV.
• Import spreadsheet reads it back. Columns match by heading, so order does not matter and extra columns are ignored. Rows failing validation — a critical dependency with no impact sentence — are skipped and reported by row number.

The file is read inside your browser, importing adds to what is already here, and nothing is uploaded.

The formulas

Slip shows "—" when there is neither a delivered nor a promised date, because a dependency nobody has put a date against has not slipped — it has never been committed to, which the confirmation flag reports instead. Both rates are calculated only over dependencies actually marked delivered, so they do not improve merely because a late item has not been closed. Neither means much below a handful of deliveries: with three delivered items, one late produces 67%, which describes almost nothing.

FAQ

How much detail should the description carry? Enough that the provider knows what "done" looks like — format, quality, environment, who signs it off. Most disputed dependencies were delivered; they just were not delivered in a usable form.

Should I log a dependency the provider has refused? Yes, as cancelled with the reason in the notes. The decision and its consequence are what you will need three months later.

One dependency needed by three projects — one row or three? Three, sharing the description. The dates and impacts differ; one row would force the earliest date and the worst impact, which is true for nobody.

The provider disputes a date I recorded. That is the register doing its job. An unagreed date surfaced in a meeting is worth more than an agreed date that existed only in your file.

Saving your work

Dependencies, settings and the report header are written to this browser's local storage as you type. That storage belongs to one browser on one computer. Treat Export .json as the real save — one file containing everything, which Import .json restores anywhere, and the sensible way to hand the register to whoever runs the cross-team meeting. Export CSV gives you every dependency in the current filter. Reset erases everything, with no undo.

Accuracy & disclaimer

The arithmetic is simple and the tool performs it faithfully: differences between dates, a rate and an average. What it cannot do is know anything you have not written down.

This register tracks the dependencies somebody thought to log. The ones that cause real damage are usually the ones nobody realised were dependencies until they were late — a shared environment, an approval nobody knew was required, a single person who turned out to be the only one who could do the job. A tick in the agreed column records that somebody said yes; it does not mean they have the capacity to deliver, or the authority to have promised. Use it to have earlier and more specific conversations, not as evidence that the plan is safe.