It Works!
Risk Management on an IS Project
Joseph A. Lukas, PMP, PE
Introduction
Risk management is the process of identifying potential project
risks, assessing the probability and severity of risk events, and plan-
ning responses for the most important risk events. People tend to
relate only negative events to the term risk. However, risk includes
all uncertainty on a project and includes both the positive (oppor-
tunities) and negatives (threats).
This paper describes the successful use of risk management on an
information systems (IS) project to create a new capital manage-
ment system (CMS) for a Fortune 500 company. This IS project was
done to create a new, customized intranet-based software package
that will be used for managing the capital budget and expenditures
for the company. The client sponsor’s most important project ob-
jective was completing the project within budget, followed by func-
tionality and then schedule. The presentation will describe how risk
management was a major part of the detailed project plan and
helped ensure project success.
This paper explains the specific risk identification technique used
by the project team. Each project risk was described using a standard
sentence format describing the cause, risk event and consequence.
The team then used qualitative risk analysis to better understand the
potential of each risk event. The scales used to assign a value for
probability and risk impact for each risk event will be reviewed.
Using these numbers, an expected value was calculated to determine
which risk events warranted specific risk response planning.
The presentation will cover risk response planning, which was
done as part of the project plan. For all major risks, mitigation
plans were prepared to reduce the likelihood of threats and to max-
imize the likelihood of opportunities. Contingency plans were also
prepared for the major risks. The spreadsheets developed on this
project to document the risk processes used will be reviewed. The
talk will conclude with a discussion on the use of risk monitoring
and control on the project. This included a status review of all risk
events as part of the weekly project team meeting. The talk will pro-
vide ideas on how to apply risk management to your projects!
Project Background
This IS project provided a new customized intranet-based soft-
ware package to manage the capital budget and expenditures for a
Fortune 500 company with multiple manufacturing plants around
the world. Capital projects include things such as new manufac-
Proceedings of the Project Management Institute Annual Seminars & Symposium
October 3–10, 2002 • San Antonio,Texas, USA
turing facilities, upgrades to production equipment, new or reno-
vated office areas, and storage facilities.
The business case for the new CMS software was productivity sav-
ings in managing the capital budget for the company. CMS re-
placed over ten obsolete systems in use at various plant sites. These
legacy systems were only accessible by a few administrative per-
sonnel, did not interface with each other and used old software that
was no longer supported. In addition, the legacy systems did not
provide online access to project information for most users and had
very limited reporting capability.
The new CMS software provides about 200 data fields for each
capital project including project description, justification category,
business case data, budgets, actual costs, key schedule dates, proj-
ect team members, project status and project performance mea-
sures. Actual projects costs are uploaded from existing cost systems
used at the various plant sites. The software also provides summary
level information that can be rolled up by business unit or plant site.
CMS includes standard reports that can be run by project, by busi-
ness unit, plant site or rolled up for the entire company. The system
includes various levels of security to limit access to project data, and
provides the ability to search the database for multiple selected
criteria (such as for a specific justification category like capitalized
maintenance projects being planned for the next year).
The resource plan for this IS project was contracting design and
programming to a software vendor. The project team was lead by
an experienced IS project manager from the client company. The
team also included the database manager and a few key users of the
existing capital budget systems. Once the software contractor was
selected during project requirements definition, the team was ex-
panded to include the contractor project manager and a lead tech-
nical consultant. Once the project was fully defined and approved,
the contractor finalized the project price and added programmers
to the project team. An experienced project management coach with
an extensive background in the use of risk management and earned
value assisted the team from project initiation to completion.
The Risk Management Process
Risk is a frequent occurrence in all aspects of our lives. People tend
to relate only negative events to the term risk. However, risk in-
cludes all uncertainty on a project, both the positive and the nega-
tive. Risk management is the process of identifying potential proj-
ect risks, assessing the probability and severity of risk events, and
Exhibit 1. Identified Risks on the CMS Project

Risk CAUSE RISK EVENT CONSEQUENCE

