A Combined Approach to Manufacturing and Project Management

Introduction

In this paper by Eli Schragenheim and Daniel Walsh, the differences between manufacturing scheduling and multi-project scheduling arediscussed. The authors point out the critical need to be able to distinguish between the two environments, and to schedule them using the appropriate algorithms.

They also discuss the frequent reality of hybrid environments-operations that have aspects of both projects and manufacturing. These hybrid environments require an integrated scheduling scenario. Mr. Schragenheim and Mr. Walsh are recognized as two of the world's foremost TOC experts.

David Updegrove

A Combined Approach to Manufacturing and Project Management

By Elyakim M. Schragenheim and Daniel P. Walsh

Current Situation

Planning and scheduling of projects are based on the basic approach that developed from the PERT/CPM methodology. Planning and scheduling of manufacturing are based mainly on the MRP way with some alterations.

The two planning methodologies are certainly different, even though the basic description of sequence of operations/tasks required is similar. In both methods we find a clear sequence of operations when one's output is the next operation's input. Both have integration/assembly operation where several inputs are converted to just one output. The concept of disassembly is more common in projects than in MRP, but is not totally unknown in manufacturing. In fact it is very common in the remanufacturing, repair and overhaul environment.

Yet, the differences are very substantial. While PERT/CPM is centered on the notion of critical path - the longest chain of sequential operations that encompass the whole project, MRP and the other APS systems ignore it totally. Another PERT/CPM specific feature is the requirement for minimum and most likely maximum task time estimation. But, experience suggests this is rarely done when estimating MRP times and certainly is not part of the MRP methodology. MRP emphasizes the role of material management, while PERT/CPM does not. MRP looks at the whole portfolio of orders to be completed in a specific time frame. While the traditional PERT/CPM was developed primarily for managing single projects rather than a portfolio of multi-projects.

Certainly there is much to be admired and benefits derived from both of these methods. However, users complain about the fragileness of the planning and how Murphy (or call it uncertainty, risk factors or unexpected events) mess things up.

Were these differences in methodologies derived from the basic difference between manufacturing and multi-project environment? A better understanding of how the difference in environments lends itself to different planning methodologies can yield two benefits:
1. Better overall planning methodology; meaning planning that is fairly robust and still draws the most from the system when necessary. 2. Better understanding when to use a certain methodology. While R&D departments seem naturally project oriented and the manufacturer of consumer goods certainly does not think in terms of projects, there are some cases where the characteristics are not that simple to pinpoint. Manufacturing of large high tech systems is a case in point. Do they manufacture "projects" or do they manufacture "products"? Which planning method is superior in such a case?

Note that if one unified planning method, that fits both multi-project and manufacturing, is found then the second benefit is trivial. However, if we conclude there is a derivative cause and need for different planning methodologies then there is tremendous value and benefit in pinpointing which methodology best fits our environment.

And, if we need to have two methodologies, then another question arises. Are there hybrid environments? Do certain products need the output of both multi-project planning AND manufacturing planning?

The TOC Angle

TOC challenges both planning methodologies. The TOC manufacturing planning method is called Drum-buffer-Rope (DBR) and is distinct from both MRP and APS methodologies.

The DBR method was developed even before the current concepts of TOC. Yet, it absolutely fits the TOC thinking. Then a control mechanism, called Buffer Management (BM), was developed to complement the planning; thus creating a distinction between planning and execution.

The TOC methodology for multi-project planning and control is a relatively later development. In the very initial stages of thinking upon the problem it was realized that DBR does not truly fit as a planning methodology for project management. Hence, from the TOC perspective there is a critical distinction between planning manufacturing and planning multi-projects. This gives us an opportunity to better understand the difference and what makes it critical.

The TOC way for planning multi-projects uses some of the TOC terminology used in DBR, notably the concept of the Drum and the Buffer. But, the actual definition of those terms when used in the multi-project environment is not the same, even though in the more abstract perspective it is fully justified to use the same terms.

We are not going to go into defining DBR and multi-project the TOC way. We are going to suggest that the differences between the multi-project environment and manufacturing demand different types of planning. Once we understand the cause for the different type of required planning, we can draw conclusions on how do define the line between projects and manufacturing.

