Why dependency mapping should come before anything else

Most change programmes begin with a plan. A timeline, a set of workstreams, a list of owners. What they rarely begin with is a clear picture of how those workstreams connect to each other, which means the plan is built on assumptions that nobody has tested. Dependency mapping is the step that tests those assumptions before they become problems.

What dependency mapping actually is ¶

A dependency map is a structured record of which workstreams, decisions or outputs rely on which other workstreams, decisions or outputs. It is not a Gantt chart, though it informs one. It is not a risk register, though it feeds into one. It is the answer to the question: if this piece is late or changes shape, what else moves?

The map does not need to be elaborate. In practice, a well-structured spreadsheet or a simple visual diagram is sufficient for most programmes. The value is not in the tool. It is in the conversation that producing the map forces the team to have.

The conversation the map forces ¶

When you ask a workstream lead to name their dependencies, you learn two things quickly. First, you learn what they think they are waiting for. Second, you learn whether the person they are waiting for knows that. Those two things are frequently not aligned.

That misalignment is not a sign of poor management. It is a normal feature of complex programmes. The dependency mapping exercise surfaces it early, when it is still easy to resolve, rather than in week eight when the delay has already happened.

When to do it ¶

The right time to produce a dependency map is before the programme plan is finalised, not after. If the map is produced after the plan, it tends to be used to justify the plan rather than to test it. That defeats the purpose.

In practice, Colin Dunmore produces a first-pass dependency map in the second week of any change management engagement, after the initial stakeholder interviews but before the implementation roadmap is drafted. The map is then reviewed and updated at each fortnightly check-in, because dependencies shift as the programme moves.

A note on scope ¶

Dependency mapping does not need to capture every possible connection. A map that tries to capture everything becomes too complex to use. The useful version captures the dependencies that, if broken, would materially affect the programme's timeline or outcomes. That is a smaller set than most people expect, and identifying it is itself a useful exercise.

If you are about to start a change programme and the dependency map is not yet on the agenda, it is worth adding it before the plan is finalised. The conversation it generates is usually the most useful one the team has in the first month.