Risk Management (how to keep your boss off your back) - PowerPoint PPT Presentation

Loading...

PPT – Risk Management (how to keep your boss off your back) PowerPoint presentation | free to download - id: 54264a-MGJhY



Loading


The Adobe Flash plugin is needed to view this content

Get the plugin now

View by Category
About This Presentation
Title:

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

Description:

Risk Management (how to keep your boss off your back) Gordon Dosher 5/1/03 Topics An exercise What makes projects go bad? How to predict problems What risks are worth ... – PowerPoint PPT presentation

Number of Views:269
Avg rating:3.0/5.0
Slides: 38
Provided by: GordonD151
Category:
Tags: back | books | boss | events | keep | management | risk

less

Write a Comment
User Comments (0)
Transcript and Presenter's Notes

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


1
Risk Management(how to keep your boss off your
back)
  • Gordon Dosher
  • 5/1/03

2
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

3
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.

4
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
  • Were just going to deal with negative risks today

5
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?

6
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

7
Risk Examples
  • Someone will be pulled off your project
  • The design may use a technology youre 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

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

9
Identifying Risk
10
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)

11
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

12
Some S/W Quality Risks
  • Inadequate requirements (unclear, missing, wrong,
    etc.)
  • Team members dont 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)

13
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

14
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

15
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

16
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 youre not sure about?

17
Qualify Risks
  • For numerical impacts, multiply impact, Ri, by
    probability, Rp, to get probable (effective)
    impact of each risk
  • RiRpRe
  • 20M102M
  • For non-numeric impacts (red-yellow-green), use
    matrix (next slide)

18
Risk Matrix
0-20 20-40 40-60 60-80 80-100
Red
Yellow
Green
Respond to Risk
Evaluate Further
Reserve
19
Risk Chart (numeric risks)
20
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

21
Risk Responses
  • Avoid
  • Transfer
  • Mitigate (lessen)
  • Impact
  • Probability
  • Accept
  • Reserve
  • Absorb

22
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

23
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

24
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

25
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

26
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.)

27
Analyzing Intermediate Risks
  • Net impact of responding, RD, is the effective
    impact of the risk, Re, minus the cost of
    response, Rr
  • RD Re- Rr
  • If net impact positive, respond otherwise choose
    different response or reserve for the risk (see
    accepting risk)

28
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

29
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?

30
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
  • Dont make this an endless exercise

31
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

32
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

33
Managing the Risks
  • 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
  • Do the risk response tasks!

34
Reasons Risk Mgmt. Fails
  • Failure to implement the risk tasks
  • Missed risks
  • Little experience in risk management
  • Not enough research
  • Things you couldnt plan for
  • Inadequate responses
  • Risk more probable or impactful than estimated

35
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

36
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!

37
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
About PowerShow.com