Uncertainty: manage for it or estimate better?

Glen Alleman has an ongoing discussion in response to Johanna Rothman's discussion about estimates always being wrong.  In Better Estimating is the Solution to Poor Estimating he talks about some of the underlying causes of uncertainty in projects (normal variability; known uncertainty; unknown uncertainty; and "chaos").  And then he provides some fundamental principles related to this uncertainty.

So Here's Some Fundamental Principles of Cost and Schedule Estimating

• Naturally occurring variance is part of the underlying statistical behaviour of any network of activities.
• Attempting to control or Over Control these natural variances is a waste of time - this is the purpose of cost and schedule margin.
• Mitigate unforeseen uncertainties with risk buy down activities - have a Plan B for everything that needs cost and schedule protection.
• Have an alternative plan for Unforeseen Uncertainties.
• When Chaos emerges, replan the project

I think Glen and Johanna agree in principle, but Johanna's discussion stops at the point where Glen wants to pick up and do something about it.  And I basically agree with what they are both saying.  Point estimates (single-value) of just about anything in business are bound to be wrong.  The struggle I have is that most people approach this problem by saying, "let's get better at estimating."  Estimates are always going to be estimates and are always subject to something like Glen's Fundamental Principles.  The title of Glen's article had me rather worried.

There is natural variance in the business world.  Rather than assuming it isn't there or trying to over-manage it (point 2), businesses need to find ways to manage it appropriately. 

In my work in Theory of Constraints, the overwhelming approach to variability is to acknowledge it and manage it with buffers ("shock absorbers").  This applies on the manufacturing shop floor, in the supply chain, and in projects.

The beauty of buffer management in practice is that it can actually help you direct your efforts at reducing actual variation and waste in the process in question.  What is the frequent cause of significant buffer consumption?  Attack that with a focused effort and the system will improve overall.

I'd also like to highlight Glen's second point about over-control of variability.  In project environments, the typical response to variability or unexpected delays is to ask people to tighten down their timelines and push them harder to hit their dates - usually with explicit reward/punishment mechanisms.  This has the exact opposite effect of what you want, which is a successfully completed project.  Tightening control at the individual task level causes people to pad their estimates, so that they are sure to hit their dates.  And even when they come in a little early, there is usually no motivation to report completion.  And there will always be delays (see the principles above), which means projects rarely come in on time.

The general direction of the solution is back to this idea of buffers and allowing variability to happen.  Loosen the local control without letting the project as a whole go awry.

[Photo: "Schrödinger tomatoes" by funadium]