The Five Focusing Steps: The Basic Decision Framework of TOC


The five focusing steps can be summarized as:

  • Step 1: Identify the constraint. A constraint is any element that limits the performance of a system, where performance is measured relative to the system's goal. Constraint identification must be the first step in any system-wide improvement process.

  • Step 2: Exploit the constraint. Exploitation is the development of a plan of action for the system constraint.

  • Step 3: Subordinate everything else to the plan. Subordination is the development of a plan of action for the system's non-constraints, in coordination with the previously developed constraint plan.

  • Step 4: Elevate the constraint. Elevation is the analysis and development of a plan to increase the performance of the system by improving the performance or the capabilities of the current system constraint.

  • Step 5: Go back to step one. In any system, actions may occur that cause the constraint to shift. If that happens, it is necessary to go back to Step 1 and repeat the process.

The basic assumption of constraint theory is that all systems have a limiting factor; the probability of the system being constrained is one. This is a critical assumption, and one that places the decision-maker in a decision environment under conditions of certainty, rather than the environment of risk. Initially ignoring the uncertainty that exists in a set of dependent tasks is a key trait of constraint theory. As will be explained later, the uncertainty in the system is accounted for and the effects of uncertainty are moderated through the use of strategically designed protection devices known as buffers.

While The Goal outlined the basic constructs of the TOC decision framework, it did not describe the numerous specific details necessary to apply the prescribed approach. This first occurred in two additional books by Dr. Goldratt. In The Haystack Syndrome (Goldratt 1990), the details of a scheduling application of the theory in traditional manufacturing operations were described. This methodology, which has experienced overwhelming success in manufacturing environments, is now widely known as the Drum-Buffer-Rope (DBR) scheduling technique. For an extended discussion of DBR and its application to a variety of manufacturing environments see Srikanth and Umble, 1997, and Umble and Srikanth, 1997. In Critical Chain (Goldratt 1997), the basic concepts are developed for applying the TOC approach to typical project management environments. The TOC-based project management scheduling method shares the name of the book in which it was first described—Critical Chain. Project Management in the Fast Lane (Newbold 1998) provides an excellent extended discussion of the critical chain approach.

In both manufacturing and project management environments, the recommended constraint theory approach to resolving problems is developed using the same five focusing steps described above. Both environments are treated as scheduling problems and solutions are developed using the same management constructs. It is important to understand the true underlying logical patterns of flow that exist in each environment. Thus, both environments are viewed from the perspective of "flow." In manufacturing environments, creating a logically correct product flow diagram (a combination of the bill of materials and the routing for each product) is essential. In project environments, developing a logically correct network diagram that considers both the precedence relationships and the resource dependencies is essential to successful critical chain scheduling.

We now describe how each of the five focusing steps applies to both manufacturing and project environments. This allows us to highlight the key similarities of the DBR and the CC methodologies.

Identify the Constraint

The most fundamental element of the TOC approach to improving system performance is to identify the constraint of the system. Generally, the system constraint is the one element that most limits the performance of the whole system.

Manufacturing Environments

For purposes of this discussion, consider a manufacturing plant that has insufficient capacity to meet all of the demand generated by the marketplace. In such a system, the constraint is the single resource (worker, machine, team, department, and so on) whose capacity is the most limited, relative to the workload placed on that resource. (In common terms, this constraint resource is often called the bottleneck.) This constraint resource determines the throughput capability for the entire system.

Figure 1 illustrates a basic product flow diagram for a simple manufactured product. The figure shows a process requiring that three materials (X, Y, and Z) be processed through four operations each. Upon completing processing, the components are assembled into the final product in a final assembly operation—identified in the figure as operation M. The figure also indicates that operations C and G are performed by the constraint resource.

click to expand
Figure 1: Product Flow Diagram for a Manufacturing Environment

Project Environments

