Critical-Chain Approach

From apppm
Revision as of 20:07, 14 September 2016 by S124692 (Talk | contribs)

Jump to: navigation, search

Critical Chain Project Management (CCPM) is a methodology for planning, executing and managing projects. The focus is on the project schedule and to reduce project changes and cost overruns by taking into account resource allocations and time uncertainties of activities.

The method was developed by an Israeli physicist, Eliyahu M. Goldratt, who introduced it in his Theory of Constraint (TOC) book “Critical Chain” in1997, which later became the foundation of CCPM. It was developed to reengineer the project planning and management practices in order to eliminate common issues and problems that can lead to poor project results, such as increased cost, fewer deliverables than expected and frequently missed deadlines due to longer than expected durations of activities.

CCPM differs from other traditional project planning methods that have its origin in critical path and PERT algorithms in several ways. The emphasis is on resources available, flexible starting times, interim milestones in projects and the use of resource-, feeding- and project- buffers but not order of tasks and strict schedules. The CCPM attempts to level out the resources available where a switch between project tasks are often needed to make sure the project is on schedule.

The focus of this article is to introduce and explain the background and concept of the CCPM approach when planning and scheduling a project together with benefits and limitations of the method. Undesired effects of more traditional planning and scheduling methods will be discussed, followed by how to prevent these effects by using the CCPM approach.

Contents

The Author and the history

Author

Eliyahu M. Goldratt (1947 – 29111) was born in Israel and over his life he worked as a lecturer, researcher, scientists, and a business leader. Goldratt completed a Master of Science and a Doctors degree in Philosophy both obtained at Bar-Ilan University in Israel [1].

He is known for developing the groundbreaking Theory of Constraints (TOC), which he introduced in his book “Critical Chain” in 1997. The book reveals the reasons for why projects are unable to finish on time or within budget. In response to that, the TOC method was introduced [2] . This method reengineers the project planning and management practices in order to eliminate issues and problems that lead to poor project results. In addition he is the innovator behind several TOC tools such as “the thinking process”, “drum-buffer-rope” and the “Critical Chain Project Management” (CCPM) [1].

History

The importance of projects in today’s global and chaotic environment is becoming significant and will continue to grow in the future. All businesses have projects and they are turning to project management as a way to improve project results in order to stay ahead of the competition. Despite of precise planning and strict schedules through PERT/CPM approaches, lack of efficiency in project management has been a big issue in the last decades. The Theory of Constraints approach (TOC) to project management strives to eliminate this lack of efficiency by using the Critical Chain method when planning, scheduling and monitoring projects [3].

It all started with Eliyahu Goldratt’s first book, “The Goal”, a non-traditional approach to share knowledge. The book is a business textbook written in a novel form, disguised as a love story and tells a story of a manager in problems due to his poorly run manufacturing plant [1]. According to Goldratt, interdependency of elements influences the ability of businesses to do what should be done and that manufacturing plants can be controlled by three main measures; throughput (TH), operating expenses and inventory. Based on this, he described the Drum-Buffer-Robe (DRB) approach, which is to produce only what is needed. In his second book “It’s not Luck” he extended this method for marketing and distribution and the extended method became known as The Theory of Constraint (TOC). In his third book “The Critical Chain” he applied the TOC method to Project Management and this method is now know as Critical Chain Project Management (CCPM) [3]. The critical chain refers to the longest string of dependencies that are present in a project. The term chain is used instead of path, because the critical path is only linked to technical dependencies and not resource dependencies [4].

Theory of Constraints

Theory of Constraint (TOC) is a change method that focuses on identifying constraints or bottlenecks in processes and systems, to enable appropriate action to be taken to improve performance to gain more profit [5]. Goldratt applied this theory to marketing and distribution in his second book “It’s not Luck” published in 1994 [2]. According to him organizational performance is dependent on bottlenecks, which prevent the organization to maximize its performance and reach the objective, which is normally to increase profit [6].

These bottlenecks can include information, equipment, work force, and supplies and can be both internal and external to an organization. The fundamental concept of the theory is that, every business has at least one constraint, that is, any factor that limits the output of the organization and prevents it to improve the performance. In other word the weakest link in the chain. The theory also states that the processes or systems can only have one weakest link at a time, and that other weaknesses are not constraining until they become the weakest link. The theory can be used in various situations and is based on five steps to improve productivity [6].

The five steps of theory of constraint

