Risk Management

Lecture 8
Risk Management Topics
◼ Risk Management
 Principles
 Process
 Indicators

◼ References
 MCSD Self-Paced Training Kit: Analysing Requirements and
Defining Microsoft .NET Solution Architectures, Microsoft Press
 Managing Iterative Software Development Projects, Kurt Bittner,
Ian Spence, Addison Wesley 2006
 RUP
 Righting Software by Juval Löwy, 2020 Pearson Education
(Chapter 10)
2
Primary SDP themes
◼ Getting the design right by focusing on
architecture first
◼ Managing risk through iterative development
◼ Reducing complexity by using components and
services
◼ Making software progress and quality tangible
through instrumented change management
◼ Automating the overhead and bookkeeping by
using automation and round-trip engineering
tools

3
Risk Management
◼ Risk Management begins with Risk
Awareness

◼ Examples
 Sickness of a skilled resource
 Delivery fail of a supplier
 Poor performance of a deliverable

4
Risk Management Process
◼ Risk Identification
◼ Risk Assessment
◼ Risk Evaluation
◼ Risk Management

5
Risk Management Process
(MSDN)

6
Risk Identification [1]
◼ Risk Identification determines which risks
might affect the project and documents
their characteristics
◼ Participants in risk identification activities
can include the following :
 Project manager
 Project team members
 Risk management team
 Customers
 End users 7
Risk Identification [2]
◼ Risk Identification is an iterative process

◼ New risks may become known as the

project progresses through its life cycle

8
Risk Identification [3]
◼ Identify activities that may be affected by
unexpected events
◼ Risks can be identified in a number of
ways
 General Risks – can happen to any task,
resource or project
 Risk specific to the project
 Risks applicable to one task
 Resource specific risks
9
Risk Identification [4]
◼ Review the project with experienced
people
 Refer to previous projects files and archives
 Brainstorm likely events that may occur in
your project
 Perform SWOT analysis (Strength,
Weaknesses, Opportunities, Threats)

10
Types of risks (from RUP)
◼ Resource Risks
◼ Business Risks
◼ Technical Risks
◼ Schedule Risks

11
Resource Risks (1)
◼ Organization
 Is there sufficient commitment to this project
(including management, testers, QA, and
other external but involved parties)?
 Is this the largest project this organization has
ever attempted?
 Is there a well-defined process for software
engineering?

12
Resource Risks (2)
◼ Funding
 Isthe funding in place to complete project?
 Has funding been allocated for training and
mentoring?
 Are there budget limitations such that the
system must be delivered at a fixed cost or be
subject to cancellation?
 Are cost estimates accurate?

13
Resource Risks (3)
◼ People
 Are enough people available?
 Do they have appropriate skills and experience?
 Have they worked together before?
 Do they believe the project can succeed?
 Are user representatives available for reviews?
 Are domain experts available?

14
Resource Risks (4)
◼ Time
 Is the schedule realistic?
 Can functionality be scope-managed to meet
schedules?
 How critical is the delivery date?
 Is there time to "do it right"?

15
Business Risks
◼ What if a competitor reaches the market first?

