The solution to this question is simple but complex….

There is a 1 in 10 chance the ‘Go Live’ date will be delayed by Project 1

There is a 1 in 10 chance the ‘Go Live’ date will be delayed by Project 2

There is a 2 in 10 chance the ‘Go Live’ date will be delayed by Project 3

What is the probability of going live on March 1st?

To understand this problem let’s look at the role of dice:

If role the dice and get a 1 the project is delayed, any other number it is on time or early.

If you role 1 dice, the probability is 1 in 6 it will land on 1 = 0.1666 or 16.66% therefore there is a 100 – 16.66 = 83.34% probability of success.

Similarly, if you roll 2 dice, there are 36 possible combinations, and the possibilities of losing are: 1:1, 1:2, 1:3, 1:4, 1:5, 1:6, 6:1, 5:1, 4:1, 3:1, 2:1. (11 possibilities)

The way this is calculated (in preference to using the graphic) is to take the number of ways a single die will NOT show a 1 when rolled (five) and multiply this by the number of ways the second die will NOT show a 1 when rolled. (Also five.) 5 x 5 = 25. Subtract this from the total number of ways two dice can appear (36) and we have our answer…eleven.

(source: http://www.edcollins.com/backgammon/diceprob.htm)

Therefore the probability of rolling a 1 and being late are 11/36 = 0.3055 or 30.55%, therefore the probability of success is 100 – 30.55 = 69.45% probability of being on time.

If we roll 3 dice we can extend the calculation above as follows:

The number of possible outcomes are 6 x 6 x 6 = 216

The number of ways not to show a 1 are 5 x 5 x 5 = 125

Meaning there are 216 combinations and there are 125 ways of NOT rolling a 1

leaving 216 – 125 = 91 possibilities of rolling a 1

(or you can do it the hard way: 1:1:1, 1:1:2, 1:1:3, etc.)

91/216 = 0.4213 or 42.13% probability of failure therefore there is a

100 – 42.13 = 57.87% probability of success.

So going back to the original problem:

Project 1 has a 1 in 10 chance of causing a delay

Project 2 has a 1 in 10 chance of causing a delay

Project 3 has a 1 in 5 chance of causing a delay

There are 10 x 10 x 5 = 500 possible outcomes and within this 9 x 9 x 4 = 324 ways of not being late. 500 – 324 leaves 176 ways of being late. 176/500 = 0.352 or a 35.2% probability of not making the ‘Go Live’ date.

Or a 100 – 35.2 = 64.8% probability of being on time.

The quicker way to calculate this is simply to multiply the probabilities together:

0.9 x 0.9 x 0.8 = 64.8%

These calculations have been added to our White Paper on * Probability*.

I have a little spreadsheet which allows you to see the effect of any number of parallel dice rolls (the result of 11 out of 36 can be generalized to (6^N – 5^N) / 6^N where N is the number of dice. I use this to d demonstrate merge bias. Also have a program that simulates the dice throwing to show that if you do enough trials you get the same answer. Both can be downloaded from http://www.barbecana.com.

The last equation is correct 0.9 x 0.9 x 0.8 = 64.8%. But not for the reasons you provide. The 1 in 10 chance is a binomial distribution. Either you finish on time or you don’t. When all three have to finish in time the Joint Probability can be multiplied.

But here’s the rub, you can’t tell from just the “point estimates” if all three project have a concurrent probability of completing. a “1 in 10” chance for a single project says there is a 90% confidence of completing on or before the planned date. But once you put 2 or more projects in parallel, you’ve created a “joint conditional” probability distribution requires knowledge of the underlying PDFs before we can say what the Joint PDF will be.

I’ve an email with the Joint Confidence Level picture for cost and schedule. A similar chart would be formed by the triple projects. Multiplying the probability of completion provides an approximate outcome, but convolution of the underlying distributions is needed for any confidence in that outcome. http://goo.gl/Z9H3r speaks to performing arithmetic on random variable distributions.

But certaintly the equation at the end gives you the “worse” case for all three completing on time for the final outcome. Can’t go wrong with that number. Now what decisions can be made to protect the final deliverable requires understanding of the statistical behaviour of all three projects and their possible interactions, since the arithmetic process assumes identical independent random variance.

BTW, these types of discussions rarely take place outside of project and programs where people die by accident or on purpose, so we shouldn’t be surprise when IT and other less critical projects show up late and over budget.

Agree for the ‘real world’, but the starting point was an exam question and one key presumption for dealing with information in questions is the data provided is correct.

Pat,

I wounder if the exam question writers understand how naive of questions they are writing?

I would not like to attempt ascribe a probability to the proposition 🙂

But in the Bayesian Inference paradigm, they’ve got a 50 / 50 chance ;>)

Tony, The interesting thing about merge bias it that is existence has no clear alternative, simply awareness the the need for schedule margin protect.

Serializing the work to avoid merge bias, without changing the work load may not be possible. Serializing the work, may not result in on time performance.

Merge Bias is part of the programmatic risk assessment and modeled in all Monte Carlo Simulation tools. What is needed is sufficient schedule margin tasks to protect the deliverable to the right of the “merge point.” This margin can be determine using any Monte Carlo tool, and is encouraged to be done in DI-MGMT-81861

Yes, Glen. My product, Full Monte, calculates a value “Merge Bias delay” which is the expected value of the expected value of the early start and the maximum expected value of the early finishes of the predecessors (having due regard to lags, calendars and such). The average of the function is not the function of the average!

Tony,

Thanks. For some good background on the Sum of the Means, not being the Mean of the Sum, see Stephen Book’s work from awhile ago. http://www.slideshare.net/NASAPMC/stephenbook

And for interested in the details of this important area (cost, schedule, technical and risk integration), the Journal of Cost Analysis and Parametrics is one place to start.

As well Goggle will find you most the Book’s work which was developed at MCR for the Space and Missile Systems Command.

One of the many tools we use when cost and schedule models are both needed is Crystal Ball. A colleague (David Hulett) has many straight forward papers on this topic. Here is one http://goo.gl/onspf

Pingback: Risks don’t add up - PMLinks.com