|
A Guide to Implementing the Theory of Constraints
(TOC) |
|||||
|
Multi-Project Drums |
|
|
|
Critical
Chain Project Management – A Performance Engine For Projects Critical
Chain Project Management is the Theory of Constraints logistical application
for project operations. It is named
after the essential element; the longest chain of dependent resourced tasks in the project. The aim of the solution is to protect the
duration of the project, and therefore completion date, against the effects
of individual task structural and resource dependency, variation, and
uncertainty. The outcome is a robust
and dependable approach that will allow us to complete projects on-time,
every time, and most importantly within at least 75% of the current duration
for single projects and considerably less for individual projects within
multi-project environments. The
shorter duration provides a sterling opportunity in the marketplace to
differentiate ourselves from our competitors who deliver poorer outcomes, and
late at that, via other project management methods. It also offers the opportunity to deliver
more projects over all, in the same amount of time, at no increase in
operating expense, thus significantly improving the bottom line. Would that be useful? Absolutely! I like
to think of Critical Chain Project Management as a performance engine for
projects. And, by “engine” I don’t
mean the thing under the hood of a bright red Ferrari, I was thinking more of
the 4000-6000 horsepower turbo-charged diesel engine that sits under the long
hood of each locomotive at the front of a North American transcontinental
intermodal freight train. The analogy
isn’t so far off. Such a freight train
is long and sinuous and interconnected, it is challenged by some fairly
impressive upgrades and is rewarded by coasting down some equally long
downgrades, it makes a number of “meets” or passes along the way, sometimes
having the right of way, sometimes having to wait for something else. But in the end the objective is to move the
freight quickly and effectively from one coast to the other and to arrive on
time. Critical
Chain Project Management is an amalgam of two parts; we need both parts to
make a really good show. If the chain
of critical tasks is the engine for projects, then buffer management is the
monitor. Buffer management is the
second part of this two part act. We
use buffer management to guide the way in which we fine tune the motor for
peak performance. In the
older notion of planning and control, or planning and execution, the first
part; the critical chain, is the planning stage of the approach. This is the overall agreement on the logic
and duration of the steps in the project.
The second part, buffer management, is the execution control system
that allows us to keep a running check on the system. However, I want to reserve the words
“planning” and “control” for localized activities within individual
projects. For the moment I want to
step out a level and instead use the terms “configuration” and “monitoring.” Configuration becomes the generic rules for
all Critical Chain Project Management, and monitoring via buffer management
becomes the feedback into these generic rules. Let’s draw this.
Let’s remind ourselves of our “plan of attack,” the
focusing process. On the measurements page we introduced the concept
of our “rules of engagement” which was to define; the system, the goal, the
necessary conditions, the fundamental measurements, and the role of the
constraints. On the paradigms page
this was extended to include the role of the non-constraints as well – an
important and too often overlooked aspect.
On the process of change page, we introduced the concept of our plan
of attack – Goldratt’s 5 focusing steps that allows us to define the role of
the constraints (and therefore also the role of the non-constraints). Once again, the 5 focusing steps for determining the
process of change are; (1)
Identify the system’s constraints. (2)
Decide how to
Exploit the
system’s constraints. (3)
Subordinate everything
else to the above decisions. (4)
Elevate the system’s constraints. (5)
If in the
previous steps a constraint has
been broken Go back to
step 1, but do not allow inertia to cause a system constraint. In other words; Don’t Stop Improving. In all of the logistical applications of Theory of
Constraints we have used these same 5 focusing steps as a scheme or a road
map for explaining the detail of each application. There is no need to change our approach
here, so let’s start at the start, with step 1; identify. Let’s have a look at our simple project – the one
that we used on the previous page in our prior discussion on buffers. However, let’s forget about buffers for a
moment, we will incorporate that newfound knowledge soon enough. Let’s concentrate first on the critical
chain. Here is the project plan.
Let’s add some additional information, some task
durations, and some colors to represent differing resource allocations.
How does the earlier approach of Critical Path
Method deal with such conflicting resource allocations? There are two answers. The first is that it doesn’t deal with it
at all, it just ignores it completely.
This can be achieved by failing to resource the tasks or by resourcing
the tasks and then failing to “level” the project according to the
resourcing. But by far the better
answer is to level the plan according to the resources. This is what we get.
Once we have leveled the plan according to the
resource availability we can determine the critical path in Critical Path
Method. Let’s have a look.
What then would be the critical chain? Let’s have a look.
In Critical Path Method the resource contention is
addressed by leveling. Here the
resource contention is addressed by moving task 4 back to an earlier start. There is no reason why a project manager
using Critical Path Method would have not have used a similar solution to
address this particular resource contention.
It is important to stress, however, the principle of Critical Path
Method, and that is that there is more than sufficient resource capacity to
undertake all the dependent tasks.
Reality is often different.
Reality requires resource leveling or moving resource dependent tasks
out of contention. In Critical Chain
Project Management, principle and reality are aligned. Tasks are dependent and resources are
always finite. We plan using that
logic from the very start. The strength of Critical Chain Project Management
comes into its own when we see how the buffering of the critical chain and
the buffering of the feeding chains protects the whole project. But we are getting ahead of ourselves. We have identified the critical chain, the longest chain of dependent
variables; both resource and structural, and hence the shortest duration in
which we can safely hope to complete the project. Or is it?
Let’s see how we can exploit this chain. We have identified the constraint, it is time. The only way that we can exploit this is to
achieve the same outcome in less time.
We can do this without working harder by addressing the mechanistic
and psychological factors that confound the safety time embedded within
individual tasks of the project.
Indeed, we have addressed all of these in some detail in the preceding
page on project buffers. The result,
the generic configuration for Critical Chain Project Management, is that we
can safely reduce the total project duration, the total touch time, to 75% of
the initial estimate. This is what we
will get.
It is the generic or global configuration that
determines the degree of exploitation of the Critical Chain. We don’t normally see it like this because
we arrive at this deduction from a different direction; identifying the
safety time, taking the safety time out, aggregating it, positioning it, and
then reducing the excess that arises as a consequence of aggregation and
global positioning. Because we have
already “been there done that” on the previous page, jumping to this step
shows clearly what constitutes exploitation.
It is the shortening of the critical chain that constitutes
exploitation. The project buffers are
not an exploitation step, they are a subordination step – they ensure that
our shortened project remains feasible.
If we were to leave the safety time localized and embedded within individual
tasks we would have no better chance of exploiting the critical chain than we
currently do. We will come to
subordination soon enough. At a local level, for each unique critical chain
project there is another level of exploitation, I want to call this local
planning. This is the determination of
each individual task in the project – or indeed whether something is treated
as one task, subdivided into two tasks, or amalgamated with another task to
create one larger task. It also
involves the determination of an appropriate initial task duration
estimate. This is an estimate that has
a reasonable chance of completion. It
is not a generous estimate that will ensure completion and it is not a tight
estimate that will ensure non-completion.
It is something that we should be reasonably comfortable with. We have previously addressed this as the
80% estimate. At a local level, for each unique critical chain
project we must also determine the correct sequence. This might appear trivial, but there are
very many projects where task B is done after task A because; “we have always
done it that way.” If we can, we
should take tasks that in the past were serial and make them parallel. This is what I mean;
Lastly, at a local level, for each unique critical
chain project, resource the tasks with appropriate people. A good place for less experienced people is
on the feeding chains, a good place for experienced people is on the critical
chain. Here is a summary diagram of the local planning
aspects.
Let’s have a look then at subordination. Here is our Critical Chain once again, showing 75%
of the original task duration.
We then reduce our task touch time estimate
accordingly – by 2 units, to 4 units.
Let’s remind ourselves once again, Critical Chain
Project Management is a sequence, not a schedule. The task touch times are made short enough
that indeed some tasks can be completed within that time. Most, however, will probably need to use
some of the buffer time that is aggregated and available to the whole project. The buffers
subordinate the tasks to the total project completion time and ensure
that we are able to fully exploit
the 25% reduction in completion time. We will take a journey through time and show how the
individual tasks and buffers operate and interact. But first, there are a few more subordination
issues to cover. The eagle-eyed amongst us, might have seen an
opportunity to further reduce the completion time and thus further exploit
the system. Because this option ends
up giving us two choices, it is worth following up as an alternative on a separate page. What else do we need to protect? Well if Critical Chain Project Management
is a sequence, not a schedule, then how do the various resources know when to
start their tasks? The answer is that
we must keep them “in the loop” as the project progresses. Although this has been termed a “resource
buffer” (1,2), it is really a “please let me know in advance” of the intended
task start date. The only scheduled
dates in this plan are the start and finish dates. A much more important subordination activity is the
removal of multi-tasking There seems little point in exploiting the
constraint, the amount of time taken to complete the project, if we then go
and extend the completion time by multi-tasking – the market won’t thank us
for doing that because it will not perceive a difference. Multi-tasking is the habit of having more than one
task from more than one project on the go at the same time. We “slice
and dice” between the competing priorities of the various projects. If nothing else, we extend individual task
time by the multiple of the number of concurrent tasks that we are working
on. If everyone in the system is doing
this – that is, it is happening to most tasks, it shouldn’t be surprising to
find whole projects taking longer as well as individual tasks. Here is a simple case, just two
projects. Let’s see what happens.
We all know the solution only too well too. We know that we have to stagger the release
of new projects into the system. We
know what it should look like in theory.
Let’s check.
In many manufacturing production operations,
production managers (or their sales people) often believe that putting new
work into the process stream earlier will ensure that it comes out earlier –
even when all past evidence is to the contrary – maybe there is some
satisfaction in saying “we started it the other day”. Oddly, in many project operations, project
managers (or their sales people) often believe that putting new work into the
project stream earlier will ensure that it comes out earlier – even when all
past evidence is to the contrary.
Again, maybe there is some satisfaction is saying “we started it the
other day.” So, you see, we are all
fairly much on even ground. When the current mode of project management is so
tightly aligned to Critical Path Method project planning and execution, it is
no wonder that multi-tasking is a fact of life, it is no wonder that projects
take longer and longer, and it is no wonder that there is real pressure to start the next
project even sooner. What is needed is
a better way to plan and to execute and have some discipline to put it into
effect. Critical Chain Project
Management is manifestly better but we have to supply the discipline. We will cover more of these aspects on the
implementation details page. Right now, we have worked our way through the identification, exploitation, and subordination
of a simple project, a very simple project.
Simple though it may be, it however allows us to examine in relative
safety, most of the decisions that we need to make in order to bring project
management into the current century.
Let’s now walk our way through this simple project as it unfolds
before us and see how the tasks and the buffers interact. Let’s go. We have done our plan, and now we need to execute
it. Stuff will happen, it always does,
but we have hopefully protected our project through our buffering activities
so that we can complete the project on time and in less time than we
initially envisaged – 25% less time than the initial estimates would have us
believe. And although we have done this once before on the
previous page, let’s do it again, because we need the numbers generated to
show us how buffer management and buffer status work. Here is our plan.
We have a buffer graph as well.
Let’s make our unit of time equal to days. On the graph, project duration, in days, is
along the horizontal axis and buffer penetration, in days, is along the
vertical axis. So we have a six week
project made up of 6 different tasks in one critical chain and one feeding
chain.
Buffer Penetration = Sum Task
Estimates - Days Elapsed - Active Task - Remaining Tasks Of these; the total task estimates are known prior
to deployment of the project, and so too are the durations of any remaining
tasks. The only variables are the days
elapsed (the duration since start and up to our review) and the task estimate
for any current task on the critical chain. For day 5 of our simple project we have; Buffer Penetration = 20 days - 5 days
- 4 days - 12 days = (-) 1 day Really what we are saying is that given that we
estimate that we need 20 days; we must keep 4 plus 12 days in reserve for the
current and future tasks or 16 days in total.
That leaves 4 days for the completed tasks, but as we know we have
already taken 5 days, so we must take one additional day from the
buffer. And that is exactly what we
did. Buffer penetration doesn’t tell us much unless we also
know the extent of the buffer, in fact by knowing the extent of the buffer we
can determine the buffer penetration as a proportion rather than an absolute
measure. We use “buffer status” as
such a proportional measure. Buffer
status was defined for drum-buffer-rope make-to-order and make-to-stock (3)
and simplifies here as; Buffer Status = Buffer Penetration /
Buffer Duration In our example this is; Buffer Status = 1 day / 10 days = 10% Buffer status is synonymous with “buffer
consumption.” Knowing the buffer status as a proportion rather
than as an absolute measure allows us to compare the progress of different
length feeding chains with the critical chain within a single project and to
also compare differing critical chains across different projects. Let’s press on, let’s look at how things have
progressed by day 10.
Buffer
Penetration = Sum Task Estimates - Days Elapsed - Active Task - Remaining
Tasks Buffer
Penetration = 20 days - 10 days - 1 days - 12 days = (-) 3 days Buffer
Status = 3 days / 10 days = 30% Well hang-on a minute, let’s have a closer
look. Surely only 2 days of buffer
consumption have occurred already? By
the end of the 10th day, we could only feasibly have done two 4-day tasks, so
surely we could only have consumed 2 days from the buffer? In fact, history shows that task 1 took
5/4ths and task 4 took 5/4ths (up until the end of the 10th day). So this proves that two days of buffer were
consumed. We seem to have appropriated another day from the
buffer for the currently active task which at the end of day 10 still has 1
day to go. So why put that in the
buffer consumption now? Why cover the
base before we get there? We haven’t
consumed it yet. But by tomorrow, we
will have. Although, equally, we might
not; we might need more yet, or we might need less, it could be over by
lunchtime the next day. And, then, if
we are going to extrapolate for the active task, why not all the other future
tasks as well? It looks like a can of worms. Let’s try and straighten these worms out
for a minute. Logically we could
account for all future tasks – but how accurate would that be? And isn’t that what the buffer is there for
in any case? So, let’s leave the
future for the future. But at the
present, at the end of day 10, people are saying that 1 more day is still
required to complete task 4. Should we
ignore that? Surely the estimate of
the current task has some much greater validity, it is already active, we
know much better the contingent dependency that arises from the
predecessor. The uncertainty must
surely be diminished as a consequence?
These are the reasons why we include the buffer consumption for the
active task – even if we haven’t consumed all of it just yet. Looking at it another way; if the completion time of
the task that we are working on is going to “blow out,” wouldn’t we want to
know that, wouldn’t we want to check that impact on the project as a whole,
wouldn’t we want to take remedial actions if they were required? OK, one more way to look at it. Forget about what you know of the detail of
the past. Let’s blank it out!
Scary not! But it certainly is
interesting. You see, we don’t need to
know what happened in the past. We
don’t need to know which tasks finished when; which tasks finished early or
which tasks finished late. We don’t
need to know which tasks took less than our estimate and which tasks took
longer. The critical chain is a chain
of dependencies. All the past actions
and non-actions feed through to the current task. If people had sat on their hands for the
first 10 days, we would know about it, because task 1 would still be active. All the hand-wringing in the world about what has
occurred and is done is of no immediate value – although we might like to
review it later so that we can learn from it – only decisions about future
tasks can have any effect. We can cut
to the chase, and focus solely upon what lies ahead. Why we want to include the current task estimate
might make more sense if we consider the concept of “project status.” Let’s define project status as follows; Project Status = Elapsed Duration /
Total Project Duration In our example here, this is; Project Status = 10 days / 30 days =
33% If we have consumed 33% of our project, we ought to
have consumed 33% of our buffer, or maybe less. Let’s add this to the diagram.
So, when we include the active task in the buffer
penetration or buffer status we are saying that during the consumption of the
first 33% of the project we exposed ourselves to a 30% consumption of the
buffer. And the buffer is there to be
consumed, but not too quickly. Onwards.
Let’s have a look at day 15. |
