Tool: Risk Registers
Type: Spreadsheet
Everybody knows about it. No one really knows how to use it.
Common mistakes I've seen when people use a Risk Register.
A Risk Register is simply a spreadsheet that lists down all the project risks as well as tracks the progress of the responses to the said risk. The important things to see in a Risk Register are:
A Risk Description describes the Risk. The proper way of describing risks is to state it in a form of a probability such as "Building might collapse" or "testing might not complete on time". Do not just simply state an object or predicament - state the activity involved that might occur. Describing the risk in the said manner is not only for conventions' sake, but rather it helps in formulating the proper response since the risk is viewed from a very precise probability.
Probability is simply a number. Depending on the organizations' preference, it can be 1-100, 1-10, or 1-3, where the highest number signifies the most probability. I normally don't advise using 1-100 unless you can actually determine a risks probability. Otherwise, you are arbitrarily creating complexity.
Impact is also a number (similar to probability) depicting the level of severity of a risk in the event that it occurs. The highest number signifies the highest, or most severe impact.
Rating is the product of Impact and Probability. The objective of this column is for us to have an idea on what specific risks we'd like to prioritize on. The PM needs to define the threshold by which risks are to be managed and what risks should be accepted.
A Risk Response basically defines how the risk is to be managed. There are many ways to respond to a risk. These include:
Moreover, reviewing the Risk Register should happen at a regular basis. A good practice would be to include reviewing the Risk Register as part of the agenda during project team meetings. Everyone in the project team should be encouraged to read and review the Risk Register as they may be able to contribute to the said document. Also, the more that people are actively aware of what the risks are, the lesser that chances of people actually contributing to the possibility of the risk from occurring.
Type: Spreadsheet
Everybody knows about it. No one really knows how to use it.
Common mistakes I've seen when people use a Risk Register.
- People often put down a list of risks in the Statement of Work, Proposal, Initial Project Plan and.. and... and... that's it. They forget all about it.
- People define risks in the vaguest most obscure manner possible. Some folks (no, not you) state risks such as "Fire"... "Earthquake"... "Programmer Problem"..."No support"... etc
- Mitigation is the ONLY way of managing a risk. Unfortunately, mitigation is all the way up there in the top ten lists of useless business jargon such as Best Practice, Right-sizing, and Can-do.
A Risk Register is simply a spreadsheet that lists down all the project risks as well as tracks the progress of the responses to the said risk. The important things to see in a Risk Register are:
- Risk ID
- Risk Description
- Probability
- Impact
- Rating
- Response
- Response Status
A Risk Description describes the Risk. The proper way of describing risks is to state it in a form of a probability such as "Building might collapse" or "testing might not complete on time". Do not just simply state an object or predicament - state the activity involved that might occur. Describing the risk in the said manner is not only for conventions' sake, but rather it helps in formulating the proper response since the risk is viewed from a very precise probability.
Probability is simply a number. Depending on the organizations' preference, it can be 1-100, 1-10, or 1-3, where the highest number signifies the most probability. I normally don't advise using 1-100 unless you can actually determine a risks probability. Otherwise, you are arbitrarily creating complexity.
Impact is also a number (similar to probability) depicting the level of severity of a risk in the event that it occurs. The highest number signifies the highest, or most severe impact.
Rating is the product of Impact and Probability. The objective of this column is for us to have an idea on what specific risks we'd like to prioritize on. The PM needs to define the threshold by which risks are to be managed and what risks should be accepted.
A Risk Response basically defines how the risk is to be managed. There are many ways to respond to a risk. These include:
- Mitigating Probability - which is looking for ways to lessen the probability that a risk will occur
- Mitigating Impact - which is looking for ways to lessen the impact of the risk when it occurs
- Avoidance - which is performing activities wherein the source of the risk is avoided altogether. To illustrate bluntly, if you would like to avoid the risk of not getting wet if it rains going out of the office - you should not go out at all. This avoids the said risk altogether.
- Transference - which is transferring the risk to another person or entity. If I want to transfer the risk of getting wet while going out if it rains, then I will ask someone else to go out for me. The risk is still there... but I do not carry the said risk anymore.
- Acceptance - which is basically accepting the impact of the risk. You typically accept risks that are either too low probability or low impact.
Moreover, reviewing the Risk Register should happen at a regular basis. A good practice would be to include reviewing the Risk Register as part of the agenda during project team meetings. Everyone in the project team should be encouraged to read and review the Risk Register as they may be able to contribute to the said document. Also, the more that people are actively aware of what the risks are, the lesser that chances of people actually contributing to the possibility of the risk from occurring.
