1 / 18

Risk Management

Risk Management. Instructor: Vassilis Athitsos. This presentation was derived from the textbook used for this class, McConnell, Steve, Rapid Development , Chapter 5. The presentation was prepared by Mr. Mike O'Dell and modified by Vassilis Athitsos. Systems Design Project Are Risky.

mmandel
Download Presentation

Risk Management

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. Risk Management Instructor: VassilisAthitsos This presentation was derived from the textbook used for this class, McConnell, Steve, Rapid Development, Chapter 5. The presentation was prepared by Mr. Mike O'Dell and modified by VassilisAthitsos.

  2. Systems Design Project Are Risky • The odds of a large project being cancelled due to risks encountered: 50% • The odds of a large project finishing on time are close to zero! • Pete Marwick (1988): 35% of companies studied had at least one “runaway project” • Allstate office automation • 5 year/$8M … 6+ years/$100M • Westpac Banking Corporation info systems • 5 year/$85M… 3years/$150M later: cancelled

  3. Why Do Projects Fail? • Generally, from poor risk management • Failure to identify risks • Failure to actively/aggressively plan for, attack and eliminate “project killing” risks • Risk comes in different shapes and sizes • Schedule risks (short to long) • Cost risks (small to large) • Technology risks (probable to impossible)

  4. Case Study 5-1: What can go wrong? • What type of project is this? • How difficult does it appear to be, on the surface? • What classic mistakes do you see along the way? • Where/when/how could the risks have been better managed?

  5. Elements of Risk Management • Managing risk consists of: identifying, addressing and eliminating risks • When does this occur? • (WORST) Crisis management/Fire fighting : addressing risk after they present a big problem • (BAD) Fix on failure : finding and addressing as the occur. • (OKAY) Risk Mitigation : plan ahead and allocate resources to address risk that occur, but don’t try to eliminate them before they occur • (GOOD) Prevention : part of the plan to identify and prevent risks before they become problems • (BEST) Eliminate Root Causes : part of the plan to identify and eliminate the factors that make specific risks possible

  6. IDENTIFICATION RISK ASSESSMENT ANALYSIS PRIORITIZATION RISK MANAGEMENT PLANNING RISK CONTROL RESOLUION MONITORING Elements of Risk Management • Effective Risk Management is made up of: • Risk Assessment: identify, analyze, prioritize • Risk Control: planning, resolution, monitoring

  7. Risk Assessment Tasks • Identification: produces a list of risks that have potential to disrupt your project’s schedule • Analysis: assesses the likelihood and impact of each identified risk, and the risk levels of possible alternatives • Prioritization: prioritizes the list by impact • serves as the basis for risk control tasks

  8. Risk Control Tasks • Planning: produces your plan for dealing with each risk • Must ensure consistency of the risk management plan with your overall project plan • Resolution: executing your plan to deal with the risks • Monitoring: staying on top of your plan and re-evaluate for new risks

  9. CLASSIC MISTAKES Risk Identification • Most common schedule risks • Feature creep • Gold-plating (requirements/developer) • Shortchanged QA • Overly optimistic schedules • Inadequate design • Silver-bullet syndrome • Research-oriented development • Weak, poorly-trained personnel • Contractor failure • Friction between developers & customers

  10. Risk Identification • Use Table 5-3: Potential Schedule Risks • Schedule Creation • Organization and Management • Development Environment • End-users • Customer • Contractors • Requirements • Product • External Environment • Personnel • Design and Implementation • Process

  11. Risk Analysis: Exposure Table • Analyze the (schedule) impact of each risk • Create a risk exposure/impact table for each risk. • Risk Exposure = Probability of Loss X Size of Loss

  12. Risk Analysis • Estimating Size of Loss • Impact to schedule IF risk is encountered in its expected form • Can be precise based on known date for re-review(s), etc. • May need to break down tasks to lowest known level • Estimating Probability of Loss • Subjective assessment of probability that a given risk will cause the stated impact • Many different practices can be used: • Experience • Delphi or group consensus • Betting analogies (How much would you bet that…?) • Adjective calibration (“Good probability” = x%, “Fair” = y%, …)

  13. 1.3+ 5.65 wks Risk Prioritization • Establishes a focus on your risks based on the expected impact (risk exposure) of each risk • Greatest potential impact must also be addressed • 80/20 Rule

  14. Risk-Management Planning • Develop a specific, detailed planfor resolution of each high-priority risk identified • What must be done • When it must be done • How it will be done • Who will do it • When/how it will be monitored/reassessed

  15. Risk Resolution • Risks can be resolved by: • Avoidance: don’t do the risky activity • Transference: move it to another place (team, organization, contractor, etc.) where it’s not as likely • Buying information: early prototyping, consulting, … • Root cause elimination: get at what causes the risk, and make it go away • Acceptance/assumption: don’t worry about it, but plan to accept the consequences • Publicizing: let stakeholders know (so they implicitly accept the risk), avoid surprises • Controlling: develop contingency plans, allocate additional resources if that will help, … • Recording/remembering: write down what you know so you can use it in the future (e.g., next project, later in this one)

  16. Risk Resolution • Use Table 5-6: Means of Controlling the Most Common Schedule Risks • Find ways to apply these common approaches to the specific risks that you have identified. • Make them specific and relevant to your project.

  17. Risk Monitoring • Risks and potential impact will change throughout the course of a project • Keep an evolving “TOP 10 RISKS” list • See Table 5-7 for an example • Review the list frequently • Refine… Refine… Refine… • Put someone in charge of monitoring risks • Make it a part of your process & project plan

  18. Case Study 5-2: Risk Management Done Right • Why/how did this project start off on the right foot? • Describe the risk management plan: • How were the top risks identified? • What were they? • How were these risks addressed? • How were risks monitored? • What was the end result?

More Related