The formula
CPM is not one equation. It is two passes over a directed acyclic graph of tasks, where each task i has a duration d(i), a set of predecessors, and a set of successors. You compute four numbers per task and one derived number.
Forward pass (earliest):
ES(i) = max over all predecessors p of EF(p) (0 if none)
EF(i) = ES(i) + d(i)
Project duration = max over all tasks of EF(i)
Backward pass (latest):
LF(i) = min over all successors s of LS(s) (= project duration if none)
LS(i) = LF(i) - d(i)
Total float:
TF(i) = LS(i) - ES(i) = LF(i) - EF(i)
ES/EF: the soonest a task can start and finish if everything upstream goes perfectly.LS/LF: the latest it can start and finish without pushing the whole program right.TF(i): how many days taskican slip before it moves the finish line.TF = 0means the task is on the critical path — slip it one day, slip the program one day.
The critical path is the sequence of zero-float tasks, and it is exactly the longest-duration path from start to finish through the network. That is the whole trick: the schedule is set by the longest path, not the sum of the work.
PERT is CPM with a probabilistic duration for each task, built from three estimates — optimistic a, most likely m, pessimistic b:
Expected duration: te = (a + 4·m + b) / 6
Variance: var = ((b - a) / 6)²
Std deviation: sigma = (b - a) / 6
te: a weighted mean that leans four-to-one on the most likely case — a beta-distribution approximation.sigma: the spread. Sum the variances of the tasks on the critical path to get the variance of the whole program, andsqrtof that is your program-level sigma.
Where you meet it
Integration and test flow at a Redstone contractor. You have twelve tasks feeding an environmental test campaign — fixture build, instrumentation, shaker cal, thermal soak, EMI screen. The vibe test can't start until the fixture and the instrumentation are both done. CPM tells you which of those two, if it slips, actually delays the shaker, and which one has a week of slack to spare.
A program review board slide. The PM stands up with a Gantt chart, and someone asks "if the connector qual slips two weeks, do we still make the ship date?" That is a total-float question. If the connector task is on the critical path, the answer is no. If it has three weeks of float, the answer is yes and you move on.
A test-stand turnaround. Reconfiguring a stand between two hot-fire campaigns is a mini-project — safe the stand, swap the thrust mount, re-plumb, leak check, re-cal. Several of those run in parallel, several are strictly serial. The critical path is the serial spine, and shortening anything off it buys you nothing.
Sequencing a bench build. Even a one-person effort — order the boards, write the firmware, machine the enclosure — has a longest path. The firmware doesn't gate anything if the boards are the long pole. CPM is why you order long-lead parts first.
How it works
The forward pass walks the graph in topological order and asks, at every merge point, "what's the last predecessor to arrive?" That max is the whole engine — a task can't start until its slowest input is ready. The backward pass runs the same logic in reverse with a min, propagating the deadline upstream. Total float falls out of the gap between the two.
The mistake people make is treating every late task as equally dangerous. It isn't. A task with float can slip its whole float and cost you nothing at the finish line. Only zero-float tasks move the date. A program manager who chases every red cell on the tracker instead of the critical-path red cells is burning attention on tasks that were never going to hurt them.
The second mistake is forgetting the critical path moves. It is a property of the current durations, not a fixed set of tasks. Crash the critical path — throw people at it, work weekends — and eventually a different chain becomes the longest one. Past that crossover, more effort on the old critical path does nothing. You have to re-run the passes after every real change; a critical path computed at kickoff is stale by the first status meeting.
Watch the assumptions. Standard CPM assumes unlimited resources — it will happily schedule five tasks in parallel that all need the same one technician or the same one thermal chamber. Resource leveling is a separate, harder problem bolted on top, and it can lengthen the "critical path" beyond what the pure graph says. The network also has to be a DAG: no cycles, no task that is its own distant predecessor, or the passes never terminate.
For PERT, the trap is the central-limit hand-wave. Summing critical-path variances and calling the total normal is only fair when the path has many independent tasks of comparable size. With three lumpy tasks it's a rough cut, and — worse — a near-critical path with high variance can become the real critical path on a bad week, which the deterministic sum quietly ignores. Treat PERT's sigma as a sanity band, not a guarantee.
Numbers to anchor it. Take four tasks: A(3 days) → B(2) and A → C(6), with both B and C feeding D(4). Forward pass: A finishes day 3; B finishes day 5, C finishes day 9; D can't start until the later of the two, day 9, and finishes day 13. Backward pass from 13: D must start by day 9, so C must finish by 9 (it does, exactly — zero float), but B only needs to finish by day 9, giving it 9 - 5 = 4 days of float. The critical path is A-C-D at 13 days; B is the one task you can ignore when the schedule gets tight. A three-point PERT task with a=4, m=6, b=14 gives te = (4 + 24 + 14)/6 = 7 days and sigma = (14-4)/6 = 1.67 days — the long pessimistic tail drags the expected value a full day past the most-likely.
History
The method came out of a corporate scheduling problem, not academia. In December 1956, DuPont — which had a UNIVAC I and was looking for something useful to do with it — framed a "construction scheduling problem" around planning plant maintenance and construction shutdowns [2]. Morgan R. Walker of DuPont and James E. Kelley Jr. of Remington Rand Univac ran a joint effort from late 1956 into 1959 to turn plant turnarounds into a computable network [1][2]. Their result was a graph of tasks with durations, and the observation that the schedule was governed by the longest dependent path through it. They published it as "Critical-Path Planning and Scheduling" at the Eastern Joint Computer Conference in Boston in December 1959 [2][4].
At almost exactly the same time, the U.S. Navy's Special Projects Office, working with Lockheed and Booz Allen Hamilton, built the closely related Program Evaluation and Review Technique to manage the Polaris fleet ballistic missile program [3]. PERT added the three-point probabilistic durations; CPM had used single deterministic ones. Kelley later credited the actual phrase "critical path" to the PERT team, even though his and Walker's method is the one that carries the name today [1][2]. Two teams, two problems — chemical-plant maintenance and a submarine-launched missile — converged on the same graph math within a couple of years, because the underlying question was identical: in a mess of parallel and serial tasks, which chain actually sets the finish date.