Day 6: Find Dependencies Before They Find You

The Concept

Dependencies are relationships between pieces of work. One team cannot begin until another provides something. A decision cannot be made until research is complete. A release cannot happen until access, testing, training, or approval is ready.

They are easy to miss because each team sees its own work clearly. The project manager has to see the handoffs between teams. AI can help by reading the plan from different perspectives, but every suggested dependency needs confirmation from someone close to the work.

Four kinds of dependency

Look for dependencies created by sequence, information, approval, and capacity. Sequence means one activity must happen before another. Information means a team needs a decision, specification, or data. Approval means progress depends on a person or governance step. Capacity means the work competes with another commitment.

The type matters because the response differs. A sequence dependency may need a new order. An approval dependency needs a decision date. A capacity dependency needs prioritisation or additional help.

Make dependencies actionable

"Waiting for finance" is not a useful project item. Who in finance? What exactly is needed? By when? What happens if it is late? What is the next action? A dependency becomes manageable when it has an owner, a date, and a consequence.

Example: turn a hidden handoff into a project item

Imagine a project that will launch a new customer onboarding flow. The plan says that the product team will finish the screens, engineering will build them, legal will approve the language, and support will prepare the help content. A simple task list may show four activities. A dependency review reveals more:

• Engineering needs the approved screens before it can estimate the build accurately.
• Legal needs the final claims and eligibility rules before it can review the copy.
• Support needs a working version of the flow before it can write useful guidance.
• The launch decision depends on a support readiness check, not just a completed build.

None of these relationships is solved by adding more detail to a task title. They need named owners, dates, and a shared understanding of what “ready” means. Record the actual handoff: “Legal approves onboarding claims by Tuesday so product can publish final copy for engineering estimation.” That sentence is much easier to monitor than “legal review.”

Run a dependency walkthrough

Take the work packages one at a time and ask four questions:

1. What must be true before this work can start?
2. What must this work provide to someone else?
3. Who can confirm that the input or output is ready?
4. What is the earliest point at which a delay becomes material?

Do not limit the conversation to the project team. A dependency may sit with procurement, security, finance, a vendor, a data owner, or an executive approver. Invite those roles into the confirmation step when the plan depends on them.

Watch for soft dependencies

Some dependencies are not formal gates. A senior reviewer may be needed to build confidence. A team may need time to learn a new process. A decision may be technically optional but important for stakeholder trust. AI can suggest these soft dependencies by comparing the plan with common handoffs, but treat them as questions until a person confirms them.

Use a simple status language

Use a small vocabulary so the list stays readable: confirmed, to confirm, at risk, blocked, or no longer relevant. Add a review date when the relationship may change. Avoid creating a complex scoring system before the team has agreed on the basic facts.

A final check before sharing

Read the dependency list as if you joined the project today. Could you tell what is needed, who provides it, when it matters, and what happens if it is late? If not, rewrite the item. A dependency map earns its place in the plan when it makes the next conversation easier.

Keep the map alive

Dependencies change as the work becomes clearer. At the end of a planning session, ask which relationships are now confirmed and which new ones appeared. During delivery, review the map when a milestone moves, a team changes its approach, or an assumption is replaced by evidence. A short, current list is more valuable than a detailed map nobody trusts.

When a dependency becomes blocked, do not simply change its colour. Record the decision or escalation required to unblock it. This turns the map into a way of managing flow rather than a passive description of the plan.

The best next action is usually a conversation with the person who controls the input. Make that request specific, include the required-by point, and explain the consequence of waiting.

For high-impact dependencies, agree how the team will escalate if the response does not arrive. An escalation path is part of the dependency design, not evidence that the plan has failed.

Use this today

Review the output with the people who own the handoffs. Ask them what the plan assumes about their work. Record what they confirm, what they reject, and what they cannot answer yet.

Remember this

• A dependency without an owner is a future surprise.
• Confirm relationships with the people doing the work.
• Describe the consequence, not just the connection.