Project uses your estimates for best case, worst case, and expected case
(usually the historic average) to compute the duration to be used for
planning purposes. You have a completely free hand to determine how each of
those three factors are weighted in the computation of duration used for
planning - if you don't like the best+worst+4*expected divide by 6 that is
Project's default, just change it with the PERT toolbar tool. Want
2*best+worst+3*expected to be used instead? You can use any multipliers you
want as long as the total of the multipliers adds up to 6. A revised
weighting is only a mouse click away.
Remember though that whatever weighting is used, your expected case, based
on performance data, is just one of the variables in the calculation of the
PERT estimated durations, not the end result estimate. You may well
estimate that your team will take X days to do task A, with best case and
worst case estimates of Y and Z, and that estimate might be based on very
expert knowledge of your team. But the question that PERT seeks to answer
is what is the probability that the final result will actually be X days and
what are the probabilities it will turn out to be X +/- 1, 2, 3, or
whatever days. It factors in the idea that the closer the best and worst
case are to being equidistant from your expected case, and the farther away
they are from each other, the more likely it is your expected case estimate
is accurate. If the best and worst cases are equidistant from your expected
case, the probability density is a symmetrical curve with your expected case
at the peak. But if the worst case is, say, 3 times farther away from the
expected than is the best case, then the curve is not symmetrical but is
skewed and it's likely that your expected case is too low. It's probable
that it will take longer to do the task than your expected case predicts and
the most likely duration, the peak of the curve, lies somewhere between your
expected case and the midpoint between the best case and the worst case. If
the worst case is farther away from your expected case than is the best
case, the probability curve's peak is to the right of your estimate while if
the best case is farther away, the curve's peak is to the left of your
expected case.
You want accuracy but the accuracy of an estimate is something that can only
be evaluated after-the-fact when you compare the actual results obtained to
the results that were predicted. No matter what method you used to arrive
at your estimate of X days to do the task at hand, it's not an accurate
estimate if it turns out to take your team 2X days to actually do the work
once the project is underway. PERT is trying to calculate how likely it is
that your estimates are accurate. Assuming your input variables of best,
worst, and expected cases are based on reality, if you estimate one thing
and PERT estimates another, I'd bet money that on the average your team's
actual performance results on their tasks will come in closer to the PERT
estimates than they are to your expected estimates.
I know it seems paradoxical terminology but unless your expected case lies
at the mean of the best case and worst case, your expected case is not the
most probable case <grin>. For greatest accuracy in calculating the most
likely duration, the best and worst cases should also be at least 3 standard
deviations of the population of data you used to determine your expected
case way from the expected case.
HTH
--
Steve House [Project MVP]
MS Project Trainer & Consultant
Visit
http://www.mvps.org/project/faqs.htm for the FAQs
r3kb said:
I'm glad that you have a standard to work with. The challenge is, that
standard doesn't accurately model my performance data. I don't want
Project
to inject errors into my values. By using Project (as designed today) to
aid
me in calculating my pessimistic/expected/optimistic durations, it skews
the
values I've input based on the way my team performs.
It seems to me that MS-Project developers would be wise to take the
Construx
Software Estimation class to learn more about how the rest of the world
wants
to estimate and commit to project completion times. Microsoft Press
publishes a number of books written by Construx team members, yet
Microsoft
Project developers seem oblivious to the methods proposed therein.
The problem with blindly following standards is they're just standards.
They don't necessarily reflect real-world performance. Whether or not
PMBOK
or ANSI approves a certain method of estimation, historical data on
performance is nearly always a more reliable predictor of future
performance
than a generalized (read more arbitrary) method.
I don't need precision as much as I need accuracy. Which is more precise?
4.124627 or 3.14? Obviously, 4.124627. The problem is, when looking for
Pi,
3.14 is far more accurate than 4.124627. What I see happening in Project
is
by clicking on Calculate Pert (for my GANTT chart update), is it's
introducing more precision while reducing accuracy. I have better
accuracy
when I base my computations on historical data. Project has more
precision
because it bases computations on a formula that doesn't correlate to our
performance.
Precision versus accuracy is the entire reason why I'm asking for the
ability to let users tell Project to leave the pessimistic, expected and
optimistic durations alone and just show me the resulting expected
time-lines
of a project. That way, I know I can give an estimate to my customer that
I'm comfortable with.
Applications for reliable cone of uncertainty data allows project managers
to calculate whether or not a project is financially feasable, resource
feasable, or even possible to complete within the given parameters. Once
that step is completed, if all three of the above are met, a good project
manager can commit to a completion date range. As the project progresses,
the project manager updates estimated data because the uncertainty has
decreased. A new estimate is given with a more precise time-line with
greater accuracy. Again, the project is checked for financial and
resource
feasability and opportunity to complete. If the project still falls
within
those parameters, it continues. And so the project continues iteratively
in
this way.
I could go on with more about this, but like I said, I'd encourage the MS
Project development team to take Construx's Software Estimation class
before
continuing further development of Project at all.
