The Critical Path Method, Explained
After reading this you can take a list of tasks with durations and dependencies, find the chain that sets your deadline, compute how much slack every other task has, and (in PERT mode) estimate the probability of finishing on time.
What the critical path is
A project is a set of tasks. Some tasks wait for others. "Launch" cannot start until "Testing" finishes. When tasks run in parallel, the finish date is not the sum of all durations. It is the length of the longest chain of dependent tasks. That longest chain is the critical path.
Here is the hook. Suppose "Backend" takes 10 days and "Frontend" takes 8 days, and both must finish before "Integration" begins. Adding the two gives 18, but they run at the same time, so integration waits only 10 days. Frontend has 2 days of room to slip. Backend has none. Speeding up frontend saves nothing. Speeding up backend saves a day of the whole project. The critical path tells you which task is which.
The method that computes this is old and exact. It was developed in the late 1950s for industrial projects, and the arithmetic is simple enough to do by hand for a dozen tasks.
When to use it, and when not
The Critical Path Method (CPM) assumes you know the dependencies and you have a single duration estimate per task. It fits work where the structure is fixed and the estimates are reasonable: construction, product launches, event setup, a release checklist.
It does not model resource contention. If two critical tasks need the same person, CPM will happily schedule them in parallel and lie to you. It also treats durations as certain. Real durations vary. PERT mode addresses the second problem by asking for three estimates per task, but it still ignores resource limits.
If your work arrives as a steady stream rather than a fixed dependency graph (a support queue, a sprint backlog), the critical path is the wrong lens. Use throughput-based forecasting instead: see the Monte Carlo Project Forecast and the WIP Limits & Little's Law Simulator.
The four numbers behind every task
CPM computes four times for each task with two passes over the graph.
The forward pass goes from start to finish and finds the earliest each task can happen:
Here ES_i is the earliest start of task i, EF_i is its earliest finish, d_i is its duration, and j \to i means "task j is a dependency of i." A task starts as soon as its last prerequisite finishes. Tasks with no dependencies start at time 0.
The backward pass goes from finish to start and finds the latest each task can happen without moving the deadline:
Here LF_i is the latest finish, LS_i is the latest start, and i \to k means "task k depends on i." The project end tasks get LF equal to the total project duration.
Slack (also called float) is the gap between the two:
A task with S_i = 0 cannot slip at all. The set of zero-slack tasks forms the critical path.
Worked example: the demo project
Eight tasks from requirements to launch
Load the demo data and you get these eight tasks. Durations are in days.
| ID | Name | Duration | Depends on |
|---|---|---|---|
| A | Requirements | 3 | none |
| B | Design | 5 | A |
| C | Backend | 10 | A |
| D | Frontend | 8 | B |
| E | Content | 6 | B |
| F | Integration | 4 | C, D |
| G | Testing | 5 | F |
| H | Launch | 1 | E, G |
- Forward pass. A starts at 0, finishes at 3. B:
ES=3,EF=8. C:ES=3,EF=13. D:ES=8,EF=16. E:ES=8,EF=14. - F depends on C and D, so
ES = max(13, 16) = 16,EF = 20. G:ES=20,EF=25. - H depends on E and G, so
ES = max(14, 25) = 25,EF = 26. The project takes 26 days. - Backward pass from 26. H:
LF=26,LS=25. G:LF=25,LS=20. F:LF=20,LS=16. - D feeds only F, so
LF=16,LS=8. C feeds only F, soLF=16,LS=6. E feeds only H, soLF=25,LS=19. - B feeds D and E, so
LF = min(8, 19) = 8,LS=3. A feeds B and C, soLF = min(3, 6) = 3,LS=0.
Now subtract to get slack. A: 0. B: 0. C: 6-3 = 3. D: 8-8 = 0. E: 19-8 = 11. F: 0. G: 0. H: 0.
The critical path is A, B, D, F, G, H, with total duration 3+5+8+4+5+1 = 26. Backend (C) has 3 days of slack even though it is the longest single task. Content (E) has 11 days of slack.
Reading the results
Three facts matter most once the tool has run.
- Project duration
- The earliest finish of the last task. In the demo, 26 days. This is the shortest possible schedule given the dependencies.
- The critical path
- The chain of zero-slack tasks. Every day you save on any of these tasks saves a day overall, until a parallel path catches up and becomes critical too.
- Slack per task
- How late each non-critical task can start without moving the deadline. Content can start 11 days late. Backend can start 3 days late.
Watch the tipping point. Backend has 3 days of slack. If backend slips by 4 days, its early finish moves from 13 to 17, which is later than frontend's 16. Now integration waits on backend, and the path A, C, F, G, H becomes critical. Compressing frontend at that point buys nothing. This is why the critical path is a moving target, not a fixed list.
PERT: adding uncertainty
Single durations are optimistic fiction. PERT mode asks for three numbers per task written as optimistic-likely-pessimistic, for example 2-4-8. It converts each to an expected duration and a variance.
Here o is optimistic, m is most likely, and p is pessimistic. For 2-4-8: \mu = (2 + 16 + 8)/6 = 4.33 and \sigma^2 = (6/6)^2 = 1. The weight of 4 on the likely value pulls the expected duration toward it, but the long pessimistic tail still lifts it above 4.
The tool sums the expected durations along the critical path to get the expected project length, and sums the variances (assuming tasks are independent) to get the path variance. The finish time is then approximated as normal with mean \mu_T = \sum \mu_i and standard deviation \sigma_T = \sqrt{\sum \sigma_i^2}. The probability of finishing within a target T is:
where \Phi is the standard normal cumulative function. If the path expects 26 days with \sigma_T = 3, then a target of 29 gives z = 1 and \Phi(1) \approx 0.84: about an 84 percent chance.
The normal approximation is decent when the critical path has several independent tasks. It is optimistic when two paths are nearly tied in length, because whichever runs longer on the day decides the finish, and PERT only tracks one path. If your near-critical path has slack under a few days, treat the probability as an upper bound.
Common mistakes
Four errors account for most bad schedules.
- Compressing a task with slack. Cutting backend from 10 to 8 days saves nothing while it has 3 days of slack. Money spent there is wasted.
- Forgetting the path can shift. After you compress the current critical path enough, a parallel path becomes critical. Recompute after every change.
- Circular dependencies. If A waits on B and B waits on A, no schedule exists. The tool detects cycles and reports them rather than looping forever.
- Ignoring resources. CPM assumes unlimited parallelism. Two zero-slack tasks assigned to the same person will not actually run at once, and your real finish will be later than the calculated 26 days.
Related tools
Once you know the critical path, other questions follow. For a probabilistic forecast built from real weekly output rather than task estimates, use the Monte Carlo Project Forecast. To choose between competing plans on weighted criteria, the Weighted Decision Matrix scores options and checks how sensitive the winner is. If your bottleneck is fitting work into fixed capacity rather than sequencing it, see the Box & Bin Packing Calculator.
Frequently asked questions
Can a project have more than one critical path?
Yes. If two chains have the same length, both are critical and every task on both has zero slack. In the demo, if content (E) took 17 days instead of 6, path A, B, E, H would also total 26, giving two critical paths. Then you must speed up tasks on both to move the deadline.
What is the difference between total slack and free slack?
Total slack is how late a task can finish without moving the project deadline (what this tool reports). Free slack is how late it can finish without delaying any immediate successor. Free slack is always less than or equal to total slack, and it matters when several tasks share the same buffer.
Why is the PERT mean higher than the most likely value?
The formula weights the likely value by 4 out of 6, but the pessimistic tail is usually longer than the optimistic one. For 2-4-8 the mean is 4.33, above the likely 4, because 8 is 4 days above the likely value while 2 is only 2 days below it.
Does slack mean a task is unimportant?
No. A task with 11 days of slack still has to be done, and letting it slip 12 days will move the deadline. Slack only tells you how much attention a task needs relative to its schedule risk, not how much the work matters.
How many tasks can this handle?
The two passes run in time proportional to the number of tasks plus dependencies, so hundreds of tasks compute instantly. The limit is your patience for typing them, not the arithmetic.
Related tools
Box & Bin Packing Calculator
How many boxes, bins or trucks? First-fit-decreasing packing by capacity or 3D size.
WIP Limits & Little’s Law Simulator
Watch a kanban board run: raise the WIP limit and see cycle time explode while throughput stalls.
Weighted Decision Matrix
Score your options against weighted criteria — with a sensitivity check on the winner.
Round-Robin Schedule Generator
Everyone plays everyone: fixtures by the circle method, byes included.
Seating Chart Optimizer
Assign guests to tables around keep-together and keep-apart rules.
Secret Santa Generator
Draw gift-exchange pairs with exclusions, no self-draws guaranteed.