cse 7315 - sw project management / module 26 - risk management process, in detail copyright ©...

CSE7315M26

January 10, 2004

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

Software Project

Module 26The Risk Management

Process, In Detail

Slide # 2 January 10, 2004

CSE 7315 - SW Project Management / Module 26 - Risk Management Process, In

All Rights ReservedCSE7315M26

Objective of This Module• To discuss the details of the risk

management process

The Risk Management Process In Detail

• Risk Assessment – Risk Identification– Risk Analysis– Risk Prioritization– Risk Planning & Mitigation (contingency planning)

• Risk Control– Risk Monitoring– Risk Abatement

Risk Assessment• Goal: understand what the risks are, what

they mean, and how best to manage them• Method: develop a risk management plan -- documents your risks -- documents your plans for managing them -- communicates responsibilities to all

affected parties• The plan must be updated as new risks are

identified• For each risk, the likelihood and impact

change over time

• Risk Assessment – Risk Identification– Risk Analysis– Risk Prioritization– Risk Planning Mitigation (contingency planning)

Risk IdentificationThe First Step of Risk Assessment• We have seen how all management

activities, especially planning activities, serve to identify risks

• And we discussed the value of a risk identification brainstorming meeting

• It helps if you know what to look for• Several authors have talked about risks

associated with software development

Boehm’s Top Ten Software Risks (and management techniques for mitigating

them)• This is Boehm’s list, based on

experience with many projects in the 1960-1980 time period

• Your project must define its own list• But this is a good place to start looking

Possible Exam Question Consider a particular situation (provided with the exam). What risks

apply? (careful analysis shows that these three risks are of greatest concern . . .) List of Boehm’s top ten risks

Boehm 1: Personnel Shortfalls

Mitigation Techniques:• Use top talent• Use people who are well matched

to the problem (i.e., they know the application, tools, etc.)

• Pre-schedule the key people• Cross training -- so you don’t

depend on heroes• Team building

Boehm 2: Unrealistic Schedules and Budgets

Mitigation Techniques:• Good estimating techniques– Know before you commit

• Incremental development cycles• Detailed milestones within each phase– Spot trouble early– Provide evidence of progress

• Software reuse– Don’t build what was built before

• Requirements scrubbing– Don’t build what is not required

Boehm 3: Developing the Wrong Software Functions

Mitigation Techniques:• Mission analysis– Understand what is supposed to happen

• User surveys and communication– Know what the user needs and is expecting

• Prototyping– Try it out - a prototype is worth a million bytes

• Write end-user documentation early in the project and use as requirements documents

Boehm 4: Developing the Wrong User Interface

Mitigation Techniques:• Prototyping• Task analysis• Scenario models• etc,

Boehm 5: Gold PlatingMitigation Techniques:• Requirements scrubbing– Don’t build what is not required

• Cost-benefit analysis– Determine what counts the most

• Design-to-cost– Development costs include debugging, error

correction• Design to life-cycle-cost– Life cycle costs include maintenance,

debugging, etc.

Boehm 6: Continuing Stream of Requirements Changes

Mitigation Techniques:• Establish a high change threshold – Make it costly to make a change

• Information hiding– Minimize the impact of change

• Incremental development– Do the stable requirements first

• Establish bounds for requirements– Limit the scope of changes

• Monitor requirements stability and completion– Know the risk of proceeding

Information Hiding• A programming technique whereby

information is made available only where it is required

• This minimizes the impact of change

Student Records

(details known only to access program)

AccessProgram

Student Data Base

Update ..

Display..

Examine..

Compute..

Requirements Bounds

Device Fog

Requirement: “device must find target in fog of density TBD.”Bounded Requirement: “TBD will range from .02 to 1.7 densograms”

When you know therange of the “TBD”

requirement, you canmake many software

design decisions.

Target

Requirements Stability Monitoring

Requirements Stability

020406080

100120140160

Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec

TotalTBDChanges

CDRPDR

Boehm 7: Shortfalls in Purchased

Software/HardwareMitigation Techniques:• Benchmarking– Learn what is the best

• Inspections– Make sure it is in good shape before you buy it

• Reference Checking– Are they able to do the work?– Do they deliver?

• Compatibility Analysis– Make sure it fits with your standards, tools,

documentation requirements, etc.

Boehm 8: Shortfalls in Externally-performed Tasks

Mitigation Techniques:• Subcontract management (a KPA for Level

2 in the SEI CMM)• Reference checking• Pre-award audits and capability

evaluations• Award fee contracts– Reward or bonus if satisfied

