You may be a user of risk Probability-Impact Tables; after all they are one of the most popular risk management tools. But how do you bring the important risk factors of Complexity and Immaturity into your project risk management? You can do it the hard way, or:
: you can do it the easy way. A hard way can involve using the Risk Factor Equation, along with 5-7 weighting factors and a fair amount of computation. I have found that selecting the weighing factors seems to move me further away from the risk being managed than I would like. So, why don’t we take the easy way out?
We know that one function of the P x I (Probability times Impact) Table is to elevate and prioritize risks so high priority ones are sure to be actively managed. The same is true of the P x I x C x IM (Probability x Impact x Complexity x Immaturity). Let’s review a few terms first, and then define a few more:
PROBABILITY of risk occurring – P
Scale: 1-5
1 – Little
2 – Low
3 – Medium
4 – High
5 – Almost certain
IMPACT to the project objectives (schedule, etc.) if the risk occurs – I
Scale: 1-5
1 – Little
2 – Moderate
3 – Heavy
4 – Very Heavy
5 – Devastating
I recommend creating an impact table for your project. For example, ‘Heavy’ might be defined as a schedule or cost slip of 20%. So using a P x I Table a risk would range in value from 1 – 25. Now, let’s go on to Complexity and Immaturity:
COMPLEXITY – The number of items or components in a hardware or software sub-system: Number of lines of code, transistors, PCB square inches, web accesses per minute, database items, cohesive modules, interfaces, etc. It is strictly a ‘numbers’ thing. Complexity can and often does add risk.
Scale: 1 – 2
1- less than 2 times the item complexity on a past project
2 – double or more the item complexity on a past project
IMMATURITY – How new or innovative is the project item? If it has never been done before on a project in the company, it could significantly increase the risk.
Scale 1 – 2
1 – about the same level of innovation as on a past project
2 – new innovation, such as having not been done on a project before
So, let’s look at an example: A quad core microprocessor, with novel power management circuitry. A schedule risk with P = 3 and I = 4 could be evaluated as follows: Schedule Risk = P x I x C x IM = 3 x 4 x 2 x 2 = 48
For Complexity, 2 was chosen due to 4 cores versus 1 or 2.
For Impact, 2 was chosen due to the new power management circuitry.
A risk rated at 48 will definitely have an elevated priority, and so it will be dealt with early. Note that with using these scales, a risk will have a priority rating of scale of 1 – 100. So, I challenge you to give this risk management approach a try on your project. Please watch for my next 2 blogs this week,
Jeff
[email protected]
©2008 Jeff Schlageter
If I read your question right, you are saying their might be the possibility of under-representing the highest risks? I’m not sure how if they are all being weighed using the same criteria?
The thresholds are just within the 1-5 range instead of 1-100 as in your system, and it does come out differently when you do the math….potatoe, potato?
Example where P=2, I=3, C=1, IM=2
Jeff’s system:
=P*I*C*IM
=2*3*1*2
=12 out of 100
Josh’s system:
=((P*5)+(I*5)+(C*2)+(IM*2))/14
=((2*5)+(3*5)+(1*2)+(2*2))/14
=2.21 out of 5
Josh Nankivel
pmStudent.com
Hi Josh,
It’s good to consider risk on all of your important project factors. When you do your averaging, how do you avoid reducing high risks to a level below the threshold of active risk mitigation,
Jeff
Good stuff. You could also add other factors that are relevant to your industry. We use 4 factors on my current project, and do an average of them.
Josh Nankivel
pmStudent.com