Identifying risk in a project is always important in order to understand potential consequences related to given tasks and/or decisions 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.
The risk register, used in both the Project Management Institute Body of Knowledge (PMBOK) and PRINCE2 standard, is a document that contains relevant information on discovered risks and/or possibilities. As it is included in both of these standards, it is, therefore, a widely-recognized tool. This tool enables the project manager to record and register risks and opportunities within a given project. As this tool is simply used to register risk, it builds on the use of other methods to locate risks, as well as, how to deal with them. Hence, the risk register is used as a risk management tool. In the risk register document, the risks are summarised, creating an overview of potential risks and opportunities. As this gives an increased overview more straightforward and easily identified risks are potentially discovered once using the risk register and also added to the register.
As the risk register is a risk management tool, it is constructed and maintained by the project manager. This helps to assure, that only relevante information and relevante risks aligning with the projects interest are entered into the document. The project manager can, however, find assistance within the project support group once discussing and filling in the relevante information. The document should be kept in a secure place and only be accessed by certain people in order to secure its quality.
Once risks are identified, the project manager can use the risk register tool to establish an overview of risk, potential threats, and/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, managers should keep in mind that assigned scores are based on 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. Therefore, this makes it a simple yet effective tool to handle risks in a project.
The risk register is both a part of the Project Management Institute Body of Knowledge (PMBOK) as well as PRINCE2, and hence, it is a widely-recognized tool to manage risk . 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 beginning or during the undertaking of the project. Here, the risk history along with relevant information, such as its impact and probability are reported and stored in a document by the project manager's choice. By doing so the project manager can use the risk register as identification of potential threats and opportunities related to the project.
This tool is a tool that the project manager can use in the beginning, as well as, throughout the lifetime of a project. However, as uncertainty will inevitably be bigger at the beginning of a project, as explained in “the paradox of project planning”  the risk register is an important tool to secure an overview and a structured approach to coming risk, opportunities, and threats. The risk register can take many forms and can be both a document, a spreadsheet, or something similar. The important part is that the structure of such a document provides a detailed yet simple and easy overview of the discovered risks. If the document is created correctly, the project manager will be able to track and accommodate certain risks throughout the lifetime of a project. An example of how to set up such a document will be given in the following section.
It is important to mention, that the risk register is not a way of identifying risks, opportunities, and threats, but rather a way of registering them. However, using the risk register, the overview, and structure, might actually help the project manager see other potential risks . This way less cryptic risks can actually be identified as a result of applying the risk register, even if this is not its intended purpose.
As risk and uncertainties can appear throughout a project, the manager will be using a risk register to track which risk or opportunities are currently present in the project. The manager should keep track of which risks have been dealt with, which are yet to be handled and how as well as weigh their importance to the project. The risk must, therefore, be scored on different parameters that indicate 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 the necessary employees ahead of time, in case a risk related to their work needs to be handled. Therefore, this also indicates, that a risk register requires a certain level of detail.
A risk register does not require any certain programs or tools although programs can be found for creating a risk register. It can simply be custructed by creating a document, spreadsheet, or something similar. The project manager can choose the option that is preferred and set up the risk register in four simple steps.
- Create the document
- Choose and fill in the relevant aspects for the given project
- Fill in the information on found risks
- Follow up on risks that have been handled and maintain the document by adding new potential risks together with adjusting existing risks
When applying the risk register, it is as mentioned important to create a simple yet detailed overview. By doing so, the project manager will be allowed to keep track of the important risks and opportunities related to the project. The project manager should, therefore together with the project support group, find the categories/aspects that they find most informative for the project and list these in the document. They should avoid overcomplicating the document in order to decrease complexity and hence preserve the overview that allows them to decide on how and what to act on.
A way of creating either a list, table, matrix, etc. is found in the standard of PRINCE2 and listed below. When choosing a selection of these, the project manager should keep in mind which aspects support one another and paint the picture, that would best benefit the project.
- "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: The person who raised the risk
- 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: It 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:
- for threats: avoid, reduce, transfer, share, accept, prepare contingent plans
- 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."
Once the categories have been chosen and listed, for instance as a table as done in the example, the project manager can start filling in the information. Assigning the Risk Identifier is simply done by assigning a unique value to each risk, and upon assigning the impact and probability of a risk the project manager can choose to either assign numerical values or alphabetical values. When looking at the probability and impact each individual score is, of course, important, but really it is the link between the impact and its probability that determines its threat to the project. This idea of seeing the correlation between categories and their impact on the project is the benefit of the risk register overview and hence what the project manager should keep in mind when using this tool.
What to do with the information
By looking at the given example it is in this case clear that the project manager should pay attention to risk number 1 as this has both a higher impact, as well as, a higher probability. However, in some cases, it might be that some risks are easier to handle than others. The project manager will have to manage and control which risks that should be focused on as it will be a balance between multiple criteria within the risk register. In case the project manager focuses on impact and probability, the summarising risk profile from PRINCE2  can be used to assist the risk register, plotting the impact and probability. This allows the manager to visually see which risk should be given attention based on these two factors. For further analysis, the project manager could also use the ARTA (Avoid, Reduce, Transfer & Accept) approach to determine how to handle the risks (See relevante aspects - risk response categories).
As the practical application of this tool has now been presented, it is important to keep in mind that this simply is a tool ment to assist the project manager to perform the best possible action. Therefore, this also calls upon a certain level of quality to ensure that the project manager is in fact basing his/her actions upon reliable and trustworthy information. By using the list of quality criteria presented in PRINCE2, the project manager will ensure that the risk register is, in fact, reliable. These criteria should both be filled into the risk register, as well as, used as precautions to secure the document and the project's interests.
- “The status indicates whether action has been taken.
- Risks are uniquely identified, including information about which product they refer to.
- Access to the risk register is controlled.
- The risk register is kept in a safe place." 
As the risk register is used throughout a project and impacts the decision-making of the project manager, the manager needs to know which conclusions he/she can draw from this tool and which aspects are outside the scope of this tool.
First, the project manager should be aware of who’s interest and hence risk the register refers to. One stakeholders’ risk might not be the risk of another stakeholder and thus, it does not represent both stakeholders’ interests and precautions. The risks included in the risk register might also not refer to the same areas in a project, and therefore, the project manager will have to include enough relevant aspects from the project to grasp all areas of the project and hence its related risks. At the same time, the project manager must however be aware, that certain risks might only affect parts of the project, and therefore, their influence might be of different characteristics and hence they can not give the total risk of the project as a whole .
As there will be different interests and thereby risks, as well as, areas of impact, opportunities, etc. the project manager will somewhat contribute to the risk register and hence the project with some bias. This means, that it will be the project manager's perspective and opinion on certain risks 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 project managers as well as the project support groups understanding of that risk . In this regard, the project manager is expected to secure the project’s interest, and he/she will be the one responsible for the risk register in order to secure the project's interest rather than a particular stakeholder’s interest, for example.
Another limitation, apart from the project manager's perspective, that has a heavy impact on the risk register is that the risk register will rely on other methods to potentially find and locate risks, as well as the severity of these risks. Similarly, the risk register does not solve risks, but rather sums up and provides an overview of risks found with other tools. It likewise relies upon potential solutions found by using other relevant tools.
Project Management Institute. (2017). A Guide to the Project Management Body of Knowledge (PMBOK® Guide). Project Management Institute.
The PMBOK that was overseen by The Project Management Institute (PMI) sets the American standard for the way of doing project management. It is a flagship within project management in any industry and its explanation and inclusion of the risk register play a vital role in the decimation and acknowledgment of this tool. It includes many aspects related to risk and hence provides context to the risk register and how it can be used to support projects.
Managing Successful Projects with PRINCE2. (2017). Managing Successful Projects With Prince2. The Stationery Office Ltd.
The PRINCE2 is originally a UK government standard for project management, that focuses on dividing projects into smaller more manageable tasks. It serves as a standard, as well as, a practitioner certification program. In this case, the PRINCE2 presents both a clear purpose and a relevant aspect to be included in the risk register. Therefore, it is relevant as it sets focus on the use of this tool and presents specific guidance for project managers on how to create and build the risk register. It also brings context to the tool and addresses, how this tool can be used and fit into a wider range of analysis to prevent and handle risk in projects.
Samset, K., & Volden, G. H. (2016). Front-end definition of projects: Ten paradoxes and some reflections regarding project management and project governance. International Journal of Project Management, 34(2),
This article focuses on and discusses the processes happening and evolving in the early stage of a project. It addresses aspects and paradoxes related to decision-making in an early stage, where many decisions must be made. Here, the information will be low and uncertainty will be high indicating that there will be certain risks related to the undertaking of the project. Therefore, it touches upon important aspects when it comes to managing risks in a project, and shines a light upon when and where risk and uncertainty might affect decision-making.
Hillson, D. (2014). Managing overall project risk. Paper presented at PMI® Global Congress 2014—EMEA, Dubai, United Arab Emirates. Newtown Square, PA: Project Management Institute.
As this paper is presented by PMI, it aligns with previously introduced literature, but introduces a more critical point of view upon risk assessment and its limitations. Here, the focus is upon the link between individuel risk and their contribution to the understanding of a more overall perception of risk within projects referred to as "overall project risk". Therefore, this also applies to risk added to the risk register and discus the limitations of these.
- ↑ Project Management Institute. (2017). A Guide to the Project Management Body of Knowledge (PMBOK® Guide). Project Management Institute.
- ↑ Managing Successful Projects with PRINCE2. (2017). Managing Successful Projects With Prince2. The Stationery Office Ltd.
- ↑ 3.0 3.1 Managing Successful Projects with PRINCE2. (2017). Managing Successful Projects With Prince2. The Stationery Office Ltd., Page 329
- ↑ Samset, K., & Volden, G. H. (2016). Front-end definition of projects: Ten paradoxes and some reflections regarding project management and project governance. International Journal of Project Management, 34(2), 297–313. https://doi.org/10.1016/j.ijproman.2015.01.014, Page 301
- ↑ https://www.stakeholdermap.com/risk/risk-register.html, visited 18/02/2021
- ↑ Managing Successful Projects with PRINCE2. (2017). Managing Successful Projects With Prince2. The Stationery Office Ltd., Page 130
- ↑ Managing Successful Projects with PRINCE2. (2017). Managing Successful Projects With Prince2. The Stationery Office Ltd., Page 330
- ↑ Hillson, D. (2014). Managing overall project risk. Paper presented at PMI® Global Congress 2014—EMEA, Dubai, United Arab Emirates. Newtown Square, PA: Project Management Institute.
- ↑ https://www.civilsociety.co.uk/finance/why-risk-registers-don-t-do-enough-to-help-you-manage-risks.html, visited 18/02/2021