The 4 Types of Task Dependencies Explained

Open almost any project schedule and you will find hundreds of tasks connected by arrows, and nearly all of those arrows are the same type — finish-to-start. That is correct behavior, but it hides a problem: teams that only know one dependency type end up forcing every relationship into it, and the schedule quietly becomes wrong in ways that are hard to see.

The four dependency types exist because real work connects in four different ways. Sometimes a task cannot start until another finishes, but sometimes two tasks must finish together, or start together, or hand off in the middle. Understanding the four types — and when each one is genuinely appropriate — is what separates a schedule that models reality from a schedule that merely looks plausible.

This guide explains all four types with concrete examples, shows when each is the right choice, covers leads and lags, and lays out the trade-offs you accept when you pick one type over another.

Quick Answer: What Are the 4 Types of Task Dependencies?

The four types of task dependencies are finish-to-start (FS), finish-to-finish (FF), start-to-start (SS), and start-to-finish (SF). In each abbreviation the first word describes the predecessor’s timing that triggers the successor: FS means “the predecessor must finish before the successor can start,” FF means “the predecessor must finish before the successor can finish,” SS means “the predecessor must start before the successor can start,” and SF means “the predecessor must start before the successor can finish.”

Finish-to-start is the dominant type — it covers the vast majority of real relationships, which is why the scheduling standard recommends using it whenever possible. The other three are situational: use them only when the work genuinely overlaps or must end together, and understand exactly how your software applies them before you do.

What Is a Finish-to-Start (FS) Dependency?

A finish-to-start dependency means the predecessor activity must finish before the successor activity can start. In the shorthand *A FS B*, activity A is the predecessor and B is the successor: B cannot begin until A has completed.

This is the natural dependency of almost every process. You cannot pour concrete until the foundations are excavated. You cannot test software until it is built. You cannot edit a text until it is written. In each case the order is forced by the logic of the work itself, which is exactly why the Practice Standard for Scheduling recommends finish-to-start as the default relationship and asks teams to treat the other types as exceptions that must be justified.

Finish-to-start is also the easiest type to explain to stakeholders, which is a real management advantage. When a reviewer asks “why can’t we start the design review today?” the answer “because the requirements draft has not finished” is instantly understood. And in software, FS links behave predictably: delay the predecessor and the successor moves; finish early and the successor can move up.

Use FS whenever the true relationship is “this must be complete first.” The only reason to reach for another type is when the real-world relationship genuinely overlaps the start or the finish of the two tasks — which the next three types describe.

What Is a Finish-to-Finish (FF) Dependency?

A finish-to-finish dependency means the predecessor must finish before the successor can finish. In *A FF B*, activity B cannot be marked complete until activity A is complete — even if B started long ago.

The classic example is a book: the last chapter must be written before the whole book can be considered finished. Both writing streams may have run in parallel for weeks, but the finish of the entire deliverable is gated by the finish of that one piece. Another everyday example: you cannot close the project’s financial accounts until the final invoice is issued, even though bookkeeping ran throughout.

Why would you model FF instead of just saying “B waits for A”? Because FF lets the two tasks run in parallel while still enforcing a shared completion point. If you used FS instead, you would be forced to serialize the work — B could not start until A finished — which would add unnecessary time to the schedule. FF captures “finish together” without the cost of “start after.”

The trade-off is coordination. Parallel tasks with a shared finish need regular checking, because one late completion drags the other past the promised date. If you model FF, make sure both tasks carry the same end-date pressure in reporting, or the dependency will be discovered only when the first task’s team realizes it is waiting on someone else’s finish.

What Is a Start-to-Start (SS) Dependency?

A start-to-start dependency means the predecessor must start before the successor can start. In *A SS B*, activity B cannot begin until activity A has begun.

This is the dependency for overlapping work. Two teams can run in parallel once the triggering activity has produced just enough to work from. A common case: “project work has started” is the SS predecessor for “project-management activities have started,” or in software, the copywriter can start drafting as soon as the wireframe structure is approved, without waiting for the finished visuals.

The value of SS is compressed duration. A finish-to-start link forces the successor to wait for the full predecessor; a start-to-start link lets work overlap, often saving days or weeks. That overlap is the difference between a 20-day project and a 14-day project when two streams genuinely can run side by side.

