Before I write any further I would like to make it very clear that I do not advocate using this approach on each and every task or each and every project. Often it is not a challenge to identify what can be done, but the real challenge is to know what not to do and then not to do that. It is rather very difficult to resist the temptation of doing something that we can do. Particularly for the less experienced people, it is painfully difficult. For instance a new web designer wants to show all his creativity in the first web page that he is designing and makes a mess out of it. Although he thinks he has done a great job, it takes his team a great deal of effort to teach him what not to do rather than what to do. Therefore, please do only as much as adds value compared to the cost.

I would also like to say loud and clear that all risks are not mitigated. Further there is a tendency of taking negative risks or threats into account and ignoring the positive risks or opportunities. So much so that many people would argue that opportunity is not a risk. They would say it is a risk only if the affect is bad. That is not the case. There are positive risks called opportunities and not taking opportunities into account will result in loss of opportunity and would attract opportunity cost.

Therefore, our job is to decide whether to avoid, transfer, minimize or accept the threats and how to exploit, attract and maximize the opportunities. Cost is a big factor that very often makes it most viable to do nothing.

I would restrict this post to the risks at the work package level and the same approach can be extended to all levels.

For the risks at the work package level, contingency requirement must also be calculated at the work package level after the risk mitigation planning. However, the reserve is added to whole project or a phase. This reserve is directly proportional to the root of the sum of individual standard deviations and proportional to the function of confidence level required and normal distribution curve. Confidence level is a requirement that has to be defined. So next time when you are asked to prepare a schedule, please seek agreement on the confidence level, if you are not already doing so.

**Most of the projects fail to meet the schedule because most of the schedules are based on 50% confidence level. Therefore, 50% projects are scheduled to fail.**

Adding buffers in lump sum is a wrong approach. Though it might seem to work in some cases, it is very similar to the approach of "take your best guess and multiply it by two." I am denying the fact that, that approach might also be acceptable sometimes.

Coming back to the topic, this approach uses pert balanced average like most of the scheduling methodologies. However it does not use the weights of 1:4:1 that most of us are familiar with. It does not even use the same weights for all the tasks. That does not mean that MS project can't be used, though I will not cover that part in this post.

By the way, using the weights 1:4:1 is an assumption and taking the sixth part of the difference of optimistic value and pessimistic value as standard deviation is an approximation. The correct way is to base the weights on the actual probability and calculate the standard deviation using the formula that we were taught in school.

In this approach we do not consider the most optimistic, most likely and most pessimistic estimates, but we consider every possibility individually. After estimating duration for all the possibilities a task would take to complete, we find the actual balanced average based on the probability of each possibility and the actual standard deviation. We then find the project standard deviation and the sum of the balanced averages of the critical path tasks. Finally we can calculate the total duration and the contingency reserve based on the confidence level required. I think everybody knows that 100% confidence is neither mathematically possible nor logically. Generally 95% confidence is taken as acceptable, though it is highly industry, domain, organization and individual specific. By the way, we can do most of this work in MS Excel.

Although, only tasks on the critical path need to be considered, we must also check the near critical paths as sometimes after risk mitigation planning, critical paths change. Therefore, non-critical tasks can become critical tasks and vice versa.

Let me use an example to explain:

Let us assume we are working on a project with three tasks, say A, B and C with finish to start dependency. Which also means that all three tasks are on the critical path. Task A can be completed in 10 days. However there is 10% likelihood that a friend might lend his machine free of cost and the task can then be completed in just 5 days. There is also a 25% probability that another machine that we are supposed to receive might come late and might delay the task by another 10 days.

Based on the figures so far:

The correct balanced average is

m1 = ((10 * 5) + (65 * 10) + (25 * 20)) / 100 = 12 days

And the standard deviation

s1 = 4.87

Now suppose there is another risk that might happen and has a probability of 5% of happening. If this happens, it will take twenty days extra to fix the issue. Then:

Balanced average

m1 = 13

And standard deviation

s1 = 6.23

Suppose for task B:

Balanced mean, m2 = 15

Standard deviation, s2 = 5

And for task C:

Balanced mean, m3 = 20

Standard deviation, s3 = 2

From above figures, if the confidence level needed is 50% then

The total duration

D = m1 + m2 + m3 = 13 + 15 + 20 = 48 days

If we need a different confidence level then we need to calculate the project standard deviation:

Project standard deviation S = SQRT (s1^{2} + s2^{2} + s3^{2}) = 8.23

Suppose we need a confidence level of 90%, then from the cumulative (single tail) probabilities of the normal probability distribution we have

Z = 1.29

Buffer = 8.23 * 1.29 = 11 days

Total duration with 90% confidence = 59 days

Similarly we can calculate the buffer and total duration for other values of confidence level.

In conclusion I would like to remind that contingency reserve is not a piece of cake to be eaten at will; it has to be managed well and utilized only when needed. The whole idea of this approach as well as recommended by PMI is to remove the buffer from task or work package level and roll it up into a contingency reserve.

## No comments:

## Post a Comment