Sample Risk Management Plan - Part 4: Risk Matrix
Published: November 16, 2011
Section 4: Risk Matrix
Construction of a risk matrix starts by first establishing how the matrix is intended to be used. … A key initial decision that has to be made is to define the risk acceptability or tolerability criteria for the organization using the matrix. Without adequate consideration of risk tolerability, a risk matrix can be developed that implies a level of risk tolerability much higher than the organization actually desires. (ioMosaic, 2009).
A&D High Tech historically veered away from Internet marketing projects either because the company saw no value in the market or the risk tolerance for such a project was low. In any case, negotiations for extended time or capital for this project may be met with resistance. The risk matrix will be used to guide the project team in avoiding and mitigating risks that A&D High Tech would likely consider intolerable.
“The next step is to define the consequence and likelihood ranges” (ioMosaic, 2009). The likelihood in this risk matrix is expressed as a percentage value in the Probability column. Determining the likelihood or probability of risk events is difficult without any quantifiable data to base the determinations on.
A major risk component is the contract with Geneva. The implied probability for this risk was determined to be very high and quantifies as a risk factor of 75%. This percentage value was then used for the Risk Matrix in section 4.2 along with the quantified values for other risks.
“The key to risk management is to identify risks that are intolerable and to mitigate them to a tolerable level” (ioMosaic, 2009). Classification of risks and ranking them by tolerability is covered in section 4.1.
4.1 Major and Minor Risks for the Risk Matrix
The author next categorized risks using a ranking system of 1 through 4. With the ranks associated with the following categories:
- Acceptable with Controls
- Acceptable as is
These categories would then lead to the following category descriptions:
Risks leading to probable project failure that should be immediately mitigated to level 3 or more using design or administrative techniques
Risks leading to undesirable scheduling or cost variances that should be mitigated to level 3 or more within 3 months
- Acceptable with Controls
Risks likely leading to no effect on the project as long as verified controls are in place to prevent the risk from graduating to level 2 or lower
- Acceptable as is
Risks that require no mitigation and may be overlooked
Evaluating the various project risks is a qualitative exercise of imagining what could go wrong and what may happen. Once each of the risks were evaluated in this manner the risks were added to the risk matrix, inserting the rank values in the impact column and the probability values from above to the probability column.
Multiplying the importance value for a risk by the inverse of the probability value yields a risk score. The risk score was then used to identify the major and minor risks. The inverse of the probability was used because the lower importance values were more critical in this case. Using this method, the risks with the lowest risk scores are the major risks and those with the highest risk scores are the minor risks.
This method of evaluation identifies three major risks and three minor risks. The three major risks for this implementation project include the following:
- Finish by Christmas
- Interface with ERP Package
- Contract with Geneva
The three minor risks include the following:
- Inaccurate Physical Infrastructure Estimates
- Employee Morale
- Change in Process Flows
The major risks must be closely monitored and action taken as necessary to mitigate the risks before a risk event occurs. The Action Plan column of the risk matrix describes the steps to be taken to prevent the risk events from occurring and the Response to Risk column describes the steps to take if a risk event occurs. The team members who are responsible for each risk are also listed in the risk matrix along with the current status.
Using the risk matrix will provide the team members a visualization of what the risks are from top to bottom and how to deal with them. Figure 4.2 above contains the completed risk matrix for the A&D High Tech Internet Store project.
A risk review is “an overall assessment of the risks involved in a project, their magnitude and their optimal management” (RAMP, 2009). These reviews may be held at any point during the project life cycle and for this project will take the form of agenda items during regularly scheduled project team meetings. These reviews will be cumulative in nature with the results of each review adding to those of the predecessors.
A risk review plan will forwarded to each team member prior to each project meeting. Chris Johnson will develop and distribute these risk review plans to each of the project team members. Team members should review the plan before attending the meeting. All team members will be permitted to attend but attendance will be mandatory for members who are responsible for items listed in the agenda. The time and location of the meetings will be adjusted in order to coincide with the schedules of attendees.
These reviews should generate information to be included in the RBS and Risk Matrix as appropriate. Mitigation strategies will be discussed along with risk ranking criteria. The result of the risk reviews should be to help mitigate those risks that would be deemed intolerable by the upper management of A&D High Tech before unacceptable conditions surface.
Dumbledore's Sample Risk Management Series
Section 5 comming soon
RAMP (2009). Risk review. Risk glossary. Risk Analysis and Management for Professionals. Available from http://www.ramprisk.com/riskglossary/glossary_p2t.asp.
More by this Author
Monitoring project activities and correcting deficienciess are major components of the Risk Management Plan to ensure project success.
Risk identification may be accomplished using a number of techniques, including brainstorming and the Delphi Technique.
This sample term paper was written to cover the topic of gathering requirements for a class in system development and design.
No comments yet.