Start-to-Finish (SF)
Start-to-Finish (SF) means the successor cannot finish until the predecessor has started. It is the rarest of the four types, used for handovers and cutovers.
How to read it
"Temporary call-center operations end only once the new call center starts answering." The successor's finish (temporary operations) is bound to the predecessor's start (new center going live). It writes down, as logic, the demand that service never drops for a moment. If a stabilization overlap is needed after go-live, add lag to the SF to model the parallel-run period — "temporary operations end five days after the new center goes live" is SF+5d. In typical SF cases — cutovers and handovers — the successor is usually already running before the predecessor begins: the temporary call center was operating long before the new one was even built. That is a feature of the examples, though, not something SF itself mandates.
Why it is rare
It runs against the direction people think. We reason front-to-back; SF lets the back task's finish be decided by the front task's start. The places that genuinely need SF are mostly handovers and cutovers — system transitions with parallel-run periods, staffing handoffs, returning leased equipment. Several SF links in one dependency list is itself a signal to revisit the model. An SF outside a handover or cutover is, more often than not, an FS wired backwards.
Common misconceptions
SF is easily mistaken for a reversed FS; they are different relationships — FS lets the predecessor's finish set the successor's start, SF lets the predecessor's start set the successor's finish. And half the spots that seem to need SF turn into ordinary FS once the task is redefined: model "decommission the temporary call center" instead of "operate the temporary call center," and it becomes an FS after the new center's go-live. Revisit the task definition before reaching for SF.
wbsgantt supports all four types including SF, so zero-downtime cutover scenarios can be written as logic too.