Start-to-Start (SS)

How to read it

"Sample QA can start once content migration starts." QA cannot begin before any migrated data exists, but once underway the two tasks run side by side. The predecessor's start binds the successor's start. One careful reading: SS does not say "they start together." It is a lower bound — the successor cannot start before the predecessor does, but its actual start may be later.

Why it matters

Linking parallelizable work as FS stretches the schedule into an unnecessary series. A plan that starts QA only after the whole migration finishes simply throws weeks away. SS is the honest tool of schedule compression: let overlappable work overlap, while keeping the kickoff order as recorded logic. To delay the kickoff slightly, add lag to the SS — "QA starts five days after migration starts" is SS+5d. Whether an overlap is written as SS or as a lead is decided by the anchor. SS+5d measures from the predecessor's start, FS-5d from its finish — change the predecessor's duration and the two give different results. If the real logic is "a few days after the predecessor starts," SS plus lag is right; if it is "a few days before the predecessor ends," FS with a lead is.

Common misconceptions

SS does not constrain the finish. If migration takes three months and QA takes one, SS alone is perfectly satisfied even when QA finishes two months early. To constrain the order of both kickoff and completion, wire SS and FF together — though both are lower bounds, so with different durations one end can still diverge. The opposite abuse also exists: tying everything you merely want to happen around the same time into SS chains means one slipped predecessor cascades into unrelated kickoffs. Like every other line, SS belongs only where the logic is necessary. On a Gantt chart, an SS arrow joins the left ends of the two bars, telling it apart from FS at a glance.