Summary Critical Chain Goldratt

July 23, 2017 | Author: Shakira Mansoor | Category: Economies, Technology, Business, Computing And Information Technology
Share Embed Donate


Short Description

Short Summary of the book...

Description

Goldratt’s Critical Chain A Technical Summary

 Copyright Chesapeake Consulting, Inc., 1997 All rights reserved. No parts of this document may be copied or reproduced without the express permission of Chesapeake Consulting, Inc.

Technical Summary of Goldratt’s Critical Chain

Introduction The purpose of this document is to summarize the technical aspects of applying the Theory of Constraints (TOC) to project management as outlined in the book Critical Chain by Eli Goldratt. This document is structured according to the TOC five step focusing process and its two prerequisites. This document assumes the reader has been exposed to the Theory of Constraints and the TOC Measurement System.

 Copyright Chesapeake Consulting, Inc., 1997

-2

Technical Summary of Goldratt’s Critical Chain

Prerequisite 1 - Identify the System and its Purpose Identify the System As defined in Webster’s New Collegiate Dictionary, a system is “a regularly interacting or interdependent group of items forming a unified whole”. By definition a project is a set of interacting and/or interdependent tasks that must be completed according to specific parameters (e.g. time, budget, etc.) and by the appropriate resources in order to generate the desired result. Therefore, a project is a system. And with further analysis, it is concluded that a project is a system that operates and interacts within a larger system. For example, projects (e.g. software, engineering, new product development, etc.) are being planned and implemented within larger business systems (e.g. a manufacturing company, software development company, drug producing company, etc.) everyday. Define the System’s Purpose Since a project is a system operating within a larger system, then the purpose of the larger system needs to be defined before defining the purpose of the project. According to Stephen Covey, the purpose of a business system (as opposed to non-business systems, such as churches, fire/police departments, etc.) is “to improve the financial well being and quality of life of all stakeholders”. A business system with the above purpose will be used as an example of a larger system, but the concepts outlined in the remainder of the document can be applied to non-business systems as well. Now that the purpose for the larger business system has been defined, the purpose of the project system can be defined. In the chart below the solid line shows the typical sales cycle of a product, the dashed line represents the point in which sales would begin if the product were introduced earlier. As this chart shows, the earlier a product is introduced the sooner and potentially longer you can reap the benefits of selling that product.

$

Time Based on this, it can by concluded that a project contributes to the larger system’s purpose by completing as early as possible. By combining the key element of project lead time and the stated purpose of the larger business system, the purpose of a project (in a business  Copyright Chesapeake Consulting, Inc., 1997

-3

Technical Summary of Goldratt’s Critical Chain

system) is to complete as early as possible so that the financial well being and quality of life of all the stakeholders is improved quicker.

 Copyright Chesapeake Consulting, Inc., 1997

-4

Technical Summary of Goldratt’s Critical Chain

Prerequisite 2 - Determine the System’s Measures Based on the purpose of a project, the method for measuring the success of the project should be based primarily on the ability of the team to meet or beat the schedule (i.e. the sooner completed the better for all the stakeholders). This is not meant to imply that the cost is not important, but it does mean that any decisions in spending should be based on the amount of incremental Net Profit (NP) improvement that would be generated by finishing earlier versus the incremental increase in Investment (I) required to make that happen (ROI = NP/I). This method for measuring is in contrast to the more traditional method of measuring a project’s success according to the team’s ability to manage cost first and time second.

 Copyright Chesapeake Consulting, Inc., 1997

-5

Technical Summary of Goldratt’s Critical Chain

Step 1 - Identify the System’s Constraint A constraint is anything that limits the system from realizing a higher performance relative to the system’s purpose. Because time is the primary attribute of meeting the purpose of a project (“…complete as early as possible…improved quicker”), then we must determine what are the tasks and/or resources that determine when is the earliest a project can complete. It is widely accepted that the critical path of a project is the longest chain, in terms of time, of dependent steps. So, if time is the primary measure of a project and the critical path is the longest chain, in terms of time, of dependent steps, then the constraint of a project is the critical path/s. See figure below and note that all numbers are in units of days. In this example the critical path is 60 days (determined by adding up the total times for each chain of dependent steps).

15

10

10

5

10

15

10

10

15

5

5

20 Critical Path

The only problem with this conclusion is that there maybe multiple tasks on various noncritical paths which are required to be completed by the same resource. Realistically this resource will work on these various tasks in one of the two following manners • at different times until all tasks are complete (also known as multitasking, which is addressed in the subordination step of this process), or • in some specified sequence (typically of his/her own choosing), thereby completing a task prior to starting another. In either case, the longest chain, in terms of time, of dependent steps may not be the critical path. Therefore dependencies between steps can be a result of a path and/or a common resource. Since the dependencies between steps is not necessarily a result of a path, then the constraint of a project is not necessarily the critical path. Therefore the

 Copyright Chesapeake Consulting, Inc., 1997

