Critical Path Method and PERT

AA Gantt chart shows you a schedule; it doesn't tell you which tasks actually determine how long the project takes, or how confident you should be in any of the dates. Two techniques, developed independently within a year or two of each other in the late 1950s, answer exactly those two questions: Critical Path Method (CPM) finds the schedule-determining sequence of tasks, and PERT adds a way to handle the fact that real durations are uncertain. Both predate agile by decades and are still routinely used underneath it, particularly for release-level and multi-team planning.

Two Separate Origins

CPMCPM and PERT are often mentioned in the same breath, and are close enough in mechanics that they're frequently taught as one technique — but they came from different problems entirely.

Critical Path Method was developed starting around 1956–1957 in a joint effort between the DuPont chemical company and the Remington Rand computer firm, formalised by Morgan R. Walker (DuPont) and James E. Kelley Jr. (Remington Rand). The motivating problem was scheduling chemical-plant construction and maintenance shutdowns — work with many interdependent activities where the calculations were run on a UNIVAC-I computer. It was first tested on a plant-construction project in 1958 and a maintenance shutdown in 1959, reportedly saving DuPont around $1 million in its first year of use¹.

PERT (Program Evaluation and Review Technique) was developed in 1958 by the US Navy's Special Projects Office working with Lockheed and the consulting firm Booz Allen Hamilton, for the Polaris submarine-launched ballistic missile programme — a project with far less certainty about individual task durations than a chemical plant retrofit, since much of the underlying technology was still being invented as the schedule was being planned. PERT is widely credited with helping bring forward the Polaris programme's timeline².

So: same era, same broad goal (schedule a complex web of dependent tasks), but CPM grew out of a deterministic industrial-engineering problem and PERT out of a genuinely uncertain R&D one. That difference in origin is exactly the difference in what each technique is best at.

Forward Pass, Backward Pass, and Float

CPM'sCPM's core mechanism finds, out of every possible path through a project's dependency network, the one that determines the minimum possible project duration — the critical path: the sequence of tasks with zero float (also called slack), meaning none of them can slip without delaying the whole project.

The calculation runs in two passes over the network:

• Forward pass — walk the network from start to finish, computing the earliest each task could start and finish, given its predecessors.
• Backward pass — walk it again from finish to start, computing the latest each task could start and finish without pushing out the overall end date.
• Float for a task is the gap between its earliest and latest allowable start (or finish) times. Zero float means the task is on the critical path — any delay there delays the project. Positive float means the task has slack — it can slip by that many days for free.

Worked example — four tasks, single project:

Forward pass: A runs days 0–3. B and C both start at day 3 (both depend only on A): B finishes at day 8, C finishes at day 6. D depends on both B and C, so D can't start until the later of the two — day 8 — and finishes at day 10.

Backward pass, working from the day-10 finish: D must run days 8–10, so it must start no later than day 8. B must therefore finish by day 8 (start no later than day 3) — B has zero float. C only needs to finish by day 8 but only takes 3 days from day 3, so it could start as late as day 5 without delaying anything — C has 2 days of float.

Critical path: A → B → D, total duration 10 days. C is not on the critical path — it has 2 days of slack, so a manager who needs to redeploy someone temporarily should pull them off C, not B. This is the concrete, numeric answer a Gantt chart's dependency arrows imply but never compute for you — see Gantt Charts for how the same network looks drawn as bars.

Drawn as a network rather than a table, with the critical path picked out, the same four tasks look like this (float shown in days; in a real project each node would also carry a stable code — an On from a Project Initiation Document, say — so the diagram, the schedule, and the report can all reference the same task unambiguously):

The critical path — the orange nodes, each with zero float — is the sequence a project manager should watch most closely: any slip in A, B, or D pushes the whole 10-day finish out by the same amount. C, in grey, is the one task in this small network where a day or two of delay is genuinely free.

PERT's Contribution: Three-Point Estimation

CPMCPM as described above takes single-point, deterministic duration estimates — "this task takes 5 days" — which works fine when the work is well-understood (DuPont's plant maintenance). PERT was built for exactly the opposite situation: R&D-heavy work where nobody can honestly give a single confident number.

PERT's answer is three-point estimation. For each task, instead of one duration, estimate three:

• O (optimistic) — duration if everything goes right
• M (most likely) — duration under normal conditions
• P (pessimistic) — duration if things go wrong

These combine into a single expected duration via the PERT weighted-average formula³:

Expected duration = (O + 4M + P) / 6

The most-likely estimate gets four times the weight of either extreme — a deliberate choice modelled on a beta distribution, giving a realistic centre of mass rather than a naive average of the three numbers. A companion figure, the standard deviation σ = (P − O) / 6, lets you attach a confidence interval to the resulting date rather than presenting it as a single certainty — e.g. "50% confident by day 10, 95% confident by day 14" — which is precisely the kind of honesty a plain Gantt-chart bar cannot express.

Run the same four-task network through PERT instead of single-point CPM estimates, and you get an expected critical-path duration plus a genuine sense of how much that number could move — useful for anyone (a sponsor, a client, a risk register) who needs to know not just the date but how much to trust it. See Risk Management for the broader discipline of tracking and owning that kind of schedule risk once it's been quantified this way.

Still Relevant, Even in Agile Contexts

BothBoth techniques are older than, and are frequently framed as the opposite of, agile methods — and it's true that estimating a fixed multi-month task network up front sits uneasily with an iterative, adapt-as-you-learn philosophy. But the underlying problems CPM and PERT solve don't disappear just because a team runs sprints. They resurface at a different altitude:

• Release-level planning — when several teams' outputs must converge on a shared launch date, that convergence is a dependency network, and finding which team's slip actually delays the release is a critical-path question.
• Multi-team, dependency-heavy programmes — a single team's backlog doesn't need CPM, but a programme where Team A's API blocks Team B's integration blocks Team C's rollout is exactly the network CPM was designed to analyse.
• Genuinely uncertain estimates — three-point estimation's honesty about a range, rather than a single sprint-velocity number, is a useful habit wherever a single agile team's estimate has to be rolled up into a commitment made to people outside that team.

Neither technique replaces agile practice within a team; both remain load-bearing at the seams between teams, which is where most large projects actually go wrong. For the WBS work that produces the task list these calculations run over, see Work Breakdown Structure. For where the O, M, and P durations that feed PERT actually come from in the first place, and how a team gets better at supplying them over time, see Estimating Effort and Time.

References