Then, we are going to look for those environments where the output is a real hybrid of manufacturing operations within projects and then a combination of the planning tools will be evaluated.

The Critical Distinction between Projects and Manufacturing

Using the DBR methodology as was first developed, let's examine what might happen if we apply it to typical multi-project environment, like in an R&D department.

First we need to identify whether we have an active capacity-constraint resource (CCR). In the following example we have two projects, identical in their routing description, but the end product is different.

Suppose that overall the blue resource is the CCR. Typically DBR ignores the run time of the non-constraint resources.

Figure 1: The DBR representation of each order

We are not going to specify the whole CCR scheduling process, but a typical process could yield the following CCR schedule:

Figure 2: The CCR schedule

What we see is that the first CCR operation for order 1, the first upper leg CCR operation, which takes 10 days, is scheduled to start on day 30. This allows starting the upper leg at day zero to maintain a whole CCR buffer to make sure the CCR would start on time. Next is the same operation, but this time for the second order.

The DBR rules require that between the 10-days operation and the 15-days operation, which is fed by it should be at least 15 days - half of the CCR buffer. This requirement is met by this schedule.

Is this schedule satisfactory? It all depends on the length of the buffers. In order to see clearly the problem with this schedule, let's show the same order, presented as projects.

Figure 3: Presenting the example as two projects with the same structure.

In the DBR representation the data concerning the non-constraints was ignored. This is not the case with projects. The TOC approach to projects directs us to look at resolving the resource contention of each resource and to signal the critical chain. Then the start time for any project is determined by the drum. Figure 4 is a TOC schedule for the same two orders, now presented as projects. We assume the run times given are 50% estimations for the actual length of each task.

Figure 4: The TOC Multi-Project schedule

The critical chain (critical path that considers resource contention) of each project is signaled by the striped lines within the tasks.

The most striking difference is that non-constraint tasks are scheduled. We can also see how critical it is to determine the actual sequence along the critical chain. Just suppose that the starting resource would have started with the first task of row B, instead of Row A. This would probably lead to significant delay in the whole project.

Another striking difference is that the "blue" resource is "wasted". The three operations for that resource are not pulled together. The 10-days operation is not part of the critical chain and there is 5 days difference until the 5-days operation starts. It is doubtful that this hole can be used for something else. That hole is not given to the second project in order to keep the second one tightly together and reduce overall resource contention. In addition, there is a small "capacity buffer" between the utilization of the drum resource between projects.

So, which way planning is "right"?

In this particular case it is the multi-project planning. It shows that you cannot ignore the internal sequence for non-constraints, because it might cause significant delays. The 30 days buffers would not hold in this case. Enlarging the buffers means that we cannot supply the two orders on time. The multi-project planning shows both projects can be on time and they are well protected.

Does it mean that the multi-project planning is always preferable? Shouldn't we use the multi-project approach to schedule the normal manufacturing shop floor?

In order to demonstrate when such a usage would go astray, imagine the same orders with the same structure, but instead of days the run times are stated in minutes. Of course, we won't have only two orders at the same time. We would have hundreds. The lead-time would be quoted not in minutes, but in days. The shipping buffer might be 4 days and the CCR buffer might be 2 days. What would be the impact of starting with the first operation on row B instead of A? Would it cause a delay of 20 minutes in the delivery? As a matter of fact, the actual lead time of each order, would be in days - even though the net processing time along its "critical chain" is less than an hour. How come? When you have to face hundreds of orders, the efforts are directed toward exploiting the capacity of the CCR. Hence, we like to take advantage of any "hole" in the schedule for the CCR and rely on the excess capacity of the non-constraints, plus the time buffers, to protect the CCR schedule and the due-dates schedule.

Hence, the critical difference between an environment that should be planned according to multi-projects and an environment that should be planned according to DBR is in the average run time of a task. When an average task takes minutes - this is definitely manufacturing. When an average run time of a task takes weeks - it is definitely multi- projects. Certainly there are some cases in the "gray area". We tend to believe that few hours for an average task still belongs to manufacturing, while average tasks that are quoted in days are projects. There is more to learn here in order to better define the criterion for environments in the gray area.

