Project dependencies: what FS, SS, FF and SF actually mean
A dependency connects task starts or finishes. Four timelines show how the link changes the earliest allowed dates, and why overlapping bars don't prove the work can overlap.
The project needs an earlier finish. Someone drags testing to the left so it overlaps development. The chart looks better. The team still needs to explain which tests can run before the software is ready.
A project dependency is a rule connecting the start or finish of one activity to the start or finish of another. The four basic types are finish-to-start (FS), start-to-start (SS), finish-to-finish (FF) and start-to-finish (SF).
The letters identify the endpoints. In FS, the first activity's finish controls when the second may start. The rule describes a condition the work must meet. It doesn't make the condition true just because a scheduling tool accepts the link.
The four dependency types, side by side
Call the controlling activity A and the dependent activity B. In scheduling language, A is the predecessor and B is the successor.
| Type | Rule with no added lag | Example |
|---|---|---|
| Finish-to-start, FS | B cannot start until A finishes | Acceptance testing waits for a completed, usable software release |
| Start-to-start, SS | B cannot start until A starts | Initial observations begin after a pilot starts |
| Finish-to-finish, FF | B cannot finish until A finishes | A final pilot report cannot be completed before the pilot ends |
| Start-to-finish, SF | B cannot finish until A starts | Outgoing service cover must continue until incoming cover starts |
PMI's scheduling standard describes these four relationships. The examples here are illustrative; a real plan may need several links to express the full requirement.
SS permits B to start after A has started. It doesn't require them to start together. FF similarly permits B to finish later than A. Microsoft's task-link documentation makes this distinction explicit.
Move the endpoints and see the dates
Use four separate fictional activity pairs. In each one, A starts at day 4 and lasts six days, finishing at day 10. B lasts three days and cannot start before day 0.
The timelines place B at the earliest dates allowed by that pair's single link. There are no weekends, resource restrictions or other dependencies in this teaching example.
Four endpoint rules
Same durations, different links
Four separate pairs. Graphite A runs from day 4 to 10. Rust B lasts three days. The lines join the endpoints named by each rule.
Scroll the timeline sideways for the full day scale. All four relationships remain visible.
B start ≥ A finish + lag
A completes the usable release; B starts acceptance testing after that completion.
With 0 days of lag, B runs from day 10 to day 13 at its earliest allowed position.
| Link | Minimum controlled endpoint | B start | B finish |
|---|---|---|---|
| FS | Start ≥ day 10 | 10 | 13 |
| SS | Start ≥ day 4 | 4 | 7 |
| FF | Finish ≥ day 10 | 7 | 10 |
| SF | Finish ≥ day 4 | 1 | 4 |
How the earliest dates are calculated
For a start-controlled B, earliest start is the linked A endpoint plus lag. For a finish-controlled B, subtract B’s three-day duration from that minimum finish. B cannot start before day 0. Its finish is its start plus three days.
Lag is a minimum interval at the named endpoints. The slider compares arithmetic rules; it does not establish a reason to add waiting time to a real project.
With no lag, FS places B at days 10 to 13. SS allows days 4 to 7. FF allows days 7 to 10, so B can begin while A is still running, but cannot finish before A does.
SF puts B at days 1 to 4. That can look backwards if you read “predecessor” as “the thing that happens first”. Here, A's start controls B's finish. Incoming cover starts on day 4, allowing outgoing cover to end then. Those labels express the controlling relationship, not the chronological order of both starts.
A link is a minimum condition
The FF example allows the report work to occupy days 7 to 10. It also allows days 9 to 12. Both finish after A ends at day 10.
If the report needs a day of analysis after the pilot ends, FF alone doesn't describe enough of the work. Add the analysis activity and its real dependency. Don't rely on a conveniently placed bar to preserve that requirement when the pilot moves.
The same applies to SS. A pilot starting may permit initial observation. It doesn't make enough evidence available for every analysis task on day one.
What lag changes
Lag adds a minimum waiting interval between the linked endpoints. Select two days in the figure. FS now allows B to start at day 12, two days after A finishes. B ends at day 15.
For FF with the same lag, B cannot finish before day 12. Its earliest start is day 9. The waiting interval is measured from finish to finish, rather than from A's finish to B's start.
These are arithmetic comparisons. A real lag needs a reason. A necessary curing or settling period may be waiting time. A review someone must perform is work with an owner and duration, so show it as an activity. PMI's 2011 scheduling standard makes that recommendation.
A late delivery is an actual delay; it isn't automatically a planned lag. Record the changed forecast or actual event, then let the dependencies show its effect.
Return to the testing plan
Our software team may genuinely be able to test completed components while development continues elsewhere. It needs to name those components and their readiness checks.
Break the delivery into usable pieces, then link each test to the piece it needs. The work breakdown structure article helps define those deliverables before the schedule gets detailed.
If final acceptance needs the integrated release, keep that requirement visible even while component tests overlap. An SS link from “development started” to “testing started” cannot express the whole acceptance condition.
Resources need checking too. Two activities may be logically allowed to overlap while competing for the same engineer or test environment. Their earliest dates don't reserve either resource.
Use the links to assess a change
Once the dependencies describe the work, the critical path method can show which sequence governs the planned finish. Its worked example uses FS links; the four endpoint types here explain how other relationships differ.
When a supplier date or deliverable changes, update the relevant activity and review the effects through its links. The scope change example explains when that review also needs a decision about the project's commitment.
For the next schedule review, choose one overlap and ask the receiving team what must be ready before its work can start, and what must be true before it can finish. Put those conditions into the plan. The dates become much easier to defend when the dependency describes a handoff people recognise.
Sources and example notes
- PMI: Practice Standard for Scheduling, second edition, 2011, section 3.2.3 and Figure 3-1, printed pages 28–30. Relationship types and guidance on lag versus work activities.
- Microsoft Support: Link tasks in a project, “Types of tasks”. Endpoint rules and the distinction between a minimum condition and equal start or finish dates.
All activities and durations are fictional. The calculator isolates one relationship per pair. A full project also needs calendars, other dependencies, resource availability and completion requirements; the diagrams do not calculate a project finish or staffing plan.