Ministry of Agriculture & Lands
SDLC STANDARDS
Project Management - RISK MANAGEMENT PRINCIPLES
Version 1.1 February 14, 2010
This page contains the published principles for Project Risk Management used within the Ministry and by its contracted consultants.
1. INTRODUCTION
1.1 Purpose
1.2 Audience
2.1 What
are Project Risks?
2.2 Why Manage
Risks?
2.3 What
is Project Risk Management?
2.4 What
are the Overheads?
2.5 What
are the Benefits?
2.6 What
is Risk Assessment?
2.7 What
are Project Impacts?
2.8 What
is Risk Identification?
2.9 How
are Risks Analyzed/Categorized?
2.10 How are Risks
Prioritized?
2.11 What is Risk Control?
2.12 What is Risk
Mitigation?
2.13 What is Risk Planning?
2.14 What is Risk
Monitoring?
2.15 What is Risk
Communication?
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 | Posted to Web | Whole Document | February 2002 | Dawn Henry | IMB |
| 1.1 | Posted to Web | Whole Document | February 2010 | Sean Cavanagh | IMB |
| Table 1: Version Control |
1. INTRODUCTION
This document provides an overview of the principles of Risk Management to support the Risk Management Standard.
1.1 Purpose
The purpose of this document is to describe in some detail an overview of a process for managing project risks. This process covers the Identification, Analysis, Prioritizing, Mitigation, Planning, Monitoring and Communication of project risks.
1.2 Audience
This Risk Management document is intended for the use of people not fully acquainted with risk management techniques and who need a more detailed explanation of the stages and steps of this project management technique.
This Project Risk Management Standard deals with the management of risks as they relate to Systems Development Life Cycle (SDLC) projects for the Ministry.
In order to manage risks we have to have a better understanding of Project Risk Management in terms of:
- What are Project Risks?
- Why Manage Risks?
- What is Project Risk Management?
- What are the Overheads?
- What are the Benefits?
- What is Risk Assessment?
- What are Project Impacts?
- What is Risk Identification?
- How are Risks Analyzed?
- What are Risk Categories?
- How are Risks Prioritized?
- What is Risk Control?
- What is Risk Mitigation?
- What is Risk Planning?
- What is Risk Monitoring?
- What is Risk Communication?
A Project Risk can be described as a likely future occurrence (a Problem) that will adversely affect the project's objectives or goals. Risks have three distinguishing features:
|
An event or action that may occur. Things that have happened are facts, not risks. |
|
An occurrence will adversely affect the cost, delay the schedule, impact quality, or change the scope of the project. |
|
Risks are future uncertainties. An impact to the project which will definitely occur, should be included in the project plan as a task, is not a risk. |
A Problem is something that has already occurred and the action(s) to be taken to deal with the problem.
Project Risks are adverse factors that have the potential to influence:
- process;
- technology (hardware and software);
- organization;
- deliverables;
- schedule;
- costs; or
- business units.
The approach to Risk Management is to address as many of the known and identified risks as possible to minimize their impact to the project. All projects are typically affected by project problems or risks that are unexpected, unplanned or ignored. Accordingly the risk of a Project's success or failure can usually be measured in terms of:
- Scope;
- Quality;
- Time;
- Budget.
The problems that are going to be faced "tomorrow" are the risks that are identified "today". Project Risk Management enables risks to be identified and mitigated or eliminated before they become problems.
Any project is subject to risks. A project which finds itself in a state of perpetual crisis, is failing to manage risks properly. Failure to manage risks is usually characterized by the inability to decide:
- what to do;
- when to do it;
- whether enough has been done.
Projects that utilize Risk Management to manage their risks are more likely to receive benefits such as:
- adherence to user requirements;
- higher quality deliverables;
- maintenance of project schedules;
- prevention of schedule slippage;
- reduction of project costs.
2.3 What is Project Risk Management?
"Project Risk Management is the process of managing a project's risk exposures to ensure it achieves its objectives."
Project Risk Management consists of using the techniques of analysis and measurement to ensure that risks are properly identified, classified, monitored, managed and communicated to all relevant project stakeholders.
There are two Stages in the process of Project Risk Management;
It is recommended that brainstorming sessions are held at the start of the project with all the members of the project team to identify all the risks and gain buy-in to their resolution. Risk Management effort expended up front in a project will save many times that effort in potential project problems at crucial times during the project execution and will be reflected in the project's benefits.
Risk Management is not performed without overhead to the project. A project has to invest effort (time and money) to get the expected returns and benefits from Risk Management. The stages of Risk Assessment and Risk Control need to be included and provided for in the project Planning Phase of the SDLC.
Benefits are hard to quantify and are not necessarily immediately obvious. Preparing for risks is to prepare for a potential future activity and accordingly any benefits will only be received in the future. The potential return on investment (ROI) by preventing one major project risk could conceivably justify and pay for all the Risk Management activities.
Risk Management will assist projects to become more successful. By completing all the components in the two Stages of Risk Management, the Ministry's management, the project team and the business users may have increased confidence that:
- the project will be delivered successfully;
- surprises will be kept to a minimum;
- risks will be effectively managed and mitigated in a timely manner.
Projects which complete on time or earlier, may cost less. Risk mitigation actions, which reduce overall project risk, are likely to accelerate project completion.
Risk Assessment is the first of two stages in Project Risk Management and includes three main steps as follows:
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
the risks in terms of those risks that: 1) must be eliminated (resolved) completely due to their extreme impact to the project; 2) are important enough to demand regular monitoring and reviewing; 3) are deemed to have a minor impact and will not require detailed monitoring; and 4) should not be totally ignored but demand less attention. |
These steps are to be repeated in an iterative process until all known risks are addressed. Risk Assessment is only completed when the Project Manager and appropriate project team members are satisfied that all the risks have been detected and recorded.
It is recommended that a workshop with the project team is held to identify all project risks. Identification of risks should be an ongoing question at each project status meeting.
All steps of the Risk Assessment are to be addressed in terms of the impact to the project's scope, quality, time or budget.
SCOPE
Project Scope can be defined as the identified tasks and activities that need to be performed in order to deliver the required features and functions of a product.
This refers to anything that will result in the project scope being altered. Such as:
- change in business requirements;
- increased/reduced functionality; and
- change in reporting.
QUALITY
Quality can be defined as the defined or accepted standard of performance or deliverable that satisfies the Ministry's expectations.
This refers to anything that will result in a project deliverable not conforming to the expected quality, standard or performance. Lesser quality may impact Time and Budget as the deliverable may have to be re-done or extra time (and money) may have to be spent to bring the deliverable up to the acceptable quality level.
Depending on the type of deliverable and contract, reduced quality may in fact reduce the cost of the project, if the reduced quality is accepted. This may be caused by:
- the level of quality not being clearly defined at the start;
- standards not being in place or clearly identified; or
- the performance of the deliverable (e.g.: system response time) is not identified at the start.
TIME
Time can be defined as the either the elapsed period of the project or the amount of effort budgeted or assigned to each project task and activity.
This refers to anything that will result in a project task, activity or deliverable being completed later than planned or requiring more effort. There is usually a direct relationship between time and budget risks. This may be caused by:
- staff not being available for their assigned scheduled tasks;
- task estimates not accurate or taking longer; or
- changes in scope.
BUDGET
Budget can be defined as the agreed or contracted amount of the project.
This refers to anything that will result in the project costing more than was budgeted. This may be caused by:
- direct cost or cost to purchase (e.g.: hardware or software) being greater than budgeted;
- scheduled tasks taking longer than originally estimated (this will not be an issue with fixed price contracts); or
- changes in scope.
2.8 What is Risk Identification?
Risk is an unavoidable ingredient of all projects. Risk Identification consists of determining which risks are likely to affect the project and then defining the characteristics relating to each risk. Identifying the project's risks is the first step in making it possible for a project to proactively reduce its overall risk and increase its chances of success. Review all aspects of the project and look for (identify) areas of uncertainty, doubt or restriction that may be recorded as project risks.
Risk identification is not a one-time process. It should be performed on a regular basis throughout the course of the project.
The entire project's documentation need to be carefully scrutinized for things which could have an impact on the project's success. In particular, concentrate on risks that will affect the project's scope, quality, time and/or budget. Risk identification needs to address both internal and external risks.
| Internal Risks | These are risks that the project team can influence or control. Staff assignments, timelines and cost estimates are such risks. |
| External Risks | These are risks that are outside of the control of the project team. Technology changes, upgrades and government decisions are examples. |
Risks can be identified by utilizing the following processes:
- review known list(s) of project risk factors and sources;
- review project plans and schedules;
- review business plans;
- review chosen technology architecture;
- review business requirements;
- interview project team members;
- conduct brainstorm session(s) with project team.
It is important to note that "The project will not be completed on time" is not a risk. It is an impact. This risk should be expressed as "The effort or duration of task 27 may have been underestimated"
Some possible project risk areas are:
- Not appointing an executive member as Project Sponsor;
- Not appointing a Project Manager to the project;
- Introducing new technology to the Ministry with the project?
- Not providing sufficient time to Ministry staff resources to participate effectively;
- Not obtaining support, commitment and participation from Ministry staff resources;
- Not appointing a project Business Champion;
- Not clearly and accurately defining the project scope (business requirements);
- Not having a clear business mandate for the project;
- Not completing a business case;
- Not clearly defining the project's business objectives;
- Not having a clearly defined technical environment;
- Not clearly and accurately estimating project costs;
- Not obtaining project funding to support the estimates;
- Not defining and forming a project team with all the appropriate skills and roles;
- Not clearly defining the scope and deliverables on contracts or Memorandums Of Understanding;
- Not providing an appropriate Project Management Office commensurate with the size and complexity of the project;
- The proposed technology has less functionality than promised;
- Potential or planned technology upgrades;
- The length of a project or project phase;
- Underestimating project tasks and/or budgets.
2.9 How are Risks Analyzed/Categorized?
Before risks can be mitigated, they need to have their degree of severity analyzed. Perform an analysis of the identified risks and categorize them according to the likelihood of their occurrence against their impact to the project.
This can be completed by using the four quadrant chart shown below. List each risk and decide on the likelihood of its occurrence and identify its impact on Scope, Quality, Time and/or Budget if the risk occurs.
The categories from this Analysis described as:
| 1 | HIGH
Likelihood and HIGH Impact. These are critical risks that will have a severe impact and are likely to occur. |
| 2 | LOW
Likelihood and HIGH Impact These are significant risks that are not likely to occur but will have a material impact to the project if they do. |
| 3 | HIGH
Likelihood and LOW Impact.. These are significant risks that may be able to be avoided with careful planning and monitoring. Those that do occur however will have a low project impact which is likely to be manageable. |
| 4 | LOW
Likelihood and LOW Impact. Although these risks should still be monitored to ensure that they do not change category, the amount of time devoted to these should be proportionate with their likelihood and impact. |
2.10 How are Risks Prioritized?
Using the risk Categories prioritize each risk for action in the order that it is to be addressed (1 to 4).
It may be necessary to prioritize a risk higher than the categorization activity suggests. In this way there may be an overlap of priority versus category. Prioritization of risks enables the Project Manager and project team to focus on the areas that are most likely to have the greatest impact to the project.
Depending on the assessed priority and the impact of each risk, it is useful to estimate the $ impact to the project should a risk occur. Provide an estimate of the cost to recover the project after this risk occurs.
Risk Control is the second stage in Project Risk Management and includes four main steps as follows:
| 1. Risk Mitigation | Identify the necessary actions that can be carried out in advance to reduce (or eliminate) the impact of the risk. |
| 2. Risk Planning | Develop an emergency plan for dealing with significant risks. |
| 3. Risk Monitoring | Monitor and track all the risks identified and manage them to successful resolutions. |
| 4. Risk Communication | Formally document and communicate the project risks to the project team and project decision makers (Steering Committee). |
All risks Prioritized as 1 in the Risk Assessment Stage must to be processed through Risk Control.
Risk identification, analysis and prioritization are only beneficial if actions are defined and executed to mitigate the risk. Risk mitigation actions must be defined individually for each risk. In some cases, immediate action will be necessary. For other risks, future plans and considerations will be more appropriate.
Risk Mitigation must not be confused with the Planning component. Mitigation actions are proactive to prevent a risk from occurring and impacting the project or reducing the impact of the risk. Plans are prepared for execution after a risk occurs, becomes a problem and starts to impact the project.
Risks can be mitigated not only by eliminating the risk but also by reducing their degree of Occurrence and/or lessen the Impact to the project. Accordingly Risk Mitigation can be broken down into two components:
1. Risk Elimination
2. Risk Reduction
RISK ELIMINATION
Aggressive, proactive risk mitigation for top priority (1) risks is essential to achieve the full benefits of Risk Management. For these critical risks it is ideal if the risks can be eliminated entirely as they will have the greatest negative impact to the project.
Risk Elimination requires carrying out the necessary action(s) to completely remove the identified issue or problem from the project.
Example: Risk: Project Sponsor has not been appointed. Priority: 1, High impact to the success of the project. Mitigation: Appoint an executive member, with available time to devote to the project as Project Sponsor.
By carrying out this Risk Elimination mitigating action, the risk is completely removed from the project.
RISK REDUCTION
A reduction of the degree of occurrence, or lessening of the impact, can be attained by actions early in the project.
Example: Risk:
A new technical environment may not be suitable or appropriate for the project. Priority: 2, Low Likelihood and High Impact. Mitigation: Conduct a prototype or proof of concept to ensure that the technology will be able to deliver the required functionality.
The prototype to confirm technology is an example of mitigating the identified risk that "the technology is new to the Ministry and may not be able to deliver the required functionality". This mitigation activity will reduce the likelihood of the technology environment causing a problem to the project in production as it will have been previously tested or proven.
However, beware of the risk that Risk Mitigation sometimes may not go far enough. In the example above, the mitigation may concentrate resources to address the prototype and then assume that there will be no problems with the production implementation. This will reduce the likely occurrence but not eliminate it completely.
If technology changes during the project, this risk will have to be reinstated and revisited.
All risks with a high priority need to have contingency plans prepared. Planning involves defining action steps to be carried out when an identified risk occurs (becomes a problem). A plan of action should be prepared for each high priority risk that is not able to be proactively eliminated. An action plan will enable the project to recover from or survive a risk's occurrence (a problem).
A 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;
- the measurements that will announce the problem as resolved (if known).
A problem that has been dealt with by the carrying out of the plan may still represent a significant project risk. Addressing a risk occurrence (problem) by the carrying out of a contingency plan is unlikely to completely eliminate the risk entirely. High priority risks are still likely to remain a High Risk. Even after being addressed once, it may still re-occur at some time in the future (e.g.: Staff leaving the project).
Each risk that requires Mitigation or a contingency Plan to be prepared should be assigned to a member of the project team to monitor. 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.
Monitoring of Project Risks can be achieved by using the following actions:
- include risk mitigation tasks in the project schedule;
- define appropriate risk milestones;
- review risk tasks regularly in project status meetings;
- perform inspections on risk status.
Risk Management is an essential part of completing a project. As the project proceeds, some risks will be eliminated, but some new risks may emerge or occur. Some mitigation actions will work well but some may not and revised and alternate actions will need to be taken. As the project proceeds, risk priorities may change and new Risk Management planning will be required.
| Example: |
|
The project schedule is the ideal tool to monitor risks. By including specific risk mitigation tasks in the project schedule, their progress and effectiveness can be reviewed on a regular basis and reported at project status meetings.
2.12 What is Risk Communication?
Project decision makers and project team members are more likely to respond to formally written information than on verbally communicated project concerns. They become more involved in the risk if it is documented and contained in project documentation. A formally documented process will enable anyone involved or interested in the project to be aware of the project risks. It also assists the Risk Monitor's commitment to the monitoring and mitigation of an individual risk.
