Yes,  Dennis.  I do not like the term muh myself either.  If you like it is a less pessimistic version fo Murphy's law; if lots of things can go wrong at least one of them probably will!

Denis, for some reason I have only just become aware of your post of 12/2/2!  You say you fail to see my point, but in fact you are making the same point.  It is nothing new, just the fact of merge bias.  In your example, you say there is a 31% chance of finishing in 35 days.  Without taking account of merge bias -- for example if one were to use the PERT method -- one would come up with a 50% chance of finishing in 35 days.  And if one used the expected durations in a determiistic CPM one would also come up with 35 days.  The triangular distribution makes the bias less pronounced than the uniform distribution, but it is still substantial.  And in a real network there may be multiple merge points and the bias builds up.

Tony;

If I understand what you are saying, we have a 6X6 matrix with each cell having an equal probability of occurence.  Which means out of 36 possible outcomes only once will we complete the project in 1 day, 3 times for 2 days, 5 for 3, 7 for 4, 9 for 5, and 11 times it will take 6 days.   Or 2.8%, 8.3%, 13.9%, 19.4%, 25%, or 30.6% respectively chance of finishing the project on the specific date. 

If I do this in PRA, I have two activities with an expected duration of 35 days (3.5 days - set up for whole days, so I multiplied by 10) with a max of 60 days and min of 10 days, and assuming a triangle distribution (no longer a equal probability of occurence) then you get 31% chance of completing the project in 35 days, 90% chance in 52 days, 50% chance in 40 days, but only a 10% chance of completing the project in 28 days or less [divide by 10 to compare with matrix results].  SRA will give a 50% chance of finishing on or before 4 days vs. 44.4 % for the matrix, this is due to the PDF used (triangle). [4 or 40 was the only whole number represented in both models].  I fail to see your point.

I assert that we can arrive at a reasonable expected value by averaging a suitably large population.  How would you arrive at the expected value?

FYI: I nice example of merge bias.

Dennis,

I like the river example very much, is perfect.

Reminds me of an issue I provide support to my wife regarding her work with transportation cycles of Containers. For some orders they have the same specifications and the average matters as a Container equals the other. One Container late will be supplied by one early. But with special orders each Container is unique and the average means about 50% of probability of delivering on time as the sample statistical analysis confirms.

This has been an issue impossible to teach to the sales force that insists in promising not average which is wrong (just 50% probability of meeting target delivery if distribution is uniform) but earliest which is worst.

The observed times last year ended up with a 60% cumulative probability at average, a bit better than if a symmetrical distribution but still short of a safe delivery promise.

..... somewhere in the Tropics

The same goes for any job, the average duration yields too low probabilities of success, you need the statistical distribution to make better decisions, and even an approximate distribution will be better than just using the average. But do not forget the curve for the total job distribution curve on a CPM is not the sum of the distribution curves of the activities on the deterministic critical path. A wrong assumption of initial PERT as it was missing the effect of changing critical path as some non critical activities in the deterministic schedule become critical, shifting to the right the total duration distribution curve, the reason why we need Monte Carlo instead of a simple equation that considers a single static critical path.

Best regards,

Rafael

I agree with Emily with regard to the importance of using Monte Carlo or other valid statistical methods.

I agree with Deveaux with regard to DRAG, it has its place with statistical method as in summary the theory is that in order to increase the probability of success you must target for an early date in the hope of finishing on time. But targeting for earlier time comes at a cost and here DRAG is of value in combination with other tools. Usually after using methods such as adding shifts, increasing crews or changing logic it is still not enough and DRAG helps.

Definitively there is an element of uncertainty on lag values and Deveaux is correct that it will provide for better modeling if Monte Carlo simulations include this uncertainty on lag. We got to live with the limits of our models, even with the issues regarding which probabilities distributions we shall use I would dare to say a probabilistic forecast is better than a deterministic.

Best regards,

Rafael

Not sure where to start in answering recent  comments.

Steve:

The issue of distributions on lags may be a valid reason for not using any existing MC system, but it would be easily fixed and is not a theoretical objection to MC.  (Some systems do allow % lags, which I think would address the issue at least wrt your example.)

Regarding references on lognormal, there is one link and two references at http://barbecana.com/lognormal-distribution/

