This tutorial we'll discuss how to classify and record project risks by focusing on:
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.
For the likelihood that the risk will occur, the project manager gives each risk a rating of high, medium, or low.
If a risk has a low probability and will not have a negative impact, then it doesn't need to be documented.
High, medium, and low rankings are also given to the negative impact a risk will have on the project.
Low impact and low probability of occurrence risks have little effect on a project:
Medium impact risks are bad but survivable in the short term; they will not stop a project from succeeding.
High impact risks will cause significant harm to the project. These risks are called “project killers” because they have the potential to end 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:
Green indicates a risk that currently requires no action.
Yellow shows risks that require tracking by the project manager. These risks are monitored regularly, and stakeholders should receive updates on status reports.
Red signifies risks that require immediate mitigation.
The project manager should be reporting on the status of these risks often, sometimes on a daily or even hourly basis, depending on the issue.
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.
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.
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.
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 to just monitor the risk more closely.
With medium probability, there is a choice to either mitigate or monitor. So this risk would be color-coded as yellow.What if key stakeholders made the decision 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.
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 over the course of the project. 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.
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. 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. 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.
When making a risk register, multiple contingencies should be created for high impact risks. For low impact risks, no contingencies are needed; however, these risks can still be tracked to see if they evolve into greater risks.
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.
In this lesson, you learned how to use the risk matrix by rating risks and the color-coding associated with risks. You now understand how project managers respond to different risk classifications, and how to use the risk register to monitor risks throughout a project's life cycle.
Source: This work is adapted from Sophia Author Jeff Carroll.
A technique to analyze the impact and probability of each potential risk that is used to determine if actions are required to mitigate a risk.
Identified occurrences that if they occur will have a negative impact on project scope and project success.
Risks that would severely impact project success and potentially kill a project from advancing.
Risks that are very likely to occur and therefore need to be watched closely or mitigated to reduce project impact.
A living document that records project risks during the life-cycles of a project.