01 - What is Critical Chain?

"Critical Chain," in the largest sense, is the set of processes and practices for project management developed by the application of the Theory of Constraints Thinking Processes to the difficulties faced in delivering projects with both speed and reliability. The "body of knowledge" associated with Critical Chain centers on Critical Chain Scheduling and Buffer Management for individual projects, and synchronization of efforts across projects in multiproject organizations. (Critical Chain is also the title of a book, by Eliyahu M. Goldratt, that introduces the basic concepts of the approach.) 02 - What is a critical chain? The critical chain of a project is the set of dependent tasks that define the expected lower limit of a project's possible lead time. Dependencies used to determine the critical chain include both logical hand-off dependencies (where the output of the predecessor task is required to start the successor), and resource dependencies (where a task has to wait for a resource to finish work on another task). The identification of the critical chain uses a network of tasks with "aggressive but achievable" estimates, that is first "resource leveled" against a finite set of resources. In traditional project management language, the structure of a critical chain is similar to that of a "resource constrained critical path." 03 - Why Critical Chain? What does it bring to the project management party? Underlying the key differentiating aspects of Critical Chain-based project management are an appreciation for the impact of variation (the statistical nature of projects) and of human behavior (people's response to how their projects are managed) on the ability of a project to move with speed and reliability. While there are established PM approaches to the consideration of variation, like PERT and Monte Carlo simulations, the application of the outcomes of these techniques (when not simply ignored) are too often applied in ways that perpetuate Parkinson's Law in most projects. One unique aspect of Critical Chain, regarding how it helps to address the impact of variation, is the jsiru concept of the feeding buffer, the role of which is to protect the critical chain from variation in non-critical chains of tasks, essentially to help keep the critical chain critical. 04 - What is a buffer? Buffers are designed quantities of time, sized and applied to a project schedule to protect what is important to the success of that project. The Project Buffer protects the promised due date from variation in the critical chain. Feeding Buffers protect the ability of the critical chain to maintain its relay race performance by buffering the variation of non-critical tasks and chains where they feed into or merge with critical chain tasks. With a properly sized feeding buffer inserted, the critical chain task that relies inputs from that non-critical chain has an improved chance of being able to start as soon as it predecessor critical task is complete. Capacity buffers are used in multi-project environments to help isolate the impact of variation of key resource performance in one project from subsequent projects.

Resource Buffers are unlike the other buffers, as they do not directly impact the lead time or scheduling of the project, but rather serve as a wake-up call for resources that may need one in order to be ready to run their leg of the relay when their predecessor is complete. 05 - What is Buffer Management? By using frequent and regular (ideally daily) updates of "time to complete" active tasks, the buffers and their rate or level of consumption turn into good indicators that something might be amiss. Buffer Management is the tracking and assessment of the consumption and replenishment of buffers during project execution. Its purpose is to provide a simple, easy to understand view of project health against original promises and provide guidance on when -- and when not to -- develop and apply corrective actions to the project effort. 06 - Isn't Buffer Management the same as managing slack or float? No. Slack and float are merely the mathematical outcome of comparing anticipated time requirements for non-critical tasks and chains against a traditional critical path. Feeding buffers are designed for the specific purpose of isolating anticipated variation and for enhancing the chance of keeping the critical critical. 07 - How are buffers sized? The most common basic approach to sizing buffers for a particular chain of tasks is to start with the 2-point range of estimates, and use half of the difference between the sum of the longer "safe" estimates and of the shorter "aggressive but achievable" estimates. Since buffers are based in the ability of "luckier" tasks making up for the "unlucky" tasks, when chains of tasks get short, with perhaps only four or less tasks, and alternative calculation based on the "square root of the sum of the squares of the differences" of these two task estimates is sometimes used. Buffer size is not limited to this accounting for task variation alone; they can also be subject to modification/augmentation to deal with other sources of variation, such as iteration uncertainty. 08 - Can Critical Chain concepts be used to manage project cost? Yes. Within the critical chain "body of knowledge" is the concept of a "budget buffer." In the same way that safety protecting against anticipated variation in schedule performance is aggregated and concentrated in a project buffer where it can be used where needed and monitored at a project level, the same approach can be used to take the possible variation in spending along the way and put it into a visible and therefore manageable project-level "buffer." 09 - Will Critical Chain work with Earned Value? Yes. There is nothing mutually exclusive about the two processes with the possible exception of a risk of driving conflicting behaviors if both systems are used for the same purposes. Success

