Theory of Constraints Projects

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

Multi-Project Drums

Projects, Projects, Projects ...

It has taken a very long time to be in the position to write webpages on projects. There were a number of good reasons for this. Most of those reasons no longer exist. However, one in particular did remain until quite recently. It concerned my mental blockage over the nature of the buffer in production and the nature of the buffer in projects. You see, I thought that they were different beasts, and as often as I tried to reconcile their differences, I would fail. The reason that I would fail is that there is no difference what-so-ever. In fact, I can hear in my mind the general description of their commonality from a number of authoritative people. But it didn’t get in!

Another good reason for not writing anything about projects sooner was that I wanted to present the graphics in a way that was different to the “standard” Gantt charts or PERT charts. In fact, I wanted to continue to use the process diagram that has served us so well in our discussion of the production operations solution; drum-buffer-rope, and the distribution and supply chain solution; replenishment. After all, a project is just a different type of logistical enterprise. The same diagram should stand for all. And in fact it can and does, but in the end I decided to use something between a PERT chart and a Gantt chart which you will also find in other approaches to explaining projects in Theory of Constraints. Such a diagram will also allow us to quickly flick from production operations to project operations and back again and therefore examine the similarities and differences between the two.

Why would anyone let decisions about how to draw something hold the process up? Well, honestly I don’t know – at least not explicitly. I do know, however, that in a former life – one where the science of geology was important to me (actually it still is), rather than the science of why people make things difficult for themselves – we tended to draw things first, and explain them with text later. When you have spatial and temporal differences often you have to draw them to understand them yourself, and certainly in order to “explain” them to anyone else. In Theory of Constraints we are often dealing with solutions that are just plain outside the experience of most people, or at least their perceptions of what ought to work. Writing text and allowing people to read it is rather like just saying something and allowing people to hear it; you can’t tell whether the information was understood as you wanted it to be understood. Especially when it is something as passive as these webpages and there is no feedback. Therefore it is better to both draw and to write, so that we can both see the diagrams and read the text and get the information from two distinct channels.

Before I could start I needed to be able to have a mental picture of the broad sequence of diagrams that I think are necessary to explain the problem to myself. Sometimes, when I don’t know the diagrams well, I have to rough them out on paper. More often than not, they develop as I go. Most often, in fact, the last diagram defines the space and size that I needed to know for the first, and I redraw the whole sequence. However, that is my problem, not yours.

Something that is “our” problem, however, is buried a few paragraphs back. I asserted that a project is just a different type of logistical enterprise, so what exactly is a project?

Let’s see.

A Definition Of Sorts

What is it that makes project operations different from production operations?

Is it that a project has a beginning and an end, even if the end might not be scheduled with any great precision? Well, an item in a production process also has a beginning and an end. At some exact moment raw material is released into the process and later at some exact moment the completed item is shipped or sent to finished goods. An item in a production process has a beginning and an end. The process continues to exist.

Is it then that the project organization and infrastructure doesn’t exist after the completion of a project? Well this is hardly true. Many organizations and the needed infrastructure exist as an overarching “process” through which different projects pass. Each project may be discrete but the overall components continue to exist. Consider a joint venture to build a tunnel for instance. At the completion of the project the joint venture dissolves, but the tunneling company goes away to bore another tunnel and the civil engineering company goes away to maybe a completely different project, but they still exist.

Is it then that a project is unique but an item in a production process isn’t? Hardly. There are many organizations which are project oriented and yet each project follows exactly the same template, you just change the detail and follow the same dynamics every time. Conversely, there are many repetitive production processes where individual items are customized. Even though each item is similar, few if any, are exactly the same.

Well, if there are project organizations that do change the detail, what effect does this have? The answer, to my mind, is that each time the detail is changed an element of uncertainty creeps in. Uncertainty, however, is nothing new, production processes are full of it. In any non-drum-buffer-rope process uncertainty is one of the things that will be present in abundance.

The key point, however, is where that uncertainty lies. In a production process the uncertainty doesn’t lie in the task, it lies in the waiting. We are very good at taking the uncertainty out of the process task, essentially removing variability – we call this quality. And even if the variability remained, the actual task time in a process is so small that it doesn’t have much effect. Most of the time is spent in waiting between tasks. The actual touch time is quite small – miniscule in fact.

If the touch time in a production process is very small, then in contrast the touch time in a project is very large indeed. Combine the high touch time with the degree of uncertainty that goes with the task and suddenly we have quite a challenge. Here the variability is in the effort, in projects the effort is unknown because we haven’t done it before, or we haven’t done in this particular way with these particular things before.

A project therefore seems to be defined by both a high touch time and large variability – or maybe you would prefer to call this uncertainty. We will look at the various components that make up this uncertainty on the next page.

Of course if there is variability or uncertainty in projects then we will try to protect the tasks in the project by adding some safety. However, unlike production processes, the safety isn’t explicit as queuing time. Rather it is implicit and embedded within the individual task estimates themselves.

So maybe a project is better defined by a high touch time, large variability or uncertainty, and significant amounts of embedded safety.

Outline

Over the next few pages we are going to explore the Theory of Constraints logistical approach to project operations. Because the concept of explicit safety is foreign to the project management environment, we will spend a whole page on just that – project buffers. With this concept safely under our belts we can then continue on to examine the specific application – Critical Chain Project Management. Following on from that there is a page on some of the implementation details that we need to know, and then short note on “drums” in constrained multi-project environments.