The critical path is the longest sequence of interdependent activities in a project. It determines the project's minimum duration.
It's one of the most frequently tested topics on the PMP exam, and at the same time the part most often misapplied in practice.
Why it matters
If an activity on the critical path is delayed by one day, the project is delayed by one day. This is automatic.
If an activity is not on the critical path, it has float — a time buffer. It can be delayed within that float without changing the project's end date.
The practical implication: when a resource is constrained, it should be redirected to the critical path. An activity with 10 days of float that doesn't affect overall project completion can be done later.
Calculating it step by step
Step 1: List activities and dependencies
For each activity: its duration, and which activity must finish first, followed by the sequence after that.
Step 2: Draw the network diagram
Activities are boxes, dependencies are arrows. From the start point to the end point.
Terms: Early Start (ES) — the earliest an activity can start, Early Finish (EF) — the earliest it can finish, Late Start (LS) — the latest it can start, Late Finish (LF) — the latest it can finish.
Step 3: Forward pass — early dates
Start from the beginning and move forward.
- Early Start (ES) of the first activity = 0
- Early Finish (EF) = ES + duration
- ES of the next activity = EF of the previous activity
If an activity has several predecessors, take the largest EF.
Step 4: Backward pass — late dates
Start from the end and move backward.
- Late Finish (LF) of the last activity = its own EF
- Late Start (LS) = LF − duration
- LF of the previous activity = LS of the next activity
If an activity has several successors, take the smallest LS.
Step 5: Calculate float
Float = LS − ES (or LF − EF, the result is the same)
Step 6: Find the critical path
Every activity with zero float is on the critical path.
Three common mistakes
First mistake: there is only one critical path
A project can have several critical paths of the same duration. This increases the risk of delay, since the source of a slip could be any of several.
Second mistake: the critical path never changes
The critical path changes as the project progresses. If a non-critical activity is delayed beyond its own float, it becomes critical.
That's why the critical path isn't calculated once — it's recalculated at every update.
Third: float belongs to the activity
Float belongs to the path, not to an individual activity. If two consecutive activities each have 5 days of float, that doesn't mean you have 10 days combined. If the first one uses up 5 days, the second one's float drops to zero.
This is the most common mistake, both in practice and on the exam.
Compressing the schedule
When a project is running over its deadline, there are two options, and both work only on the critical path.
Crashing — adding resources to shorten the duration, and this method, naturally, increases cost.
Fast tracking — performing sequential activities in parallel. It increases the risk that quality may suffer.
Adding resources to a non-critical activity doesn't speed up the project. This seems obvious, yet in practice it's exactly what happens, often.
Software
MS Project and similar tools calculate the critical path automatically. That doesn't mean understanding the calculation is unnecessary.
The software calculates whatever you enter. If you described the dependencies incorrectly, the result will be wrong too, and you'll only notice if you know what the correct answer should look like.