Regarding DRAG, I had to Google it.  Seems it is your own invention.  Sounds like something which might be worth doing, though it does not seem to fit in particularly with MC or with risk analysis in general.

You mention risk registers and such as being useful, and they are.  I think this is as much as anything a terminology issue.  Quantitative risk analysis, which I believe can  only be done by MC simulation, is answering a different question than qualitative.  Quant is concerned really with general uncertainty whereas Qual is concerned with the “black swans.”

Ralph:

“My world (Oil & Gas) does benefit from an extensive history, so reliance upon unit rates (averages) is valid.  Other industries, I cannot say. “

This misses the point.  The reason that the average does not adequately represent reality is nothing to do with how well we can estimate the average.  It could be absolutely exact but it would still not tell us everything we need to know.  (An example from the Flaw of Averages is the statistician who drowned in a river whose average depth was only 3 feet.)  And sometimes, as in project networks, using averages introduces major bias. 

In general, this is because if F is a non-linear function of x, then there can be a big difference between F(average(x)) and average (F(x)).  Another example from flaw of averages is of a drunk walking down the center of the road, or trying to, and staying there on average.  So, F(average(x)) is “alive” whereas average(F(x)) is “dead”!

Hi, Tony. 

Thanks for your response. Let me try to be a bit clearer -- I certainly don't resent anyone investing more time and effort into scheduling.  The state of the discipline is so pathetic that anything that improves it is to be lauded. I just don't think that Monte Carlo adds enough to justify a great deal of additional effort and cost.

Let me try to address your points:

"Steve, you point out that PERT utilizes a 3-point estimate, but the issue is what does it _do_ with these three estimates.  It uses the well-known formula to produce a single number which is meant to represent the expected value (though it is only an approximation), and then uses this value as if it were a deterministic one.  (snip) IMHO that makes a nonsense of PERT, which is why it was discredited ver shortly after it was first used in the 50’s."

Well, we're pretty much in agreement on traditional PERT.  I think it adds a tiny bit in cases where someone has only the sketchiest estimate for duration.  Since the mean of the three estimates will usually be greater than the mode, the (probabilistic) formula will produce a deterministic estimate that at leat takes into acount the sometimes-long "tail" of the pessimistic.  But no big deal -- back-of-the-napkin sanity checks.

For the dangers of using averages as if they were all you need to know, I recommend Sam Savage’s book, “The Flaw of Averages,” though this is not especially concerned with project management. 

I will order it.  I'll also recommend Nassim Nicholas Taleb's book The Black Swan.  Also not concerned with project management, but it has great relevance for the Trigen distribution.

The problem of determining the correct distribution to use is a real one, but given that we have to make decisions in an uncertain world it seems to me that we have no choice but to try. 

