PROJECT RISK MANAGEMENT

KEEP IT SIMPLE TO ENHANCE PROJECT SUCCESS

James A. Ward, PMP

Risk refers to uncertain future conditions or circumstances that may adversely impact a project
if they occur. A risk represents the possibility, not the certainty, of a future event affecting the
success of a project.

Risk is inherent in all projects. By effectively managing risk, the project team can reduce the
likelihood of occurrence of an adverse event and the impact on the project should such an event
occur. Risk management is a repeatable, structured process that identifies and systematically
addresses risks to minimize their affect on projects.

RISK MANAGEMENT DEFINED

Per PMI’s PMBOK, “Project risk management is the systematic process of identifying,
analyzing, and responding to project risk. It includes maximizing the probability and
consequences of positive events and minimizing the probability and consequences of events
adverse to project objectives. It includes the processes of risk management planning, risk
identification, qualitative risk analysis, quantitative risk analysis, risk response planning, and risk
monitoring and control.”

The Implementation and Execution section of the Risk Management Plan describes the
procedures for dealing with risk for Information Technology projects. It follows the Project
Management Institutei Project Management Book of Knowledgeii (PMBOK), recognized as an
industry standard for Project Management.

The Tools section of the Risk Management Plan describes the procedures for Information
Technology projects.

PURPOSE OF RISK MANAGEMENT

The Risk Management Plan as defined in this document addresses IT projects and their sub-
projects. The Risk Management Plan documents the procedures to be performed by the project
team as the organization’s risk management process.

A proactive project team tries to resolve potential problems before they occur. This is the art of
risk management. The purpose of risk management is to identify the risk factors for a project and
to then establish a risk management plan that will minimize the probability that risk events may
occur and that, should they occur, their impact on the project will be minimized.

James A. Ward & Associates, Inc. 1

 ASSUMPTIONS

All projects have risks. Risk is inherent to project work.

In any given organization or environment, projects will have common risks. In developing a risk
management plan for a project, other projects should be reviewed for risk occurrences that can be
anticipated and avoided.

Not all identified risk events will occur. Some risk events may occur more than once in the life
of a project.

Project teams should perform risk identification processes at project inception, at the start of
major project phases or iterations, and when significant changes to the project occur, such as
changes in project scope or key personnel.

The project’s top risks should be analyzed by the project team on a regular, ongoing basis and
reported to management.

IMPLEMENTATION AND EXECUTION

Step 1: Risk Management Planning

Risk Management Planning is concerned with deciding how to approach and plan risk
management activities for a project. The Risk Management Plan is based on identification of risk
events followed by risk quantification, response development (mitigation), and response control
(contingency planning and execution). Risk Management is an iterative process that is initiated
at the start of the project and will continue throughout the project lifecycle.

The project team should consider both the organization’s and the project stakeholders’ tolerance
for risk. Some organizations have very high tolerance for schedule or cost overruns, while others
have very little.

The Project Manager is responsible for proactively managing the project’s risks. The key factors
of risk identification, quantification, response, and control should be actively managed by the
Project Manager.

Risk review should be an item on the project team meeting agendas. It may also be necessary to
convene specific working sessions to assess and manage risk.

Step 2: Risk Identification

At project inception, an initial risk identification should be performed. This should be done by
reviewing risks identified (or encountered but not identified) on other projects and by
brainstorming with the project team and key stakeholders.

James A. Ward & Associates, Inc. 2

It is essential that customers/users/stakeholders be involved in the risk identification process, as
well as members of the project team. This will serve to reinforce the concept that risk is inherent
in all projects and that proactively identifying and managing potential risks will increase the
likelihood of project success.

At this point, not all details of the project may be known, and these unknowns may constitute
potential risks to the project. For example, requirements definition, and therefore project scope,
may not be fully completed. Project assumptions and constraints should be carefully reviewed. It
is possible that attempting to simultaneously address conflicting constraints could pose a risk to
the project.

All potential risks should be reviewed by the project team and key stakeholders to assess
probability of occurrence and impact. The Risk Management Matrix (see Appendix B) can be
used for recording and analysis of all identified risks. See Qualitative and Quantitative Risk
Analysis (below).

All identified potential risk events that are deemed to be relevant to the project are to be
recorded using the Risk Management Matrix. The risk matrix maintains a record of “resolved”
risks as well as “current” risks. Note that should a previously unidentified risk event occur at
any point during the project life cycle, this event should be immediately recorded on the Risk
Management Matrix.

The Project Manager should summarize the project team's risk assessment and report the
findings to the project sponsor using the Project Risk summary report or the Project Risk detail
report. The project’s “Top Risks” are also documented at project inception in the project
Statement of Work (SOW).

Risk identification must include two elements:

• The Risk Condition, the cause of a risk event, and

• The Risk Consequence, the effect of the risk event on the project.

It may be helpful to define risk conditions as one of three types:

