ABSTRACT
To maximize the potential of Critical Chain (CC) to enrich project management practice, I discuss Eliyahu Goldratt’s work in the context of his entrepreneurial career. I show that PERT/CPM had been an instance of Goldratt’s “Theory of Constraints” (TOC) before Goldratt had articulated it. I also highlight errors and questionable recommendations he made. Nonetheless, CC provides a more holistic approach than the typical practice before. I (1) discuss CC and TOC, including strengths and weaknesses, in the relevant context; (2) provide earlier sources for the major so- called Goldratt innovations; (3) identify opportunities for immediate improvement and future research highlighted by Goldratt’s work.
Keywords: PERT/CPM; Critical Chain; Theory of Constraints; Project scheduling
2005 by the Project Management Institute
Vol. 36. No. 1, 27-36, ISSN 8756-9728/03
“What’s in a name? That which we call a rose by any other name would smell as sweet.” W. Shakespeare
1. Introduction and Management by Constraints
In 1988, Eliyahu M. Goldratt, already well known for his commercially successful software Optimized Production Technology (OPT), and already a very successful author (Goldratt & Cox, 1984), articulated what some call a “radically new” approach to managing the flow of materials in factories: the so-called “Theory of Constraints” (TOC) (Goldratt, 1988). In this paper, we’ll use a more fitting term: “Management by Constraints” (MBC) (Ronen & Starr, 1990), since TOC is not an actual theory. MBC replaced a former articulation of Goldratt for the same purpose, which had essentially summarized just-in-time (JIT) principles, but with an additional wrinkle that suggested focusing on the bottleneck (BN) resource- which, under JIT, is partly implicit and partly redundant. MBC, which had emphasized the focusing aspect, could no longer be dismissed as a copy of JIT. At the time, many U.S. managers were keen to adopt JIT benefits, but some of them were less keen to admit the Japanese could teach the U.S. anything. Consequently, Goldratt’s contribution was greeted enthusiastically as radically new and better than JIT. Later, utilizing the more general aspect of MBC, it was touted as the correct approach to the management of everything under the sun. It is based on six steps (Ronen & Starr, 1990), with the first one, which we denote by the index 0, absent in the original:
0. Select an objective function and decide how to measure it.
1. Identify the binding constraints that limit our ability to improve the objective function
2. Manage the binding constraints to improve the objective function maximally. (I am not quoting Goldratt verbatim. His version was “Decide how to exploit the constraint,” but I assume he had not intended to restrict this to planning only.)
3. Subordinate everything else to the needs of the binding constraints.
4. Improve the binding constraints.
5. Return to Step 1, since the binding constraints may have changed after Step 4.
MBC enjoyed a tremendously favorable reception by practitioners. Many felt-perhaps with good reason-that no academic had ever explained these principles so clearly and succinctly. As for academics, some of them joined in, and the ideas-usually with full credit given to Goldratt-found their way into many Production & Operations Management (POM) texts, and certainly influenced academic teaching and research. There is no denying that Goldratt is bright and has a genius for selling ideas. Also, although MBC and earlier teachings mainly involve packaging of old ideas, it is certainly a clever packaging. Nonetheless, others felt that there was nothing essentially new in MBC and that much of it is too simplistic or wrong. The fact that Goldratt had made unfounded claims of optimality with respect to the OPT software long before articulating MBC may have contributed to this negative reception. OPT did not deliver everything it was supposed to deliver. By chance, I know of an example where top management bought the product but the schedules it generated were never actually used on the shop floor. Top management was not informed of this, and it was ultimately revealed when they tried to force it upon a company they eventually acquired. In other words, the software was used as a regular material requirements planning (MRP) system. Possibly, other implementations that were reported as successes never involved the use of the OPT module itself (although that was the central module used to promote the package). Another client, MARS, won a court battle against Creative Output (CO), Goldratt’s company (of which he has since divested himself). The judge set precedence by ordering CO to reveal the source code to MARS, so they could complete their proof that the package could not deliver what was promised (Wilkins, 1984). Eventually, Goldratt stopped making optimality claims with respect to OPT. Goldratt (1988) points out weaknesses of OPT and, indeed, his subsequent software package-DISASTER(TM)-is very different (Simons & Simpson, 1997). Pinedo (1997), inter alia, comments on the success of the OPT package in the marketplace. Furthermore, careful study suggests that Goldratt’s teachings are indeed too simplistic and not always correct (as I discuss in more detail later).
Since both Goldratt’s supporters and opponents have valid arguments, one might expect a consensus to emerge with respect to the correct ideas and the system that connects them. Nevertheless, this has not yet happened. There are myriad academic papers that treat Goldratt as an “academic giant,” and seek a good foothold on his shoulders. This does not mean, however, that academia as a whole admires Goldratt. Understandably, detractors rarely mention Goldratt in writing (and their point of view is usually only expressed verbally), but the existence of this point of view cannot be denied. Last, but not least, papers that seek to study the good and the bad together-exactly what we need! -are rare. Refreshing exceptions are Herroelen and Leus (2001), which is also a rich source of illuminating references (some of which are repeated in this paper); Herroelen, Leus, and Demeulemeester (2002); and Raz, Barnes and Dvir (2003). Also, Erenguc, Tirupati and Woodruff (1997) edited a special issue on capacity-constrained planning and scheduling, most of which is devoted to a balanced discussion of Goldratt’s contribution to scheduling software, including commentary from leading academics. McKay and Morton’s 1998 review of Goldratt’s book, Critical Chain, is another balanced source.
Why is the balanced approach the exception and not the rule? Arguably, the reason is that Goldratt’s personality influences the academic debate. Thus, even Goldratt’s true contributions are denied or ignored by some of his detractors, while many supporters refuse to admit that Goldratt’s teachings are often misleading or erroneous. This state of affairs is not conducive to the proper discovery and evolution of the academic truth. Personally, I believe that a necessary condition to get out of this quagmire is to “call a spade a spade” and discuss Goldratt’s work without pretending that the discussion is totally separated from his personality. (I apologize for using the first person singular while doing so, but the alternative is awkward-the paper reflects my personal take of the “Goldratt phenomenon” and much of the “evidence” is from my personal experience.) Another purpose is to list some of the relevant sources that precede Goldratt. Evidently, Goldratt had made a decision not to provide this academic service himself (and since he is not an academic, but an entrepreneur, why should he?). I hope that this list will help those of us who do not wish to be labeled as “Goldratt disciples” teach and research the issues as any other academic issue, without feeling obligated to pay undue homage to him.
Perhaps the most glaring case of misplaced credit is revealed by Goldratt’s venture into the field of project management. Wittingly or unwittingly, Goldratt had used old and well-known lessons from the project management field to develop MBC. A few years later, he turned around and reapplied them to projects, but, instead of saying so, he effectively claimed that he was applying MBC to projects for the first time! Section 2 is devoted to this issue, and demonstrates that the combination of project evaluation & review technique and the critical path method (PERT/CPM or CPM, in short) had always been an instance of MBC. (For convenience, however, I will reserve the term “MBC” for the manufacturing environment.) Section 3 asks some theoretical questions associated with MBC. It is interesting to see that they are not problematic in the project environment (which raises the question to what extent it has been appropriate to adapt CPM to MBC so faithfully). Section 4 lists some academic sources for the main so-called “innovations” in Critical Chain (CC), and discusses Soviet roots of the pivotal MBC focusing idea. Section 5 discusses the practical state of the art that gave Goldratt the opportunity to sell CC as something different from CPM. Nonetheless, Goldratt’s work can (and should) be a basis for major improvements in project management practice. Section 6 proposes a more holistic approach to project management, including steps we can take in the short- and long-term. Section 7 is the conclusi\on.
2. PERT/CPM as a Seminal MBC Model
Putting focusing aside for a while, it is relatively well known that mathematical programming principles and models (e.g., linear programming [LP]) supersede MBC (Ronen & Starr, 1990). For example, the analysis of opportunity costs and duality theory precedes Goldratt’s observations about the fallacies of traditional accounting and provides a more correct view of the value of time lost on various constraints. And the newsboy model provides a better approach to buffer setting (it may not be necessary to use models for this, however). The focusing aspect, however, seems to give MBC an edge that makes it look different. Here, we will see that this focusing aspect was not invented by Goldratt. In section 4, we discuss Soviet roots for this idea that go back to the early communist era, but it also has a very direct Western origin when we think about project management. The complete MBC structure, along with its focusing features, is well known and has been well known since Goldratt’s childhood. It is simply PERT/CPM! The isomorphism between CPM and MBC is straightforward-to wit, here are the six steps of MBC with project-specific comments added, mostly in bold. I restrict the bold statements to what I remember having been taught as an MBA student in the mid-1970s. (I remember the lessons about LP and cost accounting from the same period.)
0. Select an objective function and decide how to measure it. (The objective is to finish the full scope of a project as soon as possible and within the budget. It is measured by professionals, customers, and calendars.)
1. Identify the binding constraints. (Identify the critical path. This includes the effects of any constrained resources.)
2. Manage the binding constraints. (Focus attention on the critical path to make sure that no time is wasted there. This includes encouraging and utilizing earliness in any critical activity.)
3. Subordinate everything else to the needs of the binding constraints. (The non-critical activities must be started early enough to control the risk that these activities will delay the project. An excessively conservative [but not unusual] implementation of this principle involves starting all activities as early as possible. In addition, the critical path can be used to decide what the project manager needs to pay attention to personally and what can be delegated, which makes it also a rational basis for hierarchical management of projects.)
4. Improve the binding constraints. (Reduce the length of the critical path by crashing and other time-saving methods, where expedient, as long as it is cost-effective.)
5. Return to Step 1, since the binding constraints may have changed after Step 4. (During crashing, the critical path may change, so crashing involves focusing on the evolving critical path iteratively. Even more important than this planning aspect is the control aspect. Due to exogenous developments and chance events, the critical path may change during the project execution. Therefore, it is necessary to manage the future project activities with a focus on the updated critical path. This is equivalent to returning to Step 1. Of course, similar observations about the execution and control aspect apply with respect to flow of materials in a factory.)
Never having met the man, I do not know for sure whether Goldratt was aware of this isomorphism when he articulated MBC. (Indeed, he may have acted on subconscious information.) However, at least to the extent we treat his work as an academic source, he certainly should have been aware. Therefore, changing the name “critical path” to “critical chain” is not “a rose by any other name [that] would smell as sweet.”
3. MBC-Some Questions
CPM starts with identifying the critical path; MBC starts with identifying the binding constraint(s) (i.e., the bottleneck must be known before one can proceed further). There is no dispute that focusing on binding constraints is useful-it may be obvious, but that’s a different matter. Nonetheless, it is not clear at all that we should start by identifying them or that we should schedule production by them. In a factory, a strong case can be made that it is enough to limit the total work in progress (WIP) effectively (Hopp & Spearman, 2001) and avoid large transfer lots (Trietsch & Baker, 1993). The limiting resources may even shift with time without creating major scheduling problems. The (IT system provides a very well-known example and achieves smooth operations without wasting bottleneck capacity and without necessarily identifying the bottlenecks explicitly; in fact, even Goldratt and Fox (1986, pp. 13, 89, 95) recognized JIT’s leadership. A related approach is constant WIP (CONWIP). Hopp and Spearman (2001) and Trietsch (in press-b) explain, in detail, the advantages of CONWIP over Coldratt’s drum-buffer-rope (DBR). Essentially, DBR aims to maintain a constant WIP in the system upstream of the bottleneck resources without attempting to control the WIP downstream from the bottleneck, while CONWIP covers the whole system. If the bottleneck is stable, CONWIP and DBR perform almost equivalently, with perhaps a very small throughput advantage to DBR, at the cost of increased fluctuations risk. But, since bottlenecks should never be trusted to be stable, CONWIP has the major advantage that it will work equally well with any bottleneck, like JIT.
One additional point: although CONWIP is formally defined for flow shops, it is straightforward enough to extend to more complex factories. Basically, the idea is simple: Control the total WIP by a tight feedback loop. Do not induct new work before selling (or scrapping) the same amount. Over time, adjust the WIP cap to get the best performance and to help identify important constraints and improvement opportunities (as in “exposing the rocks” under JIT).
In a make-to-order environment, the system inducts new work if there is a queue of orders and the WIP cap allows, but, when there is no queue, the total WIP in the factory is decreased automatically. Therefore, the system may be called CAPWIP-for capacitated WIP. Together with lot streaming (i.e., using small transfer lots), CAPWIP may be considered a special case of JIT.
As under JIT, it is easy to identify persistent or recurrent bottlenecks under CAPWIP-they are the ones that collect persistent or recurrent machine queues. Other important queues await assembly parts from the bottleneck and we refer to them as assembly queues. (Sometimes, waiting space is the bottleneck; in this case, the analysis is slightly more complex, but the same situation can happen under DBR, and it is not very difficult to identify the true cause in such cases.) In conclusion, CAPWIP does not require identifying the bottleneck in advance, but does help identify bottlenecks and focus on their improvement. It is also relatively easy to implement- certainly easier than DBR, if only because the bottleneck does not have to be identified in advance.
The CAPWIP idea is obvious to anybody who is familiar with DBR, because it can be described as a special case of DBR, with the market holding the drum. This raises a question: why didn’t Goldratt choose CAPWIP? As it happens, in the early 1990s, I consulted for two managers who were using CAPWIP routinely, and both of them were Goldratt Associates. I also had a meeting with a third manager, an avid client of the Goldratt Institute, and he too used CAPWIP. According to this third manager, by then Goldratt had added CAPWIP to DBR-although his books don’t say so. Indeed, one can interpret the following quote from Goldratt (1988, p. 454) in this light: “the OPT BRAIN contains a crude mechanism to prevent excess build ahead.” This would make perfect sense because, otherwise, the shifting bottleneck phenomenon can cause uncontrolled WIP buildup. The two plants managed by these Goldratt Associates were large machine shops, where CAPWIP is by far the easiest practical way to control the total WIP. The third-in the electronics industry-had more options that could have been considered, including DBR, but management still selected CAPWIP. Why, then, did Goldratt not adopt CAPWIP from the start? Why didn’t he adopt it completely and openly later? From an academic point of view, this decision should have been explicitly made and explained.
The consulting I had done with the two Goldratt associates consisted of improving bottleneck capacities (Step 4), by using setup reduction methods and similar improvements (Shingo, 1988). Of course, we first had to identify the bottlenecks. The Race (Goldratt & Fox, 1986) explains how to do this as follows:
A capacity constraint manifests itself in all of the major business issues. An analysis of the major business issues can be used to identify the capacity constraint resources (CCR’s). (p. 107)
In both cases, however, none of us considered using Goldratt’s solution, and I doubt we could have done it had we wanted to. The organization to which the shops belong is huge and its business issues could not be used to pinpoint specific machines in one job shop. At best, such analysis could point to the facility to which the shop belonged as an organizational bottleneck, but that would not solve our problem. A more localized analysis was not a reasonable option either because it would still require vast amounts of reliable data, which was simply not available. Therefore, we selected a less sophisticated approach-observation of queues. The idea is well known from JIT, and was also endorsed by Goldratt in The Race (Goldratt & Fox, 1986, p. 129). An academic validation of this idea is included in Lawrence and Buss (1994). This brings us to the issue of Goldratt’s careful analysis where to place buffers in a factory. The following quote from The Race explains how important it is to plan protection carefully and proactively:
Concentrate protection not at the origin of dis\turbance, but before critical operations. Inventory of the right parts in the right quantities at the right times in front of the right operations gives high protection. Inventory everywhere else is destructive. (p. 113)
Again, the way to identify bottlenecks is through observation of queues, although sometimes they are intangible (e.g., lost orders) or removed from their true source (e.g., assembly queues or queues ahead of blocked machines that should be assigned to downstream resources). It follows that these queues automatically protect the resources that have to be protected. There is no need to plan the exact location of the buffers any more than there is a need to instruct the sun to rise in the east. Again, one must ask what motivated Goldratt’s recommendations. Is it an academic issue? A practical issue? Both? None? Should academics endorse it? Should practitioners pay for the required analysis?
4. Critical Chain-How Much is Really New?
To return to CC, Goldratt’s followers and some others, perhaps, believe that there are radical differences between CC and CPM. There are four main points often raised:
1) The use of resource constraints instead of resource leveling.
2) Abolishing due dates to manage critical (and other individual) activities.
3) The use of project buffers and feeding buffers.
4) The importance of avoiding multi-tasking.
In this section, we will discuss these issues, mostly in terms of their origins. In the next section, we’ll discuss them in terms of the “state of the art in teaching and practicing project management” until the 1990s. The limit of the 1990s is because contemporary, respectable project management texts cite Goldratt’s CC as the source of at least one of the very same ideas we are discussing here. Finally, since this section is focused on the academic sources of Goldratt’s work, it also includes a brief discussion of what is perhaps the earliest source of the bottleneck-focusing idea that is so pivotal in MBC. Of course, CPM itself is another such source.
Resource-Constraint Issues in the Academic Literature
Academic publications addressed this issue since the early stages of the PERT/CPM development. Wiest (1964) identified what he termed “the critical sequence” as a critical path that takes into account resource dependencies. Good POM and operations research (OR) texts always stressed the need to consider limited resources and their implications on the critical path (e.g., Nahmias, 1989). As I already stated, I was taught this in the early 1970s; I have also taught it this way many times since the late 1970s. Two sources that just preceded CC are also of interest. First is Morton and Pentico’s very comprehensive 1993 book about scheduling in general, which includes extensive coverage of project scheduling and multi-project scheduling. In the “MBC domain,” they describe OPT as an industrial benchmark, but also provide better sources for bottleneck-related scheduling. Their models for the CC environment precede CC and go way beyond what CC has to offer, both for single and multiple projects. Next, Raz and Marshall (1996) discuss the effects of resource constraints on project float (slack). It goes without saying that if you know the true slack, your critical path will not “jump all over” (Goldratt, 1997, Chapter 22, p. 212)-and in the case of Goldratt’s book, Chapter 22 of Critical Chain will become moot. Actually, we don’t even need to know the true slack to prevent such jumping: just follow the resource-constrained original schedule without factoring in slack (but include “soft” precedence constraints between activities that share a resource, after deciding how to sequence them). As Raz and Marshall (1996) demonstrate, the most popular project software package, Microsoft Project, had the capacity to do that as a matter of course (they cite Version 3.0, but such software capabilities were no longer new in the 1990s). In other words, the state of the art, as reflected by popular software, definitely included this consideration. But it is Chapter 22 of Goldratt’s book where the term “Critical Chain” is invented to respond to the “jumping critical path” phenomenon.
Interestingly enough, there is no need to look for earlier sources to prove the point. Goldratt himself, in a preemptive bid, provides sufficient evidence. To wit, consider the following quotes from Chapter 22 (Goldratt’s hero, Rick, a professor teaching a project management course, is narrating):
There are many topics I’ve skipped, but for a very good reason. They are what some would call academic-resource optimization, sequence optimization, investment optimization. I call them irrelevant, (p. 208, emphasis added)
And a bit later:
“Exactly,” I say. “Dependencies between steps can be a result of a path or a result of a common resource. Why are we so surprised that both dependencies are involved in determining the longest chain of dependent steps?” (p. 215)
Indeed, nobody should have been surprised. But, unfortunately, Rick had decided not to teach some “academic” and “irrelevant” topics, and thus deprived his students of the opportunity to draw the [trivial) practical and relevant conclusions. Nor does he hide this truth from his students:
“I don’t know how many articles dealing with resource sequence optimization I have read,” I tell them. “More than I care to remember. They contain many algorithms and heuristic rules to sequence resources. [. . .] But I don’t waste my time reading them anymore. Why? Because in each case the impact on the lead time of the project is less than even half the project buffer.” (p. 217)
Although it is not clear that the lead-time impact is indeed negligible, Goldratt is not the only one who believes that some theoretical scheduling models are impractical. But by including all sequencing rules in the group of redundant theory (e.g., all heuristics), he implied that the whole issue is not important. Yet, the need to sequence activities on limited resources is at the core of the critical sequence analysis!
The Abolishment of Due Dates
The second point, abolishing due dates, is perceptive and important. Nonetheless, it is not new either. Papers by Schonberger (1981) and Gutierrez and Kouvelis (1991) discussed this as an instance of Parkinson’s Law (i.e., work expands to fill the time allotted to it), and did so in the context of project management. Another source is W. Edwards Deming’s 14 Points (Deming, 1986), although Deming’s points are generic, and not specifically associated with the project management area. Deming had preached against the use of quotas and Management by Objectives (MBO) years before the advent of MBC, let alone CC. Managing by due dates is an instance of MBO, and, equivalently, a due date is a quota.
The Source of the Buffers Idea in the Academic Literature
Feeding buffers constitute one of the main innovations in CC relative to conventional CPM implementation. In general, a good project buffer is created when the stakeholders negotiate a reasonable and realistic completion date target. For the project manager, this allows minimizing the project cost, including the expected project delay penalties (e.g., penalties payable to the customer or other delay-related expenses). For the customers, it helps avoid the damage associated with overly optimistic expectations, and if delay penalties are negotiated, then customers are compensated for excessive delays (Ronen & Trietsch, 1988). Goldratt’s idea to monitor projects based on buffer penetration is not bad, although it requires corrections, but it is not the main function of the project buffer. Similar monitoring could easily be performed without an explicit project buffer. That is, instead of “buffer penetration,” we would monitor schedule slippage. (According to Goldratt’s approach, the size of the project buffer is arbitrary, so his fractional penetration measure is arbitrary too.) The use of a project buffer for its important protection purposes, however, is well known. One relatively early example is discussed by O’Brien (1965), under the name contingency (p. 142). In contrast, feeding buffers are important because they resolve the question when to start non-critical paths. In general, neither the early start policy nor the late start policy provides a correct approach to this question. Finally, when a project is really a subproject that feeds the critical path of a parent project, the project buffer is a feeding buffer of the parent project. One can say that feeding buffers are the general case and project buffers are a special case. Even when the project is not a subproject formally, it always serves some need that can be conceived as a parent project. Therefore, the project buffer is mathematically equivalent to a feeding buffer.
Feeding buffers may be important, but did Goldratt invent them? Ronen and Trietsch (1988) discuss a strongly related problem, and I can personally testify that it was clear to the authors that both project and feeding buffers should be incorporated in project planning. The focus of that paper is the determination of optimal feeding buffers for purchasing project items, but it also discusses project buffers and how to optimize them or negotiate them with customers. (There were two practical reasons for the limitation to this special case: a client needed it, and it is much more tractable than the general problem.) Kumar (1989), and Chu, Proth and Xie (1993) published essentially identical results for feeding buffers independently, thus demonstrating that the basic idea was understood by the professional community long before the publication of Critical Chain.
A direct conclusion of such models is that the time buffers of the various feeding activities should be balanced against each other, while taking into account their respective marginal costs and their propensity to limit the system, which we refer to as criticality (Elmaghraby, 1977, p. 27\7). This can be generalized for other buffers (e.g., resource capacity buffers should be balanced, too). Such balance may be viewed as an inescapable consequence of repeatedly implementing MBC’s Step 4 without waste, so one might expect Goldratt to applaud it. However, Goldratt is vehemently opposed to balance! His case against balance is argued in pages 139- 141 of Critical Chain, (concluding with the acronym “QED”), but the proof is based on a flawed assumption amounting to a tautology. Essentially, his argument is that if we wish to keep the bottleneck busy 100% of the time, we must have excessive capacity on other resources or the bottleneck will idle sometimes. The flaw is in the assumption that we have to keep the bottleneck busy at all times. Trietsch (in press-b) shows that correct balance involves matching criticalities with marginal resource costs. When applied to non- bottleneck resources in a system that allocates 100% of the criticality to a single bottleneck, the model shows marginal waste approaching 100%! Thus, this is a very serious mistake that Goldratt has made. Spearman (1997) provides another window into Goldratt’s surprising stance against balance, and the fact that people often accept it as true.
Finally, to conclude the discussion about buffers, there is an analogy between project buffers and bottleneck buffers, and between feeding buffers and assembly buffers. But there is also a major conceptual difference between them in terms of planning. As we have seen in the MBC arena, it is not necessary to plan individual buffers because CAPWIP (or other JIT implementations) will create them automatically. Instead, the relevant question is how much WIP we need in the factory to balance lead-time and throughput objectives. And we can answer the question by trial and error. In contrast, trial and error is not an option in project scheduling: all feeding buffers must be planned (which is why they are important). So, ironically, Goldratt’s contribution to buffers was superfluous in MBC and important (but not original) in CC. However, Goldratt also recommends a bottleneck buffer of project tasks in front of highly loaded multi-project [shared] resources: This, again, is superfluous. The buffers will create themselves. All that is required is to take the necessary additional queueing time into account. However, it is usually not necessary to schedule such resources very carefully in advance. Arguably, Goldratt’s own stance about the futility of optimization applies to this case.
Avoiding Multi-Tasking
It is easy to demonstrate that multi-tasking can be harmful. For example, in Portougal’s 1972 academic paper published in the Soviet Union, he showed that multi-tasking is detrimental in terms of all regular performance measures, for any project configuration. He assumed deterministic processing times, where task durations are inversely proportional to the intensity of resources allocated to them, and where all resources are interchangeable. He showed that there exists an optimal solution, where each job, once started, should be processed as quickly as possible. That is, we should never re-allocate resources in a manner that will delay the completion time of a task that had been started already.
Nonetheless, in practice, the idea should be taken with a grain of salt. First, while an optimal schedule exists that does not require preemption, this does not mean that preemption may not be required to correct mistakes (i.e., for control). Second, projects are never deterministic and resources are never completely interchangeable. For example, rework can never be scheduled in advance by a deterministic model. Or, suppose a manager is in the middle of a very long task, and three projects are waiting for preliminary approval of their plan. It is likely a good idea to serve them immediately and then return to the long job. (It is difficult to conceive of a manager who can do his/her job properly without multi-tasking.)
Similarly, CPU time-sharing, by completing very short jobs very quickly, was quite useful when it was first introduced. The explanation is that many programs were still at the debugging stage where it took the mainframe fractions of a second to diagnose them and, thus, provide the programmer with enough feedback to continue working. Yet, time-sharing is a quintessential example of multi- tasking. Goldratt’s philosophy is that if the resource is “the bottleneck,” then wasting capacity of the other resources is immaterial. But Trietsch (in press-b) shows that this philosophy is very wasteful for the system as a whole. It is wasteful in general, and not just in this instance. In conclusion, the idea is useful sometimes, but much less often than the hype around it seems to suggest.
Back to the USSR-The Source of the Bottleneck Focus Idea
While the main subject of this section is on the points in which CC looks different from CPM, it should be noted that the credit for Goldratt’s earlier ideas (e.g., the focusing idea incorporated within MBC) is also misdirected. One reason is that MBC, including the focusing aspect, is isomorphic to CPM. But it turns out that the focusing idea had also been articulated in the manufacturing arena long before MBC, at least in one industrialized nation: the Soviet Union. There were two schools of thought about managing production there, one “soft” and one mathematical. The former had promoted the idea of focusing on bottlenecks for several decades, starting in the first half of the last century. Considering Goldratt’s disdain of mathematical methods (as documented in this section), one can safely say that this group had basically taught the essential ideas Goldratt promoted with the same flavor, and did so before Goldratt was even born. The latter group picked up on the idea and started publishing mathematical papers about it long before the advent of OPT. For example, Pervozvansky (1975) wrote an extensive book on mathematical models in production management and discussed this idea in Chapter 7. The book also mentions an analytic solution of a flow shop with a distinct bottleneck, and discusses, in particular, the connections between resource constraints and the true critical path in projects! In other words, the ideas were known in the USSR both with respect to the MBC environment and the project environment, and they had been known years before Pervozvansky published his book- it’s just one source that certainly precedes Goldratt’s work. (My source of the information in this sub-section is my colleague Victor Portougal, an ex-Soviet scheduling expert, and I must say it came as a surprise to me when I first heard about it while working on this paper. Victor belonged to the mathematical school there, and the reference he provided is to one of the books in his personal library. As it happens, when he left the USSR, he only took with him relatively modern books. Thus, there is no reason to assume that Pervozvansky is an especially early reference for this idea, even within the mathematical school.)
5. On the Practical Pre-Critical Chain State of the Art
As we’ve seen, there is little in CC that was not known before, and some of it, including the excuse for the new name, was very well known. Does that mean that Goldratt contributed nothing new? The answer is a qualified “no.” In my opinion, Goldratt (or some unnamed associates of his) made an important contribution: He provided a new package. In it, he packed together items that go well together, but were marketed separately. Thus, he provided a more holistic approach than was previously the typical case. (A commercial law analogy comes to mind. The first person that attached erasers to pencils created a very convenient writing tool and can safely be called bright and innovative. Nonetheless, he merely combined well-known parts, and such combinations are not patentable. The inventor did not receive credit either for pencils or for erasers, and earned no royalties for the combination.) In effect, Goldratt provided a “one- stop shop” for these ideas, but he also ripped off all the labels from the merchandise before putting it on the shelves (not to protect the original brands, but, rather, to effectively re-brand them). This may be convenient for shoppers, but a far cry from a completely new approach and-from an academic point of view-there is no justification for hiding the sources of the items. 1 low, then, did Goldratt convince so many that it’s much more than merely a new package that he has to offer? Quite simply, instead of making claims with respect to CPM theory, he made [implicit] claims with respect to CPM as practiced by many and as presented by some books. Thus, he implied that typical CPM practitioners and books (1) do not identify the critical path correctly (by ignoring resource constraints), (2) fail to utilize and encourage earliness (by using due dates to manage individual activities), and (3) use the wrong approach to subordinate other activities to the needs of the critical path (which is where the feeding buffers come in).
Critical Chain’s hero, Rick, is assigned to teach project management for the first time in his career. He does not find the answers he needs in the textbooks the library carries. His disdain for academic papers has been mentioned before, so obviously he cannot use any of those. Therefore, together with his enthusiastic executive students (who liberally provide questions; answers; complete, successful, and instantaneous field-testing; and, last but not least, consulting opportunities) and with some support from colleagues, Rick proceeds to invent a “new” way to manage projects all with-in a one-semester course. Thus, the book astutely does not claim to improve upon the collected wisdom found in academic papers and advanced books, but rather, is pitted against some project management textbooks of the type available to the hero. Arguably, in a field th\at had been established about 40 years before the publication of Critical Chain, the viable textbooks should have reflected accumulated knowledge in the field, with the potential exclusion of esoteric material and very new contributions. But was this really the case?
Unfortunately, the answer is not entirely affirmative. Recently, I found myself in a similar situation, having to teach a full course in project management for the first time in my career. I was not a complete novice in the subject. I had taught CPM as a minor subject in POM and OR courses for many years, had worked within projects and project organizations, and had co-authored a couple of papers in the field. For a while, I toyed with the idea of teaching without a book altogether, but since I am not an expert in the general management aspects of the subject, I eventually decided to use a text. As a result of this experience, while I did learn many new things about the general management aspects, I also realized that the lessons I have learned and taught so often about CPM are not clearly presented in typical books.
Typical textbooks on the subject mention, as a matter of course, that resource leveling may change the length of the project, but they do not say clearly that the critical path is not fully identified until after all resource conflicts have been resolved. A Guide to the Project Management Body of Knowledge (Project Management Institute, 1996, Ch. 6)-which codifies one official collection of knowledge in the field-indicates that the critical path is not determined until after sequencing is done and, thus, contradicts Goldratt’s implicit claim (Globerson, 2000). Unfortunately, its coverage of this issue is quite confusing, and Rick could be justified in ignoring it for the purpose of teaching his course. The correct message is better conveyed in OR and POM books (e.g., Nahmias, 1989), but project management texts treat scheduling as a relatively minor issue.
A vicious cycle may be operating here: Scheduling methods, used incorrectly, did not work spectacularly well. In response, teachers (except those whose expertise is specifically in quantitative methods), and some books, stopped stressing them. Now they really don’t work well. Perhaps the two most important reasons for this are management by due dates and not using feeding buffers. (Sequencing is important, but there is abundant evidence that it was incorporated into practice already, although not necessarily optimally. Once we take sequencing into account somehow, there should be no reason to be unhappy with the results. After all, even if we miss the optimal solution by a lot, we will not know it! So this is not a likely cause of discontent. Instead, discontent is the result of failure to meet plans, and it is this failure that may have given project scheduling a bad reputation.)
Thus, overall, it seems that Goldratt successfully put his finger on an issue that OR teachers failed to market-as he had done before with respect to MBC. Somehow, important parts of the knowledge (and the intuition) that OR researchers and practitioners had developed- and published in academic and other outlets-failed to find its way to the textbooks we use to teach project management. Ironically, several recent textbook editions mention CC as the “source” of knowledge that sequencing may be required to remove resource contentions! This misses the boat in two important ways: First, as cited before, even Goldratt practically admits he barged through an open door there. So, why give him credit for it? Second, it misses two important items in the CC package: The avoidance of management by due dates and the specification of buffers. As we saw, these are not original Goldratt ideas either, but they are the ones where a strong argument could be made that practice does not conform to the recommendation, and the recommendation is meritorious.
6. Towards a More Holistic Approach
In general, CC provides a more holistic approach to project scheduling than the prevalent previous practice, and addressing the issues as a package is Goldratt’s true contribution, for which he and/or his associates deserve credit. We need to build on this basis and take a much more holistic approach to project management in general and to project scheduling in particular. Examples of a more holistic approach include (1) addressing existing techniques in the correct sequence, such as resolving resource contentions right after the determination of the initial critical path; (2) combining resource sequencing and scheduling with stochastic analysis; (3) combining crashing techniques with stochastic analysis (i.e., how to crash stochastic activities); (4) setting buffers optimally together with such scheduling and crashing activities; (5) planning buffers for time, capacity, cost, and scope in a concerted way by practical, theory-based methods; (6) monitoring buffers correctly (with a proper statistical quality control approach). Most of these go way beyond what CC has to offer, but the renewed debate CC caused may help bring this about. In this section, we discuss some of these issues.
What Should be Done Right Now?
The success of CC demonstrates that we can achieve immediate benefit by some relatively simple steps. We should not adopt the CC recommendations without scrutiny, however, since they include errors. Goldratt’s generic answer to such criticism is “it works” (see Cabanis-Brewin, 1999). But even if we stipulate that it does work, this just means that the errors are not fatal, not that they should be sanctioned. The fact is that Goldratt’s work requires both minor and major corrections. The minor corrections are easy to implement with the tools we currently have and, therefore, we should begin pursuing them at once. (From an academic point of view, this means we should start teaching them right now.) A reasonable sequence for scheduling projects that builds on the CC approach using existing tools would include the following seven steps:
1. Estimate durations (by deterministic or stochastic measures and without padding) and identify the absolutely essential precedence constraints (i.e., do not include any precedence constraint designed as an implicit resource constraint resolution).
2. Devise the CPM network and identify the initial critical path.
3. Identify any resource constraint violations and resolve them by judicious sequencing rules and/or software. (To prevent problems later, introduce “soft” precedence relationships into the network to enforce the sequencing decisions.)
4. Once a good, feasible plan has been devised, consider crashing. (Crashing before sequencing may crash activities that are not really critical, so crashing must follow sequencing, but the two can then be performed cyclically with each influencing the other.)
5. Set feeding buffers and a project buffer. Emphatically, if a feeding buffer is too small for comfort, do not change the sequence, and do not start a non-critical path before the critical path; instead, start both (or all) as early as possible and increase the project buffer as necessary. (Boldly ignore any contrary recommendations from various CC authorities. To delay the most critical path just because a nearly critical path does not have a large enough feeding buffer implies losing time with certainty to avoid any risk of losing the same time or less.)
6. Monitor performance based on buffer consumption. (However, Goldratt’s approach here fails to take into account basic statistical process control lessons and, therefore, this part can benefit from further research.)
7. In the old spirit of CPM and MBC (but contrary to Goldratt’s recommendation in CC), update the network (return to Step 1) whenever the critical path changes, or if buffer consumption is much more or less than expected. Before doing so, release all soft precedent constraints. (However, when the stability of the plan is very important, it is possible to treat some of these soft constraints as hard ones.)
Potential Future Work
Of course, this is just a start, based on what is easy to achieve relatively quickly. The list does not yet include nontime buffers and their coordination. It also does not specify how to crash stochastic activities and exactly how to set buffers (for a partial answer, see Trietsch, 2004).
Another open question is how to monitor buffers without tampering, based on statistical quality control principles balancing the damage from “Type I and Type II errors.” Coldratt’s recommendations for buffer setting and monitoring are better than nothing, but far from satisfactory. The correct estimation of project and activity durations based on historical data, and taking into account consistent bias (which varies across projects and introduces dependence between task duration estimates), is also important in this context. Incidentally, the existence of consistent bias implies that project buffers must be much larger than the randomness of individual activities suggests. This supports Goldratt’s heuristic of setting the buffer as a fixed proportion of the chain length when compared to the alternative of assuming independent activities. Leach (2000) includes an improvement whereby the buffer of short chains is relatively larger. Trietsch (in pressa) shows that the correct buffer is approximately given by a positive constant plus a fraction of the project duration. However, both the constant and the fraction should be based on historical data analysis and on the ratio between the cost of earliness and the project delay penalty. In contrast, Goldratt ignores the positive constant and uses an arbitrary fraction that is based neither on data nor on relative delay costs.
In general, Steps 3 to 7 highlight areas where more research is required. We have enough basic results to use now, but we also need more advanced results, since our present ones were derived by the analytic approach and are notfully satisfactory for the system as a whole. Morton and Pentico (1993) and Demeulemeester and Herroelen (2002) provide an excellent start for Step 3, and see also Trietsch (2004), but much more needs to be done. Another objective is to include resource capacity level optimization in the picture. This can fit within the cyclical application of Steps 3 and 4.
7. Conclusion
Not for the first time, Goldratt’s work led to debate and rethinking (e.g., Herroelen & Leus 2001-where many more such references may be found; Maylor, 2001; Raz et al., 2003). Such cause for thought is a good thing. However, while his influence cannot be denied and some of his teaching is brilliant, we should remember that Goldratt is not an academic, but an entrepreneur (albeit a bright and highly educated one). As such, his motivation may be different from that of academics. There is no compelling business reason for Goldratt (1) to give credit where it is due, (2) to adhere to the “academic” truth, (3) to discuss issues deeply and thoroughly, and (4) to make sure that his work can pass the scientific review hurdle that academic publications must. All this is fine as far as business is concerned. However, these issues are important to consider when we cite and evaluate Goldratt’s work as a source of academic knowledge. A critical approach is mandatory here.
Since practically all of Goldratt’s work had not been refereed, every academic who cites him should first imagine that he/she is required to evaluate Goldratt’s work, as would a referee. As for those who may feel unqualified to referee Goldratt’s work, they should be even more wary. The wide citation of Goldratt’s work in academic papers is not equivalent to a single thorough review of the type that all serious academic papers should undergo. (During my teaching career, I have seen the then-new edition of one of the most popular books in POM quote an erroneous example that Goldratt had taught one of the authors-a freshly minted Goldratt Associate. A simple LP check would have prevented that error, but Goldratt scorns LP. Evidently, the authors did not check Goldratt’s work with care. So, perhaps he could have cleared the peer review hurdle after all. Be that as it may, I tried to provide some of the “flavor” of such a review in this paper. After all, it is just one in a long series of papers written by academics who cite Goldratt.)
To counterbalance the criticism, however, we must note that CC- although identical to the old spirit of PERT/CPM-provides a fresh opportunity for improvement by a renewed holistic approach to project planning and execution. The paper lists some steps that can be taken almost immediately-such as changing the sequence in which we teach project scheduling models. It also discusses potential future enhancements based on studying project-scheduling issues in relevant combinations, rather than in isolation. Both practitioners and academics have a role in making this happen.
References
Cabanis-Brewin, )., (1999). Debate over CCPM gets a verbal shrug from TOC guru Goldratt. PM Network, 13 (December), 49-52.
Chu, C., Proth, J.-M., & Xie, X. (1993). Supply management in assembly systems. Naval Research logistics, 40, 933-949.
Demeulemeester, E.L. & Herroelen, W.S. (2002). Project Scheduling: A Reaserh Hardbook. Boston: Kluwer Academic Publishers.
Deming, W.E. (1986). Out of the crisis. Cambridge, MA: MIT Press.
Elmaghraby, S.E. (1977). Activity networks: Project planning and control by network models. New York: Wiley.
Erenguc, S., Tirupati, D., & Woodruff, D. (1997). Introduction to special issue on capacity constrained planning and scheduling. Production and Operations Management, 6(1), 1-2.
Globerson, S. (2000). PMBOK and the critical chain. PM Network, 14(5), 63-66.
Goldratt, E.M. (1988). Computerized shop floor scheduling. International Ioumal of Production Research, 26(3), 443-455.
Goldratt, E.M. (1997). Critical chain. Great Barrington, MA: North River Press.
Goldratt, E.M., & Cox, J. (1984). The goal. Croton-onHudson, NY: North River Press.
Goldratt, E.M., & Fox, R.E. (1986). The Race. Croton-on-Hudson, NY: North River Press.
Gutierrez, G.J., & Kouvelis, P. (1991). Parkinson’s law and its implications for project management. Management Science, 37, 990- 1001.
Herroelen, W., & Leus, R. (2001). On the merits and pitfalls of critical chain scheduling. Journal of Operations Management, 19, 559- 577.
Herroelen, W., Leus, R., & Demeulemeester, E. (2002). Critical chain project scheduling: Do not oversimplify. Project Management, 33(4), 48-60.
Hopp, W.J., & Spearman, M.L. (2001). Factory physics. (2nd ed.). Boston: Irwin.
Kumar, A. (1989). Component inventory costs in an assembly problem with uncertain supplier lead-times. IIE Transactions, 21(2), 112-121.
Lawrence, S.R., & Buss, A.M. (1994). Shifting production bottlenecks: Causes, cures, and conundrums. Production and Operations Management, 3(1), 21-37.
Leach, L.P. (2000). Critical chain project management. Boston: Artech House.
Maylor, H. (2001). Beyond the Gantt chart: Project management moving on. European Management Journal, 19(1), 92-100.
McKay, K.N. & Morton, T.E. (1998). Critical chain. IIE Transactions, 30(8), 759-62.
Morton, T.E. & Pentico, D.W. (1993). Heuristic scheduling systems with applications to production systems and project management. New York: Wiley.
Nahmias, S. (1989). Operations analysis. Boston: Irwin.
O’Brien, J.J. (1965). CPM in construction management: Scheduling by the critical path method. New York: McGraw-Hill.
Project Management Institute (1996). A guide to the project management body of knowledge (PMBOK Guide). Newtown Square, PA: Author.
Pervozvansky, A.A. (1975). Mathematical models in production management (Russian). Moscow: Nauka. [See pp. 451-452 and Section 7.7.]
Pinedo, M. (1997). Commentary on “an exposition of multiple constraint scheduling as implemented in the goal system”. Production and Operations, Management, 6(1), 25-27.
Portougal, V.M. (1972). Constrained resource intensity allocation to tasks in project planning (Russian). Ekonomika i Mathematicheskie Metody, 9(5), 761-763.
Raz, T., Barnes, R., & Dvir, D. (2003). A critical look at critical chain project management. Project Management Journal, 34(4), 24-32.
Raz, T., & Marshall, R. (1996). Effect of resource constraints on float calculations in project networks. International Journal of Project Management, 14(4), 241-248.
Ronen, B., & Starr, M.K. (1990). Synchronized manufacturing as in OPT: From practice to theory. Computers and Industrial Engineering, 18(8), 585-600.
Ronen, B. & Trietsch, D. (1988). A decision support system for purchasing management of large projects. Operations Research, 36(6), 882-890.
Schonberger, R.J. (1981). Why projects are “always” late: A rationale based on manual simulation of a PERT/CPM network. Interfaces, 11(5), 66-70.
Shingo, S. (1988). Non-stock production: The Shingo system for continuous improvement. Stamford, CT: Productivity Press.
Simons, J.V., & Simpson, W.P., III. (1997). An exposition of multiple constraint scheduling as implemented in the goal system (formerly DISASTER(TM)). Production and Operations Management, 6(1), 3-22.
Spearman, M.L. (1997). On the theory of constraints and the goal system. Production and Operations Management, 6(1), 28-33.
Trietsch, D. (2004). Stochastic economic balance principles for project planning: Feeding buffers, crashing and sequencing. Proceedings of the ORSNZ Conference, The University of Auckland, November 27-29, 35-44. http://staff.business.auckland.ac.nz/ staffpages/dtriets/Rose.htm
Trietsch, D. (in press-a). The effect of systemic errors on optimal project buffers. International Journal of Project Management. http://staff.business.auckland.ac.nz/ staffpages/ dtriets/Rose.htm
Trietsch, D. (in press-b). From management by constraints (MBC) to management by criticalities (MBC II). Human Systems Management. http://staff.business.auckland.ac.nz/ staffpages/dtriets/Rose.htm
Trietsch, D., & Baker, K.R. (1993). Basic techniques for lot streaming. Operations Research, 41(6), 1065-1076.
Wiest, J.D. (1964). Some properties of schedules for large projects with limited resources. Operations Research, 12, 395-418.
Wilkins, B. (1984). Judge orders software firm to hand over source code. Computerworld, July 9, 2.
DAN TRIETSCH, ISOM Department, University of Auckland, Old Choral Hall, 7 Symonds Street, Auckland
DAN TRIETSCH is Associate Professor of Operations Management at Auckland University. Previously, he taught at Tel Aviv University, Northwestern (Kellogg), Naval Postgraduate School (NPGS), and (as Professor of IE) at American University of Armenia. He holds a BSME from the Technion-Israel Institute of Technology, MBA (Cum Laude; specialization in OR) and PhD (Summa Cum Laude; specialization in transportation) from Tel Aviv University. Before his postgraduate studies, he had worked as an irrigation engineer on large projects. As a faculty member at NPGS, he acted as an internal consultant at several repair depots in the US Navy (large project organizations), combining IE and TQ methods with MBC to achieve focused improvements. Later, he was involved in industrial improvement projects in Armenia. His main publications appeared in Transportation Science, Transportation Research, SIAM Journal of Applied Mathematics, NETWORKS, Operations Research, European Journal of Operational Research, journal of the Society of Operational Research, IIE Transactions, Journal of Quality Technology, and Quality Engineering. He is also the author of a book on statistical quality control (published by World Scientific).
Copyright Project Management Institute Mar 2005
Comments