Earlier
we demonstrated how by simply eliminating bad multitasking, significant gains
can be made in project completion rates, but we still have to address the
negative impact of the Student Syndrome and Parkinson’s Law. We know that both of these behaviors lengthen
the time required to complete projects.
Remember I explained how resources will estimate their task times and
then add in their own personal protection against disruptions that Murphy might
cause? Because the resources know that
this safety exists, it’s not at all unusual for them to delay starting work on
their tasks until the due date is close.
They, in effect, waste the safety net of time that they had originally
inserted into their tasks. And even if
the resources don’t delay their task starts and actually do finish early, they
simply don’t report the early finishes.
So how does CCPM deal with these two behaviors?
Whereas CPM relies on individual task durations as well as scheduled start and completion dates,
CCPM’s focus is not on finishing individual tasks on time, but rather starting
and completing these tasks as soon as
possible. It’s kind of like a relay race where the runners hand off the
baton. The next runner in the race sees
the runner coming and prepares for the handoff of the baton. This may not seem like a big difference, but
it is in terms of acceleration of project completions, it’s huge. Let’s learn more about CCPM.
So how does CCPM work? Like
CPM, when using CCPM we still gather estimates on individual tasks from our
resources. Also, like CPM, we identify a
Critical Path which is the longest path of dependent tasks. That is, if a task can’t start until a
previous task is complete, then we must wait. In project management, the critical path is
the constraint. However, unlike CPM,
CCPM also considers competing resources (i.e. the same resource has to work on
different tasks) and makes them a part of the critical path. Let’s look at an example of how CPM and CCPM
identifies the critical path.
Figure 1
CPM defines the critical path as the longest
path of dependent tasks within a project.
The critical path is important because any delay on the critical path
will delay the project correspondingly.
Figure 1 is an example of a series of tasks which must be completed in a
project with the critical path highlighted in grey. For example, Task A2 can
only be initiated after A1 is completed.
Task B3 can only be performed after completion of B1 and B2. Task D1 can
only be performed after completion of A2, B3 and C2. CPM would have identified the critical path as
C1-C2-D1 (i.e. the longest path of dependent tasks) and the project completion
estimate would have been 29 days (i.e. 8d+12d+9d).
What
if, in our example, tasks A2 and B3 were performed by the same resource? Would the critical path different? In Figure 2 we see the new critical path that
includes a provision for resource dependencies and as you can see the new
critical path is A1-A2-B3-D1 or 5d+10d+10d+9d equals 34 days. So the minimum time to complete this project
is now 34 days, not 29 that CPM would tell you it is. In my opinion, the failure to consider
resource dependencies is one of the key reasons why project completion rates
are so dreadful. The simple implication
of incorrectly identifying the critical path, which we will now refer to as critical chain, is that the project team
will never be able to complete their project on time without heroic efforts,
adding additional resources, overtime or a combination of all three. The practical implication of incorrectly identifying
the real critical chain is that the focus will be on the wrong tasks. Is this any different than focusing on
non-constraints in our earlier discussion on TOC? Incidentally, this “thing” we refer to as the
critical chain is the system
constraint, so by focusing on the constraint we can maximize the throughput of
projects in your organization.
Figure 2
We
said earlier that safety is imbedded within each task as a way to guard against
the uncertainties of Murphy. Critical
Chain 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 a portion of 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. Simply remove all of the protection from the
individual task estimates which we have estimated to be 50 % of the original
estimate. Figure 3 is the same project as
shown in Figure 2 with the safety removed.
So now, the length of the critical chain is half of the original
estimate or 17 days. But instead of just
removing this safety buffer, CCPM uses it a different way. The buffer is now pooled and placed at the end of the project to protect the due
date. The buffer is intended to function
like a bank account with withdrawals and deposits. That is, when you need additional time, you
withdraw it from the buffer while if you finish a task early, you deposit time
back into it.
Figure 3
This isn’t exactly how this works, but it will suffice for
presentation purposes. Let’s look at an
example.
Figure 4 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 against
Murphy’s inevitable delays. The question
now becomes, how do we utilize this buffer and how does it improve the on-time
completion of the project? Suppose task
A2 takes 7 days instead of the 5 days shown in the plan? In a traditional project management
environment, this would be cause for panic.
In a CCPM environment we simply “borrow” two days from the project
buffer and we’re still on schedule. Now
suppose that task B3 only take 3 days instead of the planned 5 days. We simply deposit the gain of 2 days back
into the project buffer. In traditional
CPM, delays accumulate while any gains are lost, but not so with CCPM. This is a significant difference! The project buffer protects us from the
inevitable delays that crop up during all projects. 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 the start of D1, then the critical chain
will not be delayed.
Figure 4
One
of the key differences between CPM and CCPM is what happens at the task
level. In traditional project management
(CPM) 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 to begin the next
task. This is equivalent to a relay race
where the baton is handed off from one runner to the next. Since the receiving runner begins running
before the baton is handed off, very little time is wasted.
In
my next posting, we’ll discuss the difference between CPM and CCPM in terms of
how the project is tracked. As you will
see, the difference in tracking mechanisms between these two methods is stark.
Bob
Sproull
No comments:
Post a Comment