Figure 2: "The five steps of Theory of Constraints"

The aim is to keep the constraint or the bottleneck as efficient as possible, because, only the efficiency of the bottleneck is a critical factor to the overall performance. There are five important steps to improve performance of a chain. Each step will be explained with an example in production planning terms [7].

  1. Identify constraints of the process or the system: It is important to identify the bottleneck. If the bottleneck is a machine, the maximum utilization must be achieved, ensuring there is always work to do for this particular machine [7].
  2. Determine how to exploit these constraints: Find ways to ensure the maximum utilization of the bottleneck. This could mean reducing the number of changeovers, offload work that can be done on another machine or reduce setup times to create additional capacity [5].
  3. Subordinate system’s constraints: It is meaningless to run other machines with a higher production rate than the bottleneck. Therefore every other decision must be subordinated to keep the bottleneck running [5].
  4. Elevate constraints to a new level of productivity: Concentrate all resources and efforts on the bottleneck to increase throughput rate or output. One way to do this is to run the bottleneck machine for extra hours every day, this increases the capacity of the machine [7]. The different between step 2 and 4 relates to the amount of investment required [5].
  5. Start again on step on: With increased capacity of the machine, there might be a new bottleneck, which needs to be addressed and the process of improvement must be repeated. Make sure inertia does not cause a system constraint [7].

Traditional approaches

Critical Path Method (CPM) is a traditional scheduling and planning method used in project management. The method is based on estimates of time required to complete project activities that lie on the critical path. The critical path is the sequence of interdependent activities in a project that add up to the longest overall duration [4].


Program Evaluation and Review Technique (PERT) is another traditional scheduling and planning methods and is identical to the CPM method. The difference between PERT and CPM, is that PERT assumes that each project activity duration has a range that follows a statistical distribution. PERT uses three estimated durations for activities to calculate the overall project duration [4].

Problems with PERT/CPM approaches

Figure 3: "Problems with PERT/CPM approaches"

Several problems are related to the use of PERT and CPM, the traditional approaches, when scheduling and planning projects. These factors have one thing in common; they can all cause delays in the project completions.

Variability of task duration and convergence points

Most projects have a multiple tasks that converge to another tasks in the critical path, see figure 3 where activities A and B converges to activity C. This means that both A and B must be completed before activity C can be started. Due to variability of task durations, the start date of activity C (the dependent task) may be incorrect. The impact of this problem can be escalated, because all projects have paths that merge into one end node. Both PERT and CPM approaches fail to take into account the variability of task durations [3].

Scheduling to a specific time

Traditional approaches make use of start date and task durations when planning and scheduling resources. This means that if activity A is completed early, activity B will still start on the earliest start date, in this example day 4,see figure 3. However, if activity A is completed late, activity B will start late, since the activities are sequential. Both PERT and CPM do not link the start of activity B to the real finishing time of activity A [3]. In addition, scheduling to a specific date can increase the probability of two unfortunate syndromes occurring, both of them leading to a failure of completing activities early.

Sandbagging: In project management, sandbagging refers to the practice of holding a complete work until the true due date arrives. This can produce poor picture of where the project and the organisation really stands [3].

Parkinson’s Law: This occurs when an activity is completed before deadline but resources are still improving the work until the due date is reached. A good example is when a worker is given a task that takes only a few hours to complete, but was allocated a few days of work in the schedule. The time spent on the activity is often expanded and finished at the last minute. This can also be adapted to budgets and other constraints [3].

Self-protection: The concept when workers fail to report early completion of activities out of fear that management team will adjust future standards and demand more next time. This means that if a worker estimates that an activity will take 5 days to complete but delivers the work in 3 days. Next time the manager might want to trim the estimate based on past performance [4].

Increasing the estimated duration time of tasks

This is an extension to problem 2. A path has 40% certainty to be completed at the earliest finish date, in day 12. However, this is not reliable enough, so the resource manager increases the time estimate by 25%. This means that activity B can now start on day 5, the earliest, and is scheduled to finish in day 15, instead of day 12. This means, that the path is more reliable, but an extra day is needed to complete the project [3].

Consuming slack early in the process

Considering a non-critical path with a total slack of 5 days and the management practice of delaying the activities of the non-critical path to save money. This means that activity A will start during day 5 and the whole slack is spent in the beginning of the sequence A-C-F. The slack is therefore no longer protecting the sequence if anything unexpected happens [3].