• Competitive design or prototyping• Team building– Make them want you to succeed

Boehm 9: Real-time Performance Shortfalls

Mitigation Techniques:• Simulation• Benchmarking• Modeling• Prototyping• Instrumentation• Tuning

Boehm 10: Straining the Limits of Computer ScienceMitigation Techniques:• Technical analysis• Cost-benefit analysis• Prototyping• Reference Checking

Possible Exam Question

List four of Boehm’s “top ten” risks. For each of the above, list three methods of risk

mitigation Explain each of the risks and each of the mitigation

techniques

Possible Exam Question

Consider the risk mitigation technique of prototyping. Describe this technique, and list three risks that this technique helps to mitigate. For each explain how prototyping mitigates the risk.

Risk Analysis & Prioritization

Which Risks are Most Important?• A popular method is to compute two

numbers for each risk:– How likely is it to happen (a probability from 0

to 1 or a ranking from low to high)– How much will it cost if it happens (dollars,

impact)• Then make a table showing risks,

likelihood, cost, and weighted cost (likelihood * cost)

Risk Analysis TableRisk Likelihood Cost Weighted Cost

Building hit by plane 0% 50,000,000 50Sub-Contractor Failure 20% 250,000 50,000Late Hardware 75% 100,000 75,000Test Equipment Delay 30% 40,000 12,000Requirements Changes 99% 5,000 4,950Memory Size 50% 50,000 25,000

Prioritized Risk Analysis TableRisk Likelihood Cost Weighted Cost

Late Hardware 75% 100,000 75,000Sub-Contractor Failure 20% 250,000 50,000Memory Size 50% 50,000 25,000Test Equipment Delay 30% 40,000 12,000Requirements Changes 99% 5,000 4,950Building hit by plane 0% 50,000,000 50

Alternative Risk Analysis Table

Risk Likelihood I mpact WeightedLate Hardware 7 6 42Sub-Contractor Failure 2 7 14Memory Size 5 4 20Test Equipment Delay 3 3 9Requirements Changes 8 2 16Building hit by plane 1 9 9

Note that this method produced a different ordering, but the extreme cases came out in the same order.

WARNINGThis method of risk prioritization has

many risks itself!• Not all risks can be quantified in terms

of dollar impact• Estimates of impact and probability are

highly subjective• Impacts change over time -- must be

revisited• Risk mitigation techniques may have

risks of their own

Risk Mitigation

Minimizing the Impact• Taking actions to reduce the likelihood

or net impact of a risk• We saw many such actions in reviewing

Boehm’s list of risks• Each potential action must be evaluated

in terms of its cost vs. the potential impact

This is the Step Where You Impact the Planning Process

Manage Risks

Definethe Approach

GenerateDetailed Plans

Understandthe Need

Execute and Monitor

Mitigation ExampleRisk: Project delay or failure becausesubcontractor will fail to deliver Weighted Cost: $50,000 Mitigation Options:

•Do it in-house -- Costs $100,000 extra•Send staff to live with subcontractor -- $50,000•Monthly visits -- $12,000

Risk Table After MitigationRisk Likelihood Cost Weighted Cost

Late Hardware 75% 100,000 75,000Memory Size 50% 50,000 25,000Sub-Contractor Failure 5% 250,000 12,500+12,000Test Equipment Delay 30% 40,000 12,000Requirements Changes 99% 5,000 4,950Building hit by plane 0.0001% 50,000,000 50

Risk Plan May Include Tables of Mitigation, Contingency,

etc.Methods

Memory Size

Benchmark

ExtraHardware

Backup

etc.Prototype

SubcontractorDelayed

Late Test Equip.

Late Hardware X

Risk Control• Monitoring– Watch what is happening– Watch for signs of danger

• Risk Abatement– Applying contingency plans– Minimizing impact

Risk MonitoringMethods of monitoring:• Reviews - periodic status reports– Must be honest reviews, not “dog and pony

shows”• Metrics - data to compare actuals with

plans and past performanceWhat to monitor:• All high priority risk items• Consider cost of monitoring - only

monitor what is worthwhile

How Often to Monitor• It depends on priority - you must

plan. For example:– Critical items daily or weekly– Normal items weekly or monthly– Minor items quarterly

• Monitoring too often costs money and slows down the process

Watch Known Danger Points

• Monitor status at key milestones or progress points– Are we where we should be by

We always have a flurry of changes prior to CDR

Don’t Monitor Too Often or in Too Much Detail

• Too often– De-motivates people– Costs a lot – Robs resources from productive activities