# due to <cause> <risk event> could occur resulting in <consequence>
The many job opportunities for top-
The loss of key project personnel Higher costs and a longer schedule
1 notch programmers
A time & material contract with the Cost increases due to
A higher project cost
2 software vendor underestimates
The database manager having
A lack of needed functionality with
multiple job assignments and a lack Missing key project requirements
the new system
3 of time for the CMS project
Increases in cost due to scope
Late changes in requirements A higher project cost
4 changes
A lack of space to support CMS on
Other systems projects underway The need to purchase a new server
5 existing servers
the obsolete legacy cost systems in The inability to automatically feed Extra manual work each month to
6 use at different plant sites actual cost data to CMS load actual cost data
The inconsistent use of data fields Extra manual work (and costs) to
The inability to automatically
with the existing capital budget move existing project data to the
transfer existing project data to CMS
7 systems new system
Poor data quality because of
System launch without the
A lack of training resources untrained users entering incomplete
necessary training materials
8 data

planning responses to the most important project risks. The goal of
risk management is to identify all project risks and develop strate-
gies to maximize the effects of potential opportunities and signifi-
cantly reduce or eliminate the potential impact of threats.
Companies that consistently excel in project delivery, typically
have a well-documented project process in use, which includes risk
management. An excellent reference on the project risk management
process is A Guide to the Project Management Body of Knowledge
(PMBOK® Guide), published by the Project Management Institute.
The material presented in this article is consistent with the
PMBOK® Guide, which describes the generally accepted project
management knowledge. However, generally accepted doesn’t
mean that the knowledge and practices should be uniformly applied
on all projects. The project team is responsible for determining
the appropriate tools and techniques to apply on a project. For ex-
ample, the risk management plan for construction of a multibillion-
dollar chemical plant would be more extensive than the risk man-
agement plan for a simple office renovation. The risk management
processes are as follows:
• Risk Management Planning. Deciding how to approach and plan
the risk management activities for the project.
• Risk identification. Determining which risks may affect the proj-
ect and understanding the characteristics of the risk events.
• Risk analysis. Using qualitative and/or quantitative techniques
to understand the probability and severity of each risk event, in
order to prioritize the risk events based on impacts to the project
objectives.
• Risk response planning. Determining actions that the project
team can take for each major risk event, in order to maximize any
opportunities and minimize threats to the project objectives.
• Risk monitoring and control. Keeping track of major potential
risks, implementing the risk response plan when risk events do
occur, and watching for any new risks.
Risk Identification
Risk identification involves information-gathering techniques that
determine which risks may affect the project and the characteris-
tics of each risk event. Risk characteristics include the possible fre-
quency of the risk event, the range of outcomes, the type of risk, im-
pacts if the risk event occurs and symptoms of the risk event. Many
different techniques are available for identification of project risks.
These include the following:
Brainstorming. The free flow of ideas used to generate a listing
of potential risk events. The key to brainstorming is to not prejudge
any idea until after completion of the brainstorming session.
Phrases to avoid during brainstorming include: “that can’t happen”
and “what a dumb idea.”
Checklists. A listing of risk events typically encountered for a spe-
cific type or class of projects. The project team reviews the check-
list when starting a new project to identify specific risk events that
may occur. Checklists can be organized by project phase, major de-
liverables or by impacts to the project.
Interviews. Discussions with project team members and other
stakeholders can help identify risks not identified during normal
planning activities. A good source of risk information is from peo-
ple who have done similar projects in the past.
Flowcharting. Diagramming techniques displaying how various
elements of a project are related. This illustrates how risk events and
causes relate to create potential risk impacts and help the team
better understand causes and effects of risks.

Proceedings of the Project Management Institute Annual Seminars & Symposium

