Critical Chain

From apppm
Jump to: navigation, search

Category:Critical Chain by Sigrid Thorgaard

Contents

Abstract

Critical Chain Project Management(CCPM) was firstly introduced by Israeli physicist, Eliyahu M. Goldratt in his book “Critical Chain”. The development of CCPM was a response to the limitations of the critical path method leading to project delays. The article consists of the following subsections following the structure of first explaining the idea behind CCPM, its application and lastly its limitations and critique. The following key-points derived from each subsection are:


  • Why safety buffers are wasted in traditional scheduling

    Firstly the article explains the recurring problems with resource-constrained project scheduling (RCPS). With traditional project planning a high safety margin is placed between project deliverables to reduce the risk of project delays but these safety buffers are easily wasted; it is observed that early finished tasks are not passed down the project schedule while late finished tasks will always be passed down due to "the student syndrome" and Parkinson's law.


  • Bad Multitasking

    Bad multitasking is when the project is slowed down because resources are split between multiple tasks.


  • Critical Path versus Critical Chain

    There is a clear difference between the critical path and the critical chain since Critical Chain takes ressources into account. The critical chain will be more accurate than the Critical Chain, giving a more realitic picture of the project duration but also ensure that ressources are used efficiently.


  • Theory of Constraints

    CCPM stands on the shoulders of the management philosophy “Theory of Constraints” (TOC). TOC finds the weakest link or bottleneck in a production line through an iterative 5-step approach. CCPM extends the principles of TOC to the project domain e.g. when TOC finds the bottleneck in a production, CCPM finds the critical path for a project.


  • The different buffers in CCPM

    A big difference between traditional scheduling and Critical Chain Scheduling, is the placement of the safety buffers. In CCPM the safety will protect the final delivery date instead of all the milestones leading up to the final delivery. Feeding buffers will protect delays to the critical chain and resource buffers will add safety to activities carried out by resource bottlenecks.


  • Critical Chain application

    To apply the CCPM to a project there is a six step approach that needs to be followed. For the CCPM to work the company needs to organize a change in management and workstructures for a successful implementation. Especially for implementation in multi-project environments there are additional criteria in the shape of a bottleneck-buffer.


  • Limitations and Critique

    CCPM has been implemented by various companies in complex projects with high risk, but it has also been criticized for its lack of focus on quality and its simplified method for computing project buffers. Despite its limitations, CCPM remains a popular tool for companies looking to improve their project management performance in terms of time, expecially in the Arorospace and Defence industries.

Why safety buffers are wasted in traditional scheduling

Often rough estimates are made to produce a seemingly complete project schedule with task due dates and important milestones. Since there is high uncertainty in this planning stage in accordance with the rolling wave principle, a high safety margin is placed between project deliverables to reduce the risk of project delays (Figure 1)[1]. Other reasons for a high safety margin can be explained by project managers protecting their estimations from a potential cut by the board or steering group meaning they will state double the safety they actually need. In general time estimates are based on a pessimistic experience and often the larger the number of people involved, the higher the total safety estimation will be. Each level in the organization will simply add their own safety factor on top of the others.

As figure 2 states “Where does it go”, what frustrates many Project Managers (PMs) is seeing these safety buffers wasted. The reasons for this waste can be explained by two recurring problems:

  • People procrastinate and start on a task to finish the task just in time, also called "The student syndrome"
  • Even if a worker finishes early they use all the time available, which can be explained by Parkinson's law. If one finishes early they will expand the scope and use more effort on the task than required.

Furthermore, some workers will hide that they have finished their task early since reporting an early finish will invite pressure from management in the projects to come. The early finishes can also make the worker become unpopular among colleagues since they have to deal with the preceding tasks earlier than originally planned.

These structures mean ultimately that early finished tasks are not passed down the project schedule while late finished tasks create a domino effect; either the project will be on time or running late[2].

  • Figure 1: Single safety buffer estimate[1]
  • Figure 2: Sequence of tasks with safety buffers[1]