to date (January, 2001) in merging the two approaches has typically been accomplished by treating EV reporting as simply a necessary condition of the contract, and use the data gathering of EV to satisfy that need. Operational decisions and assessments of the health of their projects - the actual management of the project - are driven by Critical Chains buffer management process. Some open-minded folks in the EV-centric community of government work initially recognized the possibilities of using buffer management to apply a rigor to one of the fuzzier parts of EV practice - the reliance on relatively subjective "thresholds" for indication of the need to take corrective action. But as time has gone on, the trend (where both have been assessed) seems to have been to replace EV's supposed predictive tools (and other traditional methods of tracking their projects) with buffer management. This is supported by situations where the two systems occasionally show conflicting indications regarding project health that usually proved out that reality was in far closer alignment with the buffer management indicator. The current thoughts of a Government and Industry workgroup looking into reconciling EVMS and Buffer Management are that, if an organization wants take advantage of the benefits available through the use Critical Chain, then they should manage and take action based on Buffer Management and, if required, still report EVMS. 10 - How does CC-based multi-project management work? By combining the ability of buffers to absorb variation with the synchronization (staggering) of project launches based on the availability of key (heavily and commonly used) resources or on the capacity of (common) major integration points, cross-project contention for resources is minimized. Doing so results in less pressure to multitask and its lead-time multiply effects. 11 - What is multitasking and what's wrong with it? Multitasking is the practice of working on two or more significant tasks in the same timeframe in a manner that is characterized by shifting back and forth between them before finishing either. Task A, while started, is idle, while task B is tended to and vice versa. From the perspective of the chains with which these tasks are associated, multitasking simply delays the ability of successor tasks to start. This results in each of the tasks taking close to (and often more than) the amount of time it takes for all of them to be completed. Multitasking multiplies project lead times. 12 - What is Parkinson's Law? C. Northcote Parkinson (1909-1993) first published the "law" -- "Work expands to fill the time available for its completion." -- in November, 1955 issue of The Economist in an essay entitled "Parkinson's Law," republished later in a book of the same name, currently published by Buccaneer Books. The target of his studies was the great bureaucracy of the British Empire and the Admiralty of the time and the growth of the number of civil servants in its employ. Applied to project management, it is related to "due-date behaviors" that come from the dangerous perception that if tasks are completed by a certain point in time, the project is

