Finish-to-Finish (FF)

How to read it

"Proofreading cannot finish until translation finishes." Proofreading starts mid-translation and runs alongside it, but you cannot close the review while the last sentence is still untranslated. The successor's finish is bound to the predecessor's finish. Free at the start, bound at the end — the exact mirror of SS. "Release support cannot end until the last deployment ends" — any relationship where the main task's finish sets the companion's finish is FF territory.

Why it matters

Companion work — review, documentation, quality checks, operations monitoring — that trails a main task exists in every project. Link it as FS (start only after the main task fully ends) and genuinely parallel work gets stretched into a long series on the schedule. FF is the only way to state "we run together, but you finish first" precisely. If wrap-up time is needed after the predecessor ends, put lag on the FF — "review closes two days after translation ends" is FF+2d. One addendum: FF aligns finishes, not durations. The companion task's duration still needs to be estimated realistically on its own.

Common misconceptions

It is easy to forget that FF alone leaves the successor's start unconstrained: postponing the review forever and cramming it at the end violates nothing. To bind the kickoff too, add an SS alongside; the SS+FF pair constrains the order of both ends — though both are lower bounds, so with unequal durations one end can still diverge. Using FF as a stand-in for an acceptance gate is another misreading. Rather than the vague "development must finish before acceptance finishes," raise an acceptance milestone and wire predecessors into it — clearer for both reporting and management. On a Gantt chart, an FF arrow joins the right ends of the two bars.