Risk assessment

1. Risk Assessment

2. Risk Assessment
Goal:
• being able to prioritize risks according to
their impact and likeness on the project
• Making explicit the information
necessary to define the risk
management strategies (risk
management planning)

3. Techniques
• Two techniques:
– Qualitative risk analysis
• Simpler
• Can be used when no precise information about
probabilities of risk is available
– Quantitative risk analysis
• More systematic
• Suitable for mathematical analysis
• Provide figures on the (economial) impact of risks

4. Qualitative Risk Analysis
A three-step process
• Define probability, impact, and score
• Organize risk
• Highlight significant risks

5. Qualitative Risk Assessment
• Define classes of probabilities and classes of
impact
• Example
– Probability: Very low, low, moderate, high, very
high
– Impact: negligible, low, moderate, severe,
catastrophic
– Risk Score: low, medium, high

6. Qualitative Risk Assessment
… or numeric:
Risk Score = P x I
Very Low 0.1 1
Low 0.3 2
Moderata 0.5 3
High 0.7 4
Very High 0.9 5
Negligible 0.1 1
Low 0.3 2
Moderate 0.5 3
Severe 0.7 4
Catastrophic 0.9 5

7. Risk analysis (i)
Risk Probability Effects
Organisational financial problems force reductions in
the project budge t.
Low Catastrophic
It is impossible to recruit staff with the skill s required
for the project.
High Catastrophic
Key staff are ill at critical times in the project. Moderate Serious
Software components that should be reused contain
defects which limit their func tionality.
Moderate Serious
Changes to requirements that require major design
rework are proposed.
Moderate Serious
The organisation is restructured so that diff erent
manage ment are responsible for the project.
High Serious

8. Risk analysis (ii)
Risk Probability Effects
The database used in the system canno t process as
many transactions per second as expec ted.
Moderate Serious
The time required to deve lop the software is
unde restimated.
High Serious
CASE tools canno t be integrated. High Tolerable
Customers fail to unde rstand the impact of
requirements change s.
Moderate Tolerable
Required training for staff is not available. Moderate Tolerable
The rate of defect repair is underestimated. Moderate Tolerable
The size of the software is unde restimated. High Tolerable
The cod e generated by CASE tools is ineffi cient. Moderate Insignificant

9. Risk Matrix
Negligible Low Moderate Severe Catastrophic
Very High R1 R5
High R2 R6, R7, R8
Moderate R3
Low R4
Very Low R9, R10

10. Risk Matrix
Negligible Low Moderate Severe Catastrophic
Very High R1 R5
High R2 R6, R7, R8
Moderate R3
Low R4
Very Low R9, R10

11. Risk Matrix
Negligible Low Moderate Severe Catastrophic
Very High R1 R5
High R2 R6, R7, R8
Moderate R3
Low R4
Very Low R9, R10

12. Socially constructed risk
Two problems with qualitative risk
• People will believe some things are
risk, even when the statistics
indicate they aren't (and vice
versa). We are "risk illiterate”
• Who says what the probabilities
are? How do we calculate the risk
exposures objectively?

13. Socially Constructed Risk
• When seeking to put people's minds at rest,
qualitative risk assessment may not be
enough
• When assessing risk "objectively", we are in
fact using subjective judgements
… People are emotional!
(and fortunately so)

14. Some examples of real risks
Did you know:
• you should be more frightened of taking a bath than of
walking down a dark alleyway
• you should be more wary of yourself than of flying in a plane
Chances are your death will be by:
• being shot by a stranger...1 in 22,500
• drowning in the bath...1 in 17,500
• plane crash...1 in 800,000
• car accident...1 in 300
• suicide...1 in 160
• accidental fall...1 in 150
• cancer...1 in 4

15. Quantitative Risk Analysis
Similar as qualitative:
• Define probability and impact (in a sense:
which depends on the techniques; how
depends on the domain)
• Use techniques to numerically assess risks
and to visualize data
• Highlight significant risks

16. Quantitative Risk Assessment
• Approach: Expected monetary value analysis. It
computes the expected monetary outcome (according
to different statistical criteria) of a decision/risk
– Technique: Decision tree analysis. Technique that
helps solving the EMV analysis.
• Approach: Modeling. Provide a model of the project.
– Technique: Sensitivity analysis. Helps determining
which risks have the most impact by examining one
variable at a time. (Tornado diagrams)
– Technique: simulation, monte-carlo technique.

17. Decision Theory
S1 S2 S3 S4 S5
D1 C11 C12 C13 C14 c15
D2 C21 …
D3 C31
D4
D5 c55

18. Decision Theory
• Si: states of the system
• Dj: decisions (risks)
• Cij: cost associated to Dj in Si

19. Decision Theory
Choose cost of decision according to different
strategies:
• Minimax, take the decision which has the
maximum minimum gain associated do D
• Average, take the decision which has the
maximum average gain associated
• Max, take the decision which has the
maximum gain associated
… who’s optimistic, who’s pessimistic?

20. EMV
• Decision D has probability pj of
generating gain gj (j = 1..N, SUM(pj) =
1)
• Expected Monetary Value associated to
D is
– EMV(D) = SUMj(pj * gj)
• Take decision with maximum EMV

21. Decision Trees
• A way of computing EMV
• It graphically represents all the possible
outcomes in a tree
• Costs are associated to leaves (and
propagate to nodes)
• Probability are associated to labels

22. Event Trees
“Software Risk Management: Principles and Practices”
[Boehm IEEE Software 1991]

23. Modeling
• Define a model for the decision/project
(some formula describing how inputs
are transformed into outputs)
• “Play” with the formula to understand
the main factors (sensitivity analysis) or
to get a global value

