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

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

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

Risk Impact
Risk components

performance
cost
support
schedule

Risk impact

negligible
marginal
critical
catastrophic

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%

**

Lack of needed specialization increases defects

and reworks

ST

50%

**

Unfamiliar areas of the product take more time

than expected to design and implement

DE

50%

**

Does the environment make use of a database

DE

35%

Components developed separately cannot be

integrated easily, requiring redesign

DE

25%

Development of the wrong software functions

requires redesign and implementation

DE

25%

Development of extra software functions that are

not needed

DE

20%

Strict requirements for compatibility with

existing system require more testing, design, and
implementation than expected

DE

20%

Operation in unfamiliar software environment

causes unforeseen problems

EV

25%

Team members do not work well together

ST

20%

Key personnel are available only part-time

ST

20%

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

CATASTROPHIC

PERFORMANCE

CRITICAL

SUPPORT

COST

SCHEDULE

Failure to meet would result in mission

failure

Failure results in increased costs

and schedule delays with
expected values in excess of
$500K

Significant
degradation to nonachievement of
technical
performance

Significant,
financial
shortages,
budget
overrun likely

Non-responsive
or
unsupportable
software

Unachievable
delivery date

Failure to meet the requirement would

degrade system performance to a point
where mission success is questionable

Failure results in operational

delays and/or increased costs with
expected value of $100K to $500k

Some reduction in
technical
performance

Some
shortage of
financial
resources,
possible
overruns

Minor delays in
software
modifications

Possible
slippage in
delivery date

14

CATEGORY \ COMPONENTS

MARGINAL

NEGLIGIBLE

PERFORMANCE

SUPPORT

COST

SCHEDULE

Failure to meet the requirement would

result in degradation of secondary
mission

Costs, impacts, and/or

recoverable schedule slips with
expected value of $1K to $100K

Minimal to small
reduction in
technical
performance

Sufficient
financial
resources

Failure to meet the requirement would

create inconvenience or nonoperational
impact

Error results in minor cost and/or

schedule impact with expected
value of less than $1K

No reduction in
technical
performance

Possible
budget
underrun

Responsive
software
support

Easily
supportable
software

Realistic,
achievable
schedule

Early
achievable
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