This Focused Performance Weblog is a "business management blog" containing links and commentary related primarily to organizational effectiveness with a "Theory of Constraints" perspective. TOC is noted for its applications in Project Management and Multi-Project Management (Critical Chain) and Operations Management (Drum-Buffer-Rope), as well as in Marketing, Strategic Planning and Change Management (TOC Thinking Processes). If you are on an archive page, current postings are found here.
Saturday, January 31, 2004
Estimates and Buffers in Critical Chain (Part 5 - Using Buffers) -- OK, folks. We're in the home stretch of this series on buffered promises, buffer sizing, estimating, and buffer management in Critical Chain-based project management (CCPM). Putting it together has raised a bunch of other thoughts for your truly, but enough's "good enough," for now; that is, it'll be enough after this final installment on the mechanics of Buffer Management. Let's start with a bit of history on the evolution of those mechanics...
(1) Way back in the early days (1992-97) of CCPM, Buffer Management started with a simple (many now say simplistic) tripartite "red-yellow-green" process in which the buffer was divided into three equal parts for the life of the project. If consumption of the buffer was less than 1/3 of it's original size, project health was considered OK (green). As it crossed the 1/3 line into the middle (yellow) third, it was deemed that appropriate action was to "watch and plan" possible recovery actions that would be implemented if the project deteriorated to the extent that the 2/3 consumption (red) line is crossed. The idea of delaying implementation of recovery action was to avoid unnecessary "tinkering" with the system and distraction of the project team.
(2) A refinement of this approach, to catch with the possibility of major problems going too far too quickly, added a watch on the trend of buffer consumption; sort of a SPC-like approach. If the rate of project buffer consumption proved to be consistently faster than the rate of completion of the critical chain, a "yellow-zone" watch and plan state would be triggered. If that trend continued for a number of reporting periods, the developed recovery plan would be implemented.
(3) Later, recognizing the fact that as the project approaches completion, less buffer is required to protect against uncertainty, the original straight division of buffer into thirds - (1) - transformed to a sloping set of thresholds, with larger and larger "green" portions of buffer as the more of the project completed. (note that the slope on a chart can go in either direction -- up or down -- depending on whether your tracking buffer consumption against chain completion or remaining versus needed buffer.)
(4) A variation on the sloping green-yellow-red concept - (3) - replaces straight-line borders with borders that reflect the varying amounts of buffer needed to protect the remaining tasks.
(5) These "fever charts" have also been adapted for quick views into the relative health of multiple projects.
One of the things that seems to vary from implementation to implementation is the positioning of the thresholds relative to the buffer size. The tradition of splitting the buffer into three equal components is strong with consultants and authors who tend to respect the theory associated with avoiding unnecessary tinkering with the project. However, in reality, I have yet to implement the process in which there is not a strong pressure to implement "buffer recovery" actions as soon as they are discovered, and to tell the truth, that's tough to really argue in most cases in which projects are a mix of date promises and ASAP efforts. As a result, sometimes the yellow zone is shrunken or even eliminated altogether.
But this still begs the question as to where the border between green and yellow should be. What I like to recommend is to take advantage of the strengths of the two buffer-sizing processes, sizing the buffer with the "Half-the-Safety" and defining the yellow zone at the "Square-Root-of-Sum-of-Squares" size. This results, in typical real life chains, in a nice comfortable green zone to allow the project to run while absorbing Murphy's Law before the SSRS 85-90% confidence point gets broken. For due-date driven projects, I also prefer a "sloping" approach, as in (2), (3), or (4) above, to allow a healthy project run without distraction or pressure to tinker into it's later life.
(Unfortunately, the CCPM software packages I've worked with recently don't easily mix "Half-the-Safety" with "SRSS" calculations, so therefore require a bit of simple Excel manipulation to accomplish this. That said, setting the green-yellow threshold at about the traditional 1/3 position works more than -- dare I say -- "good enough.")
For that matter, all of the above described buffer management methods tend to be based on the "Olympic Stadium" example; the kind of projects that have promise dates that are being protected by the buffer and buffer management, and that accrue little benefit from considerably earlier finishes. However, when one shifts to an ASAP (the sooner we finish, the sooner we can ring a cash register) project environment, the emphasis also needs to shift -- from the health of buffers protecting not-to-exceed dates to projections of anticipated completion and to the encouragement of focused performer attention for maximum speed with quality. Since many of these usually have some associated "not-to-exceed" date attached to them anyhow, the basics described above can still apply, but with a bit more emphasis is on "when can this get done?"
The original buffer provides an initial range of possible completions. As the project proceeds, learning and experience refine expectations. By performing rolling recalculations of the "buffer required for remaining work" (for which my preference is the more aggressive SRSS method), we get better refinements (narrower ranges) of when we can expect the project to complete. Also, by focusing on the movement of that range in time or the SPC/trend view of buffer consumption, we can be forewarned that things might be going awry, schedule speed-wise.
Projects are exercises in turning uncertain events into reasonably certain promises. The processes common to Critical Chain-based project management, 2-point range estimates, buffered schedules and promises, and buffer management of project execution all explicitly deal with the inevitability of uncertainty, variation, and risk. They can be used to good advantage for protecting promises and realistically projecting project completions.
This concludes this little (???) tutorial on buffers and estimates in Critical Chain environments. A number of auxiliary thoughts and ideas popped into my head as re-reading and writing these installments, which will probably arise in future weblog postings. (One for example, is the relationship of "old wine" PERT scheduling to Critical Chain's "new bottle.") Also, you'll notice that this last installment included some graphics. I might go back at some point and put pertinent pictures in preceding posts as well. I'll let you know if/when I do.
If any of these entries have triggered questions or comments, please use the comment links to submit them so we can turn my monologue into a dialogue.
View Frank Patrick's profile