-6

Technical Summary of Goldratt’s Critical Chain

constraint of a project is the longest chain, in terms of time, of dependent steps (where the dependencies are a result of paths and/or common resources). Goldratt states this as the definition for critical chain. See figure below and note that X identifies tasks performed by a common resource, and the dashed line with an arrowhead defines the critical chain (which is determined to be 75 days long versus the 60 day long critical path).

10 X

10

5 X

10

15 X

15

10

10 X

15

5 X

5

20

 Copyright Chesapeake Consulting, Inc., 1997

Critical Chain

-7

Technical Summary of Goldratt’s Critical Chain

Step 2 - Decide how to Exploit the System’s Constraint Since the critical chain is the constraint of a project, any time lost on the critical chain is lost forever. As a result the project will complete later than expected and the stakeholders will not reap the benefits as quickly as possible. In contrast, any time gained on the critical chain will improve the chances of the project completing early and the stakeholders will reap the benefits quicker. Therefore, it is imperative to do everything you can to minimize any lost time on the critical chain, and take advantage of any gains in time on the critical chain, i.e. exploit the system’s constraint Before defining solutions to minimize impact of lost time on the critical chain and take advantage of time gained on the critical chain, it would be helpful to understood how projects are traditionally scheduled and executed. Generally a project manager and team identifies the tasks to be completed and the expected time to complete each task. Then they add up the times on each path, identify the critical path, and add the critical path time to the expected start date to determine the expected complete date. The problem begins with the determination of expected time for completing each task. Each resource is typically asked to define how long it will take to complete their specified task/s. The resource estimates the time based on his/her last bad experience, thereby injecting safety time to insure completing the task/s on time. If a particular resource’s boss is responsible for several tasks, this boss will inject another level of safety to insure the task/s will complete on time based on his/her last bad experience. After all the expected task completion times are collected by the project team, then they inflate the estimates by another factor. The reason for this is that it is their experience that management will cut the overall project lead time by a similar factor, so the project will be scheduled to complete sooner. It appears that the higher the uncertainty of anyone making the estimates the larger the safety time factor. It is speculated that the typical project lead time includes about 200% safety time (i.e. a project scheduled for 300 days, has about 200 days safety time estimated). There are two issues here - first, why do projects still run late using this process, and second, isn’t this methodology (of adding as much as 200% safety) counter to the purpose of the project? Why do projects still run late with all that safety? The answer is that the safety is wasted. There are three mechanisms for wasting safety: 1. The student syndrome - waiting till the last minute to start because the resource knows he/she has plenty of time due to all the safety he/she included 2. Multitasking - a resource has several tasks for various projects to complete and attempts to work on them simultaneously, thereby increasing the lead time for a specific task by the amount he/she is working on other task; this also requires many “setups” (i.e. putting down one task and then picking up another, remembering where you were and what you were doing)

 Copyright Chesapeake Consulting, Inc., 1997

-8

Technical Summary of Goldratt’s Critical Chain

3. Dependencies between steps - delays accumulate faster over time than the advances; delays are frequent because of Murphy and the effects of the first two mechanisms, but advances are not taken advantage of because of built in safety in each task in combination with the behaviors in mechanisms 1 and 2. Isn’t this traditional methodology counter to the purpose of a project? The answer is yes; because as shown in the answer to first question, the safety and advances are wasted, thereby guaranteeing the project will finish either on time late (if “all goes well”), or late. The primary cause of this behavior is rooted in how resources are measured. Each resource is measured according to his/her ability to complete their task on budget and in the time scheduled (i.e. local optima) versus being measured on the project being finished on time or early (i.e. the purpose). Project and Feeding Buffers In order to exploit the critical chain according to the purpose 1. strip out from each task time a large percentage of the safety time • The task time should be reduced to a level where the resource has a 50% chance of completing on time versus 100% chance of completing on time (as traditionally done). As a result, the traditional methodology for measuring an individual resource according to their ability to finish their task in the allotted time (a local optimum measurement) is no longer valid. A more global measurement system should be used to encourage the behavior of individual resources to be more focused on completing the project early or on time (the purpose of the project). This reduction in task times minimizes the impact of the student syndrome (i.e. resources have less time to complete their specific tasks, therefore they will not wait as long to start), thereby reducing the opportunity to waste safety time. 2. sum the individual safety times on the critical chain and each non-critical chain, reduce the accumulated safety times of each chain by some factor, and locate these new safety times at the end of the critical chain and anyplace where the non-critical chains meet the critical chain • The safety time on the end of the critical chain is called the project buffer (this buffer is analogous to the shipping buffer in manufacturing DrumBuffer-Rope implementations). The project buffer protects the project scheduled completion date from Murphy events on the critical chain (and non-critical chains where the feeding buffer is used up and causing time to be lost on the critical chain, feeding buffer is defined in next bullet). By locating the safety time of the critical chain in one location, the safety time will not be wasted by any specific task that plans for it but doesn’t use it. • The safety times located where non-critical chains meet the critical chain are called feeding buffers (these buffers are analogous to constraint and assembly buffers in manufacturing Drum-Buffer-Rope implementations).

 Copyright Chesapeake Consulting, Inc., 1997

