Download
ch 10 risk management learning objectives n.
Skip this Video
Loading SlideShow in 5 Seconds..
Ch 10 - Risk Management Learning Objectives PowerPoint Presentation
Download Presentation
Ch 10 - Risk Management Learning Objectives

Ch 10 - Risk Management Learning Objectives

171 Views Download Presentation
Download Presentation

Ch 10 - Risk Management Learning Objectives

- - - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript

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

  2. Risk Management • Identifying ... • Assigning ... • Responding to … Risk • Throughout life of project • In interest of meeting project objectives

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

  4. Risk Management Means: • Maximizing results of positive events (opportunities) • Minimizing consequences of adverse events (threats) • Risk Management Processes • Identification • Quantification • Response (Development and Control)

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

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

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

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

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

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

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

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

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

  14. Threats to respond to to accept Opportunities to pursue to ignore From quantifying risk, you get (outputs): • Documentation of who decides

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

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

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

  18. 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?

  19. Examples: Software Risk Responses • Training, team-building • Hire outside expertise • Prototyping • more information, less uncertainty • Simulation, scenarios • Contingency planning

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

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

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