Read and Delete This Page Before Use

Permissions
You are free to use this template for your professional activity in your organization and with your team.
You are not allowed to distribute this template. If someone wants to use this template, they should get
their copy from my site. Please send them to https://pmbasics101.com/risk-register/.

I strongly recommend that you get my Risk Management Resource Guide. It will help you learn project
risk management. You will adapt this template with fewer mistakes and inefficiencies. 

1. One-page Cheat Sheet on Risk Management Processes.

2. Quick access to articles and videos that explain Risk Management processes.
3. Access to other templates (Risk Register)
4. Special Video: How to Adapt PMBOK Guide Processes to Software Projects.  

Click here to get access to the resource guide.

Why do you need a Risk Management Plan?

In most organizations, you don't need to have a Project Management Plan as a formal document.
However, it's still beneficial to have the main processes described. After you adapt the Risk
Management Plan to your project needs, I recommend putting it on your project's Wiki page.

1. Present it to the whole team and get their buy-in.

2. Refer to it when you need to manage risks and explain it to new team members.
3. Update it together with the team as needed. It will develop a feeling of ownership
4. Use it as a guiding principles for risk management.

Also, save it for future needs. You never know whether your next project will require a formal Risk
Management Plan.

It's a template. It's a starting point. Here's what you need to do:
1. Read through the sections.
2. Adapt to the processes that you have using the same explanatory language.
3. Add links to the tools you use.
4. Please don't get too specific; it's not an in-depth document.
5. Adjust format and styles to your company.
6. Add a branded title page with the following information:
1. Project Risk Management Plan
2. Project Name
3. Created by: <Your Name>
4. Date
7. Review and delete all places marked with yellow.
Introduction
This document describes how the project team will manage the project risks, roles and
responsibilities, and tools they use.

For the purpose of this document, the term "Project" means one release cycle from initiation to
the deployment to the market in the overall software development life cycle.

