Task dependencies explained: the four types

A dependency is a rule that says one task can't proceed until another reaches a certain point. "You can't paint the wall until the plaster is dry" is a dependency. So is "the press release goes out the moment the product is live." Dependencies are what turn a flat list of tasks into an actual schedule — they decide the order, and they decide which delays ripple outward and which don't.

In a Gantt chart, dependencies are the arrows linking one bar to another. Most people only ever use one kind of arrow, and most of the time that's correct. But there are four types, and knowing the other three will save you from forcing an awkward plan into the wrong shape.

The four dependency types

Every dependency links an edge of one task (its start or its finish) to an edge of another. That gives four combinations. The names read "edge-of-predecessor-to-edge-of-successor":

Type	Means	Plain example
Finish‑to‑Start (FS)	B can't start until A finishes.	Plaster must dry before you paint.
Start‑to‑Start (SS)	B can't start until A starts.	Editing can begin once writing begins — not before.
Finish‑to‑Finish (FF)	B can't finish until A finishes.	Testing can't wrap up until development wraps up.
Start‑to‑Finish (SF)	B can't finish until A starts.	The old on-call shift ends only once the new one begins.

Finish-to-Start (FS) — the default

This is the one almost everyone means by "dependency". The first task has to be done before the second can begin. Build the foundation, then frame the house. Get sign-off, then send to print. It's the most common link by a wide margin, and when in doubt it's usually the right one. If your tool lets you draw a dependency without choosing a type, it's almost certainly creating an FS link.

Start-to-Start (SS) — work that runs together

Two tasks that move in parallel, but one can't get ahead of the other's start. A classic case: an editor can start reviewing chapters as soon as the author starts writing them, but not before there's anything to read. SS links are how you model overlapping work without pretending it's fully simultaneous. Pair it with a small lag — "editing starts three days after writing starts" — and you've described a realistic pipeline.

Finish-to-Finish (FF) — landing together

Two tasks that need to end at the same time, or where one can't close until the other does. Quality testing can't be declared complete until the feature it tests is complete. Documentation can't be finalised until the thing it documents is finalised. The tasks may have started at different times and run at different speeds, but FF ties their finish lines together.

Start-to-Finish (SF) — the rare handoff

The odd one out, and the one you'll use least. Task B can't finish until task A starts. The textbook example is a shift handover: the outgoing shift can only end once the incoming shift has begun, so you never leave the post uncovered. If you find yourself reaching for SF, double-check you don't actually mean FS with the tasks swapped — that's the usual confusion.

Lead and lag time

A dependency doesn't have to mean "immediately after". You can add lag (a delay) or lead (an overlap) to any link:

• Lag is waiting time built into the link. "Paint, then wait two days for it to cure before hanging cabinets" is an FS dependency with two days of lag. The second task doesn't start the instant the first ends — it starts later.
• Lead (sometimes "negative lag") lets the second task start before the first fully finishes. "Begin writing the user guide when development is 80% done" is a lead — a deliberate, controlled overlap to save calendar time.

Lag and lead are how a schedule reflects reality instead of an idealised assembly line. Use them deliberately, and write down why the lag exists, so the next person doesn't "tidy it up" and break the plan.

The mistakes that wreck a schedule

• Over-linking. Not every task that happens after another depends on it. If two tasks could in principle run in any order, don't chain them — a false dependency makes your plan look more rigid and more fragile than it is.
• Dates pretending to be dependencies. "This starts on the 14th because that's when the contractor is free" is a resource constraint, not a dependency. Pinning a date where you should have drawn a link hides the real reason and breaks silently when things move.
• Circular dependencies. If A waits on B and B waits on A, neither can ever start. Good tools refuse to create the loop; if yours doesn't, a task that "can't be scheduled" is the symptom to look for.
• Linking to summary rows. Depending on a whole phase rather than the specific task inside it that you actually need is a common way to get a schedule that's technically correct and practically useless.

How to pick the right type

A quick decision path that covers the vast majority of cases:

1. Does B genuinely need A's output before it can begin? → Finish-to-Start.
2. Can B run alongside A, but only once A is underway? → Start-to-Start, usually with a lag.
3. Can B run independently but must close when A closes? → Finish-to-Finish.
4. Is this a continuous-coverage handover? → Start-to-Finish. Otherwise you probably want FS.

Why this matters: the critical path

Dependencies aren't just bookkeeping. Chained together, they form paths through your project, and the longest of those paths — the one with no slack — is the critical path. It sets your earliest possible finish date. Get the dependency types right and the critical path tells you the truth about what's drivable and what isn't. Get them wrong — over-link, or mislabel a date as a dependency — and the schedule will lie to you about where the real pressure is.

Frequently asked questions

Which dependency type should I use if I am not sure?

Use Finish-to-Start. It is the most common link and the right one for the large majority of real dependencies — one task produces something the next task needs.

What is the difference between lag and a delay?

They are the same idea. Lag is delay built into a dependency — the successor starts (or finishes) a set amount of time after the link condition is met, rather than immediately.

Can a task have more than one dependency?

Yes, and most do. A task often waits on several predecessors; it can only start once every one of its incoming conditions is satisfied. The latest of them is what actually controls its start date.

Are dependencies the same as a task order?

Not quite. Order is just the sequence things happen in; a dependency is an enforced rule about that order. You can do tasks in an order without any dependency between them — dependencies are the orderings that are mandatory.