A Risk is an uncertain event or condition that, if it occurs, has a positive or negative effect on one or more project objectives.
As a Project Manager (PM), when we hear the word “Risk”, we usually associate it with something undesirable and seek to avoid it as much as possible. However, there are silver linings to risk, which also means it could be an Opportunity. Regardless of risk or opportunity, many PMs might use the Probability and Impact matrices to weigh the risk to determine which risk they are handling. There are bound to be risks, and it’s not realistic or efficient to manage all the risks that might hit the project.
The impact of risk could affect multiple areas, such as scope, cost, quality, reputation, and many others. Every risk is different, and the same type of risk on a project could have different outcomes and impacts. In this case, does it make any difference if we might determine the speed of impact and how easy we can detect the risk?
In this article, I like to share my thoughts on how Velocity and Detectability could drive how we manage risk.
Velocity
Once the risk happens, Velocity is how fast the impact will hit the area(s) listed on the Risk Register for that particular risk. Velocity can be defined qualitatively or quantitatively, depending on the project’s demand. For example, the area where you purchase one of your raw materials is facing a typhoon risk. Assuming that you have an inventory stockpile of this raw material, the speed at which it’s hitting you could be slow compared to a fire that broke out on your project site.
The PM might want to further deliberate on this aspect and tag a quantitative figure to this risk, such as 75-days, which might mean the time your inventory runs dry. Based on this, the PM could discuss the supplier’s disaster recovery effort and work on various scenarios to determine how the project team should manage this risk.
Detection
How easy is it for the project team to know that the risk occurred or will get triggered when it happens? This is Detection.
There are different means of how the project team can detect a risk, using sensors, from the news, from media, or from the team can feel it. It is much easier to notice something significant and visible, like a fire or smoke, than something invisible or odourless.
Adding them up
Once we have all four indicators on the risk register, we need to consider how we are utilising them to give us more depth into how we see the risk, which risk event to tackle, and probably how we will react to it.
I feel that if we define risk as a 3-Dimensional object that we ought to manage, Probability and Impact provide us with dual dimension information. We have the make of it but not that depth, which limits the “how” and “when” of risk management. I am not saying that we can’t do it. It’s that I feel there might be a more meaningful way.
When we have Velocity and Detectability inside the equation, it probably helps to explore our decision-making options. If you see a risk of Low-Probability & High-Impact, knowing that the Velocity is Very Slow and Detectability is Very Easy allows you more flexibility than one that has a very fast Velocity and is very hard to detect.
The challenge now is to determine how all these factors interact to give you the score for the team to start brainstorming on how they want to handle those critical risks. You could sum everything up to provide you with the score or have each as a factor in the overall consideration. I am still experimenting with the different computations and how they affect how the risk is handled.
Another consideration that the team might want to ponder is — “Does Probability, Impact, Velocity, and Detectability has equal weightage or are some more critical in a certain project?” Again, this might result in a weightage score on each factor, further complicating our consideration of risk.
Summary
While risk is a component of project management, I feel this is critical and must be considered sufficiently. Of course, it will take more effort and time to work all these out. First, consider the outcome and benefit you have if any of those risks get triggered. What if a risk event occurred and you did not have any solution to deal with it?
Lastly, a PM must handle those events with 100% confidence of happening immediately instead of putting them in your risk register for monitoring.
I hope this article gives you another perspective to consider for risk management.
Comments