How to Manage Project Dependencies

The problem is visibility, not planning

Teams that plan carefully still get blindsided by dependencies, and the reason is rarely that the dependency was unknown. It's that it was known to one person, tracked in their head or in a message thread, and never surfaced anywhere the rest of the project could see it. A dependency you've identified but can't see the status of is functionally the same as one you never identified: you find out it's late at the same moment either way.

Managing dependencies well is less about mapping them once at the start and more about keeping their status visible continuously, so that a delay on the upstream side is known before it reaches the downstream team.

Cross-team dependencies are a different problem than internal ones

A dependency inside one team is usually easy to manage: everyone's on the same board, in the same standup, working from the same priorities. Cross-team dependencies are harder for a specific reason: the upstream team doesn't necessarily share your priorities. Your blocking task might be their fourth-priority item this sprint, and nobody told you that when you built your plan around their delivery date.

The fix isn't more meetings between teams. It's making the dependency's priority and status visible to both sides without requiring either to ask. If the upstream team can see that their task is blocking three other teams, that's information their own prioritisation should account for. If they can't see it, you're relying on someone remembering to mention it, which is exactly the failure mode that causes the surprise slip.

The false dependency

Not everything that looks like a dependency is one. A common failure mode is sequencing two tasks because "that's the order we usually do it in," not because the second genuinely requires the first's output. This artificially narrows the schedule: work that could run in parallel gets queued instead, and the project takes longer than it needs to for no real reason.

When mapping dependencies, it's worth asking of each one: does B actually need A's output, or could B start with a reasonable assumption and be adjusted later if A comes back different? Real dependencies are a minority of the sequencing in most projects. Treating habit as dependency is one of the more avoidable sources of a slow schedule.

A working checklist

• Does every real dependency have a named owner on the producing side?
• Is the dependency's status visible to the downstream team without asking?
• Would an at-risk dependency be flagged weeks early, or only on its due date?
• Has each dependency been checked for whether it's real, or just habitual sequencing?
• When a dependency does slip, is there a clear next step, or does it just sit?

Making the status ambient instead of asked-for

The consistent theme across teams that handle dependencies well is that status is ambient rather than requested. Nobody has to send a message asking "any update on the API work?" because the answer is already visible wherever the dependent task lives. Teams that handle it badly are the ones where that question gets asked in a channel, answered three hours later, and forgotten again by the following week.

On a ShipSprint board, a dependency is a link between two cards rather than a note in a separate document, so a change in the upstream card's column, or even just a comment marking it blocked, shows up directly on the task that depends on it. Nobody has to go looking for it. Combined with delivery forecasts that recalculate from measured velocity as sprints complete, a dependency trending toward a miss shows up as risk on the downstream date weeks before the actual due date arrives.