Corporate Services for the Natural Resource Sector
<Note: Replace (or delete) bracketed
and/or Green text with required information>
[Project Name]
<Name of Ministry>
Risk Management Plan
Project Manager:
[Business Portfolio Manager]
Creation Date:
<Date – YY/MM/DD>
Last Updated:
<Date – YY/MM/DD>
Document Number: 6450-25/<Project Name>
Version:
X.XX <Increment with changes>
Approvals:
Project Sponsor
Signature
Date
Signature
Date
<Name>
<Title>
<optional others>
<Name>
<Title>
Document1
of 16
Page 2
Purpose of Document
The purpose of this document is to describe the approach and process for managing project
risks. The risks themselves will be documented in an associated risk register that will include
the risk action plan.
The Security, Threat and Risk Assessment (STRA), Privacy Impact Assessment (PIA), Financial Risk
and Controls review, and Quality Management/Assurance-related documents complement the
risk management plan.
Table of Contents
Purpose of Document ......................................................................................................................3
1.0
Project Purpose ..............................................................................................................4
2.0
Risk Management Approach and Process ......................................................................4
2.1
Definition of Risk ............................................................................................................... 4
2.2
Roles and Responsibilities ................................................................................................. 4
2.3
Risk Management Process Overview ................................................................................ 5
2.4
Identify Risks ..................................................................................................................... 6
2.5
Assess Risks ..................................................................................................................... 11
2.6
Develop Strategy ............................................................................................................. 13
2.7
Take Actions .................................................................................................................... 14
2.8
Monitor Actions .............................................................................................................. 14
3.0
Risk Management Schedule .........................................................................................14
4.0
Risk Register / Risk Management Action Plan .............................................................15
5.0
Reviews and Document Control...................................................................................16
Document1
of 16
Page 3
1.0
Project Purpose
<copy from the Project Charter or Project Plan if appropriate, and expand as necessary>
The purpose of the project is to …

<Provide a concise statement of what the project is to achieve, its mission or goal.>
Related documents:






2.0
2.1
Project Charter dated <date>
Master Project Plan dated <date>
Communications Plan dated <date>
Privacy and Impact Assessment (PIA)<date>
Security, Threat and Risk Assessment (STRA) <date>
Etc.
Risk Management Approach and Process
Definition of Risk
A project risk is a characteristic (i.e. inherent nature), a circumstance (i.e. issue, event etc.) or an
aspect of environment (i.e. internal/external organizational factors) of a specific project that is
recognized to have a potential effect (positive or negative) on the project or the quality of its
deliverables.
2.2
Roles and Responsibilities
The Project Manager <or enter role> has overall accountability to ensure that project risks are
appropriately managed. The actual task of risk management is, however, a team effort of the
project management organization, including the Project Sponsor, Project Steering Committee
and the Project Manager:

The Project Sponsor and Steering Committee will be informed of all significant risks
where the impact is imminent, and/or where appropriate actions have not yet been
taken. Assistance will be sought from the Project Sponsor and Steering Committee to
address risks that are beyond the control of the Project Manager. The Risk
Management Plan must be signed off as one component of the project approval
process.

The Project Manager <or enter role> is responsible for ensuring that risks impacting the
delivery and operations of this project are identified and appropriately managed. Where
the identified risks are beyond the Project Manager's authority to manage, the Project
Steering Committee <or enter role> should be notified so that the risk management can
be escalated to the appropriate level.