October 3–10, 2002 • San Antonio,Texas, USA
Identifying Risks on the CMS Project
To help the CMS project team focus on risk events, a technique was
used to describe each risk by listing the risk cause, risk event, and
consequence. This technique was introduced in an excellent article
titled “Project Risks, Identifying Causes, Risks and Effects” by David
Hillson, PMP. This article was published in the September 2000
issue of PM Network.
A common error during risk identification is not differentiating
between risk causes, risk events, and consequences (also called im-
pacts or effects). This failure can dilute the risk identification
process by not providing focus on actual risk events. Risk events
have one unique feature, and that is uncertainty!
A risk cause is a definite event or circumstance that exists. For ex-
ample, purchasing a special piece of equipment from a foreign
supplier would be a risk cause if the only alternative were buying
the equipment from the foreign supplier due to patents. The risk
event could be exchange rate fluctuations or poor communica-
tions due to language barriers.
The consequences are the results that will occur if the risk event
happens. For the example above, if the exchange rate does fluctu-
ate, it will have an impact on the project cost. Keep in mind this im-
pact could be favorable! If the foreign currency drops relative to the
U.S. dollar, this becomes an opportunity for the project team.
A good technique to use when doing risk identification is to ex-
press each project risk as a sentence covering the cause, risk event,
and consequence. A suggested format is: “Due to <cause>, <risk
event> could occur, resulting in <consequence>”
An example would be “Due to purchase of the equipment from an
overseas vendor, exchange rate fluctuations could occur, resulting in a
cost impact to the project budget.”Another example would be “Due to
sharing a senior programmer between two projects, a work overload
could occur, resulting in a schedule delay on one or both projects.”
The CMS project team used this technique to identify potential
risk events. A brainstorming session was held with the entire team,
and a listing of risk events was developed. Then the team used the
risk cause, risk event, and consequence technique to fully describe
each risk. For example, in Exhibit 1 Risk #3 reads: “Due to the
database manager having multiple jobs, missing key project re-
quirements could occur, resulting in a lack of needed functionality
with the new system.” Risk #1 reads: “Due to the many job oppor-
tunities for top-notch programmers, the loss of key project per-
sonnel could occur, resulting in higher costs and a longer schedule.”
In order to keep the Exhibit 1 to a reasonable size, not all identified
risks on the CMS project are listed.
Qualitative Risk Analysis on the CMS Project
Once the risk identification process was completed, the project
team used a qualitative risk analysis process to understand the like-
lihood (probability) and consequence (severity or impact) of each
risk event. This was done to identify those risks that required risk
response planning. The technique the team used is from the
PMBOK® Guide, and also from an excellent article titled “Qualita-
tive Risk Assessment” by Roger Graves. This article was published
in the October 2000 issue of PM Network.
Proceedings of the Project Management Institute Annual Seminars & Symposium
October 3–10, 2002 • San Antonio,Texas, USA
Exhibit 2. Risk Probability Scale Used by the CMS
Team to Determine for Each Project Risk the Level of
Probability
Probability Description
1.0 Certain to Occur
0.8 Highly Likely
0.6 Likely
0.4 Low Likelihood
0.2 Very Unlikely
0.0 No Probability of Occurring
For the CMS project, the team decided on a simple probability
scale as detailed in Exhibit 2.
Impact (Consequences) Scale
Basically, there are only four possible consequences to any risk event
on any project. They are cost, schedule, quality and/or functional-
ity impacts. In this definition, quality can cover a variety of miscel-
laneous impacts, including how well the product works and safety.
On any project, it is vital for the project team to understand what is
most important to the client. This is essential knowledge so the
team can accurately access the impact of any risk event on the proj-
ect. For example, if schedule is not critical to the client, then a risk
event with a schedule impact would have a lower impact rating.
On the CMS project money was limited, so the most critical im-
pact was cost. The team needed to complete the project within or
below the allocated budget. Functionality and quality were second
in importance, since it was necessary to provide the data fields and
information needed by Project Managers and management. Also,
the system had to be user friendly to ensure it was accepted and
used. Schedule was the least important driver. The desire was to im-
plement CMS in January 2002 since that was the time period of
lowest system use. However, a delay was not a significant problem
since the legacy systems could continue to be used until the new sys-
tem got up and running.
For the CMS project, the team used a simple consequence (im-
pact) scale as detailed in Exhibit 3. The highest impact value is
chosen if any of the criteria is met for that value. For example, if the
risk event had a very high cost impact, the impact value was a 10
even if there were no functionality, quality or schedule issues.
Calculating Expected Value for Each Risk
Each identified risk event on the CMS project was assigned a proba-
bility and impact value using the Exhibits 2 and 3. An expected value
was then calculated for each risk event using the following formula:
Expected Value (EV) = Probability x Impact Rating
Expected value provides a scale to assess the importance of each
risk event relative to other risk events. Using the probability and
Exhibit 3. Project Impact Scale Used on the CMS Project Shows That Schedule Was not a Major Project Driver

