Risk Management

Shankar Venkatagiri

If you don't actively attack the risks,

they will actively attack you.
Tom Gilb
• Freshly upgraded from Ariane 4
• Same software had been tested for many launches, but on a
lower capacity vehicle
• Video: First launch (upto 2:30)
• Cause: conversion of 64-bit floating point to 16-bit integer
• Video: Ian Somerville explains (upto 4:36)
• Failure of processes of validation (start at 7:55)
• Not everything is lost
• Ariane 5 is the workhorse of the European Space Agency
• Use to carry the James Webb telescope into space

Ariane 5
● Bottomline: Software risks can cause serious damage
● Risks arise mainly due to uncertainty of information,
constrained by capability and cost
● No methodology is watertight
● Waterfall: Close on scope without full knowledge of dangers
● Agile: Can be shaken by late arriving requirements
● The spiral model includes risk management as a
formal step in the execution

Context
● You are a research scientist travelling to a windy cliff to
carry out a survey
– Choice of tents: $130 for a light tent, $350 for a heavy one
– Threats
– High winds? Lose $953 worth of equipment with a light tent
– Or you will lose $48 worth of equipment with a heavy tent
– Low winds? Lose $10 with a heavy tent
– Or lose $15 with a light tent

Courtesy: Head First PMP (2007)

Warm-up
● A risk is anything that changes the outcome of a
project activity
– The outcome needn't always be negative!
– Risk and opportunity go hand in hand
● Unsatisfactory outcome is relative
– Customers & developers: triple constraint
– Users: shortfall in non-functional requirements
– Maintainers: poor code quality
● Video: iPhone 5 maps

Consequence
● Risk information
● Probability of the event, its impact on schedule/cost/…
● Risk profile
● Chronological record of a risk's current and historical risk state
● Project risk profile
● A compendium of individual risk profiles in a project
● Risk action request
● Treatment alternatives and supporting information for one or
more risks determined to be above a risk threshold

IEEE 16085
● Each risk in the risk register must have
– Risk description – short and long
– Category
– Root cause
– Triggers – symptoms
– Potential responses
– Risk owner
– Probability
– Impact
– Status

Attributes
● Projects and companies manage risk in different ways
– Fire-fight – after risks have become problems
– Fix on failure – react during nascent stages
– Mitigate – plan to support, not to eliminate
– Prevent – formal project step to identify risks
–Eliminate root causes – make it impossible for the risks to
exist in the first place (Praxis)
● What risk level is your company at?

Maturity
● Risk exposure – Potential loss/gain from a risk
● RE = Probability (outcome) x Size (outcome)
● At a minimum, the size or impact of risks must be assessed
on a project's scope, cost and schedule
● Keynes – It is better to be roughly right than...?
● Usually, multiple mitigation paths are present
–Sensitivity analysis tells you when a path of action is worth
exploring, and when it is not

Exposure
• You are a PM on a $20 million Moon Rover mission
• Your (rookie) team develops software for the rover
• There is a 0.4 probability of a critical error (CE) in the code,
which will lead to an undesirable outcome (UO)
• You have two options
1. You could train your team to code better
➢ Zero-cost option, P(UO) will fall to 0.1
2. Engage a consultant to perform an independent V & V
➢ Costs $500,000, but P(UO) will fall to 0.04
• Which option will you pick?

Decision
Adapted from Boehm (1991)
What if this is
0.1 instead?

EMV Analysis

Tree Courtesy: Boehm

● You know your product has a showstopper bug
–Fire-fight: Release the product, hold off until your customers
post lots of stinkers on Twitter/Facebook
– Fix-on-failure: React quickly to reports filed by customers
–Mitigate: Begin working on a workaround soon after the
product has been released
– Prevent: Resolve the bug when it is flagged, and only then
release to market
–Eliminate root causes: Review code often, enforce/automate
discipline

Illustration
• Which game would you play?
• Worth the risk?
0.5 Payoff = 50
Play Game 1

0.5 Loss = 10

Decision