Team members are responsible for ensuring risks that impact their deliverables are
identified and appropriately managed.
Document1
of 16
Page 4
2.3
Risk Management Process Overview
Risk Management is a cornerstone of the overall project planning and approval process. The
approved Risk Management Plan and associated Risk Register are deliverables of the NRS SDLC
planning and analysis phases. The Risk Register will be regularly updated throughout the project
lifecycle.
As the project moves through its various stages, identified risks may change or new risks may be
identified. In order to track and control changing risk, the Risk Register will be re-evaluated and
updated at least, but not limited to, after each major phase or checkpoint of the project <or
insert frequency>. Major risks will be reported on monthly <or insert frequency> in the project’s
status reports. The Risk Management Plan will identify when mandatory risk assessments will
occur and these events will be included in the overall project workplan. Also see Section 3, Risk
Management Schedule.
The diagram below provides a summary of the approach and process to be applied in managing
the risks associated with the project and documenting in the Risk Register.
Document1
of 16
Page 5
Risk Categories:
External Environment
Project Sponsorship
Project Management
Unintended Consequences
1. Identify Risks
1. Identify Risks
2. Assess Risks
2. Assess Risks
Risk Probability
Risk Severity
Risk Tolerance
Risk Ranking
Project Sponsor
Project Steering Committee
5. Monitor Actions
5.
Monitor
Actions
Log
Risks
3. Develop Strategy
3. Develop
Strategy
Threat:
Opportunity:
Avoid
Transfer
Mitigate
Accept
Document Action Plan
Followup on status
Evaluate action
results
Exploit
Share
Enhance
Accept
Project Manager
4. Take Actions
4. Take Actions
Plan Actions
Assign Actions
Communicate
Escalate
Plan Contigencies
2.4
Identify Risks
Any project team member can identify risks during the course of the project. If a team member
identifies a potential risk, he/she should report it to his/her respective project manager, who in
turn will decide whether to log it as an issue in the Issue Log or a risk in the Risk Register.
The following techniques will also be employed to identify risks during the project: <choose the
methods that will be used for this project and add/remove others.>
Technique
Document1
of 16
Description
Responsibility
Page 6
Project Assumption
Analysis
Risks will be identified by considering assumptions made
throughout the project.
[name, role]
Experience-Based
Risk Assessment
Risks will be identified by the project team members and
subject matter experts drawing upon their collective
experience.
[name, role]
Review of Lessons
Learned from
Similar Projects
Risks will be identified from a review of predecessor
versions of the project and other similar projects.
[name, role]
Semi-structured
Interviews
Risks will be identified by interviewing key stakeholders and
project staff to discuss and rank order list of potential risk
factors prepared from a master list of risks.
[name, role]
Brainstorming-Based
Risk Assessment
Risks will be identified through periodic brainstorming
sessions held throughout the course of the project
involving key project personnel.
[name, role]
Delphi Technique
Risks will be identified by eliciting information and
judgments from participants to identify risks without
physically assembling the contributors but using
information exchange via mail, fax or email
[name, role]
Nominal Group
Techniques
Risks will be identified by generating and posting ideas on a
flip chart or electronic spreadsheet, and then allowing
members to evaluate them silently, eliciting one new idea
from each member, discussing each idea in order,
conducting a preliminary vote on importance of each
item, analyzing and discussing voting patterns and then
conducting a final vote.
[name, role]
Checklists (used
during the scoping
stage of risk
assessment)
Risks will be identified by compiling a series of checklists
and keeping them up-to-date to ensure all significant
issues are discussed
[name, role]
Risks can be divided into four major categories:
1. External Environment Risks: Those risks as a result of influences outside the
sponsoring organization.
2. Project Sponsorship Risks: Those risks as a result of project leadership, executive and
partner commitment, governance and readiness within the organization where the
project is sponsored and the product will be delivered.
3. Project Management Risks: Those risks as a result of managing the project.
4. Unintended Consequences or Results: Those risks related to the product itself and its
ability to meet the original objectives and intentions.
Document1
of 16
Page 7
Risk Category
1.
Description
External Environment
1.1
 Political/ citizens values,
priorities and changes to
political direction
Is the project consistent with political
direction and prevailing citizens’ values?
1.2
 FOIPP; and any recent changes
in legislation or interpretation of
the legislation
Has PIA been completed and what significant
risk factors have been identified?
1.3
 Legislation, Statutes, Regulations
and Bylaws; new or proposed
changes
Have knowledgeable staff and stakeholders
been consulted to ensure compliance with
relevant legislation (etc.) and identify
potential risks?
1.4
 Gov’t and Ministry Policies and
plans
Same as above for each of the government
and ministry policies and plans, partners’
policies, plans and priorities and federal
legislation and policies, as relevant
 Partners policies, plans and
