Critical Chain

From apppm
(Difference between revisions)
Jump to: navigation, search
(Limitations and critique)
(Limitations and critique)
 
(2 intermediate revisions by one user not shown)
Line 150: Line 150:
 
''“ Make sure to allocate resources carefully across projects to minimize the constraints on shared resources”''<ref name=critical> Goldratt, M., Eliyahu, (1997). ‘’Critical Chain’’ North River Press </ref>.
 
''“ Make sure to allocate resources carefully across projects to minimize the constraints on shared resources”''<ref name=critical> Goldratt, M., Eliyahu, (1997). ‘’Critical Chain’’ North River Press </ref>.
  
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 tasks' priorities are determined by the due dates of the orders.  
+
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 solution 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 tasks' priorities 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<ref name=critical></ref>.
 
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<ref name=critical></ref>.
Line 160: Line 160:
  
 
For all projects, CCPM has its limitations and is critisized by some of its characteristics:  
 
For all projects, CCPM has its limitations and is critisized by some of its characteristics:  
 +
  
 
* '''A RCPSP solution'''<p>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. <ref name=pbbok> 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 </ref>. The importance of being on time is not universal across projects and for many stakeholders, a project that exceeded the schedule but earned e.g. 10 times its costs back in profits would be considered a more succesful project than a project that only delivererd on time<ref name=criticallook> </ref>.</p>
 
* '''A RCPSP solution'''<p>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. <ref name=pbbok> 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 </ref>. The importance of being on time is not universal across projects and for many stakeholders, a project that exceeded the schedule but earned e.g. 10 times its costs back in profits would be considered a more succesful project than a project that only delivererd on time<ref name=criticallook> </ref>.</p>
  
  
* '''Focus on delays in general'''<p>Another limitation to the methodology 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 e.g. the case of too many resources allocated. With CCPM the focus on delays is also very general since the methodology deals with the underlying reasons for delays in all projects by targeting the student syndrome and parkinson's law. Contrary, specific uncertainties to delays are managed through risk assessment and risk mitigation tools. Unlike risk project management methodologies, CCPM is not addressing the potential rootcauses to delays for specific projects<ref name=criticallook> </ref>.</p>
+
* '''Focus on delays in general'''<p>Another limitation to the methodology 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 e.g. the case of too many resources allocated. With CCPM the focus on delays is also very general since the methodology deals with the underlying reasons for delays in all projects by targeting the student syndrome and Parkinson's law. Contrary, specific uncertainties to delays are managed through risk assessment and risk mitigation tools. Unlike risk project management methodologies, CCPM is not addressing the potential rootcauses to delays for specific projects<ref name=criticallook> </ref>.</p>
  
  

Latest revision as of 06:18, 7 May 2023

Category:Critical Chain by Sigrid Thorgaard

Contents

[edit] 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 traditional critical path method leading to inaccurate project scheduling and 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 ensuring 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 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, especially in the Arorospace and Defence industries.

[edit] 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 that 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.

Additionally, 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 ultimately mean that early finished tasks are not passed down the project schedule while late finished tasks create a domino effect. The conclusion is clear; either the project will be on time or run late[2].

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

[edit] 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].

[edit] 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].

[edit] 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 a 4 week earlier finishing time in this example.

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

