On the merits and pitfalls of critical chain scheduling

Willy Herroelen, Operations Management Group, Department of Applied Economics, Katholieke Universiteit
Leuven, Belgium

Roel Leus, Operations Management Group, Department of Applied Economics, Katholieke Universiteit
Leuven, Belgium

Introduction

Goldratt's Theory of Constraints (TOC) and its direct application to project management, known as Critical Chain Scheduling and Buffer Management (CC/BM), has recently emerged as one of the most popular approaches to project management. Subsequent to the publication of Goldratt's business novel in 1998 (Goldratt, 1998), recent books (Newbold, 1998; Leach, 2000), articles (see, for example, Cabanis-Brewin, 1999; Patrick, 1998; Pinto, 1999; Rand, 2000), webpages (see, for example, the tutorial on the website of the Product Development Institute http://www.pdinstitute.com; http://www.focusedperformance.com, the website of Focused Performance, New Jersey; http://www.focus5.mcmail.com, the website of Focus 5 Systems Ltd.), book reviews (Elton & Roe, 1998; McKay & Morton, 1998; Rand, 1998; Schuyler, 1997, 1998), and letters to the editor in the Project Management Journal and PM Network have been written on the subject. Specific software packages based on the critical chain scheduling concepts have recently been developed (ProChain, 1999, Thru-Put Technologies, 1999) or have been announced (the new Primavera Prospective scheduling engine is to incorporate CC/BM as an extended feature; see e.g., the website http://www.ccc-key.com/criticalchain.htm). Internet discussion groups (see, for example, http://www.prochain.com/discussion.html) focus on critical chain scheduling issues. Critical chain scheduling principles have been adopted by a growing number of companies. The majority of the writings consider CC/BM as the most important breakthrough in the history of project management. Critical views risk to be pushed into a minority position, mostly deal with global project management issues and do not seem to address the real essence of the scheduling issues involved.

It is the objective of this paper to highlight the merits and pitfalls of the critical chain scheduling and buffer management approach. Our analysis is partly based on the CC/BM sources listed above and partly on our own experimentation with the ProChain software. In doing so it is not our intention to simply defend or reject CC/BM but to offer a balanced view, which reveals both its strengths and weaknesses. The paper is organized as follows. In the next section we offer a global overview of the fundamentals of CC/BM. Section 3 then focuses on the strengths and weaknesses. Section 4 discusses the results of computational experiments performed on a benchmark problem set in order to test the impact of what we believe to be fundamental assumptions and working principles of CC/BM. Section 5 provides overall conclusions and offers some suggestions for future research.

The Fundamentals of Critical Chain Scheduling

CC/BM starts from the basic observation that the problems common to all projects are the high probability of (a) budget overruns, (b) time overruns, and (c) compromising the content. Project delays are assumed to be much heavier penalized than budget overruns.

Uncertainty is blamed as the major cause of project management problems. Project management must deal with uncertainty in an attempt to deliver the project result—the set of products and services to be delivered—with certainty. In what CC/BM claims to be common project management practice, this uncertainty is not properly factored into the original activity duration estimates. Time estimates are inflated well over the 50% chance level of finishing the activity on time. These inflated estimates are turned into a project schedule with activity due dates and milestones. Project due dates are protected by protecting task due dates and milestones with safety. A lot of this safety is wasted between the connection of one project step to another. Lateness is passed down the project while early finishes are not. CC/BM claims that time estimates are self-fulfilling prophecies: people work toward the estimate. With parallel steps, the worst performance is passed downstream. The safety added may lead to a false sense of security and activities may start later. When multitasking is used, project lead times tend to expand because when a resource alternates between activities and/or projects, the activity times for an individual project are expanded by the time that is spent on the other projects.

Exhibit 1. A Critical Chain Schedule

A Critical Chain Schedule

CC/BM tries to minimize the impact of Parkinson's Law (work expands to fill the time allowed [Parkinson, 1957]) by building the schedule with target durations that are too tight to allow or encourage diversion of attention, by eliminating task due dates and milestones and by eliminating multitasking. Schedules are to be built with only the time to do the work without any safety, based on a 50% confidence level, rather than the 80–90% confidence levels that are commonly used in project management practice. If a schedule is built on the basis of aggressive 50% confidence durations, people cannot be expected to meet them all the time, and therefore there is no way project management can think in terms of task due dates and milestones. Task due dates and milestones hide inflated task estimates and turn those estimates into a reality. They create the well-known student syndrome (concentrate on the end of the task) and cause attention to slip from one urgent task to another. Above all, they divert the manager's attention from what really determines the project lead time—the critical chain.

CC/BM defines the critical chain (see Exhibit 1) as that set of tasks which determines the overall duration of the project, taking into account both precedence and resource dependencies. In order to minimize work-in-progress, a precedence feasible schedule is constructed in which the activities are scheduled at their latest start times based on traditional critical path calculations. Resource conflicts, if they do occur, are resolved by moving tasks earlier in time (Newbold, 1998). By scheduling in this way, it is possible that a task has to be moved earlier than the start of the scheduling horizon. In that case, the entire set of tasks is shoved to the right along the time line until the earliest task starts on the scheduling horizon start. The critical chain is then to be determined as the longest chain which determines the project lead time, i.e., the chain of tasks which cannot be pushed to the left, without pushing activities before the horizon start. In Exhibit 1, activities 1 and 3 and activities 2 and 4 must be performed in series due to the finish-start precedence relation defined on them. Activity 1 and activity 2 must be performed by the same single renewable resource X that has a unit availability. The resource conflict is resolved by forcing them to be performed in series, as indicated by the dotted arc in the network. The critical chain is denoted by the path Start-1-2-4-End and contains the already mentioned activities 1 and 2, as well as activity 4 that is allocated to the single renewable resource Y.

The safety associated with the critical chain tasks is shifted to the end of the critical chain in the form of a project buffer (PB in Exhibit 1), the aim of which is to protect the project due date promised to the customer from variation in the critical chain tasks. Because the activities’ target durations are 50% confidence estimates, it might be expected that half the time they are finished early while half the time they finish late. The early tasks are expected to offset some of the late ones. Consequently, a project buffer of half the project duration is expected to provide sufficient protection (as will be discussed later, more detailed methods might be used to compute the buffer length). Feeding buffers (FB in Exhibit 1), usually sized at half the duration of the non-critical chain path leading into it, are placed whenever a non-critical chain activity joins the critical chain, both to protect the critical chain from disruptions on the activities feeding it, and to allow critical chain activities to start early in case things go well. When there is not enough room to push the chain feeding the buffer to the past, gaps may be created in the critical chain, which are to be considered as informal buffers and which suggest that then project buffer size should be decreased accordingly. Resource buffers (RB in Exhibit 1), usually in the form of an advance warning, are placed whenever a resource has a job on the critical chain, and the previous critical chain activity is done by a different resource.

In short, the critical chain schedule should avoid expansion of Parkinson's Law by eliminating activity due dates and milestones and allowing to take advantage of early activity completions. The schedule should be protected against untimely availability of critical resources by the early warnings coming from preceding activities. The promised project due date should be protected from variation (Murphy's Law) in the critical chain by the project buffer and the critical chain should be protected from variation in non-critical activities by the feeding buffers. If more than one critical chain appears in the schedule, the advice is to just pick one and buffer the others.