24. Developing a tornado diagram
(100) (50) - 50 100 150 200 250
NPV (Primary Criterion)
15%
6%
100,000
Engineering Budget
Investment
Material Cost
Labor Cost
Market Size
Market Share 10%
120,000
100
150,000
120 60
Uncertainties are
sorted in descending
order of impact
on NPV
Third
Base Value $100 First
Length of bar
indicated impact
on NPV
one variable
at a time
Second

25. Montecarlo Simulation
• Automatically varies input variables
(according to their statistical distribution)
to get a probability distribution of the
outputs

26. Quantitative Risk Assessment:
Outputs
• Probabilistic Analysis of the project:
estimates of the possible schedule and
cost overruns with their probabilities
• Prioritized list of quantified risks:
risks that pose the greatest threat or the
greatest opportunity to the project
• Trends (by repeating the process,
trends may emerge)

27. Risk Response Planning
• Risk Response Planning
– Goal: define the strategies for taking
care/exploit risks

28. Strategies: Menaces
• Avoid.
– Change the plan to eliminate the threat (increase
time, relax objectives, take corrective actions -
increase time to do requirements)
• Transfer.
– Shift the negative outcome to a third party. It
transfers responsibility, it does not eliminate the
risk (insurance, contracts to transfer liability… they
require to pay you a price)
• Mitigate
– Reduce probability or impact (often better than
trying and repare the damage; prototyping)

29. Strategies: Opportunities
• Exploit
– Eliminate uncertainty relate to the occurrence of
the opportunity (e.g. assign more talented people,
provide better quality)
• Share
– Allocate responsibility of exploitation to a third
party (joint-ventures, partnerships, …)
• Enhance
– Modify the size of an opportunity by increasing
probability and/or positive impact

30. Strategy for both Threats and
Opportunities
• Acceptance
– Difficult to deal with all the risks
– May be:
• Passive: just let the team deal with them
• Active: provide some buffer (time, money, …)
• Contingent Response Planning
– Prepare a plan to implement if the risk
occur

31. Risk management strategies
(i)
Risk Strategy
Organisational
financ ial problems
Prepare a briefing document for senior manage ment
showing how th e project is making a very important
contribution to the goals of the business.
Recruitment
problems
Alert customer of potential difficulties and the
possibility of delays, inves tigate buying- in
components.
Staff illness Reorganise team so that there is more overlap of work
and people therefore und erstand each other’s jobs.
Defective
components
Replace potentially defective components withbough t-
in components of known reliabilit y.

32. Risk management strategies
(ii)
Risk Strategy
Requirements
chang es
Derive traceabili ty info rmation to assess requirements
chang e impact, maximi se information hid ing in the
design.
Organisational
restructuring
Prepare a briefing document for senior manage ment
showing how th e project is making a very important
contribution to the goals of the business.
Database
performance
Inves tigate the possibilit yof buying a high er-
performance database.
Unde restimated
development time
Inves tigate buying in components, inve stigate use ofa
program gene rator

33. Risk Response Planning:
Outputs
• Strategies for dealing with the risks
• Triggers (elements used to monitor and
understand whether a risk has
occurred)
• People responsible of monitoring the
risk
• People responsible of applying
contingency plans

34. Risk Monitoring and Control
• Process
– Analyse deviations
– Identify causes
– Evaluate corrective actions
– Modify current plan
• Mind:
– Planned risks dealt with as above
– Unplanned risks require the full process!

35. Risk Management:
Conclusions

36. Risk Management Process

37. Risk homeostasis
People accept a certain degree of risk, regardless
of what you do to reduce it
• Today, life is "safer" than ever before, but mortality rates
remain static (Gerald Wilde, cited in Bryson, 1997)
• Cars with ABS (anti-lock braking systems) no longer attract
insurance discounts because their drivers drive more
recklessly/carelessly
• As we take measures to make our projects more predictable
and safer, we can expect people to ask us to undertake more
risky work

38. It’s amazing – how many
“intelligent” people take this
approach to understanding
uncertainty/risk
Winners in the business world need to Manage uncertainty/risk
© JohnPalmer@DecisionEd.c

39. Risk management Principles
• Global perspective Viewing software development within the context of the larger systems-
level definition, design, and development. Recognizing both the potential value of
opportunity and the potential impact of adverse effects.
• Forward-looking view Thinking toward tomorrow, identifying uncertainties, anticipating
potential outcomes.Managing project resources and activities while anticipating
uncertainties.
• Open communication Encouraging free-flowing information at and between all project
levels.Enabling formal, informal, and impromptu communication. Using processes that value
the individual voice (bringing unique knowledge and insight to identifying and managing
risk).
• Integrated management Making risk management an integral and vital part of project
management. Adapting risk management methods and tools to a project's infrastructure and
culture.
• Continuous process Sustaining constant vigilance. Identifying and managing risks
routinely through all phases of the project's life cycle.
• Shared product vision Mutual product vision based on common purpose, shared
ownership, and collective communication. Focusing on results.
• Teamwork Working cooperatively to achieve common goal. Pooling talents, skills, and
knowledge.

40. Most Common Errors
• Do not identify a maximum risk value.
– Give up a project if too risky
• Do not write a balanced risk management
plan
– Not to big, not to simplicistic
• Misinterpret effects as causes
– Being late with the project
– We may be charged 100.000 euros as a penalty
• Do not apply contingency plans
– Dealing with risk when they occur is more error-
prone than think about the strategies before they
occur

41. Most Common Errors
• Do not involve actors
– Make sure stakeholders understand
consequences of the risk (share the risk);
involved stakeholders in dealing with them
• Do not update the plan
– Helps keeping the contingency plans really
applicable

42. Exercise
• Write the risk management plan for the
digital-divide project
• Write the risk management plan for the
e-procurement project