[edit] 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[5]. TOC will also not allow local optimization where too much inventory is accumulated between two machines or centers (which 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 the company 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[2].

[edit] 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[1].

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

[edit] 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 (WBS) and/or reverse scheduling. Determine critical path.

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

3. Estimate task durations with 50% confidence and define the projectbuffer:
Goldratt argues for a confidence interval of 50% in contrast to 90-95% confidence intervals used in traditional scheduling (see figure 1). Since 50% confidence estimates are equal to the average project completion time, safety has not been included thus not making room for parkinson's law or the student syndrome.

A project buffer of half the project duration (the length of the critical chain) will protect the project sufficiently since it is expected that the early tasks will equalize the tasks running late with a 50% confidence interval. Place your project buffer after the last task. The official end-date that you communicate to your stakeholders will correspond to the project buffer’s end date [2].

4. Define feedingbuffers:
Use half the length of the non critical chain leading up to the critical chain as the size of the feeding buffer. Place the feeding buffer between the last non-critical task in the sequence and the Critical Chain successor [6].

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 project 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 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 (figure 7) [7].

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

To ease the use of CCPM, different softwares can be used such as ProProfs, Asana, ProChain or Aurora CCPM. Asana promises to privide a platform for multiple projects in one place which can be beneficial when scheduling for multiple projects with resource overlaps[9].

[edit] 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 solely a change on how to schedule and monitor but requires changes in how to manage the project and its ressources. 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.

For a successful implementation, the company will both need to invest time and money in the correct software tool and change management.


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[10]. In Goldratts book “Critical Chain”, the solution to CCPM in multi-project environments 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 solution 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 tasks' priorities 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].

[edit] Limitations and critique

Multiple companies from various industries have implemeted CCPM, but most examples are from the early-mid 2000s such as Boeing and Phillips. Therefore one can question whether the method has lost some of its relevance.

When looking at the companies that have implemented CCPM, many projects are complex with high risk e.g. within Aerospace and Defence [11]. Users of CCPM have reported significant time reductions and better time accuracies in projects. However, sources also claim that these companies had little to non use of more conventional project managament methodologies when implementing CCPM and it is still unknown whether CCPM performs better than other project management methodologies in practice [12].

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. [13]. The importance of being on time is not universal across projects and for many stakeholders, a project that exceeded the schedule but earned e.g. 10 times its costs back in profits would be considered a more succesful project than a project that only delivererd on time[12].


  • Focus on delays in general

    Another limitation to the methodology 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 e.g. the case of too many resources allocated. With CCPM the focus on delays is also very general since the methodology deals with the underlying reasons for delays in all projects by targeting the student syndrome and Parkinson's law. Contrary, specific uncertainties to delays are managed through risk assessment and risk mitigation tools. Unlike risk project management methodologies, CCPM is not addressing the potential rootcauses to delays for specific projects[12].


  • Focus on human resources

    CPPM deals with one type of resource: humans but other resource-types such as money, equipment 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 experiences 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[14].


  • 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 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[14]. A study by McCollum and Sherman (1991) found that matrix organizations with ressources working in multiple projects proved to be effective [15].


  • Demotivation and stress

    The removal of reachable 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 expected time. It can be argued whether the work environment is healthy if all resources are pressured to finish deliverables as fast as possible which can result in stress [7].


  • 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 larger projects it will be difficult for the PM to monitor and change the critical chain continuously since changing the Critical Chain will also change the placement of many of the buffers.[14]. In practice, intelligent scheduling algorithms are needed to efficiently manage these changes to the Critical Chain.


To conclude, CCPM is a simple and effective methodology but it cannot stand alone. Any company wanting to apply CCPM should make sure to apply CCPM within a project environment consisting of broader conventional project managament methodologies such as risk management. It is belived that due to the narrow view on time reduction and time accuracy, multiple other factors can also influence the project being on time. Finally, CCPM is recommended for companies that lack efficient project scheduling where main concern is meeting the project's deadline compared to focusing mainly on scope and/or quality.

[edit] Annotated Bibliography

A Risk-Oriented Buffer Allocation Model Based On Critical Chain Project Management

  • KSCE J Civ Eng 21 — 2017
  • DOI: 10.1007/s12205-016-0039-y

Various 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
  • DOI: 10.1109/EMR.2004.25048

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 qualiy. Furthermore the article criticizes the link that Goldratt makes between production halls and project environments.


Buffer sizing in critical chain project management by network decomposition

  • Omega (united Kingdom) — 2020, Volume 102
  • DOI: 10.1016/j.omega.2020.102382

The article presents a new and more precise solution to buffer estimations.E.g. now the size of a feeding buffer is defined based on uncertainties of all connected noncritical chains and their relations with the critical chain, instead of only the uncertainty of the longest chain feeding on the buffer. The new procredure is based on network decomposition and can be extended to the planning of multiple projects that share resources.

[edit] References

  1. 1.0 1.1 1.2 1.3 1.4 1.5 1.6 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 2.6 2.7 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 (2021), "Lean Tools in Apparel Manufacturing", Elsevier Ltd.
  5. Karmarkar, Uday (1989), "Getting Control of Just-in-Time", Haward Business review (Accessed: May 2023) https://hbr.org/1989/09/getting-control-of-just-in-time
  6. Oya I. Tukel, Walter O. Rom, Sandra Duni Eksioglu (2006),"An investigation of buffer sizing techniques in critical chain scheduling", European Journal of Operational Research, Volume 172, Issue 2, pp. 401-416
  7. 7.0 7.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/
  8. Raz, T., Barnes, R., & Dvir, D. (2001), "A Critical Look at Critical Chain Project Management", Article in IEEE Engineering Management Review (2004)
  9. ProProfs Project (2023), "Critical Chain Project Management" (Accessed: May 2023) https://www.proprofsproject.com/blog/critical-chain-project-management/
  10. Naihui He, Nai David Z. Zhang, Baris Yuce (2022), "Integrated multi-project planning and scheduling - a multiagent approach", European Journal of Operational Research, Volume 302, Issue 2, pp. 688-699
  11. 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
  12. 12.0 12.1 12.2 Tzavi Raz, Robert Barnes & Dov Dvir (2004), "A critical look at critical chain project management", Ieee Engineering Management Review, Volume 32, Issue 2, pp. 35-4
  13. 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
  14. 14.0 14.1 14.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
  15. J. K. McCollum and J. D. Sherman (1991), "The effects of matrix organization size and number of project assignments on performance", in IEEE Transactions on Engineering Management, vol. 38, no. 1, pp. 75-78
Personal tools
Namespaces

Variants
Actions
Navigation
Toolbox