The execution of the project is not managed through the use of activity due dates and milestones, but through the use of buffer management. As activities are completed, managers keep track of how much of the buffers are consumed. As long as there is some predetermined proportion of the buffer remaining, everything is well. If activity variation consumes a buffer by a certain amount, a warning is raised to determine what needs to be done if the situation continues to deteriorate. If it deteriorates past a critical point, action is taken to put those plans into effect. The execution of the project activities should be done according to the roadrunner mentality: do not create work when there is none and do not obscure the question of how much capacity is available. The key in reducing system-wide work-in-process is to control the flow of work into the system. That means the activities without non-dummy predecessors (the gating tasks) should not start before the scheduled start time, while non-gating tasks, especially those on the critical chain, should be started as soon as they can when work becomes available.

In a multiproject environment, CC/BM relies on common TOC principles. A critical chain schedule is developed for each individual project containing the project buffer, the feeding and resource buffers. The most constraining (strategic) resource is identified as the bottleneck or the “drum resource.” In order to maximize throughput, everything is to be done to keep this resource busy. A strategic resource schedule (the drum plan) is constructed. This schedule should have start and finish times for activities on the strategic resource. The individual projects are decoupled by placing a capacity buffer before a strategic resource task that is on the critical chain in the strategic resource schedule. This capacity buffer is to be considered as a kind of protective capacity: space (idle time) is created on the strategic resource in order to ensure the resource's availability for the critical chain in the strategic resource schedule. A drum buffer is placed before tasks on the strategic resource in order to protect the strategic resource from disruptions on nonstrategic resources. It protects the throughput of the organization. It is created by pushing activities feeding strategic resource activities earlier by the duration of the buffer. The drum buffer is much like a feeding buffer that protects the critical chain in the individual projects, except that this buffer ensures that the strategic resource will have work available. The strategic resource schedule is the schedule against which new projects will be matched in order to resolve interproject contention for the strategic resource.

The Merits and Pitfalls of CC/BM

Project Duration as a Performance Measure

Makespan as the Number One Objective

In computing the critical chain as the longest precedence and resource feasible chain of activities that determines the project lead time, the advocates of CC/BM implicitly promote the minimization of the project makespan as the number one objective and the major matter of management concern. Minimizing project duration subject to precedence and resource constraints is the de facto standard objective function in the literature on the resource-constrained project scheduling problem (RCPSP). Numerous exact and heuristic procedures have been developed for the solution of the RCPSP (see Herroelen et al., 1998). CC/BM assumes that the baseline schedule must be constructed in the presence of uncertainty. Instead of solving a stochastic resource-constrained project scheduling problem (the literature on the stochastic RCPSP is just emerging; see e.g., Möhring & Stork, 1998), CC/BM generates a baseline schedule by solving the deterministic RCPSP, and subsequently protects the schedule through the insertion of buffers.

Most if not all commercial software packages do not embody optimal algorithms for resource leveling and resource-constrained scheduling, but rely on the use of simple priority rules for generating a precedence and resource feasible schedule. These rules assign scheduling priority on the basis of activity attributes such as latest start time (LST), latest finish time (LFT), minimum slack (MSLK), etc. Extensive computational experiments (Kolisch, 1995) reveal that LST and LFT rank among the best priority rules, but still may generate project durations that are more than 5% above the optimum on the average. The manuals for most software packages regard scheduling information as proprietary information and, as a result, do not offer a detailed description of the rules in use. Some packages enable the user to select a priority rule from a (sometimes very extensive) list, while others do not. Goldratt (1998, p. 217) ridicules the issue by claiming that “in each case the impact on the lead time of the project is less than even half the project buffer” and suggests to cut for each step a piece of paper so that “the length represents time. This way we can move them around until there is no contention.” Newbold (1998) spends some additional explanatory words on the load leveling procedure used to remove resource contention in the initial precedence-feasible late start schedule by moving tasks earlier to make sure that resources are not overloaded. The gist of the procedure is to find a displacement of tasks that will minimize the duration of the final critical chain.

However, it should be clear that if one relies on commercial software for the generation of a baseline schedule, one might be far off the optimum (even if only a few activities are involved), especially if resource contention is rather tricky and the “wrong” priority rule is chosen. Recent computational experiments (Kolisch, 1999) with seven commercial packages on 160 test instances reveal that Primavera Project Planner delivers the best resource-constrained project scheduling performance, especially in a multiproject environment. Average performance is quite widespread, with the best package deviating 4.39% and the worst package deviating 9.76% from the optimum makespan. The mean deviation from the optimum makespan is 5.79%, while the standard deviation calculates to 7.51% and the range is from zero to 51.85%. The scheduling performance of commercial software decreases with increasing number of activities, increasing number of requested resource types, and with decreasing resource capacity. The packages produce better results for projects with many precedence relations.

Minimizing Work-In-Process (WIP) as the Number Two Objective

Newbold (1998) explicitly mentions the minimization of WIP as the second measurement of the goodness of a project schedule and refers to the ideal situation where tasks are scheduled as late as possible while still keeping the project sufficiently protected. Scheduling activities later decreases the WIP; it decreases the chances of rework if design problems are discovered; and in some cases it maximizes cash by pushing out investment until it is absolutely needed.

