How to Quantify Risks and Prioritize Mitigation Strategies

We’ve all been there. An adverse event occurs, impacting the results of our project. We usually have two initial response options; “I should have known!” or “How the h*ll did that happen?!”

Regardless of your initial response, there’s way to improve your response and minimize the impact. Risk Tracking as a whole comprises of multiple steps in an interactive and repetitive process flow. Initiating Risk Tracking starts with a Risk Identification based on the scope included in the project, program and included departments. Risks identified outside of these elements can be identified, may be monitored, but will not be part of the mitigation strategies.

The down and dirty breakdown:

1. What could go wrong?
2. How likely is this occurrence?
3. What is the Impact to project success if it does occur?

When thinking about question 1 – What could go wrong? You may have quite the extensive list, but we know monitoring and mitigating every identified risk is a burden no one wants to, or even can take on.  We can look at Risk Management the same way we look at our roles and responsibilities at work and life. If you take on too much, spread yourself too thin, you risk careless mistakes and missing the fine details, regardless of the task. This is the same with Risk Management, and not having a strategic focus on what matters most, limits your ability to recognize when things are starting to go wrong. Which leads us to Question 2…

How likely is this occurrence? going down your identified list of risks, are they likely to occur every day? Once in a blue moon? At the performance of specific tasks only? Establish a criteria for likelihood of occurrence.  You can choose, based on the project needs and timeline, if you want to identify risks likelihood by days, weeks and months, or % chance.  Once we know our determining factor for likeliness of occurrence, I like to give it ranks of 1 through 4. 1 being the lowest category, and 5 being the highest.  The caveat here; just because something has a risk occurrence of 1, doesn’t mean you won’t create a mitigation strategy for it. In fact, you may create a mitigation strategy for a risk with an occurrence rating of 2 but not create a mitigation strategy for one with a rating of 3.  Sounds counter-intuitive, right? So, let’s look at Question 3.

What is the impact to Project success if the risk does indeed occur?

Using a similar rating structure from question 2, create a criteria for the impact to the project. Before we quantify this segment, lets dive into a few examples.

Example 1 –

In a Pharmaceutical Manufacturing Facility, the identified risk is product mis-labeling. As a batch of product is processed through the filling suite, it enters a visual inspection line, and after passing visual inspection, proceeds to receiving individual product labeling, packaging and bulk labels. The risk of mis-labeling is considered a low likelihood of occurrence, but what happens if it does occur?

Consider a facility that produces morphine for intravenous pain relief, and also produces Vitamin K for newborn administration. Both are clear liquid with no color indicators. Mislabeling the Vitamin K would not be abhorrent, but mislabeling the morphine would surely result in infant death if not caught.

Example 2 –

A construction project has an identified risk of dropped tools or supplies. This presents a safety risk of collision with a worker at the site.  Tools are stored in buckets, on belts, and held in hands. While walking up the stairs, up the scaffold, or across the roof or mezzanine, these tools pose a severe safety hazard to anyone below.

Example 3 –

Software developers fail to document decisions made and progress throughout their testing phase. While they may reach success as an end results, they do not fully document and therefore cannot reproduce the results on repeat efforts.

Depending on what the software is used for, the critical timelines leading to success, or even if regulatory requirements need to be met, such as using software for filing results of a clinical trial, these missing data points can create repeat work and delay completion.

Lets quantify these examples.

Example 1 has a low chance of occurring (lets say risk category 1) but a substantial impact (risk category 5) – Following the risk to impact table below, this is a medium categorization. By default, since this risk can result in deaths, it is immediately escalate to a Critical-risk category (think 5 and 5).

Example 2 has a medium chance of occurring (risk category 3) and a low to medium impact ( the higher the elevation, the greater the potential impact). Following a 3 for chance, and a 3-4 for impact, this falls within a medium-risk category (3 and 3 for the purposes of this article).

Example 3 has a low chance of occurrence when developers are following basic documentation standards, and has a low project impact (say 2 and 2), leading to a low-risk category.

Green = Low Risk

Yellow = Medium Risk

Orange =  High Risk

Red = Critical Risk

*The higher the risk proportionate number, the higher priority your mitigation strategy must be

 

Before starting any project, brainstorm a list of risks.

Identify scenarios where that risk could occur and define:

• Likelihood of the risk occurring
• Impact the risk could have on your project, or end users

What risks have you recently identified in your projects? Please leave comments in the post and lets discuss!