A Guide to Implementing the Theory of
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
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
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?)
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
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.
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.
“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
Let’s look at
this in more detail.
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.
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.
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