priorities
 Federal legislation and policies
1.5
 Stakeholders, users and public
expectations
What are expectations from the project by the
users, partners, public/political and other
stakeholders? How do these compare with
likely results?
1.6
 Organizational, user and
stakeholder readiness
Are the external groups ready for the business
transformation and culture change as a result
of the project? Identify potential risks.
1.7
 Union agreements
Do any union agreements impact project
delivery and/or project’s impact on any union
agreement?
1.8
 Economy
Are there any other external factors to
consider?
 Weather etc
2.
Project Sponsorship
2.1
 Executive leadership
 Ministry support
 Partners commitment
 Political, citizen and client
support
Document1
of 16
Client management risks may exist where the
project clients have some degree of
uncertainty regarding the need for the project
or objectives of the project or where multiple
clients exist that may have conflicting
understandings of the project.
Page 8
Risk Category
 Clear and appropriate
governance
 Stakeholders, users and citizen
expectations
Description
Risks may arise where there is a possibility of
change within the organization during the life
of the project. Risks are high where key
personnel such as the project sponsor may
change or where the priorities or mandate of
the organization may change.
2.2
 Funding commitment
Funding risks are related to the certainty of
project funding. Risks will be attributed as
high where all or a portion of project funding
is uncertain or dependent on events that are
themselves uncertain.
2.3
 Organizational, users and
stakeholders readiness
Are the internal groups ready for the business
transformation and culture change as a result
of the project? Identify potential risks.
3.
Project Management
3.1
 Business and organizational
issues
Risks related to general business, project
and/or organization issues.
3.2
 Staffing
Do available staffing and skills meet project
requirements?
 Contracts and subcontractor
management
 Legal
Risks related to contractual commitments and
exposure to legal action.
3.3
 Financial and other resources
Risks related to project budget and costs;
Other resource risks arise in situations where
a project relies on a limited number of
specialized resources, shares resources with
other projects, or where the availability of
project resources is uncertain.
3.4
 Project motivation and morale
Risks that reflect a lack of desire or motivation
to achieve the objectives of the project.
 Risk management integrated
into project mgmt
 Internal communication
 Stakeholders and clients
consultation
3.5
 Project Scope, Objectives, and
Outcomes
Document1
of 16
Risks related to scope arise where it has not
been clearly defined what is within and what
is out of project scope and where a danger
exists of the scope changing during the
Page 9
Risk Category
Description
project.
3.6
 Project complexity
The greater the complexity of the project in
terms of balancing multiple goals, numerous
concurrent activities, new methods or
technologies, complex technology
implementation, multiple organizational units
to coordinate, the higher the potential for
risk.
3.7
 Project schedule
Schedule risks reflect uncertainties in task
duration or dependencies. Higher risks in this
category reflect a low level of confidence in
the estimation of task duration or the
sequencing of tasks
3.8
 Project Deliverables:
System integrity and information integrity
considerations should be addressed at a high
level during planning and approval phase but
would be critical criteria in risk assessment in
the project design phase. Risks in project
deliverables relate to the existence of
processes that will measure the quality of
project deliverables including results &
milestones including system features such as
security, availability, safety and information
integrity. A fundamental aspect of the utility
of information is its compatibility with that
from other systems and jurisdictions for
shareability and integration. Consequently,
compatible standards and data dictionary are
an important element of risk assessment.
Where processes are not in place to measure
the quality of deliverables or where, due to
the nature of the deliverables, it is difficult to
measure the quality of key deliverables, high
risks may exist.
- System Integrity
- Security
- Availability
- Integrity
- Safety
- Information Integrity:
- Quality
- Standards
- Confidentiality
- Privacy
Has a STRA been started or completed and
what significant risk factors have been
identified by it?
Document1
10 of 16
Page
Risk Category
4.
4.1
Description
Unintended Consequences or Results
 Not meet client’s true objectives
 Unanticipated outcomes: too
much use, new uses
 Unintended new clients
 Unintended financial results
