Management Fix: Risk Management Implementation

A MngtFix is an actionable solution for a problem with pros and cons to be evaluated by a human manager. Every other week we share a little bit of our knowledge base on social media and our newsletter. This week’s MngtFix is…

Have you ever seen this MngtFix? What problem(s) was it solving?
Share your story!


This week’s “Risk Management Implementation” is one a personal favourite.
By definition, a risk is an uncertain event that can be either positive or negative. Additionally, risk management is, “… the systematic process of identifying, analyzing, and responding to project risk.” Risk management incorporates various processes. Models differ — one example is Risk Planning, Identification, Qualitative Analysis, Quantitative Analysis, Response Planning, and Monitoring and Controlling. While risks are “uncertain” events that have not yet occurred, an Issue is an event that has already transpired. A trigger is an indication that a risk is about to or has occurred, and is usually based on parameters that have been “set off”.

The tool or Risk Register (in this case a Microsoft Excel Spreadsheet) provides a mechanism for capturing project risks and issues, yet also covers all of the PMBOK® KPA processes, with the exception of Risk Planning. We suggest Risk Planning can be covered within one’s Project Management Plan. The planning component within the Risk Management plan can be relatively short (summarized within a couple of paragraphs) by referencing the self-contained Risk Register, identifying the methods for updating the Risk tool, and communicating the Risks and Issues from the Risk tool.

As stated previously, we choose to manage some project risks via a spreadsheet template (see diagram).

As can be seen, each of the processes is included within the spreadsheet (or Risk Register), with the exception of risk management planning. The idea is that each horizontal entry represents one Risk or Issue. If it is a risk, the format for capturing it is in a specific format: “IF BY THEN .” Because risks are uncertain events, it is useful to state them in this format so that the point at which this Risk may become an Issue is clear. Note: not all risks become issues; that is part of their inherent uncertainty.

As part of Risk Identification, we also capture the date on which the risk was identified and the category to which the risk belongs. Risk identification has been shown to be a significant part of risk management in that it makes one aware of potential events or issues that may impact the group.

Following this, we want to evaluate the quantity and quality of the individual risk itself. Many organizations use a “risk matrix” to control this (e.g. magnitude and likelihood).

The mechanism employed here multiplies the probability of risk (value between 0.0 and 1.00) by the Impact of the risk if it were to become an issue (values range 1 to 100). This produces a REN or Risk Event Number, a way of ascribing a value (1 to 100) to each risk. Depending upon your organization’s preferences, you may consider color-coding the REN cell (clear, yellow, red) as a means of drawing attention to high-probability, high-impact risk.

Additionally, this mechanism enables us to collectively sort all of the risks, allowing us to recognize at any point how close any particular risk is to turn into an issue. It also allows users to sort and compare project risks.

Continuing left to right, the next field is labeled “Mitigation.” Within this field, we want to capture our Risk Mitigation Plans. This requires that we look ahead, consider and plan as to what we will do to manage our Risks and their potential progression to becoming Issues. We find that having multiple plans in place helps to maintain a balance as to how we’ll manage our Risks. To this end, we prefer to categorize the plans as either MITIGATE, MONITOR, ENCOURAGE, or ACCEPT.

The last two fields include the Risk Owner (who is primarily responsible for the Risk) and running status of the risk. The latter should be updated each time the risk status is changed so that one has a history log for all the risks. (special thanks to

Known Associates

This MngtFix has been mentioned in relation to a number of MngtBugs such as…
“Lack of Communication”,
“Unrealistic Project Budget”,
“Undefined Project Scope”,
“Undefined Project Schedule”,
“Lack of Project Planning”,
and of course “Lack of Risk Management”!

Call to action

What about you? What do you want more or less of on medium post?
Do you have other suggestions?

I would love to know more about your feedback and stories so that we can learn, share and grow together!

Feel free to subscribe to the Human Management Weekly newsletter and share this with your friends and colleagues.
If you liked it, there is a good chance they will like it too!

Have a nice week and remember…
Human Managers should strive to be humans while managing and be managed as humans!

Eduardo Espinheira is a Consultant, Facilitator, Manager, Public Speaker, Creator of the Management Bugs&Fixes and the Machiavellian PM Stories