The critical path method explained

The critical path method (CPM) answers the single most useful question in scheduling: what is the earliest date this project can possibly finish? The answer is the length of the longest chain of dependent tasks running from start to end. That chain is the critical path, and it sets a hard floor on the schedule — no amount of working harder on anything off that path will move the finish date by a single day.

It sounds almost too simple to be worth a name, but it has a sharp consequence. In any plan with more than a handful of task dependencies, most tasks have a little room to slip without hurting anyone. A few do not. The critical path tells you exactly which is which, so you stop spreading attention evenly and start spending it where delay actually costs you the project.

Why the longest path is the shortest time

Picture two chains of work that both have to finish before you can ship. Chain A takes 12 days; chain B takes 20. You can run them in parallel, but you cannot ship until both are done — so the soonest you finish is 20 days, the length of the longer chain. Speeding up chain A does nothing; it already finishes with eight days to spare. This is the heart of CPM: the longest path through the network is, paradoxically, the shortest time the whole project can take. Every other path has slack — spare time before it would start delaying the end.

A worked example

Here is a small project: five tasks, durations in days, with finish-to-start dependencies. Start (S) and End (E) are zero-length markers.

By eye the answer is already clear — the top path totals 10 days, the bottom only 5 — but eyeballing stops working on real plans, so CPM gives you a procedure. It has two passes.

The forward pass: earliest dates

Walk left to right and compute, for each task, its early start (ES) and early finish (EF). The rule: a task's early start is the latest early finish of everything feeding into it; its early finish is its early start plus its duration. Counting from day 0:

• A: ES 0, EF 4. B: ES 0, EF 3.
• C follows A: ES 4, EF 10. D follows B: ES 3, EF 5.
• E follows both C and D. Its early start is the later of the two finishes — 10, not 5. So the project finishes on day 10.

That "take the later one" step at every merge point is where the longest path quietly wins.

The backward pass: latest dates

Now walk right to left from the finish, computing each task's late finish (LF) and late start (LS) — the latest it can happen without pushing the end date. Start E at 10 and subtract durations:

• C: LF 10, LS 4. A: LF 4, LS 0.
• D: LF 10, LS 8. B: LF 8, LS 5.

The difference between a task's late and early dates is its float (or slack) — how long it can slip before it starts dragging the project. A and C have late dates equal to their early dates: zero float. B has LS 5 against ES 0 — five days of float. D has LS 8 against ES 3 — also five days. So B and D could each start almost a working week late and the project would still land on day 10.

Why critical tasks have zero float

A task is on the critical path precisely because it has no float: its earliest and latest dates are the same, so the moment it slips, the finish slips with it. Float and criticality are two sides of one coin — the critical path is simply the chain of zero-float tasks running unbroken from start to finish. (Float deserves its own treatment; total float, free float, and the negative kind are covered in slack and float explained.)

By hand versus by tool

The two-pass method above is exactly what scheduling software does — it just does it instantly and redoes it every time you change something. Drag a bar, add a dependency, lengthen a task, and the tool recomputes the whole network and re-highlights the critical chain. Doing it by hand is worth it once, on a small plan, because it builds the intuition for what the software is showing you. After that, let the machine grind the arithmetic; a fifty-task plan has too many paths to trace reliably with a pencil. The value you add is choosing the durations and dependencies honestly — the pass itself is mechanical.

How to actually use it

Knowing the critical path changes what you do day to day:

• Focus your attention. A one-day slip on a critical task costs a day off the finish. The same slip on a task with five days of float costs nothing. Protect the critical tasks; chase the float-rich ones only when their float runs thin.
• Shorten deliberately. To finish sooner you must shorten the critical path — and only the critical path. Two levers exist. Crashing means adding resources (more people, overtime, money) to a critical task to compress it. Fast-tracking means overlapping tasks that were planned in sequence, usually by converting a strict link into one with lead time so the successor starts before the predecessor fully finishes.
• Re-check after every cut. Crash or fast-track the critical path enough and a different path becomes the longest one. The critical path moves; chasing the old one past that point wastes effort.

The honest caveats

CPM is powerful, but it is a model, and models simplify:

• It shifts as the plan changes. The critical path is true for the durations you entered today. Re-estimate a task, add a dependency, or slip a date and it can jump to a completely different chain. Treat it as a live readout, not a fixed fact — and keep your duration estimates honest, because the whole thing is built on them.
• Near-critical paths bite. A path with one or two days of float is not safe — it is one small slip from becoming critical. Watch the runners-up, not just the leader.
• The longest single task is not necessarily on it. A fat eight-day task sitting on a path that totals nine days is less dangerous than a three-day task on the ten-day critical path. Criticality is about the path, not the size of any one bar — a common and costly intuition to get wrong.
• It assumes durations are fixed and resources unlimited. Classic CPM ignores the fact that the same person may be needed on two "parallel" tasks at once. That is what resource levelling and critical-chain thinking address — and why the textbook critical path is a starting point, not the last word.

Used with those caveats in mind, the critical path is the most honest single number a schedule can give you. It tells you the truth about what is drivable, where the pressure really sits, and which heroics will move the date — and which will just make everyone tired.

Frequently asked questions

What is the difference between the critical path and the longest task?

They are unrelated. The critical path is the longest chain of dependent tasks from start to finish; the longest single task may sit on a short path with plenty of float. A small task on the critical path drives the end date; a large one off it does not.

Can a project have more than one critical path?

Yes. If two or more paths through the network share the same longest length, every task on each of them has zero float and all of them are critical. That makes the schedule more fragile, because a slip on any of those paths moves the finish.

Does the critical path change during a project?

Often. As tasks finish early or late and estimates are revised, the longest path can shift to a different chain. Good tools recompute it continuously, so it is best read as a live indicator rather than a one-time calculation.

What is the difference between crashing and fast-tracking?

Crashing shortens a critical task by adding resources — more people, overtime, money — and tends to raise cost. Fast-tracking overlaps tasks that were planned in sequence, which adds risk and rework rather than cost. Both only help if applied to the critical path.