Sunday, December 19, 2010

Top 50 Industrial Engineering and Project Management Blogs

This is not my list, but we here at "Musings" made the list of 50 Industrial Engineering and Project Management blogs, actually placing 10th in the project management list, as complied by Masters of Engineering.com

And, I am happy to report that we are in good company with many blogs listed that we follow here.

Of course, in a list as long as 50 there's always something to discover.

One for me was under the category of Operations Research Blogs: arandomforest.com,  One blog on this site caught my eye: posted this past September, it is entitled "The Flaw of Averages and why everything is late" and refers to a book similarly titled: "The Flaw of Averages: Why We Underestimate Risk in the Face of Uncertainty" by Sam Savage.

Sam talks about the 7 Deadly Sins of Averages in his paper published in OR/MS Today from the Institute of Operations Research and the Management Sciences.
The Seven Deadly Sins of Averaging
1. The Family with 1 1/2 Children
2. Why Everything is Behind Schedule
4. The Risk of Ranking
5. Ignoring Restrictions
6. Ignoring Optionality
7. The Double Whammy

Of course for the risk astute project manager, "expected value" is the statistic of choice, not an arithmetic average. Expected value is a risk adjusted average of all the possibilities that go into an estimate. Thus, it is a richer piece of information, incorporating more of the information in the distribution of possibilities than just an average. Nevertheless, it does no harm to understand Savage's 7 points--just don't throw away useful information by not understanding expected value as well.

Bookmark this on Delicious

1. Suppose that a project consists of ten independent parallel tasks, each with an "Expected" duration of 6 months. Then the chance that the project will be done in 6 months is less than 1 in 1000. This is because the project does not end until the last of the ten tasks is done. The chance that the last of ten such tasks will take 6 months or less is the same as flipping ten head in a row on a coin.

Expected value is just a weighted average, and is subject to the same problems.

++Yes, I agree: your seven points are good ones that effect both arithemtic and statistical average, and that is one of the reasons I referenced your paper.

++ Your mathematics are correct, of course. If a risk manager estimated all 10 paths at the 50th percentile, and they are all planned to complete at a milestone or join together as a predecessor to a successor task, then yes: 0.5^10 = .0009+

++Of course, memoryless systems like dice are not really what we find in projects. There's no risk management to be applied to dice: they mindlessly obey the immutable laws of probability.

++Most risk managers would apply a skewed single mode distribution to a task estimation. One in common use is the exponential, the mean of which is about the 0.63 point, not 0.5 as in the dice game or a symmetrical distribution. In the exponential case, the 10 task joining successfully at 6 months is 0.63^10 = about 1/100, more or less. So a small shift in expected value is an order of magnitude change in success probability, thus the need to be careful with estimating probability. The DoD calls this hazard 'uncalibrated probabilities'

++Of course, if the 10 paths have several independent tasks in tandem, then the central limit theory begins to affect results, and the tendency is towards the 0.5 figure, so your 1/1000 is a point well taken.

++My coaching and writing on this topic puts a label on the phenomenon: merge bias or 'shift right' at the milestone. Take a look at this link for some more detail about how I apply this to project management: http://www.johngoodpasture.com/2009/10/ideas-for-managing-at-milestone.html

++My coaching emphasizes the expected value because it is a richer concept than average when applied to risk management and project management. Arithmetic average has it's place, of course, but it's a simple frequency weighting, and the weightings should not be confused with probabilities, which they are not. So, I coach that project managers should be concerned for the probabilities of the values in distribution because that is where in information is that tells managers whether or not so spend time and money on mitigation.

++Of course, in projects, few things are independent, as you point to in your example, so all this is about being 'close enough for project work'. Project schedules are very Bayesian