Risk Register Examples - Risk Management Process Steps

Project Risk Management Process

Project Risk Management is a basic task for any project manager no matter how big or small the project. Below is a simple 3 step process for project risk management which includes identifying risks, documenting them and then monitoring them.

Risk Management Process Steps

Step 1 : Identify project risks

• The identification of risks should be done before the project starts so this is the first step in the risk management process.

• Generally, the project manager will conduct a risk assessment workshop.

• The workshop should be conducted with the project team and the stakeholders.

• The project manager should have an open discussion with the team and stakeholders to understand if they have any concerns with the project.

• During this exercise, you might discover issues which already exist in the project.

• The project team should be able to discuss issues which could be related to day to day execution of the projects.

• In an IT project, these could be lack of skills, lack of environments or lack of requirements.

• The stakeholders which could be the senior management or business managers could provide some insight into organizational impacts of the project, impact on the business or lack of visibility etc.

• In some organisations the project risks and issues are part of the project proposal or initiation documents.

• It is the responsibility of the project manager to make sure that the project proposal document has all the risks documented.

Generally, you would be able to classify the risks into at least two categories - project and organizational. Project risks would be the risks which are related to the project - example is resource dependency. Organizational risk would be any risk can affect the reputation of the entire organization - example would be a security breach or privacy violation caused by a project.

Examples of common types of risks encountered in IT Projects -

• Resourcing Issues - generally some one is going on leave or leaving the organisation.

• Technical Challenges - most of the projects will have some sort of technical challenges.

• Change Management - the project team and stakeholders may not be confident that the project change will be well managed.

• Quality Risk - If there are any risks that the quality of the project deliverable may not meet the quality assurance of the organisations.

• Schedule Risk - Are there any factors which can affect the project schedule? Does the project need any new environments?

Step 2 : Document Risks and Issues In The Register

Risk Register Sample

After you have identified all the risks and issues as a project manager its your responsibility to create a issues register and risks register. This is the second step in the risk management process.

Risk Register - A risk register is a document which is used to capture project risks. It can contain the following -

• Risk Serial Number - sequence number for risks for the current project.

• Risk Title - title for the risk. This needs to be short and crisp.

• Risk Description / Impact - detailed description of the risk. It is important to clearly explain what is the impact if the risk eventuates. Generally, there would be a schedule impact or budget impact.

• Identified Date - Date on which it was identified.

• Risk Category - Project or Organisational. You may check with PMO or Risks department to understand if there are any other categories.

• Risk Sub-Category (Optional) - Budget, resourcing, schedule,quality etc.

• Status - Open, Closed.

• Owner - name of the person or team which is responsible for mitigation. Try and specific here as the person who is responsible for this risk needs to know that he or she should be doing something.

• Risk Rating - Critical, high, medium and low.

• Possible Mitigation - Steps which can be taken to mitigate the risk.

• Date Closed - the date on which the risk was closed.

• Comments(optional) - a free text field.

Issues Register - The issues register will be similar to the risks register. In fact it can be simpler than the risk register. You can have the following fields for an issues register -

• Issue Serial Number - sequence number for risks for the current project.

• Issue Title - title for the issue.

• Description / Impact - detailed description of the issue.

• Identified Date - Date on which it was identified.

• Status - Open, Closed.

• Owner - name of the person or team which is responsible for mitigation.

• Issue Impact - Critical, high, medium and low.

• Action Taken - Steps which are taken to address the issue.

• Date Closed - the date on which the issue was closed.

• Corresponding Risk(optional) - If the issue is related to an already identified risk.

• Comments(optional) - a free text field.

Step 3 : Monitor Project Risks and Issues

The most difficult part of project risk management. Majority of the project managers religious follow step 1 and step 2 but then do not monitor the project for new issues and risks. Monitoring of the risks can be done in a few ways -

• Always keep an eye on the count of risks and issues. If you have too many "highs" then its time to review the list.Having regular risk and issue registers review with the project team.

• You can make it part of the project team meeting.

• Attend all the project meetings - technical requirement gathering, scrum meetings, review workshops, demo etc. to identify any new issues or risks.

• Include the current risks and issues in the project status report.

• Make the senior management and stakeholders aware of risks and issues on a regular basis.

• Including risks/issues in the status reports will make sure that everyone goes through the risks and issues on a weekly basis.

Risk Categories

Managing risks is a key activity of any project and it is can be so challenging that there’s even a joke about risk management being project management for adults!
However, that doesn’t mean that it is an impossible task and in this article, I’m going to help you understand one of the most useful tools for risk management: the Risk Breakdown Structure (RBS).

