Why CPM is not good enough for Scheduling Projects

1

Why CPM is not good enough for Scheduling Projects Tapan P Bagchi, Adjunct Professor, IIM Lucknow, Lucknow, India 226013

Abstract—Even with the widespread adoption of CPM, particularly Gantt charts, project managers miss deadlines, pay for overtime and penalties, tackle low morale and fatigue and perhaps most critically, struggle with limited resources. This paper tutors the gritty individuals on doing projects by Critical Chain Project Management (CCPM)—a 10-year old innovation. NASA, ITT, BOSCH, Honeywell, Lucent Technologies, TATA Steel and many others now regularly use CCPM—for its proven benefits. CCPM’s major strength is its vastly effective capability in resolving resource contentions and minimizing time overruns— without affecting the quality of deliverables. As we suggest, CCPM easily deserves to fully displace CPM as the primary instrument for project planners. This tutorial is designed to considerably aid stakeholders in the project ecosystem which repeatedly suffers “things not going right.” Indeed, many find CCPM’s promise appealing. But a fear prevails that the shift to CCPM will fill the organization with more confusion, uncertainty, and anxiety—“do we have a software for it?” MSProject® is used throughout this tutorial to demonstrate that even such a common tool can enable one to easily incorporate the essentials of CCPM on real projects and haul in material benefits.

