A Guide to Implementing the Theory of
This page contains
some of the “pointers” needed to turn the knowledge in the preceding pages on
Critical Chain Project Management into something that will produce both
action and significant results for a particular case. As you know, people write books on just this
aspect and it is not the intent here to provide yet another. But there are a number of small things,
often very small things, that people who are not so familiar with Theory of
Constraints might find value in.
Things that we might otherwise do that we shouldn’t do, and things
that we might otherwise not do that we should do. It is one of those interesting things in
life to see a “new” approach such as critical chain applied in an “old”
environment with many of the old assumptions and reactions – many of which
are so automatic that we don’t even think about them – and then to hear that
the new approach isn’t working. It’s
not the new approach that is at fault, it is the old thinking of the old
environment. We need to watch for this
Well, I don’t
know about the good, but I’ve seen a bit of the bad and the just plain
ugly. There are many companies who see
themselves as generalized producers rather than “project” companies. They make things with long touch times, for
example tangible manufacturing or near-intangible software, and yet have
little explicit project management of their operation. Companies that build one-offs, either to a
standard design or customized, tend to use the “last one like that” to estimate
effort in “the next one” and set start and finish dates around that. They then launch the new project into the
system without due regard to the loading on the system because “the customer
is waiting and every day is a day lost to him.” And so it goes.
Where there is
some logistical control, oddly, it seems to be as a material resource
planning system (MRP). I say oddly,
because such systems depend upon queuing for their functionality and as we
know there are no explicit queues in projects. Oddly too, because such companies may see
the age of their MRP system as the cause of their problems and embark on
expensive and time consuming upgrades to let them know more quickly how fast
they are losing money. They have
addressed an effect rather than the underlying cause. Maybe people use MRP systems because they do know how damn
difficult it is to organize anything around one of the Critical Path Method
(CPM) software approaches, a difficulty brought about by the close coupled
dependencies (tasks) and localized safety.
with Critical Chain Project Management is a fundamental step forward. There is a fine example of this from the
United States Marine Corps that you can download (1).
We need to
move from the bad to the good. In
order to do so, we must do things that currently we do not do. We now know the logistical direction of the
solution and most of the detail – Critical Chain. Here, let’s examine a few more of the
important implementation details, some of the things that other people might
forget to tell us about.
manufacturing/service projects that are to some extent repetitive – the same
or similar type of thing is produced each time – have sort of “evolved.” Often no one has ever
sat down and asked the critical question about what needs to be done and
when, and which parts must be done
in sequence and which parts can be done
in parallel. People are far more
likely to do this for “unique” projects or very large projects, but when we
have a significant number of apparently simple and mundane or repetitive
projects we often don’t do it at all.
Of course if we sit down and redo this plan from scratch, then once it
is done, we may not need to revisit it again; we have a template, but it will
be a vastly improved template compared to the one that we previously carried
around in our heads.
We need to sit
down and take a long hard look at devising the minimal PERT chart that we
need to implement the project.
Something like this.
The result is, as we have said, an “A” plant tipped on its side. Curiously, this is also Goldratt’s Thinking
Process logic diagram for pre-requisite trees tipped on its side as
well. A pre-requisite tree deals with
necessity-based logic – a tree with a trunk and main branches but not with
the sufficiency of all the sub branches and leaves, or a stick figure rather
than something that is fully fleshed out (2).
A discussion of these logical tools can be found in the section called
pre-requisite tree approach it is possible to build the logic needed for the
PERT diagram. If we do so, then the
following will occur;
Tasks that are
not true predecessors will be resolved out of the critical chain into
parallel feeding chains where they belong.
The overall length of the Critical Chain is therefore reduced before
we even start. This is already a
significant competitive advantage.
into the trap of providing sufficiency, that is, breaking the basic tasks
down into further detail. The people
who are directly involved know what is required.
A common enough problem once a proper project plan
has been produced is to try and resource it fully. Once again, we don’t need to do this. We only need to resource the tasks that we have to. These are
tasks where structural or resource dependency may mean we overload a resource
for a time, or where there is a resource or a group of resources who might,
if not well managed, constitute an internal constraint.
Recent work by Ricketts (3), especially the concept
of resource management and resource buffering in service-type operations,
including projects, is important and deserves widespread understanding. It is a significant move forward in Theory
of Constraints knowledge.
multi-tasking in projects is akin to reducing work-in-process in manufacturing
operations. Although in manufacturing
operations we certainly can increase the output of the constraint
independently of the work-in-process, at least in the short term, ultimately
failure to reduce work-in-process, and thus manufacturing lead time, will
cause such an implementation to stagnate far short of its real potential, or
more likely it will cause the implementation to fail.
operations we too can increase the output of the constraint, time, by
reducing the critical chain, but not independently of the work-in-process in
multi-projects. Because the touch time
is so much higher in project operations compared to production operations we
can’t even implement Critical Chain Project Management unless we reduce
have tried to keep things simple and focus on single project implementations,
the real world almost always forces multi-project conditions upon us – even
if it is a single project – by virtue of “other things” that must be done, as
well as the project. And if you think
avoiding multi-project is a cop-out, then just consider how many Critical
Path Method explanations don’t even go near multi-project.
There are two
aspects to multi-tasking. Goldratt
makes them explicit (4, 5) but my experience is that people confuse the two
issues almost immediately.
1. In any multi-tasking multi-project environment there is a proportionate
increase in individual project elapsed time with increase in total number of
projects. Simply stated, double the
number of open projects, double the length of any individual project.
2. Lack of a clear priority system between projects and tasks in a
multi-tasking multi-project environment means that there is a disproportionate
increase in elapsed time with the increase in total number of projects. Double the number of open projects and the
length of any individual project will more than double.
consequence of this disproportionate increase in duration is that the
reduction in touch time for any one project in such a multi-tasking
multi-project environment will be much greater than the 25% reduction in
touch time that we can obtain for a single project in a single project
Why is this?
Most people ascribe it to “complexity.”
But that is akin to saying “we don’t really know.”
disproportionate increase arises from the added uncertainty caused by what
Goldratt terms “bad-multi-tasking.” Bad-multi-tasking results from a lack of clear priority in
multi-project environments (6). As we
said on the page on project buffers, people are very good at estimating the
impact of uncertainty of resource availability and will build additional
safety into the touch time estimate to compensate for this (and then we go
and waste it for all the mechanistic and psychological reasons that we dealt
with on the same page).
We saw the
priority rules to avoid this situation in the buffer status section of the
previous page. In fact without buffer
management this would be impossible to achieve. This is why Critical Path Method is careful
to avoid addressing multi-project environments where there is resource
commonality between projects.
So let’s now
look at how to reduce multi-tasking in the simplest case assuming for the
moment that there is no confounding caused by lack of clear priority signals
amongst the various tasks and projects.
The surest way
to improve the flow of work through production operations is to reduce the
amount of work-in-process. Really we
are taking away the unnecessary waiting from the process – or unnecessary
delay while waiting. We have no choice
but to reduce the number of open projects on the books.
thing that has to be done is to stop new projects from entering. Stopping new projects from entering the
system has manifestly positive results.
However, despite the logic, it is not within people’s experience to
have projects taking a shorter duration.
thing to do is to help “flush” existing projects out the door by
concentrating more upon those that are closest to completion. Concentrating on projects in such a way
will cause them to finish sooner and clear the number of existing projects
faster – so we can continue to admit new projects sooner.
suggests freezing half of the open projects (4, 5). Let’s investigate this in detail.
Here we have an idealized production operation, too good to be true
for sure; but good enough to help convey the mechanics of what we must
do. There are 8 projects open at any
one time in this process. They take 16
periods to complete and one ends and another starts every 2 periods. We can see that in the next period project
2 will finish and project 10 will start.
are going to stop all new projects from entering and freeze half of the
current projects. Projects 3, 4, 5,
& 6 will continue to be worked upon while projects 7, 8, 9, & 10 will
Let’s see how
Projects 1 & 2 are completed.
Projects 3, 4, 5, & 6, are current. Projects 7, 8, 9, & 10 are frozen. We
have one new project, project 11 that is now pending.
Note that the
4 current projects will all be completed in less than their original
estimate. This is because the
resources assigned to multi-task on the frozen projects are free to
concentrate on the remaining current projects. The current projects will take half the
time to complete the remaining work because twice as much effort is being
expended upon them.
The same logic
applies in the future to the 4 frozen projects. We can taken this into account
already. Project 10 which was due to
start the period that we imposed the freeze will take half of the original time
to complete. Any new projects will
also be scheduled for the same duration – because by the time that they start
there will be only half the work-in-process present and therefore twice as
much effort can be expended upon them.
Projects 7, 8,
9, & 10 are off-set from the period that they “froze” until the period
that they are scheduled to be unfrozen.
Let’s have a
look at the next period.
Project 3 is complete, and project 7 is unfrozen and work has
recommenced on it. A new project,
project 12 is waiting in queue. No new
work has been admitted and 4 projects remain current.
Let’s look out
Project 4 is now complete and project 8 has been unfrozen. Four projects remain current. Two projects remain frozen.
Let’s step out
Project 5 has been completed and project 9 has been unfrozen. There are 4 current projects and one frozen
Let’s see what
Project 6 is now complete and project 10 is unfrozen. There are 4 current projects and no frozen
in the next period?
It seems a bit strange but after a period of completing projects
one-a-day, we have no project completed in the last period. Project 7 is completing this period. There are 4 current projects.