-9

Technical Summary of Goldratt’s Critical Chain

The feeding buffers protect the critical chain from the impact of Murphy on non-critical chains. In the example, assume 20% of the estimated times are safety. Reduce all times by 20%, then locate a project buffer at the end of the critical chain equivalent to the accumulated safety time on the critical chain reduced by 20% (follow same procedure for feeding buffers on non-critical chains). As shown in the example, an estimated time of 15 days becomes 12, therefore yielding 3 days of safety time to be used for the project buffer. Note after the defined calculations are completed a project buffer of approximately 10 days is created and located at the end of the critical chain (signified by the P.B. notation). The length of the critical chain now becomes 70 days, but in approaching the completion of tasks in this manner, it is possible for the project to be completed as early as 60 days. The feeding buffers are designated by the F.B. notation. 8 X

8

4 X

8

2

F.B.

8

4

F.B.

8 X

12

2

F.B.

4 X

4

1

F.B.

12 X

12

 Copyright Chesapeake Consulting, Inc., 1997

16

10 P.B. Critical Chain

-10

Technical Summary of Goldratt’s Critical Chain

Step 3 - Subordinate everything else to above decision/s The next step in this process is to subordinate all other activities (decisions, policies, etc.) to the maintaining and/or improving of the critical chain schedule (i.e. completing the project on time or early by minimizing the impact of Murphy and taking advantage of gains on the critical chain). The Golden Rule of Subordination In order to take advantage of gains made on the critical chain, institute the following rule for project execution: When a task completes on the critical chain (and non-critical chains, if the decision does not effect the critical chain), begin the next task as soon as possible. By adhering to this rule, gains made on the critical chain will not be lost because of the student syndrome. This will then improve the project’s ability to finish earlier (the purpose), and reduce even more the potential effects of Murphy occurring in a following critical chain tasks. Gains on non-critical chains decrease the possibility of non-critical chain Murphy events impacting the critical chain. Resource Contention and Resource Buffers Another issue that can cause a loss of time on the critical chain is resource contention. Resource contention occurs when everything is ready for a task to be started but the appropriate resource is working on something else, thereby causing a delay in starting and finishing the task. In the event of this possibility, locate safety time prior to the tasks this resource is responsible. The safety time should be large enough to insure the resource has at least a 50% chance of finishing the specific tasks on time. This safety time is called a resource buffer. A schedule should be created prioritizing the tasks (the tasks included may be on the critical or non-critical chains of various projects) expected to be in that resource buffer according to the following priority • critical chain tasks • these tasks should be sorted according to the scheduled project completion dates • tasks that are dependent on each other must be sequenced as they are in the project plan • non-critical chain tasks • these tasks should be sorted according to the scheduled project completion dates • tasks that are dependent on each other must be sequenced as they are in the project plan. Each task on the schedule should be completed prior to beginning the next scheduled task (see exploitation step for discussion of multitasking and its contribution to wasting safety time). In doing this he problem of multitasking will be resolved.

 Copyright Chesapeake Consulting, Inc., 1997

-11

Technical Summary of Goldratt’s Critical Chain

