
Last updated: July 20, 2026
There are four types of task dependency: Finish-to-Start, Start-to-Start, Finish-to-Finish, and Start-to-Finish. Most teams only use Finish-to-Start, which forces awkward sequencing onto work that actually runs in parallel or finishes together. Pick the type that matches the real constraint, then set it up in your PM tool so downstream dates update on their own.
Most project management tools let you link one task to another, but the four kinds of link work very differently. Finish-to-Start makes a task wait for its predecessor to finish. Start-to-Start lets two tasks kick off together. Finish-to-Finish ties their end dates together. Start-to-Finish, the rare one, ties a task's finish to another task's start. Use the wrong one and your schedule either lies about how much work can happen in parallel, or misses a real constraint entirely.
This post covers what each type of dependency means, how to pick the right one for a given task pair, and how to set dependencies up so your project management tool tracks and recalculates them for you.
The idea is older than the software. According to PMI's PMBOK Guide, sequencing activities and mapping their dependencies is one of the core processes of project schedule management, and the Critical Path Method has formalized it since the late 1950s.
A task dependency defines the sequential or parallel relationship between two project tasks: which one waits, which one leads, and how tightly their timing is linked. Those tasks come from somewhere: you get them by breaking the project down into deliverables and work items, which is what a work breakdown structure produces before you ever start wiring up dependencies. Both eventually feed into the same project plan, where the dependency map becomes one section of a larger, living document.
Think of a relay race. The baton has to reach the next runner at the right moment, not just eventually. Project tasks work the same way: the relationship between two tasks is a specific kind of handoff, and picking the wrong kind is what makes a schedule feel off even when every individual task is on time.
Setting one up is simple once you know the type: open the task, connect it to its predecessor or successor, and tell the tool which of the four relationships applies. Most tools handle this from a task detail panel, a dependency column, or by dragging a connector directly on a Timeline or Gantt view.
The part that matters more than the setup is what happens next. A tool worth using recalculates every downstream date automatically the moment a predecessor slips, and shows you the affected chain instead of leaving you to work it out by hand. That's the real difference between a dependency you drew once and a dependency you can actually manage. Quire, for instance, redraws the Timeline the moment a predecessor's date changes, so you see the new dates on every successor without recalculating anything yourself.
Read more on the 7 best practices for actually managing task dependencies day to day.
Tools differ less on how many relationship types they expose and more on what happens after you draw a link. Quire keeps dependencies to Finish-to-Start, the type that correctly covers most task pairs, and draws them as a visual dependency map so that when a predecessor slips, you can see exactly which downstream tasks are affected and re-sequence them. Heavier tools expose more relationship models but ask for more setup in return.
More relationship types are only worth the setup if your work genuinely needs them. For most teams, getting Finish-to-Start right and seeing a slip's knock-on effects at a glance beats a longer list of link types you never use.
Once your dependencies are set up correctly, they show you the critical path automatically: the chain of tasks where a slip moves your end date, versus the tasks with enough slack to absorb one without any impact. Protecting that chain is a planning problem. What happens when a critical-path dependency slips anyway is a different problem, covered in the domino effect of a single missed dependency.
Sometimes the relationship itself changes, not just the date. A task you modeled as Finish-to-Start might turn out to run in parallel once you free up a second person to work on it, which makes it Start-to-Start instead. Don't just push the date around and leave the old relationship in place. Go back into the tool, change the dependency type on the link itself, and let it recalculate from there. A dependency map that tracks the wrong relationship type is often worse than no map at all, because it tells you a task is blocked when it no longer is.
Four types cover every real dependency you'll run into: Finish-to-Start for sequential work, Start-to-Start for parallel work with a shared kickoff, Finish-to-Finish for coordinated end dates, and Start-to-Finish for the rare handoff-timing case. Getting the type right is a five-minute decision per task pair. Getting it wrong is what makes a schedule quietly lie to you for the rest of the project.
Set dependencies up in a tool that recalculates downstream dates on its own, and you stop maintaining the map by hand. Start a free Quire workspace and link your next project's first dependency in Timeline view.
Finish-to-Start, Start-to-Start, Finish-to-Finish, and Start-to-Finish. Finish-to-Start covers most task pairs; the other three handle parallel work, coordinated end dates, and rare handoff timing.
Ask what actually triggers the next task: a finish, a shared start, or a shared end date. That answer is the type. Defaulting to Finish-to-Start for everything is the most common mistake.
Connect the task to its predecessor or successor and pick the relationship type, usually from a task panel or by dragging a connector on the Timeline. The tool should then recalculate downstream dates on its own.
The schedule stops matching reality, either hiding real parallel work or missing a genuine deadline risk. Fix it by changing the relationship on the link, not just the date.
Edit the type on the link itself. A Finish-to-Start pair can become Start-to-Start the moment the two tasks start running side by side instead of one after the other.