+
4 Tutorials that teach Classifying and Recording Risks
Take your pick:
Classifying and Recording Risks

Classifying and Recording Risks

Rating:
Rating
(0)
Description:

This lesson provides an overview of identifying and classifying project risks.

(more)
See More
Try a College Course Free

Sophia’s self-paced online courses are a great way to save time and money as you earn credits eligible for transfer to over 2,000 colleges and universities.*

Begin Free Trial
No credit card required

26 Sophia partners guarantee credit transfer.

226 Institutions have accepted or given pre-approval for credit transfer.

* The American Council on Education's College Credit Recommendation Service (ACE Credit®) has evaluated and recommended college credit for 21 of Sophia’s online courses. More than 2,000 colleges and universities consider ACE CREDIT recommendations in determining the applicability to their course and degree programs.

Tutorial

What's Covered

This tutorial we'll discuss how to classify and record project risks by focusing on:

  1. Risks
  2. Risk Rating

1. RISKS

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.

Terms to Know

    • Risks
    • Identified occurrences that if they occur will have a negative impact on project scope and project success.
    • Risk Matrix
    • 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.

2. RISK RATING

For the likelihood that the risk will occur, the project manager gives each risk a rating of high, medium, or low.

  • High probability= likely to occur.
  • Medium = may occur, but not a general expectation that they will happen.
  • Low probability = unlikely to occur, but will still have a negative impact if they do occur.

Hint

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.


Terms to Know

    • High Impact Risks
    • Risks that would severely impact project success and potentially kill a project from advancing.
      • High Probability Risks
      • Risks that are very likely to occur and therefore need to be watched closely or mitigated to reduce project impact.

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.

IN CONTEXT

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.

3. RISK REGISTER

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:
  • 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, as displayed on the risk matrix
  • The contingencies to use to avoid the risk, or if the risk occurs

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.

Term to Know

    • Risk Register
    • A living document that records project risks during the life-cycles of a project.

Summary

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.

Good luck!

Source: This work is adapted from Sophia Author Jeff Carroll.

Terms to Know
  • High Impact Risks

    Risks that would severely impact project success and potentially kill a project from advancing.

  • High Probability Risks

    Risks that are very likely to occur and therefore need to be watched closely or mitigated to reduce project impact.

  • Risk Matrix

    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.

  • Risk Register

    A living document that records project risks during the life-cycles of a project.

  • Risks

    Identified occurrences that if they occur will have a negative impact on project scope and project success.