Introduction
Risk management is a process that is used extensively for
various purposes
Recall earlier questions raised about safety, costs, etc.
According to “Webster’s Seventh New Collegiate Dictionary”,
risk is defined as a:
“possibility of loss or injury”
“the chance of loss or the perils to the subject matter of an
insurance contract” and
“the degree of probability of such loss.” (1)
Chapter 6 – Risk Management 2
Introduction
Risk Strategies
Reactive Proactive
Software team does nothing Begins long before technical
about risks until something work is initiated
goes wrong Identification of potential
“fire fighting mode” risks (studies of probability,
impact and priorities)
Objective: AVOID RISK
At best, monitors the Responds are in a controlled
projects for likely risks and effective manner
Chapter 6 – Risk Management
Our Concern
5
Introduction
• Project Risks (budgetary, schedule, personnel, resource, customer)
• Technical Risks (design, implementation, interfacing, verification)
• Business Risks (market, strategic, management,budget)
Software
Risk Charette: (2)
• Known risks
• Predictable
•
Unpredictable
Chapter 6 – Risk Management 6
Risk Identification
Risk identification is a systematic attempt to specify threats to
the project plan
Identify known and predictable risks
Generic Product-specific
Product size
Business impact
Customer characteristics What characteristics of
this product may threaten
Process definition our project plan?
Development environment
Technology to be built
Risk Item List Staff size and experience
Chapter 6 – Risk Management 7
Risk Identification
Product Size Risk :
Estimated size of the product in LOC or FP?
Percentage deviation in size of product from average for
previous products?
Number of users/projected changes to the requirements for
the product?
Amount of reused software?
Business Impact risks:
Effect of this product on the company revenue?
Visibility of this product to senior management?
Amount & quality of product documentation to be produced?
Governmental constraints on the construction of the product?
Chapter 6 – Risk Management 8
Risk Identification
Customer related risks: (needs, personalities, contradictions ,
associations)
Have you worked with the customer in the past?
Does the customer have a solid idea of what is required?
Will the customer agree to have meetings?
Is the customer technically sophisticated in the product area?
Does the customer understand the software process?
Technology Risks:
Is the technology to be built new to your organization?
Does the SW interface with new or unproven HW/SW?
Do requirements demand creation of new components ?
Do requirements impose excessive performance constraints ?
Chapter 6 – Risk Management 9
Risk Identification
Process Risks : (4)
Does senior management support a written policy statement that
emphasizes a standard process for software development ?
Is there a written description of the software process to be used?
Process Is the software process used for other projects ?
Issues:
Is configuration management used to maintain consistency among
system/software requirements, design, code and test?
Is a procedure followed for tracking subcontractor performance?
Are facilitated application specification techniques used to aid in
communication between the customer and developer ?
Tech- Are specific methods used for software analysis?
nical Do you use specific method for data and architectural design?
Issues:
Are software tools used to support the software analysis and design?
Are tools used to create software prototypes?
Are quality/productivity metrics collected for all software projects?
Chapter 6 – Risk Management 10
Risk Identification
Development Environment Risks:
Is a software project/process management tool available?
Are tools for analysis and design available??
Are testing tools available and appropriate for the product?
Are all SW tools integrated with one another?
Have members of the project team received training in
each of the tools?
Risk Associated with Staff Size and Experience:
Are the best people available?
Do the people have the right combination of skills?
Are staff committed for entire duration of the project?
Do staff have the right expectations about the job at hand?
Will turnover among staff be low enough to allow continuity?
Chapter 6 – Risk Management 11
Risk Identification
Risk Components and Drivers (U.S. Air Force guidelines)
Performance risk: the degree of uncertainty that the product
will meet its requirements and be fit for its intended use
Cost risk: the degree of uncertainty that the project budget will be
maintained
Support risk:the degree of uncertainty that the software
will be easy to correct, adapt, and enhance
Schedule risk: the degree of uncertainty that the project schedule
will be maintained
Chapter 6 – Risk Management 12
Risk Projection
Also called risk estimation, attempts to rate each risk in two
ways:
Likelihood (probability)
Consequences
Develop a risk table: A risk table provides a project manager with a simple
technique for risk projection
For each identified risk, list likelihood, consequence and impact
Risk Assessment: Examine the accuracy of the estimates
that were made during risk projection. A risk referent level
must be defined and the referent point or break point
should be established
Chapter 6 – Risk Management 14
Risk Projection
Risks Category Probability Impact RMMM
Size estimate may be significantly low PS 60% 2
Larger number of users than planned PS 30% 3
Less reuse than planned PS 70% 2
End users resist system BU 40% 3
Delivery deadline will be tightened BU 50% 2
Funding will be lost CU 40% 1
Customer will change requirements PS 80% 2
Technology will not meet expectations TE 30% 1
Lack of training on tools DE 80% 2
Staff inexperienced ST 30% 2
Staff turnover will be high 60%
. ST 2
.
.
Chapter 6 – Risk Management 15
Risk Matrix
L 5
I
k
4
e
l
I 3
h
o 2
o
d 1
1 2 3 4 5
Consequences
Chapter 6 – Risk Management 16
Risk Mitigation, Monitoring, and
Management
An effective strategy must consider three issues:
risk avoidance,
risk monitoring, and
risk management and contingency planning.
A proactive approach to risk avoidance is the best strategy.
Develop a plan for risk mitigation. For example: assume that high
staff turnover is noted as a project risk r 1, some of the possible
steps to be taken are these:
meet with current staff to determine causes for turnover
assume turnover will occur and develop techniques to ensure
continuity when people leave.
define a backup staff member for every critical technologies.
Chapter 6 – Risk Management 17
Risk Mitigation, Monitoring, and
Management
As the project proceeds, the following factors can be
monitored:
general attitude of team members based on project
pressures,
the degree to which the team has jelled,
interpersonal relationship among team members,
availability of jobs within the company and outside it
In addition of these factors, the project manager should monitor the
effectiveness of risk mitigation steps.
Risk management and contingency planning assumes that
mitigation efforts have failed and that the risk has become reality.
Chapter 6 – Risk Management 18
Safety Risks and Hazards
Software safety and hazard analysis are software quality
assurance activities that focus on the identification and
assessment of potential hazard that may impact software
negatively and cause an entire system to fail.
If hazards can be identified early in the software engineering
process, software design features can be specified that will
either eliminate or control potential hazards.
Chapter 6 – Risk Management 19
SEI Software Development Risk
Chapter 6 – Risk Management 23
Summary
Risk analysis is an important part of most software projects.
Risk analysis requires a significant amount of project
planning effort.
Understanding risk helps you know where to commit your
resources.
If you don’t actively attack the risks, they will actively
attack you.
Major projects should all have a risk management plan..
Chapter 6 – Risk Management 25