Impact
Value Cost Schedule Functionality Quality
10 very high impact - major issue major issue
8 high impact - medium issue medium issue
6 medium impact major impact minor issue minor issue
4 low impact medium impact very small issue very small issue
2 - low impact - -
0 - - - -

Exhibit 4.The CMS Project Risks Expected Values Helped Team Members Focus on the Most Important Risks

Risk RISK EVENT Probability Impact Expected

# (0 - 1.0) (0 - 10) Value
1 The loss of key project personnel 0.4 10.0 4.0
Cost increases due to
2 underestimates 0.5 8.0 4.0
3 Missing key project requirements 0.9 10.0 9.0
Increases in cost due to scope
4 changes 0.2 9.0 1.8
A lack of space to support CMS on
5 existing servers 0.7 9.0 6.3
The inability to automatically
transfer existing project data to CMS
6 0.6 9.0 5.4
The inability to automatically feed
7 actual cost data to PIMS 0.5 10.0 5.0
System launch without the
8 necessary training materials 0.8 7.0 5.6

impact scales defined by the CMS project team, the maximum ex-
pected value a risk event could have is 10 (1.0 probability x 10 impact).
The CMS project team decided that risk events with an expected
value over 5.0 warranted specific risk response planning, and risk
events below 5.0 deserved watching, but not necessarily specific action.
Exhibit 4 shows the assigned probability, impact and expected value
for each risk event on the CMS project. For simplicity, not all identi-
fied risk events on the CMS project are shown in Exhibit 4.
Risk Response Planning
Risk response planning is the process of developing plans and ac-
tions to respond to specific risk events. The effectiveness of risk re-
sponse planning will greatly influence how much the risk level de-
creases as the project continues. The risk response techniques com-
monly used are described below.
Avoidance is changing the project plan to eliminate either the risk
event or the impact. However, keep in mind that the project team
can never eliminate all risk events! An example of avoidance is
adopting a familiar approach instead of a new and untried innov-
ative approach. Another example of avoidance is selecting a site for
a new shopping mall in a town with a friendly town planning board
where quick approval of building plans occur.
Transference is shifting the risk event impact to a third party
along with ownership of the risk response. Transferring the risk
simply gives another party responsibility for the risk but the risk
isn’t eliminated. Transference is most effective in dealing with fi-
nancial risk exposure. However, risk transfer almost always in-
volves payment of a risk premium to the party taking on the risk.
Examples of transference include insurance, warranties and fixed
price contracts.
Mitigation is reducing the expected value of a risk event by re-
ducing the probability of occurrence and/or the risk event value. It
looks to change conditions so that the probability of the risk event
occurring is reduced.
An example of mitigation to prevent missing a schedule com-
pletion date is adding more resources. Mitigation also looks to re-
duce the risk impact. An example of this is airplanes that have re-
dundant hydraulic systems to greatly reduce the impact of a failure
of any one hydraulic system.
Acceptance as a risk response technique is where the project
team has decided not to change the project plan to deal with the
risk—or more likely, is unable to identify any other suitable re-
sponse strategy. Acceptance can be either passive or active. The ac-
tive acceptance response is developing a contingency plan in case the
risk event occurs. An example of active acceptance is developing an
alternative schedule plan to deal with late delivery of key equipment.

Proceedings of the Project Management Institute Annual Seminars & Symposium