◼ What if project funding is jeopardized (the other

way to look at this is to ask "what can assure
adequate funding")?

◼ Is the projected value of the system greater than

the projected cost?

◼ What if contracts cannot be made with key

suppliers?
16
Technical Risks (1)
◼ Scope risks
 Can success be measured?
 Is there agreement on how to measure success?
 Are the requirements fairly stable and well
understood?
 Is the project scope firm or does the scope keep
expanding?
 Are the project development time scales short
and inflexible?
17
Technical Risks (2)
◼ Technological risks
 Has the technology been proven?
 Are reuse objectives reasonable?
◼ An artifact must be used once before it can be re-used.
◼ It may take several releases of a component before it is stable enough to reuse without
significant changes.
 Are the transaction volumes in the requirements reasonable?
 Are the transaction rate estimates credible? Are they too optimistic?
 Are the data volumes reasonable? Can they be held on currently available mainframes, or, if
the requirements lead you to believe a workstation or departmental system will be part of the
design, can the data reasonably be held there?
 Are there unusual or challenging technical requirements that require the project team to
tackle problems with which they are unfamiliar?
 Is success dependent on new or untried products, services or technologies, new or unproven
hardware, software, or techniques?
 Are there external dependencies on interfaces to other systems, including those outside the
enterprise? Do the required interfaces exist or must they be created?
 Are there availability and security requirements which are extremely inflexible (for example,
"the system must never fail")?
 Are the users of the system inexperienced with the type of system being developed?
 Is there increased risk due to the size or complexity of the application or the newness of the
technology?
 Is there a requirement for national language support?
 Is it possible to design, implement, and run this system? Some systems are just too huge or
complex to ever work properly.
18
Technical Risks (3)
◼ External dependency risk
 Does the project depend on other (parallel)
development projects?
 Is success dependent on off the shelf products
or externally-developed components?
 Is success dependent on the successful
integration of development tools (design tools,
compilers, etc.), implementation technologies
(operating systems, databases, inter-process
communication mechanisms etc.). Do you have
a back-up plan for delivering the project
without these technologies?
19
Checklist [1]
◼ Key member of staff on critical path
◼ Key skill on long-duration task
◼ Project Manager on critical path
◼ External dependencies without tight
contract
◼ Reliance on leading-edge technologies
◼ Many internal dependencies with
conflicting priorities
20
Checklist [2]
◼ Ramping up resources
◼ Assumptions about availability of people
and equipment
◼ Resource absences (Vacation time)
◼ Site shutdown for maintenance
◼ Health and safety requirements and
certifications

21
Checklist [3]
◼ Risks that translate to project slippage
◼ Near critical path that could become critical
◼ Slack for non critical path
◼ Risks on critical path that translate to
slippage

22
Risk Identification Output
◼ The outputs from Risk Identification are
typically contained in a document that can
be called a risk register and contains :
 List of identified risks
 Likely consequences
 List of potential responses
 Root causes of risk
 Updated risk categories

23
Risk Register

24
25
Risk Assessment
◼ Identify Probability and Impact of each risk
◼ Key question: what event will have an
influence on the project?
◼ Probability: How likely is it to happen?
◼ Impact: What will be the consequences?

26
Qualitative Risk Assessment
◼ includes methods for prioritizing the
identified risks for further action, such as :
 Quantitative
Risk Analysis
 Risk Response Planning

◼ determines the priority of identified risks =

f(probability, impact)

27
Qualitative Assessment Tools

◼ Probability and Impact Matrix

 Ratingsare assigned to risks based on their
assessed probability and impact

 Probability and impact matrix => rating the

risks as low, moderate, or high priority

28
Risk matrix example
Impact Low Medium High Critical
area

Cost Insignificant <5% <10% >10%

Time Insignificant <10 days <25 days >25 days

Scope Insignificant No Some Definite

business business business
impact impact impact
Quality Insignificant No Potential Definite
anticipated for problems
problems problems

29
Example – Inadequate training
Impact Low Medium High Critical
area

Cost Insignificant <5% 6 <10% >10%

Time Insignificant <10 days <25 days >25 days 27

Scope Insignificant 5 No Some Definite

business business business
impact impact impact
Quality Insignificant No Potential 14 Definite
anticipated for problems
problems problems

6+27+5+14 = 52 => Medium impact 30

Evaluation example
◼ Critical > 70
◼ Medium > 50
◼ Low < 50

31
Risk Exposure

32
Quantitative Risk Assessment
[1]
◼ Is performed on risks that have been
prioritized as High-Risks by the Qualitative
Risk Analysis process

◼ Analyzes the effect of those risk events

and assigns a numerical rating to those
risks
33
Quantitative Risk Assessment
[2]
◼ Uses techniques such as Monte Carlo
simulation and decision tree analysis to:
 Quantify the possible outcomes for the project
and their probabilities
 Identify risks requiring the most attention by
quantifying their relative contribution to overall
project risk

34
 200.000+35/100*120.000
Exercise = 242.000

◼ Prototyping is worthwhile on the project?

70/100*450.000 =
315.000
35
Another exercise
4000$*10/100 + 0$*90/100 +
900$ = 1300 $

4000$*30/100 + 0$*70/100 +
300$ = 1500 $

36
Risk Evaluation [1]
◼ Risks can be placed on a graph according
to probability and impact
◼ Decide the zone on the graph that contains
unacceptable risks:
 Depends on organization
 Depends on domain
 Depends on project

37
Risk Evaluation [2]
◼ To move each risk out of that zone:
 Reduce the probability and/or
 Reduce the impact
=> Reduce exposure
◼ These actions are recorded in the risk
register:
 Mitigation(what will be done to prevent?)
 Triggers (when will it be done?)
 Responsible (who will do it?) 38
Risk Management Chart

39
Another Example

 High Risk : dark gray (largest numbers)

 Moderate risk : light gray (in-between numbers)
 Low risk : medium gray (smallest numbers)
40
Risk Metrics
◼ Measurements
 EP - Total Project Exposure
 Ei – Exposure for Risk i
 Ii – Impact for Risk i
 Pi – Probability for Risk i

41
Risk Metrics Trend
◼ Risk Exposure Metric (should → 0)
n n
EP =  Ei =  Pi *I i
i =1 i =1

◼ Risk Exposure Metric Trend (should <0)

dE p
EP =
dt
42
Activity risk modeling and
quantification

43
From Righting Software by Juval Löwy (9780136524038) Copyright © 2020 Pearson Education, Inc. All rights reserved
Activity classification
◼ How do we decide the color of an activity?
◼ Thresholds
◼ Ex.
 Float>25=> green
 15<Float<=25 => yellow
 0<Float<=15 =>red

44
From Righting Software by Juval Löwy (9780136524038) Copyright © 2020 Pearson Education, Inc. All rights reserved
Criticality Risk model
Risk = (WC* NC+ WG* NG+ WY* NY+ WR* NR)/
WC*N
where
WC,G,Y,R – weight of critical/green/yellow/red
activities
NC,G,Y,R – number of critical/green/yellow/red
activities
N = NC+NG+NY+NR (total number of activities)
45
From Righting Software by Juval Löwy (9780136524038) Copyright © 2020 Pearson Education, Inc. All rights reserved
Example

WC = 4, WR = 3, WY = 2, WG = 1
Risk = (4*6+3*4+2*3+1*4)/4*17 =
46
From Righting Software by Juval Löwy (9780136524038) Copyright © 2020 Pearson Education, Inc. All rights reserved
What happens if
◼ All activities in the network are critical?
 Risk = 4*N/4*N = 1 (maximum!)

◼ All activities in the network are green?

 Risk = WG/WC (impossible!)

47
From Righting Software by Juval Löwy (9780136524038) Copyright © 2020 Pearson Education, Inc. All rights reserved
What are appropriate weights?
◼ 1, 2, 3, 4
◼ 21, 22, 23, 24?
Hint: minimum risk = WG/WC = 21/24 ~ 0.875
(too high!)

48
From Righting Software by Juval Löwy (9780136524038) Copyright © 2020 Pearson Education, Inc. All rights reserved
What are appropriate weights?
◼ Good practice: Fibonacci series
 Fibi = Fibi-1+ Fibi-2
 Fibi = φ* Fibi-1, for large i
 φ = 1.618…(golden ratio)

◼ WY = φ* WG, WR = φ2* WG, WC = φ3* WG

Risk = (φ3 NC + φ2 NR+φ NY+NG)/φ3 N

49
From Righting Software by Juval Löwy (9780136524038) Copyright © 2020 Pearson Education, Inc. All rights reserved
Activity risk model
◼ Instead of weights, use floats

Risk = 1 – (F1+ F2 +…+ FN)/M*N where

◼ Fi = float of activity i
◼ M = Max(F1, F2, … FN)
◼ N = number of activities

50
From Righting Software by Juval Löwy (9780136524038) Copyright © 2020 Pearson Education, Inc. All rights reserved
Risk and direct cost models
• Keep risk btw 0.3 and 0.75
• Decompress to 0.5
• Keep normal solutions < 0.7

51
From Righting Software by Juval Löwy (9780136524038) Copyright © 2020 Pearson Education, Inc. All rights reserved
Risk Response Strategies (for
threats)

◼ Avoidance
◼ Reduction (Mitigate)
◼ Transfer
◼ Acceptance => consider contingency
plans!!!

52
Risk Response Strategies (for
opportunities)

◼ Exploit (opposite to Avoidance)

◼ Enhance (opposite to Reduce)
◼ Share (opposite to Transfer)
◼ Acceptance

53
 Exercise
Description Strategy
Remove a work package from the project Avoid
Assign a team member to visit the suppliers’ facility Mitigate impact
Move a work package to a date when a more experienced Exploit
resource is available
Begin negotiation for an equipment early to insure a better Enhance impact
price
Notify management that there could be a cost increase due to Accept
a risk because no action was taken to
Provide a team member having limited experience with Mitigate probability
additional training
Outsource difficult work to a more experienced company Transfer
Prototype a risky piece of equipment Mitigate probability

54
Ask the client to handle some of the work Transfer
Risk Assessment Document
◼ Risk statements, which capture the nature of each risk
◼ Risk probability, which describes the likelihood of the
occurrence of the risk
◼ Risk severity, which specifies the impact of the risk
◼ Risk exposure, which specifies the overall threat of the
risk
◼ Mitigation plans, which describe the efforts for
preventing or minimizing the risk
◼ Contingency plans and triggers, which specify the
steps that you need to take when a risk occurs and when
to take those steps
◼ Risk ownership, which specifies the name of the team
member who is responsible for monitoring the risk on a
regular basis
55
Risk Management Tool
◼ Risk Template Tool

56
Risk indicators
◼ Total impact of top ten risks
◼ Top ten risks mitigation costs
◼ Top ten risk variation
◼ Top ten risks impact variation

57
Risk management key points
◼ Iterative development enables improved
risk management
◼ Risks should be monitored
 Continuously
 Proactively
◼ Risk management should be planned and
the effort for it estimated (if the effort
exceeds the risk, it is not risk)

58
Risk management in Agile
◼ Has the adoption of Agile techniques
magically erased risk from software
projects?

◼ Can Agile and lean techniques be leveraged

to make managing risk part of the day-to-
day activities of teams while reducing
overhead?
59
Recognition: Risk In Agile Is
Different
“A great deal of explicit risk management
becomes unnecessary when a project uses
an agile approach”

Mike Cohn, Mountain Goat Software

60
Approach

61
 Agile risk management
◼ Identify knowable risks when generating the
initial backlog.
◼ Build mitigation for common risks into the
definition of done.
◼ Generate stories for less common risks and
add them to the projects backlog.
◼ Review risks when grooming stories
◼ Carve out time during planning to identify
emerging risks
62
 Risk recognition
◼ Carve out time when you are developing the backlog
and ask as diverse a group possible to identify the
potential problems.
◼ Form a small team to interview stakeholders that were
not part of the planning exercise.
◼ Gather risk data though surveys when the program
stakeholders are geographically diverse.
◼ Interview customers or potential customers.
◼ Periodically discuss risks either as an agenda item or as
a follow-on to standard meetings.

63
Risk identification in DAD

64
Risk management in DAD

65
Measuring Risk

66
Lessons learned
◼ Risk management become a series of
conversations not a series of documents.
◼ Each build is assessed, issues identified
and the backlog of tasks is reviewed and
prioritized and the most important tasks,
issues and risk mitigation are scheduled
for the next sprint.

67
Discussion topic for next time
◼ Considering a project of your choice, give
an example of a specific risk of the project,
possible specific responses (and their
type). Simulate a quantitative analysis.

68
Quiz time
◼ Please switch over to Moodle

69