Ch 10 - Risk ManagementLearning Objectives

You should be able to:• List and describe risk management processes,

inputs, outputs, and tools• List and describe sources of risk • Assess the risk of a software development project• Quantify project risk• Explain ways to reduce project risk• Explain ways to monitor and control project risk

Risk Management

• Identifying ...

• Assigning ...

• Responding to …

Risk• Throughout life of project

• In interest of meeting project objectives

Risk Tolerance

• Risk is often necessary for benefits

• Risk utility varies with individuals, corps.:– risk-averse– risk-neutral– risk-seeking

• Seek to achieve balance between risks and opportunities

Risk Management Means:

• Maximizing results of positive events (opportunities)

• Minimizing consequences of adverse events (threats)

• Risk Management Processes– Identification– Quantification– Response (Development and Control)

Risk Identification

• Which risks are likely to affect a project?– documenting their characteristics

• Internal risks vs. external risks– whether project team can control or influence

• Done at beginning and throughout project

• Reduce uncertainty with more information

Sources of Software Project Risk

• User involvement and ownership

• Top management support

• Clarity of vision, objectives, requirements

• Planning, milestones

• Personnel: competent, focused, committed

• Realistic expectations

• Market, financial

To Identify Risks:

You need (inputs):

• Description of Product / Deliverables

• WBS, cost estimates, staffing plan

• Historical information / team knowledge

You use (tools):

• Checklists of sources of risk

• Consider each PMBOK knowledge area

3 Dimensions of Risk (re: McFarland)

• People– inadequate skills (technical, managerial)– inexperience

• Structure– degree of change introduced by system

• Technology– new or untried– product stability

From Identifying Risk, you get: (Outputs)

• Sources of risk applying to the project

• Potential risk events

• Symptoms (triggers for events)

• Probability estimates that events will occur

• Range of possible outcomes– narrows as project progresses

• Expected timing

• Anticipated frequencies

Software Project Risk

• Risk: the chance of something going wrong• RE = P(UO) * L(UO), where RE = risk exposure

• P(UO) = probability of Unsatisfactory Outcome

• L(UO) = loss incurred from Unsatisfactory Outcome

• 3 types of system project risk:– quality (won’t meet specs)– schedule (will be late)– cost (will exceed budget)

Risk Quantification

• Risk analysis– assessing probabilities P(UO)– assessing losses L(UO)

• Risk prioritization– identify most important risk items to address– maintain running list of top 10 risks– regular reviews

To Quantify Risk you need (inputs):

• Stakeholder risk tolerance– varies between organizations– risk averse, risk neutral, risk seeking

• Sources of risk– market, financial, technology

• Potential risk events• Cost estimates• Activity duration estimates

To Quantify Risk you use (tools):

• Expected monetary value (EMV)– risk event probability of occurrence

– risk event value: gain or loss that will occur

– tangible and intangible

• Decision trees (e.g., p. 281)

• Statistical simulations; PERT, Monte Carlo– ranges of possible costs, durations

– greater the range, higher the risk

• Expert judgment (most frequent?) - Delphi

From quantifying risk, you get (outputs):

• Threats – to respond to– to accept

• Opportunities – to pursue– to ignore

• Documentation of who decides

Developing responses to risk

Responses to threats:• avoidance

– eliminating cause of threat, e.g. an event

• acceptance – of consequences

• mitigation – reducing probability of occurrence

Develop a plan for each of top 10 risks

Risk Mitigation Strategies

• Technical, cost, and schedule risks

• Same strategies may apply to multiple areas – use WBS, PERT/CPM– frequent monitoring– team support– PM authority and experience– communication

Tools for Risk Response

• Procurement– transfer risk elsewhere

• Contingency planning– actions to be taken if risk event occurs– contingency reserves

• Alternative strategies– change approach

• Insurance (if applicable)

Outputs: Risk Management Plan

• Results of risk identification, quantification

• General approach to risk management

• Answers questions:– Why is it important to take the risk?– What is the risk?– How will it be mitigated?– Who is responsible for mitigation?– What are milestones for mitigation?– What resources are required?

Examples: Software Risk Responses

• Training, team-building

• Hire outside expertise

• Prototyping – more information, less uncertainty

• Simulation, scenarios

• Contingency planning

Risk Monitoring and Control• Inputs:

– risk management plan

– actual risk events

– identification of new risks

• Tools:– Top 10 Risk Item Tracking

– contingency plans

– workarounds (unplanned responses)

• Outputs: corrective actions, plan updates

Regular Risk Management Reviews:Top 10 Risk Item Tracking

• Actively seek risks, question assumptions

• Keeps management, customer aware

• Keeps risk response as a business decision

• Generates consideration of alternatives

• Promotes confidence in project team– risk awareness, strategies, and action plan

• Minimizes distractions to team

Guidelines for Risk Reduction

• Strong, user-oriented steering committee– high levels of management commitment

• Break up large project into smaller ones– decrease “unit of work” = more tasks

• Minimize dependencies between projects

• Use fewer, more skilled people

• Get outside assistance