I hope you've gotten MSP's PERT Analysis tools up and running. Now
I'll tell everyone why I believe this technique is obsolete from both
a theoretical and a very practical standpoint.
A few years ago I read an analysis of the validity of PERT Analysis
(aka Variance Analysis and True PERT) by a statistician. I started out
very skeptical, as I usually am about mathematicians, physicists and
statisticians (probably because I'm and engineer. Just as they all
tend to be skeptical about us). Summarizing a more technical
presentation, he said that PERT doesn't take into account the total
risk along each path, and that if you do, you'll get very different
results. PERT can be and often is very misleading. Only by assesing
the risks along a path and comparing at each node can you determine
the relative risks through a given project. I hope I'm paraphrasing
him right. It certainly made sense to me at the time.
The other practical reason that I eschew this methodology is that
unless PERT Analysis is modified in a significant way, it puts the
"schedule padding" or "contingency" within each task, just as allowing
individual resources to pad duration estimates themselves does. My
personal experience as well as my 13 years of teaching experience,
tells me that if an individual task's duration is padded to account
for the uncertainty of any such estimate, the padding is almost
universally wasted. If a 5 day task's duration is "padded", either
through PERT or just by allowing resources to estimate durations
themselves, without some "help", by 2 days, the vast majority of
people will start on the task at least 2 days after they are scheduled
to. The padding is immediately thrown away by the resource who often
requested it in the first place. This is not conjecture, but my
understanding based on 13 years of asking students, in MS Project
classes, what they normally do when they know the duration is padded.
(BTW, concealing that padding is even more danagerous, for reasons I
won't do into here.) Basically, using PERT Analysis in it's usual
form, or allowing resources to add padding themselves BOTH LEAD TO A
SIGNIFICANTLY LONGER SCHEDULE WITH NO BETTER CHANCE OF COMPLETING THE
PROJECT ON TIME THAN YOU HAD BEFORE YOU EMPLOYED THESE TECHNIQUES!
That is the name of the game in scheduling, isn't it? Finishing on or
before schedule.
The only way I've found to reliably bring most of my projects in on
time is to add the "padding" at the end of the project, or on large
projects, before major milestones. This is similar to Goldratt's
concept of Critical Chain scheduling. He claims to have invented this
method. He may have thought of it independently, but not first. I
learned it from Bob Sebald, a PM consultant in the mid eighties and
have used and taught it successfully since. Bob called the padding
"UEWS". "Unexpected Events Within Scope". Goldratt calls it schedule
contingency or buffering. With the UEWS at the end and publicly
announced, the idea is to use up the UEWS as the project slips,
hopefully ending the project before you run out of UEWS. This works
just like contingency money in the budget. Can you imagine allocating
"exta" funds for each task on the project to the resources and it
having any significant impact on bringing the project in under budget?
Of course not!
UEWS puts pressure on resources not to use it up. Everyone shares it
and if you use much of it up, you'll hear about it from your peers. Of
course, the people assigned to critical path tasks have the most
vested in not using it up to quickly.
As far as PERT goes, it can be useful if you use it to determine the
amount of UEWS you want to add at the end of the schedule, but not if
the additional duration is spread out task by task. (I'm not sure that
the time it would take to determine UEWS this way is warranted - a
good guess is probably just as valid)
I'm certainly interested in any feedback on this subject. I'd love to
hear other's experience on this issue.
David G. Bellamy
Bellamy Consulting