Risks related to delivering a product that does
not work the way it was hoped, or is not used
the way it was intended. It may be underutilized, over-utilized, or mis-used. It may not
interface well with related systems or
functions. It may not work well under stress.
It may be too costly to operate or maintain.
High risks will occur if objectives were not well
defined or the project will result in major
business change and the business
organization is not well prepared for the
change.
4.2
 Requires changes to technology
infrastructure: software,
hardware, networks
Technology risks are attributed to the role of
technology in the project, attributing higher
risk when project objectives are dependent on
new technologies and when a majority of the
technology employed by the project is new or
highly complex.
4.3
 Requires change to business
processes, organizational
structure and culture
Organizational changes in the client area as a
result of the project, such as changes in job
function, union concerns or major change to
procedures and/or policies can cause project
risk.
 etc
2.5
Assess Risks
The focus of the project risk management process is determining likelihood of occurrence and
consequence to the project of the identified risks. Risk assessment will be performed in order
that risk management efforts can be properly directed.
Each risk will be assigned a Risk Likelihood and Risk Consequence number used to generate the
Risk Importance (Rank) number. As shown in the diagram below, each risk is rated on its
likelihood of occurring and consequence or impact if it does occur. The organization’s
thresholds for low (green), moderate (yellow), high (orange) and extreme (red) risk as shown in
the matrix determines the risks rank/importance.
The following two tables provide the risk assessment scoring grid. The third table shows the
resulting level of risk from the assessment, including the four ranges of risk assessment:
Red:
Document1
11 of 16
Extreme risk; immediate action required; senior management usually involved.
Page
Orange: High risk; management responsibility should be specified and appropriate action
taken.
Yellow: Moderate risk; managed by specific monitoring or response procedures.
Green: Low risk; manage by routine procedures.
Table 1: Likelihood
LIKELIHOOD
Descriptor
Description
5
Almost certain
It is expected to occur in most circumstances. 75% chance.
4
Likely
Will probably occur sometime. 50% chance.
3
Possible
Might occur at some time. 25% chance.
2
Unlikely
Could occur but not very likely. 10% chance.
1
Rare
Would only occur under exceptional circumstances. 2% chance or less
Level
Table 2: Consequence
CONSEQUENCE
Level
5
Descriptor
Catastrophic
Crucial
4
Major
3
Moderate
2
Minor
1
Insignificant
Description
(Threat) Will almost certainly kill the project.
(Opportunity) Will have a huge benefit to overall project success
(Threat) Could threaten the survival of the project as presently defined.
(Opportunity) Major benefit to overall project success
(Threat) Will significantly affect the project in some manner but not threaten
its survival.
(Opportunity) Will significantly help the project in some manner
(Threat) Will threaten the efficiency or effectiveness of some aspect of the
project, but will be dealt with internally.
(Opportunity) Will help the efficiency or effectiveness of some aspect of the
project, and will be taken advantage of internally.
Can be dealt with or taken advantage of routinely.
Table 3: Level of Risk
Likelihood
5 (almost certain)
4 (likely)
3 (possible)
2 (unlikely)
1 (rare)
Legend:
20-25 (Red):
Document1
12 of 16
Insignificant
1
5=M
4=M
3=L
2=L
1=L
LEVEL OF RISK
Consequences / Impact
Minor
Moderate
2
3
10 = H
15 = H
8=M
12 = H
6=M
9=M
4=M
6=M
2=L
3=L
Major
4
20 = E
16 = E
12 = H
8=M
4=M
Catastrophic/Crucial
5
25 = E
20 = E
15 = H
10 = H
5=M
Extreme risk; immediate action required; senior management usually involved
Page
10-19 (Orange)
4-9 (Yellow):
1-3 (Green):
2.6
High risk; management responsibility should be specified and appropriate action taken
Moderate risk; managed by specific monitoring or response procedures
Low risk; manage by routine procedures.
Develop Strategy
The risk management strategy involves developing actions to address the risks that are above
the project's risk tolerance level. The risk tolerance level for this project has been defined as
those risks deemed High and above <or enter risk level>. Risks that are assessed as High <or
enter risk level> must have a risk management action plan and should be presented at the
Project Steering Committee for discussion and/or resolution. Risks that are assessed as Extreme
<or enter risk level> must be considered “near certainties” and should be taken forward
immediately for discussion and/or resolution.
The risk management response strategies generally fall into one of seven categories:

