RiskRegister

Abstract

Identifying risk in a project is always important in order to understand potential consequences related to given tasks and/or decision made within a project. Uncertainty and opportunities will always be present, and hence it is important to accommodate and grasp important factors, that might influence the outcome of a project and hence its success.

As the risk register tool presented in the PRINCE2 standard is a way of documenting and registering risk, it builds on other methods in order to locate more cryptic risks as well as how to deal with them. Hence he risk register is used as a risk management tool. However, more straight forward and easily identified risk are also added to the risk register and can be done so by the project manager, once updating or maintaining the document. In this document the risks are summarised, creating an overview of potential threats, risks and also opportunities.

Once risks are identified, the project manager can use the risk register tool to establish an overview of risk and potential threats or opportunities to the projects in a structured way. By filling in important information on the impact of the risk, the probability of the risk, how to handle the risk, amongst others, the project manager can locate and assign scores, indicating the importance of that risk being handled. Here manages should keep in mind, that assigned scores are based of the perception of the risk when added to the document and hence the quality of the risk register relies on an iterative and ongoing evaluation of registered risks. Noting down whether a risk has been handled or not is also an ongoing process that likewise is important in order to assure the quality of the risk register. Because of its simple structure the risk register can be reevaluated and adjusted on a day-to-day basis, by filling in the relevant information in the risk register document. This therefore makes it a simple yet effective tool in order to handle risks in a project.

Big Idea

The purpose of including a risk register in a project, as described in PRINCE2, is to record identified risks, that might have occurred in the begging or during the undertaking of the project. Here the risks history along with relevant information such as its impact and probability are captured and stored in a document of the project managers choice. By doing so, the project manager can use the risk register as identification of potential threats and opportunities related to the project. (CITE PRINCE2 side 329)

The risk register is a tool that the project manager can use in the beginning as well as throughout the lifetime of a project. As uncertainty will inevitably be bigger in the beginning of a project, as explained in “the paradox of project planning” (REF) the risk register is an important tool to an secure overview as well as a structured approach to coming risk, opportunities and uncertainties. The risk register can take many forms and can be both a document, a spreadsheet and other. The important part is here that the structure of such a document provides a detailed yet simple and easy overview of the discovered risks. If the document is created in such a way, the project manager will be able to track and accommodate for certain risks throughout the lifetime of a project. An example of how to setup the document will be given in the following section. Here it is important to mention, that the risk register is not a way of identifying risk and threats to a project, but rather a way of registering these risks. However, by using the risk register its overview and structure, might actually help the project manager see other potential risk. This way less cryptic risks can actually be identified as a consequence of applying the risk register, even if this is not its intended purpose.

As risk and uncertainties can appear throughout the lifetime of a project, the manager will be using a risk register be able to track which risk or opportunities that are currently present in the project. The manager should keep track of which risks that has been dealt with and which are yet to be handled and how. Therefore, this indicates that there for such a risk register is a certain need for detail. The project manager will not only have to identify risk and list them, but also weigh their importance to the project. The risk must therefore be scored on different parameters, that indicates their importance of being handled. How these risks are handled should also appear in the risk register. This way the project manager will be able to for example contact given employers ahead of time in case a risk related to their work is in need of being handled.

Application

• Risk identifier: Provides a unique reference for every risk entered into the risk register. It will typically be a numeric or alphanumeric value-Risk author
• Risk author: The person who raised the risk-Risk category
• Date registered: The date the risk was identified
• Risk category: The type of risk in terms of the project’s chosen categories (e.g. schedule, quality, legal)
• Risk description: Describes the risk in terms of the cause, event (threat or opportunity) and effect (in words of the impact)
• Probability, impact and expected value: I t is helpful to estimate the inherent values (pre-response action) and residual values (post-response action). These should be recorded in accordance with the project’s chosen scales
• Proximity: This would typically state how close to the present time the risk event is anticipated to happen (e.g. imminent, within the management stage, within the project, beyond the project). Proximity should be recorded in accordance with the project’s chosen scales
• Risk response categories: How the project will treat the risk in terms of the project’s chosen categories. For example:

1. for threats: avoid, reduce, transfer, share, accept, prepare contingent plans
2. for opportunities: exploit, enhance, transfer, share, accept, prepare contingent plans

• Risk response: Actions to be taken to resolve the risk. These actions should be aligned with the chosen response categories. Note that more than one risk response may apply to a risk
• Risk status: Typically described in terms of whether the risk is active or closed
• Risk owner: The person responsible for managing the risk (there should be only one risk owner per risk)
• Risk actionee: The person(s) who will implement the action(s) described in the risk response. This may or may not be the same person as the risk owner.

Limitations

When using the risk register and its limitations the project manager should be aware of whos interest and hence risk the register refers to. One stakeholders’ risk might not be a risk of another stakeholder. Therefore, the project manager will have to include enough relevant views upon the project to grasp the whole project, but at the same time be aware, that certain risk might only affect parts of the project. This therefore also somewhat contributes with a certain bias to determining the risk of certain perspectives, as it will be the project managers perspective and opinion to certain risk, that will dominate the risk register. An example of this could be if numerical values are assigned to the impact or probability of a risk. Here the numerical value will illustrate a perception of a potential risk, and hence be based on the given understanding of that risk.

Another limitation apart from that the project managers perspective has a heavy impact on the risk register is that the risk register will rely on other methods to potentially find and locate the seriousness of the risk. As the register is simply a tool to manage the risk, it is not a tool to locate more complicated and hidden risk that could potentially be located within a very specific are of the project. Similarly, the risk register does not solve the risk, but rather sums up and provides an overview of the risk found with other tools as well as potential solutions found, also by using other relevant tools. The risk register is therefore simply a registering and management tool, that can be used by the project manager, but therefor also reflects the perception, that the project manager brings to the project and the handling of risks.