Some constraints on the theory of constraints
taking a critical look at the critical chain
Taking a Critical Look at the Critical Chain
by Jeffrey K. Pinto
DR. ELIYAHU GOLDRATT'S THEORY of Constraints (TOC) and its subsequent application to project management, the Critical Chain, has recently emerged as one of the most popular new approaches to the management of projects. The theory and its direct applications have been adopted by an increasing number of corporations, including such luminaries as Lucent Technologies, as a method for achieving both greater speed and reliability in the development of projects. Indeed, recent articles and letters to the editor in the Project Management Journal and PM Network extol the TOC as one of the most important breakthroughs in managing projects.
The Next Big Thing needs to be perused with a skeptical eye in order to fully appreciate its valuable aspects.
The attraction is understandable; TOC and the Critical Chain are based on a lucid and compelling analysis of some of the key problems that continue to plague our ability to better manage projects. They note (correctly) that much of the problem underlying how we run projects can be blamed on our inability to correctly schedule critical tasks, on our unwillingness to give up personal activity safety, and on our assumption of mistrust between schedule estimates made by project managers and time allowed by top management (Bob Graham, long-time project management consultant, used to refer to this phenomenon with the dictum, “If you don't take my estimates seriously, I'm not going to give you serious estimates”).
My purpose in writing this article is to offer some thoughts for readers based on TOC's underlying assumptions as they are applied to project management. Before investing Goldratt's model with the title, The Next Big Thing (TNBT), it is important that we take a balanced look at it. TOC has much to recommend itself; however, as is the case with other examples of TNBT, unless project management professionals are aware of both its strengths and weaknesses, we may be inclined to erroneously apply it to companies, situations, and circumstances where it is not appropriate. Further, as with most TNBTs, we have to be aware of the strong potential for companies to latch on to it, raise expectations sky high, and then be disappointed when it doesn't live up to our unrealistic demands.
The TOC operates under a number of assumptions, which were addressed in Frank Patrick's excellent article, “Getting Out From Between Parkinson's Rock and Murphy's Hard Place” [PM Network, April 1999]. Let's look at just three of these assumptions along with some alternative views on how to interpret their implications.
Jeffrey K. Pinto, Ph.D., is the Samuel A. and Elizabeth B. Breene Fellow and associate professor of management in the School of Business at Penn State-Erie. The author of nine books and over 100 scientific papers, he is the former editor of the Project Management Journal. In 1997, he received a Distinguished Contribution award from PMI.
Our Weird, Multitasked World: The Assumption of Dedicated Resources. In his article, Patrick makes the suggestion:
Avoid resource multitasking and its resulting lead-time multiplication. Focus on the task at hand. Management must take responsibility for protecting resources from competing priorities that drive multitasking. (p. 62)
Here is an eye-opening exercise for 90 percent of the project managers out there: Next time you are holding a resource planning meeting with top management at the kickoff of a new project, ask for a project team composed of personnel who are 100 percent dedicated to just your project. Their response should be illuminating: snickers, followed by chuckles, and finally outright laughter are the likely result. Wouldn't we all like to have a project team whose commitments ensured no competing priorities and eliminated multitasking? The better question is: Would we get anyone under those conditions?
On the surface, Patrick's statement makes perfect sense. Multitasking is a killer of project safety. The more competing commitments my team members have, the less time they can devote exclusively to my project. The result is that they have to nibble—a little here, a little there, a quick fix here, and so on. The problem with the call to eliminate multitasking, seductive as it is, is that it flies in the face of the sea changes that have occurred in Corporate America throughout the 1990s. We live in an era of downsizing (or “rightsizing” if you prefer, I won't quibble) that means having to do more with less. Fewer people having to attend to more tasks, an ever-increasing portfolio of new projects, and greater calls for internal economies of scale due to an inflation-free marketplace, all have contributed to mean that multitasking is not a peripheral annoyance but a way of life for the majority of us.
Yes, some companies do employ heavyweight project teams for new product development. Boeing or Microsoft have the corporate structure and the resources (and corporate philosophy) available to create a project team environment in which resources are heavily dedicated. In these circumstances, it's not only possible but also probable that project team members can attend to their duties with minimal impact from the call to multitask other activities. For the majority of us, however, the call to eliminate multitasking is cogently reasoned, well-argued, well-intentioned, but may ultimately be impossible.
When Dodging Parkinson and Murphy, Don't Hit Brooks: The Assumption of Squandering Safety. The TOC has much to say about understanding and eliminating some of the principal sources of safety that all project participants routinely build into their activity duration estimates. Padding activities with up to a 200 percent safety factor is a common phenomenon and one that is generally understood, not just by the team but also by top management. Hence, their frequent shaving of our original estimates! Further, Patrick has correctly argued Goldratt's other articulated point: we have little incentive to give over work that has been completed early for fear that future estimates will then subsequently be trimmed. If I estimate five days for an activity and then finish in four, I will most likely sit on that extra day to avoid future pressures for early completions. As Goldratt notes in Critical Chain, ‘A delay in one step is passed, in full, to the next step. An advance in one step is usually wasted” (p. 121). Put another way, no good deed ever goes unpunished. Both of these points illustrate Parkinson's famous law: Work expands to fill the time allocated to it.
Patrick's message regarding how to avoid the effects of Parkinson and Murphy is sound: we need to develop tight schedules supported by resource alerts so that we can effectively de-emphasize schedules, particularly at the expense of quality tradeoffs. One of the TOCs identified “killers” of project safety here is the so-called “student model,” in which activities with explicitly scheduled durations are likely to have much of the lead time squandered through late startups. In other words, just as a student, presented with a project and a deadline will put the task off as long as possible, so too project team members will not focus on work commitments until a great amount of the activity's scheduled time has elapsed.
The problem with the model is that it ignores the other obvious reason for these late starts; namely, learning curve considerations. Fred Brooks [The Mythical Man-Month, 3rd ed., 1995, Addison-Wesley] noted nearly 30 years ago that a huge expenditure of activity time may come from no other source than the effects of upfront learning required by the team prior to actually getting the work accomplished. This learning-curve model is shown in Exhibit 1. As with TOC, this diagram also shows that when percentage of work completed is plotted against elapsed time for the activity, we find a classic curvilinear relationship. Slow starts are followed by a rapid ramp-up in activity to the completion point. The dotted line shows the perfect world model in which we can assume that at every fixed point in the timeline, a specific amount of the activity has been completed. For example, 25 percent time elapsed should yield 25 percent activity completion.
Reader Service Number 027
Of course, in the real world, this perfect model never exists. We know from personal experience that the curvilinear model (what Bob Graham calls the “term paper” model) is the true one. The TOC also recognizes this relationship; however, their argument that it is due simply to being another way in which safety is squandered is not always defensible. Just ask Fred Brooks. He discovered that learning curve time had to be factored into duration estimation. Throwing resources at these nasty curvilinear models only lengthened them; hence, Brooks’ law. Project managers must ask themselves the root cause for the duration lag. Is the technology new or cutting edge? Is the team member new to project-based work? Are there excessive uncertainties involved in the project? Is there a team development cycle that needs to be worked into the duration estimate? Any of these reasons can also lead to activity delay, not through willfully squandering safety time, but because of this learning curve.
Here's one example from manufacturing: In 1981, Dean Thornton, the program manager for the Boeing 767, was faced with a dilemma. With the first 30 aircraft already in production and nearing completion, he was given the FAA go-ahead to convert the cockpits from three-to two-seat configurations. But how? He could continue to build the aircraft in process, maintaining production learning curves and lessons learned and subsequently retrofit the cockpits, or he could stop the assembly line, retool, and make the changes while the airplanes were still in process. His response was to retrofit the cockpits off line, as a separate project once the first 30 had been completed. His reasoning was based on the sacrosanct nature of the learning curve; it had to be acknowledged and its effects factored into the production process.
Not All Career Ladders Have Rungs: The Assumption of Motivation. In their review of Goldratt's book for the Harvard Business Review [March-April 1998], Jeffrey Elton and Justin Roe offered the following commentary:
[T]he book advises managers to work with the different individuals and functional departments involved in a project to set estimates for lead times so that they meet the needs of the critical chain. But anyone who has worked on a project, been a manager of key personnel on a project, or been a senior manager mediating a resource conflict among a number of projects knows that it is a rare organizational culture indeed that is capable of such an impersonal, rational approach to setting lead times. (pp. 158-159)
The Learning Curve Model
Exhibit 1. The dotted line here represents the “Perfect World” model, and the solid line the “Term Paper,” or learning curve, model. When percentage of work completed is plotted against elapsed time for the activity, we find a classic curvilinear relationship.
Their point bears mention, not as a minor issue but as one that must be factored into an organization's use of TOC. Project team motivation and leadership issues are not a sidebar to the use of TOC; they are an absolute prerequisite. Research into the causes of project success going back to the 1980s has consistently pointed to the same message: The effects of techniques should not be confused with the effects of the team. Studies by Bruce Baker, Peter Morris, Dennis Slevin, and myself have all pointed to the primacy of “people” issues as the major determinants of project success. Good scheduling techniques or accurate earned value assessment are just that: good ways to schedule and evaluate the status of a project. I am all in favor of injecting discipline into the project development process. How many of us, however, would not trade a sophisticated scheduling or resource management technique in a heartbeat for a motivated team run by a capable leader?
Elton and Roe make a similar point in their review when they note that “project performance is often less a matter of understanding the constraints of the project and more a function of the personal skills and capabilities of the potential leaders involved” (p. 159).
The TOC model, as specified in Critical Chain, takes the existence of a motivated and committed project team run by effective leaders as a given. Of course, when these are the suppositions, any improvement to the project management process is bound to come from paying attention to internal resource requirements. The more fundamental question, however, is whether or not this state of affairs is indicative of the average corporation developing and running multiple projects. Do we gain a better payoff from a sustained commitment to training cadres of project leaders or from adopting a new planning and resource controlling methodology?
IT IS NOT MY INTENTION HERE to offer a rebuttal of TOC as a mechanism for improving the project management process. Nor do I wish to create and demolish an artificial strawman by misrepresenting TOC or refusing to give it credit where due. My concern lies in the strong potential for many companies, who do not understand both TOC's strengths and weaknesses, to latch on to it as TNBT regardless of their particular and unique circumstances. The effects of subsequent failures and disillusionment with project management as a discipline in these cases is very strong and may be damaging. Indeed, I am convinced that TOC does offer much to our generation of project managers, partly because it presents us with a philosophically different way of examining and approaching our trade. It is important, however, that we create a balanced view of the TOC model, offering up both the good and bad so that project managers can use the model appropriately. No fundamentally good thing was ever tarnished by careful examination.
August 1999 PM Network