Table of Contents |
Risks should be identified in the early phases of a project, but the project manager should continue to search for new risks as well as monitor and manage existing risks over the life cycle of the project. A consistent method for classifying and documenting risks is necessary for success.
A risk matrix is a tool project managers use to classify risks consistently. Each risk is assessed by the probability that the risk will occur, and the impact the risk will have on the project if it does occur. The risk matrix has probability and impact on its two axes.
Probability of Occurrence | ||||
Low | Medium | High | ||
Impact on Project | Low | |||
Medium | ||||
High |
For the likelihood that the risk will occur, the project manager gives each risk a rating of high, medium, or low. High probability risks are likely to occur and therefore need to be watched closely or mitigated to reduce project impact.
Probability Ranking | Description |
---|---|
High | Likely to occur |
Medium | May occur, but not a general expectation that they will happen |
Low | Unlikely to occur, but will still have a negative impact if they do occur |
High, medium, and low rankings are also given to the negative impact a risk will have on the project. High impact risks can cause significant harm to the project. These risks are called “project killers” because they have the potential to end a project.
Impact Ranking | Description |
---|---|
High | Will cause significant harm to the project |
Medium | Bad but survivable in the short term; will not stop a project from succeeding |
Low | Has little effect on a project |
When documenting risks, project managers often use color-coding to identify the risks clearly and to indicate the actions currently happening with the risk:
The project manager handles risks with different classifications.
Suppose you are managing a project that's been tasked to create a new customer support system for our organization's website. Here are some examples of risks that could affect the project, and how these risks would be classified.
High Probability and High Impact
What if your company has never developed a website before, and the available resources have no expertise with customer support systems?
If the system is extremely complicated, and it's intended to handle a high number of customers, then there's a high risk that the system will not work well for customers when the project finishes.
Probability of Occurrence | ||||
Low | Medium | High | ||
Impact on Project | Low | |||
Medium | ||||
High |
Given the circumstances, this is a high probability and a high impact risk and should be color-coded as a red risk.
Though there could be many mitigations for this risk, the primary mitigation would be to either hire an outside group to develop the site or hire designers and programmers experienced with these systems.
Medium Probability and High Impact
What if your organization does have experience with customer support sites, yet it is still a complicated project?
There would still be the risk that the system would not work, so the risk would still be high impact, but with medium probability. You might choose to hire additional experienced programmers to further offset the risk or just monitor the risk more closely.
Probability of Occurrence | ||||
Low | Medium | High | ||
Impact on Project | Low | |||
Medium | ||||
High |
With medium probability, there is a choice to either mitigate or monitor. So this risk would be color-coded as yellow.
Low Probability and High Impact
What if key stakeholders decided to move the web server to another development platform?
This is unlikely to occur, but it could kill the work on the current project if it were to happen, so this is a high impact risk with low probability.
Probability of Occurrence | ||||
Low | Medium | High | ||
Impact on Project | Low | |||
Medium | ||||
High |
Since there's little to no action that could be taken to avoid this, the risk would be marked as green. You should still document this risk and track it since low-cost opportunities might arise to mitigate it throughout the project.
Low Probability and Low Impact
What if your team lost a junior programmer?
If this is unlikely to happen, and if that person could be easily replaced, then this risk is low impact with low probability and is marked as green.
Probability of Occurrence | ||||
Low | Medium | High | ||
Impact on Project | Low | |||
Medium | ||||
High |
A risk with low impact and low probability can usually be ignored. You may still document these risks if there's a chance that they could have a higher impact than expected.
Medium Probability and Medium Impact
Risks with medium impact and medium probability are handled similarly. These risks must be monitored, but no actions are required to remove them since there will be little project disruption even if they occur.
Probability of Occurrence | ||||
Low | Medium | High | ||
Impact on Project | Low | |||
Medium | ||||
High |
They would be color-coded as yellow.
A risk register is a document that project managers can use to record risks, and may be updated throughout the life cycle of a project.
Risk registers should contain the following information:
Date | Risk | Probability | Impact | Contingency |
---|---|---|---|---|
1/10 | Backup system does not operate properly | MEDIUM | MEDIUM | Move testing of backup system earlier in project schedule to find issues sooner |
It's critical for the project manager to review the risk register often, update the information when needed, and report on existing risks to the key stakeholders.
Source: This work is adapted from Sophia Author Jeff Carroll.