Predecessors and Successors in Project Management

What are predecessors and successors?

A predecessor is an activity that logically comes before another activity and controls when that activity can start or finish. A successor is the activity that comes after it and depends on it. The relationship between them is a dependency, and the predecessor is always the activity the arrow leads out of.

A simple example: you cannot install software on a laptop until the hardware has been set up. "Set up hardware" is the predecessor and "Install software" is the successor. If the hardware arrives three days late, the software installation moves three days too, unless you change the plan.

PMI's terminology talks about the predecessor activity and the successor activity, and the method most schedules use to draw them is the precedence diagramming method (PDM), where activities are boxes (nodes) and dependencies are arrows. A few points follow from the definition:

• Each dependency has exactly one predecessor and one successor.
• Most activities are both: a successor to the work before them and a predecessor to the work after them.
• An activity can have several predecessors and several successors.
• Only the very first activity has no predecessor and only the last has no successor. In practice these are usually a start milestone and a finish milestone; see project milestones.

Predecessors and successors describe the two ends of a link. The link itself, and its type, is covered in our guide to task dependencies.

Predecessor vs successor at a glance

The words are relative. "Design pages" is a successor of "Agree requirements" and, at the same time, a predecessor of "Build pages". Whether you call an activity a predecessor or a successor depends on which link you are looking at.

The four relationship types in predecessor terms

A predecessor does not always have to finish before its successor starts. There are four logical relationship types, and each one describes which end of the predecessor controls which end of the successor.

Any of these links can carry a lag (a deliberate wait, such as FS+3 days for paint to dry) or a lead (an overlap, written as a negative lag such as FS-2 days). Leads and lags change the timing of the link but not which activity is the predecessor.

Types of predecessor you will hear about

Immediate and indirect predecessors

An immediate predecessor is linked directly to the activity. Activities further back in the chain are indirect predecessors: they still affect the activity, but only through the links in between. Record only immediate predecessors. Linking an activity to every earlier activity creates redundant links that make the schedule hard to read and harder to change.

Driving and non-driving predecessors

When an activity has several predecessors, only one of them usually controls its start date at any time. That is the driving predecessor. The others are non-driving: they finish earlier and have some float before they would affect the successor.

The driving predecessor can change as work progresses. A non-driving predecessor that runs late can overtake the driving one and become the new driver.

Multiple predecessors and multiple successors

An activity with several predecessors is where paths meet; PMI calls this path convergence. An activity with several successors is where paths split, known as path divergence. Convergence points are risky because the successor waits for the latest of all its inputs, so a delay on any one path can hold everything up. Divergence points are risky because a delay to one activity spreads to every path that leaves it.

Mandatory, discretionary and external predecessors

Predecessors also differ in why the link exists. A mandatory (hard logic) predecessor reflects physical or contractual necessity. A discretionary (soft logic) predecessor reflects a preferred way of working that you could change, which makes it the first place to look when you need to fast-track a schedule. An external predecessor sits outside the project, such as a supplier delivery or a regulator's approval. These categories are explained in task dependencies.

How to identify predecessors and successors step by step

1. Start from the activity list. Break the scope down with a work breakdown structure and turn each work package into activities; see project tasks and activities.
2. Ask one question per activity: what must be finished (or started) before this can begin? The answers are its candidate predecessors.
3. Keep only the immediate predecessors. If A drives B and B drives C, do not also link A to C.
4. Choose the relationship type. Use finish-to-start unless the work genuinely overlaps or must finish together.
5. Add a lead or lag only when there is a real reason, such as curing time or a notice period, and write that reason down.
6. Check successors. For each activity, ask what is waiting for it. An activity that nothing depends on is either the finish milestone or a missing link.
7. Draw or generate a network diagram to spot loops, dangling activities and parallel paths; see project network diagram.
8. Review the logic with the people doing the work. They know which dependencies are real and which are habits.

Worked example: a website launch schedule

A small team is launching a new website. The table lists each activity with its duration, immediate predecessors and successors. All links are finish-to-start with no lag.

A is a burst point (path divergence) because it has two successors. E is a merge point (path convergence) because it has two predecessors. Working forward from day 0 gives these earliest dates:

E cannot start until both predecessors have finished. C finishes on day 7 but D does not finish until day 14, so D is the driving predecessor of E and C is non-driving, with 7 days of float. The critical path is A, B, D, E, F and the project takes 19 days.