• Business Risk – A business condition that may arise that would impact the project.
Examples may include introduction of a competitor’s product, a merger, serious business
downturn or upswing, reorganization, etc.

• Technology Risk – Introduction of new technology to the organization. This may include
system components that are being developed by outside vendors.

• Project Risk – All of the things that can happen on a project, including such factors as
personnel turnover, poorly understood requirements, inadequate project plan, insufficient
project budget, work outside the project scope, scope creep, etc.

James A. Ward & Associates, Inc. 3

The risk consequence should define the effect, or “impact,” on the project in terms of the
following three variables:

• The Project Scope - Impact on the ability to deliver all or some of the defined functions
and features of the product or the performance attributes that have been specified, either
explicitly or implicitly, for the product.

• The Project Cost - Impact on the ability to deliver the product within the specified project
budget.

• The Project Schedule - Impact on the ability to deliver the product within the defined
time frame for the project.

Should the project team be unable to define risk consequences for any of the above three items, it
should be assumed that the identified future event does not pose a risk to the project.

The following table may prove helpful in analyzing risks.

IMPACT SCOPE COST SCHEDULE

TYPE
Business X
Technology X X
Project

Risk identification is an ongoing process to document the future risk events. Any new or
changed risks should be incorporated into the analysis from a project's start through its
completion. All risks are to be recorded on the Risk Matrix.

In addition to project inception, Risk Identification should take place on a formal basis at the
beginning of each major project phase or iteration and any time a significant change to the
project occurs, such as a scope change or changes in key project personnel.

Step 3: Risk Analysis

Risk qualification, quantification and analysis is an ongoing process which evaluates risks to
assess the range of possible project outcomes. The evaluation may be conducted as individual
assessments by assigned team members with the results presented to the project team and
stakeholders for discussion and concurrence, or as working sessions with key project team
members where a joint assessment is recorded.

For each risk the Project Team should address four risk factors:
• Identify risk probability
Estimate the probability that the risk event will, in fact, occur. This probability will be
defined as:

James A. Ward & Associates, Inc. 4

 • HIGH (value = 3): The event probably will occur.

• MEDIUM (value = 2): The event is equally likely to occur or not occur.

• LOW (value = 1): The event is unlikely to occur during the life of the project.

Probability rating is mostly determined by expert judgment based on evaluating the

history of other projects and the information available. Preliminary risk evaluation and
assessment is executed with the input of project team members and stakeholders.

In this assessment, if an adverse event is virtually certain to occur, it should be treated as

either an Issue or a Constraint by the project team. If an adverse event is extremely
unlikely to occur, this may be documented as an Assumption.

• Identify risk impact

Estimate the impact on each of the three key variables of Scope, Cost and Schedule,
should the risk event occur. Note that this impact should be framed primarily in the
manner in which it impacts “the customer” and not “the project.” As an example, a
schedule impact may have a significant impact on the customer if the project must meet a
legally mandated deadline or must support implementation of a new product or service
that has been announced to start on a given date. On the other hand, a schedule slippage
may have no appreciable impact on the customer but may mean that resources dedicated
to this project will not be available as planned to start another critical project. All impacts
must be identified and assessed.

The impact of a risk event should be defined as:

• HIGH (value = 3): Critical to the customer or the project, may even force project
cancellation.

• MEDIUM (value = 2): Significant, but not catastrophic. The project would be able to
recover and meet its objectives at a level that is acceptable to management and the
customer.

• LOW (value = 1): Relatively little impact to the project that cannot be successfully dealt
with. The risk event, should it occur, is considered to be circumstantial or of slight
consequence to the objectives of the project.

James A. Ward & Associates, Inc. 5

 •

• Calculate Risk Exposure

Multiply Risk Probability by the Risk Impact, yielding a numeric Risk Exposure.
Possible risk exposure results are 1, 2, 3, 4, 6 and 9.

James A. Ward & Associates, Inc. 6

 • Prioritize risks
Set risk priorities to direct focus where it is most critical. Determine the risks that are
potentially the most harmful to the project. The risks with the highest risk exposure
rating are the highest priority, or “Top Risks”.

This process can be done by sorting the Risk Management Matrix by Exposure Rating,
highest to lowest. All risks with an Exposure Rating of 9 or 6 must be dealt with, by
creating mitigation and contingency plans. Risks with Exposure Rating of 3 or 4 should
be recorded. If these are among the projects “Top Risks” they should also be addressed
proactively. Risks with Exposure Rating of 1 or 2 can be dropped from the analysis, but
may need to be revisited later in the project.

Where risks have an identical Exposure Rating, they should be prioritized by the project
team, to produce a Top Risk list.

About ten risks is the most that a project team can effectively deal with at any one time.
If the team finds that more than ten risks have an Exposure Rating of 9 or 6, they should
revisit the entire Risk Management process and should also seek guidance from
management, the Project Sponsor and stakeholders, as the project may be at high risk of
failure.

Step 4: Risk Response Planning

