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.
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.
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.
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 a task 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 have room.
By definition, tasks on the critical path have zero total float.
How the critical path is found
The critical path is computed, not chosen. It requires two things: a dependency network and a duration for each task.
From there, the calculation runs in two passes — a forward pass computing the earliest each task can start and finish, and a backward pass computing the latest each can start and finish without delaying the project. The difference between the two is the float. The chain where that difference is zero is the critical path. The full arithmetic is here.
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.
This has a practical consequence that is often missed: shortening the critical path does not shorten the project indefinitely. Compress it enough and another chain becomes the longest one. Beyond that point, further effort on the original path buys nothing.
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.
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.
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.
