In this posting we will continue to dissect the
most common methodology to execute projects, the Critical Path Method. Again, I want to thank Bruce Nelson and my son John for writing much of what is to be posted in the next 4 or 5 postings.
CPM attempts to guard against uncertainty by
using a sort of “fudge factor.” In the
early stages of project planning, durations for each of the individual tasks
are estimated by those resources that are responsible for executing them. These same resources then add a safety factor
to each task duration, in order to protect the task from the inevitable and
unknown sources of uncertainty. For
example, suppose the realistic estimate of time for an individual task is one
week. Typically the resource will add his
or her own safety factor of their own to guard against “things” that might
happen that would delay completion of the task.
So, for example, it’s not unusual for the original one week to be quoted
as two weeks. Resources react this way
because they know from experience, that as soon as they give the project
manager an estimate, it automatically becomes a commitment that they must meet!
A typical project manager then adds up all of
the individual, inflated time estimates and add his or her own safety
factor. Why is this done? Project Managers know from experience that at
some point in the project Murphy will strike and some of the tasks will be
delayed, so to counter this, they add a safety factor to protect the project
from being late. Keep in mind that every resource inflates every task, so it’s
not uncommon for the estimated duration to be in the neighborhood of fifty
percent greater than it takes to actually complete the task. So with all of this built-in safety, the
project should be completed on time….right?
So it seems, but the statistics on project completions don’t bear this
out.
In traditional project management tracking
(CPM), the progress of the project is typically done so by calculating a
percentage of individual tasks that have been completed and then comparing that
percentage against the due date. For
example, if there are 200 individual tasks assigned to a project and 180 of
them have been completed, then the project is 90% complete. Sounds reasonable, but is this the right way
to track progress? The problem with
using percentage of tasks completed is that not all tasks have equal duration
estimates. By that I mean, comparing a
task that has an estimate of one day to a task that should take one week to
complete is an invalid comparison.
Compounding this problem is the mistaken belief that the best way to
ensure that a project will finish on time, is to try to make every individual
task finish on time. This too sounds reasonable,
but later on you will see why this isn’t so.
So if individual project tasks have all of
this extra time imbedded in them, then why are the projects coming in late? This is partially explained by two, very
common human behaviors. The project resources
know that they have built in this “safety” into their tasks, so knowing this, work
on their tasks can be delayed and they’ll still have time to complete their
tasks on time. Remember back to your
high school days, when you were given a due date for a paper for Thursday, when
did you start working on it? Wednesday? Or you knew you had a test scheduled for
Friday, when did you actually start studying for it? Thursday? Dr. Goldratt coined the term, Student Syndrome, to help explain these
behaviors as to why the apparent built-in safety gets wasted. It’s called procrastination. When the task start is delayed and Murphy
strikes, the task will be late because the built in safety was wasted through this
procrastination..
The other human behavior that lengthens
projects is referred to as Parkinson’s Law.
Parkinson’s Law is defined as work expands to fill the available time. Resources instinctively know that if they
finish a task ahead of its scheduled due date, then the next time they have the
same or a similar task to complete, they will be expected to finish it
early. So to protect against this, when
a task is finished early, the resource doesn’t notify the project manager until
the original due date. The resources’
credibility is on the line here, so to protect it, early finishes are never reported. The key effect on projects of this behavior
is that delays are passed on, but early finishes aren’t.
While these two behaviors clearly negatively
impact project schedules, there are other explanations as to why projects seem
to always come in late. If you’re like many
organizations today, you have multiple projects going on at the same time and
it’s not unusual for projects to share resources. In fact, many project managers tend to “fight
over” these shared resources because they believe that their project is the one
that is most important. At the same
time, there is a belief that the sooner a project is started, the sooner it
will be completed. The result of this
thinking is that projects are “pushed” into the fray without considering the
capacity of the organization to complete the work. As a result of these two actions, conceivably
the most devastating problem of all associated with project completion occurs……bad
multitasking! But wait a minute….I thought
we’d all been taught for years that multitasking is a good thing? Good multitasking is good, but bad
multitasking is not.
In my next posting we’ll talk more about bad
multitasking and continue our comparison of CPM and CCPM.
Bob Sproull
No comments:
Post a Comment