Bad Multitasking

Another problem in regards to being on time is bad multitasking. Bad multitasking is to use resources across multiple projects in a way that ultimately slows down all projects. The resource is split between multiple tasks which will slow down producitivy given the amount of communication time switching from one task to another.

Multitasking can lead to a loss of attention leading to mistakes and errors which will increase the production time even more. It is belived by Goldratt that by avoiding multitasking, people can work more efficiently with less mistakes and errors[2].

Introducing Critical Chain

The purpose of CCPM is to be efficient in project management meaning delivering the project within the planned deadline. The big idea behind Critical Chain is to eliminate or reduce the aforementioned problems in the resource-constrained project scheduling through a different scheduling technique and management of buffers.

It is a methodology that helps build the schedule with task durations that are too short to encourage multitasking, procrastinations or scope expansions of the task. In traditional scheduling, time buffers are an integral part of the task duration estimates. CCPM argues that the only important milestone is the final delivery date and therefore all tasks should not be forced to complete on time since individual tasks will vary in duration from the estimate. Therefore the PM should rather monitor the use-rate of the buffers instead of monitoring the delivery of specific milestones in order to know whether the project is on time [1].

Critical Path versus Critical Chain

Critical Chain is standing on the shoulders of Critical Path, which is the longest chain of task dependencies made in order to calculate the end-date and monitor the progress of the project. The critical chain is likewise the longest chain but other than interdependent tasks it also takes resources into account.

Example Figure 3 shows an example of a project, where the critical path is EFGHM. If we were told that Activity C and G are to be performed by the same resource, they cannot be performed simultaneously as otherwise planned. Because activity G is on the critical path it should arguably be done before activity C. Even though EFGHM states a finishing time of 52 weeks, the start of activity C will consequently be delayed 18 weeks meaning that ABCDM becomes the longest path resulting in a finishing time of 66 weeks (10+6+10+18+14+8).

Following the Critical Chain which includes resource considerations (Figure 4), the project duration is estimated to 62 weeks (10+6+10+18+10+8) since tasks are arranged according to resource dependencies. This means that the Critical Chain is more accurate in its estimate but also ensures resource efficieny leading to an earlier finishing time.

  • Figure 3: Critical path example[3]
  • Figure 4: Critical chain example[3]

Theory of constraints

Critical Chain builds upon The Theory of Constraint (TOC) introduced in Goldratts book “The Goal” from 1984. Theory of Constraint is a theory for production management but Goldratt links the same principles to project management through CCPM in "Critical Chain" from 1997 [2].

Theory of Constraints addresses the problems with the application of the Pareto Principle in dependent systems. In systems composed of independent tasks, it will be possible to reap more benefits than problems solved, where approcimately 80% of the effects originate from 20% of the causes [4]. However, for dependent tasks a local optimization will not result in a global optimization. Eg. if a machine is optimized it will simply stack inventory leading to more inventory costs if the other machines depending on the optimized machine's output are still running at the same speed as before.

TOC distinguishes between the cost world and the throughput world.

  • In the cost world mentality the performance of each step needs to be protected, meaning that all workers will locally optimize their own station.
  • In the throughput world, the only thing that counts is the performance as a whole.

It can be stated that for the ‘throughput world’ the pareto principle is not always applicable[2]. It is possible to draw parallels from TOC to JIT, where the goal is to reduce lead time globally in the company. TOC will also not allow local optimization where too much inventory is accumulated between two machines or centers (as can be seen in step 3 of the five step approach)

The five step approach of TOC

  1. Identify the system’s constraint(s)
  2. Decide how to exploit the system’s constraint(s)
  3. Subordinate everything else to the above decision
  4. Elevate the system’s constraint(s)
  5. Repeat