Avoidance of threat (negative risk) – eliminating the specific threat, usually by eliminating
the cause (e.g. using proven technology, changing a policy, eliminating the requirement by
de-scoping). The project management team can never eliminate all risk, but specific risk
events can often be eliminated.

Exploitation of opportunity (positive risk) – performing actions to ensure the opportunity is
realized.

Transference of risk (negative risk) – transferring the risk to another party such as
contracting it out, or by acquiring insurance. This does not eliminate the risk, but can
significantly reduce it (possibly introducing some new risk in the process).

Sharing of opportunity (positive risk) – allocating ownership to another party who is better
able to capture the opportunity for the benefit of the project (e.g., joint ventures,
partnerships)

Mitigation of threat (negative risk) – reducing the impact of the risk by reducing the
likelihood of occurrence (e.g. building internal controls into systems design), reducing the
consequence (e.g. piloting with a smaller group), or both.

Enhancement of opportunity (positive risk) – proactively increasing the probability and/or
positive impact resulting from the opportunity.

Acceptance (both negative and positive risk) – accepting the risk and the consequences.
Acceptance can be active (e.g. developing a contingency reserve or plan to execute should
the risk event occur) or passive (e.g. accepting cost overruns on some activities, or letting
the opportunity occur on its own).
Document1
13 of 16
Page
2.7
Take Actions
Each identified risk in the Risk Register (Section 4.0) will be assigned to a specific individual who
will be accountable for implementing the action plan associated with the risk.
Communication of risk information to decision-makers (Project Sponsor and Project Steering
Committee members) is important to the success of risk management. Risks that are assessed
as High <or enter risk level> and above, and the actions to address these risks, must be
communicated to the Project Steering Committee. In some cases where the risk events are
inter-jurisdictional or the consequences are imminent, it may be necessary for the Project
Steering Committee to intervene to ensure that risk management actions are taken at the
appropriate level of management.
Contingency plans may also be developed where considered necessary by the Project Manager.
2.8
Monitor Actions
The Project Manager <or enter role> is responsible for logging, assigning responsibility for
resolution and monitoring the status of actions in the Risk Register.
Follow-up on the status of the action plans will be done on a periodic basis. The frequency will
be higher for High <or enter risk level> risks. The date that the risk is logged will also be a
determining factor for the follow-up reviews.
The risks will be reassessed and the results of actions taken will be reviewed as part of the
follow-up review sessions. A minimum of one review session to identify risks will take place
during the planning stages for each phase and subsequent review sessions will be identified in
the Project Plan <or identify when and how>.
3.0
Risk Management Schedule
The following table is the proposed schedule for updating the Risk Register. The dates for the
milestone events listed here are as known or expected at the time of writing. Refer to the latest
project workplan for more definitive dates.
<These are sample Checkpoints that could apply to a standard NRS IM/IT application
development project. Add,remove, or change the checkpoints to reflect the project.>
Risk
Register #
Checkpoint
1
Project Planning & Initiation
2
Analysis
3
Design
Document1
14 of 16
Review Date
Page
4.0
4
Build
5
Implementation
6
Evaluation
Risk Register / Risk Management Action Plan
The Risk Register describes the details of all the identified risks including:









Categories
Descriptions
Event Triggers
Impacts to objectives
Response Strategy
Actions
Responsibility Assignment
Due Date
Status
The Risk Register changes over time and can be referenced at <insert location>.
<You may also attach the Risk Register or an initial summary here.>
Document1
15 of 16
Page
5.0
Reviews and Document Control
Reviews
This document has been sent to the following for their review and comment.
Name
Position
Project Management
Name
Position
<name>
Project Manager
Document Control

<Drafts start at 0.1 whereas a document ready for signature becomes version 1.0. >
Date
Version
Change Reference
<date>
0.1
Original document
Document1
16 of 16
Reviewed by
Page