Happy New Year! I ended 2013 with a flurry of book-reading, and this is another entry from that whirlwind of reading.
Eli Goldratt’s Critical Chain is another of his business novels, published in 1997 - about 10 years after The Goal. I have read the book previously, but apparently it has been much longer than I realized. There were elements here that I didn’t remember at all - most of the story line in fact. There is even a couple of chapters of discussion of the roots of TOC to this point (Drum Buffer Rope, Throughput Accounting, and the Thinking Tools). And while I am familiar with the logical build-up of CCPM - the traditional problems of project management, their causes, and the elements of the solution - the way Goldratt presented it made me step back and think a bit about how I have been introducing CCPM in consulting engagements.
The setting for Critical Chain is a university, rather than a business. This way main character, a business school professor, gets to draw on the project management experiences of many students from many backgrounds to build up the common challenges and the Theory of Constraints way of thinking about projects. The way it is presented in the book is that CCPM is created through logical thinking about the situation over the course of a semester.
A notable difference is that by the time of writing this book Goldratt and others had developed Theory of Constraints more fully, and the development of Critical Chain Project Management in the book is more logical. Either that or I am so deep into CCPM these days that I could really see some interesting points. Also, like many business novels, it reads quickly, though there are aspects that merit pausing and thinking, particularly as I have been working with these concepts for years.
Specifically, I was interested to see that the path of thinking started out focusing strictly on the logic of the project: which tasks must be completed before others can start and where are the integration points of multiple legs.* With the basic critical path schedule, Goldratt has the characters spend a lot of time talking about task estimates and safety and the fact that nearly all safety gets lost in execution. These are things like Parkinson’s Law, Student’s Syndrome, and integration points. And a lot of local efficiency thinking that ends up killing the overall project. The characters come up with the idea of trimming task safety, buffering the project, buffering integration points in planning. And then in execution they come up with the idea of using remaining duration estimates (not % complete) for tasks, and a simple early-warning system for the task participants that critical tasks are coming up.
Goldratt doesn’t use the term "full kit," but that is what a lot of the advance warning mechanism sounded like. Goldratt also perfectly described in one of his vignettes the importance of full kit. In this case it was visiting a printer for a job:
They [quote] you four weeks. You come with all the needed final material in your hands, and you are willing to pay more, and they agree to do it in four days.
While there is the aspect of money here, the thing I really clued into was the fact that “all the needed material” was available, rather than the default assumption that the handoff would be bad, and the printer would need more information before they could really get started. This is full kit.
It was only once Goldratt had developed the basic problems of projects and the basic solution that he added the additional aspect of resource constraints. The same resource type might be needed in multiple legs of a project, causing resource contention (multitasking) within the project. The solution is to account for resources in the project plan. This is one of the central elements of CCPM: the critical chain of the project is the longest path through the project that accounts for resource contentions.
With resource contention dealt with inside a project, the next step is to look at resource contention across projects in a similar way. Ensure that the key resource of the organization is scheduled, and then schedule the rest of the work around that resource. I thought this brief section was a great introduction to the concept of pipelining.
Of course, there are some ideas here that haven’t ever taken root. The idea of a resource buffer to manage interactions for constraint resources hasn’t been applied in CCPM software I have used in favor of using project and feeding buffers. And the idea of expanding Throughput Accounting with the idea of “flush” to try to monitor the value of projects in units of dollar-days never turned into anything solid within the TOC community. (It used to come up on the TOC discussion lists from time to time.)
* Interestingly, there was no discussion of the quality of the logic. I find in many CCPM implementations that people are often challenged with devising a project plan that has the correct logic sequencing, much less conversations about task durations, multitasking and resource contentions.