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


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


The Adobe Flash plugin is needed to view this content

Get the plugin now

View by Category
About This Presentation

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


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
Tags: back | books | boss | events | keep | management | risk


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

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

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

  • 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
  • Were 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 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

Classifying Risks
  • Classifying risks helps in identifying them
  • Impact classifications cost, schedule and
  • Cause classifications resource, technical,
    planning, act of God, etc.
  • Organizational software, electronics, test,
  • 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,
  • 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)

Qualifying Risks
  • Eliminate risks that do not apply (e.g., some
    embedded software risks may not apply to
  • Determine impact of remaining risks
  • Determine probability of risks

Impact Assessment
  • Determine how goal(s) will be impacted if risk
  • 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
  • Are there any ones youre not sure about?

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)

Risk Matrix
0-20 20-40 40-60 60-80 80-100
Respond to Risk
Evaluate Further
Risk Chart (numeric risks)
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
  • Bring in expert training before heavy development

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

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
  • 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
  • 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

Accepting Risks
  • Accept low risks and any intermediate ones with
    too costly a response
  • Preferable to reserve for accepted risks (next
  • 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
  • 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!

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

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!

  • 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