SE351a: Software Project & Process Managementinstruct.uwo.ca/engin-sc/se351a/notes/HG-SE351-Lect-W10...29 Nov., 2005 SE351a, ECE UWO, (c) Hamada Ghenniwa 2 SE351 Roadmap 9Introduction

29 Nov., 2005 SE351a, ECE UWO, (c) Hamada Ghenniwa

SE351a: Software Project & Process ManagementSE351a: Software Project & Process Management

W10: Risk Management

29 Nov., 2005 SE351a, ECE UWO, (c) Hamada Ghenniwa 2

SE351 RoadmapSE351 Roadmap

Introduction to Software Project Management

Project Management

Software Development Life Cycles

Requirements Engineering

Software Process & Project Metrics

Software Project Planning

Project Monitoring & Control

Risk Management

• Software Quality Assurance

• Software Configuration Management


Detailed WBS:Software Lifecycle

Software System (SS)

SS

Subsystem(SSA)

SSA

Subsystem(SSA1)

SSA1

Requirementsof SSA1

Design of SSA1

Code of SSA1

Def

ined

Sof

twar

e Li

fecy

cle

Cod

eR

eqm

tsAn

alys

isD

esig

n

Work packages

WP 1

WP 2

WP 3


Project Management:Project Management:The Control panelThe Control panel

Cost ScheduleCost ScheduleC

umul

ativ

e C

ost

Cum

ulat

ive

Cos

t55 1010

Resource AllocationResource Allocation

Pers

onne

lPe

rson

nel

PERTPERTAssessmentAssessment

Expected DateExpected Date

Specifyoverallsystem

Specifymodule

A

Specifymodule

B

Specifymodule

C

Specifymodule

D

Checkspecifi-cations

Designmodule

A

Designmodule

B

Designmodule

C

Designmodule

D

Code/testmodule

A

Code/testmodule

B

Code/testmodule

C

Code/testmodule

D

Integrate/test

system

Activity PlanActivity Plan


Defects and Fixes MetricDefects and Fixes Metric

New Faults

ResolvedFaults

200

150

100

50

0Time

Def

ects

an d

Fi x

e s

300

200

100

0

-20Time

Total

Experienced

Planned

Actual

Unplanned losses

2000

1500

1000

500

0Time

TotalReqmtsCumChanges

Req

uire

men

ts


Cost Data Collection & Reporting FlowCost Data Collection & Reporting Flow

BCWSBCWS

Inventory AccountInventory Account

StaffStaff

ActualsActuals

ACWPACWP

BCWPBCWP

MonthlyProject Efforts

MonthlyProject Efforts

Weekly LaborReports

Weekly LaborReports

VarianceReports

VarianceReports


Risk Management!Risk Management!

What can go wrong?What can go wrong?What is the likelihood?What is the likelihood?What will the damage be?What will the damage be?What can we do about it?What can we do about it?


DilbertDilbert((Scott Adams)Scott Adams) & Risk Management& Risk Management


OutlinesOutlines

• Risk Principles

• Risk Management Process

• ReferencesBoehm, BW"Software risk management: principles and practices", IEEE Software, January 1991


Defining RiskDefining Risk

• “Risk” –Webster

Possibility of loss or injury

• Risk• the possibility that an event with

negative consequences will occur


Risk: Risk: The Positive SideThe Positive Side

• Risk and opportunity go hand in hand

Many development projects strive to advance current capabilities and achieve something that

hasn't been done before

– which cannot be achieved without taking risk

Risk in itself is not bad

risk is essential to progress

Failure is often a key part of learning

BUT we must balance between

the possible negative consequences of risk

the potential benefits of its associated opportunity


Why donWhy don’’t People Do it?t People Do it?

• Unwillingness to admit risks exist!

“Success- orientation”

o However, this leaves impression

you don’t know exactly what you’re doing

your bosses, customers don’t know exactly what they’re doing

• Tendency to postpone the hard parts

Maybe they’ll go away

Maybe they’ll get easier, once we do the easy parts

• Costs money and time up front


Risk: Risk: The AttitudeThe Attitude

• If you do not actively attack risks, risks will actively attack you!

• If you don’t ask for risk information, you’re asking for trouble

• Risk prevention is more cost-effective than problem detection

• Risk knowledge should be shared especially with decision makersdecision makers


When do people do Risk Management?When do people do Risk Management?