The system’s constraint is the weakest link, e.g. a machine in a production line, only producing half the units of the other machines. If you strengthen the weakest link sufficiently it will not be the weakest link anymore and you will not reap any benefits by continuing to strengthen it. Therefore the five step approach is iterative which can be seen in step 5 forcing you to continuously identify and improve the system’s constraints.

The link in TOC to CCPM is that like in a production where safety is measured in inventory, safety is measured in projects as buffers. In projects using CCPM the equivalent to the system’s constraint or bottleneck is therefore the critical path.

The different buffers in CCPM

Critical Chain acknowledges the need for safety margins in projects to reduce risks but as seen earlier, safety margins in it-self will not necessarily prevent the project from being late.

A big difference between traditional scheduling and Critical Chain Scheduling is the placement of the safety buffers. As figure 5 indicates, a big part of the safety is taken from the individual tasks and pooled at the end of the final project deliveries. The consequence is that the safety margins are shared globally by the whole project meaning that the performance of the project in terms of time management is evaluated globally; being on time becomes a shared responsibility.

The shared responsibility supports the argument that everyone will now complete their task as quickly as possible to reduce the consumption of the buffers. While working as fast as possible, the team will still have a safety-net where they can feed on the buffers to ensure quality and a healthy work environment. Often the buffers in CCPM are divided in three categories: project buffers, feeding buffers (Figure 6) and resource buffers.

  • The project buffers: Placed between the last task of the project and the official completion date ensuring the final date is not prolonged.
  • The feeding buffers: Placed at the end of non-critical chains preventing delays to the critical chain.
  • Resource buffers: Placed prior to critical tasks protecting the critical chain from resource bottlenecks delaying the project.
  • Figure 5: Project safety buffer in CCPM[1]
  • Figure 6: Feedingbuffer in CCPM[1]

Critical Chain application

In order to apply Critical Chain the following steps need to be followed.

1. Determine order of tasks and critical path: Identify the tasks needed to succeed with the project management as well as the task’s sequence. This planning can be done using eg. work-breakdown structure and/or reverse scheduling. Determine critical path.

2. Level resources: Identify resource constraints and arrange tasks according to resource dependencies. Determine critical chain. At this stage the Critical chain is identical to a leveled Critical Path.

3. Slice the duration of the tasks in the critical chain: Typically the PM will decide on half/half but other ratios are also possible. It is argued that since target durations are 50% confidence estimates, it is expected that half of them are finished early and the other half finishes late. A project buffer of half the project duration is therefore assumed to protect the project sufficiently since the early tasks will equalize the tasks running late. Pool the removed task durations as one project buffer after the last task. The official end-date that is communicated to stakeholders now corresponds to the project buffer’s end date.

4. Slice the durations of the non-critical tasks: Put the removed task durations of the non-critical tasks as feeding buffers between non-critical tasks and the critical chain. Notice that it is still possible to insert floats in between non-critical tasks [5].

5. Account for scarce resources: Insert resource buffers prior to activities that require critical resources.

6. Monitor: During the project monitor the use of the use-rate of the buffer. The use-rate helps to anticipate the risk of the project's delay and respond in time. In terms of knowing when to act it can be helpful to use a fever chart that compares the use-rate of a project buffer to the completion of the project in percentage. If the use-rate’s slope is greater than 45 degrees, the use-rate of the buffer progresses faster than the completion rate of the project [6].

Figure 7: Monitoring of use-ate relative to completion rate[7].

Company criteria for application

For the CCPM to work there are certain protocols for the resources in the company:

  1. Workers cannot multitask (meaning one task cannot be interrupted to start another) when working on critical activities
  2. Workers need to start immediately on the task’s successor

These success criteria demonstrate that the CCPM is not a technical change on scheduling and monitoring but requires changes in management for a successful implementation. Especially in a multi project environment (eg. managing portfolios) the PMs will develop a critical chain for each individual project but since ressources often are shared, management will need to be responsible for protecting resources from competing priorities that will otherwise result in multitasking.

Implementation in multi-project environments

