Learn about What are predecessors in project management. This comprehensive guide covers everything you need to know for beginners.
11 May 2026
Taro
TL;DR: Most definitions of predecessors stop at "Task A before Task B." The real value is in understanding how dependency types — finish-to-start, start-to-start, finish-to-finish, start-to-finish — let you model realistic schedules that absorb slippage instead of collapsing under it. This article shows how IT teams can map predecessor relationships to expose critical path bottlenecks before they become missed deadlines.
A predecessor is a task that must reach a defined completion state before a specific successor task can begin or advance. That's the precise definition. The word "predecessor" is not just a synonym for "earlier task" — the relationship carries a formal dependency condition that determines whether the next task is allowed to start at all.
Most people default to thinking about predecessors as a simple sequence: task A finishes, then task B starts. That covers one dependency type, but mapping all four dependency types between tasks shows the full picture is wider than that. A predecessor can require only that a task has started, not finished. Or it can require that two tasks finish together. The relationship type changes what "predecessor" actually means in practice.
This distinction matters most during the planning phase of a project, when you're building the schedule. If you treat every predecessor as a simple finish-before-start relationship, you'll either over-constrain your timeline or miss genuine blockers entirely.
As inloox.com notes, a predecessor is defined by its dependency relationship to another activity, not by its position in a calendar. Two tasks can overlap, run in parallel, or finish simultaneously — and predecessors govern all of those patterns.
Setting predecessors at the task level is where that logic gets applied. The next section covers each of the four formal dependency types and what they look like in an IT project context.
Most project managers know the finish-to-start relationship by instinct: you can't test software until the code is written. But that's one of four distinct dependency types defined in formal project management practice, and using only that mental model causes real scheduling problems.
Here's how all four work, each with an IT context.
Finish-to-Start (FS) is the most common. Task A must finish before Task B can start. In practice: code review must complete before a developer can merge to the main branch. This finish-to-start dependency is the default in most scheduling tools, which is exactly why the other three get overlooked.
Start-to-Start (SS) means Task B can't start until Task A has started, but both can run in parallel after that. Example: QA documentation can begin as soon as sprint development starts, because the team needs to document features as they're built, not after. Waiting for development to finish would add unnecessary lag.
Finish-to-Finish (FF) means Task B can't finish until Task A finishes. User acceptance testing can't close out until bug fixes are complete. The two tasks may overlap in execution, but their endings are locked together.
Start-to-Finish (SF) is the rarest. Task B can't finish until Task A starts. A legacy system stays live until the new deployment goes active. The old system's "finish" depends on the new one's "start." Project Insight notes this is the least common relationship in practice, and most teams go entire project cycles without needing it.
Why does this matter beyond terminology? Because when you're setting predecessors at the task level, choosing the wrong type shifts your entire schedule. An FS where an SS would work adds days of unnecessary wait time. At scale, those misclassified task dependencies compound into the kind of timeline drift that's hard to explain to a client.
Every task in a project sits in one of two positions relative to the tasks around it: it either controls something, or it depends on something. That's the predecessor-successor relationship in plain terms.
By definition, the predecessor is the first task; it controls the start or end date for all related successor tasks. The successor is the task that follows, waiting on the predecessor to reach a defined state before it can move.
The part most project plans miss: a single task is almost always both. In an IT sprint, "write unit tests" is a successor to "complete feature development" and a predecessor to "run QA review." Strip out that middle task and you don't just lose one step, you break the chain in both directions.
This is why project timeline sequencing works best when you think in chains rather than pairs. Two tasks in isolation tell you almost nothing. Three tasks in sequence tell you where the bottleneck lives.
Successor tasks inherit risk from everything upstream. A two-day slip on a predecessor doesn't stay contained, it shifts every dependent task that follows. Mapping all four dependency types between tasks makes that propagation visible before it becomes a delivery problem.
The next section covers how to build those chains deliberately, starting from a blank deliverable list.
Start during the planning phase of a project, before you've assigned a single task or set a single date. The three steps below work for any project type — the example runs through a two-week IT sprint.
Write out every output the project requires, without worrying about order yet. For a sprint, this might include: environment setup, API integration, unit testing, QA review, and deployment. Keep the list at the deliverable level, not the activity level. If a deliverable is too broad to hand to one person, break it down.
Go through each deliverable and answer that question literally. Unit testing cannot start until API integration is complete. QA review cannot start until unit testing passes. This question forces you to name real blockers rather than assume a logical order exists. For each answer, you've just identified a predecessor. When mapping all four dependency types between tasks — finish-to-start, start-to-start, finish-to-finish, start-to-finish — this step is where you decide which type applies. Most sprint tasks use finish-to-start, but environment setup and API integration might run start-to-start if the team is large enough to parallelize.
Connect the deliverables in sequence. You should end up with a chain (or several branching chains) where each task points to its successor. In the sprint example: environment setup → API integration → unit testing → QA review → deployment. Any gap in the chain is a missing predecessor — find it before you start setting predecessors at the task level in your project tool.
Once the chain is visible, tasks that have no predecessor become your starting points, and tasks with multiple predecessors become your risk concentration points. Those are exactly what the critical path calculation needs next.
The critical path method works by finding the longest unbroken chain of task dependencies from project start to finish. Every task on that chain has zero float, meaning no slack time before it must start. A one-day slip in any predecessor on the path pushes the delivery date by exactly one day.
Here is how predecessor chains produce that path in practice.
When you map your task dependencies, some chains run in parallel and some run in sequence. The critical path is whichever sequence takes the longest total duration. Tasks off that path have float: they can slip without moving the end date. Tasks on it cannot.
Consider a five-sprint release. If environment setup (3 days) must finish before backend development (10 days) can start, and backend must finish before QA (5 days) can start, that chain totals 18 days. If a separate design track runs 12 days in parallel, the 18-day chain is your critical path. A two-day delay in environment setup does not just affect environment setup; it compresses every successor on that chain.
This is why setting predecessors at the task level matters more than it looks during the planning phase of a project. A predecessor you miss or misclassify can hide a critical path entirely, making a risky chain look like it has float when it does not.
Most teams also default to finish-to-start relationships for every dependency. That works for sequential tasks, but not all dependencies are sequential. Mapping all four dependency types between tasks lets you model overlapping work accurately, which changes which chain is actually longest.
Once the critical path is visible, surfacing which blocked tasks need attention first becomes the daily management question rather than a weekly fire drill.
Three mistakes account for most of the predecessor-related delays IT project managers see repeatedly.
Missing implicit dependencies is the most common. A developer assumes the staging environment will be ready before integration testing starts, but nobody logged that as a formal predecessor. The dependency exists in everyone's head and nowhere in the schedule. When staging slips two days, integration testing slips too, and the team only finds out when someone tries to start work. During the planning phase of a project, every assumed dependency needs to be made explicit or it becomes a hidden schedule risk.
Defaulting to finish-to-start for every relationship is the second error. The four dependency types — FS, SS, FF, and SF — exist because not every task needs its predecessor fully complete before it can begin. Using FS where a start-to-start relationship fits artificially extends the schedule. Two tasks that could run in parallel get forced into a sequence, adding days or weeks with no real technical reason.
Not updating predecessors when scope changes is the most damaging. A task gets added mid-sprint, but nobody wires it into the existing dependency chain. It runs without predecessors, which means the critical path method no longer reflects reality. The schedule says the project is on track; the actual work is not.
All three errors are easier to catch when your tool supports setting predecessors at the task level and surfacing which blocked tasks need attention first before delays compound.
Predecessors aren't just sequencing—they're the logic that holds a schedule together. When you map dependency types correctly, you expose where real bottlenecks live and where parallel work can actually happen. Most IT teams start with finish-to-start relationships everywhere, then watch cascading delays unfold when a single task slips.
Manually tracking these relationships across a growing backlog is where control gets lost. Taro's dependency mapping and AI prioritization handle predecessor relationships automatically, surfacing critical path risks before they become missed deadlines. Ready to see how your current task chains would look with full dependency visibility? Explore Taro's task dependencies feature.
Q. What are predecessors in project management?
A. A predecessor is a task that must reach a defined completion state before a specific successor task can begin or advance. The relationship is governed by one of four dependency types: finish-to-start, start-to-start, finish-to-finish, or start-to-finish.
Q. How do I identify predecessors in a project timeline?
A. List every deliverable, then ask "what must be true before this starts?" for each one. Your answers name the predecessors. Map those relationships into a chain to expose gaps and confirm all blockers are accounted for before setting tasks in your tool.
Q. What is the difference between predecessors and successors?
A. A predecessor controls the start or end date for a successor task. A single task is almost always both: it depends on upstream predecessors and gates downstream successors. Thinking in chains rather than pairs reveals where bottlenecks actually live.
Q. Can you give examples of predecessors in a workflow?
A. Code review must finish before a developer can merge (finish-to-start). QA documentation can start as soon as sprint development starts, running in parallel (start-to-start). Bug fixes and UAT must finish together (finish-to-finish).
Q. bHow do predecessors affect the critical path of a project?
A. Predecessors define the critical path—the longest chain of dependent tasks that determines project duration. Any slip on a critical path predecessor shifts every downstream task. Mapping all four dependency types exposes which tasks actually control your timeline.
Q. Can a task have more than one predecessor?
A. Yes. A task can wait on multiple predecessors before it can start. In the article example, QA review depends on unit testing completion, but it also inherits risk from API integration and environment setup upstream.
Q. What happens when a predecessor task is delayed?
A. Every successor task shifts by the same amount. A two-day slip on a predecessor doesn't stay contained—it propagates through the entire chain. This is why mapping dependencies before execution prevents cascading delays.
Start your 14 day Pro trial today. No credit card required.