deemed to be "on-track." The result of such thinking is too often a full use of that "time available," losing the opportunity to take advantage of early finishes that could provide time to absorb delays in other parts of the project. These behaviors are usually not conscious decisions on the part of resources, but rather the systemic result of trying to manage with too much in the in-box and a lack of truly clear priorities. 13 - I've heard that Critical Chain requires getting resources to cut their task estimates in half. Is that true? And if so, how do you manage to do that? The key is to realize that we are NOT cutting estimates by any amount. Critical Chain scheduling typically involves a 2-point range estimate. As a matter of fact, we are probably using "safe estimates" that are bigger and safer than the old processes allow when they're combined with management pressures for shorter projects. What we are doing with the smaller, "aggressive but achievable," estimates is merely trying to understand the potential level of variation/uncertainty within that safer estimate of the task -- how much of the larger estimate is in there to cover the possibility of running into Murphy's Law while working on the task. We're not cutting estimates -- we're understanding them so that we can take their fears and uncertainties into account in a way that protects the project's promise. The shorter estimates are merely used to structure the network of activities so that we can understand what is truly critical. They are in no way considered commitments on the part of the project resources. Once this is understood and clearly communicated, there is very little difficulty getting people not to "cut their estimates," but to provide you with the information about the tasks that you need to manage with Critical Chain Scheduling and Buffer Management. A well structured introduction to the concepts (and overall implementation process) avoids the pitfalls of misinterpreting what is actually happening in the process, and smoothing out the buy-in process. 14 - Why critical chain instead of critical path? Answer A -- A critical path typically goes from the beginning of the project to it's end. A critical chain ends at the start of the project buffer. (And depending on the application of feeding buffers, the start of a project may actually be with a non-critical chain of tasks.) Answer B -- Too many people believe a critical path is what the software tells them before leveling resources. "Path" is too often interpreted as the logical hand-off dependencies and that interpretation does not take into account resource dependencies. The critical chain is explicitly defined as a resource-leveled set of tasks. 15 - If Critical Chain comes from TOC thinking, what is the constraint that's involved? When we are talking about the idea of a constraint in any area, it has meaning only in terms of the system that we are concerned with. In the application of TOC to project management, there are two systems that can be involved. The first is the system that is a single project. The second is the system that is the organization responsible for delivering projects -- a multi-project environment. Let's talk about single projects first. The goal of a project is to deliver some benefit to its sponsor -- a new product sold to a paying customer, a usable building, or a new process

that improves the ability of that sponsor to achieve more of their goal(s). If the goal of the project is defined like this, then the sooner the outcome is delivered, the more potential benefit can be accrued (in most cases at least). What is the limiting factor (the constraint) on the ability to take advantage of that outcome - to get more benefit? It's the fact that there's a bunch of work to be done to deliver it -- the tasks that make up that project, and the time it takes to perform them. Hence the role of effective project management is to identify the critical chain of tasks that are constraining the project owner from using the outcome, and manage it in a manner that minimizes that time and, given their probable existence as necessary conditions associated with the goal, do it in a way that provides a reliable promise and with reasonable expense. The critical chain of a project is defined as its constraint. Now, if we are talking about multi-project environments, finishing one project on time, as specified, and within budget is nice but not enough. The goal of an organization that is charged with making a number of projects happen is to maximize what might be considered momentum -- speed times number of valuable projects, again also supporting the necessary conditions of quality and cost as well. What is its constraint? What keeps project-based organizations from delivering more value to its clients (if the projects are owned by external entities like most construction environments) or to the larger organization (if the project organization is something like an R&D or IT shop)? There are two possibilities to consider. Assuming that the project portfolio depends on a set of shared resources, the capability and capacity of those resources might reasonably be considered a constraint at first glance. Taking this to its logical conclusion, there may be a few resource types that are more loaded and more commonly used than others. It is then these "weak links" of the resource chain that can more appropriately be looked at as a constraint. But before concluding that, one must ask how these resources are being used. Are there any policies or practices that impinge on the ability of those resources to do more? In a multi-project environment, what usually limits the resources' capability to do effective work is a combination of too much unsynchronized work in the system and a lack of clear direction regarding priorities for the use of one's time, resulting in time-wasting multi-tasking. So for most multi-project organizations, the real constraint is typically seen as the policy/practice of unsynchronized launch of too many projects without regard for the capabilities of the system and without effective mechanisms for setting resource priorities. Without going into details here (but which are available here), the TOC solution for multiproject systems takes advantage of the superficial and distracting, but visible, existence of heavily loaded, commonly used resources to address the deeper question of how to synchronize the workload, and uses buffer management to provide up-to-date priority through the execution phase of the project. 16 - What is TOC? The Theory of Constraints (TOC) is an approach to managing complex systems (like projects and organization) that is based on the idea that at any point in time, there are actually very few factors associated with that system that represent the limitations on its ability to achieve more of its goal. Originally introduced in The Goal, by Eli Goldratt and Jeff Cox, TOC has spawned a range of applications impacting most functions found in organizational systems, as well as general problem-solving approach based on finding the deepest actionable source of limitations and problems. "Critical Chain" and its collection of tools and techniques is the result of applying TOC analyses to the realm of project management

