Project Name
Project Risk Management Plan
Date - Version
Project Risk Management Plan
Table of Contents
1.
2.
3.
4.
5.
6.
Document Change Log ............................................................................................................ 2
Overview ................................................................................................................................. 2
Roles and Responsibilities ....................................................................................................... 4
Project Stakeholders ................................................................................................................ 5
Plan and/or Process Dependencies .......................................................................................... 5
Risk Management Process ....................................................................................................... 5
6.1 Identification .................................................................................................................... 6
6.2 Assessment and Analysis ................................................................................................. 8
6.3 Handling ........................................................................................................................... 9
6.4 Reporting ........................................................................................................................ 13
7. Tools ...................................................................................................................................... 14
8. Measures ................................................................................................................................ 14
9. Appendix A – Risk Tracking Spreadsheet ............................................................................ 14
Version [#]
Page 1 of 14
Project Name
Project Risk Management Plan
Date - Version
1. DOCUMENT CHANGE LOG
Note: The Document Change Log lists the document changes for revision. The log displays the
document versions in reverse chronological order. A new row explaining document changes should
be added to the Document Change Log for each revision. The Document Change Log is maintained
in reverse chronological order. Hence, the most recent changes are on the top of the list.
Version
Date
Description
Author
2. OVERVIEW
The Risk Management Plan addresses the risk and issue management activities <PROJECT NAME>
performs in support of the <PROJECT NAME> project. The plan enables a consistent, repeatable
risk management process, thus providing for a quality software implementation.
Risk Management is the recognition, assessment, and management of uncertainties that may result in
schedule delays, cost overruns, performance problems, adverse environmental impacts or other
undesired consequences. Risk Tracking is the actual process by which <PROJECT NAME>
monitors and manages identified risks. Risk Tracking is a sub-process of Risk Management.
The objectives of Risk Management are:


To focus attention on minimizing threats to the achievement of the <PROJECT NAME>
Project’s objectives
To provide a systematic approach for identifying and assessing risks, determining cost-effective
risk reduction actions, and monitoring and reporting progress in reducing risk
The overall goal of this process is to progressively reduce the <PROJECT NAME> Project’s
exposure to events that threaten accomplishment of its objectives by:
 Incorporating approaches into the Project Plan that minimize or avoid identified risks
 Developing proactive, contingent risk response actions
 Rapidly implementing risk responses based on timely identification of risk occurrence
A Risk describes a situation that could occur which would have a significant impact on the project.
An Issue refers to a problem involving a significant choice between two or more alternatives for an
event that is happening now. Risk Management is the recognition, assessment and control of
uncertainties that could result in schedule delays, cost overruns, performance problems, adverse
environmental impacts or other undesired consequences.
Risks
Version [#]
Page 2 of 14
Project Name
Project Risk Management Plan
Date - Version
The two major variables used in classifying a risk are 1) Probability of the risk occurring and 2) the
Impact or Consequence if that risk occurs.
The goal of Risk Management is to help the team avoid, prevent, and/or mitigate risk, and when
necessary, resolve the situation resulting from any realized risk. Consider the following questions as
a guide to conceptualizing the overall framework:
1. What can go wrong?
2. What is the likelihood of something going wrong?
3. What are the consequences if something does go wrong?
4. What can be done?
5. What options are available and what are their associated tradeoffs?
6. What are the impacts of current decisions on future options?
The Risk Management Plan and Tool allow the user to identify and assess each risk, as well as track
the progress towards mitigation.
Issues
An Issue refers to a problem involving a significant choice between two or more alternatives. Issues
are typically characterized by the following:



