Predecessor and successor tasks: with a worked example

A predecessor task is an activity that must reach a specific milestone—most commonly completion—before a subsequent activity can proceed. A successor task is the dependent work that cannot begin until that prior activity finishes. Together, these paired links form the sequential framework that establishes realistic schedules across any project management method.

What is the difference between a predecessor and a successor task?

A predecessor task drives the calendar date of the work that follows it, whereas a successor task reacts to changes in the predecessor. If an editor cannot proofread a manuscript until the writer completes the draft, writing the draft is the predecessor and proofreading is the successor. When the draft takes two extra days, the proofreading task automatically shifts forward by two days.

According to the GAO Schedule Assessment Guide, every activity in a credible schedule should have at least one predecessor and one successor, except for the initial start event and the final deliverable. Missing links create false flexibility, leading teams to believe they have spare time when downstream work is actually waiting.

Traditional project management suites document four logical dependency relationships, as detailed in Microsoft Support guidance on linking tasks:

1. Finish-to-Start (FS). The predecessor must finish before the successor can start. This represents the vast majority of real-world business workflows.
2. Start-to-Start (SS). The predecessor must start before the successor can start, allowing parallel activities to run concurrently.
3. Finish-to-Finish (FF). The predecessor must finish before the successor can finish, common in quality assurance or supervision.
4. Start-to-Finish (SF). The predecessor must start before the successor can finish, a rare relationship seen mainly in handover shifts.

While complex schedules accommodate all four arrangements, keeping relationships to standard finish-to-start dependencies prevents scheduling errors and makes handovers immediately understandable across teams. A broader breakdown of these four types appears in our guide on task dependencies in project management.

How do predecessor links work in a practical project schedule?

Real projects rarely fail because individual estimates were wrong; they fail because handovers between team members were not linked sequentially. In tokidu, the project manager by Sinergia Barcelona, this relationship is handled through task dependencies and work queues using «Starts when … is done», which keeps blocked activities off daily lists until their predecessor finishes.

Consider a commercial design project. This worked example illustrates how sequential finish-to-start dependencies shape a four-task delivery schedule across a working week:

A brochure for the printer

In this example, standard working hours run Monday to Friday at 6 hours per day. Each contributor works on one assignment at a time. The schedule progresses logically:

1. Design the cover serves as the initial predecessor with no incoming dependency. Ana works for two days, concluding on Tuesday 27 October.
2. Lay out the brochure is the successor to the cover design. Even though Ana handles both assignments, the layout cannot begin until Wednesday 28 October because the cover must exist first.
3. Review the copy requires the brochure layout as its predecessor. Luis starts reviewing on Thursday 29 October the moment Ana completes the layout.
4. Send to print is the final successor, waiting on copy review approval before being dispatched on Friday 30 October.

If Ana requires three days instead of two to design the cover, every successor down the line automatically moves back by one full day. That transparent ripple effect demonstrates why tracking predecessors protects commitments.

Why do teams struggle to manage predecessor and successor tasks?

Teams struggle with predecessor and successor links when tools make dependencies difficult to visualise or demand excessive administrative upkeep. When dependencies are buried inside multi-layered modal windows or hidden behind paid enterprise tiers, teams abandon them for manual chat updates.

As recorded on 2026-09-29, Microsoft Planner restricts advanced dependency adjustments—specifically editing leads and lags—to its Plan 3 subscription tier, as documented in the Microsoft Tech Community release note on lead and lag. Similarly, lighter kanban boards often require separate add-ons or custom fields just to display relationships, as examined in our review of task dependencies in Trello.

Beyond software limitations, three planning mistakes routinely break dependency tracking:

1. Creating circular dependencies. Task A waits for Task B, which inadvertently waits on Task A. Clean schedulers reject circular loops instantly because they create mathematical deadlocks.
2. Confusing resource bottlenecks with logical predecessors. If Luis must write both a report and an invoice, those tasks do not necessarily depend on each other logically. Luis simply cannot perform both at the exact same hour. A sensible tool balances team workload without forcing false dependency links between unrelated jobs.
3. Neglecting handoff buffers. In physical production or technical review, predecessors occasionally require waiting time before a successor can begin, such as waiting for ink to dry or code to build. The Microsoft Tech Community article on dependencies and critical path explains how lagging successor start dates reflects real physical constraints.

By keeping dependencies strictly tied to actual technical requirements, project managers preserve schedule clarity and avoid confusion over who works on what next.