---

Quick Links

News | The Premier Online | Ministries & Organizations | Job Opportunities | Main Index

---

Contents

• B.C. Home
• Ministry of Environment
• Ministry of Agriculture and Lands
• CSD
  • IMB
    • Services
      • Database Services
      • Management Services
      • Application Services
      • Information Management Services
      • Technology Services
      • Web Services
        • File Transfer Service (SOFT)
      • Data Services
    • Organization
      • Business Plan
      • Corporate Information Architecture
      • Web Services
      • GIS and Access Support Services
      • Application Development Services
    • Standards
      • Alphabetical List of All Standards
      • Application & Architecture
      • Project Management
      • Standards for Standards
      • System Development Life Cycle (SDLC)
      • Technology
      • Web
    • Projects
      • Corporate Information Architecture
      • Web Services
      • Data Management Services
      • GIS and Access Support Services
      • Application Development Services
      • Land and Resource Data Warehouse
  • Reports and Publications
  • Branch Contacts

B.C. Home » Environment » CSD

SDLC STANDARDS
Project Management - RISK MANAGEMENT STANDARDS
Version 1.2
February 12, 2010

This page contains the published standards for Project Risk Management used within the Ministry and by its contracted consultants.

Table of Contents

VERSION CONTROL

1.      INTRODUCTION
1.1    Purpose
1.2    Audience

2.      RISK MANAGEMENT STANDARD

2.1      RISK ASSESSMENT
2.1.1    Identify
2.1.2    Analyze
2.1.3    Prioritize
 
2.2      RISK CONTROL
2.2.1    Mitigate
2.2.2    Plan
2.2.3    Monitor
2.2.4    Communicate

3.      CONCLUSION

 

APPENDICES

Appendix A:         Risk Definition Form              (also in a WORD document)
Appendix B:         Risk Analysis Summary        (also in an EXCEL document)  

VERSION CONTROL

This section of the document records the various versions or releases of this document

Version	Details/Description	Distribution	Date	Author	Organization
0.1	First Draft	Whole Document	July 2000	Dave Knox	ISB
0.2	Second Draft	Whole Document	August 2000	Dave Knox	ISB
0.3	Third Draft	Whole Document	October 2000	Dave Knox	ISB
1.0	First Version	Whole Document	February 2001	Dave Knox	ISB
1.1	Posted to Web	Whole Document	February 2002	Dawn Henry	IMB
1.2	Feb. 2010 Review	Whole Document	February 2010	Sean Cavanagh	IMB

 

Table 1: Version Control

 

[TOC]

1.      INTRODUCTION

This standards document addresses Risk Management as it relates to Systems Development Life Cycle (SDLC) projects for the Ministry.  This standard is one of the components of Project Management Standards.  Refer to Risk Management Principles for a more detailed description of Risk Management.

1.1      Purpose

The purpose of this standard is to outline a formal process for the management of project risks. It is highly recommended that all major systems development projects follow this process and include it in all aspects of project planning.  All contractors performing systems development projects for the Ministry are to conform to the standards outlined in this document.  This process covers the Identification, Analysis, Prioritizing, Mitigation, Planning, Monitoring and Communication of project risks.

This standard describes the process and the components of Risk Management and provides examples and templates to assist project managers manage project risks.

1.2      Audience

This Risk Management Standard document is primarily intended for the use by the Ministry and vendor Project Managers.  Other decision makers should also participate in the process of Risk management and may wish to review this document.  These include:

• Steering Committee;
• Business Champion;
• IMB Business Analyst; and
• Other Project Decision Makers.

 

  [TOC]

2.      RISK MANAGEMENT STANDARD

It is assumed that the reader is fully acquainted with the contents of the Risk Management Principles that support the Standard.  The start of Risk Management for a project should be done in conjunction with the production of the Project Statement as part of the Definition Phase of the Systems Development Life Cycle (SDLC).  Project risks should be recorded in the Risks, Assumptions and Constraints paragraph of the Project Statement.

There are two stages in the process of Project Risk Management. They are:

• Risk Assessment; and
• Risk Control.

  [TOC]

2.1      RISK ASSESSMENT

There are three steps to be performed in the completion of Risk Assessment.

1.  Identify	Review all the project plans and identify areas of uncertainty
2.  Analyze	Define how the identified areas of uncertainty could affect the performance and success of the project in terms of scope, quality, duration and cost.
3.  Prioritize	Prioritize each risk to determine the amount of action or effort required.

  [TOC]

2.1.1      Identify

The Vendor Project Manager must complete a Risk Definition Form for each identified risk with the Project Name, the name of the Project Manager and the Date that the form is prepared.  (The Ministry Project Manager is the person ultimately responsible for identifying and managing project risks.  On large projects this may be delegated to the Vendor Project Manager.)

Identify all known risks by first giving each risk a brief Name by which the risk can be referred. 

Each risk should be given a unique Risk ID#. It is recommended that the Risk ID# include reference to the project such as XXXXRnnn where:

XXXX = the project,
R         = Risk and
nnn      = numeric sequence starting at 001.

Each risk must be also be given a detailed Description so that the risk is clearly defined and understood.

Example:

