Risk Management

CIS 375
Bruce R. Maxim
UM-Dearborn

1
 What is Risk?
• Risks are potential problems that may affect
successful completion of a software project.
• Risks involve uncertainty and potential
losses.
• Risk analysis and management are intended
to help a software team understand and
manage uncertainty during the development
process.

2
 Risk Strategies
• Reactive strategies
– very common, also known as fire fighting
– project team sets resources aside to deal with
problems
– team does nothing until a risk becomes a problem
• Proactive strategies
– risk management begins long before technical
work starts, risks are identified and prioritized by
importance
– team builds a plan to avoid risks if they can or to
minimize risks if they turn into problems
3
 Software Risks - 1
• Project risks
– threaten the project plan
• Technical risks
– threaten product quality and the timeliness of the
schedule
• Business risks
– threaten the viability of the software to be built
(market risks, strategic risks, management risks,
budget risks)

4
 Software Risks - 2
• Known risks
– predictable from careful evaluation of
current project plan and those extrapolated
from past project experience
• Unknown risks
– some problems will simply occur without
warning

5
 Risk Analysis
• Risk identification
• Risk projection
– impact of risks/likelihood of risk actually
happening
• Risk assessment
– what will change if risk becomes problem
• Risk management

6
 Risk Identification
• Product-specific risks
– the project plan and software statement of scope
are examined to identify any special
characteristics of the product that may threaten
the project plan
• Generic risks
– are potential threats to every software product
• product size
• customer characteristics
• development environment
• technology to be built

7
 Risk Projection
• The risk drivers affecting each risk
component are
– classified according to their impact
category
– potential consequences of each
undetected software fault or unachieved
project outcome are described

8
 Risk Impact
• Risk components
– performance
– cost
– support
– schedule
• Risk impact
– negligible
– marginal
– critical
– catastrophic
9
 Risk Estimation
1. Establish a scale indicating perceived
likelihood of risk occurring
2. Determine consequences.
3. Estimate impact of consequences on
project (for each risk).
4. Note overall accuracy of risk projection
(to avoid misunderstandings).

10
 Risks Category Probability Impact RMMM

Estimated size of project in LOC or FP PS 80% 2 **

Lack of needed specialization increases defects ST 50% 2 **

and reworks

Unfamiliar areas of the product take more time DE 50% 2 **

than expected to design and implement

Does the environment make use of a database DE 35% 3

Components developed separately cannot be DE 25% 3

integrated easily, requiring redesign

Development of the wrong software functions DE 25% 3

requires redesign and implementation

Development of extra software functions that are DE 20% 3

not needed

Strict requirements for compatibility with DE 20% 3

existing system require more testing, design, and
implementation than expected
Operation in unfamiliar software environment EV 25% 4
causes unforeseen problems

Team members do not work well together ST 20% 4

Key personnel are available only part-time ST 20% 4

11
 Risk Table Construction - 1
• List all risks in the first column of the table
• Classify each risk and enter the category
label in column two
• Determine a probability for each risk and
enter it into column three
• Enter the severity of each risk (negligible,
marginal, critical, catastrophic) in column four.

12
 Risk Table Construction - 2
• Sort the table by probability and impact value
• Determine the criteria for deciding where the
sorted table will be divided into the first
priority concerns and the second priority
concerns
• First priority concerns must be managed (a
fifth column can be added to contain a pointer
into the RMMM document)

13
CATEGORY \ COMPONENTS PERFORMANCE SUPPORT COST SCHEDULE

CATASTROPHIC 1 Failure to meet would result in mission Failure results in increased costs
failure and schedule delays with
expected values in excess of
$500K

Significant Non-responsive Significant, Unachievable

2 degradation to non- or financial delivery date
achievement of unsupportable shortages,
technical software budget
performance overrun likely

CRITICAL 1 Failure to meet the requirement would Failure results in operational

degrade system performance to a point delays and/or increased costs
where mission success is questionable with expected value of $100K to
$500k

Some reduction in Minor delays in Some Possible

2 technical software shortage of slippage in
performance modifications financial delivery date
resources,
possible
overruns

14
CATEGORY \ COMPONENTS PERFORMANCE SUPPORT COST SCHEDULE

MARGINAL 1 Failure to meet the requirement would Costs, impacts, and/or

result in degradation of secondary recoverable schedule slips with
mission expected value of $1K to $100K

2 Minimal to small Responsive Sufficient Realistic,

reduction in software financial achievable
technical support resources schedule
performance

NEGLIGIBLE 1 Failure to meet the requirement would Error results in minor cost and/or
create inconvenience or nonoperational schedule impact with expected
impact value of less than $1K

2 No reduction in Easily Possible Early

technical supportable budget achievable
performance software underrun date

15
 Risk Assessment - 1
• Define referent levels for each project risk
that can cause project termination
– performance degradation
– cost overrun
– support difficulty
– schedule slippage
• Attempt to develop a relationship between
each risk triple (risk, probability, impact) and
each of the reference levels.
16
 Risk Assessment - 2
• Predict the set of referent points that
define a region of termination, bounded
by a curve or areas of uncertainty.
• Try to predict how combinations of risks
will affect a referent level

17
Project Termination

18
 Risk Refinement
• Process of restating the risks as a set of
more detailed risks that will be easier to
mitigate, monitor, and manage.
• CTC (condition-transition-consequence)
format may be a good representation for
the detailed risks (e.g. given that
<condition> then there is a concern that
(possibly) <consequence>).
19
 RMMM - 1
• Risk mitigation
– proactive planning for risk avoidance
• Risk monitoring
– assessing whether predicted risks occur or not
– ensuring risk aversion steps are being properly
applied
– collect information for future risk analysis
– determining which risks caused which problems

20
 RMMM - 2
• Risk Management
– contingency planning
– actions to be taken in the event that
mitigation steps have failed and the risk
has become a live problem

21
 Risk Mitigation Example
Risk: loss of key team members
• Determine causes of job turnover.
• Eliminate causes before project starts.
• After project starts, assume turnover is going to occur
and work to ensure continuity.
• Make sure teams are organized and distribute
information widely.
• Define documentation standards and be sure
documents are produced in a timely manner.
• Conduct peer review of all work.
• Define backup staff.
22
 Risk Information Sheets
• Alternative to RMMM plan in which each risk
is documented individually.
• Often risk information sheets (RIS) are
maintained using a database system.
• RIS components
– risk id, date, probability, impact, description
– refinement, mitigation/monitoring
– management/contingency/trigger
– status
– originator, assigned staff member
23
 Safety and Hazards
• Risks are also associated with software
failures that occur in the field after the
development project has ended.
• Computers control many mission critical
applications today (weapons systems, flight
control, industrial processes, etc.).
• Software safety and hazard analysis are
quality assurance activities that are of
particular concern for these types of
applications
24