• After they’ve been burned in similar situation

Pain- avoidance

Convincing evidence of consequences

• When everybody involved is convinced

risks exist, but that it’s still worth going forward

o Everyone is a winner Realistic expectations

• When they’ve learned how to do it well

Techniques not well- known, but can be learned


SEI Risk TaxonomySEI Risk Taxonomy

Element Requirements … Engineering Development …. Work ResourcesSpecialties Process Environment

Attribute Stability … Scale Formality … Product Schedule … FacilitiesControl

Software Development RiskSoftware Development Risk

Class Product Development Program/ProjectEngineering Environment Constraints


Risk Areas: Risk Areas: SE ManagerSE Manager

• Areas of risk in a system environment are

o software

o hardware

• Project

o Product

o cost

o schedule

o Resources

•• BusinessBusiness

• Risks in these areas have complex interactions with each other


Risk Factors: Risk Factors: SE ProjectSE Project

• Requirements risk

are customer requirements correct?

is the change rate high?

• Development risk

can the system be designed so that functional and qualityfunctional and quality requirements are met within constraints?

• Technology risk

is the required technology available?

• Resource availability

are required personnel, skills, and facilities available?

•• ExternalExternal risks

is the system development dependent on external accomplishments over which the project has no control?


Risk: Risk: SLCSLC

• Risks in development • projects may fail or be late• products may not satisfy clients

• Risks in operationoperation• products may fail to meet business objectives• might be unreliable, unstable, difficult, or dangerous to use• products may fail to protect

• Risks in maintenancemaintenance• maintenance may be neglected• enhancements may fail• products might be un-maintainable


Risk ManagementRisk Management

• Risk Management: a software engineering practice with

processes, methods, and tools to handle risks in a project

• Provides a disciplined environment for decision-making to:

oo Assess continuouslyAssess continuously what can go wrong (risks)

oo Determine what risksDetermine what risks are important to deal with

oo Implement strategiesImplement strategies to deal with those risks


ImportanceImportance of Risk Management in SEof Risk Management in SE

• Focuses projects on criticalcritical risk items

• Provides bestbest--practice techniquespractice techniques for handlinghandling risk items

• Reduces software costs

by reducing rework

o Usually 40- 50% of software costs


Risk Management: StrategiesRisk Management: Strategies

• Reactive Risk Management

• Proactive Risk Management


Reactive Risk ManagementReactive Risk Management

• Project team reacts to problemsreacts to problems when they occur

Mitigation—

plan for additional resources in anticipation of fire fighting

Fix on failure—

resource are found and applied when the risk strikes

Crisis management—

failure does not respond to applied resources and project is in jeopardyproject is in jeopardy


Proactive Risk ManagementProactive Risk Management

• Formal risk analysis is performed

• Organization corrects the root causes of riskrisk

TQM concepts and statistical SQA

Examining risk sources that are beyond the bounds of the software

Developing the skill to manage change


Risk ManagementRisk Management(SEI, Continuous RM)(SEI, Continuous RM)

An orderly process

1. identifying risks2. analyzing risks3. Planning risks4. tracking risks5. controlling risks

Communication


SEISEI-- Continuous RMContinuous RM (Cont.)(Cont.)

• Identifying

Search for and locate

o risks before they become problems

Everyone may contribute to the risk pool

o it is everyone’s business

• Analyzing

Transform risk data into decision-making information

Evaluate impact, probability, timeframe

Classify risks

Prioritize risks



• Planning

Build a Risk Plan

o Utilize risk information into decisions and risk management actions (both present and future) and execute those actions

Planning is forward-looking

• Tracking

Monitor

o risk indicators

o risk management actions

Combine risk with project tracking



• Controlling

Correct for deviations from risk management plans

Combine with project control

• Communicating

Keep communications open

o Provide information and feedback internal and external to the project on the risk activities, current risks, and emerging risks

Communication happens throughout all the processes of risk management


Risk ManagementRisk Management(SEI, Continuous RM)(SEI, Continuous RM)


Spiral Model: Spiral Model: Risk ManagementRisk Management

Risk Management


Formal Risk Management Formal Risk Management (Boehm)(Boehm)

RiskAssessment

RiskControl

RiskManagement

Risk Mgmt.Planning

RiskResolution

RiskMonitoring

RiskIdentification

RiskAnalysis

RiskPrioritization Risk Exposure

Risk LeverageCompound Risk Reduction