Typically companies do not run single projects, an estimation is that up to 90% of all projects are carried out in a multi-project environment. In Goldratts book “Critical Chain”, the solution to this problem is stated to be:

“ Make sure to allocate resources carefully across projects to minimize the constraints on shared resources”[2].

It is here clear that PMs will need to supplement the guidelines of CCPM to fully do resource allocation in this environment. Project leaders will likely fight over what steps to postpone when facing resource contention and therefore the company needs to know how to properly manage these internal conflicts in order to implement Critical Chain successfully. The solutuion to the right prioritarization is explained by Goldratt to be in terms of the completion dates of the projects. This is again a clear link to management of production orders, where task priorites are determined by the due dates of the orders.

When running multiple projects at the same time, the buffers earlier defined are not adequate. Both project buffers, feeding buffers and resource buffers are protecting the individual project. Looking at multiple projects, the bottleneck needs to be identified to protect the overall performance of the organization. Therefore a new buffer is needed; the bottleneck buffer.

There are no rules for the size of the bottleneck buffer but it is placed before a shared bottleneck between all projects. Eg. if all projects in a company needs to have work done by the same department with limited resources, all project paths leading to that department should include a bottleneck buffer to account for delays[2].

Limitations and critique

Multiple companies from various industries have implemeted the CCPM, most examples of companies having implemented CCPM such as Boeing and Phillips was in the early-mid 2000s. Therefore one can question whether the method have lost some of its relevance. When looking at the comapnies that have implemented CCPM, most have complex projects with high risk e.g. within Aerospace and Defence [8].


For all projects, CCPM has its limitations and is critisized by some of its characteristics:

A RCPSP solution An obvious constraint to CCPM is that it is a solution to the resource-constrained project scheduling problem (RCPSP). This means that other problems in terms of resourcing eg. resource leveling problem or the multi-mode resource constrained project scheduling project (MRCPSP) are not addressed. Furthermore, RCPSP has the objective to minimize the duration of the project subject to resource constraints but other objectives, such as quality, needs to be prioritized as well using other methodologies or tools than CCPM. Specifically quality is challenged in RCPSP since the tight deadlines risk resources to deprioritize quality. In other words, the methodology deals with only project management success and not project success which depends on the derived value of the project’s deliverables. [9].

'Focus on delays Another limitation to the problem is the heavy focus on delays instead of budget overruns. Even if the project is finished on time, the project management success will suffer from a cost overrun in eg. the case of too many resources allocated.

Focus on human resources CPPM deals with one type of resource: humans but other resource types such as money or energy are not taken into account during the planning using CCPM.

The buffer estimates In the methodology all task durations are cut by the same percentage despite the fact that people have different experience in estimating and will overestimate task durations to different degrees. Therefore, it can be argued that a more detailed method to compute the size of the project buffers is needed. Always relying on the median of a right-skewed probability distribution might be too simple.

Other than computation of buffers, there are also no rules or methods in CCPM to measure the preciseness of the given estimates to systematically improve the task estimates that are forecasted in the planning phase of all projects[10].

Multitasking The “no multitasking” can be difficult for PMs to enforce in a typical project environment consisting of multiple projects with shared resources. Multitasking is described as the root to many of the current problems in project planning by Goldratt. He clearly speaks his case when highlighting bottleneck resources that may increase flowtime of the individual task if they are working on other non-critical tasks in parallel. However, multitasking can also benefit the organization and improve productivity in some cases[10].

Demotivation and stress The removal of milestones and key dates for hand-ins have been criticized since these sub-successes are seen as a motivational factor for project participants. Some state that other than demotivating, it is even disrespectful driving the resources to work at 50% confidence levels knowing that only half of them will finish their task on time. It can be argued whether the work environment is healthy if all resources are pressured to finish deadlines as fast as possible which can result in stress [6].