• Too much detail (overly precise)– Costs a lot– Does not give significant additional information– May generate a lot of misleading numbers

Late by 2.7321 weeks is not much different from late by 3 weeks

Things to Watch Out For - IHiding the facts to save face– The purpose of monitoring is to manage

properly, not to find fault with individuals– Individuals must trust that you will use the

metrics properly to fix the process, not to punish the messengers

– One solution is self-measurement -- have the individuals measure and monitor themselves without communicating higher except on an aggregate scale or with big problems that they cannot handle

Things to Watch Out For - IIHiding the facts to save the project–Egos and jobs of technical staff vs.

judgment of management vs. pocketbook of sponsor–This can get very political and very

complex

Things to Watch Out For - IIIFailure to get the data because of

fear, overconfidence, or other psychological factors–Be careful of human nature–Focus on teaming, responsibility, and

professional behavior

Things to Watch Out For - IVFailing to get the data because of

high overhead– Automate collection– Consider using a separate metrics

collection/analysis staff to minimize impact on development staff • but not if it destroys teamwork

Things to Watch Out For - VMisinterpretation of data–Any number can be interpreted in

many ways• The “three ways to get it wrong” rule

–Be prepared to ask lots of questions–Define standard measures and

methods of graphing data to minimize unintentional misinterpretation–Educate everyone in statistics

Things to Watch Out For - VI

Failure to trust past performance–Your “track record” is your most

reliable indicator

The Learning ProcessInformation is Communicated

Information isReceived

Information isAnalyzedAction

Each step offers many opportunities for error

Example of MisinterpretationProductivity is

Not EnoughWork Being

Not WorkingHard Enough

MoreOvertime

Perhaps the Real Problem is Too Much Overtime Already

Rate ChartActual vs. Plan

• A Rate Chart shows actual vs. planned progress for some artifact being produced– Coded units– Tested units– Inspected units– Specifications – Requirements defined– Requirements tested– etc.– etc.

• It works for anything that has discrete, measurable units

Units Tested

01020304050607080

1 2 3 4 5 6 7 8 9 10 11

PlanActualHistory

Testing Rate Chart

Units Tested

01020304050607080

1 2 3 4 5 6 7 8 9 10 11

PlanHistory

Testing Rate Chart

Units Tested

01020304050607080

1 2 3 4 5 6 7 8 9 10 11

PlanActualHistory

Testing Rate Chart

Units Tested

01020304050607080

1 2 3 4 5 6 7 8 9 10 11

PlanActualHistoryProjected

Testing Rate Chart

Units Tested

01020304050607080

1 2 3 4 5 6 7 8 9 10 11

PlanActualHistoryProjectedLikely

Another Rate Chart

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16

Historical AveragePlanActualProjected

Risk Abatement• Establish thresholds so you know when to

act– Beware of the “frog in the water” problem

– Historical experience is a good basis to judge when things are getting out of hand

Risk Abatement (continued)

• Act promptly when necessary– Establish action plans before they are

needed – Learn the plan (fire drills) -- there may

be no time in an emergency• Use backup plans if needed– Develop them during the planning phase– Practice them too!

Risk Abatement (continued)

• Let the team participate in the planning–Their cooperation is necessary for

success–Their ownership of the plan will

improve chances of cooperation

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 problemA risk management plan is an

important part of planning

Possible Exam Questions Explain the difference between risk mitigation and risk abatement (risk

contingency) 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

END OFMODULE 26

cse 7315 - sw project management / module 26 - risk management process, in detail copyright ©...

Documents

february 2, 2000 cse 7315 - sw project management / chapter...

cse 7315 - sw project management / module 2 – facts and...

cse 7315 - sw project management / module 36 - details of...

cse 7315 - sw project management / module 13 - function...

copyright 2003-2009, dennis j. frailey software engineering...

cse 7315 - sw project management / module 23 - cycle time...

cse 7315 - sw project management / module 5 - software...

cse 7315 - sw project management / module 8 - software...

january 20, 2000 cse 7315 - sw project management / chapter...

bvo order no.7315 fard dt.03.07.14

to jack frailey - mit class of...

cse 7315 - sw project management / module 25 - risk...

richard frailey - washington secretary of state · richard...

august 13, 2000 cse 7315 - sw project management / chapter 1...

hitech management briefing june 23, 2010 karen...

cse 7315 - sw project management / module 35 - software...

january 20, 2000 cse 7315 - sw project management / chapter...

enterprise digital rights management€¦ · enterprise...

cse 7315 - sw project management / module 1: process - the...

cse 7315 - sw project management / module 31 - software...