Identify the waiting points

For each major activity, ask what information, decision, access or external delivery it needs. Name the owner of that dependency and the expected confirmation. Avoid treating a date in a schedule as proof that the prerequisite will be available. Distinguish internal dependencies from those controlled by another organisation. Keep unresolved items visible in the project brief.

Use the map in reviews

Discuss changes to dependencies before updating downstream commitments. Identify work that can continue safely while another item is pending. Avoid compressing every later task automatically to preserve the original launch headline. Record the effect of a changed assumption and the decision made in response. A dependency map is useful when it helps the team choose what to do next, not when it becomes a complicated diagram nobody maintains.

Put the guide to work

Keep a dependency owner separate from the person who updates the schedule. The scheduler may report a delay without being able to resolve it. Naming the person who can obtain the missing input or decision gives the team a more useful route to action.

Imagine this

Hypothetical example

A launch plan assumes content approval and system setup happen simultaneously. Mapping the dependencies reveals that setup requires the approved content structure. The team changes the sequence and starts independent training preparation while the content decision is completed.

Make it practical.

Use this checklist as you read. Checks are not stored.

Published by Tap Tap Go. Product availability and eligibility vary by programme and market. About our stories.