The trade-off is rework risk. Parallel work means decisions made after the overlap point can invalidate work already done. If the wireframe changes on day three, the copy drafted against the old structure needs rework. So SS is the right choice when the early output of the predecessor is stable enough to build on — and a poor choice when the predecessor’s direction is still volatile. Ask one question before using SS: “if the predecessor changes direction after we start, how expensive is the rework?”

What Is a Start-to-Finish (SF) Dependency?

A start-to-finish dependency means the predecessor must start before the successor can finish. In *A SF B*, activity B cannot finish until activity A has started. It is the least intuitive of the four, which is why it is rarely used and generally should be avoided.

The standard example is a shift change: the new shift must start before the previous shift can finish. Activity A (new shift starts) is the trigger that allows activity B (previous shift finishes) to complete. Another instance: a security guard cannot leave their post until the replacement has arrived.

Why is SF so rare? Because it reads backwards compared to the way we naturally think. Almost every project relationship is “this must be done before that can proceed,” and SF inverts that logic into “this must begin before that can end.” In practice, teams almost always find that a different dependency type — or no dependency at all — expresses the real intent more clearly.

There is one documented corner where SF has been suggested: just-in-time scheduling, where a successor task is scheduled to finish exactly when its predecessor starts. But even this fails in practice when resource leveling is involved, because leveling can delay the successor so that it finishes after the predecessor has started — silently violating the intended just-in-time handoff. The guidance is simple: if you are tempted to use SF, challenge the design of the schedule first, and use it only with a very clear, documented operational reason.

The 4 Types at a Glance: Comparison Table

The table below compresses all four types into the information you need when modeling a schedule.

How Do Leads and Lags Modify the Four Types?

Leads and lags are adjustment values you can attach to any of the four dependency types. A lag adds waiting time between the two tasks; a lead subtracts it, letting the successor begin or finish earlier than the strict relationship would allow.

PMBOK defines a lag as the amount of time by which a successor activity is delayed relative to its predecessor, and a lead as the amount of time by which a successor can be advanced. Both can be applied to all four types.

Practical examples bring this to life. For a finish-to-start link, a two-week lead means the successor starts two weeks before the predecessor finishes — the landscaping on a building project can begin while the punch list is still open. For a start-to-start link, a two-day lag means the second task starts two days after the first starts — useful when the second team needs to learn from the first team’s early mistakes.

The discipline that applies to dependency types applies doubly to leads and lags: every one needs a documented reason. A lag representing concrete curing time is a real constraint. A lag added to “space things out” is assumption dressed as data, and it will quietly stretch every forecast. Log the reason or remove the adjustment.

How Do the Four Types Shape the Critical Path and Float?

Your choice of dependency type is not cosmetic — it changes which tasks land on the critical path and how much float the others carry. The critical path is the longest chain of dependent activities, and only the dependencies you model participate in that calculation.

Suppose you have three tasks that could logically be serialized or overlapped. Serialized as finish-to-start (FS-FS), they take 5 + 10 + 4 = 19 days, and all three sit on the critical path. If the middle task can overlap the first using a start-to-start relationship, the chain shortens, and the duration of the project changes. That one modeling decision moves the finish date by several days without any change in the real work.

The same logic applies to float. A task linked only by finish-to-start has float equal to the slack between its finish and the next constraint; a task linked with finish-to-finish absorbs its float from a shared endpoint; a start-to-start task gets float from the delay allowed between two starts. Teams that misapply the type — typically overusing FS when the work actually overlaps — end up with overly long schedules; teams that under-model types end up with optimistic schedules that collapse the moment parallel work turns out to be sequential in reality.

This is also why the four types matter so much to software selection. A tool that only supports finish-to-start links (many work-management apps) cannot express a genuine start-to-start overlap, so you will be forced either to fake the overlap with dates or to serialize work you could run in parallel. Know which types your project genuinely needs before you pick the tool.

Which Tools Handle All Four Dependency Types?

Dependency-type support is a reliable way to sort scheduling tools into “real schedulers” and “work managers.” Here is an honest comparison of the tools teams most often consider.

Microsoft Project and Oracle Primavera P6 are the tools where all four types behave exactly as the standards define them, with leads, lags, calendars, and resource constraints included. That precision is why construction, engineering, and heavy PMO environments use them — and their cost and complexity are exactly why lighter teams should not.

Smartsheet is the middle path: it implements the full predecessor logic inside a spreadsheet-like grid, which suits teams that already manage data in sheets. The trade-off is that dependency logic hidden inside cells is easy to corrupt and harder to audit than a visual network.