This difference lends itself to a different focus. In projects it is always critical to reduce the overall lead-time of each project. Hence, there is an effort to achieve continuity of work along the critical chain: start the next task as soon as the previous finishes. This is not always what actually happens, but it is always what is desired.

Of course, in manufacturing there is also a desire to reduce lead-times, but not for each individual order in isolation and not at the expense of significantly reducing the output quantity. Hence, when one follows one specific order it is evident the work waits most of the time for the resource to be available to process the order. In MRP terminology this is called queue time and this is the dominant factor in the manufacturing lead-times. Hence, reducing the queue time has a tremendous impact on the manufacturing lead-time, while focusing on the critical chain of an order produces only negligible results.

When we evaluate whether an environment is more multi-projects or manufacturing we suggest looking at the ratio between the net processing time along the longest chain of an order and the lead-time. If the ratio is above 1/3 - this is a multi-project environment. Otherwise, it is closer to the manufacturing environment.

The Role of Inventory Management

For whatever reason conventional project management planning does not address inventory management at all. It is true that many projects are not significantly impacted nor have a need for common materials. But, other environments that fully conform to the above measurement are in constant need for materials. Take, for instance, the building of a ship. A shipyard should generally speaking be treated as multi-project environment. But, undoubtedly it is very dependent on material availability and must manage significant inventories.

The current practice is to use two different sets of software. One is an ERP system that handles the inventory and financial aspects of managing the projects. Then a project management program is used, usually in isolation from the ERP system, to manage the schedule and control of the projects.

This is an undesirable situation. First of all, the changes made in the project schedule are not communicated effectively into the MRP module. Clearly there is a critical need for integrating the multi project planning and control within the ERP; where schedules, inventory and budgeting requirements must be captured. One of the difficulties is that the MRP logic is manufacturing oriented. The concept of bill-of-materials where each level is given its own lead-time results in the accumulation of loading according to work centers. The queue time concept is embedded with such a philosophy, which comes from the manufacturing and not from the multi-project paradigm.

We submit that a "marriage" between DBR and multi-project planning the TOC way is feasible and can generate a powerful link between the multi-project discipline and the broader aspects of the enterprise. Moreover, we would like to demonstrate that within the scope of multi-project management there is a real need to integrate the two different methods of planning.

Projects with Manufacturing Tasks

Consider the manufacturing of a large system such as, a ship, an aircraft or a complete communication system. Within the basic structure of the tasks we'll find tasks like: engineering design of various parts, integration of large number of parts (which may be large subsystems in themselves) and final testing are typical project tasks. They are classified as project tasks because they use specific resources for significant amounts of time. If these resources are tied up during execution working on a task that is not the highest priority task and this delays working a higher priority task, it will result in a major delay in a project. The assignment of resources is critical in projects, causing the phenomenon of multi-tasking, which is not common at all in manufacturing where such delays are not critical (unless the same mistake of ignoring something is repeated many times).

However, the same project might include tasks that seem to be manufacturing orders, like producing a number of components that are needed in several places within the ship, or even checking the quality of subsystems purchased from a contractor. These tasks are usually done at shops. A shop is a mini plant doing a variety of jobs for all projects and sometimes for non project demand that is generated elsewhere. The manufacturing of a component is normally accomplished by several work centers that do many different types of components. The actual "touch time" is short, but producing a set of components might take several weeks. Such a task, within the overall structure of a project, is a manufacturing task.

We strongly suggest merging the TOC multi-project and the DBR methodology; by treating the high level planning as multi-projects and planning the manufacturing tasks done by shops according to DBR. We further claim that both modules and the linkages between them should be part of the ERP system, thus truly integrating the resource planning of both projects and manufacturing with inventory management.

The layout of the large system should be conceived as a project. We suggest that the links between tasks within projects would be confined to finish-to-start links. Thus, the project structure can be converted tothe structure of a bill-of-material, where every task is a part within the bill.

The resources are clearly divided between project-oriented resources and manufacturing resources, whose details exist only within the manufacturing planning.