{Ideally, you should have a separate document or section that describes the project life cycle.
Don't assume that stakeholders know it! Learn more here: }  

A Risk is an uncertain event or condition that, if it occurs, has a positive or negative effect on a
project's objectives.

The main flow of Project Risk Management includes the following processes:

1. Risk Identification
2. Qualitative Risk Analysis
3. (Optional) Quantitative Risk Analysis
4. Planning Risk Responses
5. Implementing Risk Responses
6. Monitoring Risks

This project team follows the principle of one tool. As much as practical, we will keep all project
documentation in Confluence {Google Docs, MS Office 365, Asana, ClickUp, etc.}. All team
members and authorized stakeholders should have access to documentation and the ability to
collaborate on it.

The main access point is here: {URL to Risk Management Documentation}

Project Manager is responsible for educating the project team, clients, and key stakeholders in
proper risk management skills. PM should initiate and facilitate all related activities.

Risk Identification
During the whole project lifetime, all stakeholders and project team will continuously identify
risks. All the time, we should ask simple questions, "What can go wrong here? Do you see any
risks?"

All identified risks should be logged into the Risk Register. Don’t judge or discard risks without
proper analysis.
It's acceptable to perform risk analysis in batches at a later date. Project Manager is responsible
for timely updates of the Risk Register.

Access Risk Register here: {Link to Risk Register. Get a Risk Register Template in my Resource
Guide}

The Project Team will use the following techniques with the scrum team, subject matter
experts, and stakeholders:

1. Interview
2. Meeting
3. Brainstorming
4. Requirements Analysis
5. Project Documentation Review
6. Delphi Technique
7. Expert Interview

Besides continuous identification, the team will perform a dedicated risk identification session
for the following events/artifacts:

1. During all grooming sessions.

2. During a review of the release plan.
3. Analysis of work breakdown structure.
4. When a change request is approved.
5. During a review of architectural design.
6. During the sprint planning meeting.

Project Manager is also responsible for identifying risks outside of the Project Team. Project
Manager will review and analyze the company's Risk Categories on a regular basis.

Risk Breakdowns Structure is located here: {Link to Risk Breakdown Structure. Get access to list
of risk categories in the resource guide}

Budget, Risk Tolerance, and Thresholds

{Project Manager should discuss Risk Appetites, Tolerance, and Thresholds with clients. It's a
critical input for your Risk Management Plan. It will dictate your overall methodology, analysis,
and responses for the project. You need to put this information below.}

Risk Appetites is a general and subjective description of an acceptable risk level.

Risk Tolerance is a measurable and specific level of risk.

Risk Threshold is a particular point at which risks become unacceptable.

{This section is an example. You need to provide actual information from your clients!!!}

The overall risk management budget should not exceed 15% of the project's estimate.

Our releases have strict deadlines, and we have a fixed budget for the team. Therefore, risks to
schedule and budget are unacceptable.

Our overall strategy is to generate alternative solutions for the project requirements/scope that
will still meet project objectives.

Qualitative Risk Analysis

The goal of this process is to make a list of risks that require a proactive response. We should
also identify urgent risks that require a response right now.

Project Team should assess all risks in the Risk Register and identify Probability and Impact.

Impact is a level of effect that risk will have on the project.

Probability is a level of likelihood of occurrence of the risk.

It's not an in-depth analysis. Project Team should spend an adequate amount of time to assess
the risks.

The project operates under the dedicated team model. Therefore, we will represent a risk's
impact in the team's effort, for example, person-days.

As we develop the product as a series of product releases, we calculate risk management

efforts within the boundaries of one release (project).

{ This matrix is the most critical part of this document.

You need to adjust the tables below based on your environment and risk appetites.
Here's my trail of considerations. Suppose I have three months release cycle. For example, it
will include six two-weeks sprints.
Each sprint has a 10% built-in reserve—one working day for the whole team to cover
unknowns, extra defects, unexpected sick leaves, etc. Low-impact risks drain these reserves
first of all. So, in general, we should be able to soak up several low-impact risks in each sprint
without disturbing stakeholders.
Medium-impact risks drain the reserves and add more work that's still possible to compensate
throughout several sprints or by adding an extra sprint.
As a side note, at the start of a release, we should always be open to the possibility of adding or
removing one sprint of work. Otherwise, it's a too-tight schedule constraint for agile project
management.
High-impact risks add the amount of work that warrants an additional sprint for the whole
team.}

Impact Grades

Rating Interpretation
Project Failure. The project is not feasible within the
10
given constraints.
Over the project's deadline by 50%. Project goals and
9
constraints are out of sync. Feasibility is at risk.
High Over the project's deadline by 40%. More than two
8 sprints of additional work. At this scale, risks become
unpredictable without further analysis.
Over the project's deadline by 30%. Up to two
7
additional sprints of work.
Over the project's deadline by 10-20%. 6-10 additional
6
working days of the team or full sprint of work.
A slight impact on the release deadline. One such risk
will warrant additional working days for the team. It can
5
be extra days after the last sprint or overtime on
Medium
weekends.
Serious impact on reserves. One such risk will drain
reserves from all release sprints. Moreover, it puts the
4
deadline at risk. Additional risks will put us beyond the
deadline.
A medium reduction of reserves. One such risk will
3 impact a sprint's goals. We can regroup and catch up in
the following sprints.
Low A slight reduction of reserves. Several such risks may
2
impact a sprint's goals.
Neglectable impact. Several such risks may reduce
1
reserves.
Probability Grades

Rating Interpretation
10 A Fact
9
8 High Probability
7
6
5 Medium Probability
4
3
2 Low Probability
1
Impact-Probability Matrix

10
9
High 8
7

Probabilit 6
y Med 5
4
3
Low 2
1
1 2 3 4 5 6 7 8 9 10
Low Med High
IMPACT

Legend:
Red – risks that warrant a response.
Yellow – risks that require further analysis and investigation.
Green – risks that can be ignored.
Quantitative Risk Analysis
It's not cost-efficient to perform Qualitative Risk Analysis for this project.

In exceptional cases the Project Team may calculate the monetary value of critical risks and
develop a decision tree.

Planning Risk Responses

All Risk Responses should be logged in JIRA as Impediments or Tasks. These JIRA entries should
be linked to the risks in the Risk Register. Risk Responses are part of the project Scope, Budget,
and Schedule.

To overcome systematic risks, the project team may introduce additional processes and
workflows. They should be properly documented and approved by the Department Manager.

Project Team may plan Risk Responses as additional tasks, reserves of time, reserves of budget,
or adjustments to processes. Other types of Risk Responses should be developed in
collaboration with Clients and Department Manager.

Each Risk Response Plan should have a dedicated Owner. It should be a specific person who will
monitor the risk and collaborate on risk response implementation. The owner of the risk has
total responsibility for the risk. In case of issues, the risk should be escalated to the Project
Manager.

Implementing Risk Responses

The Risk Owner is responsible for:

1. Monitor the assigned risks.

2. Reporting on the progress of response implementation.
3. Reporting any changes to the risks.
4. Identifying and logging any secondary or residual risks.

Project Manager is responsible for the overall control of all Risk Management activities.

Project Team will discuss immediate risks daily during Scrum Meetings.

Project Manager will report on the immediate risks on every Status Report Meetings.
Monitoring Risks
During the whole lifetime of the project, the Project Team will continuously monitor the
existing risks. It will also have regular activities to identify new risks.

1. Project Team will review Risk Register regularly.

2. Project Team will have regular brainstorming sessions.
3. Risk Owner will control risk's Impact and Probability.
4. Risk Owners will assess the efficiency of Risk Responses.
5. Risk Owners will keep Risk Register up-to-date.
6. Project Manager will continuously coach the team and clients on the best practices of
Risk Management.
7. Subject Matter Experts may conduct risk audits on demand.