cse 7315 - sw project management / module 25 - risk management overview copyright © 1995-2001,...

CSE 7315 - SW Project Management / Module 25 - Risk Management OverviewCopyright © 1995-2001, Dennis J. Frailey, All Rights Reserved

Slide 1

CSE7315M25

January 10, 2001

SMU CSE 7315 / NTU SE 584-NPlanning and Managing a

Software Project

Module 25Risk Management Overview

Slide # 2 January 10, 2001

CSE 7315 - SW Project Management / Module 25 - Risk Management Overview

Copyright © 1995-2001, Dennis J. Frailey, All Rights Reserved

CSE7315M25

Objectives of This Module

• To discuss risk management principles, outline the risk management process, and discuss two methods of risk management

• To review some examples of software risks and risk management




CSE7315M25

Outline of This Module

1) Overview - The Risk Management Process

2) Risk Examples

• text, chapters 5, 6

• Boehm, Barry, Software Risk Management, IEEE Computer Society Press, 1989, ISBN 0-8186-8906-4




CSE7315M25

Risk Management is Continuous

Manage Risks

Definethe Approach

GenerateDetailed Plans

Understandthe Need

Execute and Monitor




CSE7315M25

Software Management:A Framework for Risk

Management

SoftwareDevelopment

RiskManagement

ProjectManagement




CSE7315M25

Another Model of theRisk Management Process

UnderstandNeeds

GenerateDetailed

Plans

DefineApproach

Evaluate& Re-plan

RiskManagement


Slide 7

CSE7315M25

January 10, 2001

The Risk Management Process

1) Risk Assessment (4 activities)2) Risk Control (2 activities)




CSE7315M25

Risk Assessment(This is done as part of planning)

A) Risk Identification- What are the risks?

B) Risk Analysis- What is the likelihood & impact?

C) Risk Prioritization- Which risks are most serious?

D) Risk Planning & Mitigation- Minimizing impact- Planning contingency actions




CSE7315M25

Risk Control(This is done as part of project execution)

A) Risk Monitoring

- Watching to see if risks happen

B) Risk Abatement

- Counteracting risks

- Taking contingency actions




CSE7315M25

Risk Management Methods• There are several recommended methods in

the literature• Here we will discuss two: -- Barry Boehm’s Method -- widely known -- very pragmatic approach -- combines assessment with control -- Dennis Frailey’s Method -- somewhat more comprehensive -- derived from DoD Standards for defense system software

development




CSE7315M25

Top 10 Risks on

Project Alpha

1. Staffing

2. Late Hardware

3. Requirements Definition

4. Real-time perf-

Boehm’s Method ofRisk Management (5 steps)

Risk Assessment (steps 1-2):

1) Identify the top 10 risk items (identification, analysis and prioritization)

2) Present a plan to resolve each of the top 10 items (mitigation; planning for control)




CSE7315M25

Boehm’s Method (continued)

Risk Control (steps 3-5):

3) Update the list and the plan monthly (monitoring)

4) Highlight the risk items at monthly project reviews (monitoring)

5) Initiate corrective action for risks that occur (abatement)

[6) Follow-up until the issue is resolved]




CSE7315M25

Frailey’s Method of Risk Management (11 steps)

Risk Assessment (steps 1-7)– Identification (Step 1)– Analysis (Step 2- 4)– Prioritization (Step 5)– Planning (Step 6,7)

Risk Control (steps 8-11)–Monitor (Step 8, 10)– Abatement (Step 9)– Planning (Step 11)


Slide 14

CSE7315M25

January 10, 2001

Risk Assessment

Frailey Method (steps 1-7)




CSE7315M25

1) Identify all Risk Elements(risk identification)

• Risk Elements consist of:– things that can go wrong – patterns of risk change over the

lifecycle• for example, cost estimating risks occur

early, whereas risks of staff burnout occur later

• If it has already happened, or is certain to happen, it is a problem, not a risk!




CSE7315M25

Notes

• Most risk identification is performed as a part of other planning processes (see the previous chapters in these notes)

