How to Actually Define Risk Categories

Tom is the program manager for a large, complex program comprised of eight projects. He thinks his project managers have identified most of their risks, but he’s not sure where to focus his attention. What areas have the highest risk exposure? Let’s look at how to actually define risk categories and how they can help Tom (and you).

a hierarchy chart representing risk categories

What are Risk Categories?

Risk categories allow you to group individual project risks for evaluating and responding to risks.

Project managers often use a common set of project risk categories: schedule, cost, quality, and scope. But project managers may use other categories.

Imagine a project manager who is managing a software development project. She may use these categories: requirements, design, coding, testing, and implementation.

Another set of categories is called PESTLE: political, economic, social, technological, legal, and environmental, which is often used as a prompt list for identifying risks.

Your risk categories should be included in your risk management plan. Project managers should also include the categories in their risk registers.

Why Use Risk Categories?

Putting risks in categories can help in several ways. First, you can better determine where your concentrations of risks are greatest.

Second, it allows you to identify common causes. Project managers often identify different risks that have the same causes.

Third, you can develop better risk responses. Because you can better see the common causes, you can zero in on the most powerful and common causes and manage them.

Risk categories are more meaningful when you perform a quantitative risk analysis resulting in quantified risk exposures (e.g., $20,000). While quantitative risk analysis takes more time than the qualitative risk analysis, it provides a deeper understanding of the individual risks as well as the overall project risk exposures.

If you have performed quantitative risk analysis, you can sum and compare the total exposures within each risk category. You could even create a pie chart to illustrate the concentrations of risks.

How to Define Risk Categories

Check your organizational process assets to determine if your organization has a standard set of risk categories that might be applicable to your project.

Your PMO may also have a standard risk breakdown structure (RBS) that provides categories and sub-categories of project risks. Click here to see an article by Dr. David Hillson on this topic.

Perhaps there are no organizational assets and you are managing a project, unlike anything you’ve managed before. One effective method for defining your risk categories is the Affinity Map method. You can use this technique to identify risks, place them into logical groups, and then name each group/category.

Join the 21 Day Challenge

Receive daily emails--learn to identify, evaluate, respond to, and control project risks.

Spend five minutes per day for 21 days--discover practical risk management techniques that can help you turn uncertainty into success!

Powered by ConvertKit

Please note: I reserve the right to delete comments that are offensive or off-topic.

2 thoughts on “How to Actually Define Risk Categories

  1. Harry,
    Nice Blog. In our space and defense domain, risk management is a critical success factor.
    In this domain, risk comes from Uncertainty and Uncertainty has two types
    ▪︎ Reducible uncertainty (Epistemic) that comes from “event-based” activities. This has a probability of occurrence, some probability of impact, and when reduced, some probability that the residual risk is still there. Handling of the risk from reducible uncertainty requires some specific work effort which can also include ignoring the risk.
    ▪︎ Irreducible uncertainty (Aleatory) that comes from the naturally occurring process of the project. Work effort durations are the primary example, but there are others. Handling the risk from irreducible uncertainty can only be done with “margin.” Schedule margin, cost margin, technical performance margin.

    Here’s some background on how we “manage risk” in our domain

Comments are closed.