Isegoria

I’ve been discussing Eli Goldratt’s third business novel, Critical Chain, and established project management techniques, like PERT.

One subtle issue with charting the critical path of a project is that the individual task estimates, which start out as distributions — defined by optimistic, most likely, and pessimistic estimates — get boiled down to one-dimensional expected numbers.

This lets us define a critical path, but — for simplicity and clarity’s sake — it ignores the potential for other paths to become critical.

Let’s say we add up all the variances along our critical path — Tasks A, C, and F, in our example — and they’re fairly small, so that our critical path has a duration of 7 ± 1 days. From that we might assume that our project has a 98-percent chance of finishing in 9 days — but what we’ve calculated is the chance that the original critical path will finish in 9 days.

What if the non-critical path along Tasks B and E takes 6 ± 2 days? We only have a 93-percent chance of finishing that path in 9 days.

Perhaps that seems academic in our toy problem, but real projects with many dependencies can demonstrate an alarming cascade effect, where every task seems to be waiting for something else to get done.

Returning to our toy problem, what happens if we replace Task A with three identical tasks, Tasks A1, A2, and A3? Our PERT analysis does not change at all, but clearly the fact that they average three days each does not mean that the dependent Task C gets to start after three days. It has to wait for the slow-poke.

Another academic complaint about PERT analysis is that it uses beta distributions, which may or may not reflect the actual distributions, and that it assumes that those beta distributions are numerous enough to sum to a fairly normal distribution, via the central limit theorem.

Less academic is the concern that the task durations are not independent. If it takes longer than planned to design a component, that might very well imply that it will take longer to develop a prototype, to produce it, to test it, etc. If that’s the case, then pooling all the safeties into one buffer at the end won’t reduce the total safety needed — but it should still reduce the threats from Student syndrome and Parkinson’s Law.

A bigger issue still is that people are notoriously bad at estimating task durations, and they are notoriously overconfident in their ability to estimate. The optimistic and pessimistic estimates are supposed to book-end a range that covers almost all possibilities — 99 percent — but far more than one percent of tasks fall outside those estimated ranges.

As I mentioned earlier, Eli Goldratt’s third business novel, Critical Chain, deals with project management, which has existed in its modern form since the 1950s.

One obvious issue with charting the critical path of a project is estimating all the task durations. Sure, for some projects all the tasks are well understood, but for many the tasks are new and untried.

In fact, complex design work that “should” take one month might take two, or three, or four months. Less likely, it might resemble an old, already-solved problem, and it might only take two or three weeks to finish.

So when the project manager asks a team member how long a task will take, what should the worker say? A young hotshot might give the mode of the distribution — “Yeah, I should be able to get it done in a month.” After a project or two, our chastened young worker starts giving numbers closer to the median of the distribution — estimates with a 50-50 chance of being long enough.

What the project manager probably wants is something closer to the mean of the distribution, or the expected duration of the task, which is greater than either the mode or the median in our skewed distribution.

On the other hand, the grizzled worker probably gives an estimate with plenty of safety — anyone who has missed a deadline knows it’s better to under-promise and over-deliver.

In fact — turning toward Critical Chain — that is one of Goldratt’s key points: each individual task estimate has plenty of safety built in. In fact, each layer of management adds its own safety, too — no boss wants his team to come in late. Then upper-level management doesn’t like the cumulative estimate, so it has all the task estimates cut — but the workers know to boost their own task estimates even more to account for that.

So why doesn’t the project come in on time? Because no one finishes early. Either they procrastinate, because they have “more than enough time” to finish the task — Student syndrome — or they use the extra time to add bells and whistles — Parkinson’s Law.

Delays accumulate, while advances do not.

So what does Goldratt recommend? He recommends cutting out most of the safety from individual tasks, then pooling the collected safety into a project buffer — which does not need to be as big as the collected safeties, because delays and advances will cancel out.

Goldratt also recommends a feeding buffer anywhere a path merges with the critical path — but our sample project is a bit of a degenerate case, with no paths merging into the critical path until the finish pseudo-task.

I don’t know if Goldratt thought that this notion of using accurate estimates and pooling safety buffers was a new idea, but it’s found in old-school PERT — the real version, if not the version most people use — where each task is assigned not an estimate but three estimates: optimistic (or best case), most likely, and pessimistic (or worst case).

These estimates are then fed into formulas based on the beta distribution, which, with the right parameters, looks an awful lot like the log-normal distribution pictured above, but with the appealing attribute that it has a well-defined minimum and maximum.

The formulas assume six standard deviations between optimistic and pessimistic:

Expected = (Optimistic + 4 x Most likely + Pessimistic) / 6
Variance = [(Pessimistic - Optimistic) / 6]²

It’s the expected times that determine the critical path and the cumulative variance — or the square root of the cumulative variance — that determines the project buffer. (PERT assumes that there are enough tasks in the critical path that the many beta distributions sum to a fairly normal distribution.)

Whether it’s new or not, the takeaway message is this: Don’t ask for a single-number estimate but for a distribution, and don’t pad each estimate, but pool the safety buffers into larger feeder buffers and project buffers, so that advances can cancel out delays.

As I mentioned earlier, when I read Kevin Fox‘s Blue Light anecdote, it spurred me to go back and read some old Goldratt books I hadn’t read yet, including his third business novel, Critical Chain.

Critical Chain doesn’t look at production or logistics but at project management.

Modern project management goes back to the 1950s, when Booz-Allen & Hamilton developed the Program Evaluation and Review Technique, or PERT, with Lockheed for the Polaris missile submarine program, and DuPont developed the Critical Path Method, or CPM, with Remington Rand for plant maintenance projects.

The basic idea behind these methods is to diagram out the various tasks within the larger project, along with their interdependencies and durations.

Two pseudo-tasks, start and finish, make the analysis clearer but don’t represent real work.



The first step in the formal analysis is to compute the early start and early finish dates for each task — the earliest it could start, given all its dependencies, and the earliest it could then end, given its duration — starting with the start pseudo-task and working to the right.



The second step in the formal analysis is to compute the late start and late finish dates for each task — the latest it could finish, without delaying the larger project, and the latest is could then start, given its duration — starting from the finish pseudo-task and working backward to the left.



Once you’ve done all that — or have made a computer do all that — you can see which tasks are on the critical path, with no slack. Any delays to any task on the critical path will delay the larger project. Any delays to any task not on the critical path will not delay the larger project — until all the slack for that task gets used up.

In The Haystack Syndrome, which I thought I was done discussing, Goldratt presents a production and marketing problem with a less-than-intuitive solution:

If you read much Goldratt, you know he’s always talking about constraints, which is a clue to how to solve the problem — it’s a thinly disguised linear programming problem.

In this day and age, solving linear programming problems is remarkably easy — if you know how to formulate the problem for Excel’s Solver add-in. This Google spreadsheet lays out the basic problem, but Google hasn’t built a Solver analog into it’s spreadsheet tool just yet.