• But it is also good to have a pro-active attempt to identify all risks in case something “fell through the cracks”




CSE7315M25

Risk Identification Meeting

• A supplementary meeting to identify risks– Some may have been overlooked– The meeting also helps to focus

attention on risk issues

• Identify the patterns of risk– Risk patterns change over the lifecycle– For example, cost estimating risks occur

early, whereas risks of staff burnout occur later




CSE7315M25

Recall How All Planning Activities Identify Risks

Manage Risks

Definethe Approach

GenerateDetailed Plans

Understandthe Need

Execute and Monitor




CSE7315M25

2) Partition Into Categories(Analysis)

• Sample Categories:-- cost risks

-- schedule risks -- other management risks -- technical risks -- other risks specific to the situation,

such as safety or security risks• One Risk may have multiple categories– Estimating inaccuracies can lead to cost and

schedule risks




CSE7315M25

Why Partition Into Categories?

• Risks may need to be prioritized as demanded by the situation– “continue at any cost” vs. “only do if low

cost”

• Different categories of risks may require different mitigation approaches– Technical risks may require performance

analysis– Schedule risks may require process

changes




CSE7315M25

Other Reasons to Partition Risks into Categories• Different people may be concerned

about different risks– Technical lead vs. – Finance manager vs. – End user waiting for delivery

• Different people may be responsible for different risks




CSE7315M25

3) Identify Contributing Factors

(Analysis)• Many risks can occur in several

ways

• If you aren’t careful, you will only be looking for one of the ways




CSE7315M25

Example of Multiple Contributing Factors

Risk: Not enough memory to hold the softwareContributing Factors: Size of computer memory Expertise of programming staff Efficiency of compiler Choice of algorithms Operating system




CSE7315M25

Using a Hierarchy of Contributing

Factors• Each risk can be seen as a

contributing factor to a larger risk• The top level risk is that the

project will fail• Sometimes it helps to use a

hierarchy to organize risks and contributing factors

• (See next slide)




CSE7315M25

A Sample Risk Hierarchy

Staffing Funding . . .

ProcessorToo Slow

. . .

Size ofMemory

ProgrammingExperience

CompilerEfficiency

Choice ofAlgorithms

MemoryToo Small

PerformanceFailure

ProjectFailure




CSE7315M25

4) Identify Potential Risk Monitoring & Mitigation

Plans (Analysis)

• This must be done for each contributing factor

• See next slides for examples




CSE7315M25

Potential Risk Mitigation Plan

Risk: memory size inadequateFactor: Compiler produces bloated codePotential mitigation:

•Choose a more efficient compiler•Negotiate improvements with vendor

Factor: Inexperienced programmersPotential mitigation:

•Training program •Use more experienced programming staff




CSE7315M25

Multiple Risks with One Approach

Risk: memory size inadequateFactor: Compiler produces bloated code

Factor: Inexperienced programmers

Potential mitigation that applies to both:•Select a larger memory size

Potential monitoring that applies to both:•Track size estimates monthly•Update at each major milestone




CSE7315M25

5) Rank and Prioritize Each Risk

(Prioritization)• Prioritize on the basis of probability

(how likely) and impact

Risk Likelihood Cost

Weighted

CostLate Hardware 75.00% 100,000 75,000

Sub-Contractor Failure 20.00% 250,000 50,000

Memory Size 50.00% 50,000 25,000

Test Equipment Delay 30.00% 40,000 12,000

Requirements Changes 99.00% 5,000 4,950

Earthquake 0.0001% 50,000,000 50

You cannot prevent all risks - focus on the big ones




CSE7315M25

6) Identify Monitoring Procedures for Each Risk

(Planning for control)• Determine how to tell if it is a problem;

how frequently to monitor; etc.• Example: monitor projected size vs.

memory limits on a monthly basis

0

50

100

150

J an Feb Mar Apr May J un J ul Aug Sep Oct Nov Dec

Limit Threshold Estimate




CSE7315M25

7) Develop a Contingency Plan(Planning)

• Identify what to do if the risk occurs despite your mitigation efforts

Risk: memory size exceededContingency Plan:

