RISK MANAGEMENT IN SOFTWARE
ENGINEERING
Risks
 All projects have some degree of risk
 Risks are issues that can cause problems
 Delay in schedule
 Increased project costs
 Technical risk example
1. We intend to use Web services, but no team
member has experience with them
2. The team may not have the required Java skills to
execute the job on time because several have not
used Java in a business environment
What is Risk Management?
 The total process to identify, control, and
minimize the impact of uncertain events.
 In IT, the focus is on availability, reliability,
maintainability & security
 In SE, the focus is on quality & productivity
 One time, on budget & works
 Realistic expectations
 Try to confront risks early in the process rather
than waiting for them to confront us when
building the application
Risk Management
 Usually performed
1. at the start of a project,
2. at the beginning of major project phases (such as
requirements, design, coding and deployment),
and
3. when there are significant changes (for example,
feature changes, target platform changes and
technology changes).
Other Processes
4
Risk Analysis Methods
1. Identify potential sources of risk

Imagine all wost-case scenarios
2. Analyze each risk

Understand its potential impact on the project
3. Prioritize risks

Focus on the most serious
4. Mitigation strategies


Conquer it (investigate & take action)
Avoid it (change plans so the issue doesn’t occur
5. Develop a plan to retire the risk
6. Review your risk management plan periodically



Progress on plan?
Change to the risk?
New risks?
Identification
 How are risks to the project’s success
identified ?
 Can be tricky
 Requires imagination – looking at parts of the
process that at first glance do not seem risky
 Brainstorming
Brainstorming
 Have a brainstorming session, consider :
 Weak areas, such as unknown technology.
 Aspects that are critical to project success, such as
the timely delivery of a vendor's database
software, creation of translators or a user
interface that meets the customer's needs.
 Problems that have plagued past projects, such as
loss of key staff, missed deadlines or error-prone
software
Other Processes
7
Expressing Risks
 Need to describe in as much detail as possible
 Vague: “Team member may get sick”
 Better: “Sick time will exceed the company norm
by 50% due to high number of young parents on
team”
Mitigation
 Do you conquer the risk?
 Take an action
 Fire young parent employees?
 Or avoid the risk?
 Change a plan
 Budget more time in the schedule?
Mitigating Risk by planning
 The team should develop a plan to address each
risk
 Assign an individual to carry out the plan
 Make plans concrete
 Vague: “we will all learn Java”
 Concrete: “Tom & Sue will pass level 2 Java Certification
by Dec. 4th by attending SuperJava Course”
 Avoidance: “Use C++ instead of Java”
Prioritizing Risks
 Create a table of identified risks and prioritize
 What is the estimated likelihood that the risk will
occur?
 L: 1-10 with 1 lowest likelihood
 What is the estimated impact of the risk?
 I:1-10 with 1 lowest impact
 What is the estimated cost of managing it?
 M:1-10 with 1 lowest cost
 Priority number
 (11-L)*(11-1)*M
 Retirement plan
 Responsible person
 Target completion date
Risk prioritization
 Describe the risks fully
 Priority depends on factors such as likelihood and
seriousness of impact on project
 A high priority task has a low priority number
because people usually refer to their “highest
priority” as number 1
 The more expensive it is to deal with a risk, the lower
its priority
 If it’s a lot of work, may be better off not working on it in
advance
 Construct an expensive simulation? Or deal with it when it
arises?
 Sometimes have to just accept the risk
Target
Completion
Responsible
Person
etirement Plan
Priority #
Management
Cost
Impact
Likelihood
Title
#
1
Lack of Java
skills (see
note 1)
8
9
9
3*2*
9 = 54
See
note 3
Jared
Oct 15.
2
Web
services
immature
(see note 2)
3
7
2
8*4*
2 = 64
See
note 4
Jen
Aug 3.
Note 1: The risk is that the team does not have enough skills in Java to handle the programming
required by this project in the time allowed
Note 2: The risk is that although a Web Service technology is a good choice, it is a new technology
and its immaturity may create difficulties
Note 3: Jen, Oscar, and Alf will all pass their level 2 Java cert by X date by taking Y course
Note 4: Jen will install 3 Web services typical of DVD inventory management and run 1,000
typical transactions against these, gathering timing data
Just deal with it?
 Not every risk can be dealt with earlier than its
natural occurrence.
 Suppose the team has a week to add significant
functionality to the app
 Goal: add the capability to show future investment
growth graphically for a financial app
 Little to gain from performing risk analysis and
retirement in this case
 With such short lead time, the resource of work time is
better spent just getting to it
 The chance that it won’t get done exists, but the time
required for risk analysis my not leave enough time to
do the job
Risk Review
 review your risks periodically,
 check how well mitigation is progressing.
 change risk priorities, as required
 Identify new risks.
 rerun the complete risk process if the project
has experienced significant changes.
 incorporate risk review into other regularly
scheduled project reviews
Other Processes
15
In your projects
 Risk management should be part of your
discussions in your weekly meetings
 Identify & mitigate (where possible)