Multiple design or management alternatives exist
The choice requires clarification of quality or technical requirements
The choice affects the team’s scope, cost, schedule or application design significantly
An Open Point refers to a problem involving missing or unclear information, and typically has less
of an impact than an issue. Open Points arise whenever critical pieces of information are not readily
available and must be obtained from a Business Representative, or Project Management. Open
Points are used to document areas where clarification or additional information is needed and
typically relate to only one team. When an Open Point cannot be resolved, it is escalated to an Issue.
The <PROJECT NAME> team’s Issue and Open Point management process is described in detail in
the Issue Management Plan.
Version [#]
Page 3 of 14
Project Name
Project Risk Management Plan
Date - Version
3. ROLES AND RESPONSIBILITIES
Below are the roles and responsibilities of the <PROJECT NAME> team members affected by the
Risk Management Plan.
Roles
Project Manager
Responsibilities
 Identifies and monitors risks.
 Meets with Client Project Manager to discuss and mitigate
risks.
 Facilitates the “Risks” agenda item at the bi-weekly status
meetings.
 Communicates disposition of the risks to parties involved.
 Tracks risk status in Risk Tracking Tool.
Client


Identifies and monitors risks.
Meets with Project Manager to discuss and mitigate risks.
Subject Matter Expert(s)



Identify risks
Discuss risks and mitigation strategies with <PROGRAM
NAME> and Client Project Manager
Implement risk mitigation strategies as appropriate



Identify risks
Discuss risks and mitigation strategies with Team Lead
Implement risk mitigation strategies as appropriate
Team Members
The project adheres to the Risk Management Plan by:









Implementing the Risk Management Plan activities into the daily project management routine
Identifying risks applicable to the project on an on-going basis
Analyzing risks and assigning risk management responsibilities to the appropriate individuals
Incorporating risk mitigation/avoidance approaches into the Project Management Plan
Developing contingent risk responses
Monitoring and identifying risk occurrence
Participating in risk meetings
Implementing risk response actions based on risk occurrence
Documenting and reporting risks via the Risk Tracking Spreadsheet
Version [#]
Page 4 of 14
Project Name
Project Risk Management Plan
Date - Version
4. PROJECT STAKEHOLDERS
The following table lists the audience for the Risk Management Plan. When changes are made to this
plan, the following stakeholders are advised. Please see project contact list for email/phone
information.
Organization/Team
Sponsor
Project Management
Quality Assurance Advisors
Subject Matter Expert
Client
Training Lead
Change Management and Testing Lead
Functional Lead
Stakeholder Name
5. PLAN AND/OR PROCESS DEPENDENCIES
The information contained in the <PROJECT NAME> Risk Management Plan both impacts and is
impacted by the following project plans and processes.


Change Control Plan
Issue Management Plan
Changes to these and the Risk Management Plan will need to be reviewed for impacts to the
dependent plans and processes.
6. RISK MANAGEMENT PROCESS
The Risk Management Plan is required to address risks and properly communicate risk outcomes
across the project. Project Leadership meets periodically to review risks opened and closed during
the prior period and to review the status of outstanding risk items.
Typically, Risk Management goes through the following five phases, described below:
 Identification – Attention is focused on risks and identifying and documenting the major
risks which may impact progress.
 Assessment – Risks are documented into characteristic categories (e.g. technical,
operational, etc) and quantify them on a numerical scale according to likelihood, impact, and
exposure rating.
 Analysis – Appropriate responses are developed to minimize the realization of each risk and
document them according to characteristic actions (e.g. avoidance, acceptance, transfer, etc).
 Handling – Risks are handled across the levels, permitting the ongoing evaluation,
aggregation, and status reporting of risks to reduce the overall risk exposure.
 Reporting – Visibility of risk and progress is provided by reporting risk items on a regular
basis.
Version [#]
Page 5 of 14
Project Name
Project Risk Management Plan
Date - Version
The following components are critical to make sure that the <PROJECT NAME> project effectively
executes the process and manages the project’s risks:






Maintain information on risks in a timely and accurate manner
Utilize escalation points and “triggers,” such as budget, schedule, benefits, which kick off the
risk escalation process
Create a forum to discuss/resolve risks
Pro-actively identify and manage risks by team members
Confirm that the Risk Tracking Spreadsheet, managed by the Project Management team, is
useable by team members
Communicate feedback to team members confirm that resolutions of escalated risks are
reported back to the originator(s) and other impacted teams
6.1 Identification
The Risk Management Process is an iterative cycle that is performed initially during the project
planning phases and thereafter following newly identified risks. New risks may arise from a variety
of sources:
 Previously missed or unforeseen requirements
 Approved change request, cost, schedule, or scope which could impact the critical path of the
project
 Major issues escalated from the Team level
 Outcomes or consequences of a separate risk occurrence
 Current risks whose response requires investigation
 Technology availability to support resolution of risk
 Overlapping of essential activities to support resolution of risk
 Insufficient monitoring capabilities/activities
 Unrealistic schedule estimates or allocation
 Inadequate personnel resources
 Personnel safety issues
 Personnel health issues
 Physical and software security issues
 Quality Management Assessment
Identification of risks occurs at the onset of the project and throughout the course of the project.
Risks are addressed at project status meetings. In performing risk identification, the following types
of questions are asked:
Requirements
 Are the requirements consistent with the strategic objectives and goals of the project?
 Are the requirements technically feasible?
 Is there consensus among the stakeholders about the requirements?
 Are the requirements subject to significant change based on external efforts?
Version [#]
Page 6 of 14
Project Name
Project Risk Management Plan
Date - Version
Capabilities
 Will sufficiently skilled and capable personnel be available?
 Are management and teaming partners providing organizational units committed to making
the needed resources available?
 Are the end user groups willing and able to adapt to change?
Knowledge
 Is information about the external environment (e.g. market and regulations) available,
accurate, and timely?
Reliability
 Are the expected techniques and technologies to be used new and untested, or proven
solutions?
 Is there a track record of similar projects?
Constraints
 Is there latitude for deviation from the expected costs and timeline?
 How stringent are the scope requirements?
Time Frame
 Do the milestones depend on other internal initiatives?
 Do the milestones depend on outside events?
Funds
 Are sufficient funds committed for the project?
 How stable is the commitment of funds?
Project Management
 Is Project Management results-oriented?
 Is Project Management willing to grant the Project Team Leads a level of authority
commensurate with their level of responsibility?
 Does the culture facilitate building effective teams?
 Does the culture utilize collaboration and cooperation among Project Team Members?
Version [#]
Page 7 of 14
Project Name
Project Risk Management Plan
Date - Version
6.2 Assessment and Analysis
Risk Analysis forms the final step in the identification, development, categorization, and
quantification cycle. It is primarily concerned with developing specific, discrete, and measurable
responses to each risk.
This is not necessarily limited to the development of only one response per risk; two or more
alternative responses may be developed if the response to that risk is contingent on the outcome of a
prior event. Additionally, the combination of two or more interdependent risks is evaluated. The
linked quantification or summation of individual risks may produce a different combined result to
the individual totals that Project Management recognizes during the quantification process.
The initial steps in the Risk Analysis Process consider the examination of detailed risk responses to
those risks which:
 May occur soonest, irrespective of probability
 Are high impact and/or high level of probability
This risk analysis is intended to cover any short-term exposure first, before considering overall risk
reduction.
Overall, risk response analysis covers five characteristic responses:
Avoidance
Avoidance-based responses are employed at any point in the project where future-planning work is
performed. Typically, most risk avoidance occurs during the definition and planning phase of the
project, where objectives, scope, key success factors, work breakdown, and project outputs or
deliverables are defined. An example of risk avoidance is the use of a stable, established technical
solution in preference to an untested or complex new technology. However, risk avoidance solutions
may limit the ability to achieve high-level objectives by unnecessarily constraining a desirable
solution.
Control
Control-based responses occur throughout the project, and are typically the most common response.
They identify an action or product that becomes part of a specific cell or area working plans. The
project monitors and reports on them as part of the regular progress reporting of the project.
Acceptance
Acceptance-based responses describe the factors that may directly affect the success of the project,
but are outside of the Project Management influence, and can therefore only be 'accepted'. In
addition, acceptance of risks may be based as a response to the cost-ineffectiveness of any available
response or solution. For example, an acceptance response from a legislative or legal risk could be
created, over which control could not be leveraged.
Version [#]
Page 8 of 14
Project Name
Project Risk Management Plan
Date - Version
Transfer
Transfer-based responses target those best suited to analyze and implement the response to the risk,
based on their expertise, experience, and suitability. Typical transfer responses include the subcontracting to specialist suppliers who are able to reduce the overall risk exposure.
Investigation
Investigation-based responses do not define any mitigation for reducing an individual risk. They are
responses to risks where a clear solution cannot be identified, and further research is required.
However, investigative responses are not ignored, as they immediately and directly lead to a greater
aggregated risk. This is because the probability quantifier for each risk includes the effect of the
applied response, for which there is none, and the level of control quantifier indicates the level of
influence to apply that response, which is low.
6.3 Handling
Categorization of Risks
Risk categorization is achieved by defining characteristic sources of risks. These sources describe
the general areas where specific risks are likely to occur and formalize the categorization initially
performed during Risk Management Planning. Categorizing risks aids the team in identifying
appropriate methods for handling each risk.
Cost
Cost-based risks outline the non-achievement of the financial benefits of the project detailed
in the objectives or key success factors. Typical cost risks include overspending for external
contractors, additional costs in changing/solving design, and operational problems.
Schedule
Schedule-based risks focus on the non-achievement of the team’s products or benefits within
the specified timeframe. Typical schedule-based risks arise from extensions from scope
changes, resource unavailability, market opportunities missed, and additional schedule
extensions from solving those risks outlined in 'Cost' above.
Technological
Technology-based risks consider the non-achievement of the application specifications and
benefits expected. Typical risks include new/non-standard platform technology, integration
problems with other existing systems, migration problems, performance expectations not
achieved, environment complexity and functionality, and system operability.
Operational
Operational-based risks focus on the peripheral organizational and business operational reengineering changes, arising from a new process or modification of an existing process.
Typical risks consider both the transitional and the long-term effects of the introduction of a
new process or the augmentation of an existing process, including the organizational and
behavioral change required, the human and physical resource planning, and communication
required to facilitate a smooth transition to the new structure.
Version [#]
Page 9 of 14
Project Name
Project Risk Management Plan
Date - Version
Staffing
Staffing-based risks focus on the availability of knowledgeable personnel to perform the
various project work activities. Typical risks include unavailability of resources to address
technical components of solution, timing of planned resources to participate in project,
unplanned resource absences, and employment termination or separation.
External
External-based risks consider the 'environmental' factors largely outside of the control of the
Project Management, which can directly or indirectly affect the successful delivery of the
project. Typically, risks are profiled arising from legislative regulations, legal requirements,
or communication to the market, lack of market sophistication, and the strategic direction and
priority conflicts of a controlling body under this category.
The Cost and Schedule risk sources are known as risk 'indicators', as they are often the most
tangible measure of overall progress towards the project objectives or goals. The
Technological, Operational, and External risk sources are referred to as risk 'drivers', as these
are the sources of Colorado risks, which additionally drive the Cost and Schedule risks.
The recognition that the management of Technological, Operational, and External risks is
inter-related to the management of Cost and Schedule risks is an important link in effectively
responding and reporting risk-reducing activities.
Assessment of Risk Responses
Following specific definitions of the risks above, the project decides on the most likely overall
response to the risk. The risk responses may be an obvious set of actions that annul or limit the risk
occurring or may be an intuitive 'best guess' of the available actions that are likely to be effective.
The development of specific and discrete responses to each risk is further analyzed in the ‘Analyze
Risk’ section. However, initial 'reactions' to each risk are required to allow quantification of each
risk, as described in ‘Quantification of Risks’.
Quantification of Risks
Risk quantification extends the value of the understanding, documenting, and reporting of level risks
by attempting to assign each risk to a numerical scale. The ‘Calculation of Risks’ section provides
further details on Quantification of Risks.
This section introduces a common format to risk quantification, based on numerical scales. These
scales assist in realizing and focusing on the 'true' impact of each risk and in the prioritization of the
risk-reducing activities and responses identified. The following parameters for each risk are
quantified:
Version [#]
Page 10 of 14
Project Name
Project Risk Management Plan
Date - Version
Probability
This is an assessment of the percentage probability of an occurrence of the risk, given the responses
identified, and the other factors or risks on which it is dependent. Risk probability is rated on the
following manual probability scale:
Probability
4
3
2
1
Descriptive Word
Expected
Probable
Remote
Improbable
Definition
Likely to occur
Likely, but not certain to occur
Unlikely, but possible to occur
Not likely to occur
Impact
This is an estimate of the overall scale of the impact following an occurrence of each risk. Risk
impact is rated on the following scale:
Risk Impact
4
Descriptive Word
Catastrophic
3
Critical
2
Marginal
1
Negligible
Description
Extremely harmful, major disruption
in project
Unstable situation, disruption in
project.
Recoverable with minimal effort,
minor disruption in project.
Very minor effect or disruption in
project
Exposure
The handling of a risk or group of risks is paramount to the project’s success. The team lists the
identified risks and identifies and records potential actions that could be taken to avoid or mitigate
the risks. Each risk’s exposure rating helps identifies the type of actions to take.
Version [#]
Exposure Rating
Type of Mitigation
12-16
Actions which must be immediately incorporated
into the Project Schedule or other appropriate plan.
6-11
Actions which must be documented as contingent
risk responses to be incorporated in the Project
Schedule or other appropriate plan in the event of
risk occurrence.
1-5
Actions which must be monitored in the Risk
Tracking Tool
Page 11 of 14
Project Name
Project Risk Management Plan
Date - Version
The probability and impact variables are combined to assess the Risk as shown below.
System Impact
Probability
1-Negligible
2-Marginal
3-Critical
4-Catastrophic
1 – Improbable
1
2
3
4
2 – Remote
2
4
6
8
3 – Probable
3
6
9
12
4 - Expected
4
8
12
16


Risks that fall into the green area are Low and should be monitored.
Risks that fall into the yellow area are Medium and a mitigation plan should be prepared for
implementation in case the risk increases in probability or impact.
 Risks that fall into the red area are High. Immediate steps should be taken to prevent them.
In the numerical quantification, a further parameter is defined, called risk exposure. Risk exposure
attempts to numerically scale each risk according to its overall level of exposure, as shown in the
mathematical expression below:
Risk Exposure =
Probability x Impact
It follows that a risk with a high probability and high impact indicates a high level of exposure.
Similarly, those risks with a low probability and low impact offer the lowest levels of exposure.
Consider the five separate and independent risks, A to E, shown in the following example:
(In decimal format)
Probability
Impact
Risk Exposure
Risk A
1
4
4
Risk B
2
2
4
Risk C
3
4
12
Risk D
1
4
4
Risk E
2
3
6
Both risks B and D have equivalent low levels of risk exposure, as shown in the end column.
However, while there are larger variations in each risk's impact, the probability of each are arguably
indistinguishable, since they both fall in the low occurrence probability scale.
The value in quantifying each risk according to the above formula comes not from being able to
assign a numerical value to each parameter, but from the subjective decision-making experience of
the Project Management involved in understanding the relative importance of each parameter
between each risk. It is through this focus that a true value-added process is achieved. Therefore, the
model is designed only to be a catalyst for focusing Project Management on the relative importance
of the risks perceived.
Version [#]
Page 12 of 14
Project Name
Project Risk Management Plan
Date - Version
6.4 Reporting
Project level risks are identified in the Risk Tracking Tool (Microsoft Excel). To provide visibility of
risks and progress towards mitigating them, Project Management meets weekly to discuss risks by
team, including the following details:




Risk Owner
Title
Description
Status (everything but Closed)
Identified risks are documented into specifically defined, tangible risk items, for which a
response/action may be well defined and measurable. This promotes analysis and reporting of risks
that support high-level objectives. The identification of vague or non-specific risks, results in
responses/actions that are ambiguous, intangible, unclearly defined, and difficult to implement
adequately.
Additionally, it is important not to attempt to document unlikely risks and outcomes in the Tool, as
this can often introduce improbable scenarios, which:




Create unnecessary concern and confusion
Shift the focus away from real or probable risks
Dilute the pool of risks, leading to diminishing returns on effort
Reduce credibility for the Risk Management Process
Risk documentation is more concerned with identifying the areas where the consequences of the
risks are most severe, and where corrective responses or actions will produce the largest benefits in
risk reduction.
Furthermore, risk documentation takes the areas where risks are most likely to occur and develops
detailed assessment criteria for the risks. Typical sources of assessment criterion include the
following:





Unrealistic budget or schedule estimates
Delivery on critical path, or unrealistic deliverable and milestone deadlines
New technologies and platforms, complex/leading edge technologies, and complex
environments
Staffing considerations for experts, numbers, and experience required
External dependencies, including legislative changes, contractor supply and delivery,
procurement, etc.
Version [#]
Page 13 of 14
Project Name
Project Risk Management Plan
Date - Version
Project risks are documented in the Risk Tracking Tool, which resides on the project LAN. The
tracking sheet has the following required fields:






Risk Area
Potential Impact
Mitigation Strategy
Actions Taken
Status
Risk Owner
This tracking sheet is discussed, as needed, during the bi-weekly client status meeting and the team
management meeting. During these meetings, risk discussions are a standard part of the agenda and
the risk status is updated accordingly.
7. TOOLS
Project level risks are documented in the Risk Tracking Tool. For risks that require escalation to
<PROJECT NAME>, the risks are attached to the <PROJECT NAME> bi-weekly status report and
discussed at the bi-weekly status meeting.
8. MEASURES
For specific information on risk related measurement, please refer to the <PROJECT NAME>
Project Measurement Plan.
9. APPENDIX A – RISK TRACKING SPREADSHEET
Please see attached Appendix A – Risk Tracking Tool.
Version [#]
Page 14 of 14