The project team should frequently notify the resource of the progress of the scheduled tasks, so that the resource will be prepared when the tasks are available to be started. This notification should begin no later than the scheduled start date of the resource buffer. The resource can continue to work on other tasks until the scheduled task appears at which time the resource immediately starts the scheduled task and completes it before continuing to perform other work. Now that there is an executable project plan in accordance with the purpose, a methodology to monitor the project and identify problems which may impact completing the project as planned must be developed. Buffer Management Remember, the project buffer was established to protect the project planned completion date. Therefore as the project buffer decreases (which is caused by falling behind schedule on the critical chain), the risk of not completing the project early or on time increases (which is counter to the purpose). The opposite is true as well, if the project buffer increases (which is caused by completing tasks on the critical chain ahead of schedule) the possibility of completing early is increased (which is the purpose). The project buffer decreases by the amount of time equivalent to the current date minus the current critical chain task’s scheduled completion date, if the current date is later than the scheduled date. Note, that the calculation for decreasing the project buffer is based on the fact that time lost on the critical chain is lost forever. The project buffer increases by the amount of time equivalent to the current task’s scheduled completion date minus the current task’s actual completion date, if the actual completion date is earlier than the scheduled completion date. This calculation uses actual completion date instead of current date, because the gain is not realized until the task is actually completed. The feeding buffers can be increased and decreased in the same manner. These buffers provide a focused method for identifying and working only the issues that are causing or may cause time to be lost on the critical chain. If the project buffer is decreasing, then the project team can identify the cause, define and implement solutions. The project team should also monitor feeding buffers and make adjustments before a noncritical chain causes problems on the critical chain. The buffers can be divided into two or three areas, each identifying a level of concern and awareness, and used in prioritizing work. As a history of projects is created using the critical chain methodology, a review of the buffers before and after would be beneficial. If the buffers are consistently larger at the end, then you may want to reduce the buffer sizes at the beginning of future projects. If the buffers are consistently smaller at the end, then you may want to increase the buffer

 Copyright Chesapeake Consulting, Inc., 1997

-12

Technical Summary of Goldratt’s Critical Chain

sizes. Also, information relating to causes of buffers decreasing can be used to focus improvement efforts, which should reduce the critical chain of future projects.

 Copyright Chesapeake Consulting, Inc., 1997

-13

Technical Summary of Goldratt’s Critical Chain

Step 4: Elevate the System’s Constraint The next step in the process is to elevate the constraint, i.e. reduce the length of the critical chain. Remember that the critical chain is defined as the longest chain, in terms of time, of dependent steps (where the dependencies are a result of path/s and/or common resource/s). Based on this definition, you can reduce the time on the critical chain by either reducing the number of dependent tasks, reducing the time to perform specific tasks, and/or reducing the number dependencies caused by common resources. Any opportunity for improvement should be tested using the ROI calculation. Compare the expected incremental improvement in Net Profit versus the incremental investment required to get that improvement in Net Profit. For companies who are project dependent, this approach should take into consideration the impact of this investment not only on the short term of a specific project or projects but over many future projects (e.g. should you hire additional resources or utilize subcontractors, make large technology investments or rent, out source or train, etc.). For companies who are not project dependent, this approach would take into consideration the impact the investment had on the rare project (e.g. should you contract consultants to manage an ERP Software System implementation project, out source some/all of the project’s tasks to subcontractors, etc.). Reduce the number of dependent tasks It would be expected that every task on any chain or path are necessary to the successful completion of a project. But, a review of the critical chain tasks may provide opportunities for eliminating tasks either because they are no longer valid or through some technological advance, thereby reducing the critical chain of a specific project or projects and/or future projects. Reduce the time to perform tasks Assuming that the tasks are necessary, review common critical chain tasks, identify the reasons for the amount of time required to complete, and implement the appropriate solutions. The solutions may include technology improvements, policy changes, training, etc.. Reduce number of dependencies caused by common resources To reduce the number of dependencies caused by common resources, make more available to perform the tasks. Options to increase the resources available to perform these particular tasks include - hiring, cross training, and/or outsourcing to subcontractors. Any combination of these options applied appropriately may reduce the time required on the critical chain.

 Copyright Chesapeake Consulting, Inc., 1997

-14

Technical Summary of Goldratt’s Critical Chain

Step 5: Do not allow Inertia to become the system’s constraint. If in the previous steps the constraint is broken, go back to Step 1. Elevating the constraint during an active project could cause the critical chain to move. It is important to be careful to consider the following: • • •

incremental improvement in Net profit versus the incremental Investment required to get that profit (ROI = NP/I) ability of the new non-critical chain tasks and resources to subordinate to the new critical chain risks associated with disrupting the project

If after elevating the critical chain moves, return to step one and follow the process. Be sure a critical chain is not made longer because of invalid policies, rules or assumptions. If the constraint is not broken and a satisfactory project plan is developed, implement the plan. As the plan is executing, utilize the various rules (such as starting tasks on critical chain as soon as possible and no multitasking), measurements (emphasis on time and overall project completion versus cost and individual task completion), and buffer management techniques to manage the project. In the case where elevation is directed at future projects (especially companies who are project dependent), it must be emphasized - be sure future critical chains are not made longer because of invalid policies, rules or assumptions.

 Copyright Chesapeake Consulting, Inc., 1997

-15

View more...

Comments

Copyright ©2017 KUPDF Inc.
SUPPORT KUPDF