0.5 Payoff = 500

Play Game 2

0.5 Loss = 450

Perception
● Risk utility or tolerance is the amount of “satisfaction”
received from a potential payoff
● Figure out your stakeholders' risk appetites – observe
the utility values in the picture
– Risk averse
1 Utility
– Risk neutral
– Risk seeking
¾

0
Potential payoff

Utility
● Bannerman (2008)
– At
the outset of a project, consider classifying the
uncertainties surrounding it

Knowns Unknowns
Known- Issues – Not risks. Risks – Identify
Manage them and mitigate them
Unknown- Buy info from others Unforeseeable –
who know about them iteratively identify

–Include risks from post-implementation reviews of similar

projects within the organisation

Awareness
• Inputs to RM planning
• What are the project's success criteria?
• Short, medium and long term
• What is the triple constraint for the project?
• Are there any standard processes in the firm?
• Is there an avenue for risk training?
• Are there any risk management templates?
• Each assumption is a potential risk – seek clarifications from
the team/client

Inputs
● Document how you are going to handle risks
– How will you assess the risks?
– Which team members are responsible?
– How often will you meet with this team?
● Risk management plan
–Simple to exhaustive action plan for each high priority risk,
depending upon the ceremony
● Solicit inputs & support from the sponsors and the org
if they are not yet clued in

Governance
Courtesy: Boehm
➢ P.L.Bannerman. Risk and risk management in software
projects: A reassessment. J Systems & Software (2008)
➢ Study of 17 state govt. projects in Australia
➢ ‘‘We have limited time & resources to get the system in.
➢ We keep a register because that’s what we’re required to do.
Otherwise we know what we have to do so we get on with it.
➢ We have a feel for areas where problems might arise, and if
they do, we handle them at the time. We don’t spend time
thinking about disasters because they rarely happen.”

Point
● Westerman & Hunter (2007)
“... if IT risk is handled in the right way, as business risk
and capability, business value is created in three ways.
● First, there are fewer fires to fight, and the enterprise can
focus on more productive activities.
● Second, the IT foundation is better structured and less costly,
freeing resources for more productive activities.
●Third, the enterprise can pursue valuable opportunities that
other firms would consider too risky to attempt.”

Counter-point
 Identification

Assessment Analysis

Prioritisation
Risk
Management

● Example checklist of risks in Rapid Development

● Reliability analysis & historical data

● Delphi techniques

Risk Assessment
● Checklists are available
– Different stakeholders rank the same risk differently...
● Arrive at a risk breakdown structure
– Technical risks – hardware, software, network
– PM risks – triple constraint estimates
– Organisational risks – attrition, project priority, support
– Business risks – market, vendors, cash flow

Identification
● Distinguish a risk from an issue (prob = 1)
● Probability is subjective and cultural
– Solicit expert opinion
– Group consensus (Wideband Delphi)
● Quantify risk probability in ranges
– Improbable (0 – 0.3), Probable (0.4 – 0.7), Frequent (0.7 – 1)
● Buy information if needed, and prototype
– Size of loss is less subjective
– Historical data may be available

Analysis
● Calculate a buffer to the schedule and cost
– Calculate expected loss & add to the schedule
– +/- timing on each risk & add when risk arises

Risk Condition Probability Schedule Impact

Inadequate planning 0.4 6

Poor integration management 0.3 4
Lack of post-project review 0.7 3
Poor definition of scope or work packages 0.45 6
Errors in determining the critical path 0.1 2
Poor allocation and management of float 0.15 3

Analysis
● Scenario: Say you know the risk profile for a project
– Consult RiskList.csv
● Optional: Can classify risks by PMBOK knowledge areas

Risk Schedule Cost

Probability
Condition Impact Impact

● Carry out a Monte-Carlo Simulation and determine

the middle-50 percentile range

Simulation
● Agree to estimates as per the middle 50 %iles
– Schedule may stretch by 31-46 weeks
– Cost may expand to $750k - $1.1 million