Financial Objective Functions

The selection of minimizing makespan as the number one objective gains additional support from Goldratt's critique on the use of payback and net present value (npv) calculations. Maximizing the npv has gained increasing attention in the recent project scheduling literature (for an extensive review see Herroelen et al. 1997).The TOC argues that payback calculations do not properly take into account the most important factor, the scarcity of money. Npv calculations are claimed to be conceptually wrong, because as long as availability of money is a constraint, interest is not the appropriate measure. TOC argues that determining the true value of a limited resource investment requires a quantification that is based on both the number of limited resource units (dollars) to be invested, and even more importantly (and hence the need to minimize makespan), the number of time units (days) that these limited resource units (dollars) will not be available. This combined unit of measure is often referred to as “dollar-days” or “flush.” Goldratt's approach omits the obvious need to incorporate compounding.

The practice of scheduling a project so as to maximize its npv has also been questioned in the recent literature (Herroelen et al., 1997). It is clear that the relevance of the max-npv objective is limited to those situations where the time value of money is to be taken into consideration, that is in capital intensive projects with a sufficiently long duration (several months or even years), significant cash flows, high interest rates and high cost of capital. Under conditions of uncertainty, there is a fundamental reason to question the use of the max- npv rule. The npv rule advocated by the orthodox capital budgeting theory assumes that either an investment is reversible or, if the investment is irreversible, it is a now or never proposition. However, the ability to delay an irreversible investment expenditure undermines the simple npv rule. The reason is that a firm with an opportunity cost to invest is holding an “option.” When a firm makes an irreversible investment expenditure, it kills its option to invest by giving up the possibility of waiting for new information to arrive that might afect the desirability or timing of the expenditure. This lost option value is an opportunity cost that must be included as part of the cost of the investment. As a result the npv-rule must be changed. Dixit and Pindyck (1994) discuss how optimal investment rules can be obtained from methods that have been developed for pricing options in financial markets. A promising research effort lies in the extension of these option theory based arguments to the resource-constrained project scheduling environment.

Other Objectives and Models

CC/BM pays no attention to other important regular and non-regular, deterministic objective functions for the RCPSP (and their stochastic equivalents), such as minimizing the average flow time of all subprojects or activities, minimizing the project lateness or project tardiness (i.e., the maximum of the lateness or tardiness of the subprojects or activities), minimizing the number of tardy activities, minimizing the weighted earliness-tardiness, minimizing the sum of the squared deviations of the resource requirements from the average (leveling), minimizing the resource availability in order to meet the project deadline, minimizing the resource availability costs, maximizing project quality (e.g., minimizing the total amount of rework time and rework cost [Erengüç & Icmeli Tukel, 1998]), determining the cumulative density function of the project realization, etc. (for a review and categorization of objective functions, see Herroelen et al., 1998). Moreover, CC/BM does not recognize the importance of practically relevant problem types other than the RCPSP, such as the resource leveling problem, the resource-constrained project scheduling problem under generalized precedence constraints, the multi-mode resource-constrained project scheduling problem, and the time/cost and time/resource tradeoff problem, to mention just a few (for a review and classification, see Herroelen et al., 1998). Newbold (1998) briefly touches upon the last issues by stating that “there are critical chain tasks that can easily be shortened by using more resources” (p. 87) and “In some cases projects can be speeded up by purchasing more resources. In many cases they can't” (p. 113).

Uncertainty and Time Estimation

CC/BM recognizes that the duration of a project activity is a statistical quantity for which it is realistic to assume a probability distribution that is skewed to the right, such that extremely short and extremely long durations still have an acceptable probability of occurrence. Goldratt (1998) suggests to remove any safety from the individual task estimates and recommends to use the median as a realistic single-point task duration estimate. Other CC/BM sources, such as the Product Development Institute (1999), argue in favor of the use of the average estimate of duration as a statistically valid way to model a single project activity. TOC, however, does not offer a reliable way to measure the quality of the activity duration estimates; a very important issue if one wants to improve project forecasts. Nor does it offer any clue to tackle the complex problem of obtaining a realistic and reliable estimate for the computation of the probability of realization of the terminal event in the project (and its corresponding probability distribution in the presence of resource constraints).

