Lean Six Sigma, CPM and PERT

These three are usually taught together, which makes them look like variations on a theme. They are not. They answer two unrelated questions, and knowing which one you have is most of the work of choosing between them.

Lean Six Sigma is for a process that repeats: an assembly line, a claims desk, an onboarding sequence, a monthly close. Because it repeats you can measure it, and so talk about its average and its spread. It attacks two defects in such a process: work that adds no value, and results that vary more than the customer will accept.

CPM and PERT are for a project that happens once: a building, a plant shutdown, a satellite, a regulatory submission. There is no average to measure because it has not been done before in this exact form. What there is instead is a set of tasks with hard dependencies, and the interesting question is which of those tasks control the finish date. Reach for a critical path diagram when the real problem is a wobbly recurring process and you get a beautiful schedule for an unreliable machine.

The two halves have separate origins and separate enemies.

Lean comes out of the Toyota Production System, formalized by Taiichi Ohno in post-war Japan. Its target is muda, waste: anything the customer would not pay for if they could see it. The classic list is seven kinds, usually taught as transport, inventory, motion, waiting, overproduction, overprocessing and defects, with an eighth (unused talent) added later by most practitioners. Lean's instinct is to remove steps and let work flow, and its measure of success is speed and cost.

Six Sigma comes out of Motorola in the 1980s, where the engineer Bill Smith is generally credited with naming it, and spread widely after General Electric adopted it under Jack Welch in the mid-1990s. Its target is variation, and its name is a statistical goal: a process centered well enough inside its tolerance limits that defects become rare, conventionally stated as 3.4 per million opportunities once the usual allowance for long-run drift is made. Its measure of success is consistency.

They merged because each was weak exactly where the other was strong. Lean makes a process fast but has no statistical machinery for finding out why one shift in five produces bad output. Six Sigma makes a process consistent but will happily make a wasteful step consistent rather than delete it. Combined, the question becomes: remove what adds nothing, then stabilize what remains. The name was popularized in the early 2000s, notably by Michael George's book Lean Six Sigma, and the training ladder came with it: yellow, green and black belts, with master black belts and champions above them. That ladder is the honest signal about cost. A method needing a certification hierarchy assumes a process large enough to justify one.

The critical path method was developed in the late 1950s by Morgan Walker at DuPont and James Kelley at Remington Rand, for scheduling plant shutdowns where a day of downtime had a known and painful cost. The idea is arithmetic rather than statistical.

Lay out every task with its duration and its predecessors. Some chains are longer than others. The critical path is the longest chain of dependent tasks from start to finish, and its total duration is the shortest possible duration of the whole project. Everything else has room to move.

That room is called float, or slack. Total float is how long a task can slip before it delays the project end date. Free float is how long it can slip before it delays the task immediately after it. Tasks on the critical path have zero float by definition: if one of them slips a day, the project slips a day.

That gives the one management instruction the method exists to give: adding people, money or attention to a task that has float buys nothing. The finish date moves only when a task on the critical path moves.

Two consequences catch teams out. First, the critical path is not fixed: shorten it enough and a different chain becomes the longest one, so it has to be recomputed after every material change. Second, CPM in its original form assumes each duration is a single known number and ignores resource contention entirely. Eliyahu Goldratt's critical chain method, from his 1997 book Critical Chain, is the best-known attempt at the second gap: schedule around the people and equipment tasks compete for, and pool safety margin into explicit buffers instead of hiding it in every estimate.

PERT, the program evaluation and review technique, was developed in 1958 for the US Navy's Polaris missile program, in parallel with CPM and independently of it. Its contribution is to admit that durations are not known numbers.

Instead of one estimate per task it asks for three: an optimistic duration O, a most likely duration M, and a pessimistic duration P if the plausible things go wrong. The expected duration is a weighted average giving the most likely value four times the weight of the two extremes:

• Expected duration: TE = (O + 4M + P) / 6
• Standard deviation: SD = (P - O) / 6
• Variance: V = SD squared, summed along a path and square-rooted to get that path's standard deviation

The weighting does something specific. Durations are not symmetric: a task can finish a little early but it can overrun enormously, so the distribution has a long right tail and its most likely value sits below its mean. Weighting the mode at four pulls the estimate slightly toward the pessimistic case, which is usually the direction reality goes.

The standard deviation then lets you talk about confidence rather than a single date. On the normal approximation PERT relies on, roughly two thirds of outcomes fall within one standard deviation of the expected duration and about 95 percent within two. A date given as twenty-nine days plus or minus three is more useful than a flat twenty-nine that is wrong.

PERT also has a systematic bias worth stating plainly. Because it computes the distribution along the critical path only, it ignores the chance that a near-critical path overruns and becomes the critical one. Whenever several chains converge on a milestone, that milestone waits for the slowest of them, so the real expected finish is later than the arithmetic suggests. This merge bias makes PERT optimistic more often than pessimistic; Monte Carlo simulation over the whole network, which most scheduling tools now offer, is the standard remedy.

Take a six-task project: relaunching a documentation site. Durations are in working days.

There are two paths through the network. A to B to E to F takes 5 + 8 + 4 + 3 = 20 days. A to C to D to E to F takes 5 + 6 + 10 + 4 + 3 = 28 days. The second is longer, so it is the critical path and the project is 28 working days.

The content audit is the interesting task. It finishes on day 13, but E cannot start until D also finishes on day 21, so B carries eight days of float. If the writer doing the audit asks for another week, it costs nothing. If the designer doing task C asks for another week, it costs the project a week. Both requests sound identical in a status meeting; the network is what tells them apart.

Now apply PERT to task D, the one everybody is nervous about. The team estimates six days if the component library holds up, ten days most likely, and twenty days if the templates have to be rebuilt against a new design system. Then TE = (6 + 40 + 20) / 6 = 11 days, and SD = (20 - 6) / 6 = 2.3 days.

Two things follow. The expected duration is eleven days, not the ten everyone has been repeating, because the pessimistic tail outweighs the optimistic one. And the spread on that one task is over two days, so the exact 28-day date commits to something the arithmetic does not support. Substituting the expected value makes the critical path 29 days, plus or minus a few, with nearly all the variance in a single task, which is also the instruction about where to reduce risk first.

All three are expensive in the same currency: up-front modeling and continuous maintenance. A network diagram is useful only while it matches reality, and a DMAIC project spends weeks measuring before it changes anything. That cost is repaid when the work is large, dependency-heavy or repeated enough to amortize it.

The pattern is consistent. Construction, shipbuilding, plant turnarounds, aerospace, logistics and regulated infrastructure use CPM and PERT because their dependencies are physical, their durations are informed by decades of comparable work, and a slipped date has a price on it. Manufacturing lines and high-volume service operations use Lean Six Sigma because the same sequence runs thousands of times and a fraction of a percent of defect rate is money.

They do not earn their keep on a five-person team shipping software every two weeks. The estimates are guesses rather than informed ranges, the dependency graph is redrawn every sprint, and maintaining the model costs more than the model reveals. That work is better served by the empirical approaches in Agile, Scrum and Kanban: short cycles, work-in-progress limits, and measured throughput instead of predicted durations. Kanban's flow metrics are a lighter descendant of the same Lean thinking, minus the certification ladder.

Most people are in the middle ground, and the useful move there is to borrow the concepts without adopting the apparatus. You can find a project's critical path on a whiteboard in twenty minutes and never draw a formal network. You can ask for three estimates instead of one on the two tasks that worry you. You can run Measure and Analyze on a recurring process without chartering anything. The float arithmetic is automated in most serious planning software, covered in task and project management tools, though doing one network by hand is worth it once.