Risk Management Strategies, Tools, and Techniques
Risk Management Strategies, Tools, and Techniques
By Kathie York
This essay is an excerpt from an assignment for the Assessing and Managing Project Risk course in my Master of Science in Project Management program. The tasks for this question were:
Describe, compare, contrast, and fully analyze the various strategies and tools/techniques for each of the six PMBOK risk management processes (for both negative and positive risks)
(In this document, negative risks are “risks.” Positive risks are “opportunities.”)
The six PMBOK risk processes are (from Chapter 11 of the Fourth Edition PMBOK):
- 11.1 Plan Risk Management
- 11.2 Identify Risks
- 11.3 Perform Qualitative Risk Analysis
- 11.4 Perform Quantitative Risk Analysis
- 11.5 Plan Risk Responses
- 11.6 Monitor and Control Risks
11.1 Plan Risk Management
The Risk Management Plan (RMP) is an overview of the entire risk process, initiated at the beginning of a project. It is usually completed during the planning phase. The project manager (PM), and other stakeholders as necessary to this project, help develop the plan. The opportunities in the completed plan lay in having an unchanging project “map” to which all team members can refer. The RMP dispenses the same information to everyone: the original plans and processes agreed to by the stakeholders. This helps keep the team on track and is also a good deterrent to arguments (strategy).
As new ideas come to light, it is tempting to change “just this one part …” to make the Plan
better. The books in this course seem to say planning files can be changed. However, I have not seen that on a project. We have always kept the plans the same and used the reports at the end of the project to document discrepancies (good or bad). Updating a plan would skew the historical nature of the document. Later files, such as a Project Report, capture the changes made to the processes outlined in the plan.
The tools used to create the RMP are planning meetings and analyzing the ideas that come from them, along with an RMP template to keep the team on track. The plan should be basic but thorough (strategy). For example, instead of a full-blown Roles and Responsibilities document residing within the RMP, the section would probably be a paragraph or two with a table showing the contact information for team members. Readers would then be directed to the complete Roles document for further information. The electronic version of the RMP should include a link to the most recent version of Roles and other listed documents.
11.2 Identify Risks
Everyone on the team – including the testers, trainers and technical writers who are often excluded – should participate in project risk identification (strategy/tool). The Risk Management Plan is an excellent document to reference, along with other papers, if for no other reason than to use as a checklist (tool). The first place I look in the RMP is the roles and responsibilities list. Not only does that help me remember what departments are included in the project, it is also the first step to assigning the research portion of “identify risk” (strategy).
While identifying opportunities and risks, encourage the team to use brainstorming and other techniques to uncover hidden nuggets. It is important to have all the stakeholders around a table and ask each for ideas gleaned from similar projects (techniques). If they don’t work well in a brainstorming environment, the Delphi technique would be a good alternative. Anonymous tips from the questionnaire afford good information. I have seen a group reconsider brainstorming after Delphi got the ball rolling.
From my experience, the most important reasons to identify risk are to help with the schedule and costs. If I know my project needs four people for one year and the budget only allows for two workers, something has to give. Let’s find that out up front (strategy/technique). I have worked on projects where planning was not very thorough because the “unimportant people” – the writers and testers – were left out of the plan. If the proper people had been available from the beginning, we might have prevented an angry client and a project only three-fourths complete by the due date.
The output from “Identify Risk” is the risk register. The team updates the register as it works through its processes, but the register starts here. This is not the same as risk analysis. We’ll look at this in the next section.
11.3 Perform Qualitative Risk Analysis
Qualitative Risk Analysis works directly with the risk register output from “Identify Risks.” Since the team prioritizes the risks for further analysis (strategy/tool), this meeting can become quite testy! I think the best part of this process is creating the probability and impact grid (or “matrix”). It is sometimes difficult to tell Manager T that Manager A’s risk is more important to “solve” first. Of course, this process group isn’t about solving the problem, but staff often sees it that way. The matrix points out criticalities without anyone’s pride getting in the way.
What it finally boils down to: which opportunities and risks are the most probable and which have the highest impact? I have seen a PM split a team once a newly-found opportunity became apparent. The core group followed through on the risk (strategy), since it was “real” and the opportunity mioght not come to fruition. Since I was the only tech writer available for a while, I worked with both teams on their documentation. That was a most interesting process!
When the qual is complete, the risk register is updated and risks can be grouped by categories (tool). If some opportunities/risks need further analysis, they are “sent” to the next process: quantitative analysis.
11.4 Perform Quantitative Risk Analysis
Qualitative and quantitative risk analysis work together. Once the risks have been prioritized (in qual-), it is the job of the metrics (in quant-) to help us analyze the significance of each (tools). As an investigator and technical writer, I am often tasked to do some of the legwork in quantitative analysis on a project. I research similar projects to
see if their lessons learned or other documentation may lead us to a good conclusion with our risks. Interviewing is also a good way to find information, especially if engineers or other designers of project “pieces” can lend their expertise (tools).
For example:
A qualitative risk analysis lists two items that may impact a project. A weakened dam, five miles downriver from town is the project (to rebuild or reinforce it). Secondly, a rainstorm is predicted which may make the river crest 15 feet above flood stage. A sensitivity analysis (tool) shows the dam is the weakest link.
After checking historical records and talking with subject matter experts in town (tools), the team discovers this type of flooding has never occurred in this season in the 154 years records have been kept. A probability distribution (tool) shows the likelihood of a high river crest is extremely low, but the effect (should it happen) could be catastrophic for the dam and those living below it. An opportunity of having former data is exploited.
A simulation (tool) is run, using data from a flood 20 years ago. It is decided the lessons-learned result should work here, if necessary: with only two days’ warning, volunteers can sandbag a mile upriver and temporarily reroute two of the small tributaries to divert enough water to save the dam (strategy).
11.5 Plan Risk Responses
We had an excellent example of risk response planning in this course. Our instructor fell ill, after the first class, and was replaced within 18 hours of notifying the school and the students of the issue. I will be interviewing an Embry-Riddle employee, later this month, to find what the actual risk plan and responses are in this situation, but it is interesting that this happened during a risk management course! Obviously, options and processes were already in place should this problem occur.
In my world of work, we usually show the risks and the response(s) to them with tables. These tables are usually packaged in a Business Continuity Plan, Disaster Recovery Plan, or a Crisis Plan and would include a brief definition of the risk, perhaps the trigger mechanism, when/how to perform the response and whom to contact (and when) if the risk occurs.
Risks (tools): In (legit) U.S. pharmaceuticals manufacturing, acceptance is never an option as a risk response. Transferring risk would only happen should another expert be brought in to deal with the issue. Usually we planned mitigation steps and ensured all that information was stored on- and off-site.
Opportunities (tools): In the world of medical research, new options frequently appear for a medicine. Although it was created for Condition A, it is realized it also helps with Condition B … a wonderful side effect. Of the four tools in the PMBOK, the two I saw the most in this situation were a new team veering off into this new direction (exploitation) or another firm being called upon to help in the new endeavor (sharing). Sharing was usually the response if the other company was already working on a similar product.
11.6 Monitor and Control Risks
The risk register, created in “Identify Risks,” is very helpful here, ensuring all risks are considered. The actual monitoring and controlling risk, in my career, has been a very exacting process. Whether it’s employing variance techniques to ensure a rotor is machined to within the standard or a Petri culture plate is incubated at the proper temperature, monitoring can be tedious (tools). Policies and procedures are what my teams follow for monitoring (strategy/tools).
Part of controlling the risk is to have the equipment validated periodically, usually within guidelines of a federal government agency (tool). Any variance from the norm is viewed with suspicion, and a trigger “happening” can shut down a line.
Kathie York is a business analyst specializing in system testing and documentation. Her favorite projects involve testing and validation of software or equipment. Her Master of Science degree in Project Management gives her a ‘heads up’ on the processes her PMs face. Ms. York also assists students and businesspeople with her proofreading/editing skills. “Especially for those in a Master’s or Doctoral program, ‘getting the paperwork right’ can be a daunting task,” Kathie states. “Sometimes, though, business managers need that other pair of eyes to review a final draft of a proposal or PowerPoint presentation. I like to help in that effort.”
