What Is a Risk?
By Andrea Brockmeier
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.
Andrea Brockmeier is the Client Solutions Director of Project Management at at Watermark Learning, Inc. She began her project management career in the non-profit sector in Dallas where she developed and directed a community program for refugees. After returning to Minnesota, she spent over 10 years managing technical, operational, and financial projects. She also has many years of experience developing and leading technical project teams. Most recently, she has focused on curriculum development and training delivery of project management and influencing skills classes. Andrea holds a number of technical certifications and is certified as a Project Management Professional® by the Project Management Institute. You can read more from Andrea on her blog.