Understanding Risk Management
Software Technology Support Center
The U.S. Air Force’s Software Technology Support Center offers an updated and condensed version of the “Guidelines for
Successful Acquisition and Management of Software-Intensive Systems” (GSAM) on its Web site <www.stsc.hill.af.mil/
resources/tech_docs>. This article is taken from Chapter 5 “Risk Management” of the GSAM (Version 4.0). We are
pleased that all editions have been so well received and that many individuals and programs have worked hard to implement
the principles contained therein. The latest edition provides a usable desk reference that gives a brief but effective overview of
important software acquisition and development topics, provides checklists for rapid self-inspection, and provides pointers to
additional information on the topics covered.
R isk is a product of the uncertainty of
future events and is a part of all
activity. It is a fact of life. We tend to stay
ty of the event actually occurring by the
potential negative impact to the cost,
schedule, or performance of the project:
digms, certain characteristics are univer-
sally required for the program to be suc-
away from situations that involve high • The risk management process is
risk to things we hold dear. When we can- Risk Severity = Probability of planned and structured.
not avoid risk, we look for ways to reduce Occurrence x Potential Negative • The risk process is integrated with the
it or its impact upon our lives. Yet even Impact acquisition process.
with careful planning and preparation, • Developers, users, procurers, and all
risks cannot be completely eliminated Thus, risks where probability of occur- other stakeholders work together
because they cannot all be identified rence is high and potential impact is very closely to implement the risk process.
beforehand. Even so, risk is essential to low, or vice versa, are not considered as • Risk management is an ongoing
progress. serious as risks where both probability of process with continual monitoring
The opportunity to succeed also car- occurrence and potential impact are and reassessment.
ries the opportunity to fail. It is necessary medium to high. • A set of success criteria is defined for
to learn to balance the possible negative Project managers recognize and all cost, schedule, and performance
consequences of risk with the potential accept the fact that risk is inherent in any elements of the project.
benefits of its associated opportunity . project. They also recognize that there • Metrics are defined and used to mon-
Risk may be defined as the possibility to are two ways of dealing with risk. One, itor effectiveness of risk management
suffer damage or loss. The possibility is risk management, is proactive and care- strategies.
characterized by three factors : fully analyzes future project events and • An effective test and evaluation pro-
1. The probability or likelihood that loss past projects to identify potential risks. gram is planned and followed.
or damage will occur. Once risks are identified, they are dealt • All aspects of the risk management
2. The expected time of occurrence. with by taking measures to reduce their program are formally documented.
3. The magnitude of the negative probability or to reduce their impact. The • Communication and feedback are an
impact that can result from its occur- alternative to risk management is crisis integral part of all risk management
rence. management. It is a reactive and activities.
The seriousness of a risk can be resource-intensive process, with available While your risk management
determined by multiplying the probabili- options constrained or restricted by approach should be tailored to your pro-
events . ject needs, it should incorporate these
Figure 1: Software Engineering Institute’s Risk Effective risk management requires fundamental characteristics. The process
Management Paradigm  establishing and following a rigorous is iterative and should have all the com-
process. It involves the entire project ponents shown in Figure 2. Note that
team, as well as requiring help from out- while planning appears as the first step,
side experts in critical risk areas (e.g., there is a feedback loop from the moni-
ol technology, manufacturing, logistics, toring activity that allows planning and
tif etc.). Because risks will be found in all the other activities to be redone or con-
y areas of the project and will often be trolled by actual results, providing contin-
interrelated, risk management should ual updates to the risk management strat-
include hardware, software, integration egy. In essence, the process is a standard
issues, and the human element . approach to problem solving:
1. Plan or define the problem-solving
Process Description process.
Various paradigms are used by different 2. Define the problem.
organizations to coordinate their risk 3. Work out solutions for those prob-
management activities. A commonly used lems.
Plan approach is shown in Figure 1. While
 4. Track the progress and success of the
