We said in an earlier posting that in the Critical Path (CPM) Method safety is
imbedded within each task as a way to guard against the uncertainties of
Murphy. Critical Chain Project Management (CCPM) takes a
completely different approach by assuming that Murphy’s uncertainty will happen
in every project. Unlike CPM, CCPM
removes these safety buffers within each task and pools them at the end of the
project plan to protect the only date that really matters, the project
completion date.
There are many references that explain the details of how CCPM does this, but here’s a simple example to explain it. That is, by simply removing all of the protection from individual task estimates which we have estimated to be 50 % of the original estimate. Figure 6 demonstrates the removal of this safety. So now, the length of the critical chain is no longer 34 days, but rather 17 days. But instead of just eliminating the safety buffer, we want to place it where it will do the most good…..at the end of the project to protect the due date. This isn’t exactly how this works, but for presentation purposes to demonstrate the theory behind CCPM it will suffice.
There are many references that explain the details of how CCPM does this, but here’s a simple example to explain it. That is, by simply removing all of the protection from individual task estimates which we have estimated to be 50 % of the original estimate. Figure 6 demonstrates the removal of this safety. So now, the length of the critical chain is no longer 34 days, but rather 17 days. But instead of just eliminating the safety buffer, we want to place it where it will do the most good…..at the end of the project to protect the due date. This isn’t exactly how this works, but for presentation purposes to demonstrate the theory behind CCPM it will suffice.
Figure 6
Figure 7 is this same process, but this time
the safeties that we removed are added to the end of the project to act as a
cushion to Murphy’s inevitable delays. Actually,
we have added only 50% of the time to create the project buffer. So the question now becomes, how do we
utilize this buffer and how does it improve the on-time completion of the
project?
Figure 7
Suppose task A2 takes 7 days instead of the 5
days that are in the plan? In a
traditional project management environment, this would be cause for panic. In a CCPM environment we simply consume two
days from the project buffer and we’re still on schedule. Suppose now, for task B3, we only take 3 days
instead of the planned 5 days. We simply
add the gain of 2 days back into the project buffer. These actions are similar
to a bank account with deposits and withdrawals. When you need money, you withdraw it and when
you have excess money, you deposit it.
In traditional CPPM, delays accumulate while any gains are lost. This is a very significant difference! The project buffer protects us from
delays. For non-critical chain tasks, or
subordinate chains such as C1-C2 from our example, we also can add feeding
buffers to assure that they are completed prior to negatively
impacting/delaying the critical chain.
That is, in our example, as long as C2 is completed prior to D1, then
the critical chain will not be delayed.
One of the key differences between CPM and
CCPM is what happens at the task level.
In traditional project management we said earlier that each task has a
scheduled start and completion date.
CCPM eliminates the times and dates from the schedule and instead
focuses on passing on tasks as soon as they are completed. This function serves to eliminate the
negative effects of both the Student Syndrome and Parkinson’s Law from the
equation and permits on-time and early finishes for projects. In order for this to work effectively, there
must be a way to alert the next resource to get ready in time. This is equivalent to a relay race where the
baton is handed off from one runner to the next.
Earlier, we explained that in traditional
project management we track the progress of the project by calculating the
percentage of individual tasks completed and then we compare that percentage
against the due date or the percentage of remaining tasks. The problem with this method is because we
aren’t considering the estimated durations that are left to complete, it is
nearly impossible to know exactly how much time is remaining to complete the
project. Using this method to track
progress, many times you’ll see 90 % of a project completed relatively quickly
only to see the remaining 10 % take just as long. In fact, looking at the number or percentage
of tasks completed instead of how much of the critical path has been completed,
only serves to give a false sense of conformance to the schedule.
In my next posting we’ll look at the different
way CCPM tracks the progress of projects and why it is simply a much better way
of doing so.
Bob Sproull
No comments:
Post a Comment