Student syndrome: The student syndrome is a common student behaviour to postpone the homework to the last possible start time, while at first working with a high level of slack. In project management, this syndrome can jeopardize the due date. This can be caused by, poor project management, unclear requirements, human nature etc. [8].

Resource issues

Figure 4: "Multitasking - shifting from one activity to another "

Neither PERT or CPM approaches do not take into account that resources might be needed at the same time. E.g. assume that activities C1 and C2 need the same resource C. If C1 starts first, C2, which is part of the critical path, will be late and therefore the whole project will be delayed. If C2 starts, activity C1 will be late and the non-critical path will become critical. Either way the project will not be finished on time [3]. Another big resource issue is the phenomenon of multitasking.

Multitasking and safety times: The performance of multiple project activities done at the same time is called multitasking, dividing time between multiple project tasks and shifting from one activity to another if there is no prioritization of activities. Multitasking is often thought of as a good way to improve efficiency of resources. However, the focus on local efficiency can damage the over all performance. This issue can easily be explained by comparing two project paths, see figure 4. Path 1 prioritizes the work of activity A and the activity will be completed in 10 days. Multitasking is used in path 2, where activity A is completed in 20 days but the total duration of both paths are 30 days. Another issue caused by multitasking is the increase in lead-time caused by increase in setup changeovers. This can often result in project managers adding extra time for each activity to be on the safe side in terms of project delivery time [8].

Dropped baton: This refers to the impact of poor coordination. If an activity is completed early and the resources for the new dependent activity is not ready, the time gained by completing the activity early, is lost. Inflexible resource schedules can cause this problem [4].

CCPM as a solution to these problems

CCPM was developed to reengineer the project planning and management practices, in order to eliminate the problems mentioned above, which existing methods, expensive software and tools had not been able to solve. These problems lead to poor project results such as increased cost, fewer deliverables than expected and frequently missed deadlines due to unrealistic estimates of activity durations. The biggest potential for improvements are connected to the common cause variation which the CCPM takes advantage of.

Dr. W. Edwards Deming, an American engineer and a management consultant, developed the theory of Common Cause Variation and defined two types of variations:

  1. Common Cause Variation: is caused by unknown factors resulting in steady but random distribution of outputs around the average of the data. This type of variation is inherent in the system and is a measure of how well the process can perform when the special cause variation is removed.
  2. Special Cause Variation: is a shift in outputs caused by specific factors such as environmental conditions or a specific machine. This type of variation can be accounted for and possibly removed.

All project activities have common cause variations in the time of activities, which represent uncertainty in performance. Traditional planning and scheduling methods estimate the impact of common cause variations and settle the problem by adding safety time for each activity [8]. CCPM deals with common cause variation by insisting on using 50% chance of completion before time estimates, but not 80-90% chance like traditional methods. In addition to shorten time estimates of activities the method uses strategically located buffers, which aggregates the safety time and protects the chain. There are three types of buffers used in CCPM:

  1. Project buffer: Due to common cause variations in time, the project duration is unclear. To tackle this, project buffer is added to the expected project duration.
  2. Feeder buffers: Buffers are added to the schedule where non-critical paths merge with the critical chain.
  3. Resource buffers: Additional time buffers are inserted where scarce resources are needed for a project activity.

Insisting on using 50/50 estimates will discourage Parkinson’s law, student syndrome and self-protection because there is less slack in the chain. Productivity will increase due to less slack and the method also provides resource buffers to protect activities from unavailable resources. This means the likelihood of dropped baton effect will be reduced [4].

As long as resources start the activity as soon as necessary inputs are received, work on an activity without multitasking, and passes on the activity output to the next activity as soon as it is completed, CCPM does not criticize performances that overrun the estimated activity durations.

CCPM allows the project team to focus on completing the project as soon as possible by only providing start dates for the whole activity chain and the end date of the project buffer. During the project, the plan only provides approximate start times and estimated activity durations for each project activity [8].

Critical Chain Project Management

Planning

Figure 5: "Traditional Schedule vs. CCPM Schedule "

The first step in CCPM is to create a project schedule. In order to do so, it is necessary to define all project activities that needs to be performed along with estimated activity durations, interdependencies between tasks and availability of resources. Availability of resources is a crucial part when applying CCPM and since a part of the resources have limited availability, the resulting schedule is likely to be longer than a schedule obtained by applying traditional methods.

