Free during our launch: every feature, every plan, until 31 March 2027.

See the offer

Scheduling

Task dependencies explained: FS, SS, FF and SF, with lags and leads

A task dependency is a rule that ties the start or finish of one task to the start or finish of another, and there are four types: finish-to-start (FS), start-to-start (SS), finish-to-finish (FF) and start-to-finish (SF). A lag adds waiting time to a dependency and a lead (a negative lag) lets the second task overlap the first.

Updated · 5 min read

What a task dependency is

A dependency (also called a link, a relationship or logic) says that one task cannot start or finish until another task has started or finished. The first task is the predecessor; the one that waits is the successor.

Dependencies are what turn a list of tasks into a schedule. Without them, every task floats freely and a delay in one has no visible effect on the others. With them, a scheduling tool can move dates automatically when something slips, find the critical path and tell you how much float each task has. If you want the full calculation behind that, the critical path method guide walks through it.

Most dependencies come from one of three places: the physical order of work (you cannot paint a wall before it is built), a resource that can only do one thing at a time, or a decision or approval that must happen first.

The four dependency types

TypeRuleEveryday example
Finish-to-start (FS)B cannot start until A finishesSign the contract, then start the work
Start-to-start (SS)B cannot start until A startsOnce writing starts, layout design can start
Finish-to-finish (FF)B cannot finish until A finishesProofreading cannot finish until writing finishes
Start-to-finish (SF)B cannot finish until A startsThe old system's support cannot end until the new system goes live

FS is the default and should carry most of your logic. It is easy to read and hard to misuse.

SS models work that runs in parallel once the first task has got going. It almost always needs a lag, otherwise you are saying both tasks can start on the same day.

FF models work that can run alongside its predecessor but must wrap up after it, such as testing that cannot finish before the last feature is built.

SF is rare. It suits handovers where the outgoing activity must keep going until the incoming one starts, such as a night shift that cannot end before the day shift begins. If you find many SF links in a schedule, something has usually been modelled backwards.

Lags and leads

A lag is a delay added to a dependency. "FS + 2 days" means the successor starts two days after the predecessor finishes. Use a lag for waiting time that needs no work and no resources, such as paint drying, a supplier's fixed queue or a mandatory notice period.

A lead is a negative lag. "FS - 2 days" means the successor starts two days before the predecessor finishes, so the two overlap. Leads are a common way to fast-track a schedule.

Three practical rules:

  • If the waiting time involves real work (a review, an approval, a test), make it a task with an owner, not a lag. Lags are invisible on most reports and nobody is responsible for them.
  • Check which calendar the lag uses. Two working days and two calendar days can be very different over a weekend or a holiday.
  • Prefer an SS link with a positive lag to an FS link with a lead. "Start design 3 days after writing starts" survives a change in the writing duration; "start design 7 days before writing ends" does not.

Worked example: producing a printed guide

Day numbers below count from day 0 at the start of the project, and a task that starts on day 3 and lasts 8 days finishes on day 11.

TaskDurationDependencyStartFinish
A. Write content10None010
B. Design layout8SS + 3 on A311
C. Proofread4FF + 2 on A812
D. Print5FS + 2 on C; FS on B1419
E. Distribute3FS - 2 on D1720
  • B starts 3 days after A starts: 0 + 3 = day 3. It lasts 8 days, so it finishes on day 11.
  • C must finish at least 2 days after A finishes: 10 + 2 = day 12. Working back 4 days, it starts on day 8.
  • D has two predecessors. C finishes on day 12 plus a 2-day printer queue gives day 14. B finishes on day 11. The later date wins, so D starts on day 14 and finishes on day 19.
  • E uses a 2-day lead: the first boxes ship while the last ones are printing. It starts on 19 - 2 = day 17 and finishes on day 20.

The project takes 20 days. With plain FS links and no overlaps, the same tasks would take 10 + 8 + 4 + 2 + 5 + 3 = 32 days. That difference is why the link type matters. It is also why overlaps carry risk: if the layout changes after proofreading has started, part of the proofreading is redone.

An SF example, separately: if the new booking system goes live on day 20, an SF link from "New system live" to "Support old system" means the old support task cannot finish before day 20, however the go-live date moves.

  1. Start with FS everywhere. Ask for each task: what must be finished before this can start?
  2. Replace FS with SS or FF only where work truly overlaps, and add a lag that reflects how much of the predecessor must be done first.
  3. Give every task a predecessor and a successor, except the project start and finish milestones. Open ends make float meaningless.
  4. Use logic, not dates. If you type a start date instead of linking a task, the schedule stops reacting to change. Keep fixed dates for real external commitments.
  5. Review links with the people doing the work. They know which overlaps are realistic and which ones only look good on paper.

Common mistakes

  • Lags used to hide work. A 10-day lag for "client review" means nobody tracks the review.
  • Too many leads. Every overlap adds rework risk, and schedule reviewers often treat any lead as a warning sign.
  • SS without a lag. It usually means the planner forgot to set one.
  • Redundant links. If A links to B and B links to C, an extra A to C link adds clutter and can hide which path really drives C.
  • Linking summary tasks. Link the detailed tasks instead, so the logic stays visible and the critical path stays correct.

How to do this in Critova

Critova supports all four link types (FS, SS, FF and SF) with positive or negative lags. In the activity grid you pick each predecessor by name and set the type and lag in the same row; the Gantt chart redraws the links and the scheduler recalculates dates, float and the critical path straight away. Lags follow the working calendar you assign, including holidays. Projects at the timeline level also support dependencies and milestones without the full controls setup. See the details on the scheduling feature page, or start a free project and link your first tasks.

Common questions

Which dependency type is most common?

Finish-to-start. It should carry most of the logic in a schedule; DCMA-style checks commonly look for at least 90% of links to be FS.

What is the difference between a lag and a lead?

A lag delays the successor (positive value). A lead lets the successor start early so it overlaps the predecessor (negative value). Both are set on the link, not on the task.

Can a task have more than one predecessor?

Yes. The task then waits for whichever predecessor gives the latest date, as task D does in the example above.

Bring one schedule. See your critical path in an hour.

Free during our launch until 31 March 2027.