But how should we identify the constraint for a project? Our working definition of constraint is the element that limits the performance of the system. In projects, the constraint cannot simply be a bottleneck resource because the key measure of project performance is project duration. Since the longest sequence of dependent tasks in a project network determines project duration, this longest sequence of dependent activities can be considered to be the project's constraint. We have avoided using the term "critical path" here because the common usage of critical path includes only precedence requirements between activities. However, in most project environments, there is significant resource contention. (Resource contention occurs when a resource is scheduled to perform two or more tasks during the same window of time.) In such cases, this contention for resources must also be included in the determination of the longest sequence of dependent activities. In general, when resource contention is taken into account, the longest sequence will be composed of activities that are both path dependent and resource dependent. That is, the longest sequence will consist of activities on multiple paths, connected by common resources. This more realistic concept of the longest dependent sequence of activities is called the "critical chain."

The distinction between critical path and critical chain can be illustrated with a relatively straightforward example. Consider a simplified diagram of a product development project network as illustrated in Figures 2 and 3. Figure 2 shows that the network consists of three paths. The figure also indicates that path EFGHM is the critical path, taking fifty-two weeks to complete.

click to expand
Figure 2: Critical Path for a Project Network

click to expand
Figure 3: Critical Chain for the Project Network in Figure 2

Figure 3 introduces a resource contention problem—activities C and G are performed by the same resource and cannot be performed simultaneously. Following critical path logic, since activity G is on the critical path, it should be performed before activity C. Accordingly, path EFGHM is finished in fifty-two weeks. However, the start of activity C will be delayed by eighteen weeks while G is being completed. This delays path ABCDM so that it takes sixty-six weeks to complete. In essence, the "critical" sequence of dependent activities is EF(G)CDM. That is, G cannot start until E and F are completed, C cannot start until G is completed, and M and D follow C.

However, suppose that, contrary to critical path priorities, activity C is performed before G. Path ABCDM still takes forty-eight weeks. Moreover, since activity G is delayed ten weeks while C is being performed, this lengthens path EFGHM to a total of sixty-two weeks. This sequence of dependent activities is AB(C)GHM.

The resource contention problem between activities C and G clearly results in a realistic project duration that is much longer than the original critical path estimate of fifty-two weeks. Using the given activity times, the shortest realistic project duration is sixty-two weeks. The sequence of activities that yields this shortest realistic duration is the critical chain. Note that if the critical path priority of G before C is followed, the project duration is needlessly extended by four weeks to a sixty-six week completion time.

Exploit the Constraint

Once the constraint has been identified, the next step is to develop a plan that fully exploits the constraint. This plan should be one that squeezes the highest possible level of performance from the constraint, and thus, the system as a whole.

Manufacturing Environments

In DBR systems, the derived plan that fully exploits the constraint is called "the drum." This plan sets the production schedule for the entire plant and therefore determines the throughput for the plant. The drum includes a schedule for the constraint resource that maximizes the possible throughput. The prime directive for the plant is that none of the valuable constraint resource time should be wasted. This directive is implemented by enforcing key aspects of shop control such as:

  • The constraint is never starved for work.

  • The constraint should never work on defective materials.

  • The constraint receives top priority on items such as repairs and setups.

In traditional production scheduling systems such as MRP, production lead-times are significantly inflated because they allow for inefficiencies such as queue time and wait time at each operation. In DBR scheduling plans all excess "safety time" for each operation is eliminated. This allows the products to flow through the system as quickly as possible. How the system is protected from variability and disruptions is the topic of Step 3.

Project Environments

The idea of excess safety time in production environments also extends to project environments. Goldratt defines safety time for an individual activity as the difference between the actual time estimate and the expected median completion time. Goldratt further argues that the time estimates for individual activities in a typical project contain a large amount of safety time, often as much as 200 to 300 percent of the median completion time. There are many reasons for the existence of this amount of safety time—multitasking, procrastination, Parkinson's Law, and so forth. The problem is that the use of safety time is an attempt to protect each individual activity and keep each activity "on schedule." The hope is that by keeping each activity on schedule, the project can be completed on schedule. However, despite all of the protection time afforded each individual activity, projects still tend to finish late, over budget, and/or with compromised specifications.

