Task dependencies explained: FS, SS, FF, SF, lag and lead in practice
How the four dependency types really behave, when to use positive or negative lag, why working days and calendar days give different dates, and the linking mistakes that quietly break a schedule.
In this article
Dependencies are what turn a list of tasks into a schedule. Change one duration and the dates that follow move with it; delay one task and you can see immediately what it pushes back. Get the links wrong, though, and the plan becomes either too long, because everything waits for everything, or too optimistic, because real constraints are missing.
This guide assumes you already know the four types at a glance (the Gantt chart guide covers the basics). Here we look at how they behave in detail, how to use lag and lead, why the calendar matters, and the mistakes that most often break a schedule without anyone noticing.
The four dependency types, beyond the basics
In the precedence diagramming method every link connects one end of a predecessor (its start or its finish) to one end of a successor. Dependency types, lag and lead are part of PMI's standard project management vocabulary[1], and every serious scheduling tool uses the same four combinations.
| Type | Rule | Typical use | Common misuse |
|---|---|---|---|
| Finish-to-start (FS) | B cannot start until A finishes | A real hand-over: a signed contract before an order | Used everywhere, even where work can overlap |
| Start-to-start (SS) | B cannot start until A starts | Parallel work that follows behind: translation after writing starts | Without lag, it lets B start on the same day as A |
| Finish-to-finish (FF) | B cannot finish until A finishes | Closing work together: testing cannot end before development ends | Confused with SS when the overlap is only at the end |
| Start-to-finish (SF) | B cannot finish until A starts | Shift hand-overs: the old system runs until the new one starts | Used to fake a backwards plan |
Two details are easy to overlook:
- A link sets a minimum, not an exact date. With FS, B can start any time after A finishes; it will start immediately only if nothing else holds it back.
- When a task has several predecessors, the most restrictive one wins. The successor waits for the latest date imposed by any of its links. This is why one missed link can make a plan look shorter than it really is.
Lag and lead: positive and negative waiting time
Lag modifies a link by adding time between the two ends it connects. The same idea works in both directions.
Positive lag
A positive lag adds a wait. FS + 3 means B starts three working days after A finishes. Use it for time that passes without anyone working on the task: a supplier's delivery time, a contractual review period, a cooling-off period before going live.
Do not use lag to hide work. If the three days are actually spent by someone checking documents, that is a task with an owner and should appear as one.
Negative lag (lead)
A negative lag, also called lead, lets the successor anticipate. FS − 2 means B can start two working days before A finishes. It is useful when the tail of one task does not affect the start of the next: the launch emails can be drafted while the final pages of the website are still being polished.
Lead is a shortcut, and it carries a risk. If A slips, B still starts at the same distance before A's new finish, but whatever B was relying on may not be ready. When the overlap is significant, a start-to-start link with lag usually describes the situation more honestly.
Working days or calendar days?
A lag can be measured on the project's working calendar or in elapsed calendar time. The difference only shows up around weekends and holidays, which is exactly when it causes surprises.
Take a task that finishes on a Friday, followed by a link with a lag of 2 days:
| Lag measured in | Days counted | Successor starts |
|---|---|---|
| Working days | Monday, Tuesday | Wednesday |
| Calendar days | Saturday, Sunday | Monday |
Same number, two working days of difference. Neither is wrong: a review period defined in business days follows the working calendar, while a wait that runs regardless of the office, such as a statutory notice period of 14 days, runs on calendar time. MS Project lets you express lag in elapsed days and also as a percentage of the predecessor's duration; other tools are stricter. Whatever the tool, know which unit you are using, and convert explicitly when a wait is defined in the other one.
When start-to-start plus lag beats finish-to-start
The most common reason a schedule is longer than it needs to be is that every link is FS. Consider a user manual: writing takes 10 working days and translation takes 8. The translator can start once the first chapters are available, and needs about two days after the last chapter is delivered to finish.
Option 1, finish-to-start. Writing runs on days 1 to 10, translation on days 11 to 18. Total: 18 working days.
Option 2, SS + 3 and FF + 2. Two links connect the same pair of tasks:
- SS + 3: translation can start three days after writing starts, so not before day 4.
- FF + 2: translation cannot finish until two days after writing finishes, so not before day 12.
With 8 days of duration, finishing on day 12 means starting on day 5, which also satisfies the SS link (day 5 is after day 4). Translation runs on days 5 to 12. Total: 12 working days, six fewer than the FS version, and a more accurate picture of how the work actually happens.
The FF link is what keeps the overlap safe. With SS + 3 alone, translation would run on days 4 to 11 and finish before the last chapter exists. Pairing SS with FF is the standard way to model work that "follows behind" another task.
A checklist for linking a schedule
- Does every task, apart from the project start, have at least one predecessor?
- Does every task, apart from the final milestone, have at least one successor?
- Is each FS link a real hand-over, or could the work overlap?
- Is every SS link paired with an FF link where the successor needs the predecessor's final output?
- Is every lag a genuine wait, not hidden work without an owner?
- Is the lag unit (working or calendar days) the one the wait is actually defined in?
- Are links placed on tasks and milestones rather than on summary tasks?
- Are date constraints limited to real external dates, with everything else driven by links?
Common dependency mistakes
Links on summary tasks
Linking a phase to another phase looks tidy, but it hides which task actually drives which. It also makes the critical path harder to read and can create conflicts with the links of the tasks inside. Link the specific tasks, and let summary tasks simply roll up their dates.
Circular dependencies
A cycle (A waits for B, B waits for C, C waits for A) has no possible solution, and a scheduler has to reject it. Cycles often appear when two people add links from different points of view; a link from a task to its own summary task has the same effect.
Constraints instead of links
Typing a date into a task, or pinning it with a "start no earlier than" constraint, freezes it. When the predecessors move, that task does not follow, and the schedule silently stops telling the truth. Keep constraints for genuine external dates such as a trade fair or a regulatory deadline.
Start-to-finish used out of habit
SF is legitimate but rare: it fits hand-overs where the old activity must continue until the new one starts. If you find yourself using SF often, the plan is probably being built backwards from dates instead of forwards from work.
Missing or redundant links
A task without a successor can slip indefinitely without affecting the finish date, so its delay never shows. At the other extreme, a link that repeats what another chain already guarantees adds clutter without changing anything.
How to do it in Planitude
Planitude supports all four types, FS, SS, FF and SF, with lead and lag in working days: a positive value adds a wait, a negative value is a lead. Dates are calculated on the project calendar, including holidays and exceptions, so a lag never ends on a closed day. When you type the name of a new task in the Gantt or List view, the AI assistant can suggest a predecessor, which you accept with Tab.
When a task slips beyond its slack, the links it pushes are shown in red, so you can see where the delay propagates. Turn on the critical path and total slack to check which links are driving the finish date. Constraints, deadlines and manually scheduled tasks are available for the cases where a link is not the right tool. If you import a plan from MS Project (.mpp, Project XML) or Primavera (.xer), review links that used percentage or elapsed lags in the original.
Try Planitude with your own plan
Try Planitude freeFrequently asked questions
What is the most common type of task dependency?
Finish-to-start: the successor starts after the predecessor finishes. It is the right choice for real hand-overs, but using it everywhere tends to make schedules longer than necessary.
What is the difference between lag and lead?
Lag is a positive delay added to a link, a waiting time between the two tasks. Lead is a negative lag: the successor can start before the predecessor finishes.
When should I use start-to-start instead of finish-to-start?
When the successor can begin once part of the predecessor is done, as with translation following writing. Add a lag to the SS link and, usually, an FF link so that the successor cannot finish before the predecessor.
Can I link summary tasks?
Many tools allow it, but it is better to link the individual tasks. Links on summary tasks hide the real logic, complicate the critical path and can conflict with the links inside the phase.
Is start-to-finish ever useful?
Rarely, but yes: for example when an existing system or shift must keep running until its replacement starts. In most plans, the same logic is clearer with an FS or SS link.
Sources
The official pages cited in this article, checked in October 2026.
Try Planitude with your own plan
Create a free account, import your .mpp file or start from a template: within minutes you will see the Gantt chart with dependencies, calendars and the critical path.