Introduction
Project-based management has long been the business style associated with the construction industry, U.S. defense contractors, large consulting firms, and even Hollywood. Today, project management is spreading to all sectors of work. Accordingly, the membership in the Project Management Institute (PMI®), a professional organization for the project management specialist, quadrupled between 1993 and 1997. PMI membership is growing by some 1,200 members per month and is expected to break the 100,000-member mark by 2002. Clearly, the trend indicates that there will be an increase in the importance and role that projects and their successful management contribute to the strategic direction of the firm. David Cleland, an established project management scholar, has declared that this is the “Age of Project Management” (Cleland, 1990).
At the same time that project management methods have become common practice, the pressures associated with global competition, increased customer focus, shortened manufacturing lead times, and corporate downsizing have created many new challenges for traditional project management. Among these challenges are the issues of sharing resources and prioritizing those resources across a portfolio of concurrently implemented projects. Resolving the conflicts that arise during this resource sharing and prioritization is what really converts the project network into a project schedule.
Historically, the project management literature has made very little connection between the management of manufacturing activities necessary to create a variety of finished goods and the management of activities required to successfully complete a project. Despite the fact that every organization undertakes projects, manufacturing-based organizations and project-based organizations are generally perceived as being dramatically different. In fact, project managers have traditionally viewed the repetitive tasks of manufacturing a tangible item and the typically one-time non-repetitive tasks associated with a project as being so different that a completely different set of tools is required to plan, schedule, and control the activities. Manufacturing activities are best coordinated and controlled using one of the many best practices of the day in combination with some variation of a Material Requirements Planning (MRP) system, Manufacturing Resource Planning (MRP II) system, or Enterprise Resource Planning (ERP) system. But conventional wisdom suggests that project activities are best coordinated and controlled using variations of the Critical Path Method (CPM) or Program Review and Evaluation Technique (PERT).
However, upon closer examination, it becomes obvious that both manufacturing-based and project-based organizations share a common set of objectives. Both must meet the expectations of their clients, with on-time delivery, while adhering to budget limitations necessary to achieve levels of profitability acceptable to their stakeholders.
It is not unreasonable to believe that a general body of knowledge already exists that could be utilized to achieve the common objectives of both organizational types. The authors of this paper suggest that such knowledge does, in fact, exist. The body of knowledge is broadly referred to as Theory of Constraints (TOC) or Constraint Management (CM). This approach, developed by Dr. Eli Goldratt, was first described in his now classic book, The Goal (Goldratt, 1984, 1986, 1992). In this business novel, Dr. Goldratt provides the basic decision framework to solve numerous business problems. Those who are familiar with the book will remember the basic framework as the five focusing steps. We now describe in detail how these five steps provide the framework for coordinating and controlling activities in both manufacturing and project environments.
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. Uncertainty is not ignored completely, only initially when developing a scheduling solution using constraint theory methods. 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 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 exists 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 Drum-Buffer-Rope (DBR) and the Critical Chain (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, etc.) 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.
Exhibit 1 illustrates a basic product flow diagram for a simple manufactured product. The exhibit shows a process that requires 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 exhibit as operation M. The exhibit also indicates that operations C and G are performed by the constraint resource.
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 Exhibits 2 and 3. Exhibit 2 shows that the network consists of three paths. The exhibit also indicates that path EFGHM is the critical path, taking 52 weeks to complete.
Exhibit 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 52 weeks. However, the start of activity C will be delayed by 18 weeks while G is being completed. This delays path ABCDM so that it takes 66 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.
Exhibit 1. Product Flow Diagram for a Manufacturing Environment
Exhibit 2. Critical Path for a Project Network
However, suppose that, contrary to critical path priorities, activity C is performed before G. Path ABCDM still takes 48 weeks. Moreover, since activity G is delayed 10 weeks while C is being performed, this lengthens path EFGHM to a total of 62 weeks. This sequence of dependent activities is AB(C)GHM.
Exhibit 3. Critical Chain for the Project Network in Exhibit 2
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 52 weeks. Using the given activity times, the shortest realistic project duration is 62 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 66 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% of the median completion time. There are many reasons for the existence of this amount of safety time—multitasking, procrastination, Parkinson's Law, etc. 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 Exhibit 3. The result is a new project network, shown in Exhibit 4, with revised activity times. The revised critical chain for this network is 31 weeks, instead of the previous 62 weeks.
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% 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 disruptions are 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, semi-finished components, or material. Constraint theory time buffers are established to insure 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 some 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. Exhibit 5 illustrates the placement of these three categories of buffers in our manufacturing environment.
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 nonproductive 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.
Exhibit 4. Project Network With Activity Safety Times Estimated
Exhibit 5. Buffers for Drum-Buffer-Rope System
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.
Exhibit 6. Buffers for a Critical Chain System
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, there will be no constraint buffer. Furthermore, 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, the shipping buffer effectively acts as both the constraint buffer and the shipping buffer.
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 Critical Chain 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. Exhibit 6 illustrates the placement of project and feeding buffers in our ongoing project network example.
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 deadline 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 Exhibit 6, the stripped safety time was 31 weeks. Thus, we add back half of this stripped time (16 weeks) as a project buffer. The realistic expected project duration is now 47 weeks. If all of the 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 Exhibit 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 re-analyzed 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 disruptions 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.
Suggestions for Resolving Conflicts
We have seen how the basic decision framework provided by TOC can be applied to scheduling practices in both manufacturing and project environments. Both constraint theory applications share the common elements of identifying the constraint, eliminating excess safety time, establishing protection through the creation of appropriate time buffers, and the resulting coordination of all tasks.
A complicating issue in most product and project environment has to do with the conflict that arises when managers are faced with the necessity to sequence multiple products or multiple projects. The conflict is between starting new products or projects in the midst of trying to make sure that existing products or projects flow through the system. The existing products or projects must flow through without interference from the new products or projects entering the system. Otherwise, the new orders or projects may cause the existing items in the system to become late. We can recommend three strategies for managing the conflicts that exist in both manufacturing and project environments.
(1) Conflicts may be greatly reduced by “metering,” or allowing into the system only those orders or projects that the organization has the capacity to fulfill. However, we realize it is difficult to turn down new orders or reject seemingly worthwhile new projects.
(2) Resource contention problems may be significantly reduced by staggering individual orders or projects according to their relative priority and according to the available capacity of the firm. However, in dynamic environments, even the successful resolution of resource contention may be short-lived.
(3) To promote stability and establish proper priorities, select what appears to be the most heavily loaded resources and declare that resource to be the bottleneck or constraint resource for the organization. Then develop a schedule for that resource based on the strategic priorities of the organization. If necessary, follow this approach for a second constrained resource. Release new orders or new projects only according to the available capacity of these constraint resources.
Project managers might employ one or more of the above suggestions to achieve higher performance and better control of their environment.