Relying on a fixed, right-skewed probability distribution for the duration of project activities may prove to be inappropriate (the advocates of a fuzzy set approach reject it from the outset, see Slowinski & Hapcke, 1999). Even for a single activity, the same assumed distribution will not always hold during the entire activity execution. If a person responsible for the execution of an activity knows that the next job allocated to him has to be done somewhere in the distant future (resource dependency), and the successors of his activity can only start much later (technological dependency), he will be tempted to take his time (Parkinson's Law). This is not always a bad thing, since you cannot have the workforce under stress all the time. A person who feels the pressure to hurry or expedite, will probably do so. The ex ante realistic 50% task duration estimate may well be based on loose ground. It might well be possible that if during project execution, activity slack consumption reaches a critical level, management relies on the use of expediting, working in overtime, adding an extra shift, etc., such that the last 50% of the activity workload may actually be executed in say 20% of the time.

Working with a single 50% confidence task duration estimate for an activity basically assumes that the activity can only be executed according to a single scenario. This ignores the dependency of the duration of an activity on the amount of resources allocated to it: the so-called time/resource tradeoffs where different renewable resource allocations may yield different activity durations, and time/cost tradeoffs where different execution scenarios result in different activity durations at different costs. This gives rise to the realistic and well-studied time/cost tradeoff problem (Demeulemeester et al., 1996, 1998), the time/resource tradeoff problem (De Reyck et al., 1998, Demeulemeester et al., 2000), and the multi-mode problem (De Reyck & Herroelen, 1999). Relying on multiple execution scenarios for the project activities may provide a valuable tool for crashing activities to cope with delays during project execution.

Resources and the Elimination of Multitasking

CC/BM oversimplifies the resource requirements of project activities. All illustrative examples provided throughout Goldratt (1998) and the other CC/BM writings only deal with human beings, i.e., single unit renewable resources. Activities requiring several units of the same renewable resource type for their execution do not receive significant attention in the CC/BM world. Requirements for other resource types (e.g., nonrenewable resources such as money, energy, etc., spatial resources, doubly-constrained resources, constrained per period and for the total time horizon) are not discussed either.

Given the focus on single-unit renewable resource types, CC/BM starts a crusade against the use of multitasking—assigning resources to more than one significant task during a particular time window. Goldratt (1998) describes it as “the biggest killer of lead time”. Admittedly, multitasking is quite common, especially in multiproject environments where resources frequently work across projects on more than one significant task in any particular period of time. No harm is done, however, as long as people complete the individual tasks they are involved in before moving to another task. Allowing that type of multitasking is a decision each company has to make. However, individuals, i.e., single resource units, bouncing back and forth between various tasks may increase the flow time of the individual tasks, especially if they are bottleneck resources. Rejecting multitasking is all but a new idea. It is indeed a long established and well-known result in single machine scheduling theory that activity preemption may be harmful for the flow time of jobs. It is also a well-known project scheduling fact, however, that activity preemption may shorten the duration of a project (Demeulemeester & Herroelen, 1996).

The Critical Chain

CC/BM correctly recognizes that the interaction between activity durations, precedence relations, resource requirements and resource availabilities determines the project duration. The interaction results in one or more sequences of activities, consisting of technologically connected and/or resource-dependent segments, which determine the length of the baseline schedule. Goldratt (1998) identifies such a sequence as the critical chain. This concept is definitely not new. As early as 1964, Wiest (1964) already introduced the concept of a critical sequence “determined not by just the technological ordering and the set of job times, but also by resource constraints; furthermore, it is also a function of a given feasible schedule.” Wiest (1964) explicitly states that the concept of a critical sequence is similar to the Thompson-Giffler concept of an active chain of operations in the job-shop scheduling problem (Giffler & Thompson, 1960).

Creating a Baseline Schedule

Of fundamental importance is the fact that there may be more than one critical sequence in a baseline schedule and the critical sequences are entirely dependent on how the baseline schedule has been generated. Different suboptimal procedures for solving a RCPSP may yield different feasible schedules with different critical sequences (even alternative optimal schedules may exhibit different critical sequences). Goldratt speculates that it does not really matter which critical sequence is chosen. Apparently, he assumes that the critical sequences are easily identified and are an objective fact (McKay & Morton, 1998). Creating a good baseline schedule, however, is definitely not easy (most resource-constrained scheduling problems are NP-hard) and does matter. As mentioned above, problem instances on which heuristics and commercial software produce makespans far above the optimum are easy to find.

However, the critical sequence is not only dependent on how we schedule, but also on how we execute. Uncertain events during project execution—activity delays, the necessity to insert new activities, unavailability of resources, late deliveries by a subcontractor, etc.—may dramatically change the composition of the critical sequences. A critical sequence may shift just as a bottleneck may shift. What is the value of concentrating on an ex ante derived critical chain, when it may change composition and/or wander around during project execution?

Newbold (1998) gives the advice not to reschedule frequently. Only if the project is in real trouble, meaning the project buffer is in real trouble, will it make sense to reschedule. He emphasizes that rescheduling can change the critical chain, and thereby change the focus of the entire project team. We cannot support this argument. Remaining focused on a critical chain that no longer determines the project duration (and, hence, has lost its “criticality”) may be a bad thing to do. Especially when during project execution time gains occur on the critical chain, possibly combined with delays on other non-critical paths, it might be the case that the feeding buffers are only partially consumed while the project buffer remains untouched. In that case CC/BM will remain focused on the critical chain, that is on the “wrong” part of the network, and will leave the gating tasks at their scheduled start times (even if they can be left-shifted), while left-shifting these tasks may avoid project delays. CC/BM's argument that it is necessary to remain focused on the original critical chain is simply the result of its mechanism of monitoring the buffers: allowing the critical chain to wander around and/or change its composition would change the position of the buffers.

Baseline Scheduling for WIP Reduction

Creating a baseline schedule that minimizes work-in-process inventory (WIP) is a major concern in CC/BM. In order to minimize WIP—defined as “work sitting in a system waiting to be finished”—the construction of a baseline schedule starts with a right-justified schedule in which activities are scheduled at their critical path based latest allowable start times. Resource conflicts are detected through a backward pass and resource contention is removed through a heuristic process called “load leveling,” which is not explained in detail, but that involves left-shifting those activity chains that lead to the smallest increase in project duration. Moreover, Newbold (1998) states that the key in reducing system-wide WIP is to control the flow of work into the system. That means, the operations that control this flow, the gating tasks (tasks without real predecessors), must have start times. The general principle applied by CC/BM is that gating tasks should not start before the scheduled start time and non-gating tasks should be started as they can when work becomes available (the already mentioned roadrunner mentality). It might be questioned whether this principle of starting non-gating tasks as early as possible is always beneficial with respect to WIP reduction. Sometimes, WIP might well be reduced by right-shifting non-gating tasks with sufficient safety float.

It may be questioned whether minimizing WIP is mandatory in all types of project environment. Is it really a problem whether an auditor has his part of the audit report ready three days before his output is needed elsewhere? In capital intensive projects, cash flow patterns may be the determining factor: incoming cash flows may ask for certain activities to start as soon as possible while cash outlays may ask for certain activities to start as late as possible.

Buffers

Project Buffer and Feeding Buffers

CC/BM shifts the safety associated with the critical chain activities to the end of the critical chain in the form of a project buffer. Again, the idea is not new. For example, it is quite common practice in the building industry to add “weather delay” to the baseline schedule. Feeding buffers are placed whenever a non-critical chain activity joins the critical chain, both to protect the critical chain from disruptions on the activities feeding it, and to allow critical chain activities to start early in case things go well.

Because the activities’ target durations are 50% confidence estimates, a project buffer of half the project duration is expected to provide sufficient protection. Also the size of a feeding buffer is usually set at half the duration of the non-critical chain path leading into it. The obvious advantage of this procedure is its simplicity. The procedure, however, is a linear procedure. The size of the buffer that is calculated increases linearly with the length of the chain with which it is associated (for example, a two-year project could end up with a year-long project buffer). In many cases, the result might be an unnecessarily large amount of protection, which could lead to uncompetitive proposals and the loss of business opportunities.

CC/BM admits that more detailed methods might be used to compute the size of the project buffers and the feeding buffers (Newbold, 1998; Product Development Institute, 1999). The root-square-method tries to base buffer sizes on the aggregate risk along the chain feeding the buffer. The method requires two estimates of task duration. The first estimate should be a safe estimate, S, which includes enough safety to protect against all likely sources of delays. The second estimate, A, should be one that includes no such protection. In addition, it should be assumed that activities will be worked at a full level of effort, with no interruptions imposed by external factors. The difference between the two estimates, D = S – A, is treated as the magnitude of uncertainty in the shorter estimate. The buffer size required is then estimated as the square root of the sum of squares of the uncertainty (D) in the individual activities. This method clearly makes the assumption that project activities are independent.

Newbold (1998) elaborates on the calculation under the assumption of a lognormal distribution for the probability of completing a task. Assuming that tasks should be completed within the worst-case duration estimates around 90% of the time, he claims that the difference between the average expected duration and the worst-case duration will be about two standard deviations. For each task feeding the buffer, the presumed standard deviation would be (SiAi)/2, with Si the worst-case duration and Ai the average duration. If it is further assumed that the sum of the distributions will be approximately normally distributed (that is, pretend the central limit theorem applies), and assuming we want a buffer that is two standard deviations long, we can set its length to:

img

It can easily be verified, however, that this 2σ-assumption does not hold. It is well known that if img, then img, the lognormal distribution. Note that μN and σ2N are not the mean μ and variance σ2 of this latter distribution. In fact, img, and img; the median duration is exp (μN). More generally, the 100q %-quantile lnq of the distribution equals exp img, where Zq is the 100q %-quantile of the standard normal distribution (Aitchison and Brown 1973). It is clear that the number of standard deviations between lnq and img, which is tabulated in Exhibit 2 for some values of μ and σ. A constant value of the coefficient of variation σ/μ guarantees constant Δq; typical values for q = 0.9 range between 0.05 and 1.5, contrary to Newbold, who claims that this is always about two standard deviations.

If one insists on using the lognormal distribution for modeling activity durations, the following more sophisticated approach might be used. Assume that one can come up with median (med), minimal (min) and maximal (max) durations. It is our opinion that med is a more intuitive notion than μ, which makes it easier to specify. For calculation purposes, however, we advocate the use of the mean. Possibly min = 0, and a certain q is specified such that max=lnq, for instance 90%. If we can consider min to be a value that represents the offset of the distribution from 0, we can deduct min from the other specified quantities and work as if our lognormal distribution takes on nonzero densities starting from zero. Corresponding μN and σN are then readily obtained, and the convenient μ and σ2, given the assumptions, can be computed. If enough activities are present on any chain and we can assume their durations are independent, we can invoke the Central Limit Theorem to approximate the distribution of the chain makespan by a normal distribution, based on calculated mean and variance for each activity. If only a smaller number of activities is to be considered, correction coefficients can be tabulated through simulation or analytical approaches.

Exhibit 2. Validating the 2σ-Assumption

Validating the 2σ-Assumption

CC/BM computes the project buffer for the baseline schedule that does not yet contain the feeding buffers. During execution, however, the schedule contains feeding buffers that are placed whenever a non-critical chain activity joins the critical chain. It would be more logical to base the calculation of the project buffer size on the length of the baseline schedule already buffered by the feeding buffers. Inserting feeding buffers, may result in the fact that the critical chain is no longer the longest path in the network (see the problem example given by Rizzo, 1999). Moreover, one of the purposes of the project buffer is that it provides an estimate of the completion time of the project that can be realized with an appropriate probability and, hence, an estimate of the project due date. It would be logical to update the size of the project buffer during project execution, as a reaction to the dynamic process of reestimating the probability of meeting the due date.

The precise procedure for inserting the feeding buffers as given in Goldratt (1998) and Newbold (1998) lacks clarity. Pushing activities backward in time in order to insert a feeding buffer may, and mostly will, create resource conflicts. How these conflicts are to be resolved is not described in sufficient detail. A possible way for resolving the conflict may by to push the chain of activities feeding a feeding buffer backwards in time until a feasible schedule is obtained again. Very pathological situations, leading to a serious increase in project makespan may be the result. Another way of resolving the resource conflict may be complete rescheduling, treating feeding buffers as dummy tasks with positive duration, and assuring sequential execution of the critical chain activities. A schedule that is totally different from the original baseline may result, which poses the question whether the critical chain of the original baseline schedule should be kept intact.

Both Goldratt (1998) and Newbold (1998) argue in favor of the “roadrunner mentality”, i.e., start an activity as soon as the predecessor activities are finished. Again, this is not a new concept. It is referred to as semi-active timetabling in scheduling theory (timetabling is semi-active if in the resulting schedule there does not exist an operation which could be started earlier without altering the processing sequence or violating the technological constraints and ready dates). In order to minimize a regular measure of performance, such as minimizing the project duration, it is well known that it is only necessary to consider semi-active timetabling (French, 1982). Implementing the roadrunner mentality during project execution implies that the inserted feeding buffers are disregarded when determining the activities that are eligible to start. Starting activities as soon as possible may imply a serious deviation from the baseline schedule and the critical chain associated with it.

The implementation of the roadrunner mentality implies that two different baseline schedules are maintained. One schedule, subsequently referred to as the baseline schedule, has the buffers inserted, is late start based and is not recomputed at each schedule update. The second schedule, subsequently referred to as the projected schedule, is early start based (except for the gating tasks) and does not take the buffers into account. This two-schedule mechanism is not easy to communicate to the workers. Workers may be tempted to give in to Parkinson's Law if they are told that their tasks, while buffered, have been left-shifted.

When repairing the projected schedule is necessary for whatever reason, and a choice has to be made which eligible activities to start, should priority be given to activities belonging to the critical chain associated with the baseline schedule? If feeding buffers are to be ignored in making these decisions, one might question the use of the feeding buffer mechanism. CC/BM sees the answer in buffer management. In addition to providing protection against statistical variation, buffers are supposed to act as transducers that provide vital operational measurements and an early warning mechanism. This implies that if other mechanisms are used to provide an early problem detection mechanism, the need for feeding buffers as a problem detection tool disappears. Moreover, the consumption of buffers will usually go together with the creation of resource conflicts somewhere in the schedule. Again, these conflicts will have to be resolved. This phenomenon remains undiscussed in the CC/BM treatise on buffer management.

Resource Buffers

Resource buffers are placed whenever a resource has a job on the critical chain, and the previous critical chain activity is done by a different resource. Resource buffers should make sure that resources will be available when needed and critical chain tasks can start on time or (if possible) early. Resource buffers usually take the form of an advance warning, i.e., a wake-up call for every new instance of a resource on the critical chain. Alternatively, space (idle time) can be created on the resource to provide a kind of protective capacity.

A fundamental question to be asked is what needs to be done when more than one perfectly equivalent unit of a resource type may be allocated to a critical chain activity. Should the wake-up call or space be inserted for all the resource units, or should the initial allocation of the resource units to project activities be taken into account?

If a wake-up call is set under the assumption that preemption is not allowed (remember the avoidance of multitasking), it is implicitly assumed that a critical activity resource, in order to be ready to undertake a critical chain activity, will speed up its remaining workload. This possibility of activity crashing exploiting existing time/cost and/or time/resource tradeoffs is not explicitly incorporated in CC/BM, and if it would be incorporated, would drastically change the way activity duration estimates are to be obtained. If, on the other hand, the assumption is that a wake-up call asks for the immediate attention of a resource currently involved in performing other non-critical chain activities, preempting non-critical chain activities in execution seems unavoidable (while preemption as such does not fit at all in the CC/BM framework) and people are invited to implement multitasking exactly at the place where it is undesirable (that is, at the critical chain). When preempted resources are released again, it must be decided whether the preempted activity should be resumed again, or whether another activity that requests the resource should be started instead.

If idle time is introduced to implement a resource buffer (possibly inducing additional resource conflicts and schedule distortion), the resource may well be invited to use its additional slack created on the predecessor activity which feeds the critical chain activity for which the resource buffer was inserted.

Subordinating to the Critical Chain

Subordinating all scheduling decisions to the “unique” and “never” changing critical chain forces the entire project into a rigid framework that may not be able to cope with the dynamics of project execution. According to CC/BM, the buffers introduced to protect the critical chain should be able to cope with serious delays that occur on non-critical chain activities. We already mentioned that this might be wishful thinking. Buffer consumption mostly implies resource contention and the necessity to resolve resource conflicts, i.e., to repair the schedule. This may cause one or more other sequences to become as long as or longer than the critical chain on which management is concentrating. The result is that management is focusing attention on a sequence of activities, determined prior to activity execution, which no longer determines the project makespan.

Multiple Projects: Strategic Resource Buffers

In a multiproject environment, CC/BM relies on the common five TOC steps: (a) prioritize the organization's projects, (b) plan the individual projects via CC/BM, (c) stagger the projects, (d) measure and report the buffers, and (e) manage the buffers.

Step (a) attacks multitasking among projects. Often projects are pushed into an organization without regard to the system's capacity and capability. The projects of a multi-project organization share many resources. The basic argument is that time-sharing people (again CC/BM mainly argues from a product development viewpoint where individuals are the key resources) across projects is a compromise solution, but a lose-lose solution. The earlier projects lose because their progress is slowed; the new project loses because its progress is not nearly as great as it might be. Therefore, prioritization is a leadership's task and responsibility.

Step (b) asks for the development of a critical chain schedule for each individual project containing the project buffer, the feeding and resource buffers. CC/BM assumes that it is now possible to identify within the multiproject organization the most constraining (strategic) resource as the bottleneck or the “drum resource.” In order to maximize throughput, everything is to be done to keep this resource busy. The argument is again in terms of a single unit resource. This resource is the one resource whose schedule—the strategic resource schedule (the drum plan)—is used to stagger the projects in Step (c). This schedule should have start and finish times for activities on the strategic resource. The individual projects are decoupled by placing a capacity buffer before a strategic resource task that is on the critical chain in the strategic resource schedule. A drum buffer is placed before tasks on the strategic resource in order to protect the strategic resource from disruptions on nonstrategic resources. It is created by pushing activities feeding strategic resource activities earlier by the duration of the buffer.

Our critical arguments made above with respect to the buffers for individual projects also hold for the multiproject case. In practice it is often quite difficult to identify exactly the single heavily loaded resource to be considered as the drum, especially in those environments where different resource types (renewable, non-renewable, doubly-constrained, etc.) are required in other than single unit amounts. Resource utilization not only changes from project to project, but also obviously depends on the schedules generated for the individual projects, and, as a result, changes dynamically over time. Addition of new projects to an existing pool will lead to resource contention. Using a capacity buffer in front of a single-unit drum to resolve these conflicts is, again, a “solution” based on a severe oversimplification of the resource-constrained multiproject scheduling problem. Using buffers as risk gauges looks nice: if any activity requires more time then previously estimated, the corresponding buffer is consumed; if any activity requires less time than previously estimated, the corresponding buffer is replenished. Unfortunately, things do not work out that way. Late and early finishes may create immediate resource conflicts which need to be resolved, and which cry for efficient and effective reactive and rescheduling tools. The simplified buffer management argument of CC/BM step (d) and (e) makes it appear as if uncertainty simply translates into buffer consumption or buffer replenishment, without the need for rescheduling and/or changing the composition of individual critical chains. There is simply no guarantee that the original critical chain schedules derived for the individual projects should remain unchanged when the project portfolio changes dynamically. The need for intelligent rescheduling/repair algorithms is definitely not replenished by the buffer management mechanism of CC/BM. Other, more powerful mechanisms than inserting and managing buffers may be developed which alert management for emerging problems that may be harmful for the project due date and that allow for the dynamic evaluation of the criticality of project activities.

Computational Experiment

In order to validate the fundamental working principles of the CC/BM scheduling methodology we implemented our own computerized version of CC/BM. A full factorial computational experiment was set up using the well-known 110 Patterson test problems (Patterson, 1984) as vehicles of analysis. The test instances have a number of activities varying from seven to 50 requiring up to three renewable resource types each. The original activity durations were multiplied by 25 to obtain the average activity durations used to compute the right-justified baseline schedule using both the branch-and-bound procedure of Demeulemeester and Herroelen (1997a, 1997b) and the LFT (latest finishing time) heuristic. For each right-justified baseline schedule the critical chain is computed and protected by feeding buffers and a project buffer. For each problem, also a projected schedule is computed with all activities, except the gating tasks, left justified.

Project execution is simulated through five replications for each problem as follows. Disturbances are generated for each activity by drawing a new duration from a lognormal distribution with mean equal to the baseline duration and a coefficient of variation uniformly distributed between 0.75 and 1.25. Project execution is based on the average baseline duration for every activity until the information about the activity disturbance is known. This time instant is the activity finishing time in the baseline schedule if the activity does not finish earlier than planned, or the actual finishing time otherwise. Each time a deviation from the projected schedule occurs, the projected schedule is recomputed. Exhibit 3 shows the evolution of the project buffer end through time as a percentage of the final project duration. The horizontal axis indicates what fraction of the project has been executed. The dotted curve (labeled standard) refers to the standard procedure which only recomputes the baseline schedule if a feeding buffer or the project buffer is exceeded. The bold curve (labeled same CC) refers to the case where the size of the project buffer is recomputed upon the completion of every task of the critical chain, which is kept unchanged. The light curve (labeled new CC) refers to the case where the baseline schedule and the critical chain are updated at every decision point before recalculating a new projected schedule. Clearly, the fact that the light curve approaches the value of one as the project completes, indicates that regularly updating the critical chain provides the best intermediate estimates of the project makespan. Moreover, not only the makespan estimates improve, but also the realized project makespan is significantly smaller as will be discussed below.

Exhibit 3. Evolution of the Project Buffer End Through Time

Evolution of the Project Buffer End Through Time

The factorial experiment is based on five factors with two settings each: (a) the use of branch-and-bound (BB=1) or the LFT heuristic for scheduling and rescheduling (BB=0), (b) computing the buffer sizes using the 50% rule (RS=0) or the root-square-error method using 2σ (RS=1), (c) allowing the serial structure of the critical chain to be broken (CC=0) or keeping the critical chain activities in series (CC=1), (d) allowing the gating tasks to start prior to their scheduled start in the baseline schedule (GAT=0) or not (GAT=1), and (e) recomputing the baseline schedule at each decision point (REC=1) or only when buffers are exceeded (REC=0). This results in a total of 32 × 5 × 110 runs.

A regression analysis is performed using as explanatory variables the number of activities (N), dummies for every factor, various factor interaction terms and both precedence and resource-based network characteristics. The explained variables are (a) the makespan of the projected schedule resulting upon project completion (Cmax), (b) the percentage deviation of the final projected makespan from the optimal makespan computed ex post using branch-and-bound on the basis of the real activity durations (PERC), (c) the sum of the free floats in the final projected schedule as a measure of WIP (FF), and (d) the ratio RAT= ((project buffer end prior to execution—final projected schedule makespan)/(final projected schedule makespan)).

The number of activities has a positive impact on Cmax, a negative impact on PERC, a positive impact on FF, and a positive impact on RAT. Using the branch-and-bound instead of the LFT heuristic for rescheduling leads to a smaller value of Cmax (4.45% gain), PERC and FF, clearly revealing the advantages of clever scheduling and rescheduling. The beneficiary effect of computing the buffer sizes using the root-square-error method increases with problem size, which is reflected in the negative effect of RS and RS × N on RAT. Using the 50% rule for buffer sizing may lead to a serious overestimation of the project buffer size, and consequently of the project duration. Keeping the critical chain activities in series leads to greater values of Cmax and PERC, especially for large problems. As a result, keeping the critical chain activities in series has a negative impact on RAT. Not allowing the gating tasks to start prior to their scheduled start time in the baseline schedule has a limited impact on PERC and a virtually negligible impact on FF, especially for large problems. The use of branch-and-bound has a much stronger effect on WIP reduction than the use of ready times for the gating tasks (8.76% versus 2.69%). If the critical chain is kept in series, then recomputing the baseline schedule at each decision point has a strong beneficiary effect on Cmax and PERC.

We have also conducted a small experiment in which we compare the end of the project buffer in the baseline schedule prior to project execution to the final makespan for the case BB=1, RS=1, CC=1, GAT=1 and REC=0, using the mean, median and mode as the initial duration estimate for the activities. The conclusion is that the use of the mean provides the safest estimates of the project duration. Hence, we cannot recommend the use of the median or mode. This is a normal result since only the mean durations add up linearly to estimate in a statistically sound way the mean duration of a path.

Conclusions and Suggestions for Further Research

CC/BM, similar to what happened with the introduction of TOC in production management, has acted as an important eye-opener. CC/BM's recognition that the interaction between activity durations, precedence relations, resource requirements and resource availabilities has a major influence on the duration of a project is well taken and, although mostly unrecognized by many practitioners, in line with the fundamental insights gained in the project scheduling field. The idea of protecting a deterministic baseline schedule in order to cope with uncertainties is sound. The TOC methodology of using feeding, resource and project buffers and the underlying buffer management mechanism provide a simple tool for project monitoring and realistic due date setting. The danger, however, lies in the oversimplification. The CC/BM pitfalls resulting from this oversimplified view at the real scheduling and rescheduling issues have been scrutinized in this text and have been confirmed by a full factorial experiment.

The need for intelligent scheduling/repair algorithms is definitely not replenished by the schedule generation schedule protection and buffer management mechanism of CC/BM. Additional research is needed in the development of effective and efficient algorithms for the creation of robust baseline schedules. Similarly, additional research is needed in the development of powerful mechanisms for alerting project management for emerging problems during project execution which may be harmful for the project due date and which allow for the dynamic evaluation of the criticality of project activities.

Aitchison, J., & Brown, J.A.C. (1973). The lognormal distribution. Cambridge: Cambridge University Press.

Cabanis-Brewin, J. (1999, December). “So … So What??” Debate over CCPM gets a verbal shrug from TOC guru Goldratt. PM Network, 13, 49–52.

Demeulemeester, E.L., & Herroelen, W.S. (1992). A branch-and-bound procedure for the multiple resource-constrained project scheduling problem. Management Science, 38, 1803–1818.

Demeulemeester, E.L., & Herroelen, W.S. (1996). An efficient optimal solution procedure for the preemptive resource-constrained project scheduling problem. European Journal of Operational Research, 90, 334–348.

Demeulemeester, E.L., & Herroelen, W.S. (1997a). New benchmark results for the resource-constrained project scheduling problem. Management Science, 43, 1485–1492.

Demeulemeester, E.L, & Herroelen, W.S. (1997b). A branch-and-bound procedure for the generalized resource-constrained project scheduling problem. Operations Research, 45, 201–212.

Demeulemeester, E.L., Herroelen, W.S., & Elmaghraby, S.E. (1996). Optimal procedures for the discrete time/cost tradeoff problem in project networks. European Journal of Operational Research, 88, 50–68.

Demeulemeester E., De Reyck, B., Foubert, B., Herroelen, W., & Vanhoucke, M. (1998). New computational results on the discrete time/cost tradeoff problem in project networks. Journal of the Operational Research Society, 49, 1153–1163.

Demeulemeester, E., De Reyck, B., & Herroelen, W. (2000, November). The discrete time/resource tradeoff problem–A branch-and-bound approach. IIE Transactions.

De Reyck, B., Demeulemeester, E., & Herroelen, W. (1998). Local search methods for the discrete time/resource tradeoff problem in project networks. Naval Research Logistics, 45, 553–578.

De Reyck, B., & Herroelen, W. (1999). The mufti-mode resource-constrained project scheduling problem with generalized precedence relations. European Journal of Operational Research, 119 (2), 538–556.

Dixit, A.K., & Pindyck, R.S. (1994). Investment under uncertainty. Princeton: Princeton University Press.

Elton, J., & Roe, J. (1998, March–April). Bringing discipline to project management. Harvard Business Review, 76, 153.

Erengüç, S.S., & Icmeli Tukel, O. (1998). Using quality as a measure of performance in resource-constrained project scheduling. Proceedings of the Sixth International Workshop on Project Management and Scheduling. Istanbul, 54–57.

French, S. (1982). Scheduling and sequencing. An introduction to the mathematics of the job-shop. New York: John Wiley & Sons.

Giffler, B., & Thompson, G.L. (1960). Algorithms for solving production scheduling problems. Operations Research, 8, 487–503.

Goldratt, E.M. (1998). Critical chain. Great Barrington: The North River Press Publishing Corporation.

Herroelen, W.S., Van Dommelen, P., & Demeulemeester, E.L. (1997). Project network models with discounted cash flows–A guided tour through recent developments. European Journal of Operational Research, 100 (1), 97–121.

Herroelen, W., De Reyck, B., & Demeulemeester, E. (1998). Resource-constrained project scheduling: A survey of recent developments. Computers and Operations Research, 25 (4), 279–302.

Herroelen, W., Demeulemeester, E., & De Reyck, B. (1998). A classification scheme for project scheduling. Project scheduling–Recent models, algorithms and applications (Weglarz, J. (ed.)). Dordrecht: Kluwer Academic Publishers.

Kolisch, R. (1995). Project scheduling under resource constraints. Heidelberg: Physica-Verlag.

Kolisch, R. (1999). Resource allocation capabilities of commercial project management software packages. Interfaces, 29 (4), 19-31.

Kolisch, R., Icmeli Tukel, O. & Rom, W. (1999). Measuring the quality of a project: An empirical study. Paper presented at the INFORMS Cincinnati Spring Meeting.

Leach, L.P. (2000). Critical chain project management. Artech House Professional Development Library.

McKay, K.N., & Morton, T.E. (1998). Book Reviews–Critical chain. IIE Transactions, 30, 759–763.

Möhring, R.H., & Stork, F. (1998). Stochastic project scheduling under limited resources: A branch-and-bound algorithm based on a new class of policies. Proceedings of the Sixth International Workshop on Project Management and Scheduling. Istanbul: 102–105.

Newbold, R.C. (1998). Project management in the fast lane–Applying the theory of constraints. Boca Raton: The St. Lucie Press.

Parkinson, C.N. (1957). Parkinson's Law. Cambridge: The Riverside Press.

Patterson, J. (1984). A comparison of exact procedures for solving the multiple constrained resource project scheduling problem. Management Science, 30, 854–867.

Patrick, F.S. (1999, April). Critical chain scheduling and buffer management–Getting out from between Parkinson's rock and Murphy's hard place. PM Network, 13, 57–62.

Pinto, J.K. (1999, August). Some constraints on the theory of constraints–Taking a critical look at the critical chain. PM Network, 13, 49–51.

Pollack-Johnson, B. (1999). Factors influencing project management techniques & software usage & attitudes on future research among project management professionals. Paper presented at the INFORMS Cincinnati Spring Meeting.

ProChain Solutions, Inc. (1999). ProChain® Plus Project Scheduling (http://www.prochain.com/prochain_plus.asp).

Product Development Institute. (1999). Tutorial: Goldratt's Critical Chain Method, A One-Project Solution. http://www.pdinstitute.com/tutoriahntro.html.

Rand, G.K. (1998). Critical chain. Journal of the Operational Research Society, 49 (2), 181.

Rand, G.K. (2000). Critical Chain: The theory of constraints applied to project management. International Journal of Project Management, 18 (3), 173–177.

Rizzo, T. (1999, December). Operational measurements for product development organizations–Part 2. PM Network 13, 31–35.

Schuyler, J. (1997). Tip of the week #26: Critical Chain. http://www.maxvalue.com/tip026.htm.

Schuyler, J. (1998). Tip ofthe week #39: Project Management in the Fast Lane: Applying the Theory of Constraints. http://www.max-value.com/tip039.htm.

Slowinski, R., & Hapcke, M. (Eds.). (1999). Scheduling under fuzziness. Springer-Verlag.

Thru-Put Technologies, Inc. (1999). Concerto-EMMS™–The Enterprise Multiproject Management Solution. (http://www.thruput.com/products/concerto.html).

Wiest, J.D. (1964, May-June). Some properties of schedules for large projects with limited resources. Operations Research, 12, 395–418.

This material has been reproduced with the permission of the copyright owner. Unauthorized reproduction of this material is strictly prohibited. For permission to reproduce this material, please contact PMI or any listed author.

Proceedings of PMI Research Conference 2000

Advertisement

Advertisement

Related Content

Advertisement