Dependency Tracker Example: Sixteen Live Dependencies on a Cloud Migration

The example

The tracker below belongs to a fictional cloud migration programme: around 200 applications moved out of a leased datacentre in four waves, with a contractual exit date at the end of the year. Sixteen open dependencies is typical at the start of wave 1. Most sit with teams inside the same organisation but outside the programme, which is the ordinary case and the hardest one, because there is no contract to point at.

Reading the example

• ID - a stable reference used in the status report, the escalation email and the wave plan, so that everyone is arguing about the same item.
• What is needed - the deliverable, not the activity. "Firewall rule set for the payroll application" can be handed over and recognised; "security engagement" cannot. If the row does not name a thing, nobody can say whether it arrived.
• Provider and consumer - both sides, named. Two columns rather than one because the useful questions differ: the provider needs to know the date, and the consumer needs to know what breaks. Naming a team is acceptable here only if a person inside it has agreed to own it.
• Type - technical, decision, contractual, business, resource or policy. It matters because the chase is different. A technical dependency is chased through a delivery plan; a decision is chased through whatever board owns it, and the lead time for the next meeting is often the real constraint, as D-10 shows.
• Needed by - the date derived from the plan, calculated backwards from when the consuming work starts. This is the programme's number and does not change because the provider is busy.
• Committed - the date the provider has actually agreed, or an explicit "not committed". Keeping these as separate columns is the single most useful decision in the whole tracker. D-02 shows a real gap of a week; D-03 shows the worse case, where nothing has been promised at all.
• Confidence - how much the commitment is worth, based on evidence rather than tone. High normally means it is in the provider's own plan with a named owner; low means someone said it would probably be fine.
• Last confirmed - the date the commitment was last checked. A commitment made in February and never revisited is not a commitment, it is a memory. Sorting by this column finds the dependencies that are quietly rotting.
• Impact if late - written in terms the provider will care about. "Wave 1 cannot start; three-week slip to every later wave" travels much further inside an organisation than "impacts programme timeline".
• Status - on track, at risk, late or delivered, derived from the two dates and the confidence rather than typed by hand. Delivered rows stay in the tracker as a record of what was relied on.

The three columns that do the work

Needed by, committed and last confirmed are what turn a list into a tracker. Between them they answer the only question that matters: is somebody going to give us this thing in time, and how recently did they say so.

D-01 and D-02 look similar on a plan. One has a matching commitment, confirmed a fortnight ago, and is fine. The other has a commitment a week later than needed, which is a scheduling problem with an obvious next step: either the payroll cut moves or security operations reprioritises, and one of those conversations has to happen this week. Merging the two dates into a single "date" column hides that entirely.

The three late rows are late for different reasons and need different handling. D-03 is a legal dependency where the programme has no leverage and the impact is total; that is an escalation to a sponsor, not a chase. D-11 is a policy gap nobody owns, which usually means the programme has to draft the policy itself and ask for approval. D-15 sits with a third party, where the answer is normally commercial and slow, so the row also names the fallback. The general approach is set out in the dependency tracking guide.

How this is worked

In practice the tracker is reviewed weekly with the workstream leads, and the review is short because only three questions are asked per row: has the needed-by date changed, has the commitment changed, and when did we last speak to the provider. Rows where nothing has changed for three weeks are the ones to look at, not the ones being discussed loudest.

Escalation follows from the columns rather than from irritation. A dependency goes to the programme board when the gap between needed and committed cannot be closed by the two teams, or when there is no commitment at all and the needed-by date is inside four weeks. That threshold is written down in advance so escalation is a process rather than a judgement about how annoyed somebody is. Where those thresholds sit and who owns them is a governance design question, covered in programme governance.

What this example leaves out

• Direction both ways. This tracker only records what the programme needs. Real programmes also owe things to other teams, and those commitments deserve the same discipline - not least because they are the rows that get forgotten.
• The link to the plan. Needed-by dates here look like fixed facts. They are derived from plan activities, and when the plan moves they should move with it. Without that link the tracker drifts out of date silently.
• Evidence. A real row points at the email, the minute or the plan line where the commitment was made. "Committed" with nothing behind it is a recollection, and recollections differ.
• Chains. D-01 depends on D-10 being approved first. Trackers rarely model that, which is why a single slip sometimes moves three dates at once and nobody sees it coming.
• Cost. None of these rows carries the cost of being late. On a programme paying for a leased datacentre by the month, that number is often the most persuasive thing available.
• The relationship. Nothing in a table records that the identity team delivered early because someone spent two days helping them, which is how most of these actually get done.

The working version of this tracker sits in the RAID log and governance pack alongside the RAID log it feeds, and the presented version - the cross-team matrix that goes to a committee - is in the decision log and dependency matrix. The wave and application planning behind this example is the cloud migration wave planner.

Examples · All 36 templates