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 poor time management in projects that the critical path method was not able to solve. This article will firstly explain recurring problems with resource-constrained project scheduling. To describe Critical Chain fully it will be compared to its precursor, Critical Path as well as the Theory of Constraints since CCPPM stands on the shoulders of this management philosophy. The elements that Critical Chain consists of and its application will be described and lastly the company criteria for implementation are listed and discussed as well as the method’s limitations.


Time management in projects

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. 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 management 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 become a waste of allocated resources. The reasons for this waste can be explained by two recurring issues in time management:

  • 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.

Critical Chain acknowledges the need of safety margins in projects to reduce risks but safety margins will not prevent the project from being late due to the aforementioned problems. Furthermore, these safety margins are shared globally by the whole project meaning that the performance of the project in terms of time management is evaluated globally.

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

It also needs to be added that some workers will hide that they have finished the 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. Another problem in regards to time management is bad multitasking. Bad multitasking means to use resources across multiple projects in a way that ultimately slows down all projects. Multitasking fails to complete tasks fast since the resource is split between multiple tasks and also due to the fact that there is a certain amount of communication time switching from one task to another.

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 [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 also the longest chain but other than interdependent tasks it 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.

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

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 CCPM in Critical Chain [3].

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[3]. 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 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 in the shape of feeding 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.
  1. 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.
  1. 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.
  1. 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].
  1. Account for scarce resources: Insert resource buffers prior to activities that require critical resources.
  1. Monitor: During the project monitor the use of the use-rate of the buffer. The use-rate helps 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 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”[3].

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. In Critical Chain, the priority of the tasks are managed the same way as in orders in production; in production orders’ priorities are determined by the due dates of the orders while in the project environment, the tasks should be prioritized by the completion dates of the project [3].

When running multiple projects at the same time, the earlier buffers 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.

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 critique that the method most 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].

RCPSP problem 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.

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 are needed.

Other than computation, there are 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.

Focus on delays and not budget overruns 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. Demotivation and stress The removal of milestones and key dates for hand-ins have been criticized since they are seen as a motivational factor and important sub-successes for project participants. Some even 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.

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. 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 Path. In a small project the theory may be sufficient but in larger projects it will be difficult for the PM to monitor and changethe critical chain manually.

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.

References

  1. 1.0 1.1 1.2 1.3 1.4 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 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.
  3. 3.0 3.1 3.2 3.3 Goldratt, M., Eliyahu, (1997). ‘’Critical Chain’’ North River Press
  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. 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
Personal tools
Namespaces

Variants
Actions
Navigation
Toolbox