This Focused Performance Weblog started life as a "business management blog" containing links and commentary related primarily to organizational effectiveness with a "Theory of Constraints" perspective, but is in the process of evolving towards primary content on interactive and mobile marketing. Think of it as about Focusing marketing messages for enhanced Performance. If you are on an archive page, current postings are found here.
Thursday, January 29, 2004
Estimates and Buffers in Critical Chain (Part 3 - Estimates are Conversations) -- The firsttwo parts of this "tutorial" on estimates and buffer sizing in Critical Chain schedules addressed the use of "open" buffers as an explicit acceptance of schedule uncertainty and several common methods for deriving buffer size. This installment will introduce the recent commentary by Eli Goldratt that triggered the series, and deal with the implications of Goldratt's proposed "Half the Chain" approach to buffers versus the other two, which rely on 2-point range estimates.
In a recent piece in CC@Work (a webletter of Critical Chain software provider Realization), the author quotes Dr. Goldratt on the use of 2-point range estimates (which, with a nod to the nominal confidence levels that they cover, he calls 50/90)...
"50/90 is useless. In projects, no one will ever know what the distribution curve of task duration looks like for any task. Moreover, with chaos all around them, people cannot distinguish between the real variability of a task and the variability resulting from chaos...When implementing CC for the first time, the way to get safeties out of the estimates is to take the current task estimates and cut them in half. As an implementation matures, people get experience in giving tighter estimates and you want to cut the estimates by a number that is less than half."
Let's get the semantics out of the way first. While he has a point regarding the unknowable distribution of possible task durations calling into question the reality of 50% and 90% confidence levels of these estimates, many of us use those numbers (if we do) merely as additional description of "aggressive/average" and "safe/commitment-level" estimates in introducing Critical Chain concepts to a team or organization. The words that most of us put around the concept clearly admit the "unknowable" nature of the estimating process. With it's basis in Goldratt's early work on the subject, "50/90" has, at best, simply become an easy-to-remember shorthand for the 2-point range estimating process that is in common usage in many, if not most, Critical Chain implementations. At worst, it's an unfortunate, possibly distracting carry-over from the early days.
Regarding "real variability from a task" versus "variability resulting from chaos," there is little point at drawing that distinction unless and until the chief causes of "chaos"-driven variability can really be separated out (which partially occurs in successful CCPM implementations). In the early goings of a Critical Chain implementation, they are often both included in the "safe" estimate, at least to the extent the experience and past pain is not overcome by the promises inherent in the training on the approach. The distinction simply doesn't matter regardless of the process used for estimation and buffer sizing. (And anyhow, in execution, the work is going to take as long as the work takes, or is allowed to take, or is forced to take. If the performer behaviors that are the raison d'etre of CCPM are effectively effected, then the organization's learning will allow the recognition of the two sources of variability, but in all likelihood, not before then.)
All that said, 50/90 [2-point range] estimates are far from "useless!" They are the basis for important conversations in the planning process about the risks and opportunities related to the tasks being estimated. The difference between the two estimates highlight opportunities for and potential value of mitigating or even avoiding foreseeable risks associated with the tasks in question. Yes, at that level, they may constitute "noise" in the larger scheme of things if the appropriate work practices are not fully embraced, but there is, in the process, the opportunity to discover meaningful dependencies and to highlight potentially wasteful practices that can be eschewed.
But even more important than the numbers, the conversation that surrounds the range estimating process is important to show the respect for the team...respect for their concerns about the work...respect for their experience...and respect for them as members of the team. Goldratt's recommended practice of "cutting estimates in half" can be perceived as an affront to the team and its experience, and become an obstacle to a smooth implementation of non-trivial "cultural" changes that accompany the implementation of the Critical Chain methodology.
Finally, in the cited comments, he suggests that as "people get experience in giving tighter estimates...you want to cut the estimates by a number that is less than half." How much less? Who determines the necessary experience? When is it appropriate to do this? How much tighter? There is nothing in this "Half the Chain" approach that addresses these questions. At least with the methods that use range estimating, there is a smooth path for tightening or loosening estimates as appropriate and as performers and estimators become accustomed to working in the new environment that CCPM allows.
The citation of Goldratt's opinion continues...
"Along the same lines, advanced statistical analysis to optimize safeties is an exercise in futility. Moreover, since delays propagate across chains in execution (through resource dependencies), buffer sizes should reflect system-level variability, not task-level variability...Buffers should be 1/3 of the total lead-time or half of the length of a chain. This should be consistent across projects. So, next time you are tempted to use 50/90 or some statistical analyses, beware. Simplicity, not complexity, is the answer."
The mention of "advanced statistical analysis" is a swipe at the "Square Root of Sum of Squares" approach. Again, Eli is attacking the idea that the numbers have real meaning as numbers, rather than as views of possibilities. And again, he is assuming that system-level variability is excluded from the range-estimating process while it is very much embedded in the minds of people offering the "safe" estimates.
But to say, by flat out edict, that "buffers should be 1/3 of the total lead-time" regardless of the lesser or greater variation that may be encountered in a project smacks of black-box, top-down, top management versus project manager versus team, command-and-control mindset that is not an appropriate approach to guiding today's project performers (formerly known as resources). Sure, I get a bit nervous when buffers approach 1/4 of the lead time, and yes the 1/3 "rule of thumb" is a good guide for assessing the estimating process, but who is to say that a highly uncertain discovery or problem-solving project shouldn't have a buffer that approaches 1/2 of the lead time?
Introduced appropriately, with a sense of realism about whether the estimates have meaning as specific numbers or as "good enough" views of expectations, and with some minimal training regarding the differences between safe/commitment estimates and aggressive/average estimates, the methods that rely on 2-point range estimates provide as good, if not better (whatever that means) project promises without the buy-in and teamwork drawbacks of the "cut-the-estimate-in-half Half-the-Chain" approach. The "Half-the-Chain" approach may have proven "good enough" in early tests of CCPM, and probably still does technically work, but there is much more to be gained from the conversation that is at the heart of the range-estimating process. That said, you might have noticed the non-meaningful difference in the "Half the Chain" and "Half the Safety" in Part 2's examples. If the buffers are usually the same, and the latter approach is more team-friendly, I'll take the latter every time.
While this discussion might be seen as an interesting "difference of opinion" among Critical Chain practitioners -- actually, I suspect it's a difference of opinion between primarily Dr. Goldratt and most practitioners in the field -- the real concern that it raises for me comes in the message from Realization that closes the piece...
"Realization has introduced "buffering policy" in its software that helps institutionalize consistent buffering. Top management specify how much buffer projects should have, and the software makes sure that projects conform to that policy as they enter execution. In addition, we are seriously considering taking the option of two estimates (50/90) out from our CC Planning module by Q3 of 2004. If you have any feedback or concerns, please write to us at email@example.com."
In the name of "simplicity" such top management policies are troubling for the same "black-box, top-down, top management-driven" concerns I raised above. Yes, there should be a consistent means of planning, promising, and performing projects in an organization. But there doesn't have to (shouldn't) be a consistent absolute buffer proportion across all projects.
While I have no concern that other CCPM-savvy software solutions (cc-Pulse, Sciforma's PS8, and ProChain) will abandon the common sense and teamwork-friendly 2-point estimate processes, the combination of a major player doing so with the "blessing" of Dr. Goldratt can only muddy the waters for the further acceptance and growth of CCPM as it approaches a critical mass of acceptance beyond the early adopters.
I'd be very interested to hear comments from other CCPM practitioners, proponents, or users who might be reading this. Please use the comment link at the bottom of this entry for your thoughts. I would particularly like to hear from users of Realization's Concerto software to see if their possible direction down their proposed path has had any impact on the way projects are planned in your organization. Maybe you can shed a little more light on what they are thinking. If my concerns resonate with other CCPM consultants, educators, and users, you might also want to share your thoughts with them via the email link mentioned above.
Now that I've dealt with the reason for this series with this rant, the next and last part of it will go into more on the interpretation and uses of buffers as well as some thoughts on possible different applications of two range-estimate-based methods.