Understanding and applying risk management frameworks to project management

June 02, 2021 | 0.25 PDUs

Risk management is an often-misunderstood topic. This is true when dealing with any kind of risk—from risk to personal safety to project management risk. Let’s dive into why we are so bad at understanding risk and how we can use risk management frameworks to truly assess, understand, and manage the risk associated with our projects.

Why is risk so unintuitive?

Risk is unintuitive for people because we’re pretty risk-averse in general. If you think about it, this is an evolutionary advantage: the fewer risks we take, the more likely we are to survive. While Darwin might appreciate our aversion to risk, it isn’t always helpful in the project management world—risk is guaranteed with every endeavor, so we must strive to understand it and, if necessary, mitigate it.

The illusion of control: fear of flying vs. comfort driving

It’s extremely common for people to fear flying. We have seen instances in which planes crash and people die and we have absolutely no control. But in reality, the probability of perishing in a plane crash is extremely low (about 1 in 110 million). On the other hand, the odds of dying in a car crash is closer to 1 in 100! Despite tremendously larger odds of dying in a car crash, we rarely hear of a fear of driving. This exposes the illusion we tend to have that our being in control of the vehicle has some impact on the risk of its operation. This is of course untrue, as exemplified by the statistics!

We don’t understand probability

We are simply pretty bad at understanding probability. This is especially true for rare events: it’s really hard to fathom what one in a million really looks like. This can be demonstrated by the lottery systems many of us buy in to: the odds of winning a substantial amount of money are astronomically low (you’re usually more likey to die in a plane crash) yet we throw quite a bit of hard-earned money trying to hit the jackpot.

Risk management frameworks

Our poor understanding of risk was the bad news. The good news is many folks understand how poorly we understand risk, and have in turn created risk management frameworks. Risk management frameworks provide a repeatable process for identifying, assessing and, as necessary, mitigating risk.

Describing the system

Often, risk management processes start out by asking you to identify the system you’re working in. Importantly, you describe what’s inside and what’s outside the boundaries of the system—you can’t account for every risk in the universe!

Identifying risk

Having an accounting of your system is helpful when trying to identify risk. Risk identification often comes in the form of a risk register, and is generated through ideation sessions like brainstorming.

Identifying existing controls

All of the risks you identify likely have controls in place. For example, one risk might be that your project depends of software development expertise and you only have one software developer on the team. However, your risk is mitigated because your company has a bench of software development talent from which you can pull. This is a control that’s already in place and will reduce the likelihood of your risk.

Quantifying severity

Once we have identified existing controls, we should quantify the severity of our risk. Generally, risk frameworks will have guidelines for how exactly this quantification works. For example, there might be a five point scale, 1 being the lowest risk and 5 being the highest risk. An example of a (1) is an event that displeases a minor stakeholder. An example of a (5) is an event that causes project failure.

Quantifying probability

Next up, we would quantify the probability of our risk happening. Again, there would be guidelines within the risk framework for this quantification. Sometimes, this can be an actual probability number (e.g., the probability of a part failure is 1E-7), but often we have to be a bit more qualitative (e.g., there is a 10% chance we lose our software developer before the end of the project).

Many risk management frameworks will have you quantify probability using the same scale as severity. In our example, we might therefore end up with a scale from 1 through 5 with 1 being very unlikely and 5 being almost certain to happen.

Calculating risk

Once you have an initial severity and probability, you can calculate risk. Risk is the product of severity and probability.

risk = severity x probability

Some examples of quantified risk:

  • risk = severity (2) x probability (4) = 8
  • risk = severity (5) x probability (5) = 25

The higher the risk score, the riskier! Once you have a score, you can usually plot it on a risk matrix. Risk matrices usually assign a high/medium/low categorization to risk based on its score. In our examples, a score of 25 is most certainly a high risk (the highest in fact) whereas a risk score of 8 is either medium or low.

The following image gives an example of what a risk matrix usually looks like.

Example risk matrix

If our risk lands in the red, it’s a high risk. Some frameworks dictate that this must be mitigated. if our risk lands in the yellow, it’s a medium risk. We should probably still mitigate this risk, but it’s less urgent. Finally, if our risk lands in the green, it’s a low risk. We probably don’t need to mitigate these.

Mitigate risk

Now that we have a quantification for all of our identified risks, we should mitigate our high risks (and possibly medium risks). We discussed earlier about the example of needing software development expertise—one mitigation would be to eliminate our single point of failure by obtaining additional software development support personnel. This would significantly reduce the likelihood that our team loses this critical expertise.

Through ideation techniques like brainstorming, you should come up with mitigations for all high risks. Once this is done, you can move forward.

Reassess risk

You can now reassess your risk. It’s possible that mitigations reduced the severity of, or even eliminated, some risk! It’s more likely, however, that your mitigations reduced the probability of your risks occurring. This is still great—whether you reduce the likelihood or severity is somewhat immaterial, you have reduced your risk.

Monitor risks

All of the assessment we have done so far is theoretical. We should not assume that our assessment of risk was perfect, nor should we assume it won’t change. We need a plan to periodically check in on the status of our risks throughout the project. If some risks are sufficiently large, we may even have stakeholders that require updates on the status of certain risks.

Conclusion

As with a lot of project management work, it’s important to document your findings and decisions. This is typically done in the risk register. The risk register can become a security blanket of sorts: if you get really good at uncovering and documenting your risks, you can set a lot of fear aside as you move through your project. You performed a dedicated assessment of the risks associated with your project and you have mitigations and monitoring in place. Good work!


Welcome to PMKnowledge.org! Here you will find articles about various project management topics. Each article lists a number of Professional Development Units (PDUs) you can earn by reading the article based on the average reading time of that article.

© 2021, PMKnowledge.org