Software Risk Management

(Slides by Omar Garcia)

2

Definitions

• What is Risk Management?– “There is only one risk: the project might fail…and

we’re managing that by working like hell to assure it doesn’t happen.”

• “Everyone does risk management.”• Why does it matter?

– Building software is risky business

– Ignoring risks is a no-win situation

– With risk comes opportunity

Agenda

• Motivation

• What is risk about

• Risk Management Process

• Risk Taxonomy

• Your Project

• Summary

4

Some Definitions

• Risk - A possibility of loss; or any characteristic, object or action that is associated with that possibility

• Risk is associated with– Probability - there is uncertainty– Loss - some harm, damage or consequence to

goals or expectations, or stakeholder• The transition of the risk is the moment of occurrence

5

Risk Management

• A systematic and explicit approach used to identify, analyze, evaluate, plan, control and monitor risks

• A formal process for dealing with risks before the transitions occur

• Component activities include– Exposure analysis– Contingency planning– Transition monitoring

6

A Graphic Definition

Cost to Solve

PracticalOptions

Risk Management

Crisis Management

Time

7

Risk Management

Identify New Risks

Evaluate Risks

Classify Risks

Prioritize Risks

Plan RiskMitigation

Track Risksand Status

Mitigation plans

Review Risksand Adjust

Mitigation plans

Risk &MitigationPlan DB

1. Identify Risks

• Use postmortem analysis and industry data to classify each project-specific risk

• “Yesterday’s problem is today’s risk” - Tom DeMarco

• Traditional folklore• Analogies to well known cases• Common sense• Experimental results• Epidemiological survey

9

Risk Activities

• Risk Identification– Use postmortem analysis and industry data to

classify each project-specific risk– “Yesterday’s problem is today’s risk” - Tom

DeMarco

• Risk estimation and evaluation– Risk exposure = consequence * probability– A problem is a risk whose likelihood has

reached 100%

Boehm’s spiral model

Risk analysis

Risk analysis

Risk analysis

Risk analysis

Prototypes

1 2 3 Opera-tional

Simulations, Models, Benchmarks Concept

Requirements

Design

Test

Code

Review

Requirement/ Lifecycle plan

Development plan

Integration & test plan

Determine objectives, alternatives and constraints

Evaluate alternatives, identify, resolve risks

Plan next phase Develop, verify next-level product

2. Evaluate Risks

• Estimate likelihood of the risk occurring– Sometimes pseudo-mathematical Risk exposure = risk likelihood * impact

– Usually based on judgment and experience

• Estimate the consequences of the risk– Negligible, marginal, critical, catastrophic– Determine impact on cost, performance, schedule and

support

• Determine the overall risk to the project– Use a “risk matrix”

Risk Analysis

<10% = very low10-25% = low 25-50% = moderate50-75% = high>75% = very high

Effectsinsignificanttolerable seriouscatastrophic

Probability

What are acceptable risk levels?• Cost less than company turnover / 10?

• Cost less than the predicted insurance payout?

• Probability of loss of life > 10-3 p.a.?

• Road deaths in NSW 1.3 x 10 –4

• Commercial Aircraft probability per flight = 3 x 10 –6

• Who should determine these?

Risk Matrix

Very high high medium low very lowCatastrophic high high moderate moderate low

Critical high high moderate low none

Marginal moderate moderate low none none

Negligible moderate low low none none

Probability

Imp

act

Prioritise risksSelect the highest impact risks

15

5. Plan Risk Mitigation

For each major risk– Identify alternatives for reducing risk– Associate plan for risk reduction – Establish risk thresholds curves– Establish a contingency plan and fund– Identify a trigger for the contingency plan

• May also establish a system risk level

16

6. Typical Information to Record

• Basic– Description, date identified– Responsible person

• Status and history of events contributing to reduction or elimination of risk, or re-assessment of risk

17

7. Risk tracking and controlling

• Periodically re-evaluate risk parameters• Be proactive in identifying new risk• Frequently status progress of mitigation

plans relative to existing thresholds• Be willing to adjust or replan if actual

progress does not match expected progress• Follow up on risk resolution and closure

18

Risk Barriers

• Deficient management infrastructure – Managing the top-ten problems rather than

looking to the future to determine the risks they are facing

• Doing anything sensible about risks costs money

• Risk identification can make you look like a whiner

19

Principles for Effective Risk Management

• Global and Integrated Mgt. Perspective– Recognize potential value of opportunity and

potential impact of adverse effects– Risk management is vital to project mgt.

• Forward-looking view and rear-view– Managing project resources and activities while

anticipating uncertainties and potential outcomes, using from past successes and failures.

Identify Risks (your project)

– Considers risk affecting the following• Requirements

• Design

• Code and Unit Test

• Integration and Test

• Communication

• Team Compatibility and Motivation

• Resources availability

Risk Factors (Checklist Approach)• Organisation• Estimation• Monitoring• Development methodology• Tools• Risk culture• Usability• Correctness• Reliability• Personnel

Organisation risks

• Will you use experienced software managers?

• Have you produced similar software before?• Do you have a documented organisational

structure clearly delineating lines of communication?

• Are software configuration management functions being performed?

Estimation

• What estimation method is used?• Is the cost estimate based on past software project

metrics?• Are schedule estimates based on schedules from

past projects?• Are estimates revised on a monthly basis (or less)?• How closely do past cost/schedule estimates

match actual costs/schedules?

Monitoring (metrics)

• Are there distinct milestones for each phase?

• Is there a monitoring system to track costs, schedule earned value etc?

• Is there a process for addressing and recording technical problems?– Is it used and updated weekly?

Development methodology

• Is there a documented software development methodology/plan that is followed closely?

• Are the developers trained in the methodology?• Does the methodology

– include requirements, design, code reviews?

– require test plans for all functions?

– Require documentation

Tools

• Are the developers trained to use the project tool?• Are automated tools used for

– design?

– Testing?

– Requirements traceability?

– Re-engineering?

• How stable is the compiler/linker/debugger?• Are the tools readily available when needed?

Risk culture

• Will the company trade– increased budget risks/schedule/technical risks

for higher profit?– decreased budget risks/schedule/technical risks

for higher profit?

• Is the company market-driven?

• Does the company practice and document formal risk management procedures?

Usability

• Has the user manual been developed, tested and revised?

• Are help functions available for each input and output?

• Is the user involved in any prototype review?• Id the user interface designed to an industry

standard?• Has the design been evaluated to minimise

keystrokes and data entry?

Correctness

• Have all the requirements been identified and documented?

• Have the requirements been traced to the code & test procedures?

• Have there been/will there be many changes to the requirements?

• Are the designs traceable to code and test procedures?

• Are there any open action items still to be addressed?

Reliability

• Do error-handling conditions exist for every possible instance in the design and code?– Does execution proceed when en error condition is

detected?

• Are error tolerances defined for each input & output?– Is input data validated before processing begins?

• Are test plans used to perform software tests?• Is defect data collected during integration?

Personnel

• Have the personnel resources needed been identified and are they available?

• How experienced is the team – with this product type?– With the development environment?– With the implementation language?

• How many personnel will be required for peak production?