The basic TOC approach, which is very effective in DBR production scheduling applications, is to shift the focus away from trying to achieve local optimization at each activity and focus on the optimization of the whole system. This approach to project environments is applied by stripping all of the safety time from individual activities. If you don't know how much safety time is included in a time estimate, that makes it difficult to strip away the safety time. For such instances, Goldratt has developed a practical rule of thumb—assume that half of the time estimate is safety time.

We apply this rule to the project network shown in Figure 3. The result is a new project network, shown in Figure 4, with revised activity times. The revised critical chain for this network is thirty-one weeks, instead of the previous sixty-two weeks.

click to expand
Figure 4: Project Network with Activity Safety Times Eliminated

If the safety time for an individual activity is stripped away, what is left is the expected median completion time. This clearly implies that each individual activity has only a 50 percent chance of on-time completion. But remember, the objective of a project is not to finish an individual activity on time. The objective is to complete the project on time. How the project completion time is protected is the topic for Step 3, subordinate everything else to the plan.

Subordinate Everything Else to the Plan

The resulting plans that are developed using the constraint theory approach (in either environment) are initially ideal in nature and are not yet realistic. The development of a realistic manufacturing or project schedule is achieved through a series of actions designed to ensure that the impact of variability and disruption is minimized and that the non-constraining elements of the system do not interfere with the expected performance of the system constraint. In both manufacturing and project environments, this is achieved through the establishment of a variety of strategically designed and implemented "buffers."

Manufacturing Environments

If it were not for uncertainty, ideal schedules could be used. However, uncertainty does exist and must not be ignored. But even in the midst of uncertainty, the plant still has the commitment to meet the customer's delivery date. In constraint theory, buffers are established in order to develop a realistic schedule and protect the commitments that have been made to the customer. There are several types of buffers, but the buffers that are most critical to DBR applications are "time buffers." A brief description of the types of buffers utilized in DBR applications follows.

In DBR methodology, time buffers, space buffers, and stock buffers are all used to protect the decisions or actions that are required to meet customer expectations. Stock buffers are traditional and need no further explanation here. Space buffers are simply the planned allotment or dedication of sufficient manufacturing floor space to physically hold the preplanned arrival of a certain number of parts, semifinished components, or materials. Constraint theory time buffers are established to ensure that timely product flow through critical resources is achieved, thereby protecting the ability of the system to meet customer expectations. Parts are planned to arrive at predetermined critical locations a certain amount of time earlier than needed. In one sense, TOC time buffers are a mechanism to facilitate parts arriving at key locations "just-before-their-time." The exact amount of buffer time is based on the level of protection that those managing the system are willing to authorize.

In order to not overly pad the length of time required to complete customer orders, time buffers are only established at critical locations. These significant locations give the time buffers their names—constraint buffer, assembly buffer, and shipping buffer. Figure 5 illustrates the placement of these three categories of buffers in our manufacturing environment.

click to expand
Figure 5: Buffers for Drum-Buffer-Rope System

A constraint buffer is the authorized early arrival of parts to the system constraint. The idea here is to insure that the system constraint is never left "waiting" for parts on which to work. Since the system constraint is what governs the ability to meet customer expectations, any time wasted at the constraint will translate into a lost opportunity to meet customer expectations. The constraint buffer protects the environment from disruptions (uncertainties) that can exist in activities prior to the constraint activity. Any non-productive time at the constraint always translates into lost system throughput. Obviously, such lost time should be kept to a minimum. If no capacity constraint resource exists, then it is not necessary to establish a constraint buffer.

