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]2
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.