In
the past several weeks I’ve been getting lots of emails about Project
Management (PM) and specifically how the Theory of Constraints handles this
subject. And although I’ve had a similar
posting in the past, because of all the inquiries on this subject I’ve decided
to create a new entry. So let’s first
look at some published statistics on the state of projects around the US and
world and then take a look at the most common project management technique used
in the world today.
If yours is an
organization that relies on project completions as their primary source of
revenue and you’re like many other project based organization, then the results
of multiple surveys by an organization called the Standish Group1
might be of real concern to you. Back in
1994 the Standish Group conducted a landmark study (entitled the Chaos Report)
of nearly 10,000 IT projects across America and found that 52 % of projects ended up costing greater than 189 % of the original budget, 31
% were cancelled and only 16 % of
the projects were completed on time and on budget. The cost of these failures and overruns are
just the tip of the proverbial iceberg. The lost opportunity costs are probably
immeasurable, but could easily be in the trillions
of dollars. Pretty scary figures if
project execution is your business model aren't they?
Now
let’s fast forward thirteen years to 2007 to the “new” Chaos Report5
which revealed that only 19 % of
projects begun were considered outright failures and were cancelled, compared
to the 31% reported in 1994. In addition, 35 % of software projects started in
2006 can be categorized as successful, meaning they were completed on time, on
budget and met user requirements. Although
this is a marked improvement from their initial groundbreaking report, it’s
safe to say that these statistics still aren’t acceptable or at least where
they need to be! The point is, project
failure rates appear to be a universal problem spanning virtually all industry
types and although the success rates are improving, they still don’t rise up to
an acceptable level.
As I write this
posting, about 90% of the Project Managers around the world are using a project
management methodology known as the Critical Path Method (CPM) and have been
doing so for many years. If you ask a
typical project manager about what factors delayed a completed project, most
will tell you that something they didn’t expect or even had no control over
cropped up in some of the tasks and delayed them. In other words uncertainty or the Murphy bug bit them! Every project from virtually every
environment has uncertainty associated with it and how this uncertainty is
dealt with determines the ultimate success or failure of the project. So in order for a project to be successful,
there must be a way to protect it from uncertainty. So let’s take a look at how traditional
project management (CPM) attempts to protect a project from inevitable
uncertainty.
CPM uses a sort of
“fudge factor” in an attempt the completion date of projects. When developing the project plan, durations
for each individual task are estimated by the resources responsible for
executing them and then a safety factor is added to each task by the resource
responsible for completing it. For
example, suppose the realistic estimate of time for an individual task is one
week. Is one week what the resource
actually tells his or her project manager?
The answer is no! Most of the
time the resource will add his or her own safety factor to guard against
“things” that might happen that would delay completion of the task. So it’s not unusual for the original one week to be quoted as two weeks. They do this because they know from past
experience that as soon as they give the project manager an estimate, it automatically becomes a commitment! So with all of this built-in safety, you
would think that the project should always be completed on time….right? So it would seem, but the statistics on
project completions that we just saw paint a much different picture.
Ok, so if individual
project tasks have so much extra time imbedded in them, then why do you suppose
that so many projects coming in late? It’s
my opinion, and that of many others, that these completion failures are at
least partially explained by two very common human behaviors. Since the resources who gave the padded estimates
know that they have built “safety” into their tasks, they often delay or procrastinate work on the task until
much later than they had originally planned simply because they know they can. It’s a common behavior and if you think 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?
How about Wednesday? The late Dr.
Eli Goldratt coined the term, Student
Syndrome, to explain one of the reasons why the apparent built-in safety
gets wasted. When the task start is
delayed and Murphy strikes, the task will typically be late because the built
in safety was wasted through procrastination.
Ok, so what else negatively impacts project completions?
Another common human
behavior that extends projects and causes them to be late is something called Parkinson’s
Law. Resources intuitively know that if
they finish a task in less time than they estimated, the next time they have
the same or a similar task to complete, they will be expected to finish it
early again. So to protect against this,
even when a task is finished early, the resource doesn’t notify the project
manager that it is finished until the original due date is reached. We’re talking about personal credibility
here, so to protect it, early finishes aren’t reported. Parkinson’s Law states that work expands to
fill the available time so if the resource has one week to finish a task, the
entire week is taken to finish it. The
key effect on projects of these two behaviors is that delays are passed on,
but early finishes are not. So with
just these two behaviors in play, is it any wonder that projects are late?
While these two behaviors
do negatively impact project schedules, they aren’t the only reasons why
projects are late. Most organizations
today have multiple projects going on at the same time and it’s not unusual for
all of the projects to share common
resources. In fact, many project
managers tend to “fight over” these shared resources because they believe that
their project is the most important one or the one that has the highest
priority. Another problem is that in
many project based companies, leadership continually pushes new projects into
the system without considering the capacity of the organization to complete the
work. Leadership also mistakenly assumes that the sooner a project is initiated, the sooner it
will be completed. As a result,
perhaps 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 really bad! So is
there a difference between good and bad multitasking? In my opinion, I simply don’t like
multitasking of any kind because it extends the time required to complete all
tasks. I believe it’s more effective to
start a task and complete it or take it to a logical stopping point before you
start another one.
Quite simply, bad
multitasking happens when resources are forced to split their time between
multiple projects. Many leaders
mistakenly believe that multitasking is a good thing because it increases efficiency. In their minds, since everyone is “busy”
all of the time the organization is more efficient. Those of you that follow my blog on a regular
basis know how I feel about this performance metric! The bottom line is that using efficiency to
measure performance quite simply encourages exactly the wrong behaviors no matter what industry! It only encourages people to look busy, so the
negative impact of bad multitasking in a project management environment becomes
much, much worse. So to demonstrate
this, let’s look at an example.
Suppose you have
three projects (see Figure 1) that you’re working on simultaneously.
Figure 1
Figure
2
By using bad multitasking
look what’s happened to the time to complete each individual project. Without bad multitasking, Project 1 was
completed after 10 days, but with bad multitasking Project 1 has now taken 28
days, a full 18 days later than without multitasking!! Project 2, which was originally completed in
20 days, is not completed until day 29, 9 days later than with
multitasking! Project 3 which originally
took 30 days to complete, again is finished at the same 30 day mark. Both methods completed all three projects in
30 days, but which set of results do you think your leadership would
prefer? Having two projects done in 20
days and the third one at the 30 day mark or the results of bad
multitasking? Also keep in mind that
when you are guilty of bad multitasking, there is also time required to get
re-acquainted with each project so the multitasking times will actually be
considerably longer. In fact, some
studies have shown that this getting re-acquainted time on projects often pushes
out their duration by 2-3 times their estimated duration in the presence of
multi-tasking.
So let’s summarize what
we’ve learned before we move on. We’ve
learned that task time estimates for tasks are artificially lengthened as a
protective measure against Murphy and all of the negative baggage he brings to
the party. We’ve learned that even
though this safety is built in, it is wasted because of the Student Syndrome
and Parkinson’s Law. With the Student
Syndrome we procrastinate by putting off work until the last minute, while
Parkinson’s Law says that if we’re given ten days to complete a task, that’s
the shortest period of time it will take to complete, even if it is completed
earlier. We’ve learned that delays are
passed on, but early completions are not.
And finally we’ve learned how devastating bad multitasking can be to the
completion rate of projects and if we could eliminate it, we know our on-time
completion rate will improve.
In my next blog posting,
we’ll complete our discussion on CPM and then I’ll show you a different way to
run projects that typically raises the on-time completion rates in excess of
90%.
Bob Sproull
References:
1. THE
STANDISH GROUP REPORT © The
Standish Group 1995. Chaos Report.
No comments:
Post a Comment