Critical Chain Method
Creating realistic and accurate schedules is the first step towards project success. In Project Scheduling, PERT and Critical Path Method (CPM) are widely known methods. Using CPM, early Start and Finish dates and Late Start and Finish dates are calculated by forward & backward analysis of the project network diagram paths.But this method, does not take resource limitation into consideration. After identifying the path, resources are picked up & leveled. In general, activity owners add safety margin (buffers) to each of the activities in order to cope up with uncertainties. But this cause time waste when activities can be completed well before the estimated finish date.
Critical Chain Method, developed by Dr. Eliyahu M. Goldratt (1997), is a schedule network analysis technique that takes account of task dependencies, limited resource availability & buffers. First step in this method is identifying set of activities that results in longest path to project completion which are called critical chains. As it includes resources into consideration, it may be longer than CPM schedule. Resources used in those critical chain activities are critical resources. Set of activities that are in non-critical chain but converging to critical chain are feeders. Next step is shortening the project schedule by reducing the activity duration estimates with effective buffer management. CCM focuses on eliminating project schedule delays due to uncertainties, overestimation of task duration and wasted internal buffers.
Critical Chain Method (CCM) in Project Management
We have studied the critical path method (in my previous blog post), which was used to develop the project schedule. This technique helped project managers manage their projects in the past. However, in today’s fast moving era, a project manager has to build an aggressive and realistic schedule because time is important, resources are costly, and the organization may be managing many projects at the same time, requiring cross utilizing of resources.In such scenarios in the past, project managers were having difficulties with managing schedules because of some inherent drawbacks of the critical path method.
These projects were having poor responses, such as not being able to complete on time, over budgeted, and in some cases terminated.
Issues with the Critical Path Method
The following are a few issues faced by project managers while dealing with the schedule based on the critical path method.Unlimited Resources
The first issue with the critical path model is that it is an optimistic model which assumes that all resources will be available at all times and can be utilized whenever they are needed.However, practically this was not always possible. Many times this assumption led to delay in projects and more spending.
Misuse of Float or Slack
Another issue with critical path method is misuse of float or slack.According to Parkinson’s Law which states that “work expands so as to fill the time available for its completion,” team members misuse the slack, causing the project to be delayed.
Activity Completion Gain/Loss
In the critical path method, even if an activity is completed before its planned completion date, the time gain cannot be utilized by the next activity, because the next activity has to wait until its early start date. Usually this happens because the resource allocated to the next activity may not be available at the moment.However, the opposite is not true. If any previous activity is delayed, this delay will be passed to the next activity and this may cause delay in the project.
In the critical path method, delays accumulate but gain does not.
Student Syndrome
The critical path method is also infected with Student Syndrome, where team members do not start the task until the last moment.So you see there were many problems with the schedule based on the critical path method.
There was a need to develop a more pragmatic approach to build the project schedule, help project managers to run projects efficiently, and hence consequently the critical chain method (CCM) came into existence.
The critical chain method (CCM) is also known as critical chain project management and was developed by Eliyahu M. Goldratt in 1997.
What are the Critical Chain, and the Critical Chain Method (CCM)?
The critical chain can be defined as “the longest path in the network diagram considering activity interdependence and resource constraints.”
(Path “Start->C->D->E->F->End” is the critical chain.)
The critical path can be assumed as a particular case of the critical chain when the project has access to unlimited resources that will never run out.
In other words, you can say that the critical chain method is a modified form of the critical path method. Here, availability of resources is considered while creating the project schedule.
In critical chain project management, instead of float, buffers are used. These buffers are designed in such a way that they completely eliminate the concept of float or slack.
Three types of buffers are used in critical chain management. These buffers are as follows:
Project Buffer
This buffer is placed between the last task and the project completion date as a non-activity buffer, and this buffer acts as a contingency for the critical chain activities. Any delay on the critical chain will eat this buffer, but the project completion date will remain unchanged. Also, if there is any gain from the early finish of any activity, this gain will be added to this buffer as well.Usually the duration of this buffer is 50% of the contingency that you have removed from each task estimate. This helps you move uncertainty from each task to the project buffer.
Please note that, although the critical chain starts from the beginning, it ends before the start of the project buffer. It does not end at the end of the project.
This duration will include any time duration borrowed from the project buffer or exclude the duration added to the buffer.
Feeding Buffers
These buffers are added to the non-critical chain so that any delay on the non-critical chain does not affect the critical chain. They are inserted between the last task on a non-critical chain and the critical chain.Feeding buffers are also calculated the same way as the project buffer. The duration of these buffers is based on some fraction of the safety removed from the tasks on non-critical chains.
Resource Buffer
These buffers are kept alongside the critical chain to make sure that they are available when they are required. This buffer can be a human resource or any equipment.Please note that, since the critical chain considers the resource constraints as well, it may be longer than the critical path schedule. However, this might be compensated by removing the contingencies from the activities.
Resources used in critical chain are known as critical resources.
Difference Between Buffer and Float (or Slack)
People often get confused between buffer and float. They find these two terms similar, however they are not.The following are a few differences between the float and buffer:
- Float or slack is a critical path phenomenon, and buffer belongs to critical chain.
- Float is the difference between the duration of the critical path and non-critical path. On a critical path, float is zero.
- Buffer is based on contingencies. For example, the project buffer is about 50% of the safety time that you have removed from the activity estimate duration. As per the definition of buffer, it is not zero on a critical chain or any other chain.
- Float is the same for all activities on a non-critical path, any activity can consume it partially or fully, and balance can be utilized by other activities. There is no further analysis.
- Buffer can also be borrowed by any activity if the activity is delayed. The project manager analyzes the remaining buffer to find the status of the project.
- Buffer can be divided into three categories: project buffer, feeding buffer and resource buffer. Float can be either total float or free float.
How to Create the Critical Chain Network Diagram
Three steps are required to create a critical chain from the critical path. These steps are as follows:- Remove all contingencies from activities, regardless of whether you have added the calculated contingencies or any percentage of it. If you’ve used the PERT (Program Evaluation and Review Technique) estimate to build the schedule, replace your estimate with optimistic estimate.
- Align the activities with late finish dates and remove resource constraints. Give priority to critical chain activities while assigning resources.
- Add feeding buffers to non-critical chains so that their durations become equal to the critical chain. Add project buffer to end of the critical chain, but before the project end date. The project buffer should be approximately half the contingency you removed from the activities. This helps improve the efficiency, and reduces the schedule duration.
Now, let’s see a real world example.
Suppose you get a project to construct a building. You build the schedule based on the critical path method, and start working on it.
However, during the execution of this project, you happen to know that:
- There is a shortage of cement, or
- Some of the equipment needed by you is assigned to some other projects, or
- One of your key team members is pulled out for some other important tasks by management.
Of course this will cause a delay in your project.
So, where was the problem?
Did the critical path not identify the resources required by your project?
No, the critical path had identified the resources for your activities.
So, where was the problem?
What did it go wrong?
The problem was with the resource allocation. Although the critical path had identified the resources, it did not account for the limited availability of resources into the schedule. The project schedule was developed optimistically, assuming that all resources would be available whenever they were needed. Unfortunately this could not happen in this case, putting the project in trouble.
Therefore, to solve these issues, you made some modifications to the critical path, considering limited resource availability. Now this critical path has been converted to the critical chain, and it is more realistic.
And now you can complete your project with more confidence.
Before this blog post ends, let’s revisit some key features of critical chain management:
- It is a deterministic model
- It avoids mismanagement of slack or float
- It optimizes the utilization of resources
- The project based on the critical chain method completes 10% to 30% faster than that based on the critical path method
- It is a more practical approach
- It encourages team members to perform efficiently, and
- It improves the productivity
========================================================================
Additional Info:
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 multi-project organizations. (Critical Chain is also the title of a book, by Eliyahu M. Goldratt, that introduces the basic concepts of the approach.)
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."
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 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.
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.
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.
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.
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.
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."
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.
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.
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.
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.
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.
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 un-synchronized 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 un-synchronized 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 multi-project 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.
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
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 d’être 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.
Yes.
At the time of the writing of this FAQ document (January, 2001) there are at least three major providers of software supporting Critical Chain at the multi-project level, and a couple additional minor providers of single project support software.
=========================================================================================
Resource buffers
A resource buffer acts as a warning signal when a shift in resources will occur on the critical chain.
While both the project buffer and feeding buffers act as mechanisms to transpose (part of) the removed safety time of the individual activities to safety time buffers, resource buffers act as warning signals that ensure the timely availability of project resources. More precisely, resource buffers can be set alongside of the critical chain to ensure that the renewable resources are available to work on the critical chain activities as soon as they are needed. Consequently, a resource buffer warning signal is added each time an activity needs a renewable resource that is not used by the previous activity. In figure 2, a resource buffer is added between activities 2 and 6 to ensure that resource B is available upon the start of activity 6.
No comments:
Post a Comment