The critical path method, explained with a worked example

Every project has more tasks than anyone can watch closely. The critical path method (CPM) answers a simple question: which of them actually decide the finish date? Delay one of those tasks by a day and the project ends a day later. Delay one of the others and, up to a point, nothing changes.

The method was described by James E. Kelley and Morgan R. Walker in 1959^[1], and it is still the engine behind every scheduling tool, from Microsoft Project to modern online Gantt charts. Knowing how it works lets you read a schedule critically instead of trusting whatever bar turns red.

What the critical path is#

A schedule is a network: tasks connected by dependencies, each with a duration. Several chains of tasks run from the start of the project to its end. The critical path is the chain with the longest total duration, and therefore the one that sets the earliest possible finish.

“Critical path” and “total float” are both part of the standard project management vocabulary^[2], and they come from the same calculation. Float (also called slack) is how long a task can slip without delaying the project. On the critical path, float is zero: those tasks have no room at all.

Two consequences are worth stating plainly:

• The critical path is not the list of important tasks. A contract signature can be vital and still have three weeks of float. Criticality is about time, not value.
• The critical path can change. When a non-critical task slips past its float, or a critical task finishes early, another chain may become the longest one.

How the calculation works#

CPM needs three inputs for every task: a duration in working days, its predecessors, and the type of each link. With those, the calculation has two passes.

Forward pass. Starting from the beginning of the project, each task gets an early start (the latest early finish among its predecessors) and an early finish (early start plus duration). The early finish of the last task is the project duration.

Backward pass. Starting from the end, each task gets a late finish (the earliest late start among its successors) and a late start (late finish minus duration). These are the latest dates the task can have without moving the project finish.

Float. Total float is late start minus early start. Free float is how far a task can slip before it delays the early start of its next task, which is often less.

The method works the same way with start-to-start, finish-to-finish and lagged links; only the arithmetic of each link changes. The guide to task dependencies and lag shows how each type moves dates.

A worked example: moving an office#

A small company plans to move to a new office. Seven tasks, all linked finish-to-start, durations in working days:

Forward pass. A runs on days 1–3. B and C both start on day 4: B ends on day 8, C on day 7. D follows B (days 9–14), E follows C (days 8–10). F waits for both D and E, so it starts after the later of the two, day 14, and runs on days 15–16. G closes on days 17–18. The project lasts 18 working days.

Backward pass. G must finish by day 18, so it starts by day 17; F by day 15. F’s predecessors must finish by day 14: D therefore has late dates of days 9–14, and E of days 12–14. C must finish before E’s late start, so by day 11, and can start as late as day 8. B must finish before D’s late start, by day 8.

Reading the result. The critical path is A, B, D, F, G: 3 + 5 + 6 + 2 + 2 = 18 days. Space preparation and cabling have 4 days of total float each.

Look closely at C and E, though. Their float is shared. C has 4 days of total float but zero free float: any delay on C pushes E. If the space is ready 3 days late, E still fits, but it has only 1 day left. Float belongs to the chain, not to each task.

The practical consequences:

• If supplier selection slips by 2 days, the move slips by 2 days.
• If cabling slips by 3 days, nothing changes. If it slips by 6, the move slips by 2, and C and E join the critical path.
• Adding a person to space preparation does not shorten the project at all, because C is not critical.

What to do with the critical path#

Once you know the critical path, you know where to spend attention.

1. Track critical tasks more closely. Ask for progress on them at every update, not only at milestones.
2. Protect their owners. Avoid pulling people off a critical task for something with float.
3. Watch near-critical chains. A chain with one or two days of float can become critical after a small slip.
4. Shorten the schedule only on the critical path. Running tasks in parallel or adding effort helps only where float is zero; elsewhere it costs effort and saves nothing. The guide on recovering a delayed project compares fast-tracking and crashing.
5. Compare with the baseline. Slippage on a critical task is a finish-date problem; on a task with float, it is a warning. The baseline and variance guide explains how to read both.

Checklist before trusting a critical path:

• Does every task, except the first and the last, have at least one predecessor and one successor?
• Are durations in working days, on the right calendar, with holidays included?
• Are there fixed dates or constraints that override the logic?
• Are summary tasks free of links that should belong to their subtasks?
• Has anyone checked that the people on critical tasks are not overloaded?

The limits of the method#

CPM is precise arithmetic on imprecise inputs. Three limits matter in practice.

Durations are estimates. The critical path uses one number per task, but a task estimated at 5 days might take 4 or 9. A chain with 2 days of float and very uncertain tasks can be riskier than the official critical path. Good duration estimates help, and so does simulating the uncertainty.

Resources are assumed unlimited. If the same developer is on two tasks scheduled in parallel, the network says both can happen, but reality says one waits. Always look at the workload alongside the critical path.

Missing links create false float. A task without a successor shows a lot of float simply because nothing depends on it in the plan. Before trusting a float value, check that the logic is complete.

Common mistakes#

• Manual dates everywhere. Tasks with hand-typed dates or hard constraints break the calculation: float becomes meaningless.
• Dangling tasks. Tasks that lead nowhere make the network look more flexible than it is.
• Treating float as personal spare time. If each owner spends “their” float, a shared buffer is gone twice over.
• Calculating once. The critical path must be recomputed after every update, because progress changes it.
• Confusing critical and important. A high-risk task with float still needs attention, just not for the finish date.

How to do it in Planitude#

In the Gantt chart, turn on the critical path whenever you need it: critical tasks and links are highlighted in red, and the total float of each task is shown. Dependencies support all four types (FS, SS, FF and SF) with lead and lag in working days, and constraints such as “start no earlier than”, deadlines and manually scheduled tasks are taken into account. Project calendars handle working weeks, holidays and exceptions, so float is counted in real working days.

During tracking, the baseline is saved automatically at the first progress update (or with “Save baseline”), and each task shows its slippage in working days. When a delay exceeds the available float and spreads to other tasks, the affected links turn red, and hovering over them shows how far each task moves.

To go beyond a single finish date, the Monte Carlo simulation uses three-point estimates to give P50, P80 and P95 dates, the probability of meeting a deadline and a criticality index for each task: how often it ends up on the critical path across the simulated scenarios. Plans imported from Microsoft Project files keep their links, so you can check their critical path straight away.

Frequently asked questions#