Definition: A dependency is a relationship between two tasks where one cannot start or finish until the other does. Dependencies set the order your project runs in, and they are what turn a flat to-do list into a real schedule with a critical path.
You already track dependencies in your head. "We can't paint until the drywall is up." "Outreach starts the day the landing page goes live." Writing those rules down is the whole job. Once they live somewhere everyone can see, the schedule stops being a guess and starts being a plan you can defend.
TL;DR: A task dependency is a rule that one task waits on another. There are 4 types (Finish-to-Start, Start-to-Start, Finish-to-Finish, Start-to-Finish), with Finish-to-Start the most common. Map them in a Gantt view so a slip in one task shows its ripple before it becomes a delay. Map yours free →
What Is a Task Dependency?
A task dependency is a link that forces one task to wait on another. The task that must happen first is the predecessor; the task that waits is the successor. Dependencies are the difference between a list of work and a schedule, because they answer the one question a list can't: in what order does this have to happen?
The simplest case is a chain. Task A blocks Task B, which blocks Task C. Move A's finish date and everything downstream slides with it. That ripple is exactly what you want to see early, while it is still a calendar problem and not a missed deadline.
The 4 Types of Task Dependencies
There are four dependency types, defined by which ends of the two tasks are linked. Finish-to-Start covers the large majority of real schedules. The other three handle work that overlaps, finishes together, or runs in an unusual order. Recognizing the right type keeps your timeline honest and your critical path accurate.
| Type | Rule | Plain-English example |
|---|---|---|
| Finish-to-Start (FS) | Predecessor must finish before successor starts | Drywall must be up before painting begins |
| Start-to-Start (SS) | Successor can't start until predecessor starts | Pouring concrete and leveling it start together |
| Finish-to-Finish (FF) | Successor can't finish until predecessor finishes | Writing and editing wrap on the same day |
| Start-to-Finish (SF) | Successor can't finish until predecessor starts | New shift can't end until the next shift clocks in |
The two attributes you add on top of the type are lead and lag. A lag delays the successor (start outreach 3 days after launch). A lead overlaps them (start editing when drafting is 80% done). Together, type plus lead/lag describes almost every scheduling rule a real project needs.
FS ──[ A ]──┐
└──[ B ]── B starts after A finishes
SS ──[ A ]──
──[ B ]── B starts with A
FF ──[ A ]────┐
──[ B ]────┘ B finishes with A
Why Dependencies Drive Your Whole Timeline
Dependencies decide the project's earliest possible finish date. Lay every link end to end and the longest unbroken chain becomes the critical path, the sequence where any slip pushes the whole launch. A task with slack can run late and hurt nothing. A task on the critical path has zero slack, so it is where your attention belongs.
This is also why a flat task list lies to you. It can show 40 tasks and 40 due dates, but it can't show that finishing task 12 a day late steals a day from the launch. Only the dependency links surface that. Map them once and the schedule starts telling you the truth about risk.
Related Terms and Concepts
Gantt Chart: The bar chart where dependency links and the critical path become visible at a glance.
Project Timeline: The schedule that outlines when tasks, including dependencies, are completed so the project progresses smoothly.
Milestone: Key checkpoints that often depend on a set of tasks finishing before they count as achieved.
Resource Allocation: Assigning people and tools in a way that respects the dependencies among tasks, so nobody waits on a handoff that hasn't happened.
Project Charter: A document that may flag major dependencies affecting the project's scope, timeline, and resources.
MoSCoW Method: A prioritization technique that helps manage dependencies by separating must-haves from could-haves during planning.
Frequently Asked Questions About Dependencies
Why Are Dependencies Important in Project Management?
Dependencies dictate the order in which tasks run, so they directly shape the schedule, resource allocation, and the earliest possible finish date. Without them you have a list of due dates that can't show how a slip in one task ripples into a missed launch.
What Is the Most Common Type of Dependency?
Finish-to-Start (FS) is by far the most common. The predecessor must finish before the successor can start, like drywall going up before painting begins. Most real schedules are mostly FS links, with the other three types reserved for work that overlaps or finishes together.
What Is the Difference Between Lead and Lag?
Lag adds a wait between linked tasks, so a successor starts a set time after its predecessor (start outreach 3 days after launch). Lead does the opposite and overlaps them, so a successor starts before its predecessor fully finishes. Both let you model real timing without inventing fake tasks.
How Do Dependencies Affect the Critical Path?
The critical path is the longest unbroken chain of dependent tasks, and it sets your project's finish date. Any task on it has zero slack, so a one-day slip there delays the whole project. Mapping dependencies is what reveals which chain is critical in the first place.
How Can Dependencies Affect Project Risk?
Unmapped dependencies are where delays hide. When the order of work lives only in someone's head, a late handoff becomes a surprise instead of a forecast. Writing dependencies down turns hidden risk into a visible ripple you can plan around before it costs you a deadline.
Can Dependencies Exist Between Projects?
Yes. Dependencies often cross project boundaries when teams share resources, have interconnected deliverables, or when one project's output is required for another to start. These are called interproject dependencies. In Taskade you can model them as connected projects so a handoff between two plans stays in sync.
Do It in Taskade: An Ops Dashboard That Shows the Ripple
You already know the order your work has to happen in. The move is to put it where the whole team sees it and the schedule keeps itself honest. Describe your plan in plain English to Taskade Genesis and it builds an ops dashboard with your tasks, owners, and due dates, then a Gantt view draws every dependency as a link between bars.
Drag one task and everything downstream slides with it, so a slip surfaces as a visible ripple instead of a missed deadline. Owners see only what they're blocking, status rolls up on its own, and a reliable automation can nudge the next person the moment a predecessor is marked done. One prompt, one living schedule that updates itself.