Risk Management(how to keep your boss off your back)

Gordon Dosher5/1/03

Topics

• An exercise• What makes projects go bad?• How to predict problems• What risks are worth addressing?• How to reduce risk• What do I do if something unplanned

happens?• References

A Risk Exercise, Part I

• For a project you are working on now: Work, school, home, personal life, etc. Write down some goals (deliverables, schedule,

quality of work, cost, etc.) Write down 2-5 things that could prevent you

from meeting the goals What is the rough probability of each

happening? Write by each item. What will happen if each thing occurs? Write by

each item.

What is Risk?

• A risk is an unplanned event that might happen in the future and would have an impact on a goal

• A problem is a risk that became a reality and has a negative impact

• An opportunity is a risk that became a reality and has a positive impact

• We’re just going to deal with negative risks today

Risk Tolerance

• The ability of the stakeholders to absorb the impact of negative events

• How much deductible do you have on your homeowners insurance?

• How late can your homework be and how much of a grade reduction could you stand?

• How much delay could your customer or organization stand on a project?

Risk Attributes

• Probability: estimate of the likelihood of the risk occurring

• Impact: how the risk would affect project goals if it happened

• Time: when the risk could occur• Response options: whether the risk

can be avoided, reduced or transferred

Risk Examples

• Someone will be pulled off your project

• The design may use a technology you’re not familiar with

• The new development environment will have bugs (is too slow, eats your code, etc.)

• Your significant other will leave you• Your instructor will grade tough

Classifying Risks

• Classifying risks helps in identifying them• Impact classifications: cost, schedule and

quality• Cause classifications: resource, technical,

planning, act of God, etc.• Organizational: software, electronics, test,

manufacturing• Other taxonomies could be used• Sub-categories may be useful (resource-

schedule)

Identifying Risk

Ways to Identify Risks

• Use info from past projects• Use expert knowledge

People who do the work Subject matter experts Books, articles, etc.

• Use checklists of risks• Use group method (brainstorming)

Some S/W Schedule Risks

• Resource not available as planned• Resources not as skilled as planned• More errors than planned• Requirements unclear• Requirements missing or wrong• Unfamiliarity with tools• Tools not as good as planned• Unfamiliarity with technology or language• Organizational change, move, etc.• Friction among team members• Code reuse less than planned• Architecture problems -- too complicated, not modeled, too big,

etc.• Inadequate configuration management• Build times too long

Some S/W Quality Risks

• Inadequate requirements (unclear, missing, wrong, etc.)• Team members don’t follow process• Unfamiliarity with technology• Unfamiliarity with language• Resources not as skilled as planned• Code complexity• Architecture complexity• Inadequate reviews• Inadequate testing• Inadequate configuration management• Inadequate interface control• Inadequate error handling• Inadequate data structure / table management (e.g., Windows)

Qualifying Risks

• Eliminate risks that do not apply (e.g., some embedded software risks may not apply to databases)

• Determine impact of remaining risks• Determine probability of risks

Impact Assessment

• Determine how goal(s) will be impacted if risk occurs Schedule, cost, quality, etc. impact

• Impacts in one category (resources, cost, etc.) should use the same unit ($, hrs., etc.)

• Ideally, all impacts would be in same unit• Use group method to get consensus on

project-level impacts• May want to use non-linear or discrete

scaling on some risk categories

Probability Assessment

• Probabilities should be rough estimates (10 or 20% granularity) Hard to quantify risks better Complex methods get poor response

• For project-level risks, get consensus on probability from stakeholders

Risk Exercise, Part II

• For your list of risks from part I: How much would each problem cost if it

happened ($, time, grade, etc.) Would you be willing to accept the risk

of any of them (cost and probability)? Are there any that are unacceptable

(cost and probability)? Are there any ones you’re not sure

about?

Qualify Risks

• For numerical impacts, multiply impact, Ri, by probability, Rp, to get probable (effective) impact of each risk

Ri*Rp=Re

$20M*10%=$2M• For non-numeric impacts (red-yellow-

green), use matrix (next slide)

Risk Matrix

0-20% 20-40%

40-60%

60-80%

80-100%

Red

Yellow

Green

Respond to Risk

Evaluate Further

Reserve

Risk Chart (numeric risks)

Acceptable

Intermediate

Not acceptable

0

20

40

60

80

100

120

140

160

180

0% 20% 40% 60% 80% 100%

Risk probability

Risk Value ($k)

