The four dependency types, and when each one is right
Finish-to-Start, Start-to-Start, Finish-to-Finish, and Start-to-Finish explained, with lead and lag time and when each link type is the honest one.
A dependency says one piece of work constrains another. Which end of each task is constrained gives you four possible link types. Most plans use one of them almost exclusively, and knowing when the others apply is the difference between a schedule that describes the work and one that fights it.
Finish-to-Start
The successor starts after the predecessor finishes. You cannot test what has not been built; you cannot migrate into an environment that does not exist yet.
This is the default, and it should be. Most sequencing is genuinely of this shape, and an FS link is the easiest for everyone to reason about. If you are unsure which type applies, it is almost always this one.
Start-to-Start
The successor starts after the predecessor starts. Used where two pieces of work run in parallel but one cannot begin until the other is under way.
Documentation starting once development starts is the standard example. So is quality assurance shadowing a build: the QA effort has no meaning before the build begins, but it certainly does not wait for it to finish.
Start-to-Start is usually paired with lag: "documentation starts five days after development starts", not the same morning.
Finish-to-Finish
The successor finishes after the predecessor finishes. The two tasks run alongside each other and the constraint is on the ending, not the beginning.
Testing and defect fixing is the clean case: fixing runs throughout testing, and cannot be declared complete until testing is. Similarly, a training programme cannot finish before the system it trains people on is finished.
Start-to-Finish
The successor finishes after the predecessor starts. This is the rare one, and most planners go entire careers without a legitimate use.
The genuine case is a handover where something must not stop until its replacement is running. The old system stays live until the new system starts; a night shift ends once the day shift begins.
If you find yourself reaching for Start-to-Finish, it is worth checking whether you have the two tasks the wrong way round, because an inverted Finish-to-Start is the usual cause.
Lead and lag time
Lag is a wait built into the link. A Finish-to-Start link with five days of lag means the successor starts five days after the predecessor finishes: concrete curing, a client review window, hardware shipping. It is time that must pass but is not work anyone is doing.
Lead is the opposite, expressed as negative lag. Minus three days means the successor can start three days before the predecessor finishes, which is how you model a sensible overlap without pretending the tasks are independent.
Record lag in the plan, not in someone's head
This is the mistake that quietly ruins float calculations. If a two-week wait for a vendor lives in a project manager's memory rather than in the link, every downstream date is wrong by two weeks and the critical path is fiction. The lag is part of the schedule, so it belongs in the schedule.
A note on how many types you actually need
Plans that use all four types are rarer than the textbooks imply, and a plan that uses them heavily is often harder to explain than one that models the same reality with Finish-to-Start links and honest lag.
The useful skill is not using every type. It is recognising the handful of places where Finish-to-Start genuinely misrepresents the work, and being deliberate there.
How this works in Depentra
Depentra links tasks Finish-to-Start with lead and lag time, and carries lag through the schedule calculation, so it affects propagated delays and float rather than only where a bar is drawn. Negative lag gives you lead time. Circular chains are rejected when you create them.