The largest projects in the world, from the summer olympics to big petrochemical projects, have one major thing in common at the project management level – a relentless focus on risk. What happens if there is a riot? Or a catastrophic explosion? What if protestors disrupt the project, or regulatory agencies reject it?
These large megaprojects must allocate a small but important part of their budget to studying risk events and ensuring the adequate response plans are in place in advance of their potential disruption.
If it makes sense on large projects, doesn’t a proportional amount of risk analysis make sense on any size project?
The backbone of a solid risk management plan is called a risk register.
What is a Risk Register?
A risk register is an itemized listing of the risks that could derail the project. For example, a supplier delivering their product late.
The Project Management Body of Knowledge defines a risk register as a document in which the results of risk analysis and risk response planning are recorded. It is created within the context of the overall project management plan and/or risk management plan (if applicable).
Risk Register Example
Here is an example risk register:
| Risk Register | |||||
|---|---|---|---|---|---|
| ID | Risk | Probability | Impact | Contingency | Risk Response Plan |
| 1 | Rain delay | 20% | 5 days | 1 day | Read weather forecast daily. Inform supervisor of poor forecast the previous day |
| 2 | Poor quality welding | 10% | $3,000 | $300 | Inspect welding prior to end of day |
How to Create a Risk Register
There are three steps to creating a strong risk register:
- Risk Identification
- Risk Analysis
- Risk Response Plans
Risk Identification
A strong risk identification process is central to good project risk management.
There are many techniques that can be used to develop a listing of risks, but here are the most important:
- Brainstorming
Whether alone or in a group, brainstorming involves focusing on quantity over quality. Just write everything you can think of on paper, and then come back and narrow down the list later. - Subject matter experts
There is no substitute to having experts in subject matter advising you of the risks involved with the work. Often they are in other departments but their advice is second-to-none. - Checklists
Although we have a generic checklist, it is best to eventually develop a specific one for you organization or type of project. - Lessons learned
Few organizations maintain a lessons learned database, but it is an invaluable tool. It’s a collection of project summaries, a record of problems encountered, mistakes made, and what the project manager would do differently in future projects. When you’re starting a new project and you spend a few minutes reading that, how can you go wrong? - Documentation review
This involves learning about the project, its technical details, and its people. The higher risks will be present in the non-standard tasks that haven’t been performed by the organization before. - SWOT Analysis
A Strengths-Weaknesses-Opportunities-Threats analysis will assist in drawing out the risks inherent in the project. Particularly the Weaknesses and Threats quadrants can yield some new risks. - Delphi technique
This method involves querying a group of people or subject matter experts, then sharing all of the answers anonymously with the whole group and letting them revise their original answers. After several rounds a consensus should emerge. - Assumptions analysis
Every project contains certain underlying assumptions upon which its business case is built. Identifying these assumptions, and analyzing their reliability, can result in the identification of new risks. - Influence Diagrams
Drawing out a simple decision network for the major turning points within a project can yield the important risks.
Obviously it is not possible, nor is it a desirable goal, to list all risks to a project. The real world simply contains too many variables. But a risk register is there to provide the project manager with a swift and decisive response when things go wrong.
The following example illustrates the Risk Register after the Risk Identification step:
| ID | Risk |
|---|---|
| 1 | Rain delay |
| 2 | Poor quality welding |
Risk Analysis
There are two types of risk analysis:
- Qualitative Analysis
- Quantitative Analysis
Qualitative Analysis
This involves assigning each risk in the register a probability and impact score.
Risk has two components:
- Probability. The statistical chance that the risk event will occur.
- Impact. The consequences of the risk event.
For small projects each risk event can be given a score of 1-10, A-E, or similar in both categories. For larger projects it might be prudent to put the Probability on a scale of 1-100 (i.e. a percentage) and the Impact the actual impact on the project. This can be a monetary value, schedule impact, or whatever the actual impact is.
For example, you could decide that there is a 20% chance that the project will be delayed 5 days due to rain. In this case the Probability is 20% and the Impact is 5 days. Another example would be that there is a 10% chance that the welder will have to return to fix deficiencies at a cost of $3,000.
Both of these examples are typical to real projects and easy to obtain from real data from previous projects (or first hand experience).
After qualitative analysis, our example risk register looks like this:
| Small Projects | |||
|---|---|---|---|
| ID | Risk | Probability | Impact |
| 1 | Rain delay | 7 | 2 |
| 2 | Poor quality welding | 2 | 6 |
| Intermediate Sized Projects | |||
|---|---|---|---|
| ID | Risk | Probability | Impact |
| 1 | Rain delay | 20% | 5 days |
| 2 | Poor quality welding | 10% | $3,000 |
Quantitative Analysis
Once each risk event is given a Probability and Impact score, it is analyzed and compared to the other risks to determine a prioritization. Quantitative analysis involves the use of analytical tools to determine the effect of the risk on the project.
For small projects the two scores on a scale of 1-10 can be multiplied together to determine the overall priority of the risk. This will not yield a meaningful project impact value but it will provide you with a prioritized ranking of the project risks. Communicating this list to clients or stakeholders can be very effective in the absence of any other analysis, and can be appropriate for small projects.
| Small Projects | ||||
|---|---|---|---|---|
| ID | Risk | Probability | Impact | Priority |
| 1 | Rain delay | 7 | 2 | 1 |
| 2 | Poor quality welding | 2 | 6 | 2 |
For intermediate size projects, the Probability is on a scale of 1-100 and the Impact is given as the actual impact. The quantitative analysis step consists of multiplying the two together to get a meaningful value for the risk event’s consequences to the project. For example:
- 20% chance of being delayed by 5 days = 0.20 x 5 days = 1 day.
- 10% chance of welder returning to fix deficiencies at a cost of $3,000 = 0.10 x $3,000 = $300.
In order to ensure these risk events are covered the schedule would be increased by 1 day and the budget would be increased by $300.
The task which receives the changes is not always obvious. For example, if there is a task called “welding” it would obviously receive the budget increase, but what about the rain delay? It can be added to any one task or averaged throughout all of them.
The risk register now looks like this:
| Intermediate Sized Projects | ||||
|---|---|---|---|---|
| ID | Risk | Probability | Impact | Contingency |
| 1 | Rain delay | 20% | 5 days | 1 day |
| 2 | Poor quality welding | 10% | $3,000 | $300 |
These values represent the ideal contingency. In other words, if you performed the project many times this value will cover those potential risk events.
It could also be seen as a fair insurance premium if you were to attempt to remove the risk via purchasing insurance, performance bonds, or the like.
Finally, for large projects, it could be prudent to perform more detailed analyses:
- Monte Carlo analysis involves assigning a probability distribution to risk events and running many random simulations to determine what the actual budget/schedule probability outcome for the overall project is.
- Running simulations or lab tests to determine the potential real world occurrence of theoretical events.
- Consult probability tables. Probability values of known events can often be looked up and then combined to produce tangible probabilities of other real world events. For example, the probability of rain events in most parts of the world are known. The number of days during the project in which rain would delay it is also well known. The statistical probability of rain delay on the project can then be calculated.
Risk Response Plans
The third and final step in the production of a risk register is the creation of response plans.
There are four ways to respond to each risk event within the risk register:
- Avoid. Eliminate the threat or protect the project from its impact. For example,
- Change the scope of the project.
- Extend the schedule to eliminate a risk to timely project completion.
- Change project objectives.
- Clarify requirements to eliminate ambiguities and misunderstandings.
- Gain expertise to remove technical risks.
- Transfer. This involves moving the impact of the risk to a third party. Direct methods might be through the use of insurance, warranties, or performance bonds. Indirect methods such as unit price contracts instead of lump sum (or vice versa depending on which side of the contract you’re on), legal opinions, and so forth.
- Mitigation. Reduce the probability or impact of the risk. This is not always possible and often comes with a price that must be balanced against the value of performing the mitigating action.
- Accept. All projects contain risk. As a minimum, there is the risk that it does not accomplish its objective. Thus stakeholders, by definition, must accept certain risks. Accepting risk is a strategy like any other, and should be documented and communicated like any other strategy. Risk acceptance can be passive, whereby the consequences are dealt with after the risk occurs, or active, whereby contingencies (time, budget, etc.) are built in to allow for the consequences of the risk to the project.
The Risk Register will Change
Throughout the project the risk register will be in a constant state of change. As the real world presents new risks the risk register must be updated to ensure it contains the most accurate risk profile of the project. On top of that, the project manager is constantly designating risks on the register as expired because the associated tasks are complete.
But at any time, a risk can occur and the other risks should be reassessed. One of the following three things could occur:
- The risk has been eliminated
- The priority has been changed (probability and/or impact)
- The risk event has been triggered. It is now an issue.
Whether you’re a veteran risk manager on megaprojects or a technical project manager on small projects, everyone can benefit from the use of a risk register.
Good luck with your risk register and let us know in the comments if you have anything to add.
