Description
This paper presents a risk management process recently implemented by the government on a large-scale, multi-billion dollar, information system upgrade. The major features of this process are described. This includes how risks are identified, how the potential impacts of risks are assessed as a function of multiple evaluation criteria, and how identified risks are scored to produce a most-to-least critical risk ranking.
Implementing a Risk Management Process for a
Large Scale Information System Upgrade – A Case Study
Abstract This paper presents a risk management process recently implemented by the government on a large-scale, multi-billion
dollar, information system upgrade. The major features of this process are described. This includes how risks are identified, how the
potential impacts of risks are assessed as a function of multiple evaluation criteria, and how identified risks are scored to produce a
most-to-least critical risk ranking. In addition, methods are described for evaluating risk mitigation progress and visually displaying
risk status to decision-makers. The paper concludes with a summary of best practice considerations and recommendations.
1. Introduction
Managing the development or modernization of todays information systems re!uires
careful attention to risk. Inade!uate attention to risk, especially at the early stages of a
project, is often the reason behind cost overruns, schedule delays, and poor technical
performance. "#$
%ecently, a government agency embarked on a large scale, multi-billion dollar, upgrade
to a suite of information processing systems. &or purposes of this paper, this effort will
be referred to as the I' upgrade project. This project is a se!uential upgrade to an
enterprise-wide family of data processing systems. (s such, an enterprise-wide process
for managing risk was recognized as essential to the success of the effort. This paper
describes the major features of the risk management process designed for this upgrade.
)ey features discussed include how risks are identified and risk statements written, how
the potential impacts of risks are assessed, and how risks are characterized so a most-to-
least critical risk ranking is produced. In addition, displays designed for management to
track risk priority as a function of their potential impacts, occurrence probabilities, and
mitigation status are presented. The paper concludes with a summary of best practice
considerations and recommendations.
!. Process "#er#ie$
In general, risk management is a process focused on the identification and management
of events that could negatively affect projects, programs, or the enterprise. &ormally, risk
is the probability an unfavorable event occurs "#, *$. &rom a project management
perspective, risk is a measure of a projects inability to achieve its objectives within
specified constraints "#$. +onstraints may include cost, schedule, and technical
performance objectives. Traditionally, risk is measured according to two components,
the probability of failing to achieve specified objectives and the impact of failing to
achieve those objectives "#$.
The risk management process designed for the I' upgrade project is characterized by the
si- elements shown in figure #. This process is iterative and continuously performed
throughout the duration of the project. The first three elements address the risk analysis
aspects of the process. The last three address the risk management aspects of the process.
The following briefly defines these elements.
Identify Risks% %isk identification is the critical first step of the risk management process. %isk
identification defines the set of events that could have an unwanted impact on the projects cost, schedule,
or technical performance re!uirements. The objectives of risk identification are to enumerate known
project risks and, in so doing, identify risks not immediately evident to the project team. .ependencies
among risks must also be identified, since the risk of failing to achieve one objective often impacts the
ability to achieve others "#$.
Identify
Risks
Identify
Risks
Risk Analysis
Analyze
Risks
Analyze
Risks
Plan
Mitigation
Prioritize
Risks
Identified
Risks
Monitor
Analy&ed
Risks
Monitor
Risk Management
Reassess
Exposure
Reevaluate
Risk
Exposure
Mitigate
Risks
Develop
Management
Plans
Assess
Effectiveness
Evaluate
Progress
Prioriti&ed
Risks
Monitor
Monitor Monitor
Monitor or
+lose %isks
'e$
Risks
Report
Progress
Actions
Implemented
'tart
(igure 1. Risk Management Process )lements ? IS Upgrade Pro*ect
Analy&e Risks% This element is focused on assessing the probability that each identified risk will occur, the
severity of its impact to the project /if the risk does occur0, and the timeframe when the risks impact will
be felt on the project.
Prioriti&e Risks% This element is focused on determining the relative rank-order of the identified risks. (
1most-to-least critical2 risk ranking is computed as a function of each risks potential impacts to the I'
upgrade project. This ranking provides an input to management on where resources may be needed to
manage, or mitigate, potentially high impact risks.
+e#elop Management Plans% (fter the projects risks have been analyzed, a management plan is
developed for each risk. 3ike the previous elements of the risk management process, risk management
planning is a continuous process that includes the regular monitoring of risk handling actions in terms of
status and completion dates. The risk management planning process must identify what actions are needed,
when these actions must be completed, and who is responsible for their implementation and resolution.
)#aluate Progress% This element of the process is focused on assessing the progress of the risk-handling
actions defined in a risks management plan. 4ere, the primary contact for managing the identified risk is
responsible for evaluating, and reporting to management, the overall progress of the risk management plan.
Ree#aluate Risk ),posure% This activity involves continuing efforts to identify and assess new risks and
e-posures and to reevaluate e-isting risks and changes in previously understood e-posures as the project
progresses. The intent of this activity is to look towards the ne-t set of key project events and to identify
specific risks that may occur.
5ditorial considerations preclude a full discussion of the procedures designed and
implemented for each process element in figure #. Thus, the following summarizes the
key procedural features of just the first three elements of this process. .etails on the
procedures for all si- elements, as they were implemented on the I' upgrade project, is
available by contacting the author.
-. Procedural +etails
This section presents a high-level summary of the procedures designed for the Identify
Risk, Analyze Risk, and Prioritize Risk elements of the process shown in figure #. In
addition, displays designed for management to track risk priority as a function of their
potential impacts, occurrence probabilities, and mitigation status are presented.
-.1 Identify Risk…“You can only manage the risks you identify
Mentioned previously, risk identification is the critical first step of the risk management
process. %isk identification defines the set of events that could have an unwanted impact
on the I! upgrade pro"ect#s cost$ schedule$ or technical performance re%uirements. (ll
project stakeholders have the responsibility to assist in the identification, validation, and
eventual resolution of risk.
%isks are identified and validated through systematic engineering analyses, as well as by
the application of observation, judgment, and e-perience. %isk identification efforts
include reviews of written materials and interviews with subject e-perts in specific areas
of the project. 6orking sessions are regularly held, with key team members and
e-perienced personnel, to review and validate all identified risks.
The I' upgrade staff regularly review a set of risk checklists "7$ to aid in their
identification of project risks. These lists have been developed from government and
industry e-periences in managing risks on similar projects. They provide an independent
source for comparing a set of identified risks against those known to have occurred in the
past.
.riting t/e Risk Statement% Identified risks are described and communicated to
management in the form of risk statements. ( risk statement provides the clarity and
descriptive information re!uired for a reasoned and defensible assessment of the risks
occurrence probability and areas of impact. ( well-written risk statement contains two
components. They are a statement of the &ondition Present and the Associated Risk
'vent /or events0.
),ample 1% Risk Statement 1A large part of the software must now be written in &(
() the time re%uired to train the development team in &(( will e*tend the pro"ect#s
schedule by + months2.
4ere, the &ondition Present is 8A large part of the software must now be written in &(
(9: the Associated Risk 'vent is 8the time re%uired to train the development team in this
language will e*tend the pro"ect#s schedule by + months9.
In a risk statement, the &ondition Present is itself an event: it is an event that has
occurred or is presently occurring. Associated Risk 'vents are future events that might
occur because of the &ondition Present.
The &ondition Present acts as the departure point from which one or more Associated
Risk 'vents may originate. 5-ample * illustrates how three risk events A#, A*, and A7
originate from a single condition.
),ample !% Condition Present 8,ersion -./ 0v-./1 of the enterprise system
architecture is not yet defined) furthermore$ the schedule re%uired to deliver the
architecture is highly compressed and not synchronized to the ma"or funding and
review milestones of the systems being upgraded to comply to this architecture9.
Risk )#ents
A# ; 82ilestone funding and review schedules for each system being upgraded will slip
by more than + months due to the time re%uired for them to properly apply and
demonstrate compliance to the v-./ architecture9.
A* ; 83nce v-./ is delivered$ the current designs of the systems being upgraded may be
inade%uate to support the interoperability re%uirements of users9.
A7 ; 84he systems being upgraded may design functionality that is significantly less in
scope than v-./ will re%uire9.
6riting a risk statement according to the formalism described above, enables
management to clearly see the source and the nature of the risk. This improves the teams
ability to properly analyze the risk, make reasoned assessments of occurrence
probabilities, and select appropriate risk management strategies.
.AB - ? >.BB (n even chance to occur 2edium
C >.BB - ? >.EB 'omewhat greater than an even chance 2edium
C >.EB - ? >.FB 3ikely to occur 9igh
C >.FB - ? >.GB Hery likely to occur 9igh
C >.GB - ? >.IB (lmost sure to occur 9igh
C >.IB - J # 5-tremely sure to occur 9igh
3a4le !. Su4*ecti#e Pro4a4ility Assessment 5uide 678
( risk event that is certain not to occur has, by definition, probability e%ual to zero. In
this case, we say the risk event does not e-ist. Table * does not assign a categorical
rating /i.e., 9igh, 2edium, or 8ow0 to a risk event that is certain not to occur. ( risk
event that is certain to occur has, by definition, probability e%ual to one. In this case, we
say the event is no longer a risk: on the I' upgrade, it is considered an issue that presently
e-ists on the project. Table * does not assign a categorical rating /i.e., 9igh, 2edium, or
8ow0 to a risk event that is certain to occur.
Criterion% Impact
5ach risk on the I' upgrade project is characterized in terms of its potential effects on the
cost, schedule, and technical performance of the project. Table 7 presents these
definitions, which were developed by project personnel.
Area of Impact +efinition
+ost
This impact area refers to a risks potential effect on the overall budgeted cost of the I'
upgrade project. The cost impact area should include considerations for the impact of
risk on continued agency funding.
'chedule
This impact area refers to a risks potential effect on the I' upgrade projects schedule.
Technical
Kerformance
This impact area refers to a risks potential effect on the ability of the I' upgrade project
to achieve its overall functional and?or operational performance re!uirements. The
technical performance impact area includes considerations for the impact of risk on
Integration and Interoperability and :ependencies.
3a4le -. Areas of Impact for IS Upgrade Pro*ect Risks
In theory, it is desirable to assess these areas of impact !uantitatively. In practice, this is
difficult to do in an accurate or timely manner. &urthermore, the impact of risk on a
projects technical performance is difficult to e-press in a common unit or dimension.
Thus, risk impact assessments on the I' upgrade project are made on the basis of
carefully defined !ualitative ratings, as specified by the project team. These ratings are
then mapped into an e!uivalent numerical value /or score0
L
. &or each area of impact,
defined by the I' upgrade project, the following tables present the rating categories, their
associated definitions, and their e!uivalent numerical values /or scores0.
Rating +efinition
)9ui#alent 'umerical :alue
!evere
(n event whose occurrence will impact the projects cost
/and?or schedule0 so severely that the project will be
terminated.
1
9igh
(n event that, if it occurs, will cause significant cost /and?or
schedule0 increases /e.g., increases of more than B percent0 on
the project.
.efaults, >.EB, >.G7, >.IB
%ange, >.EB J Allowable ,alue J #
2oderate
(n event that, if it occurs, will cause noticeable cost /and?or
schedule0 increases /e.g., increases of not more than B
percent0 on the project.
.efaults, >.7B, >.B>, >.E>
%ange, >.7B J Allowable ,alue J >.EB
8ow
(n event that, if it occurs, will cause small cost /and?or
schedule0 increases that, in most cases, can be absorbed by the
project.
.efaults, >.>B, >.#G, >.7>
%ange, > J Allowable ,alue J >.7B
;one
(n event that, if it occurs, will cause no impact to cost /and?or
schedule0 of the project.
3a4le 7. Cost2Sc/edule Impact Ratings and +efinitions
Rating +efinition
)9ui#alent 'umerical :alue
!evere
(n event whose occurrence will impact the projects technical
performance so severely that the project will be terminated.
1
9igh
(n event that, if it occurs, will cause significant change to the
projects technical architecture and?or a significant loss of
re!uired functionality and?or a significant loss in re!uired
operational performance. Minimum acceptable re!uirements
will not be achieved.
.efaults, >.EB, >.G7, >.IB
%ange, >.EB J Allowable ,alue J #
2oderate
(n event that, if it occurs, will cause modest change to the
projects technical architecture and?or a modest loss of some
non-critical functionality and?or a modest loss of some non-
critical operational performance re!uirements. Minimum
acceptable re!uirements will be achieved.
.efaults, >.7B, >.B>, >.E>
%ange, >.7B J Allowable ,alue J >.EB
8ow
(n event that, if it occurs, will cause small /if any0 change to
the projects technical architecture and?or little-to-no loss of
re!uired functionality and?or little-to-no loss in re!uired
operational performance.
.efaults, >.>B, >.#G, >.7>
%ange, > J Allowable ,alue J >.7B
;one
(n event that, if it occurs, will cause no impact to the projectMs
technical architecture, re!uired functionality, or re!uired
operational performance.
3a4le ;. 3ec/nical Performance Impact Ratings and +efinitions
Tables A and B provide three default values for all but the !evere rating. The low default
values are used to represent situations where a risk event 1just crosses over2 into a higher
rating category. &or instance, if a risk to the I' upgrade project has just over a B percent
impact on its cost then it might be given a score of >.EB. 4owever, if a risk to the project
has a #> percent impact on its cost then it might be given a score of >.IB /or higher0.
L
The mathematical formalism for this mapping originates from utility theory. 5ach score reflects a value of the utility
function for this rating. The reader is directed to "#, A, B$ for a general technical discussion on this topic.
Criterion% 3imeframe
( timeframe is assessed for each identified risk. %isk timeframe refers to the time during
which a risk, if it occurs, will impact the project. This rating is assessed according to the
project-defined guideline in table E.
Rating Interpretation )9ui#alent 'umerical :alue
!hort
( risk is short-term if the project will be impacted
by the risk, if it occurs, in the ne-t 7> days.
.efaults, >.EB, >.G7, >.IB
%ange, >.EB J Allowable ,alue J #
2edium
( risk is medium-term if the project will be
impacted by the risk, if it occurs, in the ne-t 7> to
E> days.
.efaults, >.7B, >.B>, >.E>
%ange, >.7B J Allowable ,alue J >.EB
8ong
( risk is long-term if the project will be impacted
by the risk, if it occurs, beyond the ne-t E> days.
.efaults, >.>B, >.#G, >.7>
%ange, > J Allowable ,alue J >.7B
3a4le >* 2edium< /.A> !evere< -.// 9igh< /.@> 2oderate< /.A/ 2edium< /.@/
I'= .>>7 2edium< /.@/ 2oderate< /.>/ 2oderate< /.@/ 9igh< /.?+ 8ong< /.-?
3a4le =. Risk Analysis .orks/eet% Analy&e Risk Segment /'ample0
-.- Prioriti&e > +isplay Risk
This element of the risk management process is focused on determining the relative rank-
order of the identified risks. ( 1most-to-least critical2 risk ranking is computed as a
function of each risks potential impacts to the I' upgrade project. Table G presents a
summary of the Prioritize Risks segment of the Risk Analysis 5orksheet /%(60. The
entries in this segment of the %(6 are computed. The following describes how these
computations are made.
Prioriti&ing Risks
.EB and less than one.
The overall Rating of an identified project risk is rated 2oderate /in the projects %(60 if the !core for
that risk is greater than or e!ual to >.7B and less than >.EB.
The overall Rating of an identified project risk is rated 8ow /in the projects %(60 if the !core for that risk
falls between > and >.7B.
Table G summarizes the results of the scoring and risk ranking process described above.
Risk Analysis .orks/eet 0RA.1…Prioritize Risks !egment
IS Upgrade 0ISU1
Prioriti&e Risks
Risk
I+
Impact
Score
Impact
Rating
Risk
Score
Risk Priority
Rating
Risk Priority
Ranking
I'=.>># >.E*F 2oderate >.F7E 9igh *nd
I'=.>>* #.>>> !evere #.>>> !evere #st
I'=.>>7 >.EA7 2oderate >.AFA 2oderate 7rd
3a4le ?. Risk Analysis .orks/eet% Prioriti&e Risk Segment /'ample0
Risk !core is used to rank a risks priority relative to the other identified risks. The risk
with the highest risk score is ranked first in priority, the risk with the ne-t highest risk
score is ranked second in priority and so forth. The closer the risk score is to one the
higher the priority: the closer a risk score is to zero the lesser the priority.
+etermining Conse9uence Score
3astly, another measure is defined for identifying the criticality of managing potential
risks. G*AFGIEE>: www.dekker.com?e?p.pl?GIEE->.
7. Oarvey, Kaul %., Khair, .ouglas Q., 6ilson, Qohn (.: 1(n Information Technology
(rchitecture for %isk (ssessment and Management2, I''' !oftware, May, #IIF:
www.computer.org?software?so#IIF?s7toc.htm.
A. +ho, +. +., Oarvey, Kaul %., Oiallombardo, %obert Q.: 1%iskDav™, ( .ecision (id
for Krioritizing, .isplaying, and Tracking Krogram %isk2, 2ilitary 3perations
Research, H7, D*, #IIF: www.mors.org.
B. Oarvey, Kaul %., 3ansdowne, Sachary &.: 1%isk Matri-, (n (pproach for Identifying,
(ssessing, and %anking Krogram %isks2, Air Dorce Eournal of 8ogistics, Holume
TTII, Dumber #, Qune #IIG: www.mitre.org?resources?centers?sepo?risk?riskUmatri-.html.
K(=3 %. O(%H5P is +hief 'cientist for the 5conomic and .ecision (nalysis +enter at The
MIT%5 +orporation. 4e is the author of numerous technical papers, and book chapters, on cost uncertainty analysis
and the application of decision theory methods to problems in project risk management. 4e is a four-time recipient of
the best paper award from the =nited 'tates .epartment of .efense +ost (nalysis 'ymposium. Oarveys most recent
work is the te-t Probability 2ethods for &ost Bncertainty Analysis F A !ystems 'ngineering Perspective, published by
Marcel .ekker, Inc. Dew Pork, DP. Oarveys book presents how probability theory is applied to model, measure, and
manage risk in the cost of a systems engineering project. The work is a first of its kind in the cost analysis and
operations research communities.
C"'3AC3 I'("
Kaul %. Oarvey
+hief 'cientist
The 5conomic and .ecision (nalysis +enter
The MIT%5 +orporation
*>* Nurlington %oad
Nedford, M( >#F7>-#A*>
Mail 'top '#>B
Telephone, FG#-*F#-E>>*
&a-, FG#-*F#-EI7I
5mail, pgarveyVmitre.org
doc_285418808.doc
This paper presents a risk management process recently implemented by the government on a large-scale, multi-billion dollar, information system upgrade. The major features of this process are described. This includes how risks are identified, how the potential impacts of risks are assessed as a function of multiple evaluation criteria, and how identified risks are scored to produce a most-to-least critical risk ranking.
Implementing a Risk Management Process for a
Large Scale Information System Upgrade – A Case Study
Abstract This paper presents a risk management process recently implemented by the government on a large-scale, multi-billion
dollar, information system upgrade. The major features of this process are described. This includes how risks are identified, how the
potential impacts of risks are assessed as a function of multiple evaluation criteria, and how identified risks are scored to produce a
most-to-least critical risk ranking. In addition, methods are described for evaluating risk mitigation progress and visually displaying
risk status to decision-makers. The paper concludes with a summary of best practice considerations and recommendations.
1. Introduction
Managing the development or modernization of todays information systems re!uires
careful attention to risk. Inade!uate attention to risk, especially at the early stages of a
project, is often the reason behind cost overruns, schedule delays, and poor technical
performance. "#$
%ecently, a government agency embarked on a large scale, multi-billion dollar, upgrade
to a suite of information processing systems. &or purposes of this paper, this effort will
be referred to as the I' upgrade project. This project is a se!uential upgrade to an
enterprise-wide family of data processing systems. (s such, an enterprise-wide process
for managing risk was recognized as essential to the success of the effort. This paper
describes the major features of the risk management process designed for this upgrade.
)ey features discussed include how risks are identified and risk statements written, how
the potential impacts of risks are assessed, and how risks are characterized so a most-to-
least critical risk ranking is produced. In addition, displays designed for management to
track risk priority as a function of their potential impacts, occurrence probabilities, and
mitigation status are presented. The paper concludes with a summary of best practice
considerations and recommendations.
!. Process "#er#ie$
In general, risk management is a process focused on the identification and management
of events that could negatively affect projects, programs, or the enterprise. &ormally, risk
is the probability an unfavorable event occurs "#, *$. &rom a project management
perspective, risk is a measure of a projects inability to achieve its objectives within
specified constraints "#$. +onstraints may include cost, schedule, and technical
performance objectives. Traditionally, risk is measured according to two components,
the probability of failing to achieve specified objectives and the impact of failing to
achieve those objectives "#$.
The risk management process designed for the I' upgrade project is characterized by the
si- elements shown in figure #. This process is iterative and continuously performed
throughout the duration of the project. The first three elements address the risk analysis
aspects of the process. The last three address the risk management aspects of the process.
The following briefly defines these elements.
Identify Risks% %isk identification is the critical first step of the risk management process. %isk
identification defines the set of events that could have an unwanted impact on the projects cost, schedule,
or technical performance re!uirements. The objectives of risk identification are to enumerate known
project risks and, in so doing, identify risks not immediately evident to the project team. .ependencies
among risks must also be identified, since the risk of failing to achieve one objective often impacts the
ability to achieve others "#$.
Identify
Risks
Identify
Risks
Risk Analysis
Analyze
Risks
Analyze
Risks
Plan
Mitigation
Prioritize
Risks
Identified
Risks
Monitor
Analy&ed
Risks
Monitor
Risk Management
Reassess
Exposure
Reevaluate
Risk
Exposure
Mitigate
Risks
Develop
Management
Plans
Assess
Effectiveness
Evaluate
Progress
Prioriti&ed
Risks
Monitor
Monitor Monitor
Monitor or
+lose %isks
'e$
Risks
Report
Progress
Actions
Implemented
'tart
(igure 1. Risk Management Process )lements ? IS Upgrade Pro*ect
Analy&e Risks% This element is focused on assessing the probability that each identified risk will occur, the
severity of its impact to the project /if the risk does occur0, and the timeframe when the risks impact will
be felt on the project.
Prioriti&e Risks% This element is focused on determining the relative rank-order of the identified risks. (
1most-to-least critical2 risk ranking is computed as a function of each risks potential impacts to the I'
upgrade project. This ranking provides an input to management on where resources may be needed to
manage, or mitigate, potentially high impact risks.
+e#elop Management Plans% (fter the projects risks have been analyzed, a management plan is
developed for each risk. 3ike the previous elements of the risk management process, risk management
planning is a continuous process that includes the regular monitoring of risk handling actions in terms of
status and completion dates. The risk management planning process must identify what actions are needed,
when these actions must be completed, and who is responsible for their implementation and resolution.
)#aluate Progress% This element of the process is focused on assessing the progress of the risk-handling
actions defined in a risks management plan. 4ere, the primary contact for managing the identified risk is
responsible for evaluating, and reporting to management, the overall progress of the risk management plan.
Ree#aluate Risk ),posure% This activity involves continuing efforts to identify and assess new risks and
e-posures and to reevaluate e-isting risks and changes in previously understood e-posures as the project
progresses. The intent of this activity is to look towards the ne-t set of key project events and to identify
specific risks that may occur.
5ditorial considerations preclude a full discussion of the procedures designed and
implemented for each process element in figure #. Thus, the following summarizes the
key procedural features of just the first three elements of this process. .etails on the
procedures for all si- elements, as they were implemented on the I' upgrade project, is
available by contacting the author.
-. Procedural +etails
This section presents a high-level summary of the procedures designed for the Identify
Risk, Analyze Risk, and Prioritize Risk elements of the process shown in figure #. In
addition, displays designed for management to track risk priority as a function of their
potential impacts, occurrence probabilities, and mitigation status are presented.
-.1 Identify Risk…“You can only manage the risks you identify
Mentioned previously, risk identification is the critical first step of the risk management
process. %isk identification defines the set of events that could have an unwanted impact
on the I! upgrade pro"ect#s cost$ schedule$ or technical performance re%uirements. (ll
project stakeholders have the responsibility to assist in the identification, validation, and
eventual resolution of risk.
%isks are identified and validated through systematic engineering analyses, as well as by
the application of observation, judgment, and e-perience. %isk identification efforts
include reviews of written materials and interviews with subject e-perts in specific areas
of the project. 6orking sessions are regularly held, with key team members and
e-perienced personnel, to review and validate all identified risks.
The I' upgrade staff regularly review a set of risk checklists "7$ to aid in their
identification of project risks. These lists have been developed from government and
industry e-periences in managing risks on similar projects. They provide an independent
source for comparing a set of identified risks against those known to have occurred in the
past.
.riting t/e Risk Statement% Identified risks are described and communicated to
management in the form of risk statements. ( risk statement provides the clarity and
descriptive information re!uired for a reasoned and defensible assessment of the risks
occurrence probability and areas of impact. ( well-written risk statement contains two
components. They are a statement of the &ondition Present and the Associated Risk
'vent /or events0.
),ample 1% Risk Statement 1A large part of the software must now be written in &(
() the time re%uired to train the development team in &(( will e*tend the pro"ect#s
schedule by + months2.
4ere, the &ondition Present is 8A large part of the software must now be written in &(
(9: the Associated Risk 'vent is 8the time re%uired to train the development team in this
language will e*tend the pro"ect#s schedule by + months9.
In a risk statement, the &ondition Present is itself an event: it is an event that has
occurred or is presently occurring. Associated Risk 'vents are future events that might
occur because of the &ondition Present.
The &ondition Present acts as the departure point from which one or more Associated
Risk 'vents may originate. 5-ample * illustrates how three risk events A#, A*, and A7
originate from a single condition.
),ample !% Condition Present 8,ersion -./ 0v-./1 of the enterprise system
architecture is not yet defined) furthermore$ the schedule re%uired to deliver the
architecture is highly compressed and not synchronized to the ma"or funding and
review milestones of the systems being upgraded to comply to this architecture9.
Risk )#ents
A# ; 82ilestone funding and review schedules for each system being upgraded will slip
by more than + months due to the time re%uired for them to properly apply and
demonstrate compliance to the v-./ architecture9.
A* ; 83nce v-./ is delivered$ the current designs of the systems being upgraded may be
inade%uate to support the interoperability re%uirements of users9.
A7 ; 84he systems being upgraded may design functionality that is significantly less in
scope than v-./ will re%uire9.
6riting a risk statement according to the formalism described above, enables
management to clearly see the source and the nature of the risk. This improves the teams
ability to properly analyze the risk, make reasoned assessments of occurrence
probabilities, and select appropriate risk management strategies.
.AB - ? >.BB (n even chance to occur 2edium
C >.BB - ? >.EB 'omewhat greater than an even chance 2edium
C >.EB - ? >.FB 3ikely to occur 9igh
C >.FB - ? >.GB Hery likely to occur 9igh
C >.GB - ? >.IB (lmost sure to occur 9igh
C >.IB - J # 5-tremely sure to occur 9igh
3a4le !. Su4*ecti#e Pro4a4ility Assessment 5uide 678
( risk event that is certain not to occur has, by definition, probability e%ual to zero. In
this case, we say the risk event does not e-ist. Table * does not assign a categorical
rating /i.e., 9igh, 2edium, or 8ow0 to a risk event that is certain not to occur. ( risk
event that is certain to occur has, by definition, probability e%ual to one. In this case, we
say the event is no longer a risk: on the I' upgrade, it is considered an issue that presently
e-ists on the project. Table * does not assign a categorical rating /i.e., 9igh, 2edium, or
8ow0 to a risk event that is certain to occur.
Criterion% Impact
5ach risk on the I' upgrade project is characterized in terms of its potential effects on the
cost, schedule, and technical performance of the project. Table 7 presents these
definitions, which were developed by project personnel.
Area of Impact +efinition
+ost
This impact area refers to a risks potential effect on the overall budgeted cost of the I'
upgrade project. The cost impact area should include considerations for the impact of
risk on continued agency funding.
'chedule
This impact area refers to a risks potential effect on the I' upgrade projects schedule.
Technical
Kerformance
This impact area refers to a risks potential effect on the ability of the I' upgrade project
to achieve its overall functional and?or operational performance re!uirements. The
technical performance impact area includes considerations for the impact of risk on
Integration and Interoperability and :ependencies.
3a4le -. Areas of Impact for IS Upgrade Pro*ect Risks
In theory, it is desirable to assess these areas of impact !uantitatively. In practice, this is
difficult to do in an accurate or timely manner. &urthermore, the impact of risk on a
projects technical performance is difficult to e-press in a common unit or dimension.
Thus, risk impact assessments on the I' upgrade project are made on the basis of
carefully defined !ualitative ratings, as specified by the project team. These ratings are
then mapped into an e!uivalent numerical value /or score0
L
. &or each area of impact,
defined by the I' upgrade project, the following tables present the rating categories, their
associated definitions, and their e!uivalent numerical values /or scores0.
Rating +efinition
)9ui#alent 'umerical :alue
!evere
(n event whose occurrence will impact the projects cost
/and?or schedule0 so severely that the project will be
terminated.
1
9igh
(n event that, if it occurs, will cause significant cost /and?or
schedule0 increases /e.g., increases of more than B percent0 on
the project.
.efaults, >.EB, >.G7, >.IB
%ange, >.EB J Allowable ,alue J #
2oderate
(n event that, if it occurs, will cause noticeable cost /and?or
schedule0 increases /e.g., increases of not more than B
percent0 on the project.
.efaults, >.7B, >.B>, >.E>
%ange, >.7B J Allowable ,alue J >.EB
8ow
(n event that, if it occurs, will cause small cost /and?or
schedule0 increases that, in most cases, can be absorbed by the
project.
.efaults, >.>B, >.#G, >.7>
%ange, > J Allowable ,alue J >.7B
;one
(n event that, if it occurs, will cause no impact to cost /and?or
schedule0 of the project.
3a4le 7. Cost2Sc/edule Impact Ratings and +efinitions
Rating +efinition
)9ui#alent 'umerical :alue
!evere
(n event whose occurrence will impact the projects technical
performance so severely that the project will be terminated.
1
9igh
(n event that, if it occurs, will cause significant change to the
projects technical architecture and?or a significant loss of
re!uired functionality and?or a significant loss in re!uired
operational performance. Minimum acceptable re!uirements
will not be achieved.
.efaults, >.EB, >.G7, >.IB
%ange, >.EB J Allowable ,alue J #
2oderate
(n event that, if it occurs, will cause modest change to the
projects technical architecture and?or a modest loss of some
non-critical functionality and?or a modest loss of some non-
critical operational performance re!uirements. Minimum
acceptable re!uirements will be achieved.
.efaults, >.7B, >.B>, >.E>
%ange, >.7B J Allowable ,alue J >.EB
8ow
(n event that, if it occurs, will cause small /if any0 change to
the projects technical architecture and?or little-to-no loss of
re!uired functionality and?or little-to-no loss in re!uired
operational performance.
.efaults, >.>B, >.#G, >.7>
%ange, > J Allowable ,alue J >.7B
;one
(n event that, if it occurs, will cause no impact to the projectMs
technical architecture, re!uired functionality, or re!uired
operational performance.
3a4le ;. 3ec/nical Performance Impact Ratings and +efinitions
Tables A and B provide three default values for all but the !evere rating. The low default
values are used to represent situations where a risk event 1just crosses over2 into a higher
rating category. &or instance, if a risk to the I' upgrade project has just over a B percent
impact on its cost then it might be given a score of >.EB. 4owever, if a risk to the project
has a #> percent impact on its cost then it might be given a score of >.IB /or higher0.
L
The mathematical formalism for this mapping originates from utility theory. 5ach score reflects a value of the utility
function for this rating. The reader is directed to "#, A, B$ for a general technical discussion on this topic.
Criterion% 3imeframe
( timeframe is assessed for each identified risk. %isk timeframe refers to the time during
which a risk, if it occurs, will impact the project. This rating is assessed according to the
project-defined guideline in table E.
Rating Interpretation )9ui#alent 'umerical :alue
!hort
( risk is short-term if the project will be impacted
by the risk, if it occurs, in the ne-t 7> days.
.efaults, >.EB, >.G7, >.IB
%ange, >.EB J Allowable ,alue J #
2edium
( risk is medium-term if the project will be
impacted by the risk, if it occurs, in the ne-t 7> to
E> days.
.efaults, >.7B, >.B>, >.E>
%ange, >.7B J Allowable ,alue J >.EB
8ong
( risk is long-term if the project will be impacted
by the risk, if it occurs, beyond the ne-t E> days.
.efaults, >.>B, >.#G, >.7>
%ange, > J Allowable ,alue J >.7B
3a4le >* 2edium< /.A> !evere< -.// 9igh< /.@> 2oderate< /.A/ 2edium< /.@/
I'= .>>7 2edium< /.@/ 2oderate< /.>/ 2oderate< /.@/ 9igh< /.?+ 8ong< /.-?
3a4le =. Risk Analysis .orks/eet% Analy&e Risk Segment /'ample0
-.- Prioriti&e > +isplay Risk
This element of the risk management process is focused on determining the relative rank-
order of the identified risks. ( 1most-to-least critical2 risk ranking is computed as a
function of each risks potential impacts to the I' upgrade project. Table G presents a
summary of the Prioritize Risks segment of the Risk Analysis 5orksheet /%(60. The
entries in this segment of the %(6 are computed. The following describes how these
computations are made.
Prioriti&ing Risks
.EB and less than one.
The overall Rating of an identified project risk is rated 2oderate /in the projects %(60 if the !core for
that risk is greater than or e!ual to >.7B and less than >.EB.
The overall Rating of an identified project risk is rated 8ow /in the projects %(60 if the !core for that risk
falls between > and >.7B.
Table G summarizes the results of the scoring and risk ranking process described above.
Risk Analysis .orks/eet 0RA.1…Prioritize Risks !egment
IS Upgrade 0ISU1
Prioriti&e Risks
Risk
I+
Impact
Score
Impact
Rating
Risk
Score
Risk Priority
Rating
Risk Priority
Ranking
I'=.>># >.E*F 2oderate >.F7E 9igh *nd
I'=.>>* #.>>> !evere #.>>> !evere #st
I'=.>>7 >.EA7 2oderate >.AFA 2oderate 7rd
3a4le ?. Risk Analysis .orks/eet% Prioriti&e Risk Segment /'ample0
Risk !core is used to rank a risks priority relative to the other identified risks. The risk
with the highest risk score is ranked first in priority, the risk with the ne-t highest risk
score is ranked second in priority and so forth. The closer the risk score is to one the
higher the priority: the closer a risk score is to zero the lesser the priority.
+etermining Conse9uence Score
3astly, another measure is defined for identifying the criticality of managing potential
risks. G*AFGIEE>: www.dekker.com?e?p.pl?GIEE->.
7. Oarvey, Kaul %., Khair, .ouglas Q., 6ilson, Qohn (.: 1(n Information Technology
(rchitecture for %isk (ssessment and Management2, I''' !oftware, May, #IIF:
www.computer.org?software?so#IIF?s7toc.htm.
A. +ho, +. +., Oarvey, Kaul %., Oiallombardo, %obert Q.: 1%iskDav™, ( .ecision (id
for Krioritizing, .isplaying, and Tracking Krogram %isk2, 2ilitary 3perations
Research, H7, D*, #IIF: www.mors.org.
B. Oarvey, Kaul %., 3ansdowne, Sachary &.: 1%isk Matri-, (n (pproach for Identifying,
(ssessing, and %anking Krogram %isks2, Air Dorce Eournal of 8ogistics, Holume
TTII, Dumber #, Qune #IIG: www.mitre.org?resources?centers?sepo?risk?riskUmatri-.html.
K(=3 %. O(%H5P is +hief 'cientist for the 5conomic and .ecision (nalysis +enter at The
MIT%5 +orporation. 4e is the author of numerous technical papers, and book chapters, on cost uncertainty analysis
and the application of decision theory methods to problems in project risk management. 4e is a four-time recipient of
the best paper award from the =nited 'tates .epartment of .efense +ost (nalysis 'ymposium. Oarveys most recent
work is the te-t Probability 2ethods for &ost Bncertainty Analysis F A !ystems 'ngineering Perspective, published by
Marcel .ekker, Inc. Dew Pork, DP. Oarveys book presents how probability theory is applied to model, measure, and
manage risk in the cost of a systems engineering project. The work is a first of its kind in the cost analysis and
operations research communities.
C"'3AC3 I'("
Kaul %. Oarvey
+hief 'cientist
The 5conomic and .ecision (nalysis +enter
The MIT%5 +orporation
*>* Nurlington %oad
Nedford, M( >#F7>-#A*>
Mail 'top '#>B
Telephone, FG#-*F#-E>>*
&a-, FG#-*F#-EI7I
5mail, pgarveyVmitre.org
doc_285418808.doc