More discussion on LinkedIn about risk, risk management, types of risk, and definitions of risk and opportunity. The "risk management" community in the domains I work is based on Department of Defense, Department of Energy, Department of Homeland Security, NASA, ITIL, AACEI (Association for the Advancement of Cost Engineering International), Nuclear Regulatory Commission, INCOSE (International Council of Systems Engineering), OGC Management of Risk, GAO, and Deloitte's Risk Management Framework.

Several core concepts get confused. So before taking any deep dive into "managing risk," these need to be established.

**What is Risk**

There are many definitions of risk from a variety of sources. In the end these definitions are all pretty much the same.

- Risk involves the probability of something happening in the future.
- When that something happens it impacts the project in ways that are not good.
- There can be a probability of the effect of the impact as well.
- Handling the risk means knowing what kind of risk it is, and what the choices are for handling the risk.

Here's a good definition that can be used in probably any domain.

Risk refers to the uncertainty that surrounds future events and outcomes. It is the expression of the likelihood(probability of occurrence)and(probability of)impact of an event with the potential to influence the achievement of an organization’s objectives. -Managing Risk in Government: An Introduction to Enterprise Risk Management, IBM Center for The Business of Government.

I've *edited* this a bit to remove the *likelihood* measure and replace it with the *probability* just to keep the math straight. You'll see why below when it comes to *ordinal* values in the *risk matrix* - a bad idea.

There is a *time honored* approach to *ranking *a risk, by calculating some number. This number is meanigless of course, because it has no scale, it is just a *ordinal* number. We need *cardinal* numbers for actual risk management.

Risk = Probability of Occurrence x Impact

This is a trick question. The risk matrix approach that results from this calculation treats these numbers as *likelihood* not probabilities. But in fact they are probabilities. As well they are *Ordinal* numbers (1, 2, 3, 4, 5 usually) and as such represents the *relative* ranking of the *likelihood* of occurrence, not the actual *probability* of occurrence.

This approach starts with a major problem - a *show stopper problem*. The two values on either side of the multiplication sign are probability distributions, not real numbers. There is no *MULTIPLY* operator between two probability distributions. The is the CONVOLUTION operator, but that is not likely to be of much value to ordinary project management staff. One starting point for a better understanding of the problems with the risk multiplier and *risk matrix* approach is the work of Tony Cox. Optimal Design of Qualitative
Risk Matrices to Classify
Quantitative Risks. Tony's source paper provides the basis for this discussion, "What's Wrong with Risk Matricies."

To put it in blunt terms.

The combination of Ordinal Scales and Risk Matricies are Fatally Flawed

In this link, it is stated again, so I'll restate it here

It is a category mistake to multipy ordinal numbers

By category error it means the *objects*, the *categories*, do not have the proper properties to work with the *operators*. For some more discussion of this topic and a bit of *counter discussion*, see What's Right with Risk Matricies.

**Where does risk come from?**

Risk comes from uncertainty. There are two kinds of uncertainty.

- Uncertainty that can be
- reducible uncertainty. This is called**reduced***epistemic*uncertainty. This uncertainty is characterized by the lack of knowledge. We can*buy*this knowledge. - Uncertainty that
- irreducaable uncertainty. This is called**cannot be reduced***aleatory*uncertainty. This uncertainty is an inherent variability in the project processes and characterized by a probability distribution. We can not*buy*more information about this uncertainty.

The critical point here is the *reducibility *and the *irreducibility* of these uncertainties.

- If the uncertainty is irreducible, then only
*margin*can be used to protect the project from the risk. This is scehdule margin, cost margin, techncial performance margin. - If the uncertainty is reducible, then we can
*buy down*the uncertainty and therefore*buy down*the risk. That is we can spend more to find out more information - increase our knowledge. This is done in one of two ways:- Spend money in the project to increase our knowledge.
- Provide a
*Management Reserve*or*Contingency*to handle the risk when it comes true.

**How is Risk Maanged?**

We must start with a risk management process. There are several, but they are essentially the same. Here's my favorite, there are others of course, but this one covers all the steps.

- There is no need to make up definitions for risk and risk management. There are plenty around and all of them are
*in use*on actual projects by actual project and program managers, managing risks every day. Providing your own definitions, is sporty at best. At worst, it shows you haven't done your homework. - Uncertainty is the source of risk. There are two types of uncertainty - reducible,
*epistemic*and irreducible,*aleatory*. If you do not separate these two, you cannot credibly have a risk handling plan. If you do not have a credible handling plan, then you're not actually*managing*risk. *Ordinal*numbers cannot be used to make risk decisions.*Cardinal*numbers are needed. No ranking likelihood of occurrence as 1,2,3,4,5. Not allowed, it's bogus. Same for impact. Bogus. And certainly no multiplying those two, even more bogus.*Risk Management is How Adults Manage Projects*- Tim Lister