Indeed, we have to realize that we live in an uncertain world (and, admittedly, some fools don't realize it!), but as Taleb points out, it's not necessarily a Gaussian world -- and those tails of uncertainty can inflict painful wounds!  Yes, we need to manage uncertainty through contingencies and schedule reserves -- but I would much rather see effort being put into schedule compression and optimization (resulting in more profitable schedules and larger reserves) than believing that running a Monte Carlo system gives an answer that is any better than the quality of the data that were input.

You are also correct to point out that there is a big difference between a triangular and a PERTbeta distribution with the same absolute end points, but there is very little difference between a triangular and a PERTbeta with the same standard deviation.  (The so-called Trigen distribution helps here, though it is really just a different way to specify a triangular distribution.)  There is quite a bit of empirical evidence in favor of the lognormal distribution.

I'd honestly like to read that evidence, if you can point me.  The traditional estimates suffer from variable definition: when one person says "pessimistic", they mean a number they might miss 20% of the time; when another person says "pessimistic", they mean a number they will probably still achieve if a nuclear war, a comet, and a gamma ray burst all arive at the same time! The Trigen distribution helps define an estimating point, but at the cost of:

1. In effect, two more estimates needed for each activity (the % chance of being below that number);
2. Factoring out even the "little" black swans, i.e., the medium-sized but impactful tails on the Gaussian distribution.

The numbers I looked at seem to change the delta from the PERTbeta by about 6%, rather than the 10-15% of the triangular.  But since I (and most of the time the user) don't know what the distribution should be anyway, I don't know if that's good or bad.  Maybe it SHOULD be the triangular -- I'm just saying there's nothing precise about it, and a lump reserve estimate based on the overall riskiness of the project is a lot simpler and likely to be just as accurate. But I'm willing to be persuaded.

I have not before come across the requirement to put distributions on lags, but there is no reason why it should not be done.  I will consider it for our next  release.  (Yes, I have an axe to grind, being the developer of Full Monte for MSP, see www.Barbecana.com)   It certainly is not a theoretical reason to object to MC. 

I have to disagree with that last sentence.  If the MC does not vary lags, it's a huge problem. Again, if X has estimates of 5, 12 & 24, and is an SS 8 predecessor of of Y, Y's start date is the beginning of Day 9, whether X finishes on Day 5 or Day 25. That is a problem!   If X takes 5 days, Y should probably start about Day 3, and if X takes 25 days, X probably shouldn't till about the beginning of Day 17.  That's a huge difference.

However, if you want to REALLY add something new and valuable to Full Monte, have it compute the probabilistic Critical Path Drag and Drag Cost.  Now THAT might really have value, showing the PM where to staff up. And I don't know of any MC that does that calculation.

Finally, you say there is an attempt to make Schedule Risk Analysis synonymous with Monte Carlo simulation.   Since there is no other way to do schedule risk analysis  I would say that this is legitimate

I don't agree that there is no other way to do schedule risk analysis.  A risk log with estimates of schedule impacts and reserves (before both merge points and at the end of the project) can have significant value, whether or not an MC system is used.

Fraternally in project management,

Steve the Bajan

Steve, you point out that PERT utilizes a 3-point estimate, but the issue is what does it _do_ with these three estimates.  It uses the well-known formula to produce a single number which is meant to represent the expected value (though it is only an approximation), and then uses this value as if it were a deterministic one.  In the symmetrical case, it is actually no different from a deterministic CPM using the middle value.  The main problem however is that it still considers only one path, and so does not take account of merge bias.  IMHO that makes a nonsense of PERT, which is why it was discredited ver shortly after it was first used in the 50’s.

For the dangers of using averages as if they were all you need to know, I recommend Sam Savage’s book, “The Flaw of Averages,” though this is not especially concerned with project management.

The problem of determining the correct distribution to use is a real one, but given that we have to make decisions in an uncertain world it seems to me that we have no choice but to try.  You are also correct to point out that there is a big difference between a triangular and a PERTbeta distribution with the same absolute end points, but there is very little difference between a triangular and a PERTbeta with the same standard deviation.  (The so-called Trigen distribution helps here, though it is really just a different way to specify a triangular distribution.)  There is quite a bit of empirical evidence in favor of the lognormal distribution.

I have not before come across the requirement to put distributions on lags, but there is no reason why it should not be done.  I will consider it for our next  release.  (Yes, I have an axe to grind, being the developer of Full Monte for MSP, see www.Barbecana.com)   It certainly is not a theoretical reason to object to MC. 

Finally, you say there is an attempt to make Schedule Risk Analysis synonymous with Monte Carlo simulation.   Since there is no other way to do schedule risk analysis  I would say that this is legitimate.

Emily;

Thanks.

Steve;

PERT provides a deterministic value [(O+4R+P)/6]=D.  Probalistic risk assessment (Monte Carlo) will randomly take a value from this range - O to P (PDF) each iteration, then group the results.  Using PERT will only give one outcome, though there is greater confidence in the choice of the activity duration.

Assigning a PDF can be relatively easy, if the underlying assumption is that most variability is in the unit rate of the individual crafts/disciplines (resource).  If this is true, then only one PDF needs to be determined for each resource and applied accordingly - this implies 100% correlation within the craft/discipline and single-resource activities.

Selecting curve shape is a bit more subjective.  For me, there are three relevant shapes - betaPERT, triangle, and trigen representing pessimitic, realistic, and optimistic biases on the part of the PDF 'determiner'.  I run all three and present the results with my recommendation.

Probalistic schedule risk assessment is not exact/perfect, but it is a giant step in the right direction.

FYI my assumptions are based on mid-stream and downstream oil and gas projects.