---
title: "The critical path method, explained with a worked example"
description: "What the critical path is, how to calculate it with a forward and backward pass, total vs free float, a worked example and how to use it to manage delays."
url: https://planitude.app/blog/critical-path-method-guide
language: en
---

# The critical path method, explained with a worked example

How the forward and backward pass work, how to read total and free float, what the critical path tells you about a delay, and where the method stops being enough.

by Planitude Team · Published October 14, 2026

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.

> **Key takeaways**
>
> - The critical path is the **longest chain of dependent tasks** from start to finish: its length is the shortest possible duration of the project.
> - It is calculated with a **forward pass** (earliest dates) and a **backward pass** (latest dates); the difference between the two is the **total float** of each task.
> - Tasks with zero total float are critical: **any delay on them moves the finish date**. Tasks with float can slip, but float is often shared along a chain.
> - CPM assumes fixed durations and unlimited resources: check **workload** and **uncertainty** before trusting a single finish date.

## 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](https://planitude.app/blog/task-dependencies-fs-ss-ff-sf-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:

| Task | Duration | Predecessors | Early dates | Late dates | Total float |
| --- | --- | --- | --- | --- | --- |
| A. Define requirements | 3 days | none | days 1–3 | days 1–3 | 0 |
| B. Select the furniture supplier | 5 days | A | days 4–8 | days 4–8 | 0 |
| C. Prepare the space | 4 days | A | days 4–7 | days 8–11 | 4 |
| D. Order and deliver furniture | 6 days | B | days 9–14 | days 9–14 | 0 |
| E. Network cabling | 3 days | C | days 8–10 | days 12–14 | 4 |
| F. Install furniture | 2 days | D, E | days 15–16 | days 15–16 | 0 |
| G. Move and test | 2 days | F | days 17–18 | days 17–18 | 0 |

**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](https://planitude.app/blog/project-delay-recovery-fast-tracking-crashing) 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](https://planitude.app/blog/project-baseline-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](https://planitude.app/blog/how-to-estimate-task-durations) 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](https://planitude.app/features#planning), 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](https://planitude.app/features#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](https://planitude.app/features#risk) 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](https://planitude.app/features#import) keep their links, so you can check their critical path straight away.

**Try Planitude with your own plan** [Try Planitude free](https://planitude.app/signup)

## Frequently asked questions

### Can a project have more than one critical path?

Yes. When two chains have the same total duration, both are critical, and a delay on either one moves the finish. Parallel critical paths make a schedule more fragile, because there are more ways to be late.

### What is the difference between total float and free float?

Total float is how long a task can slip without delaying the project finish. Free float is how long it can slip without delaying the early start of its successor. Free float is never larger than total float, and is often zero for tasks in the middle of a chain.

### Can float be negative?

Yes, when a deadline or constraint requires a finish earlier than the logic allows. Negative float measures how many working days must be recovered to meet that date.

### Is CPM the same as PERT?

No. PERT uses three estimates per task (optimistic, most likely, pessimistic) to describe the uncertainty of durations, while CPM works with a single duration per task. Modern tools combine them: CPM for the logic, simulation for the uncertainty.

### Does the critical path change during the project?

Often. Every progress update can shorten or lengthen chains, so a task that had float last week can become critical today. That is why the calculation must be repeated after every update.

## Sources

The official pages cited in this article, checked in October 2026.

[^1]: [Kelley & Walker (1959): Critical-path planning and scheduling](https://doi.org/10.1145/1460299.1460318)
[^2]: [PMI Lexicon of Project Management Terms](https://www.pmi.org/standards/lexicon)

## Try Planitude with your own plan

Create a free account, import your .mpp file or start from a template: within minutes you will see the Gantt chart with dependencies, calendars and the critical path.

[Try Planitude free](https://planitude.app/signup)