What Is a Project Dependency

A relationship, not a thing on its own

A project dependency is a constraint between two tasks: one cannot start, or cannot finish, until something happens with the other. It's not an item on a schedule the way a task or a milestone is; you can't point to a single box and call it "the dependency." It's the line connecting two boxes, and the rule that line represents.

That distinction matters because dependencies are the part of a schedule most likely to go undocumented. A task missing from a plan is usually noticed quickly, because the work has to happen somewhere. A dependency missing from a plan is invisible until the moment it matters: a task sits finished and ready, and it turns out something else nobody flagged has to happen first.

Why dependencies are where schedules actually break

A task running a day or two long is a normal, absorbable event: most schedules carry enough slack to survive a handful of small overruns without the finish date moving at all. A missed or mis-drawn dependency doesn't behave that way. It behaves like a chain reaction: the delayed task pushes back everything waiting on it, and everything waiting on those things, and the effect compounds rather than absorbing.

This is why post-mortems on late projects so rarely land on "a task took too long" and so often land on "we didn't realise X was blocked on Y." The individual task performance was often fine. The map of what waited on what was wrong, or didn't exist.

Hard dependencies and soft ones

Not every dependency represents a real technical constraint. A hard dependency is a genuine impossibility: you cannot deploy code that hasn't been written yet. A soft dependency is a preference dressed up as a rule, along the lines of "let's finish the design review before starting the build," when in practice a competent team could start build work on the parts of the design that are already settled.

Soft dependencies aren't wrong to have; sequencing work deliberately is often sensible. The problem is treating them with the same rigidity as hard ones. A schedule that can't distinguish "literally impossible before this" from "we'd rather do it in this order" ends up with a critical path padded by choices, not constraints, and choices can be revisited when a deadline is at risk in a way that real constraints cannot.

Not the same as a milestone

A dependency and a milestone get confused because both involve one thing waiting on another, but they operate at different levels. A milestone is a single point on the timeline marking that something significant has been reached; it has no direction, no "before" or "after" task attached to it directly. A dependency is specifically the directional link between two tasks: task A blocks task B. A milestone can sit downstream of several converging dependencies, acting as a checkpoint that confirms they've all resolved, but the milestone itself isn't a dependency. It's what you get when a cluster of dependencies has been satisfied.

Finding the dependencies that actually matter

Not every dependency deserves equal attention. A dependency on the critical path, where a delay in the upstream task moves the project's finish date directly, needs active monitoring. A dependency off the critical path, where the downstream task has slack to absorb a delay, can usually be tracked more loosely.

• Is this dependency drawn explicitly, or just assumed because the tasks appear in order on a list?
• Which of the four types is it? Is finish-to-start being used by default when the real constraint is looser?
• Does the upstream task's owner know downstream work is waiting on them specifically?
• Is this dependency on the critical path, where a delay moves the finish date directly?

Cross-team dependencies are the dangerous ones

A dependency between two tasks on the same team is usually visible, because both tasks live on the same board and the same person or a close colleague notices when something's stuck. A dependency between two different teams is where things go quiet. The upstream team doesn't know anyone is waiting, and the downstream team doesn't know who to ask.

This is the specific gap ShipSprint's triage inbox is built for: new requests land there instead of someone's messages, so a downstream team blocked on another team's work has a visible, trackable way to raise it instead of a Slack message that gets lost in a busy channel. And because work is planned against real per-column capacity rather than headcount on paper, an upstream task that's genuinely at risk of running long is visible before it silently becomes someone else's blocker. See how the triage inbox works.