for the limited resources and thus delays project completion, no matter how cautiously the plans were prepared. In fact, as numerous studies on project delays have indicated, the widespread use of CPM as the primary method for project planning regularly leads to serious resource sharing conflicts in the field (PM Knowledge Center [2]. CPM rarely facilitates easy handoffs. Additionally, as pointed out by Eliyahu Goldratt [3] and others, reliance on CPM as the sole planning methodology frequently causes projects to miss deadlines and commitments to stakeholders—for rectifiable reasons (Standish [4]). A major risk omitted from mitigation in CPM indeed is the contention for scarce resources. Goldratt proposed an innovative planning strategy as the solution to such plunders. Known as Critical Chain Project Management (CCPM), at its core is the application of resource constrained project scheduling. Additionally, Goldratt offered methods to address several attendant problems in project planning and execution attributable to human behavior and tendencies. These include multitasking, student syndrome, sandbagging time estimates, false notions about what it means to be productive, and not doing good handovers to the next resource when a task is completed (DRM Associates [5]. II. CRITICAL CHAIN PROJECT SCHEDULING

I. INTRODUCTION

Meredith and Mantel [1] remark that a project schedule converts a project work breakdown structure (WBS) into an operating timetable. This in turn guides the physical start of each project activity—many being dependent on each other—done at right instants this completes the project. On the face of it the CPM network helps one to plan, monitor and control the progress of the project on a timeline. Leaving aside a multitude of organizational and resourcebehavior issues, a critical lacunae with CPM is that it assumes that the resources required to complete project activities are available in unlimited quantity. In other words, the project will never be starved of resources. In reality one finds that project resources—construction manpower, cranes, software test platforms, etc. etc.—are available recurrently in limited number or quantity, enforcing what is called resource constraints on the execution of the project. In practice this leads to contention

CCPM is a groundbreaking spin-off of the Theory of Constraints (TOC) proposed by Goldratt [3]. TOC says, any system must have a constraint (bottleneck) that limits its output. In fact Goldratt initially wanted to improve productivity and profits of manufacturing systems— through the judicious scheduling and management of bottlenecks in the system. In reality, TOC is not a “theory” based on scientific experiments or basic laws. Rather it is a collection of some very sensible heuristics, as system management applications of TOC have later endorsed. The key upshots of adopting TOC in the context of manufacturing enterprises are shown in Table 1. TOC identifies, exploits and resolves bottlenecks to improve system throughput. With the same inspiration, Goldratt identified a key bottleneck in projects, the limited availability of resources that typically impedes their progress. This resource availability bottleneck generates a critical chain of project activities. The critical chain thus

2 contrasts with a project network’s critical path, which only endures technological dependencies among the tasks. The critical chain satisfies both the technological as well as resource constraints binding the project. It is defined as the longest time any feasible task sequence would actually take to reach from the project’s start to its finish, while being constrained by resources. Owing to these hard constraints—technical dependencies and resource limits— the project cannot be done any faster than what the critical chain dictates. TABLE I THE KEY TAKEAWAYS OF GOLDRATT’S PROPOSAL FOR MANUFACTURERS (GOLDRATT AND COX [6])  The goal of any manufacturing operation is to earn a profit. 

One of the three measures of profitability is throughput, or the amount of product moved through a plant via sales.



A second measure of profitability is inventory, or the money the factory uses to buy items it plans to sell.



A third measure of profitability is operational expense, which is the money the factory spends to turn inventory into throughput.



The major impediment to a factory earning as much money as it should is bottlenecks, or constraints in the manufacturing system.



The first step in overcoming a bottleneck is identifying what the bottleneck consists of.



The second step in overcoming a bottleneck is deciding how to utilize it.



The third step in overcoming a bottleneck is making a priority of utilizing the problem.



The fourth step in overcoming a bottleneck is taking steps to prevent it from recurring.



The fifth step in overcoming a bottleneck is using the identification and resolution process to utilize the next bottleneck because bottlenecks tend to move from one part of a manufacturing operation to another.

Thus Goldratt reformed the “unlimited availability of resources” basis in projects planned by CPM. His new method (now a decade old) focuses on technological dependencies among tasks, as well as the bounds imposed by the typical instance of limited resources. Goldratt dubbed it “critical chain project scheduling.” For its proven merits the method has already been embraced by many leading organizations and government agencies; the Israeli aircraft industry, Tata Steel, Lucent Technologies, Boeing, HP, ITT, NASA and the US Army are among a hundred others who have saved much in cost and time—by adopting

CCPM. As Millhiser and Szmerekovsky [7] point out, CCPM now comprises a substantial body of knowledge (theory and heuristics) and cumulative experience, augmented by enriched SW capabilities that now decidedly facilitate its adoption by project planners. This last aspect is demonstrated in this tutorial. III. THE ILLS OF CPM Many defects innate in the Critical Path Methodology (CPM) have frustrated planners and executers of projects for over decades. Often the impact is exasperating and costly. Briefly, these include safety padding task durations by the project crew when the “inputs” to develop the project network (generally called the CPM or PERT network) are put forward—to ensure a “high probability” of on time completion. Yet, few projects finish on time (Standish [4]). The heightened focus on time alone driven by CPM also often prompts starting each task as early as possible “for the resources to be maximally and immediately productive” and to help minimize the effect of anticipated uncertainties and delays. Similarly, multitasking (an attempt by human resources to be maximally “productive” by performing multiple tasks together) becomes routine. Focusing only on committed dates and not delivering the results earlier even when the task at hand is finished, etc. etc. abound when the delivery deadline for each task is seen as paramount. Nonetheless, two crucial maladies inherent in CPM are undeniable—(a) ignoring the potential contention for scarce resources— CPM disregards resource use. Also (b), CPM counts on the “statistical safety” built into time estimates for each activity when one quotes completion times of which one is >90% confident. Beyond these is the effect of typical human behavior when one focuses only on task milestones— instants when each task must be individually completed as dictated by the CPM Gantt chart. How Goldratt boldly challenged these practices is stimulating. Indeed, to prepare his alternative approach he diligently examined such ills in the extant mode of planning and executing real projects. He probed their reasons and devised their mitigation. IV. CCPM—THE INITIAL MOTIVATION We use an instructive example to first underline a critical shortfall of CPM. We transliterate here two original project activity network diagrams (Figures 1 and 2) provided on line by the PM Knowledge Center [2]. These diagrams are prominently informative. The PERT/CPM AON diagram of an example project is shown in Figure 1. The numbers inside the circles are activity IDs with the number at top right being their respective duration, in days. Figures 1 and 2 will promptly highlight a critical ill of CPM. The network comprises two critical paths, 1 – 2 – 3 – 6 – 9 – 11, and 1 – 2 – 5 – 8 – 10 – 11 respectively, both 22 days.

3

Fig. 1: An example PERT/CPM network of 11 tasks

Note that so far, we have not disclosed any other constraints—other than the technological (sequential) dependency shown by arrows existing among the tasks shown. Next, we are told that when started, many of these tasks would demand use of a single renewable resource (here labor), the respective requirements for which are shown in Figure 2 in the lower right position of each circle.

With labor requirements as declared, would we have enough of them to complete this project still in 22 days? This would encompass one’s processing the manpower data for each concurrently running tasks in Figure 1. To assist in the manipulations we can use MSProject® [9] and allocate the resources (labor) to each activity 1, 2, 3, etc. as dictated by Figure 2. To begin this investigation, labor availability throughout the project is initially set generously at 10. Figure 3 shows the project’s labor loading profile under these conditions and also its Gantt chart. The Gantt chart indicates that the project might still be completed in 22 days—10 laborers are sufficient for it, though some might be idling here and there. Now we impose a constraint—and assign only 6 laborers really available to work on this project. The Gantt chart and the resource use profile plot of Figure 3 together suggest that 6 laborers wouldn’t probably be enough to complete the project in 22 days. This can be checked precisely by limiting labor availability to 6 and then performing resource leveling—a feature in MSProject®-our presently chosen workhorse. This SW allows one to view the project plan both without and with the leveling of resources. For the case in Figure 4 we did not “level” the daily use of resources—we kept them at their “as and when required” levels. Without executing such leveling this helped in keeping the project duration unchanged at 22 days. But the impact, as the resource use profile graph in Figure 4 shows, would be that the laborers would be now overloaded, perhaps an unacceptable situation.

Fig. 2: Fig. 1 network showing resource requirements

Fig. 3: The project’s Resource use profile and Gantt chart with resource availability set at 10

4

Fig 4: Resource overload and the Gantt chart with resource available limited to 6 laborers

A couple of observations must be immediately made. Figure 4 shows the effect of resource constrained project scheduling (the projected overloading of labor)— accomplished here using MSProject®’s built-in resource loading capability. This effect is not conveyed by the plain CPM chart of Figure 1. This demonstrates a major shortcoming of the traditional CPM scheduling methodology, which, for most planners, “finishes with the drawing of Figure 1” and a defective Gantt chart. The critical path method (CPM) thus ignores the effect of limited resources on a project’s duration or any potential overloading of resources that one wouldn’t escape in the field except by Divinity’s grace. Next we examine the effect of leveling the day-to-day fluctuation of labor requirements (what HR would normally desire—in order to minimize hiring-firing), as long as no more than 6 workers are engaged on any day. For this we utilize MSProject®’s built-in resource leveling capability. The impact promptly quantified is that resource requirement would now remain at or below 6 throughout, but project duration would extend to 24 days. And indeed there is no overload anywhere over those 24 days which MSProject® ensures—something we had also hoped to achieve. Figure 5 shows this. Note again that the mere drawing of the conventional CPM chart (Figure 1) or its Gantt chart—which reflects only technological dependency of the tasks (but not the constraints due to limited

resources)—does not convey such information. This again is inadequate for the project planner’s achieving prudent resource allocation and possible time-resource tradeoffs. As displayed in Figure 5, limiting labor to 6 would force project completion to shift to the right—it would get delayed by 2 days. What we have revealed is one crucial inadequacy of traditional CPM scheduling—it does not incorporate the impact of limited resources on a project. Thus CPM does not accomplish resource constrained scheduling. This was a fundamental shortfall of CPM noted by Goldratt. He also observed several other behavioral maladies of the project’s human resources working with their sole focus on time and task deadlines as induced by CPM. These led to the making of Critical Chain Project Management (CCPM). Note that we used some additional analytical skills to generate Figure 5 from Figure 4. This required achieving constrained resource leveling to deliver a resourceconstrained project schedule. This job is not trivial. The exact analytical procedure for this is still unknown as the problem is NP-hard in computational science; it belongs to the complex class of job shop scheduling problems (Kastor and Sirakoulis [10], Ponz-Tienda et al. [11] and Sonmez et al. [12]). However, several methods have been researched to do resource leveling effectively even if not optimally. Some of these methods are heuristic but they do provide “good enough” answers for project managers.

5

Fig. 5: Impact of resource leveling after limiting resource availability to 6 laborers

Many such heuristics are now built into the workings of project management SW such as MSProject®, Primavera® P6 and Prochain® etc. (Herroelen [13]). Independent computational studies are periodically done to check the capability of such SW (see for instance, Kastor and Sirakoulis, [10]). V. THE MOTIVATION FOR PLANNING PROJECTS BY CRITICAL CHAINS – THE HUMAN ASPECT In the foreseeable future humans will continue to be the main actors in projects. This picture has changed in manufacturing, as more and more factories are now run by robots. Therefore, the project system no matter how capably designed, must still integrate with the human system. Hence, before we describe the nuts and bolts of converting the traditional project planning method— essentially CPM/PERT—to CCPM (page 10 below), it is worth to review what various adopters of CCPM have narrated as their reflections and experience on the people front. Many have attributed astonishing improvements to it in a variety of organizations spanning construction, new product development, software and R&D (Cox and Schleier [14]). Still, this being a new approach, one would seek reliable evidence that the CPM/PERT  CCPM conversion does actually yield measurable improvement—amid humans. But, as with most management innovations, there

are many who point to the difficulties it imposes even if there already are many enthusiastic supporters of CCPM. This discussion is perhaps best balanced by Millhiser and Szmerekovsky [7], whose inferences we recall below. A key challenge in moving to CCPM is noted to be the vital cultural shift required for the project’s stakeholders— the actors in the project—including top management, project planners, estimators, those entrusted to monitor and control the progress of the project, and very importantly, the contractors, executers and workers. Happily by now hundreds of case studies of encounters with CCPM at private, public and government agencies have been documented. From Japan the news is firmly positive. Many were inspired by pilot CCPM applications in some industries, which in Hokkaido led to over 4000 projects based on the Theory of Constraints. In US NASA’s LaRC wind tunnel facility now uses CCPM to conduct effective bidding for selling its testing capability. It is proud of its reduction of execution risks. Initially there were some disbelief as these newscasts came out. Some questioned if those good results were not due to the Hawthorne Effect (changes in one’s behavior when one is being studied, see The Economist [38]). Subsequently, a balanced appraisal—even if it was literally inconclusive—indicated that such effect was unlikely in project organizations (Cabanis-Brewin [8]). The reason perhaps is that the critical chain methodology attacks the

6 ills of the conventional project ecosystem on many fronts, a vital one being the mindset and cultural disposition of all those involved. Some of these practices exist as discernable features of the traditional embrace of CPM. We note first certain behavioral aspects of the project’s resources—the humans involved. CCPM would involve a well-meaning but deliberate cultural shift (Hagemann [15]). Later we examine some structural deficits of CPM/PERT—the key ones being (a) its disregard for resource contention developing when execution begins, and (b) the inclusion of “safety” time cushions as contingencies in each individual task. CCPM removes these individual time cushions to aggregated buffers placed at end of the project’s longest resource-constrained task sequence—called the critical chain, and the feeding chains. So contingency in CCPM is put at the end of the chain of tasks, not at each padded individual task. Most managers are profit oriented. Many feel that a productive worker is a busy worker—a belief traceable to the advent of scientific management. Thus each project resource must “individually aim” at completing his/her own task by the management-assigned deadline, an information derivable for everyone from CPM’s Gantt chart. While the details are tersely discussed by Goldratt [3] and Leach [16], they all point that such directives lead to many anomalous behavior, including the student syndrome, (perceived as well as actual) procrastination, the “three-minute egg boiling” criterion for task completion, not alerting the next resource when a task is near complete, etc. etc. Then one observes the ever-presence of “Murphy”, Parkinson’s Law, and perhaps most critically, the start-stop waste caused by multitasking, often seen and even expected of resources. The details of such pervasive phenomena in the conventional planning and execution of projects may be read in Goldratt [3], Newbold [17], Elton and Roe [18], Leach [16] and Budd and Cerveny [19]. The mechanical aspect of adopting CCPM is relatively easy. Hence the central message here is that certain anomalous behavioral issues remain firmly set in the backdrop of projects repeatedly executed in the firm by CPM/PERT culture. Skinner [20] called this operant conditioning and demonstrated this. But these issues—many rectifiable— often harm projects a great deal. Goldratt carefully examined these issues and alongside providing his innovation in project planning, he extended many valuable suggestions to amend such anomalous human behavior. Millhiser and Szmerekovsky [7] also cite instances shared by industry practitioners who gained much by attacking project execution on the human front alone. VI. THE MOTIVATION FOR ADOPTING CCPM – STRUCTURAL ASPECTS When a new theory is proposed (presently, CCPM to push over CPM as a more reliable method to assure project success—in time, cost and scope), the scientific method

would check the claim’s validity by experiment. Indeed, no theory is ever “proven.” It is accepted as good enough to use until it is rejected by a single experiment as Leach [16] says, or is replaced by a better predictor of reality. With CCPM, the project planning procedure fundamentally changes. However, the impact is impressive. Briefly, first, the original task-time estimates (prepared for CPM) are cut in half by the 50% rule. This is done to counteract the worker/estimator’s tendency to build in some contingent safety in every estimate—time that one is “90% sure or more” of achieving even when things will go wrong when least expected, interruptions will occur, he/she will be called out to help somewhere else, etc. etc. This tendency of quoting the 90% number is a common practice as workers imagine “contingency.” This is how CPM receives its estimates. In R&D work it may be genuinely difficult to estimate times. But in many situations padding is just “expected.” Sometimes this padding is done even in formal methods, as with a weather-related allowance put in construction planning (Sears et al. [21]). Goldratt observed that time overrun risks handled by such safety padding is generally wasteful and it leads to other problems as well. Hence he removed these individual task allowances and statistically aggregated them, and added half (50%) of that resulting safety time to an end-of-project time buffer. A buffer is the deliberate placement of an in-process time inventory to account for statistical (common cause, Deming [22]) fluctuations in the project system. Indeed Goldratt’s views on behavior such as Murphy’s Law, Parkinson’s Law, Student syndrome etc. being active in projects are quite difficult to argue with. Also, he placed feeding buffers at the end of each noncritical chains. Placement of buffers is Goldratt’s second action with the CPM task estimate data. ITT’s Night Vision project planning is an illustration of such action (Cook [23]). We review buffer sizing suggestions in a subsequent section where we also describe the use of resource buffers to ensure timely availability of the means to carry out the next task. In reality these are alerts for resources and suppliers needed to perform the next task. Something is worth pointing out at this juncture. Goldratt designed CCPM so as to protect the entire project from task duration variation risks of slippage—by buffers, not by ensuring each individual task’s completion on time as is aimed in CPM’s deterministic world by focusing on individual task deadlines. Further, as Leach [16] notes, CCPM provides workers the opportunity to view their success not in a win/lose manner near the deadline, as it happens in CPM. Variation in CCPM is normal and acceptable, but evidence shows that buffers protect (Hagemann [15]) Still the ultimate difference between CPM/PERT planning and CCPM is the explicit consideration, requirement analysis, allocation, leveling and management of the project’s resources. Indeed the planning methodology shifts from CPM, which is discovering the

7 longest (“critical”) path through the activity network, to resource constrained project planning, as noted at the outset of this tutorial. This leads to a different deliverable for the project planner. It is not the critical path that is now delivered. Rather, the planner produces a new artefact, known as the critical chain of the project network. As a result, resource requirements get explicitly accounted for and any contentions for limited renewable resources such as labor, skilled manpower, cranes, computer processors, etc. are proactively eliminated from becoming barriers during the project’s execution. In the material below we illustrate how this is achieved. We quickly note that a key strength of CCPM indeed is its explicit consideration of resources. It first does resource loading of all the tasks logically sequenced. It then does resource leveling— removal of conflicts whenever demand exceeds supply. CPM disregards this action. It is to be noted that less than 5% project managers resource level their plans (Leach [16]). Few projects, if any, have infinite resources. The project’s progress and any needed control actions in CCPM are not based on watching the workers’ achievement of their respective task deadlines or milestones. Project progress is measured by monitoring the consumption (or penetration) of the strategically placed feeding (time) buffers and the project buffer (sized in time units) on the chains. This is akin to one’s watching the space between the vehicle one is driving and the car ahead of it; on the highway one backs off or acts when one gets too close (i.e., when the safety “buffer” has been penetrated). VII. THE CCPM METHODOLOGY We recall first the specific steps to identify and manage the critical chain in a project (DRM Associates [5]). The steps are: 1. Ready with the WBS, spell out each project activity in a PERT chart, recording its completion time estimate as done in CPM, its sequential dependency on other tasks, and additionally, its resource requirements. 2. Cut each task completion estimate aggressively by 50%. The rational is that the initial field estimates would have a high level of safety allowance built into it—to ensure completion within the initial estimates with >90% confidence (Leach [16]). 3. Develop the activity network model for the project indicating carefully the resource requirements of each activity. 4. Load the tasks with resources as needed by them and develop the resource use profile of the complete project. Impose any known resource restrictions on this profile. 5. Level the resources within their respective availabilities to eliminate resource contentions—to produce the resource constrained project schedule. A project management SW may help here.

6.

Identify the critical chain—this is the longest sequence of tasks from start to finish reflecting both path (technological) as well as resource dependencies for the tasks—after resolving resource contentions. (This identification may have to be done manually! In our knowledge no publicly available SW does this step automatically yet.) 7. Insert the project buffer at the end of the critical chain. Its size should be 50% of the length of the critical chain (see below for alternatives). 8. Protect the critical chain from possible resource starving by employing resource buffers. 9. Locate all non-critical chains in the network. These chains have their own resource requirements and they “feed” the critical chain. Size and place Feeding Buffers at the end of each of these non-critical chains— to help protect the critical chain from excessive or lost times and uncertainties encountered in the execution of the non-critical tasks. 10. Locate any task chains that have no predecessors. These chains comprise gating tasks. Start these gating tasks as late as possible, to prevent the tendency of the resources’ multitasking in the initial days of the project. 11. Ensure that each resource delivers Roadrunner performance as in a relay race. Each should work as quickly as possible and pass on their work to the next worker as soon as one completes her own. 12. To assist each resource in contributing their best, without being externally constrained, provide them with activity durations and estimated start times as the resource constrained schedule indicates—not Gantt chart milestones to look forward to. This will encourage resources to pass on their work as soon as it is done to the next resource, and not wait till milestone dates are reached. 13. Managers should use buffer consumption status (often shown on the project’s “fever chart” (Leach [16]) to control the project. Buffers should trigger recovery actions when needed. Clearly these steps require (a) a belief that CCPM will deliver, and (b) a committed champion to orchestrate it. The champion must be the best one you can find. He will find his technicians—good people who have the right skill and right behavior. Table 3 in Millhiser and Szmerekovsky [7] tells that many organizations have documented cases vouching the success of CCPM in their organizations. Also, anecdotes are now spreading of renewed worker enthusiasm, enhanced sense of team work, and more joy in working on CCPM projects. The authors of this tutorial witnessed this personally at Tata Steel. Issues still remain. The 50% or even the square root basis for sizing buffers has not been established as optimal—at best it is a heuristic. And a champion is still needed to see a CCPM project successfully through,

8 playing a role similar to what a master black belt does in Six Sigma projects. Also, the needed SW tools are still rather few—even MSProject® requires a fair amount of educated tweaking to serve as a usable workhorse for CCPM, the noteworthy quality of it being the ease with which it delivers resource leveling under different priorities. If you are new to MSProject®, refer to the links provided in MSProject® [9] under References. A working knowledge will suffice. (Note that for the inspired, an addon called Prochain® is available. But this tutorial is about internalizing and benefitting from CCPM, not some software. Note that a SW may encourage digging for more and more details, diverting attention from the imperative issues.) We recall first certain principles that should be internalized in order to facilitate one’s embarking on CCPM. Thus we cover buffer sizing and resource leveling notions. We then turn to solved examples and applications. For those still on the CPM fence, we urge them to first stir up their personal motivation to do this tutorial, for to learn and be productive with CCPM, one will have to work with project data and the keyboard. Recollect the quagmire resulting in the straight attempt to rely dutifully on CPM alone—to plan and execute projects. CPM is seductively easy to adopt—all engineering students learn it. The calculations are all at high school level and one can actually get the Gantt chart up on the wall in precious little time. Even PERT is intellectually appealing and easy to conduct—though it serves no material needs of management. But what about managing a project with limited resources, and when each human actor builds in a great deal of fat into time estimates for safety; yet deadlines are regularly missed. As Goldratt says, Murphys and Parkinsons would rarely rest! Many do workers not report completed tasks—they cite the deadline. Furthermore, is the next guy ready when I get to his desk (never mind I never told him that I was coming)? This is how a positive performance variance—finishing before target time—is frequently lost. And most of us become “students” when we are given submission deadlines—we postpone those ppts till the night before. Many feel OK with multitasking, even though it is known to delay projects and hamper the quality of all but only trivial deliverables. Goldratt provided some structural and some behavioral solutions here. As authors, we therefore feel that one should spend some quiet hours to contemplate and explore which elements of CCPM one might incorporate both in culture and methodology when starting a new project. That said, can a practicing manager make a case for ignoring resource bottlenecks—something that CPM innocently induces? On the other hand, is adopting CCPM tough? In this paper we demonstrate that for the switch to the technical procedures of CCPM, the universally available and inexpensive SW tools may be enough—to get one going, once one sets the sights for the switch and takes the steps. The human front, however, is indisputably challenging and requires top

management’s direct involvement and blessings, along with the appointment of the company’s CCPM Champion. Beyond this, of course, for hardcore project managers remains the challenge of resourcing multiple projects from a pool with prioritized projects and shared resources. CCPM sets up capacity buffers for it (see Leach [16]. CPM is grossly ineffective here (Leach [16], [24]). VIII SIZING BUFFERS AND THEIR USE IN TIME OVERRUN Statistical evidence now exists which says that when task times are individually inflated for the sake of “safety”, it reduces their effectiveness in protecting project overruns. Rather one should pool such safetys to draw the benefits (Yeo and Ning [25]). Goldratt suggests that adding only half of the pooled safety time as a buffer (project or feeding) at the end of the appropriate chain is enough. The rationale is that some tasks would finish late, yet others are likely to finish earlier and generate gains due to the roadrunner mode of task execution. We show these buffers in the CCPM examples to follow. Note that the idea of inserting buffers existed before Goldratt (Trietsch [26]). And their correct size is still being debated. However, we accept its merit as a risk management tool (implemented with the fever chart) and we regard its use as a useful heuristic, till perhaps a better sizing basis emerges. The two common formulas for sizing CCPM buffers available today are as follows. Buffer size = 50% of the length of the critical (or feeding) chain. Alternatively, Buffer size = Square root of the Sum of variances of tasks on the critical (or feeding) chain. The second formula has been shown to have a higher validity through numerical experiments. On the other hand, the first is simpler to use. However the buffers are sized, they are designed to serve as risk management (control) tools when the project is executing. The buffers are used to suggest whether the project should be left alone, or the problem should be assessed, or corrective actions should be initiated. To do this each buffer is monitored to check if part or all of it has been consumed by delays in activities leading up to that buffer. Goldratt called such monitoring spotting the penetration state of the buffer (Figure 6). In CCPM the status of penetration for each feeding buffer, and the project buffer, are periodically updated by asking the resources working on the pertinent chain of activities how many days they estimate to the completion of their activity. These completions may vary from their original estimates—some tasks get behind while others get ahead. Such change shows up in the updates of the buffer status. Management actions follow the buffer penetration monitoring guide rules, as shown in Figure 6. A fever chart can also display buffer status and prompt appropriate management action if necessary (Leach [16], page 120).

9

Chain’s end Buffer ID Project buffer

 Penetration into Buffer Buffer status

Penetration stays in the lower third of the buffer Penetration reaches the top third part of the buffer

Feeding buffer 1

Feeding buffer 2

Penetration reaches the middle third part of the buffer

Corrective action No action is needed

Act immediately to rectify the cause of time slippage Plan corrective actions

Fig.6: Buffer management in CCPM – Monitoring and Actions due for buffer penetration caused by time delays on chains

IX. RESOURCE LEVELING AND RESOURCE CONSTRAINED PROJECT SCHEDULING The biggest challenge a CPM network presents is how to release the tasks for execution when the renewable resources (manpower, equipment, computers, vehicles, etc.) are limited. This is not surprising because by design CPM focuses only on technological dependency among the tasks while completely disregarding any issues of problems resourcing those tasks for execution when resources are limited and must be used and reused as needed. In reality a buffer cushions the chain’s delivery date. Many experts have strived to tackle the issue of resource allocation, their leveling, and scheduling resources in projects as well as manufacturing systems. The job shop is one example. Constrained resource allocation in projects is another. Exact methods such as linear integer programming can address only toy-size problems (Iranagh and Sonmez [27]). The real life ones are too complex and large. For one’s comfort, the complexity of such scheduling problems has been established—it is NP-hard—too complex to tackle by known analytical methods or enumeration (Lee [37], Herroelen [13], Meredith and Mantel [1]). Several heuristic methods for resource allocation in projects have been proposed, some being borrowed from studies on job shop scheduling (Yamada and Nakano [39], Dilmaghani [28]). But, as is well known, heuristic methods do not provide exact solutions. An example is the resource leveling heuristic due to Burgess and Killbrew [29], which seeks to minimize the sum of squares of period to period variations in resource use in a project, by shifting tasks within slacks. A vital step in using CCPM is to obtain a resource constrained activity schedule for the project that incorporates both the technological (or logical) dependency among the tasks, and the limited availability of resources (Goldratt [3]. Achieving this is fundamental because

resource contentions are thus removed (a basic risk in CPM) and the critical and feeding chains may then be identified. But, as we just indicated, the exact attainment of this is not yet possible. An optimized resource constrained schedule is thus still beyond the reach of the project planner. However, several very useful and well-performing heuristic methods to produce schedules of practical value do exist. There are now several software vendors including MSProject®, Primavera® and Prochain® who have builtin heuristics to deliver resource-constrained project schedules. In fact, several such SW have been compared for their relative performance on assorted problems (Kastor and Sirakoulis [10]). Genetic algorithms have also been formulated for the task, some reaching near-optimal schedules (Ponz-Tienda et al. [11]). For the practitioner, tools such as MSProject® or Primavera® heuristically deliver resource-constrained schedules that are quite satisfactory. In this paper we have used MSProject® exclusively in our examples for leveling and resource-constrained scheduling—for this tool is easily accessed by most. In the sections below we work out three different resource constrained project scheduling cases. We tackle each by CCPM. We develop the resource constrained schedule, identify the critical and feeding chains for each, and then size their buffers. The first problem is a tworesource 10-activity project (Figure 9-4, Meredith and Mantel [1], 2012). The second problem is from NASA’s Langley Research Center (LaRC) that originally suffered numerous ills of CPM (Hagemann [15]). The third problem is due to Cook’s lecture material from MIT (IPPD 3/14/2000) [30]. This problem is posed as a tutorial exercise to the reader, to be done in MSProject®. (We provide also the solution.) It engages three renewable resources, each capacitated by limited quantity.

10 Case 1: A Two-resource 10-activity Resource Constrained Project This multi-resource project scheduling problem is presented in the Meredith-Mantel text on Project Management (Meredith and Mantel [1]) as a resource leveling exercise. Two resources—A and B—are used in the project shown in Figure 7. The task IDs appear on the arcs (a, b, etc.) with their (CPM) duration estimates shown alongside the IDs. For instance, task a would take 20 days to complete. Further, each task’s resource usage is indicated by two numbers, the first being the requirement for Resource A while the second indicates the units of resource B. Thus task a requires 4 units of A and 0 unit of B. Our object here is to prepare a CCPM plan for this project complete with project and feeding buffers. It is given that both A and B are constrained at 6 units. The straightforward CPM scheduling of Figure 7 with resource availability for both A and B set at 6 units and the resource use profile leveled produces a project duration (makespan) of 67 days. When the CCPM exercise that follows is complete, we would compare these 67 days to that produced by CCPM. Step 1 of the procedure shown on page 9 is already done, as we have the data on Figure 7 with us. Next, in order to produce the critical chain, we cut each activity time estimate provided by 50%, and use MSProject® to construct the resource loaded activity network model (Figure 8). Note the new activity times, which are now at 50% of Figure 7’s numbers. The use profile for resource A is also visible in the top half of Figure 8. At this stage we have not leveled the resources. Note the overloading of resource B above its 600% availability line. The project’s duration at this resource unleveled stage is 22 days.

2

1

b, 20 2, 11

Before we move to find the critical chain for Figure 7, we shall have to produce the resource constrained schedule for it. This would require imposing the A max = 6 and B max = 6 constraints, leveling the resource allocations, and redoing the project schedule under this restriction. Thankfully, MSProject® does this job effortlessly, although the schedule it produces may not be optimum (i.e., a schedule containing the shortest critical chain.), for it uses undisclosed proprietary heuristics to do the leveling procedure. Figure 9 shows the leveled project schedule delivered within the A = B = 6 restriction. The project’s duration now extends to 35 days (recall that the unrestricted resource duration—Figure 8—was 22 days). Figure 9, being now the resource constrained schedule for the original project (Figure 7), contains the project’s critical chain—the longest chain of activities reflecting both technological (i.e., sequential) as well as resource constraints—connecting the project’s start to its finish. It may be shown that it is the chain comprises activities a, d and j. It may surprise you to notice gaps within the critical chain identified—tasks a, d and j in Figure 9 are not contiguous or “touching each other.” A gap may also occur when a feeding buffer pushes a critical chain task back. This is happens due to their individual resource requirements and is permissible (Leach [24], page 45). A caution is to be exercised in not to include such gaps in buffer sizing calculations (Leach [16]). But even with gaps the critical chain remains the true constraint in this project—it can’t deliver the results any faster.

d, 15

f, 14

3

4

6

0, 2

7

1, 1

h, 11 0, 2

5

Fig. 7: The AOA network of a Two-resource Project (Figure 9-4, Meredith and Mantel [1])

11

Fig. 8: The resource loaded but unleveled activity network model of Fig. 7

Wait, we aren’t done yet! We still have to identify the feeding chains in Figure 9, calculate and place these feeding buffers and the project buffer. Figure 10 shows the completed job. To reach it we had to manually identify the critical chain and all feeding chains in Figure 9, size and place them in the respective chains, and the redo the resource constrained scheduling once more—by leveling resource use by MSProject®. The critical chain is a-d-j-PBadj with the project buffer for it sized 11 days. This being a multi-resource project, the chain a-d-j-PBadj is constrained by both resources A and B, and it is the longest chain. There are four non-critical chains, “e”, “f”,”bg” and “chi”. Their sizes are 2.5 days, 4 days, 6 days and 10 days respectively. In practice, once the critical chain schedule is complete, we would set up the buffer management system with fever charts—to monitor the execution of the project, i.e., if dates are slipping. What merits a mention is that the CCPM project of Figure 10 is a 49.5 days long. By contrast, a CPM based schedule for Figure 7 after leveling of resources within the A = B = 6 max constraint predicted the duration of the project to be 67 days. And, in view of today’s project management experts, the CCPM schedule is more reliable, key reasons being its better management of risk—the explicit consideration of resource contention, and the statistical cumulation of individual task contingencies into buffers (Leach [24], Styne [31]). When individual allowances are cumulated, their sum’s variance is the square of the sum of squares of individual standard deviations. The other benefit of cumulating is that the distribution of the sum approaches the normal distribution. This distribution would concentrate contingency as the chance of a large overrun would be reduced (Leach [16]). Note also that this exercise tackled a multi-resource project. So CCPM works for multiple resources as well. We must confess to one shortfall of the foregoing procedure. Figure 10 is not the optimum resource constrained schedule (Kastor and Sirakoulis [10], Steiness [32]). The critical and feeding chains were not determined by some optimizing analytical method—we used the leveling heuristic built within MSProject® for it. A superior method would perhaps be to use Genetic algorithms (Bagchi [33], Iranagh and Sonmez [27], Wuliang et al. [34]). Note also, since we did not optimize the schedule, the solution we produced is not unique—other shorter schedules are indeed possible. But what have demonstrated with a common SW is quite straightforward and would be handy to implement.

12

Fig. 9: The resource leveled activity network model of Figure 7—this is the resource constrained schedule, ready now for the identification of the critical chain

Fig. 10: The final resource constrained project schedule for the network of Figure 7—with the project and feeding buffers

13 Case 2: The NASA Wind Tunnel With world class capabilities that it has diligently built, NASA’s wind tunnel facilities now sell high quality wind test results (Hagemann [15]). A key test facility is operated at the Langley Research Center (LaRC) at Hampton, VA which must schedule each test and also maximize the utilization of its human and physical resources. One test, for instance, uses a high temperature tunnel, actually a liquidfuel rocket engine lying on its side. The test piece is mounted where the apex of the flame occurs—to simulate the effects of a re-entry into the earth’s atmosphere. Quality of the test results is paramount. Other non-technical matters being subjugated by this concern for quality were being managed by PERT/CPM. The difficulties arose in LaRC’s facing resource contention, and the noticeable presence of multitasking by technicians and others. To tackle these, safety margins (padding) were built into task times—as risk mitigation initiatives. At that moment-of-truth, LaRC considered adopting CCPM—to “drastically reduce” multitasking (which it was felt was causing padding), and to help resolve resource contentions as CCPM promised. CCPM was also expected to raise the productivity of the wind tunnel testing cycle—by cutting interferences and consequent delays. Much action also occurred on the human front—top managers were oriented on CCPM first, followed by hands-on training for all concerned. A high level champion was considered to be crucial and was appointed. By his daily involvement in the pilot project the champion committed to ensuring that things worked the CCPM way.

For illustration an 8-resource “project” (one complete test) is discussed here, each resource—technician, tunnel, data acquisition system, etc.—has the capacity of “1” unit. For illustration, the proprietary task times are 2 days each. Figure 11 is the partial display of CPM/PERT chart for the project. Its purpose here is two-fold: (a) it shows the technological sequencing of the tasks as dictated by the tunnel test protocol, and (b) it makes the contention for the limited resources very much visible. The chart indicates that the duration of the project (without resolving any resource contentions) will be 12 days. The critical path is a1 – b1 – b2 - b3 – b4 – a5. But MSProject® importantly reveals that the project has conflicts in the demand for Resources 2, 3 and 6, which if unresolved would not allow the project to be done in 12 days—the simple-minded CPM projection. If resources are “leveled” by a proactive and experienced planner—perhaps manually—the project seems doable in 14 days. But that is not a CPM projection! To convert to CCPM one would follow the steps on page7. First, task times would be cut by 50%, then resource contentions resolved by leveling, and lastly the critical chain identified. It ts a1 – a2 – d3 – b2 – b3 – b4 - a5. The project buffer, size 3 days, follows the critical chain. Project duration—with all resource contentions fixed and buffers incorporated—still is 12 days, with time overrun and resource missing risks much reduced. The feeding buffers (Table 1) would be located y on non-critical chains. The project would be monitored by the consumption of these eight buffers.

Fig. 11: The CPM chart for the NASA testing project

14

Fig. 12: Partial display of the CCPM chart for the NASA testing project

Table 1: Project and Feeding Buffer sizes for the critical chain in Fig.12.

Project Buffer a1-a2-d3-b2-b4-a5

3.5 days

FB a3-a4

1 day

FB b1

0.5 day

FB c1-c2

1 day

FB d1

0.5 day

FB c3-d3

1 day

FB e1-e2-e3

1.5 days

FB f1-f2

1 day

We described above the mechanical steps to produce a CCPM model. When adopted, this approach would eliminate any contention for resources, and also minimize time overrun risk due to the incorporation of and control by buffer management. The human side of the CPM  CCPM conversion, however, would be fraught with challenges: Regular and disciplined use of project management was not the prevailing culture at LaRC before CCPM entered its modality. Multitasking by technicians was common causing interruptions and task lengths to expand. The routine therefore was to pad timings to tackle contingent delays. Resource contention—another cause of delays and

multitasking at LaRC—was accepted as a fact of life, for CPM did not ask for nor help in its resolution! But the pressure to increase productivity and utilization of the test facilities became high since a prospect for expanding LaRC’s business developed beyond its being a NASA Research Lab. LaRC management recognized several things at this juncture. They had to deliver quality test results from the wind tunnels, yet they had to raise productivity and test data volume for additional and paying users, not just NASA scientists. This could be done if somehow resource contentions could be made zero, overtime decreased and staff morale improved. The staff comprised Aeronautical Engineers, Model Designers, Fabricators, Test Engineers, Technicians and others. They routinely experienced surprises by shifting deadlines, leave restrictions and hardware not being ready when needed. CCPM had the promise. But several other changes would also be required. A high-level champion would have to lead and drive the effort. Therefore, the first CCPM project was designed as a pilot CCPM demonstration project. Management were to be briefed, for many practices would change. Training was to be all pervasive—all operating units were brought up to the CCPM mode of thinking. For instance, staff who beat the deadline would now be rewarded. The structural changes—mainly the elimination

15 of resource conflicts—led to less uncertainties and therefore the need for padding to remain safe in delivery commitments. Yet morale got a boost because with more predictable plans one could take vacations, attend training classes or seminars. As Hagemann [15] writes, leaving CPM behind led LaRC to tell success stories. The staff discovered, for instance, the construction of a valid PERT chart (Step 1 on page 9) requires an extensive amount of communication among the staff. Earlier, research engineers told the technicians what they had to do, just before they had to do it. Now they build the plan together and own it (feel accountable for it) together. The loss of overtime got compensated by the ability to regularly take weekends off. These delivered productivity and notably raised the number of wind tunnel tests completed per LaRC body count. Case 3: MIT’s take on CCPM It is not surprising that CCPM material finds itself now in MIT’s MBA and BS syllabi. Furthermore, several related theses have been completed in recent years at the Sloan School. A presentation dubbed Lecture 11: Critical Chain and the Design Process from MIT appears on line at IPPD 3/14/00 [30] in which a development project is illustrated. In the paragraphs below we present the same problem as a CCPM drill for the reader. You should try this using MSProject®. The tasks and their associated details in a product design and testing project—with a unique deliverable—are shown in Table 2. To get familiar with the MSProject® environment use the activity times, and task dependencies from the predecessor information in Table 2. Go ahead, and boot up MSProject®. Then set up the project as a CPM exercise, using help from the links at MSProject® [7] listed in the reference. Your screen, using Table 2 data, should appear as it does in Figure 13. CPM says the project will take 15 days to complete. But there may be resource overloads in this plan! The first step in CCPM is to cut all activity estimates by 50%. Then the project plan is prepared considering together all task dependencies—and resource requirements—for each task. Without leveling of the resources done, this stage should show any resource overloading present in this plan. Modify your CPM plan (Figure 13) to reflect (a) estimate reductions by 50%, and (b) the resource loading of tasks by the respective resources they each need. At this stage you should be at Figure 14. Resource overload may be caused by two reasons. (a) Resources as supplied to the project (i.e., their availability) may be limited to enable execution of some other project tasks—implying that the project at hand is infeasible to execute without adding more resources to it. (b) There may be contention among the tasks looking for the same resource(s) at the same instant.

Table 2. Tasks, their Estimated Times in days, Predecessors and Resources required

Task

90% completion time estimate in days 2

Resources required

Predecessors

E

None

4

P

Internal design

2

T

External design Build External Integration

4

E

Basic function specs None

3

T

2

P, E

Self-test Acceptance ASM Integration 2 Final Test

2 3 1 2

P, E P T P, E

2

P, E

Internal design Basic function specs Build Internal

External design Build Internal, Build External None Self-test Integration ASM Acceptance, Integration 2

Case (a) needs management action. Case (b) may be managed by delaying some tasks within their technological sequencing requirements. This is called resource leveling, usually an automated action in the SW user’s control. The automated generally leveling step gives one several options, including assigning priorities to tasks to indicate which tasks may wait their turn to use some resource and which ones should go ahead. Those web links should help now. When you have cut the activity times and loaded the tasks with required resources, you should be at Figure 14. This display will show any resource overloading (unless you have accidentally leveled the resources—a step you can easily reverse without causing any damage!). Thus Figure 14 is at the unleveled stage of your assignment. Any overload present here will be visible on the Gantt chart— with a human icon in the second column of the display (see Figure 14). Overload condition is also visible on the Resource Graph display retrievable from the first dropdown menu on the MSProject® screen.

16

Fig. 13: The CPM Chart for the IPPD 3/14/00 project

Fig. 14: This Gantt chart shows if any resources are overloaded, indicating there is contention

17

You are moving well! To deliver the critical chain (CCPM) project schedule you will have to build now the resource constrained project schedule. This task is greatly facilitated by a project management SW that has heuristics to do the job. As indicated on page 12 of this tutorial, this problem is akin to job shop scheduling and is NP-hard computationally (Lee [37]). In many cases therefore resource constrained scheduling in projects cannot be done optimally. MSProject® also uses built-in proprietary heuristics that deliver results generally acceptable in practice. This step, “resource leveling”, will lead to Figure 15. Now the resources are all leveled and all are within their respective availability limit—1 unit each. This is the fundamental input to the CCPM procedure. At this stage of your work, no resource is overloaded! What remains now is identifying the critical chain, and the feeding chains, in this resource constrained network. Several solutions are possible, because different attempts of resource leveling by heuristic methods will possibly yield differing versions of Figure 15. For Figure 15 you must verify these: The critical chain for this MIT exercise is Internal Design  External design  Build External  Build Internal  Integration  ASM  Integration 2  Final Test  Project Buffer (size 4 days – how?)

This is the longest chain that the project must traverse in that order to complete itself as resources P, E and T are limited, each being available exactly as 1 unit. Feeding chains are three, since we must protect different locations (activities) of the critical chain. Thus Feeding Chain #1 Basic Function  Feeding Buffer BF (size 1 day) Feeding Chain #2 Self-test  Feeding Buffer s-t (size 0.5 day) Feeding Chain #3 And Acceptance  Feeding Buffer A (size 0.75 days) Figure 16 shows the complete critical chain schedule for this project. The buffers have been sized using Goldratt’s 50% sizing rule (page 9). In practice, for control one would also set up fever charts or the three-color boxes for each buffer—to keep an eye on their consumption—to flag alerts if activities are slipping (see Figure 6). For example, for the project buffer (PB = 4 days) we shall have a three-color control box as follows. Remaining buffer 0 to 1.33 days Control Action: Leave the project running

Remaining buffer 1.34 to 2.66 days Control Action: Plan mitigation of delays in activities

Fig. 15: The resource leveled IPPD 3/14/00 schedule that has all resource contentions removed

Remaining buffer 2.67 to 4.00 days Control Action: Act to eliminate delays in the project

18

Fig. 16: The complete CCPM chart with Project and Feeding Buffers for the IPPD 3/14/00 exercise

X. DIFFICULTIES IN ADOPTING CCPM It is difficult to find cases where a project’s could be attributed to CCPM. Yes, in many instances the implementation did not target or achieve the changes necessary for moving into CCPM. Some of these are mentioned below. Since the potential benefits, particularly in doing project management with limited resources, are substantial, at minimum a pilot project should be attempted—led by a competent and capable CCPM champion within the company (NASA and TATA did this). This person must be soundly knowledgeable in the practice of project management and also made well-versed in CCPM with requisite training. A consultant can advise or coach, the champion alone will identify with the company and pour in passion. As with any new venture, the best way to prepare for CCPM, once the buzz has reached top management, is not to promise results before a thorough risk management exercise is done. Many things can go wrong in moving into the CCPM initiative (Styne [31]). Traditionally, individual activity estimates incorporate some contingency. Commitments are made for task completion dates only. With the buffers built in, there may be a tendency to waste time, procrastinate, and even multitask. Have the resources been leveled correctly and constraints identified? Etc. etc.

Have these risks been identified—to then move toward their analysis, prioritization, mitigation and monitoring? A systematic procedure, as Styne shows, can reduce risks, but earnestness is a must. This will lead to an effective implementation plan. Beyond this and certainly no less critically, top management must ensure that external risks have been addressed and resolved. The regulators, inspectors, permits and financiers are sometimes the major constraints in the delivery of the project. A fully complete auto factory had once to be shifted off its foundations (Tata Sons Limited [35]). XI. THE HUMAN SIDE OF CCPM The technical aspects of CCPM can be quickly grasped by any organization that regularly runs and delivers projects. But one cannot pretend likewise that the company’s culture would be simple to re-mold. Has top management accepted this major change in how the company’s projects will now be done? Have the incentives been clearly articulated to them—with instances? Juran’s Cost of Poor Quality (Juran and Gryna [36]) basis is how many Six Sigma projects are justified. Can the effect of poor project management be similarly compiled from the company’s or public records? This is no trivial task but securing management’s forthright support by divulging

19 such data or by not doing it will make or break any CCPM initiative. Leadership – having on board the Champion, the CCPM Guru—we repeat again, is a must! In these initial days of industry experimenting with CCPM, one person worth his weight in gold is this individual. He will be the resident CCPM steward, motivator, guide, coach, consultant to planners and estimators, PMO office staff, and the resources, everyone! Training—it is recommended—must begin with the top getting briefed first. Material difference has been found where top management rolled up sleeves and sat down to define the charter, scope and deliverables—of the CCPM conversion project itself. It is they who should first grasp why watching delivery dates yields little. Why resource contentions are the real culprits when one misses deadlines and commitments to customers. The new language—buffers, resource alerts, critical chains, feeding chains, etc.—has a lot more power than the Gantt chart in enabling the project’s successful execution. Yes, CCPM is a heuristic and its guidelines are not yet optimized. But the like of it (i.e., another more effective way to plan and manage projects), as vouched by its adopters, is yet to appear in project management. Recall again when you had to wait in your last project for a critical resource and CPM gave no answer. What follows is some samples of what CCPM users such as ITT, NASA, TATA and others have to suggest to others. The shift in mindset CPM  CCPM will be demanded from everyone once the new method formally comes on board. In return, adopters say, headaches will greatly reduce. With CCPM no contention for scarce resources will normally develop, thus no surprises a la “equipment tied up elsewhere.” Furthermore, the buffers absorb and help control delay shocks, hence the plan’s delivery deadlines are more reliable and predictable. Task handovers are done in roadrunner mode. So resources are able to also plan for their personal needs much better (Hagemann [15]). Individuals operate in CCPM not by watching deadlines for the tasks at hand. Rather the team watches and reviews the penetration of the time buffers. Most do buffer reviews weekly. Workers are not reprimanded for missing their own deadlines—for fluctuations will occur; and this is a mindset shift for managers who have earlier used CPM dates to appraise an individual’s performance. In CCPM the whole team is held accountable for delivery, not individuals. With the roadrunner mode of working—you will get the feeling of accomplishment when you do a good and clean handover to the next guy. For this each tasks’ expectations (quality, time, etc.) must be clear and resources identified for the next task on the chain must be resourced buffered (alerted)—ahead of the handover. No multitasking—as its usefulness has been shown to be an illusion. It’s not much fun to eat a pizza a bit here and a bit there. Hold the slice and finish it when it’s warm!

Multitasking usually occurs when the resource you need to carry on is not available just when you require it and you are forced to wait. CCPM holds that in such situations there is likely to be a yet unresolved resource contention present. NASA has found multitasking to be a major cause for project delays (Hagemann [15]). If you are a compulsive multitasker, you are not a reliable project resource. You are under the illusion that staying busy is being productive. But you are likely delaying others—and the project. Think through the task you are about to start, get organized, and once you are on the roll, don’t interrupt it deliberately. If it is a large task, break it into byte size chunks (and show it in the network) but finish each chunk before stopping. Are the shortage of the needed resources interrupting you? No procrastination—“students” are dead! They must reform or be fired. Know clearly when your own task will be considered complete. Report as soon as you are done with your task. These practices bring in a different style of working. Leach [16] provides many reasons why this should be the way we handle projects. Consider that only 15% projects globally are done on time, within budget, and delivered complete in scope (Standish [4]). And in forty years that figure has not changed. XII. TO CONCLUDE… You can’t afford nor do you have any good reason to be stuck with CPM anymore! Projects are important stepping stones in one’s career. Projects can turn around an organization. If you persist with the deceptively comforting CPM charts, your enduring headaches with projects aren’t likely to leave you soon either. Frankly, you probably read through this tutorial without touching the keyboard. Perhaps you clicked on some of the links under References—a lot of good material is there. But if you already know some basics in project management or have worked on projects, in half a day you can get MSProject® up and running to do CCPM. MSProject® is nicely crafted—with a lot of useful features. With the help of the links provided under References you will now only require the will to leave CPM behind. Indeed mastering the mechanical aspects of CCPM planning by a SW—as shown here—is straightforward for today’s professionals. It is the behavioral and cultural front where you will be challenged. So will be your management and the project organization (Leach [16], Hagemann [15]). But the evidence is plenty that those who have made the switch to CCPM successfully have cut risks, improved resource utilization, and met deadlines with high reliability— something CPM won’t even pretend to assure.

20 REFERENCES [1] Meredith J R and S J Mantel (2012). Project Management: A Managerial Approach, Wiley [2] PM Knowledge Center (2017). http://www.pmknowledgecenter.com/category/proje ct-management-tags/critical-chain [3] Goldratt, E M (1997). Critical Chain, North River Press. [4] Standish (2015). https://www.infoq.com/articles/software-failurereasons; https://www.infoq.com/news/2010/11/getback-to-work [5] DRM Associates (2016). Critical chain project management, http://www.npdsolutions.com/critical.html [6] Goldratt, E M and Jeff Cox (2012). The Goal: A Process of Ongoing Improvement, North River Press [7] Millhiser W P and J G Szmerekovsky (2012). Teaching Critical Chain Project Management: The Academic Debate and Illustrative Examples, INFORMS Transactions on Education. [8] Cabanis-Brewin J (1999). So…So what? Debate over CCPM gets a verbal shrug from TOC Guru Goldratt. PM Network, 13(12), 49-52. [9] MSProject® (2017). Manuals and learning material are available at http://www.tacticalprojectmanagement.com/micro soft-project-dashboard-tutorial/ ; https://www.tutorialspoint.com/ms_project/ms_pr oject_quick_guide.htm ; https://www.tutorialspoint.com/ms_project/ms_pr oject_tutorial.pdf [10] Kastor and Sirakoulis (2009). The effectiveness of resource leveling tools for Resource Constrained Project Scheduling Problem, International Journal of Project Management, 27, pp. 493-500. [11] Ponz-Tienda J L, V Yepes, E Pellicer and J MorenoFlores (2012). The resource leveling problem with multiple resources using an adaptive genetic algorithm, Automation in Construction, 29, 161-172. [12] Sonmez, Rifat, M A Abbasi Iranagh and F Uysal (2016). Critical sequence crashing heuristic for resource-constrained discrete time-cost trade-off problem, J. Construction Management, 142(3), 1-12. [13] Herroelen, Willy (2001). On the merits and pitfalls of critical chain scheduling, J Operations Management, 19(5), 559-577. [14] Cox J F and J G Schleier (2010). Theory of Constraints Handbook, McGraw Hill [15] Hagemann, A G (2001). Use of the critical chain project management technique at NASA, Langley Research Center, IEEE Explore, August 7.

[16] Leach, L P (2000). Critical Chain Project Management, Artech House [17] Newbold, R C (1998). Project Management in the Fast Lane: Applying the Theory of Constraints, St Lucie Press. [18] Elton J and J Roe (1998). Bringing discipline to project management, Harvard Business Review, 76(2), 153-159. [19] Budd, C S and J Cerveny (2010). A Critical Chain Project Management Primer, in J F Cox and J G Schleier, eds, Theory of Constraints Handbook, 17(2), McGraw-Hill, 45-77. [20] Skinner, B F (1953). Science and Human Behavior, Collier Macmillan. [21] Sears, S K, G A Sears and R H Clough (2010). A Practical Guide to Field Construction Management, Wiley. [22] Deming, W E (1982). Out of Crisis, MIT Press. [23] Cook, C C (1998). Applying Critical Chain to improve Management of Uncertainty in Projects, Masters Thesis, MIT. [24] Leach, L P (1999). Critical chain project management improves project performance, Project Management Journal, June, 39-51. [25] Yeo, K T and J H Ning (2006). Managing uncertainty in major equipment procurement in engineering projects, Eur. J. Oper. Res., 171(1), 123134 [26] Trietsch, D (2005). Why a critical path by any other name would smell less sweet? Toward a holistic approach to PERT/CPM, Project Management J., 36(1), 27-36. [27] Iranagh, M A and R Sonmez (2012). A genetic algorithm for resource leveling of construction projects, in Proceedings of Annual ARCOM Conference, 3-5, September, Edinburgh. [28] Dilmaghani, F (2008). Critical Chain Project Management (CCPM) at BOSCH Security Systems (CCTV) Eindhoven, MSc Thesis, August. [29] Burgess, A R and J B Killbrew (1962). Variation in Activity Level on a Cyclic Arrow Diagram, J Industrial Engineering, 122(3), 125-132. [30] IPPD 3/14/00 (2017). http://web.mit.edu/2.742/www/sylabus/3_14.pdf [31] MIT CCPM Lecture 11 by Steven Cook (2017). In IPPD 3/14/00 slides, http://web.mit.edu/2.742/www/sylabus/3_14.pdf [32] Steiness, Kenneth (2014). www.mpug.com [33] Bagchi, Tapan P (1999). Multiobjective Scheduling by Genetic Algorithms, Kluwer. [34] Wuliang P, Su Hui and Hao Yongping (2013). A genetic algorithm for the critical chain project scheduling problem, I. J. of Digital Content Technology and its applications, 7(3), 571-578

21 [35] Tata Sons Limited (2010). Small Wonder, The making of the Nano, [email protected] [36] Juran, J M and F M Gryna (1980). Quality Planning and Analysis, 2nd ed., McGraw-Hill. [37] Lee, ChungUng (1975). A multi-resource leveling algorithm for project networks, Calhoun NPS Institutional archive, Dudley Knox Library. [38] The Economist (2008). The Hawthorne Effect, November 3. http://www.economist.com/node/12510632 [39] Yamada and Nakano (1997). Job shop scheduling, Chapter 7, Genetic Algorithms in Engineering, IEE Control Engineering Series 55, ISBN 0 85296 903 3.