A Guide to Implementing the Theory of
Constraints (TOC) |
|||||
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. 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. 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. This Webpage Copyright © 2008 - 2009 by Dr K. J.
Youngman |