Critical chain project management improves project performance
This paper describes the theory and practice of critical chain project management (CCPM). CCPM provides a substantial step in the ongoing improvement to the Project Management Body of Knowledge. The critical chain differs from the critical path by including resource dependencies and never changing. CCPM improves the project plan by ensuring that it is feasible and immune from reasonable common cause variation (uncertainty or statistical fluctuations). It does this by aggregating uncertainty into buffers at the end of activity paths (or chains). The project buffer protects the overall project completion on the critical chain path, and feeding buffers protect the critical chain from path merging. Buffer management enhances measurement and decision-making for project control. CCPM implements required changes in resource behavior, including elimination of date-driven activity performance and multitasking. Most of all, CCPM improves the focus of the project manager and performers. Projects that use CCPM have a greatly improved record of schedule, cost, and scope performance. Experience with CCPM projects demonstrates completion in less than one half the time of projects using previous planning and control methods.
Keywords: critical chain project management; project schedule; project buffers
Critical chain project management (CCPM) adds to the present Project Management Body of Knowledge (PMBOK™), as described in A Guide to the Project Management Body of Knowledge (PMBOK™ Guide) (Project Management Institute Standards Committee, 1996) and supporting literature, in the areas of project planning, activity performance, and control. It reengineers project planning and management to eliminate common problems that lead to poor project performance.
CCPM emphasizes focusing on the project schedule. Further, it also reduces project changes and the major source of project cost overruns by improving schedule performance. It accomplishes these results by changing the project plan, the project measurement and control system, and certain behaviors by the project team and supporting personnel. The critical chain plan effectively eliminates most resource contention before the project starts, and uses buffers for project control.
System thinking and the Theory of Constraints (TOC) were used to develop CCPM. The CCPM project planning and control process directly addresses uncertainty and variation in project activity duration. It helps eliminate undesirable behaviors fostered by using scheduled dates and milestones within a project plan. It focuses on developing and managing project performance to meet or exceed reduced activity times, thereby reducing overall project duration.
CCPM departs from the PMBOK™ Guide and supporting literature as follows. CCPM:
Specifies the critical chain, rather than the critical path, as the project constraint. This path includes resource dependencies, and does not change during project execution.
Uses 50% probable activity times, and aggregates allowances for uncertainty of estimates and activity performance into “buffers” at the end of activity chains.
Uses the buffers as an immediate and direct measurement tool to control project schedule.
Defines the constraint for multiple projects as the constraining company resource. It links projects through this resource, using buffers to account for activity duration variability.
Seeks to change project team behavior; encouraging reporting early completion of activities and elimination of multitasking.
Applications Demonstrate Effectiveness
Real-world applications of CPPM demonstrate effectiveness over a wide range of project types. Large and small companies demonstrate similar improvements for project types, including construction, software development, and high-technology research and development. Companies such as Texas Instruments, Lucent Technologies, Honeywell, and Harris Semiconductor complete projects in one half or less the time of previous or concurrent similar projects, or as compared to industry benchmarks.
Harris Semiconductor manufactures semiconductor wafers. Harris used CCPM to build a new 8” wafer plant. The total investment for a plant of this size is in the range of $250 million. The revenue for such a plant is in the range of $2 million per day! (Raw material cost is very small.) The industry standard to build a 6” wafer plant is 30 months. The industry standard to get the plant up and running to 90% of capacity is about 46 months. Harris completed the plant, and brought it up to 90% production in 14 months. Harris presented their results at a recent conference hosted by the Avraham Y. Goldratt Institute. A video is available through their Internet page.
The Israeli Aircraft Industry employs about 15,000 people. One of their major functions is to maintain jumbo jets used in passenger service. A particular type of maintenance called “type D” normally takes 46 days in the industry. The penalty for nonperformance to schedule is very steep ... $60,000 per day, because the airlines need the planes back into scheduled service. The company had been paying up to $25 million per year in penalties. A letter from the manager to Dr. Goldratt (included on www.Goldratt.com) notes, “ ... we succeeded to drop our average turnaround time per aircraft visit from three months to two weeks and to increase our backlog from two months to one year.”
Lucent Technologies applies CCPM to increasing numbers of R&D projects. Many of the projects are still in operation; but general feedback demonstrates plan reductions in excess of 25%, and performance to date using very little of the project buffers. Early application to a software development project that was thought to be impossible completed in June 1997, with buffer to spare.
Critical Chain Theory
CCPM uses three theory tools to improve project performance. It applies the theory to eliminate six specific project effects that lead to project schedule overruns. (TOC identifies the six items as effects, rather than causes, because they have underlying causes.)
Theory 1: Theory of Constraints. CCPM applies the TOC to project management. Goldratt first described TOC in The Goal (1984) when applied it to production systems. TOC can be summarized by: “Any system must have a constraint. Otherwise, its output would increase without bound, or go to zero.” Most people readily accept this statement as self-evident fact.
The primary message of The Goal is focus. Focus on the goal of the company. Focus on the constraint that blocks achieving the goal of the company. The Goal ends with five focusing steps, which apply to any physical system. These steps are:
1. Identify the system constraint.
2. Exploit the system constraint.
3. Subordinate everything else to the system constraint.
4. Elevate the system constraint, and
5. If, in the previous step, a new constraint has been uncovered, repeat the process. Do not let inertia become the system constraint.
Dr. Goldratt used the focusing steps to develop critical chain project management (CCPM), and CCPM managers use them to guide projects. Dr. Goldratt’s TOC analysis identifies the core problem leading to most project failure as, “failure to effectively manage uncertainty.” The core problem leads to six undesired effects. The CCPM process uses TOC and the following theory to eliminate the causes of these effects.
Theory 2: Common Cause Variation. Dr. W. Edwards Deming (1989) included “an understanding of variation” as one of his four points of profound knowledge. He identified two types of variation: (1) Common Cause Variation: A cause that is inherent in the system. The responsibility of management. (2) Special Cause Variation: A cause that is specific to some group of workers, or to a particular production worker, or to a specific machine, or to a specific local condition.
Projects have common cause variation in the performance time of activities. This variation represents uncertainty in the activity performance time. Although the time to perform individual project activities may be independent of each other, project activity networks define activity dependence. The project logic demands that successor activities cannot start until the predecessor activities complete (for the most frequent finish-to-start activity connection). Thus, projects have statistical fluctuations and dependent events, the same key issues that Dr. Goldratt (1984) addresses for production.
■ About the Author
Larry P. Leach is the principal of Quality Systems, a manufacturing consulting firm that specializes in leading the implementation of the new critical chain method of project management. He has an M.S. in business management from the University of Idaho and mechanical engineering from the University of Connecticut. He is a member of PMI and the American Society for Quality Control. He has published many papers on related topics, and authored a self-published book, The Critical Chain Fieldbook. Prior to founding Quality Systems, he worked at VP-level in several Fortune 500 companies, and was a systems analysis division director for the U.S. Department of Energy. His experience as a project manager includes research and development projects for construction projects.
Figure 1. Typical Project Activity Performance Time Probability Distributions
Dr. Goldratt’s improvements for production take advantage of (exploit) the reality of common cause variation. Figure 1 illustrates a typical project activity performance time distribution. The solid curve (left ordinate) shows the probability of a given time on the abscissa. The dotted line shows the cumulative probability of completing the activity in a time less than or equal to the time on the abscissa. Note the left skew of the distribution and the long tail to the right; this is typical of the common cause variation for many project activities.
This common cause variation in activity performance is not an exceptional event, such as discrete project risk events. PERT attempted to estimate the impact of this common cause variation using three activity duration estimates, but for a variety of reasons did not succeed. The PMBOK™ Guide and other literature still mention PERT in this fashion, although from my experience it is little used today. The PMBOK™ Guide acknowledges this. PERT diagrams, as referred to in much of the project literature, and in many project software packages, are simply a way to show the project network logic independent of the time scale; not an application of the three time estimates. Some projects use methods such as simulation and Monte Carlo analysis to assess the impact of activity duration and cost uncertainty. While these methods propose a way to estimate uncertainty, they do not pose in my view an effective systematic method to manage it.
Theory 3: Statistical Laws Governing Common Cause Variation. The PMBOK™ Guide (Table 11-2) describes the well-known statistical law of aggregation: “The project variance is the sum of the individual activity variances.” Note that in statistical terminology, variance is the square of the standard deviation, usually represented by “s2” or the Greek sigma squared. For a given statistical distribution, it requires a given number of standard deviations to provide a cumulative probability to that point. For example, with a normal distribution, one standard deviation plus or minus represents 67% of the data, or a cumulative probability that 67% of the time a result will fall within one standard deviation of the mean, plus or minus.
The statistical method to combine variances means that we can protect a chain of activities to the same level of probability with much less total contingency time than we can protect each individual activity. Aggregation of the contingency times dramatically reduces the overall estimated time for a chain of activities. Consider a chain of four activities, each of which has a 50% probability estimated duration of one time unit, and a 90% probable estimated activity duration of two time units. If we include the contingency in each activity, the chain of activities is eight units long. If we use the law of aggregation, we can protect the whole chain to 90% probability by scheduling the individual activities at their 50% estimates (a total of four units), and adding a two-unit buffer at the end of the chain, for a total of six units.
A second factor that comes into play in aggregating activities is the central limit theorem. The central limit theorem states “as sample size increases, the distribution of the sample mean becomes closer to the normal distribution” (Moore & McCabe, 1993). Many project activities have a skewed probability distribution. Figure 1 illustrates this general shape. The distributions have an absolute minimum time, and a long tail to the right, meaning that they can take much longer than the average time. The central limit theorem means that a project chain of activities has a more symmetrical distribution. This is true whether we know the real distributions or not.
Undesired Effect 1: Excessive Activity Duration Estimates. Most project managers include contingency time within each activity estimate to account for individual activity common cause variation. Contingency is defined as the difference between the 95% probable estimate and the 50% probable estimate. The existence or the amount of this contingency time is not usually specified. People estimating activity times for a project usually believe that the project manager wants low-risk activity times; perhaps a probability of 80% to 95% completion on, or less than, the activity duration estimate.
Most project plans that I have examined fail to specify the probability and confidence expected for activity duration estimates. Most fail to provide a quantitative basis for the activity duration estimate. The PMBOK™ Guide states, “Activity duration estimates should always include some indications of the range of possible results,” and refers to risk management as the control technique. However, risk management in the project management literature generally fails to differentiate between common cause and special cause variation.
Construction projects are somewhat exceptional, having access to extensive quantitative data to estimate activity duration. For example, the 1997 National Construction Estimator (Kiley, 1996) uses an extensive database, which lists many potential contributors to common cause uncertainty in the estimates. It states that many of these uncertainty items have ranges of several tens of percents of the cost estimate. Therefore, in many cases, they have the same potential impact on schedule.
Figure 1 illustrates that the “low-risk” duration estimate can be two or more times the 50% probable estimate. In most project environments, people feel good if they complete an activity by the due date, and feel bad if they overrun the due date. This reinforces their attempts to estimate high probability completion times.
Walter A. Shewhart (1986), mentor to W. Edwards Deming, wrote:
Thus, attempts to deal with uncertainty by including contingency in individual activity estimates are fruitless, and significantly extend project plan duration.
Undesired Effect 2: Little Actual Activity Positive Variation. Activity performance behavior leads to little positive variation. If estimates are 50% probable, people should complete and report 50% of the activities early. If estimates are 99% probable, 99% of the activities should report as completed early. Usually, people report most of the activities as done on the scheduled date, and they report a significant fraction (~10%) of the activities as late.
Goldratt (1997) described several effects that led to performance systematically overrunning estimates, although the estimates initially had extensive contingency time. Many people have a tendency to wait until activities get really urgent before they work on them. This is especially true for busy people in high demand: that is, all of the most important people the project manager is counting on to get the critical path work done on time. If people believe they have some extra time in their estimates, they are often willing to accept other “higher priority” work at the beginning of the scheduled activity duration. This tends to waste their contingency time before they start the activity, forcing them to perform most of the work in the later portion of the scheduled activity time. Then, if problems occur, there is no time to recover.
Figure 2 shows the typical work pattern of many people. Goldratt calls this the student syndrome. They do less than a third of the work on an activity during the first two-thirds of the activity duration, and the final two-thirds during the last third of the activity duration. They are more likely to find they have a problem to complete the activity in the remaining time during the last third of the scheduled activity time. If they are working above 100% capacity already to complete twothirds of the work in one-third of the time, it is unlikely they can keep to the activity duration. They have little chance to recover from an unanticipated problem, such as computer failures. This makes it feel like the activity was underestimated to begin with.
Meredith and Mantel (1995) state, “ ... operation of Parkinson’s Law ... clear and present danger. The work done on project elements is almost certain to ‘expand to fill the additional time.’” In Goldratt’s words, “the safety time is wasted.”
Failure to provide resources when needed impacts activities by extending the duration from the time the input is available until the activity can complete. Providing fewer resources than planned also extends the activity duration.
Undesired Effect 3: Failure to Pass on Positive Variation. Projects do not get the benefit of many actual early activity completions. Even if completed “early,” performing resources often fail to pass on positive variations. In most cultures, there is little or no reward for completing individual activities early, and punishment for being late or having quality problems. In many project environments, there is a significant disincentive to reporting an activity complete early. Work performed on “time and material” contracts results in less revenue if the work is completed early. Many companies budget work performed by internal functional organizations as if it were time and material contract work. If the functional organization completes the work in less time than estimated, they cannot continue to charge to the project. They must find alternative work for the resources. If individuals complete activities early, they get more to do. These cultures drive local optima, which means delivery on the scheduled date, but not before. There are many ways to justify keeping the potentially early result. We can put its review or completion at “low priority,” because it is not due yet, or we can “polish the apple.” The result is the same: we waste contingency time originally included in individual activity time estimates.
Figure 2. Typical Work Pattern
Examination of milestone performance in a very large project (over 15,000 activities) conforms very closely to Goldratt’s prediction that about 80% of the activity milestones are achieved exactly on the working scheduled date (i.e., exactly on the original planned duration). Only one or two activities have reported early completion (out of a sample of 3,000), and the rest later, including a few significantly later. This project consists of about 30 large subprojects, some of which contain yet smaller subprojects.
Undesired Effect 4: Project Delay Caused by Activity Path Merging. Most projects have multiple activity paths. All activity paths must merge into the critical path by the end of the project; if for no other reason than into a milestone that identifies project completion. Usually, the path merges tend to concentrate near the end of the project. One reason for this is that “assembly” or “test” operations tend to occur near the end of the project, requiring many elements to come together. The following discussion demonstrates how this becomes a primary cause of the well-known project “truth” that, “many projects complete 90% in the first year, and complete the final 10% in the second year.”
Activity path merging creates a filter that eliminates positive fluctuations, and passes on the longest delay. The reason is that merging activity paths means that all of the feeding paths are required to start the successor activity. Therefore, the successor activity cannot start until the latest of the merging activities completes.
Consider an activity on the project critical path that requires three separate inputs in order to start (see Figure 3). This is frequent in assembly operations, and in many project results, such as a major show or meeting event where everything has to be ready on opening day. Usually, there are many more than three. However, even with three, if each has a 50% chance of being done in the estimated time, the probability that at least one is late is over 88%! Even if each individual activity had a 90% probability of completion, the probability that at least one is late is still 30%, or nearly one out of three times.
The PMBOK™ Guide states, “Schedule simulation should be used on any large or complex project since traditional mathematical analysis techniques such as the Critical Path Method ... do not account for path convergence ... and thus tend to underestimate project durations.”
Figure 3. Impact of Activity Path Merging
Undesired Effect 5: Multitasking. Multitasking is the performance of multiple project activities “at the same time.” Some people refer to it as the “fractional head count.” Humans are not too good at rubbing their tummy and patting their head at the same time. People actually perform in a multiactivity mode by dividing time between the multiple activities. They might do this during the course of the day by working on one project in the morning and one in the afternoon.
Most people think of multitasking as a good way to improve efficiency. It ensures everyone is busy all of the time. Often, I have to wait for inputs or for someone to call back before I can get on with an activity. Multitasking makes good use of this time.
Goldratt (1984) demonstrated how focus on local efficiency could damage the overall performance of a system, an example of the phenomenon of suboptmization. He used the example of robots, which operated all of the time in order to show high efficiency. In the case of production, this leads to producing excess inventory, and may “plug” the constraint with work not necessary for current orders, increasing operating expense and delivery times with no positive benefit to the company as a whole.
Multitasking on project activities has a much worse impact. Consider a person who has to do three oneweek activities for three different projects (see Figure 4). If the person were permitted to work exclusively on each one, the first project would have its result in one week. The second project would have its output at the end of the second week, and the third project at the end of the third week. However, if the activity performer multitasks, spending for example one-third time each day on each project, none of the projects get their output until the end of the third week. All three activities have a three-week duration, potentially extending the overall duration of each project.
If multitasking is a normal way of business in a company, three weeks becomes the normal activity duration for this activity. Performance data supports this inflated activity duration. If this is a critical chain activity, the practice directly extends the duration of the project. Most companies admit to encouraging extensive multitasking.
Undesired Effect 6: Loss of Focus. Several aspects of current project planning make it difficult for the project manager to know where to focus to ensure project delivery. These include:
Early start schedules, which allow all activity paths to start at the same time. The instant jump to a highactivity level causes the project manager’s attention to become diffused.
Changing the critical path during project performance.
Attempts to exclusively use earned value for project control. Earned value does not discriminate between activities that affect the critical path and those that do not. It weights activities by dollars, not schedule importance. It gives no indication of the potential impact of paths parallel to the critical path.
Frequent use of earned value action thresholds that are too tight, causing too many control actions. Deming (1989) called this damaging behavior “tampering.” Tampering is attempting to fix variation that is within the statistical bounds of common cause variation. Tampering always damages process performance.
Critical Chain Plan Process
Critical Chain (Identify the Constraint). Goldratt (1997) extended the production application of TOC to projects. He identified the constraint of a project as the critical chain or “the sequence of dependent events that prevents the project from completing in a shorter interval. Resource dependencies determine the critical chain as much as do activity dependencies.”
Defining the constraint of a project in terms of the schedule derives from the impact that schedule has on project cost and project scope. The three conditions are dependent. As schedule increases with fixed deliverable scope, cost usually increases. As scope increases with fixed cost (or resources), schedule tends to increase. As scope increases with fixed schedule, cost tends to increase.
Figure 4. Multitasking Extends Activity Duration
Critical path project planning contains an often hidden assumption: an acceptable way to account for potential resource constraints on the project is to first identify the critical path, and then perform resource leveling. Network specialists know that there is no optimum method to resource level. Network configurations and some resource-leveling algorithms give very poor results. For most networks, applying resource-leveling algorithms lengthens the overall schedule. For this reason, few projects use the resource-leveling tools.
Figure 5 illustrates a typical deterministic project schedule. The different shades represent unique resources. The plan identifies the last activity as a critical path activity. Resource leveling has eliminated the rest of the critical path, an often-mystifying result for the inexperienced project manager. Still, this is a frequent result of resource-leveling methods.
Since the resource constraint is often a significant project constraint, the Theory of Constraints method of project planning always considers it. Thus, the critical chain includes the resource dependencies that define the overall longest path (constraint) of the project. The method resolves all resource constraints while determining the project critical chain. The project critical chain may have gaps between activities. Figure 6 illustrates the comparable critical chain plan.
The improvements that result from CCPM do not depend on having significant resource constraints or conflicts in the project. For a project without resource constraints, the critical chain is the same initial activity path as the critical path. The project plan differs significantly, as described below.
The PMBOK™ Guide’s definition of critical path states that the critical path may change during the performance of the project. This occurs when other paths experience delay, and redefine the longest “zero float” path to complete the project. The critical chain does not change during project performance. This is partly a matter of definition, but mostly a result of the overall critical chain plan construction procedure.
Project Activity Estimates (Exploit the Constraint). CCPM seeks to use the best estimate, or 50% probable, individual activity time estimates. First assemble the plan using the “low-risk” activity estimate duration provided by the project resources. Teach the estimators to understand variation and the critical chain method, including assurance that they will not be criticized or otherwise impacted by either underrunning or overrunning estimated duration. Next (the order is extremely important), solicit their estimated “average” times, assuming everything went as they would hope it would, they have all inputs when they start, and they are able to devote 100% effort to the activity once started. Finally, build the critical chain plan using these reduced activity duration estimates, and collect the differences (D) between the lowrisk and average estimates to develop buffers.
Subordinate Noncritical Chain Paths (Late Finish Plan). Project managers understand that early start schedules can reduce project risk by getting things done early, while late finish schedules:
Reduce the impact of changes on work already performed
Delay the project cash outlay
Give the project a chance to focus by starting with fewer simultaneous activity chains, allowing the project team and processes to come up to speed.
Much project management guidance recommends that project managers use an early start schedule. Many scheduling computer programs use the early start schedule as the “default.” Early start means permitting all of the noncritical path activities to start earlier than is necessary to meet the schedule date. People working on those activities know that there is slack in their activity.
Figure 5. Example of Resource-Leveled Critical Path
CCPM uses “late start” for all project activities. Feeding buffers provide an explicitly sized buffer to protect the overall project from late completion of the feeding paths. This maximizes the advantage to the project, while ensuring project schedule protection.
Project Buffer (Subordinate to the Constraint). CCPM protects the overall project delivery time with a project buffer at the end of the critical chain. This exploits the statistical law of aggregation by protecting the project from common cause uncertainty of the individual activities in an activity path using buffers at the end of the path. Buffers appear as activities in the project plan, but have no work assigned to them.
Goldratt (1997) suggests a very simple method to size buffers: use one half of the sum of the activity durations in the chain of activities that precedes the buffer. This is the critical chain for the project buffer. Others use a method developed and applied by Lucent Technologies. Sum the “Ds” (from above, the difference between the low-risk and average estimates). Following the “law of aggregation,” use the square root of the sum of the squares (SSQ) to sum the Ds.
While the SSQ method has some theoretical attraction, and generally leads to shorter buffers, the primary reason to apply this method is to get the buy-in of the project team. This way, management does not arbitrarily cut the “low-risk” estimates people provide; instead, they are use the information to compute the shared buffer.
Critical Chain Feeding Buffers (Subordinate Merging Paths). CCPM protects the critical chain from potential delays by subordinating critical chain feeding paths; placing an aggregated critical chain feeding buffer (CCFB) at the end of each path that feeds the critical chain. This includes paths that merge with the critical chain at the end of the project. The feeding buffer provides a measurement and control mechanism to protect the critical chain, as described in Figure 7, which illustrates how the buffers absorb the late paths. Figure 6 illustrates the location of CCFBs.
This innovation immunizes the critical chain from potential delays in the feeding paths. It also provides a means to measure the feeding paths, while keeping focus on the critical chain.
Resource Buffers Exploit the Critical Chain. Resource buffers protect the critical chain from unavailability of resources. They are a signal to the project manager and resource managers to ensure resources are ready to work on critical chain activities as soon as the activity input is ready. Resource buffers do not take time in the critical chain and are sometimes called resource “flags.” In risky situations, and in subcontracts, it may be appropriate to include financial incentives in the resource buffers, such as paying for early delivery, penalties for late delivery, or paying for standby time. CCPM only applies resource buffers to critical chain activities, because the feeding buffers provide added protection to noncritical activity chains.
Figure 6. Example of Critical Chain Schedule
Figure 7. Critical Chain Feeding Buffers Absorbing Delays
Critical Chain Human Performance
Eliminate Date-Driven Behavior. Critical chain project plans only provide dates for the start of activity chains and the end of the project buffer. This enables the project team to focus on completing the project as soon as possible. For the rest of the project, the plan provides approximate start times and estimated activity duration. This helps avoid date-driven behavior.
Critical chain project managers do not criticize performers that overrun estimated activity durations, as long as the resources (a) start the activity as soon as they had the input, (b) work 100% on the activity (no multitasking), and (c) pass on the activity output as soon as it is completed. This is called “roadrunner” activity performance. They expect 50% of the activities to overrun. (In practice, date-driven behavior persists; but with CCPM it causes delivery to the 50% probable time, thus automatically passing on positive variation relative to previous “low-risk” estimates.)
Elevate Activity Performance by Eliminating Multitasking. CCPM seeks to eliminate this type of multitasking by eliciting 100% focus on the project activity at hand by all resources supporting the project. Thus, eliminating “fractional head counts” is a primary consideration in planning a critical chain project.
Figure 8. Example of Using the Buffers
Buffer Management Process. This process measures drive actions that move the project toward the goal. Goldratt (1990) notes, “The first thing that must be clearly defined is the overall purpose of the organization—or, as I prefer to call it, the organization’s goal. The second thing is measurements. Not just any measurements, but measurements that will enable us to judge the impact of a local decision on the global goal.”
Goldratt (1990) also defines data as, “every string of characters that describes something, anything, about our reality.” He defines information as “The answer to the question asked.” Goldratt suggests that the information system should incorporate the decision.
The improved measurement system for critical chain project management follows the practice established by Goldratt for production operations. It uses buffers (that is, time) to measure activity chain performance. We set explicit action levels for decisions. The decision levels are in terms of the buffer size, measured in days:
1. Within the first third of the buffer: No action.
2. Penetrate the middle third of the buffer: Assess the problem and plan for action.
3. Penetrate the third third: Initiate action.
These measures apply to both the project buffer (PB) and the CCFBs. Figure 8 shows an example of how buffer penetration provides the essential measurement for CCPM project control.
Project teams monitor the PB and each CCFB at the appropriate time intervals for the project, usually weekly but at least monthly. For this tool to be fully useful, the buffer monitoring time must be at least as frequent as one-third of the total buffer time. If the buffers are negative (i.e., latest activity on the chain is early relative to schedule date) or less than one-third of the total buffer late (e.g., less than 10 days if the total buffer is 30 days), take no action. Buffer management provides a unique anticipatory project management tool with clear decision criteria.
Project managers update the buffers as often as they need by simply asking each of the performing activities how many days they estimate to the completion of their activity. They do this without pressure or comment on the estimate. They expect these estimates to vary from day to day and some of the activities to exceed the original duration estimates. As long as the resources are working on the activities with the CCPM activity performance paradigm, managers evaluate them positively, regardless of the actual duration.
Multiple Project CCPM Process. The impact of multitasking on a single project is significant. In a multiple project environment, it is a disaster. The impact gets worse and worse as managers push more and more projects into the project performance system. CCPM project managers work to eliminate multitasking and create a “pull” system for the multiproject environment. Figure 9 illustrates an example critical path multiproject scenario. The patterns on the bars represent resources. Using conventional low-risk activity estimates and considering three project multitasking, we estimate each activity duration as 90 days.
Identify the Multiproject Constraint. TOC applies directly to plan and manage projects in the multiproject environment. First, we have to identify the company capacity constraint resource. This is most often a certain type of person, but may be a physical or even a policy constraint. The company constraint resource becomes the “drum” for scheduling multiple projects. This terminology comes from Goldratt’s production methodology, where the drum sets the beat for the entire factory. Here, the drum sets the beat for all of the company projects. Think of the drummer on a galleon. What happens if even one rower gets out of beat?
Figure 9. Example of Critical Path Multiproject Schedule
Figure 10 illustrates the CCPM method—activity times reduced to 15 days, eliminating the three times multitasking, and using 50% probable duration estimates. The resource supplying activities 2 and 3 is the “capacity constraint resource.” The plan exploits the resource by synchronizing the projects, using this resource as the drum. The plan subordinates to this resource by adding capacity buffers between the projects. The capacity buffers ensure that the capacity constraint resource (drum) is available for the subsequent project.
The project system becomes a “pull” system because the drum schedule determines the sequencing of projects. It pulls projects forward in time if the drum completes project work early. It delays subsequent projects when the drum is late. For this reason, projects in a multiproject environment also require buffers to protect the drum ... to ensure that they never starve the capacity constraint for work. The plan should schedule the projects to ensure that they are ready to use the drum resource should it become available early. (The figure does not show the drum buffers for simplicity.) Early implementations of CCPM may not deploy the drum buffer.
Do not attempt to schedule all resources across all projects. Companies demonstrate repeatedly that this is a losing proposition. It has never proven possible to get enough current information together and processed quick enough to exceed the ongoing variations in all activities. CCPM allows for this variation with the resource flags and buffers within each project.
Figure 10 shows the CCPM plan completing the three projects (including the project buffer) near the end of August 1998. It shows the first two projects completing even earlier. Contrast this to the critical path multiproject plans of Figure 9, all of which were scheduled to complete in May of 1999. Single-project experience suggests that the CCPM projects should be finished early. Experience with critical path projects suggests that they will be late for even these extended schedules.
Also note that synchronizing the projects this way eliminates resource contention for all resources; not just the drum resource. This happens in the example because the projects are identical. While most multiproject environments do not have identical projects, synchronizing projects to the drum usually eliminates some resource contention.
Exploit Multiproject Resource Allocation. Resource managers prioritize resource allocation across projects according to the importance of activities to the projects. They give priority to (in order):
1. Critical chain activities over noncritical chain activities
Figure 10. The CCPM Multiproject Plan
2. Activities in project chains with greatest project buffer penetration
3. Activities in project chains with the highest feeding buffer penetration.
Penetration of feeding and project buffers resolves remaining resource contentions.
CCPM planning and project management is simple compared to other alternative techniques such as simulation, quantitative risk assessment, PERT three time estimates, Monte Carlo methods, and earned value. The primary concepts are simple; comprising 50/50 estimates, the critical chain, buffers, and buffer management. CCPM requires neither statistical sophistication nor possession of actual distributions of activity performance data. Such data usually does not exist for most projects, and even where it does exist, such as in the construction industry, it has not solved the problem of time overruns.
Busy project managers do not have the time or inclination to assimilate obtuse data. They need real information, gathered in real time. Everyone understands buffer management, measured in days of buffer penetration. Projects can collect and process buffer data daily, if desired. Buffer penetration provides the decision on when to plan and when to act. Few people really understand the meaning of earned value measurements, and how to use them for project management. For example, Powers (1997) notes, “... the participants from leading Fortune 500 companies attending the last benchmarking forum were queried regarding their use of earned value calculations. None indicated that they were using the format described in the PMBOK™ Guide.”
The five focusing steps are clear and concise. CCPM provides a recipe for the straightforward application to real projects. CCPM does not require new computer software, although such software is already available to simplify the activities of resource leveling, finding the critical chain, sizing and placing buffers, and performing buffer management (Creative Technology Labs). Project teams can create CCPM plans in a short time (within a week for projects with the activity network and resource estimates available).
Critical chain project management provides a substantial step in continuous improvement to the Project Management Body of Knowledge. It derives from applying TOC and statistical theory to the project system. It provides a conceptually simple and practical process to plan and manage projects.
Focusing on the project constraint (the critical chain) causes the success of CCPM. The critical chain provides the focus for the whole project. The buffers provide focus and clear decision criteria for the project manager.
The essential changes introduced by critical chain project management (relative to the current practices) are:
Develop the critical chain plan
1. Develop the critical chain, using both activity logic and resource constraints.
2. Reduce activity-estimated times to 50% probability estimates to account for aggregation of the activity contingency times.
3. Add a project buffer to protect completion of the critical chain.
4. Add critical chain feeding buffers to immunize the critical chain from delays in the feeding chains and merging effects.
5. Add resource buffers to ensure critical chain resources are available when needed.
Multiple project plan
1. Plan each project plan as in above steps 1 and 2.
2. Identify the constraint (drum) resource.
3. Create the drum schedule.
4. Sequence projects to the drum.
5. Insert project, feeding, and resource buffers into each project.
6. Insert drum and capacity buffers into each project.
Measure and control to the plan
1. Use buffer management as the primary tool to measure and control the project.
2. Use buffer reports to assign resources.
Lead behavior to achieve earliest project completion
Use behaviors conducive to the global project optima, such as roadrunner activity performance, passing on positive variation, and critical chain-based resource allocation to satisfy the company project needs.
All projects that have diligently applied CCPM have completed the project substantially under the original time estimate, fulfilled the original scope, and came in near or under the estimated budget. Project durations normally reduce by at least 50% in the first pass, and several companies have taken the early successes to cause further substantial duration reductions.
Creative Technology Labs LLC, 37 Grieb Trail. Wallingford, CT.
Deming, W. Edwards. (1989). Out of the crisis. Cambridge, MA: MIT Press.
Goldratt, Eliyahu M. (1984). The goal. New York: North River Press, Croton-on-Hudson.
Goldratt, Eliyahu M. (1990). The haystack syndrome. New York: North River Press, Croton-on-Hudson.
Goldratt, Eliyahu M. (1997). Critical chain. New York: North River Press, Croton-on-Hudson.
Kiley, Martin D. (1996). 1997 National construction estimator. Craftsman Book Company.
Meredith, Jack R., & Mantel, Samuel J. (1995). Project management: A managerial approach. New York: John Wiley & Sons Inc.
Moore, David S., & McCabe, George P. (1993). Introduction to the practice of statistics. New York: W.H. Freeman & Co.
Powers, Ray. (1997). Response from standards committee. Project Management Journal, 28 (2), 53.
Project Management Institute Standards Committee. (1996). A guide to the project management body of knowledge (PMBOK™ guide). Upper Darby, PA: Project Management Institute.
Shewhart, Walter A. (1986). Statistical method from the viewpoint of quality control. New York: Dover Publications (Originally published in 1939).
©1999 by the Project Management Institute — 1999, Vol. 30, No. 2, 39–51 — 8756–9728/99/$5.00 per article + $0.50 per page