An assembly buffer is the authorized early arrival of parts (or purchased items) that are to be combined with parts that have been previously processed through the constraint operation. This type of buffer is necessary to insure that no constraint-processed parts are stranded and not available to be assembled with other necessary, but not as critical, components on their journey toward the customer. The assembly buffer protects the environment from disruptions (uncertainties) that can exist in operations prior to the combination of non-constraint content parts with parts processed through the constraint. Depending on the network structure, assembly buffers may or may not be required.

A shipping buffer is the authorized early arrival of finished goods at the shipping area of the facility. This buffer is required to guard against uncertainties that can exist in the operations required of the non-constraint resources used subsequent to the constraint resource. A shipping buffer should always be established. In the case where no constraint resource exists, the constraint of the system is said to exist in the market because lack of demand is blocking the system from achieving higher performance. In this case, there is no constraint buffer and the shipping buffer must be sufficient to absorb all process disruptions.

When establishing buffers in DBR scheduling, the question of buffer length usually arises. The established duration of the buffers is based upon the amount of protection that the managers of the system are willing to authorize. There are rules of thumb, but the authors' experience indicates that buffer duration decisions are usually based on achieving a stable system.

Project Environments

Buffers are a key component of the CC approach to developing a realistic project schedule. The CC approach recommends removing all individual safety time and reallocating a portion of the stripped safety time to time buffers. This increases the level of protection against the uncertainties of the project, while also allowing for shorter project completion times than traditional project approaches can achieve.

We now consider the protection that the CC method provides to individual projects through the establishment of project, feeding, resource, and bottleneck buffers. The time blocks used in project and feeding buffers come from using a portion of the safety time that is removed from individual activities. The buffers are strategically located for maximum impact, just like in the DBR scheduling approach. Figure 6 illustrates the placement of project and feeding buffers in our ongoing project network example.

click to expand
Figure 6: Buffers for a Critical Chain System

A project buffer is safety time added to the end of the critical chain in order to protect the completion date of the project. These buffers are similar in function to the DBR shipping buffer and offer protection for the project as a whole.

Stripping safety time from the individual critical chain activities frees up more than sufficient time to establish the project buffer. Each critical chain activity is started and finished as soon as possible. While some critical chain activities will take more than their median times, other critical chain activities will take less. The delays will be at least partially offset by the early completions. Any delays that are not offset by early completions will be absorbed by the project buffer. Stripping safety time from activities usually reduces the critical chain to a fraction of its previous length. Even with adding the project buffer, the expected project dead-line is still less than what it otherwise would have been.

To establish the project buffer, Goldratt suggests adding back half of the safety time that was stripped from the critical chain activities. In our example in Figure 6, the stripped safety time was thirty-one weeks. Thus, we add back half of this stripped time (sixteen weeks) as a project buffer. The realistic expected project duration is now forty-seven weeks. If the entire project buffer is not needed, then the project is completed earlier than scheduled.

Feeding buffers protect the critical chain from delays that occur on non-critical paths. Feeding buffers are inserted at the point where a non-critical feeding path merges with the critical chain. This is logistically implemented by scheduling all non-critical paths to be completed before the corresponding critical chain activity is scheduled to begin. These feeding buffers are similar to the DBR constraint and assembly buffers. They help ensure that non-critical chain activities are completed in a timely manner so as not to delay the start of critical chain activities.

The appropriate location and size of feeding buffers are illustrated in Figure 6. Three feeding buffers are needed to protect the critical chain. Half of the safety time that was stripped from the non-critical path segments that feed into a critical chain activity is added back as a feeding buffer for that segment of activities. It is important to note that the feeding buffers do not add any time to the project duration. Their only purpose is to help insure the timely completion of the critical chain and the project. It should also be noted that if a feeding buffer is insufficient to protect the timely start of a critical chain activity, then the resulting delay will be absorbed by the project buffer.