there are variations in the different para- solutions.
4 CROSSTALK The Journal of Defense Software Engineering February 2005
Planning Assessment Handling Monitoring
Understanding Risk Management
The following sections expand upon the Risk Documentation
risk management approach. Planning Assessment Handling Monitoring
Risk planning includes developing and
documenting a structured, proactive, and
comprehensive strategy to deal with risk.
Key to this activity is establishing meth- Risk Documentation
ods and procedures to do the following:
1. Establish an organization to take part Figure 2: Risk Management Process Example
in the risk management process.
2. Identify and analyze risks. Condition End users submit requirements changes even though we are in the design
3. Develop risk-handling plans. Consequence
phase and the requirements have been baselined.
Changes could extend system design cycle and reduce available coding time.
4. Monitor or track risk areas. Probability and Impact 80%. $2 million.
5. Assign resources to deal with risks. Mitigation Actions Who, what, and when?
A generic sample risk management
plan can be found in Appendix B of the Table 1: Risk Statement Example
“Risk Management Guide for DoD relationship to other risk areas . determine a level of risk severity. In addi-
Acquisition” . defined, and tion to an overall even though risk in the
Once risks have been End users submit requirements changes method of we arerating,design
and conse- the model also baselined.
probability of occurrence phase and the requirements have beengives good examples of
quences assigned, the risk can be rated as probability levels and types and levels of
Consequence Changes could extend system design cycle and reduce available coding time.
Risk assessment involves two primary
Probability and Impact 80%. $2 million.
its severity. This consequences. The ratings given in the
to Mitigation Actions facilitates prioritizing when?
activities: risk identification and risk Who, what, and
risks and deciding what level of resources assessment guide matrix are suggested
analysis. Risk identification is actually to devote to each risk. Figure 3 depicts an minimum ratings. It may be necessary to
begun early in the planning phase and assessment model using risk probability adjust the moderate and high thresholds
continues throughout the life of the pro- and consequence levels in a matrix to to better coincide with the type of project.
ject. The following methods are often
used to identify possible risks : Figure 3: Defense Acquisition University Assessment Model 
• Evaluations or inputs from project
• Periodic reviews of project data. Level Likelihood Risk Will Happen
• Questionnaires based on taxonomy, a Minimal/Remote
the classification of product areas and b Small/Unlikely
disciplines. c Probable/Likely
• Interviews based on taxonomy. d Large/Highly Likely
• Analysis of the Work Breakdown
e Significant/Near Certainty
• Analysis of historical data.
When identifying a risk it is essential
to do so in a clear and concise statement. RISK IMPACT RATING
It should include three components : ASSESSMENT GUIDE
1. Condition: A sentence or phrase HIGH: Significant impact on cost,
briefly describing the situation or cir-
e schedule, and performance. Significant
action required. High priority
cumstance that may have caused con- d management attention required.
cern, anxiety, or uncertainty. c MODERATE: Some impact.
2. Consequence: A sentence describing
Special action may be required.
b Additional management attention
the key negative outcomes that may a may be needed.
result from the condition. 1 2 3 4 5 LOW: Minimum impact. Normal
3. Context: Additional information
oversight needed to ensure risk
about the risk to ensure others can
understand its nature, especially after
the passage of time. CONSEQUENCE
Table 1 is an example of a risk statement Impact on Other Teams
Level Technical Performance Schedule Cost
The other half of assessment is risk 1 Minimal or No Impact Minimal or No Impact Minimal
analysis. This is the process of examining Acceptable With Some Additional Resources Required
each risk to refine the risk description, 2 Reduction in Margin – Able to Meet Need Dates < 5% Some
isolate the cause, quantify the probability 3
Acceptable With Significant Minor Slip in Key Milestone –
5% - 7%
of occurrence, and determine the nature Reduction in Margin Not Able to meet Need Dates Moderate
and impact of possible effects. The result 4
Acceptable – No
Minor Slip in Key Milestone or
Critical Path Impacted 7% - 10% Major
of this process is a list of risks rated and Cannot Achieve Key Team of
prioritized according to their probability 5 Unacceptable
Major Project Milestone > 10% Unacceptable
of occurrence, severity of impact, and
February 2005 Figure 3: Defense Acquisition University Assessment Model  www.stsc.hill.af.mil 5
Risk Management 3: Defense Acquisition University Assessment Model 
K Are all project positions appropriately
Identify Evaluate Select Implement Mitigation
staffed with qualified, motivated per-
Figure 4: Risk Handling Process K Are the developers trained and expe-
rienced in their respective develop-
• Project metrics to be used for risk ment disciplines (i.e., systems engi-
Risk handling is the process that identi- management.
neering, software engineering, lan-
fies, evaluates, selects, and implements • Identified risks and their descriptions.
Figure 4: Risk Handling Process guage, platform, tools, etc.)?
options for mitigating risks, as shown in • The probability, severity of impact, K Are developers experienced or famil-
Figure 4. Two approaches are used in and prioritization of all known risks. iar with the technology and the devel-
handling risk. The first is to employ • Description of risk handling options opment environment?
options that reduce the risk itself. This selected for implementation. K Are key personnel stable and likely to
usually involves a change in current con- • Project performance assessment remain in their positions throughout
ditions to lessen the probability of occur- results, including deviations from the the project?
rence. The second approach, often baseline plans. K Is project funding stable and secure?
employed where risk probability is high, • Records of all changes to the above K Are all costs associated with the pro-
is to use options that reduce the negative documentation, including newly iden- ject known?
impact to the project if the risk condition tified risks, plan changes, etc. K Are development tools and equip-
should occur. Improving jet engine main- ment used for the project state-of-
tenance and inspection procedures to Risk Management Checklist the-art, dependable, and available in
reduce the risk of in-flight engine failure This checklist is provided to assist you in sufficient quantity, and are the devel-
is an example of the first approach. risk management. If you answer no to opers familiar with the development
Providing a parachute for the pilot, to any of these questions, you should exam- tools?
reduce loss if the risk condition should ine the situation carefully for the possibil- K Are the schedule estimates free of
occur, is an example of the second ity of greater risks to the project. This is unknowns?
approach. only a cursory checklist for such an K Is the schedule realistic to support an
important subject. Please see [5, 6] for acceptable level of risk?
more detailed checklists. K Is the project free of special environ-
Risk monitoring is the process of contin- K Do you have a comprehensive,
mental constraints or requirements?
ually tracking risks and the effectiveness planned, and documented approach K Is your testing approach feasible and
of risk handling options to ensure risk to risk management? appropriate for the components and
conditions do not get out of control. K Are all major areas/disciplines repre- system?
This is done by knowing the baseline risk sented on your risk management K Have acceptance criteria been estab-
management plans, understanding the team? lished for all requirements and agreed
risks and risk handling options, establish- K Is the project manager experienced to by all stakeholders?
ing meaningful metrics, and evaluating with similar projects? K Will there be sufficient equipment to
project performance against the estab- K Do the stakeholders support disci- do adequate integration and testing?
lished metrics, plans, and expected results plined development methods that K Has sufficient time been scheduled
throughout the acquisition process. incorporate adequate planning, for system integration and testing?
Continual monitoring also enables new requirements analysis, design, and K Can software be tested without com-
risks to be identified if they become testing? plex testing or special test equipment?
apparent over time. Monitoring further K Is the project manager dedicated to K Is a single group in one location
reveals the interrelationships between this project, and not dividing his or developing the system?
various risks . her time among other efforts? K Are subcontractors reliable and
The monitoring process provides K Are you implementing a proven proven?
feedback into all other activities to development methodology? K Is all project work being done by
improve the ongoing, iterative risk man- K Are requirements well defined, under- groups over which you have control?
agement process for the current and standable, and stable? K Are development and support teams
future projects. K Do you have an effective require- all collocated at one site?
ments change process in place, and do K Is the project team accustomed to
you use it? working on an effort of this size (nei-
Risk documentation is absolutely essen- K Does your project plan call for track-
ther bigger nor smaller)?
tial for the current, as well as future, pro- ing/tracing requirements through all
jects. It consists of recording, maintain- phases of the project?
ing, and reporting risk management K Are you implementing proven tech-
Project managers recognize and accept
plans, assessments, and handling infor- nology? the fact that risk is inherent in any pro-
mation. It also includes recording the K Are suppliers stable, and do you have ject. The most successful project man-
results of risk management activities, multiple sources for hardware and agers choose to deal proactively with risk.
providing a knowledge base for better equipment? They carefully analyze future project
risk management in later stages of the K Are all procurement items needed for events and past projects to identify
project and in other projects . your development effort short lead- potential risks. Once risks are identified,
Documentation should include – as a time items (no long-lead items)? managers take steps to reduce their prob-
minimum – the following information: K Are all external and internal interfaces ability or reduce the impact associated
• Risk management plans. for the system well defined? with them by establishing and following a
6 CROSSTALK The Journal of Defense Software Engineering February 2005
Understanding Risk Management
rigorous process, which involves the
entire project team as well as outside About the Author
experts. Risk management should include
hardware, software, integration issues, The Software Technology Support
and the human element. A risk manage- Center (STSC) produced the “Guide- Get Your Free Subscription
ment process includes planning, assess- lines for Successful Acquisition and
ment, handling, monitoring, and docu- Management of Software-Intensive Fill out and send us this form.
mentation. Risk is a product of the Systems.” Visit the STSC Web site at
uncertainty of future events and is a part <www.stsc.hill.af.mil/resources/tech_ OO-ALC/MASE
of all activity. Learning to balance its pos- docs> to access all 17 chapters of this 6022 Fir Ave
sible negative consequences with its document. The STSC is dedicated to Bldg 1238
potential benefits is the key to successful
helping the Air Force and other U.S. Hill AFB, UT 84056-5820
government organizations improve their Fax: (801) 777-8069 DSN: 777-8069
capability to buy and build software bet- Phone: (801) 775-5555 DSN: 775-5555
ter. The STSC provides hands-on assis-
1. Software Technology Support Center.
“Life Cycle Software Project Manage- tance in adopting effective technologies
Or request online at www.stsc.hill.af.mil
ment.” Project Initiation. Hill Air for software-intensive systems. The
Force Base, UT, 9 Oct. 2001. STSC helps organizations identify, evalu-
2. Department of Defense. “Risk Man- ate, and adopt technologies that improve
agement Guide for DoD Acqui- software product quality, production RANK/GRADE:___________________________
sition.” Washington, D.C.: DoD Feb. efficiency, and predictability. Technology
2001: Chap. 2 <www.dsmc.dsm.mil/ is used in its broadest sense to include _________________________
pubs/gdbks/risk_manag ement. processes, methods, techniques, and
tools that enhance human capability. The __________________________
3. Higuera, Ron, and Yacov Haimes.
“Software Risk Management.” Pitts- STSC offers consulting services for soft-
burgh, PA: Software Engineering ware process improvement, software ________________________________
Institute, 28 June 1996 <www.sei. technology adoption, and software tech-
cmu.edu/publications/documents/ nology evaluation, including the ________________________________
96.reports/96.tr.012.html>. Capability Maturity Model® Integration,
4. Department of Defense. “Risk Man- software acquisition, project manage- ______________________________
agement Guide for DoD Acqui- ment, risk management, cost and sched-
sition.” Washington, D.C.: DoD, Feb. ule estimation, configuration manage- _____________ _________________
2001: Appendix B <www.dsmc.dsm. ment, software measurement, and more.
5. Arizona State University. “Question
List for Software Risk Identification ______________________________
in the Classroom.” <www.eas.asu.
6022 Fir AVE BLDG 1238
Hill AFB, UT 84056-5820
6. Department of Energy. Risk Assess- Phone: (801) 586-0154
ment Questionnaire. <http://cio. DSN: 586-0154
CHECK BOX(ES) TO REQUEST BACK ISSUES:
doe.gov/sqse/pm_risk.htm>. E-mail: firstname.lastname@example.org
SEPT2003 DEFECT MANAGEMENT
OCT2003 INFORMATION SHARING
NOV2003 DEV. OF REAL-TIME SW
DEC2003 MANAGEMENT BASICS
MAR2004 SW PROCESS IMPROVEMENT
MAY2004 TECH.: PROTECTING AMER.
JUN2004 ASSESSMENT AND CERT.
JULY2004 TOP 5 PROJECTS
AUG 2004 SYSTEMS APPROACH
SEPT2004 SOFTWARE EDGE
OCT2004 PROJECT MANAGEMENT
NOV2004 SOFTWARE TOOLBOX
JAN2005 OPEN SOURCE SW
To Request Back Issues on Topics Not
Listed Above, Please Contact Karen
Rasmussen at <stsc.customerservice@
February 2005 www.stsc.hill.af.mil 7