Project Risk Management is one of the meatier knowledge areas found in the Guide to the Project Management Body of Knowledge (PMBOK^® Guide). Anyone who is a Certified Associate in Project Management (CAPM)^® or a Project Management Professional (PMP)^® will remember wrestling with identifying risks, analysing them and coming up with appropriate risk responses.

On this page:

• Analyzing Project Risks: Challenges in Probability and Impact Assessment
• The Vagueness of Impact Assessment: Interpreting High, Medium, and Low Impacts
• Evaluating Risks in Context: Project-Specific Probability and Impact Assessment

Analyzing Project Risks: Challenges in Probability and Impact Assessment

In an earlier article we covered how to go about identifying risks, but a major hurdle for Project Managers is analysing the risks they identify. We are supposed to rank risks in terms of probability of occurrence and severity of impact if they do occur. We also have clever strategies to ensure that unlikely risks with major impacts, or highly probable risks with low impacts, are not forgotten. But they do not help us decide if a particular risk should be rated in a particular way.

Probability and impact criteria are normally divided up into high, medium and low. Some organizations use a 1 to 10 scale with very specific meanings for each rating. For instance, an impact of 8 means that there will be a major impact on project schedule, budget or performance, whereas an impact of 7 means that the project schedule, budget or performance will be impacted significantly. How do you distinguish between major and significant? Both terms are quite vague, so there is scope for disagreement among the team during analysis.

The 1 to 10 scale for probability is more precise – an 8 here means a 1 in 8 chance, while a 7 is a 1 in 20 probability. Unless the Project Manager also moonlights as a bookie, it is unlikely that s/he will be able to access risk at this level.

On balance, the high, medium and low triage is a better option. It is better to be openly vague, than to be spuriously precise. But even high, medium and low are not totally straightforward. Again, the probability breakdown is the easier to understand. A highly probable event is one that is almost guaranteed to happen; a low probability is one that most likely will not happen, while a medium-level probability is an even-money bet.

The Vagueness of Impact Assessment: Interpreting High, Medium, and Low Impacts

However, the impact breakdown is a bit more difficult. What constitutes a high-impact? Is this something that could cause the project to be cancelled? Or should it be something that affects only one of our triple constraints? How about a medium impact? Would this be a delay in a delivery or an activity taking longer than expected? A low impact could be defined as something that does not affect the overall schedule, budget or performance. However, an issue could have a low impact if it relates to something that is off the critical path, while the same risk could be a medium (or even a high) impact if it occurs to a critical path activity.

If Project Managers, as a species, tend to be paranoid, it is probably due to analysing risks. Take, for example, the risk of fire. What is the likelihood of a fire occurring that will affect the project team’s work? The Project Manager might look at the organization’s history and decide that, because there has never been a fire in the building before, the likelihood of a fire occurring during the project is low. The Project Management Institute would approve of this use of historical data. However, if the facility is an old building, is not the likelihood of fire increasing with each passing year? Are not the wires getting old, their insulation breaking down? Should we have a review of building safety before deciding?

The fire example is a good one when deciding what to do about the risk. As an example, if a fire occurs in a software development facility, the most likely impact will be a loss of data. Using off-site back-ups, or even cloud solutions, will take care of that (accepting the risk). Damage to computer equipment can be covered with insurance (transferring risk). If the office is burned down, the team can be relocated without too much difficulty. Of course, fire safety must be considered to make sure the team evacuates without incident if the fire occurs during office hours.

So, for a software development team, a fire is a low probability / medium impact. However, a chemistry lab fire could be a catastrophic event, with very expensive, highly specialized equipment being in danger. Simply compare the number of fire extinguishers in a chemistry lab to that of a typical office. Also, compare the safety regulations for labs versus offices. However, the risk (fire) is the same.

Evaluating Risks in Context: Project-Specific Probability and Impact Assessment

At the end of the day, the Project Manager (with the help of the project team) needs to assess probability and impact in the context of this particular project. Although the insurance industry assesses risks in order to determine its premia, it averages risk across a sector. Because you are the Project Manager on a single project means that you will not be able to do that. In principle, this means that your assessments will be much more accurate in terms of your project. So, even if standard risk assessments are available to you, be sure to filter them through the prism of your temporary endeavour to create a unique product, service or result.

Project Risk Management is covered in all Velopi’s project management courses, from our one-day introduction to our full PMP^® exam preparation offerings. Please visit our training page or contact us directly for more details.