Risk response is the action plan to eliminate, reduce, or minimize the probability of a risk event
occurring and/or the impact of a risk event should it occur. The output from this activity is a
Risk Mitigation Plan that contains a set of actions directed at minimizing the potential
occurrence or impact of risks on a project and a Risk Contingency Plan, to be activated should
the risk event occur.

For risks requiring response, there are two strategies that are considered:
Mitigation, a pre-emptive strategy, is concerned with minimizing the threat posed by a
risk by removing the risk, reducing the risk, or avoiding the risk; e.g., benchmarks for
performance, start early, provide training, implement a formal change management
process, set expectations, involve customer in early planning sessions. Risk warning
flags or risk outcomes can be a part of the mitigation plan.
Risk mitigation strategies include the following:
• Acceptance: The project can live with the consequences of the risk event, and
deal with it effectively should the event occur.
• Avoidance: Elimination of the risk by doing something less risky. For example,
the team may decide to eliminate a non-critical requirement from the initial release of
the system if meeting that requirement poses a significant risk to the success of the
entire project.

James A. Ward & Associates, Inc. 7

 • Reduction: Minimize the likelihood that a risk event will occur (for example,
offering a bonus to a key project team member to remain on the team through the
duration of the project) or minimize the impact (for example, hiring a backup person
for a key team member).
• Transference: Shift the risk to someone else, including the responsibility for
response to a risk event. For example, requiring the users to develop a work-around
for a non-critical requirement that has been identified as a risk to the project.
Contingency strategy deals with the impact of a risk by creating a contingency plan that
will be activated should the conditions or warning flags occur, e.g., exceeded expected
resolution date, delay schedules, team is working extended hours, increased staff needs,
modified scope.
Contingency plans are necessary for all project risks, including those that have mitigation
plans. They focus on the consequences, when the risk event has occurred.
Contingency planning has three elements:
• The plan itself, containing specific actions to be taken in the event of an
occurrence of the risk event.
• Triggers, to determine when to activate the contingency plan. Triggers may be
specific events or conditions (thresholds) that are met. For example, an event that
may trigger a contingency plan is the resignation of a key team member. A
threshold may be schedule slippage of greater than two weeks.
• Triggers, to determine when to de-activate a contingency plan (not always
applicable). For example, contingency plans may be de-activated when the project
is back on schedule.
For each risk, the Project Manager should assign an owner responsible for developing
and maintaining its risk mitigation and contingency plans. The project work plan should
contain specific tasks with dates for the development of mitigation and contingency plans
for all risks.

Step 5: Risk Monitoring and Control

The Project Manager should implement and direct mitigation actions, monitor the mitigation
actions to determine their effectiveness, and revise the mitigation strategies as needed. The
project manager should:

• Implement the Risk Mitigation Plan - Implementing the Risk Mitigation Plan requires
the monitoring of the risk warning flags and reacting quickly to implement the risk
mitigation strategies. Effective mitigation is proactive, as problems rarely solve
themselves.
• Assess Mitigation Effectiveness - After implementing the Risk Mitigation Plan, the
project manager should assess the effectiveness of the risk mitigation actions.

James A. Ward & Associates, Inc. 8

 • Reassess Exposure - Evaluating the project's current risk status on a regular basis will
address the dynamic realities of the project. Project team meetings can be venues to raise
and report project risk and risk mitigation actions and results.

The Project Manager should address probability of risks and impact changes, as well as any new
risks that are identified. Newly identified risks should be subjected to the same risk assessment
and management process.

Risks that have been successfully mitigated should be “resolved” and that status should be
reflected in the Risk Management Matrix and on project reports. Successful mitigation means
reducing Risk Exposure to a level where the risk is no longer deemed by the project team to be
among the project’s “Top Risks.”

Step 6: Risk Review and Reporting

New risks that have been identified and old risks that have changed within the reporting period
should be communicated in project team meetings and should be included in all Project Status
reporting.

Risk changes will include the following:

• Successful mitigation, resulting in retiring or resolving a risk.

• Occurrence of a risk event, either previously identified or unidentified.
• Activation of a contingency plan or de-activation of that plan.
• Re-prioritization of “Top Risks” based on planned risk identification, risk mitigation or
changing project conditions.

RISK QUALITY ASSURANCE

Risk management quality assurance should measure:

• Total number of risks identified.

• Number and percentage of risks successfully mitigated.
• Number of occurrences of risk events, both identified and unidentified.
• Number and percentage of occurrence of unidentified risk events.
• Impact of the occurrence of risk events on Scope, Cost and Schedule.

James A. Ward & Associates, Inc. 9

i
Project Management Institute, Newtown Square, PA, USA
ii
Project Management Book of Knowledge, 2000 Edition , Project Management Institute Standards committee

JAMES A. WARD is an independent consultant specializing in systems development project management and
implementation of quality improvement initiatives. He can be reached at (904) 273-8777, via e-mail at
soozward@earthlink.net or on the web at www.JamesAWard.com.