Performance ModelsCost ModelsNetwork AnalysisDecision AnalysisQuality Factor Analysis

ChecklistsDecision Driver AnalysisAssumption AnalysisDecomposition

Buying InformationRisk Avoidance or TransferRisk ReductionRisk Element PlanningRisk Plan Integration

PrototypesSimulations, Benchmarks, AnalysesStaffingMilestone TrackingTop-10 TrackingRisk ReassessmentCorrective Action


Elements Of Risk ManagementElements Of Risk Management(Boehm)(Boehm)

• Risk assessment

risk identification,

risk analysis, and

risk prioritization

• Risk control

risk management planning,

risk resolution, and

risk monitoring


Risk IdentificationRisk Identification

• Identify items or events

that may have a significant negative impact on the project

o e.g., changes in customer requirements, new development technologies, or a change in target systems

Collect input from

project participants

lessons learned from past projects

Develop risk identification checklists

to guide the process


Top 10 Risks Top 10 Risks (Boehm)(Boehm)Based on a Survey of Experienced project managersBased on a Survey of Experienced project managers

1. Personnel shortfalls

2. Schedules, budgets, process

3. Requirements mismatch

4. User interface mismatch

5. Requirements changes

6. Architecture, performance, quality

7. COTS, external components

8. Legacy software

9. Externally- performed tasks

10. Straining software engineering capabilities


Risk AnalysisRisk Analysis

• Risk analysis techniques:

decision analysis, cost risk analysis, schedule analysis, etc.

• Each risk item is evaluated to assess its potential impact on the project

Then each risk is rated in two ways:

o the likelihood that the risk event will actually occur, and

o the consequences to the project if the risk event occurs.


Risk Analysis Risk Analysis (Cont.)(Cont.)

LIKELIHOODLevel What Is The Likelihood

The Risk Will Happen?abcd

e

RemoteUnlikely

LikelyHighly Likely

Near Certainty

CONSEQUENCE Given The Risk is Realized. What is the Magnitude of the Impact?

Level Technical Performance Schedule Cost Impact on Other Team

1

4

5

3

2

Minimal or No Impact Minimal or No Impact Minimal/No-Impact None

Acceptable with SomeReduction in Margin

Additional Resources Required;Able to Meet Need Dates

Acceptable withSignificant Reductionin MarginAcceptable, NoRemaining MarginUnacceptable

Minor Slip in Key Milestone;Not Able to Meet Need Dates

Major Slip in Key Milestoneor Critical Path ImpactedCan’t Achieve Key Team orMajor Milestone

<5%

5 - 7%

>7 - 10%

>10%

Some Impact

Moderate Impact

Major Impact

Unacceptable


Risk PrioritizationRisk Prioritization

• Risk Exposure,

RE = P(UO) X L(UO)

RE: Risk Exposure

P(UO): Probability of Unsatisfactory Outcome

L(UO): Loss of Unsatisfactory Outcome

• Then the risks are prioritized

Problems:o Accuracy of estimates of probability and loss associated with UO

o The amount of uncertainty is a risk

Buy information: e.g., invest in a Prototype


Risk Risk Prioritization Prioritization (Cont.)(Cont.)

Risk exposure

$0.18 million

$0.82 million

$0.30 million

$0 million

$0 million

$2 million

L=$0.5 million

Don’t find CE

P=0.36Find CE

P=0.04Don’t find CE L= $20.5 million

P=0.6No CE L= $0.5 million

Find CE

No CE

L= $20 million

L= $0 million

L= $0 million

P=0.6

P=0.3

P=0.1

CE: Critical Error

Combined risk exposure

$1.3 million

$2 million

Do

Don’t

V & V


Risk Assessment ProcessRisk Assessment Process

LIKELIHOODLevel What Is The Likelihood

The Risk Will Happen?abcd

e

RemoteUnlikely

LikelyHighly Likely

Near Certainty

ASSESSMENT GUIDE RISK ASSESSMENT

HIGH - Unacceptable MajorDisruption likely. Differentapproach required. Prioritymanagement attentionrequired.

MODERATE - Somedisruption. Different approachmay be required. Additionalmanagement attention may beneeded.

LOW - Minimum impact.Minimum oversight needed toensure risk remains low.

Consequence

a

b

532

c

d

e

Like

lihoo

d41

CONSEQUENCE Given The Risk is Realized. What is the Magnitude of the Impact?