It is strongly recommended that the entire Project Team participate in a risk identification meeting at, or soon after, the project kick-off meeting. 

  [TOC]

2.1.2      Analyze

Risk Analysis is performed by categorizing all the identified risks according to the likelihood of their occurrence and the impact that they will have on the project.  Use the matrix below to assist in the Risk Analysis.   This will also assist with the Prioritization of the Risks.

LIKELOOD OF OCCURENCE
The High or Low likelihood of a risk occurring is to be determined by the Vendor Project Manager and appropriate project team members and rated accordingly.  Record this determination and provide a comment describing the rating Likelihood of Occurrence.
 
PROJECT IMPACT
Rate each risk High or Low according to the impact that it will have on the project.  Record the overall Impact Rating and provide a comment to further  describe this rating to the project.  Also record (as appropriate) additional Impact Rating comments in terms of scope, quality, time and/or budget.

Update the Risk Definition Form with the appropriate ratings and comment(s) relating to the Analysis performed.

Example:

  [TOC]

2.1.3      Prioritize

Each risk must be Prioritized for action by the project team as follows:

1	Risks that must be eliminated or significantly reduced immediately;
2	Risks that need to be monitored closely.  There needs to be an action plan in place to prevent them from effecting the project;
3	Risks that need to be monitored, but less rigorously and mitigation plans are less urgent; and
4	These Risks carry the lowest priority and demand appropriately less attention but should not be totally ignored.

 

The Analyze Risks table (above) is intended to be used as a guide to assist in setting the risk priority.   The priority assigned may change if a risk is borderline between two quadrants in the Analyze Risks table.  The priority assigned to each risk may vary based on other factors such as effort, cost or likelihood of recovering from a risk. At the discretion of the Project Manager a risk priority may be adjusted.

Prioritization of risks enables the Project Manager and project team to focus on areas that are most likely to have the greatest impact to the project.

Update the Risk Definition Form with a comment relating to the process that was followed or the project team discussion to support the priority selected.

Example:

  [TOC]

2.2      RISK CONTROL

Risk Control is this is the second stage in Project Risk Management.  There are four steps to be performed in the completion of Risk Control.

1.  Mitigate	Identify the necessary actions that can be carried out in advance to reduce (or eliminate) the impact of the risk.
2.  Plan	Develop a contingency plan for dealing with significant risks.
3.  Monitor	Monitor and track all the risks identified and manage them to successful resolution.
4.  Communicate	Document and communicate the project risks to the project team and project decision makers (e.g.: Steering Committee).

Most risks should have contingency plans prepared.  These plans can then be actioned when a risk occurs (becomes a Problem).  These plans will enable the project to recover from, or survive a risk's occurrence (a problem).

A member of the project team must be assigned as the Risk Monitor for each documented risk.   The Risk Monitor will be responsible to the Project Manager for monitoring the risk, reporting any change in condition, taking the agreed contingency action (Plan) if the risk occurs.

Update the Risk Definition Form with the assigned Risk Monitor for each risk.

Example:

  [TOC]

2.2.1      Mitigate

Risk Mitigation is performed in one of two ways:

• Risk Elimination; or
• Risk Reduction.

Risk Elimination

All top priority 1) risks require proactive mitigation actions to achieve the full benefits of Risk Management.  Priority 1) risks should be completely eliminated if possible, as they will have the highest impact to the project.  It is preferable to eliminate as many risks as possible, early in the project.

Risk Reduction

Risk Reduction involves identifying mitigation actions that will significantly reduce a risk's occurrence or impact to the project.

Update the Risk Definition Form with a comment relating to the Mitigation action that is identified for each risk.

Example:

  [TOC]

2.2.2      Plan

A separate documented contingency Plan should be prepared for each risk, identifying:

• the problem description;
• The Risk Monitor; who is to be responsible for carrying out the plan and ensuring that the project survives the problem
• the key identifiers that will announce the problem as having occurred (arrived);
• the activity(ies) to be performed to resolve, reduce and or eliminate the problem; and
• the measurements that will announce the problem as resolved (if known).

Update the Risk Definition Form with a comment and reference relating to the plan prepared and the assigned Risk Monitor.

Example:

  [TOC]

2.2.3      Monitor

This activity will take place after Mitigation and Planning.  Monitor project risks by using the following actions:

• include risk mitigation tasks in the project schedule;
• define appropriate risk milestones; and
• review risk tasks regularly in project status meetings.

The results of the Monitoring step and the status of each monitored risk should be reported at each Project Status meeting and included in the Project Status Report.

2.2.4      Communicate

Ensure that all documented Project Risks are communicated to the project team and decision makers on a regular basis.  Use the Project Risk Analysis Summary form to communicate the status of project risks.

  [TOC]

3.      CONCLUSION

Project Risk Management enables processes and actions to be identified and implemented in an orderly manner without causing any disruption or delays to the overall completion of the project.  By following the phases, steps and actions outlined in this standard, the constant management of risks can become a primary component of all systems development projects in the Ministry.

  [TOC]

APPENDIX A:   Risk Definition Form     (WORD version )

  [TOC]

APPENDIX B:   Risk Analysis Summary         (EXCEL version)

  [TOC]