what the critical path actually is

Once a project plan is sequenced, some tasks can slip a little without affecting the finish date, and others can't slip at all. The critical path is the longest chain of dependent tasks from start to finish — it determines the earliest possible completion date, and every task on it has zero room to slip. Delay any task on the critical path by a day, and the whole project finishes a day later.
Tasks not on the critical path have float (also called slack): the amount a task can slip without pushing out the project finish date. A task with 3 days of float can start late, run long, or both — up to 3 days total — without anyone else noticing.

computing it: forward pass, backward pass

The forward pass walks the network from start to finish, computing each task's early start (ES) and early finish (EF) — the soonest it could start and finish given its dependencies (EF = ES + duration; a task with multiple predecessors takes the latest EF among them as its ES).
The backward pass walks the network from finish to start, computing each task's late start (LS) and late finish (LF) — the latest it could start and finish without delaying the project (starting from the project's finish date and subtracting durations; a task feeding multiple successors takes the earliest LS among them as its LF).
Float = LS − ES (equivalently LF − EF). Tasks with zero float are on the critical path.
A small example: a five-task project to rebuild a company's marketing site.
TaskDurationDepends onESEFLSLFFloat
A — Requirements gathering2d02020
B — Wireframes3dA25361
C — Backend API build4dA26260
D — Frontend integration & QA2dB, C68680
E — Launch prep1dD89890
The critical path is A → C → D → E, a nine-day project. Wireframes (B) has one day of float — it can start a day late or take a day longer without moving the launch date, because the backend build running in parallel takes a day longer anyway.

capacity planning: the schedule still needs people

The critical path math above assumes every task has whatever people it needs, whenever it needs them. In practice, the same designer might be the only person who can do both wireframes and a later design-review task, and the schedule breaks the moment those two land on the same day. Capacity planning checks that planned work doesn't exceed the hours actually available from the people assigned to it.
Resource overallocation is when someone is scheduled for more hours in a period than they actually have — two "full-time" tasks in the same week, for instance. Two techniques resolve it:
  • Resource leveling — delay tasks (using their float, or by pushing the project end date if float runs out) so no one is overallocated. Prioritizes a workable schedule over the original finish date.
  • Resource smoothing — adjust task timing only within existing float, so overallocation is reduced without moving the project finish date at all. Weaker fix, but keeps the deadline intact.
In the example above, if the same backend engineer is needed for both task C and an unrelated task on another project during the same week, leveling might push C later — and because C is on the critical path with zero float, that delay pushes the whole launch date out. This is why capacity constraints can turn what looked like a comfortable plan into a resource-critical path: the real bottleneck is who's available, not just what depends on what.

practical notes

The critical path isn't fixed for the life of the project — if a task with float slips by more than its float allows, it can become critical, and the original critical path can lose that status if it finishes early while another chain catches up.
Watch near-critical paths too — chains with only a day or two of float are one bad week away from becoming the new critical path, and tracking only the current critical path can miss that risk building up elsewhere.

related topics

reference