Level Technical Performance Schedule Cost Impact on Other Team

1

4

5

3

2

Minimal or No Impact Minimal or No Impact Minimal/No-Impact None

Acceptable with SomeReduction in Margin

Additional Resources Required;Able to Meet Need Dates

Acceptable withSignificant Reductionin MarginAcceptable, NoRemaining MarginUnacceptable

Minor Slip in Key Milestone;Not Able to Meet Need Dates

Major Slip in Key Milestoneor Critical Path ImpactedCan’t Achieve Key Team orMajor Program Milestone

<5%

5 - 7%

>7 - 10%

>10%

Some Impact

Moderate Impact

Major Impact

Unacceptable


Risk Management PlanningRisk Management Planning

• Risk management techniqueA set of risk-control functions to

bring the risk items under control

• For each riskeach risk item, answer the following questions:Why?

o Risk Item Importance, Relation to Project ObjectivesWhat, When?

oo Risk Resolution DeliverablesRisk Resolution Deliverables, Milestones, Activity NetsWho, Where?

o Responsibilities, OrganizationHow?

oo Approach (Prototypes, Surveys, Models, Approach (Prototypes, Surveys, Models, ……))How Much?

o Resources (Budget, Schedule, Key Personnel)

• Risk management planningintegrating the plans for each risk itemeach risk item


Risk ResolutionRisk Resolution

• Techniques to resolve or reduce risks, may includeprototyping

scrubbing requirements

benchmarking

simulation/modeling are employed

cost/schedule estimates

quality-monitoring

staffing decisions

evaluation of new technologies

• 20/80 Ruleexperience in project management has shown:

80% of the potential for project failure can be accounted for by only 20% of the identified risks


Risk ResolutionRisk ResolutionSuccessful RM Techniques for Top 10 Risks Successful RM Techniques for Top 10 Risks (Based on a Survey of Experienced project managers(Based on a Survey of Experienced project managers

Risk Management TechniqueRisk Item

Prototyping; scenarios; user characterization (functionality, style, workload)

5. User interface mismatch

Stakeholder win-win negotiation; business case analysis; mission analysis; ops- concept formulation; user surveys; prototyping; early users’ manual; design/ develop to cost

4. Requirements mismatch;

Qualification testing; benchmarking; prototyping; reference checking; compatibility analysis; vendor analysis; evolution support analysis

3. COTS; external components

Business case analysis; design to cost; incremental development; software reuse; requirements de-scoping; adding more budget and schedule

2. Unrealistic schedules & budgets

Staffing with top talent; key personnel agreements; incentives; team- building; training; tailoring process to skill mix; peer reviews

1. Personnel Shortfalls


Successful RM Techniques for Top 10 RisksSuccessful RM Techniques for Top 10 Risks(Cont.)(Cont.)

Risk Management TechniqueRisk Item

Technical analysis; cost- benefit analysis; prototyping; reference checking

10. Straining software engineering

capabilities

Reference checking; pre-award audits; award-fee contracts; competitive design or prototyping; team building

9. Externally- performed tasks

Design recovery; phase-out options analysis;wrappers/mediators; restructuring

8. Legacy software

High change threshold; information hiding; incremental development (defer changes to later increments)

7. Requirements changes

Architecture tradeoff analysis and review boards; simulation; benchmarking; modeling; prototyping; instrumentation; tuning

6. Architecture, performance,

quality


Risk MonitoringRisk Monitoring

• provides timely risk visibility and resolution

• Incorporate tracking techniques such asmilestone trackingmilestone tracking, tracking of top risks

guarding against new vulnerabilities from prior fixes

continual risk reassessment

• At any point in time, insist at stating the three top risks (i.e., priorities, or watch items), this will include

o the manager,

o the technical leader

o each developer

• Ensure that the feedback loop stays activeRisk Reassessment

Corrective Action


However,However,……

• Risk management steps can incur additional project costo in terms of both resources and project duration

As a result, cost-benefit analysis should be used

o to evaluate when benefitsbenefits, gained by the risk management steps

might become out-weighed by costs associated with implementing them

Documents

SE351a: Software Project & Process Managementinstruct.uwo.ca/engin-sc/se351a/notes/HG-SE351-Lect-W10...29 Nov., 2005 SE351a, ECE UWO, (c) Hamada Ghenniwa 2 SE351 Roadmap 9Introduction