Lack of continuous improvements A critical chain is not permanent during the lifecycle of the project and its relevance can change. Continuous improvements are needed in the case of changes in the critical sequences. The critical chain is only critical as long as it is the indicator of the project’s duration and it can therefore be argued that CCPM is not capable of standing alone without the use of the TOC methodology. In practice,intelligent scheduling algorithms are needed to efficiently manage these changes to the Critical Chain. In a small project the theory may be sufficient but in larger projects it will be difficult for the PM to monitor and change the critical chain manually. Changing the Critical Chain will also change the placement of many of the buffers.[10].

To conclude, CCPM is a simple and effective methodology but it cannot stand alone. Any company wanting to apply CCPM should apply CCPM within a project environment consisting of broader conventional project managament methodologies</critical look></ref>.

Annotated Bibliography

A risk-based Critical Chain Project buffer sizing methodology

  • City, Society, and Digital Transformation — 2022, pp. 331-344

Vaious risks exist in modern complex engineering projects. During recent years, adding risk considerations when determining the buffer sizes for the Critical Chain have been explored in multiple papers. This paper uses a case-simulation to demonstrate the effectiveness of this revised CCPM method. Their method includes the probability of risk occurrence and the degree of impact on activities.


A critical look at critical chain project management

  • Ieee Engineering Management Review — 2004, Volume 32, Issue 2, pp. 35-44

The premise of CCPM is that uncertainty in task duration is one of the major factors in managing a project on time. This article sheds a critical light on the limitations of CCPM in terms of other factors such as personal skills and leadership capabilities. Furthermore it critisizes the link that Goldratt makes between production halls and project environments.

References

  1. 1.0 1.1 1.2 1.3 1.4 1.5 Patrick, F. S.(1999). Getting out from between Parkinson's rock and Murphy's hard place. PM Network, 13(4), 57–62.
  2. 2.0 2.1 2.2 2.3 2.4 2.5 Goldratt, M., Eliyahu, (1997). ‘’Critical Chain’’ North River Press
  3. 3.0 3.1 Gray, V., Felan, J., Umble, E., & Umble, M. (2000). A comparison of drum-buffer-rope (DBR) and critical chain (CC) buffering techniques. Paper presented at PMI® Research Conference 2000: Project Management Research at the Turn of the Millennium, Paris, France. Newtown Square, PA: Project Management Institute.
  4. Prabir Jana, Manoj Tiwari, in Lean Tools in Apparel Manufacturing, 2021
  5. European Journal of Operational Research — 2006, Volume 172, Issue 2, pp. 401-416
  6. 6.0 6.1 Roland Wanner (2020) "How to Plan and Monitor Projects Successfully With Critical Chain" (Accessed: April 2023) https://rolandwanner.com/how-to-plan-and-monitor-projects-successfully-with-critical-chain/
  7. Raz, T., Barnes, R., & Dvir, D. (2001). ‘’A Critical Look at Critical Chain Project Management.’’ Article in IEEE Engineering Management Review (2004)
  8. Marris Consulting, (unknown). ‘’Critical Chain Project Management & MRO - How a new project management approach can help reduce Turn Around Time?’’ Marris Consulting (Accessed April 2023) https://www.marris-consulting.com/en/our-expertise/critical-chain-project-management/critical-chain-project-management-mro </critical look>. Raz et al, A critical look at critical chain project management, Ieee Engineering Management Review, Volume 32, Issue 2, pp. 35-4 (2004)
  9. pmbok®, (2021). A Guide To the Project Management Body of Knowledge (pmbok® Guide)– Seventh Edition and the Standard for Project Management (english), Project Management Institute, Inc
  10. 10.0 10.1 10.2 Herroelen, W. & Leus, R. (2000). On the merits and pitfalls of critical chain scheduling. Paper presented at PMI® Research Conference 2000: Project Management Research at the Turn of the Millennium, Paris, France. Newtown Square, PA: Project Management Institute
Personal tools
Namespaces

Variants
Actions
Navigation
Toolbox