NRS Project Charter Template - British Columbia · Web viewThe actual task of risk management is, however, a team effort of the project management organization, including the Project

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

<Name>

<Title>

<optional others> Signature Date

<Name>

<Title>

document.docx Page 2 of 16

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 ContentsPurpose 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....................................................................................................................12

2.6 Develop Strategy............................................................................................................13

2.7 Take Actions...................................................................................................................14

2.8 Monitor Actions..............................................................................................................14

3.0 Risk Management Schedule........................................................................................15

4.0 Risk Register / Risk Management Action Plan.............................................................15

5.0 Reviews and Document Control.................................................................................16


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:

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.

2.0 Risk Management Approach and Process

2.1 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.


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.


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 Description Responsibility


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.


Risk Category Description

1. 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

Partners policies, plans and priorities

Federal legislation and policies

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

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

Weather etc

Are there any other external factors to consider?

2. Project Sponsorship

2.1 Executive leadership

Ministry support

Client management risks may exist where the project clients have some degree of uncertainty regarding the need for the



Partners commitment

Political, citizen and client support

Clear and appropriate governance

Stakeholders, users and citizen expectations

project or objectives of the project or where multiple clients exist that may have conflicting understandings of the project.

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

Contracts and subcontractor management

Legal

Do available staffing and skills meet project requirements?

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

Risk management integrated into project mgmt

Internal communication

Risks that reflect a lack of desire or motivation to achieve the objectives of the project.



Stakeholders and clients consultation

3.5 Project Scope, Objectives, and Outcomes

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 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

- Security

- Availability

- Integrity

- Safety

- Information Integrity:

- Quality

- Standards

- Confidentiality

- Privacy

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.

Has a STRA been started or completed and what significant risk factors have been identified by it?

4. Unintended Consequences or Results

4.1 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 under-utilized, 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

etc

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.

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: Extreme risk; immediate action required; senior management usually involved.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

LIKELIHOODLevel 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

Table 2: Consequence

CONSEQUENCELevel Descriptor Description

5 CatastrophicCrucial

(Threat) Will almost certainly kill the project.(Opportunity) Will have a huge benefit to overall project success

4 Major(Threat) Could threaten the survival of the project as presently defined.(Opportunity) Major benefit to overall project success

3 Moderate(Threat) Will significantly affect the project in some manner but not threaten its survival.(Opportunity) Will significantly help the project in some manner

2 Minor

(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.

1 Insignificant Can be dealt with or taken advantage of routinely.

Table 3: Level of Risk

LEVEL OF RISKLikelihood Consequences / Impact


Insignificant Minor Moderate Major Catastrophic/Crucial

1 2 3 4 55 (almost certain) 5 = M 10 = H 15 = H 20 = E 25 = E4 (likely) 4 = M 8 = M 12 = H 16 = E 20 = E3 (possible) 3 = L 6 = M 9 = M 12 = H 15 = H2 (unlikely) 2 = L 4 = M 6 = M 8 = M 10 = H1 (rare) 1 = L 2 = L 3 = L 4 = M 5 = M

Legend:20-25 (Red): Extreme risk; immediate action required; senior management usually involved10-19 (Orange) High risk; management responsibility should be specified and appropriate action taken 4-9 (Yellow): Moderate risk; managed by specific monitoring or response procedures 1-3 (Green): Low risk; manage by routine procedures.

2.6 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).

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 Review Date

1 Project Planning & Initiation

2 Analysis

3 Design

4 Build

5 Implementation

6 Evaluation

4.0 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.>


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 Reviewed by

<date> 0.1 Original document


Documents

NRS Project Charter Template - British Columbia · Web viewThe actual task of risk management is, however, a team effort of the project management organization, including the Project