The multi-project TOC/critical chain should clearly note what tasks are project tasks, with the associated resources and what tasks are manufacturing tasks, defining the manufacturing shop.

Every manufacturing task should contain the bill-of-manufacturing id for the part. This should contain the default buffers for that part. The shipping buffer plus the CCR buffer should be used as the default duration for the task.

The shops are scheduled using the DBR methodology. If, because of a heavy load on the shop's CCR, some orders have to be delayed, then the effected project buffer penetration will indicate which orders must be expedited.

A manufacturing task within the framework of a project might have one or more inputs coming from other project tasks. The DBR algorithm treats those inputs as regular materials, meaning given a "don't release before" date. A change to the DBR should enable it to treat the input dates also as "not before" dates and, when needed, to push forward a CCR instruction. We assume that the vast majority of the materials are consumed by the manufacturing tasks and hence are managed by the DBR plan. The following shows a high level notional project plan and an example of how one manufacturing task is translated into a bill-of-manufacturing that is treated as an order to the DBR planning of the specific shop.

Figure 5: A DBR scheduled component feeding into a critical chain task

In the Figure 5 critical chain project many thousands of required manufactured components are scheduled using DBR. In other words the components are manufactured and subordinated to the needs of the critical chain schedule. During the Assembly Phase the components must arrive at the various Assembly tasks which are managed by the critical chain in the proper sequence. If the components are manufactured out of sequence they will turn the assembly area into a bottleneck. The component order is released to the floor a shipping buffer ahead of when it is needed by the Assembly task in the project. The component's "customer" is the project task, in this case the Assembly task.

Combined Buffer Management

Within the project the tasks are 50% estimation of the processing times. Within the DBR methodology buffers are defined to allow for more than 90% confidence of delivery on time.

Hence, the regular planning mechanisms might cause double-protection on the manufacturing tasks. One way, like the case in the above example when the manufacturing task is non-critical chain task that directly integrates into a critical chain task, is to eliminate the usual feeding buffer. That means relying on the manufacturing shipping buffer to be good enough protection. A more common way of addressing this is by reducing the shipping buffer for orders that are generated from projects. But, that is not that important.

The more significant point is preventing unnecessary expediting efforts at the manufacturing shop. Buffer management identifies situations where the planned buffer is almost exhausted. At that point extreme measures are taken so the order will be shipped on time. When the demand is internal we can check whether the urgency is really true and needed. We should try to avoid the situation where a manufactured part is expedited in order to prevent a chain in the project from consuming some feeding buffer.

Hence, a linkage between the two systems of buffer management should be created. Expediting for the orders generated from projects should be done only when there are two requirements for expediting - one from the DBR system itself and the other from the project's buffer management control.

Conclusions

Clarifying the basic assumptions and rules behind the planning method is critical for developing the correct relationship between multi-project environment and manufacturing. The critical differences we have found have very little to do with some classical definition as "every project is unique while manufacturing is mainly repetitive". Another common cited difference is that projects usually work on just one unit of output, but even this has very little to do with the planning algorithm. It also has little to do with the fact that the main resources planned in projects are the human resources, while in manufacturing the main resources are machines.

The critical difference lies in the time frame where a resource has to be dedicated to a particular task/operation. In projects, most tasks take days, weeks and months, while in manufacturing we usually speak in minutes or hours. This difference causes a different focus for the planning algorithm. A quick measure to assess whether a certain environment is closer to a multi-project environment than to manufacturing is seeing whether the net processing time across the critical chain/critical path is pretty close to the actual lead-time.

DBR planning is capable of exploiting the most heavily loaded resources capacity, maintaining good control on the lead-time, making it as short as practical. We believe this is a more sound approach to manufacturing planning.

Once the difference between multi-project and DBR becomes clear, the next question concerns the hybrid environments, where typical projects have typical manufacturing tasks embedded within the projects. We suggest planning the manufacturing tasks using DBR, have the project planning generating the required due-dates and inputs and the buffer management of the two are closely linked. With such an approach, the high level planning is the TOC multi-project way and the manufacturing shops are receiving their planning from a more appropriate planning mechanism.