The focus of this article is to continue the discussion in our series of “Proactive Risk Management.” Writing the risk mitigation plan is one of the steps in the project risk management process. Under the “Well Skilled PM®” series of MCLMG’s Training and Education Division, the project risk management process has five steps:1. Plan risk environment 2. Identify risk potentials 3. Determine risk assessment 4. Develop mitigation strategies 5. Manage risk environment
If you would like a review of any of the steps above, before the discussion of developing risks mitigation plans, I recommend several articles in past PPG newspapers: “Not all uncertainties is project risk,” Octobers PPG, “Identifying risks, causes and triggers in IT projects,” November’s PPG and “What is a risk,” Octobers PPG.
The first step, plan risk environment, describes how the risk environment will be implemented within your project. At this point the project manager and project team will develop the Risk Management Plan (RMP) that provides all the necessary information to manage the risk process within the project. The RMP should include a risk dictionary of all the risk terms on the project, roles and responsibilities of the risk owners and risk action others, constructs for performing risk identification, risk assessment (quantitative and qualitative analysis), procedures for escalating risks, de-escalating risks, understanding root cause analysis, risk trigger management, risk assessment audits, risk documentation, and risk archiving and de-briefing (lessons learned).
The second step in your pro-active risk environment is: identify risks. Risk identification is an iterative process repeated throughout the project’s lifecycle. The identification of project risks must be both complete, accurate, and timely in order to support the fast moving pace that projects carry during the initial weeks of their existence. A risk program must stay up with this pace and thus risk identification must begin as soon as the stakeholders have been identified using the stakeholder register and analysis processes. Risk identification is a foundational process within an project since as a primary constraint, it lays the groundwork for other activities that may impact the other four constraints of scope, time, cost and quality as the PM and project team seek to produce the project’s ‘fit-for-use’ deliverables.
The third step in your risk process is to assess your risks both quantitatively and qualitatively. This article will not expand on the reasoning behind performing quantitative versus qualitative analysis since we have covered this topic in other PPG articles. We have also discussed some of the more modern risk assessment techniques in our targeted risk articles to which we direct the readers.
The fourth step in the risk process is developing mitigation strategies for your risks. Many current bodies of knowledge will talk about risks response plans at this point. All project risks as well as any other type of risk potential is entirely a future event that may or may not ever occur to impact the projects production of the ‘fit-for-use’ deliverables. By indicating that risks should be responded to implies that all risks live within the past temporal vector. A risk is a future event that has yet to materialize therefore a risk potential is something or an event that has not yet occurred, so the question is: how can one respond to an event that has not materialized?
The correct terminology is that one can only attempt to mitigate the impact of a future event by studying its possible outcomes and the costs associated with each of these possible future possibilities. This is why we put into place risk mitigation plans because the project manager and project team can only mitigate a risk potential. Writing a response plan for something that has already occurred (in the past) involves an entirely different perspective and set of constructs than writing a mitigation plan for something that has still not occurred (in the future). Remember, an issue is a risk potential that has materialize (in the past), and one cannot mitigate an event that is already occurred.
While this concept may be challenged by some that are reading this article, I challenge you to look beyond your biases of accepting current risk practices just because they are touted as “best practices.” From working in the industry for over 20 years as a risk manager, I have found that project managers and teams that incorrectly use the terminology of risk response when they mean risk mitigation tend to treat risk potentials as issues and therefore do not truly take advantage that a mitigation strategy can provide by reducing the probability and cost of the risk potential even before it can trigger into reality. This is the true failing of what the current bodies of knowledge are hoisting upon project managers and team since the advantage of mitigation is to reduce the future impact of risk not respond to something that has not yet occurred. This dogged acceptance and lack of challenge towards so called standardized and proffered dogma is one of the cognitive biases that the PPG staff has been discussing in our other targeted articles – it is called the confirmation bias. The overweighting of the value of evidence or information that confirms what we (the project manager) already accepts or believes. Check your biases, folks!
So what is the purpose and focus of risk mitigation planning? Quite bluntly the purpose of any mitigation is the reduction of a future event’s impact if that future event were to in fact become a reality. In risk management we call this risk triggering. The mitigation plan should therefore be focused on the reduction of the initial risk assessment that is embodied in its risk equivalent value (REV) by either seeking to reduce the risk probability of occurrence (RPO) or its risk cost of impact (RCI) component of the REV and thereby reduce the overall possible impact the risk could have on a project’s deliverables if it were to trigger. In short, the project manager in consultation with the risk manager and risk owners is attempting to balance between the use of risk mitigation funds and resources and the obtaining the largest reduction in overall project REV that is possible.
Now that we are beyond the explanation of why we are developing a risk mitigation plan and not a risk response plan, we can further discuss the vectors of RPO and the RCI. Together these assessments produce the product of the REV mentioned in the previous paragraph that will always be currency denominated for a more clarified and understandable value of the true nature a risk possesses to a project’s deliverables. An additional third risk potential vector called the trigger potential of existence (TPE) that characterizes a risk potential’s dependencies on its associated triggers for its conversion into an issue. Please see previous PPG risk articles for a full coverage on trigger management.
The RPO and the RCI are important components to the risk mitigation plan. The RPO can be calculated through a statistical model such as a three-point estimation, probability density analysis, or a Monte Carlo simulation. One important point here is that the project manager should not be assessing these risks alone, but should be engaging with the assigned risk owner who in truth is the risk’s subject matter expert (SME).
The second risk vector, RCI is a currency denominated estimate. It is important that the RCI is a currency denominated evaluation in terms of cost to be able to understand the impact and reference to the project’s budget.
By not understanding or using the information gleaned from the RPO and the RCI the project manager and the project team cannot effectively put together steps to mitigate a risk properly. If the project manager only uses the unitless scoring method of likelihood times severity (the infantile method now touted in several of the discipline’s bodies of knowledge as best practice) without supporting these decisions on anything other than a “gut feeling” then there is no true basis for determining the optimal mitigation plans for each risk.
When the project manager and team along with the risk owners and risk action owners can now begin the work necessary to put together a strategy to reduce the risk’s REV, the mitigation plan, the information that is gathered from the RPO and RCI are going to provide more accurate and thus more valuable information to these decisions. The value from these calculations is both in providing a more accurate detection of the risk potential’s budget negativity to the project, but also to improve decision-making in the mitigation planning.
Risk mitigation planning is not just another step in the risk process, but if carefully and thoughtfully accomplished, can either assist in the reduction of the impact of the risk should it trigger, or through careful trigger management, eliminate the risk from occurring altogether. But without understanding the impact of identifying true risks from normal project problems, performing quantitative risk assessment to eliminate subjectivity, ensuring risks are scored to include its three vectors (RPO, RCI and TPE), mitigation plans will not provide the project manager, project team or the risk owners with the information that they need to have any impact on the reduction of uncertainty which is the goal of any decision support solution.