Distribution
● Risks usually form a Pareto distribution
– Focus on the top few (7-12) based on RE
– Can calculate the expected time savings
● Watch out for synergistic risks!
– Need to bump up their collective importance
● Mitigate risks whose impact can be substantial, even if
the probability of their becoming an issue is low
● Take a leaf out of utility theory

Prioritisation
● Isoquants reflect quartiles

Compare
 ● Information buying, risk transfer,
risk reduction, risk avoidance
● Cost benefit analysis

● Checklist of resolution techniques

● Simulation, prototyping, …

● Top 10 risks

Risk
Management Planning

Control Resolution

Monitoring

Risk Control
● You are a PM with Goli Infomatics
– Mobile apps for the healthcare sector
● Your project team is building an app for telemedicine
doctors to record ailment details and prescriptions
– App will connect them with insurance agency
● Late-arriving requirement
– Ailment classification must be in ICD-10 format
● Misreporting will lead to zero/reduced settlement

Scenario
● Avoid the risk
– De-scope the requirement from current version
– Eliminate its root cause
● Transfer it – pass the task to insurance agent
– Outsource the requirement
● Accept it – have contingency reserves in place
– Publicise the risk as well
● Mitigate it – manage the threat to zero
– How would you?

Resolution
● RQMT: Ailment classification must be in ICD-10 format
● Risk Exposure = Probability x Impact
● Work on Probability

● Code requirement, train doctors & double-check their reports

● Work on Impact
● Negotiate with the insurance agency and get penalty reduced
● Buy information about the risk
● Bring in an insurance consultant
● Undertake prototyping

Actions
 Courtesy: Boehm

Monitoring
Courtesy: IEEE 16085
● Benefits of risk management planning
– Increased confidence in achieving objectives
– More precise estimations (reduced uncertainty)
– Predictable execution
● Drawbacks of projects that manage risk well
– Lot less exciting to work
– No heroics at the boss’ office
– No late-nighters and late-to-early beer & pizzas
– Lessened visibility to senior management!

Outcome
● Distinguish between risk & crisis management
– Crisis mgmt attracts the attention of the entire project team
● A project that is shipped successfully is rarely
commended for its effective risk management
– Organisations tend to downplay formal RM practices
– Post-implementation reviews must highlight the role of RM
in its success
▪ Improve risk checklists, response strategies

Reward
● Robert Charette, IEEE Software (1995)
● Hiding behind the view that what isn’t illegal is not unethical
will not do. As the impact of software broadens and the risks to
the public become more profound, we must learn that ethical
behavior is as important an element of survival as are
aggressiveness, optimism, and intelligence.
● Boehm & DeMarco (1997)
● If a software product fails, the existence of a formal risk plan
that acknowledges the possibility of such a failure could
complicate and even compromise the producer’s legal position.
There is reason to suspect that most risk management
practitioners have adopted a “don’t ask, don’t tell” attitude
toward publication of their successes.

Perspectives
Lyttinen & Robey (1999)
“If we fail to learn from our experiences in
software projects, we will learn to fail...”
● What is a risk-related pitfall of the Waterfall process?
● What is a risk-related pitfall of the Evolutionary process?
● What is risk exposure?
● UO = unsatisfactory outcome. Why is this multi-dimensional?
● What can a PM do with decision trees?
● How would you undertake a sensitivity analysis?
● What are the two important stages of risk management?
● How does a PM monitor risks?
● What does Boehm say about assigning probabilities to risks?
● What's a good way to plot risks?

Boehm on Risk
● What did Eddie tell Kim about her fresh project?
● What was Kim's risk management plan?
● What sort of a contractor was Chip?
● In what way did Eddie's words turn out to be prophetic?
● In what way did Kim perceive her project?
• In Case 5-2, Eddie takes on a new project.
● What was Eddie's RM plan?
● How did the team arrive at a list of project risks?
● How did they analyse the codebase risks?
● How did they handle the documentation risk?
● How did they handle the feature-creep risk?
● How did Bob achieve a 100% speedup of the scientific functions?

Kim & Eddie