• If C slips by 3 days, it finishes on day 10. E still starts on day 14, so the launch date does not move; C's float drops to 4 days.
• If D slips by 3 days, E starts on day 17 and the launch moves to day 22.
• If C slips by 9 days, it finishes on day 16, overtakes D as the driving predecessor and pushes the launch out by 2 days (9 days of delay minus 7 days of float).

This is why you monitor driving predecessors closely and watch the float on the others. The calculation method is explained step by step in forward and backward pass.

How predecessors appear in Gantt charts, network diagrams and tools

Gantt charts

In a Gantt chart, a dependency is drawn as an arrow from the predecessor's bar to the successor's bar. For a finish-to-start link the arrow runs from the end of the predecessor to the start of the successor. When you move a predecessor in most Gantt chart software, its successors move with it automatically.

Network diagrams

In an activity-on-node network diagram, each activity is a box and each arrow runs from predecessor to successor. Network diagrams make convergence and divergence points easy to see, which is why they are useful for checking logic even if you manage day to day in a Gantt view. A PERT chart uses the same idea with three-point estimates.

Predecessor notation in scheduling tools

Most desktop scheduling tools let you type predecessors into a column using the predecessor's row ID, the link type and any lead or lag. In Microsoft Project, according to Microsoft's documentation, entering just an ID creates a finish-to-start link with no lag, a positive number adds lag and a negative number adds lead. Several predecessors are separated by the list separator (a comma or semicolon, depending on regional settings).

In the website example, E (Load content) would show "3,4" if C and D were rows 3 and 4. Cloud tools such as Wrike and Smartsheet let you create the same links by dragging between bars in the Gantt view or by filling in a predecessors column, and both support dependencies and critical path views on paid plans.

Tracing logic

Many tools can highlight a task's predecessors and successors. Microsoft Project's Task Path feature, for example, can highlight predecessors, driving predecessors, successors and driven successors in the Gantt chart. When a milestone slips, tracing its driving predecessors backwards is usually the fastest way to find the real cause.

Why predecessors matter for the critical path and float

The critical path method is built entirely on predecessor and successor links. The forward pass pushes earliest dates from predecessors to successors; the backward pass pulls latest dates from successors back to predecessors. The difference between the two is float, and the chain of activities with zero (or the least) float is the critical path.

That has some practical consequences:

• An activity with no successor has misleading float. Its float is measured against the project end, so it can slip a long way before the schedule shows any impact, even if something else really depends on it.
• An activity with no predecessor can start on day one. Unless that is true, the schedule will show work starting before it realistically can.
• Missing links make the critical path wrong. If the logic is incomplete, the path your tool highlights may not be the one that actually controls the finish date.
• Resource limits are not predecessors. CPM assumes unlimited resources. If two activities cannot run together because the same person does both, that is handled by resource leveling, not by inventing a logic link.

Common mistakes with predecessors (and how to fix them)

If the same overlap keeps needing a start-to-start link with a long lag, it is often clearer to split the predecessor into two activities and link the successor to the first part.

Checking the quality of your schedule logic

Large projects often test schedule logic against published health checks. A widely used example is the US Defense Contract Management Agency (DCMA) 14-point assessment, which includes these logic checks:

These thresholds come from a defence-contracting context, but they make a useful sanity check for any schedule. Our own advice for smaller projects is simpler:

• Filter for activities with an empty Predecessors or Successors column and fix each one.
• Move one early activity by a week and check that the finish date moves as you expect.
• Read the critical path aloud from start to finish; if any step sounds illogical, check its links.
• Re-run the checks before you set the project baseline and after any major replan.

Best practices for managing predecessors

• Build the logic before you add dates. Let the links calculate the dates rather than typing them in.
• Give every activity a clear owner so someone is accountable when a predecessor runs late.
• Agree cross-team and external predecessors early, with a named contact on the other side.
• Treat convergence points (activities with many predecessors) as risks and monitor them.
• Note why each discretionary link exists so you know which ones can be changed to recover time; see schedule compression.
• Keep the network tidy with start and finish milestones, and use a hammock activity for support work that spans a group of activities.
• Update links as part of your regular schedule review, not only when something goes wrong.

If you are building a schedule from scratch, the free project schedule template, critical path template and Gantt chart template all include predecessor columns, and the work breakdown structure template helps you build the activity list first. For the wider process, read our guide to project scheduling.

Free templates for this topic

Browse all templates

Frequently asked questions