Chapter-28: Risk Management
•Objectives
– Project Risk
– Proactive Risk Management
– Principles
– Risk identification
– Risk Table
– Summary
Project Risks
What can go wrong?
What is the likelihood?
What will the damage
be?
What can we do about
it?
Project Risk Analysis is a series of
activities to quantify the impact of
uncertainty on a project. These activities
are risk identification, probability
assessment, and impact estimation. Risk
analysis creates the foundation for running
the risk management process throughout
the project lifecycle.
2
Reactive Risk Management
• project team reacts to risks when they
occur
• mitigation—plan for additional resources
in anticipation of fire fighting
• fix on failure—resource are found and
applied when the risk strikes
• crisis management—failure does not
respond to applied resources and project
is in jeopardy
3
Proactive Risk Management
• formal risk analysis is performed
• organization corrects the root causes of
risk
– TQM concepts and statistical SQA
– examining risk sources that lie beyond the
bounds of the software
– developing the skill to manage change
4
Seven Principles
• Maintain a global perspective—view software risks within the context of
system and the business problem
• Take a forward-looking view—think about the risks that may arise in the
future; establish contingency plans
• Encourage open communication—if someone states a potential risk, don’t
discount it.
• Integrate—a consideration of risk must be integrated into the software
process
• Emphasize a continuous process—the team must be vigilant throughout
the software process, modifying identified risks as more information is
known and adding new ones as better insight is achieved.
• Develop a shared product vision—if all stakeholders share the same vision
of the software, it likely that better risk identification and assessment will
occur.
• Encourage teamwork—the talents, skills and knowledge of all stakeholder
should be pooled
5
Risk Management Paradigm
control
track
RISK identify
plan
analyze
6
Risk Identification
• Product size—risks associated with the overall size of the software to
be built or modified.
• Business impact—risks associated with constraints imposed by
management or the marketplace.
• Customer characteristics—risks associated with the sophistication of
the customer and the developer's ability to communicate with the
customer in a timely manner.
• Process definition—risks associated with the degree to which the
software process has been defined and is followed by the development
organization.
• Development environment—risks associated with the availability and
quality of the tools to be used to build the product.
• Technology to be built—risks associated with the complexity of the
system to be built and the "newness" of the technology that is
packaged by the system.
• Staff size and experience—risks associated with the overall technical
and project experience of the software engineers who will do the work.
7
Risk Components
• 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 resultant software will be easy to correct,
adapt, and enhance.
• schedule risk—the degree of uncertainty that
the project schedule will be maintained and
8 that the product will be delivered on time.
Building a Risk Table
Risk Probability Impac RMM
t M
Risk
Mitigation
Monitoring
&
Managemen
t
9
Building the Risk Table
• Estimate the probability of occurrence
• Estimate the impact on the project on a
scale of 1 to 5, where
– 1 = low impact on project success
– 5 = catastrophic impact on project success
• sort the table by probability and impact
10
Example #1
Example #2
Risk Exposure (Impact)
The overall risk exposure, RE, is determined using the
following relationship [Hal98]:
RE = P x C
where
P is the probability of occurrence for a risk, and
C is the cost to the project if the risk occur (i.e loss).
13
Risk Mitigation, Monitoring,
and Management
• mitigation—how can we avoid the risk?
• monitoring—what factors can we track that
will enable us to determine if the risk is
becoming more or less likely?
• management—what contingency plans do we
have if the risk becomes a reality?
14
Summary
• This lecture emphasise on Risk Management.
• Risk identification is the most important part of
the phase Risk Analysis.
• Risk mitigation can be easily done with help of
Risk table
References
1- These slides are designed to accompany Software
Engineering: A Practitioner’s Approach, 7/e (McGraw-Hill
2009). Slides copyright 2009 by Roger Pressman.
2- http://www.cs.unc.edu/~stotts/145/cocomo7.gif
