A risk matrix or stoplight risk matrix is a tool used in risk management to assess and visualize the likelihood and impact of risks.
On one dimension the likelihood or probability of the risk is measured. On the other, impact (sometime called severity or consequence) is measured.
Risks are then identified and scored on a psuedo-quantiative scale.
See also:
ROAM is an acronym used in risk-management to describe a process for managing risks. It stands for:
When ROAMing risks, you assign each risk to one of these categories to understand what needs to be done about it and who is responsible.
A resolved risk is one that is no longer a risk. This is generally because circumstances have changed either internally to the team or externally.
For example, a risk might be that that the webserver cannot handle the expected load. But a design change was introduced to horizontally scale the service behind a cloud-based load balancer. This change could make this risk negligible.
In short, a resolved risk is one you no longer need to keep track of.
An owned risk is one that is still a risk, but someone has taken responsibility.
That could be internal to the team. For example, a risk might be that the team doesn't have the expertise to build a particular feature. One team member takes on the responsibility to learn the necessary skills. The risked is now owned by that team member and until they have the necessary skills and share those skills with the team, it remains a risk.
Alternatively, external ownership could be assigned. For example, a the shared responsibility model of cloud providers means that some risks are owned by the cloud provider. The risk of a server failure, power issues, or physical security is owned by the cloud provider.
An accepted risk is one that is still a risk, but the team has decided to accept the risk in its current state. I've worked with many student teams who design small remote-controlled aircraft. The canonical example I used with them is "none of you have flown an RC aircraft before, what is the likelihood that you will crash the aircraft on the first flight?" The answer is always "ummm ... very high." Yet, the team still plans to try to fly the aircraft.
The risk is inherent in the project, only so much can be done to mitigate it (more on that in the next section), yet the project proceeds. The team has accepted the risk.
A mitigated risk is one that is still a risk, but the team has taken steps to reduce either the likelihood of the risk occurring or the impact of the risk if it does occur.
Considering the RC airplane example again, teams generally took one of two paths to mitigate the risk of a crash. Some teams opted to build their aircraft out of carbon fiber to ensure the body of the aircraft could withstand a crash. Others chose to use a low cost material like balsa wood or foam and construct spare parts so that they could quickly repair the aircraft after a crash. Still others opted to practice flying RC aircraft or bring in a more experienced RC pilot to reduce the likelihood of a crash.
These approaches all reduce either the likelihood or consequence of the risk. Thus the risk is mitigated, but not resolved.
Pseudo-quantitative numbers are used when it useful to give something a quantiative score, but that score is determined from non-quantative or unmeasurable information.
For example, in risk management, the impact of a risk might be scored on a scale of one to three. The buckets 1-3 might have descriptions such as "low, medium, and high" or criteria like 1 is "less than a day of work to recover" and 3 is "we will go out of business".