17 - How does Critical Chain fit with PMI's PMBOK Guide processes and knowledge areas? PMI's "Guide to the Project Management Body of Knowledge," commonly known as the "PMBOK Guide," is an excellent attempt at clarifying the interactions of the different processes and knowledge areas associated with the subject. Critical Chain Scheduling and Buffer Management (as well as the Multi-Project Management Method) is an approach that was built up not from the pieces of the PMBOK, but from the goals and common problems associated with project management, from an understanding of statistical variation, and most importantly, from an understanding of human behavior. That the result of the common sense that went into its development provides coherent solutions to issues individually identified in the PMBOK is a testament to both the PMBOK and the utility of Critical Chain Scheduling and Buffer Management to achieve what the PMBOK prescribes. Based on the identification of project management processes found in the 1996 edition of the PMBOK Guide, Critical Chain-based project management is related to the following processes. Initiating Processes - Projects are selected to further the attainment of the goal(s) of the organization. In assessing and launching projects, TOC emphasizes the relationship to throughput and its protection or enhancement. As such, the initiation of a project in the TOC world would typically drive a scope that results in actual attainment of throughput, sometimes expanding project scope beyond that acceptable in non-TOC environment. While the PMBOK Guide has little to say about multi-project management, the TOC solution for that realm of the subject is applicable to the prioritization, assessment, and launching of projects in a system characterized by (practically) finite resource capacity. Planning Processes - In the TOC world, network building, identification of the critical chain, drum scheduling, and buffering provide key requirements of the core planning processes. Cost estimating and budgeting are dealt with via the little-written about budget buffer. Facilitating processes in this category include, among others, risk identification and quantification. To the extent that Critical Chain-based PM is schedule-centric, schedule risk is an inherent part of a critical chain schedule and is dealt with, at least in the planning phase, through appropriate buffer sizing. Another key facilitating process is communications planning, which, in the TOC world, is centered on the wide distribution and understanding of a buffer report. Executing Processes - One of the core processes mentioned in this category is quality assurance. The critical chain approach provides support for this need of projects by removing artificial due-date pressure on activities, allowing the activity to do what is necessary to assure a quality hand-off without unnecessary concern about due dates. Effective execution is also enhanced by the full focused attention on tasks at hand associated with Critical Chain's single-tasking "relay race behaviors." Controlling Processes - Schedule control, performance reporting and risk response control all are supported by Buffer Management in the TOC approach. Changes to the schedule are assessed by their impact on buffers. Performance reporting, defined as status reporting, progress measurement, and forecasting, is the raison dtre of buffers and buffer management. Risk response control is aided by buffer management in its contribution to the ability to focus on the serious issues as they arise.

Closing Processes - It is not yet clear to the writer where TOC impacts the primarily administrative processes of closure and contract close-out. 18 - What can I expect if I pilot Critical Chain on one project in a multi-project environment rather than implementing the full multi-project application? While it can be accomplished, piloting a process that relies on one set of behaviors while around it are conflicting processes and behaviors is rife with risk. Considerable attention to avoiding infection across the two cultures will be required, and as a result, it may be unclear to some that the project's success came from Critical Chain or from the special attention it received in that effort. It's not impossible, but it requires additional efforts that may make it a bit daunting. Plus, once piloted, you still face rolling it out to the rest of the organization. Alternatively, a direct implementation of the full multi-project solution can be designed in a phased approach that provides the benefits of a pilot's ability to identify needed alterations in the process or in the organization, but also helps to attain full organizational benefit as quickly as possible. 19 - Is there software that supports Critical Chain processes? Yes. Homex India uses Projnir software.