Risk Breakdown Structure

Risk Breakdown Structure

A Risk Breakdown Structure (RBS) is a very visual tool for project managers in the way that it is a hierarchical tree that decomposes the risks of a project into categories, according to the source of risk. A RBS can be a useful prompt to identify new risks and ensure that no threat is being neglected, as well as to check where do risks concentrate the most and to identify dependencies between risks.

A RBS is very simple to build and very powerful to communicate with your project team and stakeholders. Some of the categories to consider include:

• Technical: Relates to any technical risks for the project, such as the risk that the design is not suitable for the product, the risk of slow performance, poor quality, or that not all requirements are met.

• Resources: Relates to any risks regarding resources employed in the project, either human resources, materials, or money. For instance, the risk that funding is insufficient, or that key resources are unavailable due to holidays.

• Suppliers: Relates to any risks regarding the provision of services of products by a third party. It includes the risk of procurement activities taking too long, contractual risks, and the risk of poor performance and delays by suppliers.

• External: Relates to any risks arising from an external source, outside the project, such as environmental risks, or the risk of new legislation that can constraint the scope or delivery of the project.

• Project Management: Relates to any risks deriving from the way the project management team is managing the project, such as the risk of lack of sponsorship, poor communication, or poor stakeholder engagement, just to mention a few.

Given that the purpose of a RBS is to assist project managers in ensuring that no risk goes unnoticed, there should be a RBS template defined at the organization level, typically a responsibility of the enterprise project management office (PMO).

Risk Register Examples

Risk Register Examples

Risk Impact Assessment

Once risks are identified, the next step is to assess their likelihood and how they can impact the project. A risk, by default, can have a negative impact (threat), however, the severity of that impact can vary. Impact refers to the effects or consequences the project will experience, should the risk materialize, in terms of schedule, finances, scope, quality, and attainment of benefits.

While the very uncertain nature of risks makes it difficult for risks to be predicted and accurately assessed, it is important that, within the organization, there is a shared understanding of different risk impacts so that everyone is speaking the same language when it comes to risk management.

Risk Register Examples

Risk Register Examples Showing Impact

Hence, organizations tend to define a scale of impact to assess risks, typically represented using a scale of 3 (low, medium, high) or 5 levels. Here’s what it means each of the different impact levels:

The Scale of Impact To Assess Risks:

• Level 1 Insignificant: risks which do not pose any significant concern at the time.

• Level 2 Marginal: risks that are deemed to have just a minor impact on the project.

• Level 3 Moderate: risks which will affect the project with some significance.

• Level 4 Critical: risks that have a high impact on the project and require strong monitoring.

• Level 5 Catastrophic: risks that will jeopardize the whole project should they materialize.

By assessing the probability and impact of risks, risk can then be mapped into a matrix, enabling the project manager to quickly identify which risks to focus on.

Risk Register Examples

Information about the category of the risk and its assessment is captured in a Risk Register, the day-to-day tool for risk managing by the project manager. Here are some examples of what a Risk Register looks like:

Risk Register Example 1

ID	Risk	Category	Owner	Probability	Impact	Mitigation
1	Resources are unavailable to carry out testing during August	Resources	Joe Blog	3	4	Re-schedule testing; appoint deputy resources
2	The final product does not meet requirements	Technical	Matt Damon	2	5	Follow an iterative approach; establish intermediate approval cycles
3	Poor performance of the product	Technical	Matt Damon	3	3	Include stress testing into test cases

 

Risk Register Example 2

ID	Risk	Category	Owner	Probability	Impact	Mitigation
1	Lack of buy-in by end-users	Project Management	Mariah Carey	3	4	Invite representative of each end-user group to attend requirement gathering workshops
2	The final product does not meet requirements	Project Management	Oprah Winfrey	2	3	Work with the Comms department to emphasize the importance of training
3	Poor performance of the product	Resources	Mariah Carey	2	4	Prepare a business case with the Sponsor to be presented at the next Finance Committee meeting so that funds can be secured for the project

 

Risk Register Example 3

ID	Risk	Category	Owner	Probability	Impact	Mitigation
1	Poor sponsorship	Project Management	Steve Jones	2	3	Escalate to the Project Board
2	Contract takes too long to be drafted	Suppliers	Steve Jones	3	3	Work with the Procurement team to timely gather their requirements
3	Changes to the SOX legislation	External	Miranda Roberts	1	4	Arrange regular calls with our contact in the Financial Authority

 

It’s impossible eliminate and to account for all risks, but with proper risk identification, assessment, and mitigation, you’ll certainly be in a better place in your project. Make no mistake: risk management should not be underestimated.