What is a Risk?

These next few weeks I will be sharing thoughts about Project Risk Management. 

In my training experience, I find that most people know what risk management is, but many people struggle with identifying risks.  Often, people create a list of risks that includes things like “The infrastructure is outdated,” or “We aren’t sure how much Sam will be available for the project.” 

These are certainly concerns that we should be thinking about, but are they risks? I would suggest that no, they aren’t.  The first one is simply a statement of fact; the second one is an uncertainty.  Risks may derive from circumstances or uncertainties like these, but the most effective way to articulate a risk is to express it as an event.  It’s something that could happen. 

Why does it matter?  The importance of articulating risks as events comes into play when we get to quantifying them, particularly the probability.  When stated as facts or uncertainties, the probabilities are rather meaningless. 

For example, let’s take the first one: “The infrastructure is outdated.”  On a probability scale of 1-5 with 1 being not very likely and 5 being highly likely, what the probability of the infrastructure being outdated?  5, right?  We are stating a fact.  How about the second one: “We aren’t sure how much Sam will be available for the project.”  Again, using the same probability scale, what’s the probability of us not being sure about Sam’s availability?  Again, it’s going to be 5.

When we state risks as facts or uncertainties, their probability will always be the highest number available on your probability scale.  It isn’t terribly meaningful.

Additionally, defining a response to risks expressed in this way is difficult.  What exactly are we supposed to do about the infrastructure or Sam’s availability?  It’s a little obtuse as to what an appropriate response might be.

What, then, would be a better way of expressing these?  After all, these may be significant considerations for the project.  How could we turn these into events to make probability quantification more meaningful and response planning more directed?

We need to examine the concern.  What is the potential problem?  Let’s go back to the first example above,”The infrastructure is outdated.”  If we modify that to be a risk event such as “The infrastructure fails to support the application being built” or “The existing components fail to process the data coming from the new components,” then we can think about how likely that event is to happen and assign it a meaningful number given our scale.

Now on a scale of 1-5, how likely is it that the existing components are unable to process the data coming from the new components?  2?  5?  Now those numbers have a little more meaning.  Additionally, now I am in a better position to decide what, if anything, we should do about it.

So when identifying risks, think about the uncertainties and concerns that are generally the source of our risks, and when it comes time to put them on your risk register, make sure to articulate them as discrete events.

Stay tuned next time for more on Project Risk Management.