Managing Risk Project Management PDF

Because learning changes everything.® Chapter Seven Managing Risk © 2021 McGraw Hill. All rights reserved. Authorized only for instructor use in the classroom. No reproduction or further distribution permitted without the prior written consent of McGraw Hill. ...

Because learning changes everything.® Chapter Seven Managing Risk © 2021 McGraw Hill. All rights reserved. Authorized only for instructor use in the classroom. No reproduction or further distribution permitted without the prior written consent of McGraw Hill.  Where We Are Now © McGraw Hill 2  Learning Objectives 7-1 Describe the risk management process. 7-2 Understand how to identify project risks. 7-3 Assess the significance of different project risks. 7-4 Describe the five responses to managing risks. 7-5 Understand the role contingency plans play in the risk management process. 7-6 Understand opportunity management and describe the five approaches to responding to opportunities in a project. 7-7 Understand how contingency funds and time buffers are used to manage risks on a project. 7-8 Recognize the need for risk management being an ongoing activity. 7-9 Describe the change control process. © McGraw Hill 3  Chapter Outline 7.1 Risk Management Process 7.2 Step 1: Risk Identification 7.3 Step 2: Risk Assessment 7.4 Step 3: Risk Response Development 7.5 Contingency Planning 7.6 Opportunity Management 7.7 Contingency Funding and Time Buffers 7.8 Step 4: Risk Response Control 7.9 Change Control Management © McGraw Hill 4  7.1 Risk Management Process Risk Defined An uncertain event or condition that if it occurs, has a positive or negative effect on project objectives. No amount of planning can overcome or control risk. Risk Management Defined An attempt to recognize and manage potential and unforeseen trouble spots that may occur when the project is implemented. What can go wrong (risk event). How to minimize the risk event’s impact (consequences). What can be done before an event occurs (anticipation). What to do when an event occurs (contingency plans). © McGraw Hill 5  Risk Event Graph for a Construction project -Scope Creep (Initiation and Planning Phases) Risk Description: Scope creep happens when new project requirements are added without adjusting resources, time, or budget. Cost Impact: Moderate -Supply Chain Delays (Execution Phase) Risk Description: Delays in obtaining critical materials can halt the project. Cost Impact: High -Team Shortages (Execution Phase) Risk Description: Labor shortages, strikes, or a lack of skilled workers can cause delays and increased costs. Cost Impact: Moderate to High -Regulatory Compliance Issues (Late Execution to Closing Phase) Risk Description: Non-compliance with building codes or regulations discovered late in the project can require significant rework. Cost Impact: Very High © McGraw Hill 6  Risk Event Graph FIGURE 7.1 Access the text alternative for slide images. © McGraw Hill 7  Benefits of Risk Management A proactive rather than reactive approach. Reduces surprises and negative consequences. Prepares the project manager to take appropriate action. Provides better control over the future. Improves chances of reaching project objectives on time, within budget, and of meeting required performance. © McGraw Hill 8  The Risk Management Process FIGURE 7.2 Access the text alternative for slide images. © McGraw Hill 9  7.2 Step 1: Risk Identification Generate a list of all the possible risks that could affect the project through brainstorming and other problem identifying techniques. Focus on the events that could produce consequences, not on project objectives. Use risk breakdown structure (RBS) in conjunction with work breakdown structure (WBS) to identify and analyze risks. Identify the macro risks first then specific areas can be checked. Use risk profile (a list of questions) to address traditional areas of uncertainty on a project. © McGraw Hill 10  The Risk Breakdown Structure (RBS) FIGURE 7.3 Access the text alternative for slide images. © McGraw Hill 11  Partial Risk Profile for Product Development Project Technical Requirements Quality Are the requirements stable? Are quality considerations built into the Design design? Does the design depend on unrealistic or Management optimistic assumptions? Do people know who has authority for Testing what? Will testing equipment be available when Work Environment needed? Do people work cooperatively across Development functional boundaries? Is the development process supported by Staffing a compatible set of procedures, methods, Is staff inexperienced or understaffed? and tools? Customer Schedule Does the customer understand what it will Is the schedule dependent upon the take to complete the project? completion of other projects? Contractors Budget Are there any ambiguities in contractor How reliable are the cost estimates? task definitions? FIGURE 7.4 © McGraw Hill 12  7.3 Step 2: Risk Assessment Scenario analysis assesses the significance of each risk event in terms of probability and impact. Risk assessment form evaluates the severity, probability of risk events and its detection difficulty. Risk severity matrix prioritizes which risks to address. Failure Mode and Effects Analysis (FMEA) extends the risk severity matrix by including ease of detection in the equation: Risk Value = Impact  Probability  Detection Probability analysis uses statistical techniques in assessing project risk. Decision trees, net present value (NPV), program evaluation and review technique (PERT), PERT simulation © McGraw Hill 13  Defined Conditions for Impact Scales of a Risk on Major Project Objectives (examples for negative impacts only) Relative or Numeric Scale Project 1 2 3 4 5 Objective Very Low Low Moderate High Very High > 40% cost Insignificant cost 20% time Time increase increase increase increase increase Project end Scope reduction Scope decrease Minor areas of Major areas of item is Scope unacceptable to barely noticeable scope affected scope affected effectively sponsor useless Only very Quality reduction Project end Quality Quality reduction demanding unacceptable to item is Quality degradation requires sponsor applications are sponsor effectively barely noticeable approval affected useless FIGURE 7.5 © McGraw Hill 14  Risk Assessment Form Risk Event Likelihood Impact Detection Difficulty When Interface problems 4 4 4 Conversion System freezing 2 5 5 Start-up User backlash 4 3 3 Postinstallation Hardware 1 5 5 Installation malfunctioning FIGURE 7.6 © McGraw Hill 15  Risk Severity Matrix Failure Mode and Effects Analysis (FMEA) Impact × Probability × Detection = Risk Value 5 User Interface 4 Backlash problems Likelihood Red zone (major risk) 3 Yellow zone (moderate risk) Green zone (minor risk) System 2 freezing Hardware 1 malfunc- tioning 1 2 3 4 5 FIGURE 7.7 © McGraw Hill 16  7.4 Step 3: Risk Response Development Mitigating Risk Reducing the likelihood that the event will occur. Reducing the impact that the adverse event would have on the project. Avoiding Risk Changing the project plan to eliminate the risk or condition. Transferring Risk Passing risk to another party. Examples: Fixed-price contracts, insurance, Build-Own-Operate-Transfer (BOOT) provisions. Escalating Risk Notifying the appropriate people within the organization of the threat. Retaining Risk Making a conscious decision to accept the risk of an event occurring. © McGraw Hill 17  7.5 Contingency Planning Contingency Plan Defined Is an alternative plan that will be used if a possible foreseen risk event becomes a reality. Is a plan of action that will reduce or mitigate the negative impact of the risk event. Is not a part of the initial implementation plan and only goes into effect after the risk is recognized. Risks of the absence of a contingency plan Cause a manager to delay or postpone the decision to implement a remedy. Lead to panic and acceptance of the first remedy suggested. Make the decision making under pressure which can be dangerous and costly. © McGraw Hill 18  Risk Response Matrix Risk Event Response Contingency Plan Trigger Who Is Responsible Interface Mitigate: Test prototype Work around Not solved Nils problems until help comes within 24 hours System freezing Mitigate: Test prototype Reinstall OS Still frozen after Emmylou one hour User backlash Mitigate: Prototype Increase staff Call from top Eddie demonstration support management Equipment Mitigate: Select reliable vendor Order replacement Equipment fails Jim malfunctions Transfer: Warranty FIGURE 7.8 © McGraw Hill 19  Risk and Contingency Planning Technical Risks Backup strategies if chosen technology fails. Assess whether technical uncertainties can be resolved. Schedule Risks Expedite or “crash” the project to get it back on track. Schedule activities in parallel or use start-to-start lag relationships. Use the best people for high-risk tasks. Cost Risks Review price to avoid the trap of using one lump sum to cover price risks. Funding Risks Evaluate the risk of reductions in funding—a cut in the project. © McGraw Hill 20  7.6 Opportunity Management An opportunity is an event that can have positive impact on project objectives. Exploit Seek to eliminate the uncertainty associated with an opportunity to ensure that it definitely happens. Share Allocate some or all of the ownership of an opportunity to another party who is best able to capture the opportunity for the benefit of the project. Enhance Take action to increase the probability and/or the positive impact of an opportunity. Escalate Notify the appropriate people within the organization of the opportunity. Accept Be willing to take advantage of the opportunity if it occurs, but not taking action to pursue it. © McGraw Hill 21  7.7 Contingency Funding and Time Buffers Contingency Funds Are funds to cover project risks—identified and unknown. For control purposes, contingency funds are divided into: Contingency reserves—cover identified risks and allocated to specific segments or deliverables of the project. Management reserves—cover unidentified risks and are allocated to risks associated with the total project. Time Buffers Are amounts of time used to cushion against potential delays in the project. Add to activities with severe risks. Add to merge activities that are prone to delays. Add to noncritical activities to reduce the likelihood that they will create another critical path. Add to activities that require scarce resources. © McGraw Hill 22  Budget Estimate Budget Contingency Project Activity Baseline Reserve Budget Design $500,000 $15,000 $515,000 Code 900,000 80,000 980,000 Test 20,000 2,000 22,000 Subtotal $1,420,000 $97,000 $1,517,000 Management reserve — — 50,000 Total $1,420,000 $97,000 $1,567,000 TABLE 7.1 © McGraw Hill 23  7.4 Step 4: Risk Response Control Risk Register Details all identified risks, including descriptions, category, probability of occurring, impact, responses, contingency plans, owners, and current status. Risk Control involves: Executing the risk response strategy. Monitoring triggering events. Initiating contingency plans. Watching for new risks. Establishing a Change Management System Monitoring, tracking, and reporting risk. Fostering an open organization environment. Repeating risk identification/assessment exercises. Assigning and documenting responsibility for managing risk. © McGraw Hill 24  7.9 Change Control Management Sources of Change Project scope changes. Implementation of contingency plans. Improvement changes. Change Management Systems 1. Identify proposed changes. 2. List expected effects of proposed change(s) on schedule and budget. 3. Review, evaluate, and approve or disapprove of changes formally. 4. Negotiate and resolve conflicts of change, conditions, and cost. 5. Communicate changes to parties affected. 6. Assign responsibility for implementing change. 7. Adjust the master schedule and budget. 8. Track all changes that are to be implemented. © McGraw Hill 25  Change Control Process FIGURE 7.9 Access the text alternative for slide images. © McGraw Hill 26  Benefits of Change Control Systems 1. Inconsequential changes are discouraged by the formal process. 2. Costs of changes are maintained in a log. 3. Integrity of the WBS and performance measures is maintained. 4. Allocation and use of contingency and management reserves are tracked. 5. Responsibility for implementation is clarified. 6. Effect of changes is visible to all parties involved. 7. Implementation of change is monitored. 8. Scope changes will be quickly reflected in baseline and performance measures. © McGraw Hill 27  Sample Change Request FIGURE 7.10 Access the text alternative for slide images. © McGraw Hill 28  Change Request Log Owner Requested Change Status Report—Open Items OSU—Weatherford Dates Rc# Description Reference Document Date Rec’d Date Submit Amount Status Comments 51 Sewer work offset −188,129 OPEN FUNDING FROM OTHER SOURCE 52 Stainless Plates at restroom ASI 56 1/5/2013 3/30/2013 9,308 APPROVED Shower Valves 53 Waterproofing Options ASI 77 1/13/2013 169,386 OPEN 54 Change Electrical floor box RFI 113 12/5/2013 3/29/2013 2,544 SUBMIT spec change 55 VE Option for Style and rail Door samples 1/14/2013 −20,000 ROM doors 56 Pressure Wash C tower Owner request 3/15/2013 3/30/2013 14,861 SUBMIT 57 Fire Lite glass in stairs Owner request 8,000 QUOTE ROM BASED ON FIRELITE NT 58 Cyber Café added tele /OFOI ASI 65 1/30/2013 3/29/2013 4,628 APPROVED equipment 59 Additional Dampers in C wing ASI 68 2/4/2013 3/29/2013 1,085 SUBMIT 60 Revise Corridor ceilings ASI 72 2/13/2013 3/31/2013 −3,755 SUBMIT OPEN—Requires estimate SUBMIT—RC letter submitted ASI—Architect’s supplemental instructions ROM—Rough order magnitude APPROVED—RC letter approved RFI—Request for information QUOTE—Subcontractor quotes REVISE—RC letter to be reviewed FIGURE 7.11 © McGraw Hill 29  Key Terms Avoiding risk Risk Change management Risk breakdown structure system (RBS) Contingency plan Risk profile Contingency reserves Risk register Escalating risk Risk severity matrix Management reserves Scenario analysis Mitigating risk Time buffer Opportunity Transferring risk Retaining risk © McGraw Hill 30  Appendix 7.1 PERT and PERT Simulation © McGraw Hill 31  PERT—Program Evaluation and Review Technique Assumes each activity duration has a range that statistically follows a beta distribution. Uses three time estimates for each activity: optimistic, pessimistic, and a most likely time estimate to represent activity durations. From these three time estimates, a weighted average time estimate and a variance is calculated. Knowing the weighted average and variances for each activity allows the project planner to compute the probability of meeting different project durations. The longer the project duration is, the higher is the probability of meeting that duration. © McGraw Hill 32  Activity and Project Frequency Distributions FIGURE A7.1 Access the text alternative for slide images. © McGraw Hill 33  Activity Time Calculations 1 The weighted average activity time is computed by the following formula: a + 4m + b te = (7.1) 6 where te = weighted average activity time a = optimistic activity time (1 chance in 100 of completing the activity earlier under normal conditions) b = pessimistic activity time (1 chance in 100 of completing the activity later under normal conditions) m = most likely activity time © McGraw Hill 34  Activity Time Calculations 2 The variability in the activity time estimates is approximated by the following equations: The standard deviation for the activity b−a t =   (7.2) e  6  The standard deviation for the project T = E  t  2 e (7.3) The above formula is just the square-root of the sum of the variances of all critical tasks. © McGraw Hill 35  Activity Times and Variances Activity a m b te [(b − a)/6]2 1 to 2 17 29 47 30 25 2 to 3 6 12 24 13 9 2 to 4 16 19 28 20 4 3 to 5 13 16 19 16 1 4 to 5 2 5 14 6 4 5 to 6 2 5 8 5 1 TABLE A7.1 © McGraw Hill 36  Probability of Completing the Project The equation below is used to compute the “Z” value found in statistical tables (Z = number of standard deviations from the mean), which, in turn, tells the probability of completing the project in the time specified. Ts − TE Z= (7.4)  2 te where TE = critical path duration TS = scheduled project duration Z = probability (of meeting scheduled duration) (see statistical Table A7.2) © McGraw Hill 37  Hypothetical Network FIGURE A7.2 Access the text alternative for slide images. © McGraw Hill 38  Possible Project Durations Probability project is completed Probability project is completed before scheduled time (TS) of 67 units by the 60th unit time period (TS) TS − TE 60 − 64 Z= Z=  t  2 e 25 + 9 + 1 + 1 67 − 64 −4 = = 25 + 9 + 1 + 1 36 +3 = −0.67 = 36 P  0.26 = +0.50 P = 0.69 FIGURE A7.3 Access the text alternative for slide images. © McGraw Hill 39  Z Values and Probabilities Z Value Probability Z Value Probability −3.0.001 +0.0.500 −2.8.003 +0.2.579 −2.6.005 +0.4.655 −2.4.008 +0.6.726 −2.2.014 +0.8.788 −2.0.023 +1.0.841 −1.8.036 +1.2.885 −1.6.055 +1.4.919 −1.4.081 +1.6.945 −1.2.115 +1.8.964 −1.0.159 +2.0.977 −0.8.212 +2.2.986 −0.6.274 +2.4.992 −0.4.345 +2.6.995 TABLE A7.2 −0.2.421 +2.8.997 © McGraw Hill 40 Because learning changes everything. ® www.mheducation.com © 2021 McGraw Hill. All rights reserved. Authorized only for instructor use in the classroom. No reproduction or further distribution permitted without the prior written consent of McGraw Hill.