2
$\begingroup$

I found this document on the internet: Dealing with Project Uncertainties

In this article I read:

In order for uncertainties to be included in the project estimates it is necessary to take into account an optimistic estimate (o), a pessimistic estimate (p), and a most-likely estimate (m). This approach is referred to as stochastic, or statistical estimating, and is the correct technique to use when developing what is known today as a PERT (Program Review and Evaluation Technique)

So to obtain the estimate for 1 task one can use this formula:

$$ Te = \frac{o+4m+p}{6} $$

It then presents us with this formula (I had already heard of this formula (in the book The black art of Software Estimation)):

$$ D = \sum T_{e} + Z\sqrt{\sum}\sigma ^{2} $$

Where $\sum T_{e}$ = the sum of all path expected times and $\sum \sigma ^{2}$ = the sum of all critical path variances and $Z$ is the number of standard deviations of a normal distribution (the standard normal deviate). And D is the project’s duration at a desired level of confidence "Z", such as 1.281 for 90% confidence

To obtain the variance it presents the formula:

$$ Variance = \sigma^{2} = (\frac{p-o}{6})^{2} $$

The article also says:

Regardless of the shape formed by the data values of the estimates, the shape of the values making up the sampling distribution of the expected times will approach a normal distribution based on the central limit theorem, if the sampling size is sufficiently large (usually 30 or greater). When the sampling size is less than 30, and the Central Limit Theorem cannot be invoked, a tdistribution must be used

Now the questions:

¿Is this $D = \sum T_{e} + Z\sqrt{\sum}\sigma ^{2}$ an accurate way to sum estimates? I asked before about file storage estimation, and this formula was not used to provide me with answer... ¿why is that? ¿is it because did not have different estimations with different optimistic, pessimistic and most likely sizes?

¿If sampling size is less than 30... how can I use this "tdistribution" to sum estimates ? ¿what is the formula then?

$\endgroup$
  • $\begingroup$ What is D meant to be? If it had "+/-" instead of "+" I would think it was a confidence interval, but is it instead the "maximum likely time to complete the tasks on the critical path?" $\endgroup$ – Peter Ellis Jul 22 '12 at 5:18
  • $\begingroup$ It is the project’s duration at a desired level of confidence "Z", such as 90% $\endgroup$ – Luxspes Jul 22 '12 at 5:23
  • $\begingroup$ For 90% confidence in the duration, Z would have to have a value of 1.281, for 75% a value of 0.675 (you can see the values in Table 2 – Cumulative Probabilities of a Normal Distribution in the linked article) $\endgroup$ – Luxspes Jul 22 '12 at 5:30
  • $\begingroup$ @PeterEllis so, to put it in your words: "D is the estimated time to complete the tasks on the critical path, based on the confidence interval specified in Z" $\endgroup$ – Luxspes Jul 22 '12 at 5:35
4
$\begingroup$

I would say the answer to your first question is "no, this is not an appropriate way to sum the estimates of time for individual tasks". It would be appropriate if the random element of the time taken to complete each task were independent of the randomness in the other tasks; but this seems unlikely. Obvious sources of dependence would include:

  • the initial estimates were all biased in the same direction due to the project manager's pessimism or optimism
  • a key resource that is used in more than one task on the critical path is under or over performing, leading to several tasks taking more or less time than predicted

How much of a problem this is is entirely a pragmatic matter and depends on the usual size of the covariance of task times (ie how much dependence there is in the way they differ from their estimates).

On your second question re t v Z statistics when there are less than 30 estimates of task time to add (I wouldn't call this a "sample" as your reference seems to - it's a bit counter-intuitive, although it could be justified if you twist your brain around enough). I would say that in fact the t distribution should be used all the time because the variances are all estimated. However, as n becomes bigger the t distribution becomes effectively identical to a normal distribution.

Wikipedia's article on the t distribution has a table of the critical values, or any stats program (even Excel) can provide it. As you're only worried about exceeding a certain threshhold, you can use the one-sided values (and this seems to be how you do your Z estimates). The appropriate degrees of freedom is a bit of a guess (because of the way variances are estimated in the first place) but is probably the number of tasks for which you are adding estimates, minus one. You'll see that as the degrees of freedom go up, the values of the t distribution approach the Z values you refer to in your comments.

$\endgroup$
  • $\begingroup$ So, while would be a bad idea to use it for scheduling (because the tasks are not independent, and if one ends later, it affects the other tasks depending on it), would it be appropriate to use it for effort? if we disregard project manager's pessimism or optimism, from an effort perspective, tasks are not "linked" ¿correct? $\endgroup$ – Luxspes Jul 22 '12 at 5:43
  • $\begingroup$ And, what about the file storage estimation? Should that be done using this formula for a sum of estimates? $\endgroup$ – Luxspes Jul 22 '12 at 5:46
  • $\begingroup$ Unless you take a circular definition of "effort" I would have thought any randomness in the amount of effort involved compared to estimation could still be dependent for the same reasons eg it turns out a resource is more or less efficient than realised, so all the tasks take more "effort" (if dedicated time from the resource is counted as effort). $\endgroup$ – Peter Ellis Jul 22 '12 at 5:48
  • $\begingroup$ Interesting... yes, dedicated time from the resource is counted as effort...So... if this approach is not such a good idea... would you please point me in the direction of a better approach? $\endgroup$ – Luxspes Jul 22 '12 at 5:55
  • $\begingroup$ (+1) I would add that it is folly to invoke the CLT in this context. If, for instance, the duration of one task on the critical path dominated the length of the project, then the CLT is useless and attempting to apply its formula would lead to overoptimistic estimates. For the last quarter century, simulation has been the standard practice for estimating variation in project duration, because the (clear, explicit) dependencies among tasks can create total duration distributions that cannot be calculated or approximated in any other way. $\endgroup$ – whuber Jul 23 '12 at 12:46

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.