October 3–10, 2002 • San Antonio,Texas, USA
Exhibit 5. Sample Mitigation and Contingency Plans on the CMS Project

Risk RISK EVENT Probability Impact Expected Mitigation Plan Contingency Plan
# (0 - 1.0) (0 - 10) Value

* Include in the resource plan a

Missing key project
requirements
3 0.9
A lack of space to support CMS
5 on existing servers 0.7
System launch without the
necessary training materials
8 0.8
detailed estimate of activities and
hours needed by key resources
* Get management commitment to
dedicate key personnel to this project
10.0 9.0
* Get commitment from systems
9.0 6.3 support for space required
* Get management commitment to
dedicate key personnel to this project companies to prepare materials
7.0 5.6
* If problem persists for more than 2
weeks, elevate issue to project
sponsors
* Include $25k in project budget for
server
* Investigate vendor training

The passive acceptance response would be doing nothing until the Conclusion
risk event occurs.
Risk Response Planning on the CMS Project Successful project teams include risk management as part of their
project plan. The probability of success on any project is much
Exhibit 5 shows the risk planning worksheet used by the CMS proj- higher when the project team follows a structured risk management
ect team for some representative risk events. Exhibit 5 only shows process. On the Capital Management System (CMS) IS project,
a few representative examples from the CMS project. use of risk management helped ensure successful completion of the
Mitigation was the biggest response technique used by the CMS project.
team, and this technique looks to reduce the expected value of the
risk event by reducing either or both the probability and impact. It References
makes sense that if a risk has high likelihood of occurring, the Graves, Roger. 2000. Qualitative Risk Assessment. PM Network (Octo-
team won’t just sit idle, but will try to intervene to reduce the prob- ber), pp. 61–66.
ability of the risk event. Likewise, if the consequences of the risk Hillson, David. 2000. Project Risks—Identifying Causes, Risks, and Ef-
event are high, the team will look for methods to reduce the impact. fects. PM Network (September): pp. 48–51.
In addition to mitigation planning, the project team also considered Lukas, Joseph. 1995. Managing Risks on Capital Projects. AACE Trans-
contingency plans in case the risk event did occur. This allows a actions.
team to quickly respond to any risk event that does occur. The Lukas, Joseph. 2001. Manage Project Risks with Success. Inside Project
spreadsheet in Exhibit 5 includes columns for mitigation and con- Management (November), pp. 1–5.
McKim, Robert. 1992. Risk Management—Back to Basics. Cost Engi-
tingency plans, along with columns for responsible person and sta-
neering (December), pp. 7–12.
tus. The project team reviewed the risk spreadsheet at the weekly
Project Management Institute Standards Committee. 2000. A Guide to
team meetings. the Project Management Body of Knowledge. PMBOK® Guide. 2000 Edition.
Newtown Square, PA: Project Management Institute.
Risk Response Monitoring and Control Royer, Paul. 2000. Risk Management: The Undiscovered Dimension of
Project Management. PM Network (September), pp. 31–39.
Note that probability and impact are not fixed during the project
life! As the project team implements actions to mitigate risk prob-
abilities and impacts, the associated values should drop. This means
the expected value should also decrease, reducing the overall risk
level on the project.
For example, in Exhibit 5, Risk Event #3 (missing key project re-
quirements) has a high probability and impact. The high probability
(0.9) resulted from the database manager holding multiple jobs. The
mitigation plan was getting management commitment to dedicate
the database manager to the CMS project and finding another per-
son to pick up her other job responsibilities. Once this happened,
the probability dropped from 0.9 down to 0.4. In addition, once the
project requirements were totally defined, the impact dropped
from 10 down to 4. This means the expected value of Risk Event #3
dropped from 9.0 down to 1.6, which is a very low risk event value.
This is the goal of the project team—to reduce the expected value
of risks and to increase the expected value of opportunities.

Proceedings of the Project Management Institute Annual Seminars & Symposium

Previous Menu
October 3–10, 2002 • San Antonio,Texas, USA