• Switch to a slower but smaller algorithm• Use a more efficient compiler • Use a smaller operating system• Use larger memory size


Slide 32

CSE7315M25

January 10, 2001

Risk Control

Frailey Method (steps 8-11)




CSE7315M25

Review Status and Take Action (Steps 8, 9)

8) Review status of risks at periodic reviews (Monitor)– Metrics– Changes in impact analysis

9) Take appropriate action when called for (Abatement)– Closer monitoring– Contingency activities




CSE7315M25

“Do Your Homework”(Steps 10, 11)

10) Track all actions to closure (Monitoring)– Don’t forget about them

11) Update the plan (Planning)– Keep it consistent with current knowledge

and status




CSE7315M25

Beware of Subcontractors and Co-contractors

• Risk management applies to these as well

• Include risk management elements in contracts We want

to monitor

your risks

Just trust us




CSE7315M25

The Risk Management Process In Detail (next module)

• Risk Assessment

– Risk Identification

– Risk Analysis

– Risk Prioritization

– Risk Planning & Mitigation (contingency planning)

• Risk Control

– Risk Monitoring

– Risk Abatement


Slide 37

CSE7315M25

January 10, 2001

Risk Examples




CSE7315M25

Risk Example #1“Getting Started on the PC”

To be subcontracted

Need: something that will make our PC stand out to new users -- must have pizzazz

Risk Identification:• Vendor A: best product, positive attitude,

but in financial jeopardy• Vendor B: mediocre product, sound

finances, blasé attitude




CSE7315M25

Analysis and Prioritization

• Only vendor A can do the job– Mediocre product will not fill the bill

• But the whole project could fail if they go out of business prematurely




CSE7315M25

Risks and Mitigation• Product must appeal (“flash and dash”)– End user tests, focus groups

• Deadline is very short– Incentive clause– Incremental deliveries

• Vendor financial instability– Ownership of key resources if they fail– Weekly deliveries of in-progress work– Monthly visits to site




CSE7315M25

The Risk We Overlooked!

• The biggest problem turned out to be our own technical staff– They distrusted the results of focus

groups with real end-users– They did not provide enough “ease of

use” features, even though the subcontractor and the focus groups recommended this




CSE7315M25

Risk Example #2Embedded Flight Control

SoftwareNeed: high performance, embedded, real-

time software for flight control

Risk Identification:• Memory size very limited - might not be

enough– Compiler is new– Requirements are unstable

• Processor may be too slow• Shortage of programmers for this

processor• Schedule very tight




CSE7315M25

Risk Mitigation - Memory Size• Compiler Performance– Evaluation of alternatives before selecting– Backup vendor (different host system)– Assembly language option

• Requirements Stability– Evolutionary lifecycle with prototype– Strong requirements control

• Other– Design hardware to allow larger memory– Use a smaller operating system




CSE7315M25

Risk Mitigation - Processor Speed

• Prototype of key algorithms• Design to allow faster clock• Plan to monitor performance

regularly, starting with simulation of design model

• Consider alternative processor design

• Consider use of multiple processors




CSE7315M25

Risk Mitigation - Staff Experience

• List of programs we can borrow people from• Training plan• Prototype on target

hardware, for experience




CSE7315M25

Risk Mitigation - Schedule• Incremental delivery negotiated with

customer• Do operating system first–Relatively stable–Can start before requirements for

application are complete–Development work provides target

processor experience for staff




CSE7315M25

Summary of Module1) Risk Assessment – Done as part of project planning– Continues throughout the project– Includes planning for risk control

2) Risk Control – Done as part of project execution– You must respond promptly when

monitoring indicates a problem

A risk management plan is an important part of planning




CSE7315M25

Possible Exam Questions Explain the difference between risk mitigation and risk abatement Explain why a risk management plan should be documented Explain why a risk management plan should be periodically revisited Explain why one would go to all the trouble to write a risk

management plan when it tells your manager and your customer that you have a risky project




CSE7315M25

END OFMODULE 25

cse 7315 - sw project management / module 25 - risk management overview copyright © 1995-2001,...

Documents