ClickUp bundles dependency types, Gantt views, and task management into one affordable product. It works well for small teams that want everything in one place, with the caveat that its scheduling precision is thinner than the dedicated engines.

Asana and similar work managers are superb for running collaborative work but typically model only finish-to-start relationships. If your project genuinely needs start-to-start overlaps or finish-to-finish gates, these tools will force you to approximate — and approximations are where schedules go wrong.

Three Scenarios: Choosing the Right Dependency Type

Scenario 1 — Serialize what is truly sequential. A compliance team is building a new onboarding flow. The sequence is: write policy (3 days) → legal review (5 days) → publish (1 day). All three are finish-to-start, and the project is 9 days. Could legal review start while the policy is still being written? No — reviewing a partial draft wastes the lawyers’ time and risks reviewing discarded text. FS is correct, and any attempt to “overlap” it with a lead would be fake compression. The team reports a realistic 9 days and protects the legal-review buffer instead of pretending to be faster.

Scenario 2 — Overlap with start-to-start to beat the deadline. A product team has a 30-day deadline: UI design takes 15 days and copywriting takes 10 days. Serialized with FS, the copy stream adds 10 days after design, pushing the finish past the deadline. But the copywriter can begin as soon as the wireframes are approved — roughly after 3 days of design. Modeling this as a start-to-start relationship with the wireframe approval as the trigger lets copy run in parallel, and the project finishes inside 25 days. The trade-off is 5 days of rework exposure if the visual design changes the copy’s core message after day 3.

Scenario 3 — Finish-to-finish to hold a shared release. A mobile team’s final release must wait for both the Android and iOS builds to pass certification. The two build tracks run independently with different durations (iOS 8 days, Android 11 days), so neither can be the FS predecessor of the other in a natural sequence. Modeling the release as finish-to-finish on both tracks — release cannot finish until each build finishes — produces the correct shared gate. The team sees that Android is the binding constraint and watches its certification status weekly instead of being surprised at release day.

Common Mistakes With the 4 Dependency Types

• Using finish-to-start for everything. It is the safe default, but forcing overlapping work into FS inflates your schedule by days — the exact opposite of the precision you want from dependency modeling.
• Using start-to-start where the predecessor’s direction is volatile. Overlap saves time only if the early output is stable; otherwise you pay for the overlap twice in rework.
• Using finish-to-finish without monitoring both finishes. FF creates a hidden wait — one team is done but blocked by the other’s finish, and nobody flagged it.
• Using start-to-finish without questioning the design. SF is counterintuitive and fragile; before deploying it, ask whether a clearer relationship exists.
• Applying leads and lags without a documented reason. Every adjustment becomes an assumption that a delay review will expose.
• Picking a tool that cannot express your needed types. If the software only supports FS, you will silently serialize or fake your real relationships.
• Ignoring how the software implements the type. Some tools interpret SS and FF with default gaps or different directions; verify against a tiny test schedule before trusting the big one.

Know This Before You Choose

Before you decide which dependency types to use — and which tool will carry them — answer these questions.

• Which relationships in your project are truly forced (FS) versus merely overlappable (SS or FF)?
• If you overlap work with SS, how expensive would rework be if the predecessor changes direction?
• Which deliverables share a finish gate, and can your reporting show both tasks’ status together?
• Do any real handoffs depend on a start, not a finish? If so, is SF truly the clearest model, or is the schedule design the real problem?
• Does your software implement all the types you need, and have you verified the behavior on a test schedule?
• For every lead or lag you plan to use, can you write down the operational reason in one sentence?

Conclusion

The four dependency types are a small vocabulary with big consequences. Finish-to-start is your default, finish-to-finish and start-to-start are your tools for parallel work, and start-to-finish is a rare exception you should almost never need. The right type models how the work actually connects; the wrong type produces dates that look authoritative and turn out to be fiction.

Choose the type by asking what the real relationship is — must this complete, must these finish together, or must these begin together? Then verify your software applies it the way you think, and give every lead and lag a reason. That discipline is cheap, and it is what keeps your schedule honest.

To be transparent: Doitify is our product, which is why we know its capabilities from the inside. If you want dependency modeling inside a full project workspace — multi-level tasks with WBS dependencies, Gantt charts, calendars, and team collaboration in one place — Doitify’s project management workspace is designed for that workflow, and it is the scenario where we recommend it.