Resource buffers are used to ensure that resources are available to perform critical chain activities when needed. This means making sure that necessary resources are kept properly informed as the activity start time nears. Whenever a resource contention arises, the critical chain activity receives top priority. Resource buffers represent additional buffer time created at a resource that is scheduled to begin work on a critical chain task. It protects against the case where a resource may not be instantly available to start on a critical chain task. Resource buffers generally do not change the elapsed time on a project. These buffers aid in priority setting and further enhance the reliability of the critical chain schedule.

Bottleneck buffers may be necessary when there is a true constraint resource in the project environment. In a single project environment, this problem can often be handled without much ado. However, in multiple project environments, the resource contention problem becomes more complicated. In such cases, the constraint resource can wreak havoc with attempts to synchronize the use of resources across different projects. If the constraint resource is not carefully managed and protected with buffers, the eventual result will be wasted constraint capacity. This will adversely affect project completion dates and reduce the number of projects that can be delivered.

This constraint resource in a project environment is very similar to the constraint resource in a manufacturing environment. To fully exploit the constraint, it must be carefully scheduled according to the completion dates of the various projects. The bottleneck buffer is designed to ensure that all prerequisite activities are completed before the constraint is scheduled to begin work. The bottleneck buffer does not increase the duration of a project, it is designed to protect it.

Elevate the Constraint

Since the system's constraint is what limits the performance of the entire system, the only way to increase the performance of the system is to increase the performance of the constraint. In many respects, elevation is a focused cost/benefit analysis, where the analysis is focused upon those initiatives that involve the current constraint of the system. In both of our environments, elevating the constraint means undertaking actions that increase the capabilities or the performance level of the constraint.

Manufacturing Environments

In DBR manufacturing systems, depending on the nature of the constraint, elevating the constraint may encompass a large variety of actions. If the constraint is a physical resource, then elevation might include constraint-focused actions such as assigning overtime, providing additional training to increase productivity, hiring additional workers, purchasing additional equipment, or replacing older, slower equipment with faster models. If it is determined that the constraint is insufficient demand (there are no significant resource constraints), then constraint elevation translates into implementing initiatives that generate additional orders. Such initiatives might include improving customer relations, shortening delivery lead-times, or improving product quality.

Project Environments

In project environments, TOC treats the critical chain as the system's constraint. Thus, all actions intended to elevate the constraint must involve the critical chain. If it becomes necessary to shrink project duration, then this provides a clear focus for project managers on where to apply stricter control and resources to "crash" the project. Typical elevation initiatives include hiring new people, moving people from other projects, hiring consultants, purchasing additional equipment or software, or assigning overtime. Critical chain activities are usually different from traditional critical path activities. If you attempt to add resources to enhance non-critical chain activities, you may be wasting those resources.

Go Back to Step One

Sometimes actions taken or independent developments within a system cause the limiting factor of the system to change. When this occurs, we say that the constraint has been broken. This also means that something different is now the constraint. Now the system must be reanalyzed according to the first four focusing steps.

Manufacturing Environments

In DBR systems, managers often proactively implement changes in order to elevate the constraint and increase system performance. Thus, breaking a constraint is usually a sign of improved performance. In DBR systems, the five focusing steps act as a systematic procedure to achieve an ongoing process of improvement, where each iteration through the five steps yields improved performance.

Project Environments

In project environments, breaking a constraint could be a sign of improvement, but it may also signal a problem. If actions taken to elevate the constraint significantly reduce the length of the critical chain, a different chain of activities may become the critical chain. This also reduces the project duration. However, if excessive variability or disruption occur on certain non-critical activities, then a formerly non-critical sequence of activities may become the new de facto critical chain. Whenever feasible, the recommended response is to initiate corrective elevation measures to force the new critical chain to revert to non-critical status. In cases where a new and longer critical chain emerges, project duration has increased. In such cases, the focusing steps should be repeated, even though this requires significant revision of established plans and priorities.




The Frontiers of Project Management Research
The Frontiers of Project Management Research
ISBN: 1880410745
EAN: 2147483647
Year: 2002
Pages: 207

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net