Often in my consulting and training, I emphasize the need for a risk log. When I present that, I often get a lot of head nods and agreeable looks. But rarely do I see them put into practice. As a person who constantly thinks in terms of risks and trade-offs, I find this a bit surprising, but not that unexpected.
We humans have a positivity bias. What this means is that we always think that the future will be better than the past. This bias also leads to aversion of raising red flags, especially if it is not absolutely necessary. This is wrapped up in a lot of psychology and behavioral economics - a great topic for a future blog but, for now, I'll stick to the implications. What this leads to is commonly referred to as the "ostrich effect": we bury our heads in the sand as to not make our projects look too risky and put in jeopardy it's continuation or even launch.
However, good risk (and issue) management is critical to the success of any project. Not only will it make your project's timeline, budget, and scope more realistic, but it can help you reduce the severity of issues that arise and could even help you solicit support for managing them. So, let's see how good risk and issue management can work together:
Issue management is far more common in our project management. Mostly, this is because issues are things that we HAVE to deal rather than risks that we COULD address. Though separate concepts, they are intricately linked. A quick review of the difference: risks are things that have PROBABILITY of occurring where issues have ACTUALLY occurred (i.e. 100% chance of happening or did happen). We often deal with issues when they arise but wouldn't it be nice if we have a nice risk register to describe the plan and resources to deal with it? By connected a risk log (list of possible issues) to an Issue log (list of actual issues), some really great insights occur:
1. Issues that weren't planned for in risks
These are true surprises. If you have good risk management, these are the anomalies. Things that no one thought could or would have happened. Think earthquakes in non-seismic areas, sudden and severe storms not typical of an area, or the election of a long-shot candidate. Good risk managers, however, would say these are all risks (we should have planned for) just very low probability. For the rest of us, these are great learning opportunities. We can examine the root causes and see if this is a true anomaly or start of a future pattern. These issues should be logged and considered in future planning. It goes without saying, that these should be minimized.
2. Risks that never turn into issues
This really can be only understood in the aggregate. If you logged a risk that never turned into an issue, this could be just plain luck in your project. So, it is worth comparing to other projects. For example, if all of your projects in Vietnam plan for the risk of flooding, and this flooding fails to occur for all of your projects in the country over an extended period of time, it is worth considering removing it as a risk. This could be the result of a new climate situation that has greatly reduced the probability of flooding (but probability increased the probability of other climate-related risks) and teams should consider retiring that from their risk register. It needs to be noted that when this occurs, project managers should revisit if the risk was properly described. For example, if your risk is the "ship sinks with all of our supplies on board" and it never happens, you should examine whether that risk was properly defined. Instead, the real risk is the impact to your project and should be reworded as "Supplies don't arrive and we can't build [regardless of reason]".
3. Issues that are risks realized
This is when a PM looks really smart. When an issue occurs and you are able to simply go over to your risk register and implement your mitigation plan, people may start to think you can predict the future (instead, you're just really good at risk/issue management!). Let's return to flooding: you logged your risk of coastal flooding in Tanzania and you created a contingency plan to move inland. This entails you have some budget and time set aside in your project plan to conduct those activities. When that flooding occurs, you spend that budget and move around activities in your schedule and you look brilliant! When this happens often enough, teams should cease to be logging them as risks and start fully incorporating them into project planning.
Bringing this together
In order to achieve these benefits and insights, PM's need to not only create a sound practice of risk and issue management and create time in the planning and implementation process to do so, but it also requires a connection to the risk and issue logs. Ideally, there would be a nice information system where you are logging all of issues and risks and using a reference / drop down menu to connect them. However, few organizations have committed to investing in such as system. Nonetheless, this can be accomplished by good Excel workbook design. List your risk in the beginning of your project and as they are identified throughout the project. Then, log issues as they arise and use a reference number to connect them to a risk (or not) to your risk register. Though it will take a little bit of data analysis, you should be able to examine the three scenarios discussed above.
To get started, you can download a free template in our PM Toolkit. Happy Pming!
Ryan LaPrairie is the Director of Systems and Innovation for Mission Critical Development International. He has a Bachelor's degree in Cultural Anthropology, Master's in Public Administration and holds a Project Management Professional (PMP) certification and is a Certified Change Management Practitioner. As a project manager and consultant, he has been working with individuals and teams to improve group dynamics, processes and procedures, and decision-making methodologies. He routinely conducts data analyses for organizations using advanced statistical software. As a trainer, Ryan builds capacity for individuals and organizations around topics such as risk management, indicator targeting, applied project management tools, and Project Management for Development Professionals 1. He can be reached at firstname.lastname@example.org