A New Approach to Qualitative Risk Management

This week’s Sidewise Thinking post is hardcore project management, for those of you who are interested in that sort of thing. The chart and approach to qualitative risk analysis comes from my recent AMACOM self-study sourcebook, Project Risk and Cost Analysis, but the words are original to this blog piece.

Qualitative risk analysis as expressed in the PMBOK® Guide has always given me a headache. The definition is confusing and badly written. That’s not just my opinion, it’s the common experience of lots of people taking project management seminars. (Certainly it's true of my seminars, but I’ve seen many other trainers struggle with this as well.) The problem isn’t with the individual tools. They are easy enough to understand and apply, and the utility is reasonably obvious. But when you look at the similarities and difference between qualitative and quantitative risk analysis using the official PMBOK® (11.3, 11.4) definitions, some problems arise.

·      Qualitative risk analysis is the process of prioritizing risks for further analysis by assessing and combining their probability of occurrence and impact.

·      Quantitative risk analysis is the process of numerically analyzing the effect of identified risks on overall project objectives.

When people first encounter this, the response is a great big "Huh?" I don't really blame them. Here's why.

To see the problem in PMBOK, start with the most obvious difference between the two types: quantitative risk analysis uses numbers and qualitative risk analysis uses "prioritization." In practice, these amount to the very same thing.

How do you value a risk? According to the book, you multiply its probability of occurrence by the impact should it occur, expressed by the formula R = P x I. For example, a ten percent risk of losing a thousand dollars turns into 0.1 x $1,000, or $100. If the cost of dealing with that risk is less than $100, it’s clearly a good investment. (It’s always worth noting that the reverse isn’t necessarily true. Spending more than $100 may well be a good idea, but you may have to prove it.) That's the quantitative way.

In the qualitative approach, according to PMBOK, you might say the probability is LOW and the impact is, say, MEDIUM (depends on the size of the project). You look on a grid to see where the terms intersect (usually LOW). But that's the same thing as saying LOW x MEDIUM = LOW, or P x I again.

In other words, the “numerical analysis of effect” and “combined probability and impact” are, for all practical purposes, synonyms — the very definition of risk says so. That creates a lot of blurring between the two processes, especially in terms of their utility. No matter which technique you use, you end up with a priority ranking of your project’s risks. (You also get analytical data about those risks.) Then you move on to risk response planning.

Prioritizing risks gives you only a two-dimensional sort: higher or lower. That’s quantitative risk analysis — whether you use actual dollars and percents, or whether you use a scale of high, medium, and low. You rank the risks into a numerical hierarchy. And that's it.

Prioritizing risks isn't nearly all you need to be doing. In this post, I want to give you a new way to think the two kinds of risk analysis.

You need to organize your list of identified risks in three dimensions, based on the initial choices you must make. Some risks require more rapid response than others, severity notwithstanding. Some risks affect the project but aren’t yours: they may belong to the customer, your boss, or other departments in the organization. If you’re running an IT project and you identify legal risks, you probably should route those risks to the general counsel rather than deal with them yourself. Some risks have solutions — and others have no solution at all.

Using the accompanying chart, let’s look at those choices.

IMPACT: The first gateway is to examine a risk’s impact. Forget probability: if the impact is low enough, you’re done with the risk. If the cost of the risk if $50 and the project is $5 billion, it’s irrelevant whether it happens or not. Granted, first impressions can be deceiving and the impact of a given risk can change over the lifespan of the project, so you don’t want to throw this list away.

PROBABILITY: Only then should you think about the probability of occurrence. If you are lucky enough to have real numbers, good for you. More often, you’ve got a vague idea (it’s pretty likely to happen, or maybe it’s very unlikely) or you don’t have any idea at all about the probability.

Here’s where you deal with the R = P x I formula, whether you’re using 0.1 x $1000 or a high, medium, and low scale from a table (Low x Medium = Low). And yes, when determining impact, you have to extend your vision from the impact on the work package to the impact on the project as a whole, and from there to the impact on outside people and organizations.

At the end, you put more risks on the parking lot. Perhaps the impact is serious enough to be noticed, but the probability is ridiculously remote. You make sure that the risks that get further action are the ones with the highest net value.

According to PMBOK, you're done — but you aren't.

URGENCY: Risk responses follow the Godzilla Principle: baby problems are easier to deal with than full-grown problems. The available set of responses to a given risk tends to deteriorate over time. Even if some risks have higher value, you need to move urgent risks to the front of the queue. It’s less important whether the risk event is coming up soon; the key question is when your solutions expire. So we’ve already violated the priority order we established in the previous step — another tip-off that prioritizing risks by probability and impact isn’t nearly enough to do the job.

OWNERSHIP: If there’s no reason for a risk to jump to the head of the line, we go back to the prioritized list of risks, but with another question: do these risks fall under the jurisdiction of the project manager or team? As we noted, legal risks usually belong to the legal department, rather than, say, IT. Other risks may fall generally into our project, but if the impact is great enough, higher levels of the chain of command usually get the final say-so.

Transferring risk, in other words, often doesn’t wait until risk response planning — when we need to pass the buck, we pass it early in the process. Of course, we’re often responsible for providing information and options to the people who own the decision, and sometimes responsible for implementing the solutions they devise, but the key question of ownership has already been settled.

ACTIONABLE: Our remaining pile of risks shrinks with each step, but before we start on the process of planning our risk responses, there’s still one more sort that needs to be done. Do these risks have answers? In other words, can we find a potential proportionate and cost-effective response to the risk that doesn’t create serious negative consequences as a side effect?

If the answer is yes, we have our tentative risk solution. We accept the risk and move forward to risk response planning.

ACCEPTABLE: If the answer is no, we have a decision to make. We can decide to accept the risk

Maybe we add something to the contingency allowance for dollars or time. Maybe we come up with a recovery plan. But either way, we move forward.

But if the risk is too serious, moving forward may be a very bad idea indeed. We have to re-think the project. Maybe we modify it. Maybe we cancel it. Either way, we’re no longer going ahead with the original vision.

* * *

No matter what approach we use, we plan risk responses for some risks, but not all of them. In the PMBOK model, we plan risk responses based on the priority of the risk. As you’ve seen, however, that’s not enough. Think of qualitative risk analysis as the overall process of sorting risks not merely by P x I, but by the nature of the initial actions you should take.

     Is it SERIOUS? If not, accept it.

     Is it LIKELY? If not, accept it.

     Is it URGENT? If it is, act on it now.

     Is it MINE? If not, transfer it.

     Is it ACTIONABLE? If so, act on it.

     If not, is it ACCEPTABLE? If not, rethink the project.