Qualifying Risks (cont.)

• Matrix and chart are just examples. Modify for your situation.

• Response dividing lines based on risk tolerance of stakeholders

• High risks are those stakeholders cannot tolerate

• Intermediate risks must be qualified further during response phase

• Low-risk areas should still be accounted for in risk responses

Risk Responses

• Avoid• Transfer• Mitigate (lessen)

Impact Probability

• Accept Reserve Absorb

Risk Avoidance

• Do root-cause analysis • Eliminate the cause of the risk• Example:

Risk that staff unfamiliar with development environment

Bring in expert training before heavy development starts

Risk Transfer

• Insurance: pay someone to assume the risk of the problem happening

• May be done through insurance company, customer, supplier, etc.

• Not usually possible for individuals on a team

Mitigating Risk Probability

• Similar to risk avoidance, except uncertainty cannot eliminated

• Root-cause analysis also helps here• Example: Risk that new technology

will not work Hire expert in similar area Do technology maturation project Do prototypes Do evolutionary development

Mitigating Risk Impact

• Contingencies: actions to minimize the effects of negative events

• Alternate paths: if a risk occurs, put plan into action (go to tornado shelter)

• Have a backup ready in case the primary fails (remote data storage, second bridegroom, etc.)

• Very similar to risk transfer

To Respond or Not

• Must respond to high risks (“red”) because stakeholders cannot tolerate these risks

• Low risks (“green”) can be tolerated by stakeholders and should be accepted

• Analyze the cost of responding to each intermediate risk vs. accepting it

• Response cost, Rr, must be defined in same units as risk ($, hrs., etc.)

Analyzing Intermediate Risks

• Net impact of responding, R, is the effective impact of the risk, Re, minus the cost of response, Rr

RRe- Rr

• If net impact positive, respond; otherwise choose different response or reserve for the risk (see accepting risk)

Risk Response Analysis Example

• Effective risk that supplier will delay project completion by 5 weeks

• Mitigation: pay supplier $50k for overtime to meet schedule

• Cost of getting to market 5 weeks late: $100k

• Net gain: $50k• Pay the supplier

Risk Exercise, Part III

• For your list of risks from Part II: Multiply the probability of each by its cost (for

items that are numerically costed) Choose the highest probable-cost problem What could be done to prevent the problem or

reduce its probability? How much would it cost to prevent or mitigate

the problem? Is the cost of prevention less than the cost of

the problem?

Secondary Risks

• Nothing is free, including risk response• Besides cost to respond, response may

create own risks• The more complex the response, the more

likely to cause problems• Do scenario analysis to determine possible

risks of responding• Analyze these risks like the primary ones• Don’t make this an endless exercise

Accepting Risks

• Accept low risks and any intermediate ones with too costly a response

• Preferable to reserve for accepted risks (next slide)

• Less preferable to absorb them if they occur

Reserving for Risks

• Building in enough budget and schedule tolerance to account for assumed risks

• Cost reserves are investment or contract funds set aside for accepted cost risks (material overruns, etc.)

• Schedule reserves are activities or times added for accepted schedule risks

Managing the Risks

1. Build your responses and reserves into your project plan and budget

Add tasks to cover avoidance, transfer, and mitigation activities

Add money or set aside a portion to cover reserves and responses

Cut project scope, if necessary to ensure risk management is covered

2. Do the risk response tasks!

Reasons Risk Mgmt. Fails

1. Failure to implement the risk tasks2. Missed risks

• Little experience in risk management• Not enough research• Things you couldn’t plan for

3. Inadequate responses4. Risk more probable or impactful

than estimated

Risk Reviews

• The risk process is cyclic. New risks may crop up at any time and must be handled.

• Risks should be reviewed at every project or development phase: Update on impacts, probabilities and responses Risks that became reality and their impacts Risks that are no longer possible Newly discovered risks and the analysis of

them

What About the Unexpected?

• Surprises happen!• Determine whether the event

can be tolerated or absorbed by reserves

• If not, determine an immediate response (workaround, stopgap, renegotiation, etc.) and implement it!

References

• DeMarco and Lister, Waltzing with Bears: Managing Risk on Software Projects, Dorset House, 2003

• A Guide to the Project Management Book of Knowledge (PMBOK Guide), Project Management Institute, 2000

• Continuous Risk Management Guidebook, Carnegie Mellon University, 1996

• Dorofree, Audrey; Software Risk Management (presentation), Carnegie Mellon University, 1998