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.
Why Task Dependencies Matter in 2026
Work now crosses teams, tools, and time zones, and the order of handoffs is where schedules break. A design that waits on a legal answer, a launch that waits on a vendor: none of it shows on a flat list. Dependencies make the waiting visible, so you can plan around it instead of discovering it.
They also feed the schedule math. The critical path method starts from a dependency network, so a missing link produces a wrong finish date and a wrong list of critical tasks. Build the dependencies once, from your work breakdown structure, and both the Gantt chart and the critical path follow.
Why Is a Dependency There? Four Causes
The four types above describe the link. A second classification describes why it exists. PMBOK-style guides commonly name four causes, and knowing the cause tells you how flexible the link is.
| Cause | Meaning | Can you change it? |
|---|---|---|
| Mandatory | Forced by physics or contract (walls before paint) | No |
| Discretionary | Chosen by team preference or best practice | Yes, at a risk |
| External | Depends on a party outside the project (vendor, regulator) | Only by negotiation |
| Internal | Depends on another task inside the team | Yes |
Discretionary links are your schedule-compression lever. If you need to finish sooner, look there first, since a link you chose can be removed. External links are your biggest risk, because you do not control them.
Dependency Example: The Ripple
A launch plan has four tasks in a Finish-to-Start chain: brief (2 days), design (5 days), build (6 days), QA (1 day). The chain is 14 days. If design slips by 2 days, build starts 2 days later, QA moves 2 days later, and the launch moves from day 14 to day 16. With no dependency links, the same slip shows as one late task and no other change. Links are what turn a slip into a forecast.
Now change one link. If build can start when design is 80% done, that is a lead of 1 day on a 5-day task, and the finish moves 1 day earlier. A small overlap on a critical chain is often the cheapest way to buy time.
Common Dependency Mistakes
- Leaving order in your head. If it is not recorded, the next person cannot see it.
- Linking everything. Too many links make a tangle that nobody trusts. Link only real waits.
- Ignoring external dependencies. Vendors and approvals need a named contact and a due date.
- Treating people as free. Two tasks with no link can still collide if one person owns both. Check resource allocation.
- Never revisiting them. Review links at each milestone, since plans change.
Related Terms and Concepts
Critical Path Method: The technique that turns dependency links into a finish date and a zero-float chain.
Work Breakdown Structure: The list of work packages you link.
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.
What is the difference between a predecessor and a successor?
A predecessor is the task that must happen first. A successor is the task that waits. In a Finish-to-Start link, the successor cannot start until the predecessor finishes.
What is a mandatory dependency?
A mandatory dependency is a link forced by the nature of the work or by a contract, such as pouring a foundation before building walls. You cannot remove it. A discretionary dependency is a preference, and you can change it at some risk.
What is an external dependency?
An external dependency is a link to something outside your project team, such as a vendor delivery, a regulator approval, or another company's release. It carries the most risk because you do not control the date. Name a contact and track it like a task.
How do you manage task dependencies in Taskade?
Keep tasks with owners and due dates in one project and view them on the Gantt Chart view, a paid-plan view in the More Views menu, to see the links on a timeline. An automation can notify the next owner when a predecessor is marked done.
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.