After resource levelling, it is possible to identify the critical chain, which yields the project completion date. Resources that are allocated to activities that are part of the critical chain are referred to as critical resources. At this stage, the approach is identical to the approach of Levelled Critical Path.

The next step in the planning phase is to shortening activity durations based on the 50/50 chance of completing before time estimate. This means removing the safety margin, added by the worker who provided the estimate, from all the critical activities. The difference between the two project schedules, with and without safety margins for each activity, is called a project buffer and should now be displayed as a separate project activity in the end of the updated schedule, see figure x. Notice that, it is assumed that only half the critical activities will exceed the estimated time duration and the other half will be completed early.

This step is now repeated for all non-critical activities and a safety margin removed. A safety buffer is now only placed where the non-critical path merges into the critical chain, this type of buffer is called feeding buffer, see figure x. Notice that the non-critical path can still have slack.

The final step of the planning phase is to account for scarce resources. The third type of buffer used in CCPM is called resource buffer and located prior to critical activities that require critical resources. The buffer acts as a signal for the critical resources and notifies them that a critical activity is soon to be started [9]. This type of buffer protects the chain from resource bottlenecks, by causing critical resources to complete non-critical activities and to be ready to start working on the critical activity [4].

Execution

During the execution of the project plan it is expected that resources:

  • Work on critical activities continuously without multitasking
  • They complete the critical activity as soon as possible, regardless of schedule
  • When the critical activity is complete, they start immediately on the activity’s successor

If an activity is not completed on time, based on the time estimate in the schedule, there is no reason for concern since the buffer in the chain will absorb the delays. During the project, the CCPM schedule will be recalculated and buffer sizes adjusted in order to keep the final due date [9].

Control

The approach of CCPM uses the three types of buffers to monitor and control the project time performance. The monitoring process is based on buffer consumptions and is divided into three zones, OK (green zone), Watch and Plan (yellow zone) and Act (red zone), see figure x. As the buffer consumption begins to decrease and move towards the second zone (Watch and Plan) signals are set off in order to seek corrective actions. However, this warning mechanism is not used to its full potential unless the buffer consumption is compared with the actual progress of the project. As an example, if the project is 75% complete and the buffer consumption is 50%, there is nothing to worry about. Conversely, if the project is only 25% complete and the buffer consumption is 50%, appropriate and immediate actions must be taken [4].

Benefits

Criticism and limitations

Conclusion

References

  1. 1.0 1.1 1.2 Van Vliet, V.(2011) "Eliyahu Goldratt.", Retrieved on 11 September 2016 from http://www.toolshero.com/toolsheroes/eliyahu-goldratt/
  2. 2.0 2.1 TOC Goldratt.(2011) " Biography of Dr. Eliyahu M. Goldratt.", Retrieved on 11 September 2016 from https://www.toc-goldratt.com/tocweekly/biography-of-dr-eliyahu-m-goldratt/
  3. 3.0 3.1 3.2 3.3 3.4 3.5 3.6 3.7 3.8 Abreu, A., & Correia, F.(2011) "An overview of Critical Chain applied to Project Management.”, 4th International Conference on Manufacturing Engineering, Quality and Production Systems, Meqaps – Proceedings, 261-267
  4. 4.0 4.1 4.2 4.3 4.4 4.5 4.6 4.7 Gray, C. F., & Larson, E. W. (2011). “Project Management, The Managerial Process.” McGraw-Hill/Irwin, NY
  5. 5.0 5.1 5.2 5.3 Rand, G.K.(2000) "Critical chain: the theory of constraints applied to project management", International Journal of Project Management 18(3), 173-177
  6. 6.0 6.1 Mind Tools Editorial Team (2016) "The Theory of Constraints (TOC) - Strengthening Your "Weakest Link".", Retrieved on 11 September 2016 from https://www.mindtools.com/pages/article/toc.htm
  7. 7.0 7.1 7.2 7.3 McKellen. C.(2004) "Theory of Constraints", Metalworking Production. 148(6), 9-9
  8. 8.0 8.1 8.2 8.3 Leach, L.P.(2000) "Critical Chain Project Management Improves Project Performance", Project Management Journal 30(2), 39-51
  9. 9.0 9.1 Raz, T., Barnes, R., & Dvir, D. (2001). “A Critical Look at Critical Chain Project Management.” Article in IEEE Engineering Management Review (2004)

Annotated Bibliography

Personal tools
Namespaces

Variants
Actions
Navigation
Toolbox