Theory of Constraints Projects Project Buffers

A Guide to Implementing the Theory of Constraints (TOC)
PowerPoints	Preface	Introduction	Contents	Next Step	Advanced

Multi-Project Drums

Comparing Safety In Production & Projects

There are two groups of people who are likely to use these pages on projects; those with prior knowledge of production operations (manufacturing) and those with pure project backgrounds. For this reason I want to compare and contrast between production operations and project operations. The similarities are much greater than the differences. I want to do this for two reasons;

1. Provide a bridge for people with production operation experience in order to enter into the project domain.

2. Show people with project operation experience that the challenges that they face are not that different from those experienced in production environments.

So I ask for your indulgence if you already feel slighted that “your” area of expertise is apparently no more difficult than “their” area of expertise. You see, we are basically all in the same boat – and we are all at sea as well. Industrialization is new. We only have to check whether our parents’ generation ran projects or production operations as we do, and if they did, then check out our grand-parents generation. The scale and scope of operations today is vastly different from that of just one or two generations ago. For instance, just one generation ago we didn’t have computers to make mistakes quite as quickly as we are able to today.

In fact, computers are now so ubiquitous that we can discuss operations in terms of the software that drives them, or at least the generic approaches. For production operations the first software was material requirements planning (mrp or small mrp – referring to the use of lower case letters). Material requirements planning allowed the building of bills of material (BOMs) for a process; a list of all the bits and pieces and maybe the places where, and the time when, they were required. It wasn’t long before this was beefed up to materials resources planning (MRP or MRP II) with the addition of capacity scheduling of each step in the routing that had been used to generate the bill of materials. More recently this has been beefed up once again to enterprise resources planning (ERP) where schedules are wired across functions as well as within functions. Sales and marketing now know what production is doing and vice versa (well it sounds good doesn’t it?)

The project operations equivalent of the mrp, MRP II, ERP, alphabet soup is Critical Path Method, (CPM for short). Critical Path Method tends to be associated with the Gantt charts that are used to graphically present the relationships between tasks in a project, but it is generated from an approach called program evaluation and review technique (or PERT for short). In fact, as we will soon see, program evaluation and review technique can be equally applied to production operations as well as to projects. Indeed, maybe PERT is responsible for the two short comings of both MRP and CPM. Both approaches assume, even today, that there is more capacity at each step in a production process, or task of a project, than is actually required. Colloquially, we tend to call this “infinite capacity” although we only mean that there is “more than enough.” Before the advent of computers when PERT was a manual exercise, this simplification made the impossible possible.

Also, both MRP and CPM assume that safety is localized throughout the respective operations. In production operations, safety is localized in the queuing of product (work-in-process). Each queue represents a safety buffer that allows late work to catch up to its schedule through the rearrangement of items or “jobs” in the queue. Historically, these types of scheduling approaches originated in so-called job shop environments – places where machinery was likely to be grouped according to function, rather than the flow-shops that are so much more common in all but the smallest of facilities today. In Critical Path Method the safety is localized not in the queue, but within each and every task in the project.

Assumptions of infinite capacity and the localization of safety throughout the operation are the two aspects that cause so much trouble to modern operations. We won’t address the issues of infinite capacity assumptions until the next page on Critical Chain Project Management, because this is an important issue of itself and is to me the distinction between Critical Chain Project Management and Critical Path Method. On this page we will address the issue of localized safety in each step or each task. Essentially we are going to move from safety that is localized, specific, and everywhere, to safety that is general, aggregate, and located in just a few critical places.

Having safety “embedded” in each step of a production process or each task of a project ought, at first pass, seem to be an effective solution. After all you can size each individual allocation as required – regardless of whether it is explicit within a production process queue, or implicit within a project task. However, a number of operational and psychological factors contrive against us. The operational factors are the dependent nature of serial operations and the inherent variability that occurs within each operation. The psychological factors are varied, and probably more important for project-based operations than production-based operations. We will deal with the psychological factors as we come to them.

In order to develop the argument for the aggregation and placement of buffers in project management, I am going to use a PERT diagram for both a production process and a project. In order to do that we must make use of the realization that a project is an “A” plant tipped on its side.

Let’s look at this in more detail.

A Project Is An “A” Plant Tipped On Its Side

A project is an “A” plant tipped on its side (1). This is the “thing” that finally allowed me to see the relationship between production operations and project operations and their buffers or safety. But what is an “A” plant you are asking? Theory of Constraints sees 4 generic flows in production operations, they are; “V” plants or divergent plants (divergent from the bottom of the “v” to the top), “A” plants or convergent plants (convergent from the bottom of the “a” to the top), “I” plants or linear plants, and “T” plants – a plant with a linear stem and an explosion of choices at the top (assembly). Each type of plant is typical of particular operations. “A” plants are typical of situations where a number of different components from different raw materials come together to form a final assembly.

Let’s draw a simple, a very simple, “A” plant on its side to see how it would look.

We have 6 steps in our simple process. Step 1 must be done before step 2, and step 2 must be done before step 3. Step 4 must be done before step 5, and steps 3 and 5 together must be done before the final step, step 6. Two arms; steps 1-3 and steps 4-5 converge on step 6.

This type of logic diagram is common in Theory of Constraints. The logic might coincide with the physical layout of the plant; more often than not, it won’t. For an example of a more complex “A” plant logic diagram and its corresponding physical layout, have a look at the diagrams for the P&Q Question.

If we were to draw a very simple project, then apart from some different names, it would look exactly the same, lets see.

We have 6 tasks in our simple project. Task 1 must be done before task 2, and task 2 must be done before task 3. Task 4 must be done before task 5, and tasks 3 and 5 together must be done before the final task, task 6. Two arms; tasks 1-3 and tasks 4-5 converge on task 6.

The logic diagram for production operations and project operations are exactly the same, save for different labels. Let’s put the two diagrams side-by-side.

Of course they are the same, but from a project perspective something is wrong. We really expect to see some proportionality between the tasks and the time taken, and moreover, we expect to see each task abut onto the next. However, such a notion is frightening to production people because the time taken by each step is miniscule in the overall scheme of things.

Let’s draw each respective diagram so that the steps and tasks are somewhat proportional to the time taken.

That looks better from a project perspective. However, from a production perspective the time shown, let’s call it the touch time, is still way too large. The touch time as shown is something larger than 10% of the previous size for each task. Reality is that it is more like 1-2% or maybe 5% at the absolute outmost. Really just a sliver of a line. You see, most things in most production operations spend an awful lot of time just waiting in queues.

Let’s have a look at this waiting in queues.

Waiting, waiting, waiting; the waiting in production operations is explicit. It is in the queues that are planned into the process from the very beginning. The actual touch time of material in the process is very small indeed.

This raises a question; there isn’t any waiting in projects – right? Well, not explicitly, and it isn’t called waiting, it is called safety – “things” in production might wait but people in projects don’t like to be seen waiting, so we have to call it safety.

Let’s have a look.