The critical path is the longest sequence of dependent tasks in a project. It determines the minimum time the project can possibly take. Any delay on a task sitting on that path pushes the delivery date by exactly the same amount, which is what makes it the single most useful number in a schedule, and the one most often misread.
Longest, not most important
The most common misunderstanding is to read "critical" as "important". It does not mean that. A task can be strategically vital and sit off the critical path. A trivial administrative step can sit on it and hold the whole project.
Critical is a structural property, not a judgement of value: it means the task has zero float. There is no room to move it without moving the end of the project.
This is why the critical path cannot be decided in a meeting. It is a consequence of two things only: which tasks depend on which, and how long each one takes. Change either and the answer changes, whatever anyone thinks about priorities.
Reading one from a small network
Four steps, with one branch. Specifying comes first. Building and writing the documentation can then run in parallel. Shipping waits for both.
- Specify, 5 days
- Build, 8 days, after Specify
- Test, 4 days, after Build
- Write docs, 3 days, after Specify
- Ship, 2 days, after Test and after Write docs
There are two routes from start to finish:
- Specify, Build, Test, Ship: 5 + 8 + 4 + 2 = 19 days
- Specify, Write docs, Ship: 5 + 3 + 2 = 10 days
The project cannot take less than 19 days, so the first route is the critical path. Every task on it has zero float.
Writing the documentation has room. It can start on day 5 and must be finished by day 17, when shipping begins. Three days of work in a twelve-day window leaves nine days of float. Nine days during which nothing you do to the documentation changes the delivery date.
That is the practical value of the calculation: it tells you where effort moves the date and where it does not. The arithmetic behind it, including how to derive durations from three-point estimates, is set out in the PERT formula and critical path calculation.
Float: total and free
Float, also called slack, is the amount of time a task can slip without causing damage. Two measures matter, and confusing them leads to bad decisions.
- Total float: how long a task can slip without delaying the project end date.
- Free float: how long it can slip without delaying any successor.
A task can have several days of total float and zero free float: delaying it will not move the project, but it will immediately squeeze the next task. Teams that only look at total float routinely create local crises while believing they had room.
By definition, tasks on the critical path have zero total float.
Why it moves
The critical path is not a fixed property of a project. It is the result of the current durations and dependencies. Change either, and it can jump to a different chain entirely.
Take the example again. If writing the documentation turns out to need 13 days instead of 3, its route becomes 5 + 13 + 2 = 20 days, longer than the 19 of the build route. The critical path is now the documentation branch, and every hour spent accelerating the build buys nothing at all.
This has a consequence that is often missed: shortening the critical path does not shorten the project indefinitely. Compress it enough and another chain becomes the longest. Beyond that point, further effort on the original path is wasted.
It also means the critical path has to be recomputed as the project evolves. A critical path identified at kick-off and never revisited is a historical artefact, not a management tool. This is the argument for computing it in a tool that recalculates on every change rather than by hand.
Watch the near-critical paths
A chain with two days of float is not safe, it is two days from being critical. Projects rarely fail because the critical path slipped: they fail because a second chain nobody was watching overtook it.
In practice, look at every path whose float is smaller than the delays you routinely absorb. If your tasks commonly slip by three days, a path with two days of float is already critical in all but name, and deserves the same attention.
This is also why a single critical path can be misleading on a project with many parallel branches. Several chains within a few days of each other means the date is fragile everywhere, not robust except in one place.
What the critical path does not tell you
The calculation assumes that anyone needed is available when the schedule says so. It knows about dependencies between tasks, not about competition for people.
Two tasks off the critical path, both assigned to the only person who can do them, will run one after the other in reality and can push the project further than the critical path suggests. The critical chain approach exists precisely to handle that resource constraint, and it is a different calculation.
So the critical path answers one question well, the sequencing one, and stays silent on the staffing one. Reading it as a complete picture of project risk is a mistake. A workload view alongside the network is what closes the gap.
What to do with it
Knowing the critical path changes three decisions.
- Where to put your best people. Effort spent off the critical path does not bring the date forward.
- What to protect. A critical task with a single owner and no backup is the project's real risk, whatever the risk register says.
- What to escalate. A one-day slip on the critical path is a schedule change. The same slip elsewhere may be noise.
And one conversation. When a date is challenged, the critical path is what lets you answer with a structure rather than an opinion: this chain sets the date, here is what would have to change to move it. Without it, every delay looks equally alarming, which in practice means none of them does. This is how a small local delay quietly becomes a project-wide one.
