Source: Image of cube, hand moving cube, Creative Commons, Kelly Eddington; Image of arrow, man at laptop, Images by Video Scribe, License held by Jeff Carroll.
Hi, I'm Jeff, and in this lesson, we'll discuss how to classify and record project risks. Risks should be identified in the early phases of a project, but the project manager should continue to search for new risks and monitor and manage existing risks over the life cycle of the project. A consistent method to classify and document risks is necessary for success, so we'll learn about that next.
To classify risks consistently, project managers use a tool called a risk matrix. As you might remember from an earlier lesson, 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. High means the risk is likely to occur. Medium is a risk that may occur, but there is not a general expectation that it will happen. And low probability risks are unlikely to occur, but will still have a negative impact if they do occur. 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 will have little impact on a project. Medium will be a bad but survivable risk in the short term, but will not stop a project from succeeding. And high impact means the risk will cause significant harm to the project. We call these risks 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. And red, which requires 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.
Next we'll talk about how the project manager handles risks with different classifications. Let's imagine that we're managing a project that's been tasked to create a new customer support system for our organization's website. But 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. There could be many mitigations for this risk, but the primary mitigation would be either to hire an outside group to develop the site or to hire designers and programmers experienced with these systems.
But what if your organization did have experience with customer support sites, yet it was still a complicated project? Then there would still be the risk that the system would not work, and the impact of this risk would still be high, but the probability of it occurring could be moved to medium. In that case, the project manager might choose to hire additional experienced programmers to further offset the risk, or to just monitor the risk more closely. With medium probability, you can choose to mitigate or monitor. So this would be color coded as yellow.
What would be a high impact risk with a low probability? In the case of our project, this might be a decision by key stakeholders to move the web server to another development platform. It's unlikely to occur, but it could kill the work on the current project were it to occur. Since there's little to no action that could be taken to avoid this, the risk would be marked as green. The project manager should still document this risk and track it, since low cost opportunities might arise to mitigate it over the course of the project.
A risk with low impact and low probability can usually be ignored. Some project managers will still document these risks if there's a chance that they could have a higher impact than expected. An example on our project would be the loss of a junior programmer. If that person could be easily replaced, then the impact would be minimal. These risks are marked as green.
Medium impact and medium probability risks are similar. These risks must be monitored, but no actions are required to remove the risk, since even if it does occur there will be little project disruption. Yellow is the color code for these risks.
To document these risks, project managers can use a risk register. This document can be updated throughout the life cycle of a project. A risk register should contain the following information: the date the risk was recognized and documented; a short description of the risk; the classification of the risk's impact and the probability that it will occur from the risk matrix; and the contingencies to use to avoid the risk, or if the risk occurs.
Multiple contingencies should be created for high impact risks. For low impact risks, no contingencies are needed, but 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.
And that's how a project manager classifies and records risks. Nicely done. In this lesson, you learned how to use the risk matrix, you know the color coding associated with risks, you learned how project managers respond to different risk classifications, and you understand how to use the risk register to monitor risks throughout a project's life cycle. Thanks, and have a great day.
