Learn more about the role of a risk register in project management. A key element that contributes to the clear understanding of any risk is its description or definition, usually found in one of the first columns of the risk register. Based on this simple description, we will support an entire risk process. There is no room for being vague or unclear. Unfortunately, we generally spend no time or thought on this important component which might lead us to over or underestimate the risks of the project in the long run. We discuss the risk register, risk log, risk descriptions, risk statement, and risk formulas in proper risk planning and management.
The project has started, and with it, a brand-new risk register is created, filled with our understanding of risk and the requirements for the job at hand. The team is busy setting up a risk identification meeting, and participants are being invited or scheduled to participate. Before you know it, that risk register has taken a life of its own and contains a lot of details that should assist us in making the right decisions for the project going forward.
For a lot of projects out there, this would be the way that we establish our risk register. As time progresses, not to mention, with the help of progressive elaboration, the PM and the team generate a valuable risk register. Over the years, I have seen this exercise create a small but easy-to-fix the problem, which could make our work on risk management better as we go forward if we address it early in the risk process. That small problem is the result of us trying to cut time out of the identification process. We do not spend enough time on our description of the risk so that it is framed properly.
Look at any recent risk register from your organization. Tell me what you see in the risk description column? For most, it will be something similar to weather, inflation, a rise in the price of gasoline, or the quality of part ABC…
Risk descriptions: What is wrong with this picture?
Well, it does not really provide a complete or clear description, and it certainly does not paint a picture of our risk in a way that it is easy to analyze or assign responses or strategies to. Associated with the description is the fact that we clearly need to understand the extent or magnitude of the risk in order to make future decisions that can handle the totality of that risk.
What is a proper definition that would help us in our risk management process?
IF [Event], THEN [Consequences] This is as basic as you can take it, and you have to admit is easy to remember. It just flows as one thinks it.
I have since researched this topic and found others that go a bit deeper in their elaboration of risk. In a briefing published in 2004, Dr. David Hillson, who suggested that risk events should be documented on our ability to understand the risk based on three key components: management, ownership, and reporting. So, it stands to reason that one description must address a variety of factors, not all contained in a word.
Common Risk Formulas
Below are some of the most common risk formulas that I have found or have seen used in organizations:
- An <uncertain risk event> could occur due to <definite cause or trigger>, leading to <impact on objectives>. This is also recognized as the Total Economic Impact (TEI) model.
- [Event that has an effect on objectives], caused by [cause(s)] resulting in [consequence(s)] (XSEDE, Nayak, 2018)
- A condition can cause an uncertain outcome and the likely consequences (negative) if it is not managed
Where did we lose our way?
It all starts with planning. It seems that over time, project managers have started to not pay as much attention to their risk descriptions in risk logs and the impact of not having a full-fledged risk statement. Your risk statement, risk formulas, risk description, and risk log must be a key focus.
Part of the problem is related to going through the planning stage as fast as we can, which causes issues in a number of ways (i.e., weak requirements gathering, not performing a deeper analysis, etc.), including this one. Cutting corners here will lead to further problems in risk planning as we will need precise information in order to analyze, provide risk response strategies and plans as well as assign ownership to our risks.
If you find your risk register lean in the definition section, going forward ask your team to slow it down a bit when it comes to describing the risk events. You might want to have a quick review session on best practices for doing this which can involve practicing and playing with the formulas I introduced in this article.
I have in my office a laminated copy pinned to my wall that serves as a reminder of both doing it right and slowing myself down so that I do not have problems at a later point.
At the end of the day, this goes to show why we do risk management in the first place: to deal with our lack of information which brings uncertainty to the project. It should start with a properly defined description of the risk event. Addressing risks adequately means making sure your risk statement, risk formulas, risk description, and risk log are accurate and makes the grade.
