Eliyahu M. Goldratt has found a nice little niche in the business education market, churning relatively simple management concepts into a genre he calls "business novels." Now that I've read The Goal and Critical Chain, I have to say as novels, they are utter failures. The business content is useful, but the artistic conceit is a definite obstacle to their instructive value.
If you haven't read the book, but want to know what it's about, read this page, and the first reference (at least) under "Further Reading" below. If you're still desperate for some amusement, go ahead and read the silly thing.
The starting point was presented in another of Goldratt's "novels," The Goal, dealing with manufacturing: In production flow, one bottleneck determines throughput, and a sequence of processes and their interaction with the bottleneck determine lead time. Here's the recipe for improvement:
The same idea can be applied to project management, except now the constraint is the critical path (CP). "Processes" are tasks or activities.
An additional dimension is created by considering the people (Goldratt calls them "resources") who perform the tasks. The abstraction of a PERT chart can conceal the fact that the same person might be required for multiple activities. The true constraint of the project can be a critical chain, involving the constrained person.
(This amounts to putting more dependency information into the PERT network, and simply allows better determination of the actual CP. But he wouldn't have sold any books titled Critical Path. Further, PERT analysis depends on resource levelling to be truly useful; and the data required for levelling is the same information required to determine the critical chain.)
If I put it in bold face, would you have read that last paragraph? Reread it now, and save yourself and your project a whole bunch of time and effort.
Goldratt emphasizes three important ones:
Improve performance by eliminating the padding (or "safety") in individual task estimates, and creating a combined CP buffer which is put at the end of the CP. This intended to directly address delay items 1 and 3 above.
If a task is finished "early" (which could mean "at the median estimate" if estimates weren't padded), the project completion slides earlier. If it finishes late, subtract the overage from the CP buffer as "used." Actually, you could also account for the "unneeded buffer," when a task is completed, and gradually reduce the CP buffer; the size of the needed buffer is directly related to the number of tasks (and the complexity of their interrelationships).
Paths that are subsidiary to the CP should have buffers inserted after their sequence of tasks, and before connection to the CP; just like a queue of materials at the bottleneck process ensuring it can keep working.
The critical chain idea acknowledges that tasks requiring constrained resources (maybe the combination of individual + skill makes it less dehumanizing to use that term) also require buffer ahead of them to ensure that nothing delays the CP. Multitasking is inevitable, but as long as the increased leadtime isn't in the CP, there is no penalty.
If everyone would just work harder, we'd get done sooner, right? Well, no, not unless they're involved in the critical path (or helping others on it, or making sure nothing delays it, etc.) The simple production mentality of "stay busy, or else," can work against us, if we stay busy with the wrong things. At best it will just be wasted effort (from a project point of view anyway). Rather than being done early, people may expand tasks to fit the time allotted.
Put another way - don't confuse activity with progress.
To the extent that milestones are fixed dates by which tasks need to be completed, they can exacerbate the deadline effect. They tend to conceal opportunities available from getting tasks done early. Goldratt recommends doing away with the altogether. Another approach is to keep them tied to key connection points on the critical path, and let them slide as needed if buffer is required.
If "completing by the deadline" is given paramount importance, people will do their best to set deadlines they know they can meet. This is where all that task by task padding comes from, and why Goldratt recommends doing away with milestones and managing the project buffers instead.
The abstractions of project management are instantiated by having portions of the project supplied by other firms. That is, the simple metrics of "minimize cost," and "deliver by this date" may be implicit for internal teams, but they have to be explicit for vendors, and there is less opportunity for fine tuning, and more motivation for protection, as described above.
The importance of schedule, and ways to improve it, can be explored by negotiating tradeoffs between it and cost. What cost incentives for early delivery will they respond to? What cost penalties for late delivery will they accept? More importantly, what penalties should we be seeking to impose to capture our own opportunity costs and the expenses of a schedule slip?
If they depend on inputs from us, find that out, and then find out how their delivery can be improved by better information of when we will provide the crucial inputs.
Since small delays can create big impacts on profitability, improvements in delivery schedule will often be worth a premium. Don't step over a dollar to pick up a dime, eh? But focus this effort where it matters - in the critical path, and the critical chain dependencies within it.
A former HP colleague of mine has also done a writeup of the project management ideas, with a "recipe and explanation" approach: Take a look at Project Management Revisited: The Theory of Constraints.
Robert C. Newbold seems to have made an industry out of the concepts with ProChain Solutions, Inc., where you can find a long list of papers on this topic.
Finally, you don't have to take my word for the critical assessment; you can see what reviewers on Amazon.com had to say.
This review was originally published within HP's intranet in April, 1998.
Tom von Alten tva_∂t_fortboise_⋅_org