|
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 most
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,
and 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. |
