Ch 10 - Risk Management Learning 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

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

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

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

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

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

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

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

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

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)

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

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

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

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

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

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

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)

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?

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

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

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

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