Risk register

Revision as of 14:59, 26 November 2014

Example of a Risk Register used by SURF [1]

The uncertainty surrounding any decision, action or unprecedented occurrence that may negatively affect a project’s success can be defined as a risk and knowing how to classify, identify and document these risks is essential to the success of any project. This is because risk uncertainty can be difficult to control and predict; being able to communicate risk likelihood and the impact of this risk to a project team in an efficient way allows the team to evaluate risks together and identify to what extent they can prevent these risks from happening. Documenting risks from an early stage streamlines a team’s goals and their perception of the project, working as a communication tool and a risk management tool simultaneously. The risk register is an efficient risk documentation tool when it is used correctly within project management.

What is a Risk Register

Risk register within the project life cycle

A risk register is the baseline document of the process of managing risk (reference Winch); it is a means of visualising a project’s risks within a table or template so that risks can be better understood and dealt with by a project team. It allows risks, their likelihood and preventive measures for each risk to be recorded [3]. The risk register should be in a centralised location for information to be stored and updated with respect to the risks that are effecting the company; it is key that the risk register is used constantly throughout a project process.As can be seen in Graham Winch’s risk process diagram on the left hand side, throughout the life cycle of how a risk is dealt with, the risk register is the tool that should be constantly updated and referred to; it is the centre of all processes and decisions.

Generally, risk registers are created within a company's intranet or online database where the register can be updated by any member of staff and can be seen by any relevant project stakeholders. The register would then be made using database or spreadsheet software. A risk register could also be made offline however, being drawn on a whiteboard at a company meeting for example as a quick and efficient tool for motivating the meeting. The register must always be in a visual format however; visualisation is key to the success of the risk register tool.

Whenever an important decision is made within a project, the risk register is referred to. Whenever something unfamiliar is being dealt within a project, again the risk register should be referred to. This is how the risk register should be used, as a familiar tool that any member of a project team can come back to to ensure they can make the right decisions with a clear and focused mindset and without the need for a boss or authoritative figure being at hand. It therefore also reduces the time needed for project teams to carry out tasks, improving the efficiency of workers.

The risk register cannot only be used as a motivating risk management tool; it also has further uses as a documentation tool. Documenting information that is flowing into a project is incredibly important to manage risks affecting a current project but it also works as means of storing historical data. Ensuring that information is quickly available to you may be entirely necessary if a past client requires information about a past project [4]. Having a shared risk register would provide access to this information. It is also crucial in preventing future failures as risk registers become more and more effective as they are used more frequently within a company. Information about the uncertainty of a previous risk would allow a project manager to make a more educated decision about how to deal with the risk and would increase their own knowledge about these risks.

Implementation Advice

To use the risk register correctly, it is essential that the risks associated with the project are identified properly using a risk management plan [5]. A risk management plan should consist of utilising the help of relevant stakeholders and project team members to gather all risks prior to the risk register being created. Consulting everybody before the risk register is created increases the efficiency of the risk register; everyone who uses it is involved in its creation and all relevant risks should be covered and correctly recorded if everybody has an input from their respective departments.

Risk Impact/Probability Chart[2]

According to Winch (reference Winch), it is important to remember that one of the key ways to identify risks is to really on those with more experience. Consulting older project stakeholders on what risks are most relevant, where risks could occur or how risks could be dealt with is essential to defining risks for the risk register. Furthermore, tools can be used to ensure that risks are being identified in the right way.

Probability/Impact Matrix

Risks should be prioritised. By prioritising risks in the correct, a risk register becomes more relevant to the project and gives the user a clear understanding of how problems are being dealt with within the project. Categorising risks by how likely they are to happen and how much they will affect the organisation is a common practice that assists project managers in prioritisation of their risks. Using a tool such as the Probability/Impact Matrix allows the manager to define these risks by where they stand within the two dimensions. Risks closer to the lower left hand corner should be ignored whilst risks at the top right hand corner are of critical importance; they are likely to happen and will have a large impact on the project. Those in the top left hand corner generally are low impact risks that happen often, they should try to be reduced but should not affect the company much if they are unavoidable whilst bottom right hand corner risks are unlikely to happen but will have a high impact if they do occur- having a back up plan to deal with a risk like this would be wise. This is how the table categorises risks and from this, their risk likelihood can be transferred to the risk register.

Risk Matrix

A risk matrix [6] works in a similar way to the probability/impact matrix as the two dimensions used are identical. This matrix helps to define priority of risks in that it is colour coded. If the risk is in red then it should be treated with more importance than a risk in green. The risk can then be assigned a number taken by multiplying its probability value with its impact value. This tool is perfect to use in conjunction with a risk register as this number can then be transferred to the risk register and easily read by the user.

Using these tools, risks are properly identified and categorised. They can then be transferred to the risk register for use by the whole project team.

Layout

The key to a strong layout [7] for a risk register is that it must be easily comprehensible and concise. That way, any stakeholder can update the risk register or take information from the risk register quickly. There are a number of things that must be included within a risk register to convey information efficiently and quickly, however risk register can be expanded on to include more information depending on the type of project that is being dealt with. A larger scale project that has more of an impact on the company may require and expanded risk register with further headings to indicate all required information to a user. For projects that are shorter and possibly smaller in scale and impact, only the necessary headings may be used.

Necessary Headings

1. Risk name/number- A title, a number or a couple of words conveying what the risk is quickly. Much shorter than the description.
2. A brief description of the risk- A sentence or two or possibly a paragraph explaining what the risk is and what or who it would affect.
3. Likelihood of the risk occurring- It's probability of happening, taken from previous findings. Should be marked on an appropriate scale, eg a percentage scale perhaps.
4. Impact of risk- It's impact on the company were it to happen, taken from previous findings. Should be marked on an appropriate scale, eg a percentage scale perhaps.
5. Risk severity level- A combination of both likelihood and probability showing how important is the risk is dealt with. Should be marked appropriately, eg colour coded, words such as "high", "very low" etc.
6. Risk time- A date by which the risk should be dealt with or evaluated by; this allows the risk register to be more of an organisational tool.
7. Risk ranking- A heading that quickly portrays the importance of each risk with respect to each other.
8. Completion of the risk- A tick/cross or green/red indicating that the risk is active within the register.

Further Headings

1. Risk reduction plan- Any notes or plans that will reduce the likelihood of the risk occurring. This can be edited by any stakeholder as the project develops and risk reduction plans become more apparent.
2. Risk contingency plan- A solid plan on what to do in the occurrence of a risk. This is more beneficial as a heading for a risk that is in the top right hand corner of a probability/impact matrix (likely to happen, high impact).
3. Further description- Explicit details on which stakeholders would be affected and how the risk would affect QCT values.
4. Familiarity- A brief paragraph on how the risk has been dealt with in the past or whether or not the risk is unfamiliar to the project stakeholders. This information is vital if the risk is completely new and likely to occur.
5. Risk links- An explanation of whether or not the risk is codependent with another risk and whether or not this is relevant to the risk nature itself.

This is an example of how the risk register may be created however, due to project management being such a vast subject there may always be additional headings required or possibly even fewer headings required; it all depends on the nature of the project. However, this is certainly a good example of how a risk register should be designed if it is necessary to convey information about each risk quickly and visually.

Utilisation

The risk register should be used in conjunction with the rest of

Faults

Notes and Citations

= References = .