Technical Risk Management
•Télécharger en tant que PPT, PDF•
3 j'aime•5,118 vues
Risk Management is a critical success factor for all project work. Risk identification, quantitative and qualitative analysis, and risk response planning and execution is provided in this presentation
Recommandé
Contenu connexe
Tendances
Tendances (20)
Similaire à Technical Risk Management
Similaire à Technical Risk Management (20)
Plus de Glen Alleman
Plus de Glen Alleman (20)
Dernier
Dernier (20)
Technical Risk Management
- 1. CPM-200F: Technical Risk Management Dr. William G. Chadick, D.M., PMP, EVP, CSSMBB MCR, LLC wchadick@mcri.com 719-330-0188 Date: October 2012 IPMC 2012 1
- 2. TLO #1: The student will recognize the importance of technical risk issues and their impact on project performance. TLO #2: The student will summarize how risk management involves all program team members. TLO #3: The student will recognize the importance of identifying, documenting, tracking, and managing risks and opportunities. TLO #4: The student will recognize the importance of establishing a risk management plan TLO #5: The student will recognize the importance of establishing a plan to integrate risk management with EVM. Learning Objectives 2
- 3. • Process and Definitions • Risk Management • Risk Identification • Quantitative and Qualitative Analysis • Risk Response Lesson Outline 3
- 4. Prior Modules By now you should have had modules on: • Risk and Procurement Management • Development of the WBS • Critical Path Method • Schedule Risk Analysis 4
- 5. PMBOK® Guide Risk Definition Project risk is an uncertain event or condition that, if it occurs, has a positive or a negative effect on at least one project objective, such as time, cost, scope, or quality • Uncertainty, i.e., probabilistic in character • Not an ISSUE • Affect on dimensions of time, cost, scope, quality TLO 1 5
- 6. PMBOK® Guide Risk Management • Management Planning – how to approach, plan, execute • Identification – determine risks that might affect project • Qualitative Risk Analysis – prioritizing for further analysis • Quantitative Risk Analysis – numerically analyzing effect • Risk Response Planning – develop options and actions • Risk Monitoring and Control – track, monitor, execute TLO 1 6
- 7. What is Risk Management? • “…the systematic process of identifying, analyzing and responding to project risk.1” • Includes, “developing risk-handling options, monitoring risks to determine how risks have changed, and documenting the overall risk management program.2” • Comprises both risk and opportunity management 1 A Guide to the Project Management Body of Knowledge (PMBOK® Guide), 4th Edition, Project Management Institute. 2 Risk Management Guide for DoD Acquisition Second Edition, Defense Systems Management College, Fort Belvoir ,VA, May 1999. TLO 1 7
- 8. Risk Identification Risk Mitigation Plan Implementation Risk Mitigation Planning Risk Analysis Risk Tracking The DoD Risk Management Process Model AT&L Defense Systems Risk Guide The Risk Management process includes: • Identification • Analysis • Mitigation Planning • Mitigation Plan Implementation • Tracking Focus is on Mitigation. Opportunities not addressed. TLO 2 8
- 9. Another Risk Management Process (Chapman & Ward) Consolidate information, identify information needs Scope the effort based on operational level assessment Identify potential risk and responses Test assumptions about risk against the overall project plan Assign responsibilities Identify areas of uncertainty Synthesize, evaluate, and diagnose results Finalize the plan for implementation Ongoing control, monitoring and reporting Define Focus Identify Structure Ownership Estimate Evaluate Plan Manage TLO 2 9
- 10. TitleUse a Risk Management Process TLO 2 10
- 11. Risk Plan SECTION PURPOSE Methodology Define the approaches, tools, and data sources. Roles and Responsibilities Define the lead, support, and membership of the risk management team. Budget Establish a budget for risk management. Timing Establish how often and when risk is assessed during the project life cycle Scoring and Interpretation Employ tool(s) to identify the risk Scoring and Interpretation Employ Quantitative or Qualitative tool (s) to assess the risk Threshold Establish the criteria for acting on risk: by whom and in what manner. Tracking and Reporting Establish how risk will be documented, analyzed, and communicated to the project team, stakeholders, and sponsors PMBOK® Guide, chapter 11 TLO 4 11
- 12. Managing Risk • Have an overall process • Have a plan, directive, etc., unique to the program or project • Identify and empower key people: PM, CAMs, Engineer/Technical SMEs, Risk Manager • Hold Risk Review boards with specified frequency • Use pertinent tools rigorously TLO 4 12
- 13. PMBOK® Guide Risk Management • Management Planning – how to approach, plan, execute • Identification – determine risks that might affect project • Qualitative Risk Analysis – prioritizing for further analysis • Quantitative Risk Analysis – numerically analyzing effect • Risk Response Planning – develop options and actions • Risk Monitoring and Control – track, monitor, execute TLO 3 13
- 14. Risk and Opportunity Identification • What are the Risk Events in the Program? – Known / Unknowns (can assess probability/consequence) – Unknown / Unknowns (true uncertainty) • Where are Risk Events Located in the Program? – Technology, Design, T&E, M&S, Cost, Funding, Schedule – Program Environment/Structure – Functional or Product or both – Oversight and Politics…changing Department guidance/priorities – US or World Markets – Election, Labor markets (hot/cold cycles) • Analyze Root Cause/Source of Risk – Tactical and Strategic (inside/outside PM Office) – Product or Process (predicts the product problems) Don’t narrow the vision of your Program TLO 3 14
- 15. Risk Identification Tools • Risk Breakdown Structure (RBS) – Lists the categories and sub-categories of risk – Associate risks with a Control Account on the WBS • Risk Critical Path – Along with tasks that are on the Critical Path…also identify tasks that have technical or performance challenges • Flowchart Analysis – Look for logic flow and task linkage – Causal Flow Analysis/Influence Diagram is a flavor • Checklisting – Tasks not completed to standard are a risk TLO 3 15
- 16. More Risk Identification Tools • Cause and Effect Analysis – Force Field Analysis – Causal Flow Diagramming – Isolate and analyze how variables interact • SWOT Analysis – Lists threats and opportunities • Pareto Analysis – Empirical 80/20 rule • Fishbone/Ishikawa/Root Cause Tree – Root cause analysis • Earned Value Metrics – Indicate risk with respect to Cost, schedule, performance TLO 3 16
- 17. Risk Identification R e g u la to ry N a tu ra l H a z a rd s P o s tu la te d E v e n ts S id e E ffe c ts C o m p le tio n E x te rn a l U n p re d ic ta b le M a rk e t R is k s O p e ra tio n a l E n v iro n m e n ta l Im p a c ts S o c ia l Im p a c ts C u rre n c y C h a n g e s In fla tio n T a x a tio n E x te rn a l P re d ic ta b le M a n a g e m e n t S c h e d u le C o s t C a s h F lo w L o s s o f P o te n tia l In te rn a l N o n -te c h n ic a l C h a n g e s in te c h n o lo g y P e rfo rm a n c e R is k S p e c ific to te c h n o lo g y D e s ig n S h e e r S iz e o r C o m p le x ity o f P ro je c t T e c h n ic a l L ic e n c e s P a te n t R ig h ts C o n tra c tu ra l O u ts id e r S u it In s id e r S u it F o rc e M a je u re L e g a l R is k Id e n tific a tio n Source: Max Wideman, “Project and Program Risk Management,” 1984. TLO 3 17
- 18. Risk Identification F u n d in g P o lit ic a l S u p p o r t S h a r e d T e c h n o lo g y A s s o c ia t e P e r fo r m a n c e E x t e r n a l R is k s P la n n in g R e s o u r c e s T o o ls S k ills S u b c o n t r a c t o r P e r fo r m a n c e I n t e r n a l R is k s I m p le m e n t a t io n R is k s S in g le p o in t o f F a ilu r e L im it e d life it e m s E x p e n d a b le s U n t e s t a b le s P r o c e s s S e n s it iv e R is k s o f F a ilu r e R a d ia t io n E x p lo s iv e s P o t e n t ia l E n e r g y H ig h V o lt a g e T o x in s R is k s o f H a z a r d s P r o d u c t R is k s P r o je c t R is k These can lead to project cancellation. These can lead to personal injury or project failure Source: Stephen Grey, “Practical Risk Assessment for Project Managers,” 1995. TLO 3 18
- 19. Project Opportunities N e w M a r k e t N e w P r o d u c t N e w A p p r o a c h R e p o s it io n in g S t r a t e g ic O p p o r t u n it ie s S h o r t e n S c h e d u le R e d u c e C o s t I m p r o v e P r o c e s s e s E lim in a t e u n n e c c e s s a r y a c t iv it ie s L e v e r a g e R & D T a c t ic a l O p p o r t u n it ie s P r o je c t O p p o r t u n it ie s Source: Stephen Grey, “Practical Risk Assessment for Project Managers,” 1995. TLO 3 19
- 20. Risk Identification NATURAL ENVIRONMENTAL PROCESSES BIOHAZARDS INDUCED SABOTAGE/ TERRORISM FLOOD ECO-TOXIC ELEMENTS MINING POISONOUS CONTAMINATION LAND SLIDE ALGAL BLOOMS HUMAN DEVELOPMENT DESTRUCTION OF PIPELINES FIRE INVASIVE SPECIES POLLUTION DESTRUCTION OF PUMP STATIONS EARTHQUAKE ACID DEPOSITION LAND USE CHANGE DESTRUCTION OF FACILITIES DROUGHT NATURAL ELEMENTS OVERFISHING SECURITY GEOLOGIC RADON OVERGRAZING LAND SUBSIDENCE EUTROPHICATION WATER TREATMENT WASTE WATER DISPOSAL PESTICIDE HERBICIDE MERCURY ARSENIC CONTAMINANT TRANSPORTATION Risk Taxonomy for Water Projects-USGS definitions TLO 3 20
- 21. Risk Identification Sample WBS for Wastewater Treatment Plant (PMBOK® Guide) Wastewater Treatment Plant Earlier Phases Design Construction Later Phases Civil Drawings Architectural Drawings Structural Drawings Mechanical Drawings HVAC Drawings Plumbing Drawing Instrumental Drawing Electrical Drawing Headworks Aeration Basin Effluent Pumping Station Air-Handling Building Sludge Station TLO 3 21
- 22. Risk Identification Compare your WBS to your risk taxonomy… Wastewater Treatment Plant Earlier Phases Design Construction Later Phases Civil Drawings Architectural Drawings Structural Drawings Mechanical Drawings HVAC Drawings Plumbing Drawing Instrumental Drawing Electrical Drawing Headworks Aeration Basin Effluent Pumping Station Air-Handling Building Sludge Station NATURAL ENVIRONMENTAL PROCESSES BIOHAZARDS INDUCED SABOTAGE/ TERRORISM FLOOD ECO-TOXIC ELEMENTS MINING POISONOUS CONTAMINATION LAND SLIDE ALGAL BLOOMS HUMAN DEVELOPMENT DESTRUCTION OF PIPELINES FIRE INVASIVE SPECIES POLLUTION DESTRUCTION OF PUMP STATIONS EARTHQUAKE ACID DEPOSITION LAND USE CHANGE DESTRUCTION OF FACILITIES DROUGHT NATURAL ELEMENTS OVERFISHING SECURITY GEOLOGIC RADON OVERGRAZING LAND SUBSIDENCE EUTROPHICATION WATER TREATMENT WASTE WATER DISPOSAL PESTICIDE HERBICIDE MERCURY ARSENIC CONTAMINANT TRANSPORTATION Where they intersect lies risk! TLO 3 22
- 23. Risk Identification E n g in e e r in g S p e c ia lt ie s I n t e g r a t io n a n d T e s t C o d e a n d U n it T e s t D e s ig n R e q u ir e m e n t s P r o d u c t E n g i n e e r i n g W o r k E n v ir o n m e n t M a n a g e m e n t M e t h o d s M a n a g e m e n t P r o c e s s D e v e lo p m e n t S y s t e m D e v e lo p m e n t P r o c e s s D e v e l o p m e n t E n v i r o n m e n t P r o g r a m I n t e r fa c e s C o n t r a c t R e s o u r c e s P r o g r a m C o n s t r a i n t s S o ft w a r e D e v e lo p m e n t R is k TLO 3 23 SEI Taxonomy for Software Development Risk ENVIRONMENTAL RISK OPERATIONAL RISK FINANCIAL RISK EXTERNAL RISK LAND RISK Aesthetics Availability Targets Capital Cost Buy/Build capacity Easements Conservation Communications Compatibility Disposal Costs Construction Market Gravel Supplies Environmental Compliance Control Room/SCADA Economy Equipment Supplies Land Available Distribution Generation Financing Growth Right-of-way Exit Strategy Lease Options Local Forecast Expansion Flexibility Net Present Value Location of Power Needs Facilities Needs Off Market Sales Military Plans Fuels Profit Margin Outsourcing Generation Ramp Rates Rate Impacts Political Leveraging Opportunities Return of Investment Public Input/Acceptance Load Shape/Type Partnerships Regulatory Major Maintenance Schedule Budgeting Security Quality Criteria O&M Labor Weather Reliability Targets Run, repair, retrofit, retire Load Growth Reserve Margins Regulatory requirements Equipment Availability Taxonomy for Risk to Utilities Projects Taxonomy Customized for a Particular Company
- 24. WBS to Schedule relationship dependency relationships between tasks distributed over time according to durations Dream House 1.0 Concrete 2.1 Roofing 2.2 Electrical 2.3 Interior 2.4 Framing 2.5 Plumbing 2.6 Sidewalks 2.1.1 Foundation 2.1.2 Patio 2.1.3 Driveway 2.1.4 Felt 2.2.1 Shingles 2.2.2 Roof Caps & Soffits 2.2.3 Interior Wiring 2.3.1 Outlets & Switches 2.3.2 Service Cable 2.3.3 Fixtures 2.3.4 Cable & Telephone 2.3.5 Walls 2.4.1 Cabinets 2.4.2 Trim 2.4.3 Carpet 2.4.4 Paint 2.4.5 Fixtures & Appliances 2.4.6 Exterior Walls 2.5.1 Interior Walls 2.5.2 Trusses 2.5.3 Sheathing 2.5.4 Roof 2.5.5 Waste Lines 2.6.1 Water Lines 2.6.2 Gas Lines 2.6.3 Fixtures 2.6.4 Project Management 2.7 Architectural Drawing 2.7.1 Permits & Licenses 2.7.2 Loan Processing 2.7.3 Grub the Site 2.7.4 Inspection Signoffs 2.7.5 WBS Tasks Arranged in Network Flow Diagram TLO 3 24
- 25. Risk Identification Requirements Analysis Design Code Test System Implementation User Acceptance TLO 3 25
- 26. Requirements Analysis Design Code Test System Implementation User Acceptance User Briefing Data Prep and Load Prepare Test Environment Write Test Plan User Acceptance Test Component test Integration Test String Test Regression Test Risk Identification TLO 3 26
- 27. Requirements Analysis Design Code Test System Implementation User Acceptance User Briefing Data Prep and Load Prepare Test Environment Write Test Plan User Acceptance Test Component test Integration Test String Test Regression Test Thresh holds and Trigger Points Divergence Convergence Risk Identification TLO 3 27
- 28. Critical Path 1 27 32 21 22 231915 14 13 1812 201711 7 6 5 24 29 2826 25 30 8 9 4 1610 Identify your critical path using CPM TLO 3 28
- 29. Risk Critical Path 1 27 32 21 22 231915 13 1812 201711 29 2826 25 30 8 9 4 24 5 7 6 14 10 16 Identify additional tasks that have technical or resource risks TLO 3 29
- 30. Schedule Metric Explanation 1. Baseline Execution Index (BEI) (# Baseline Tasks Actually Completed) / (# Baseline Tasks Scheduled for Completion) Note that this is DOD Tripwire metric. 2. Critical Path Length Index (CPLI) (Critical Path Duration + Float Duration (to baseline finish)) / (Critical Path Duration) Note that this is DOD Tripwire metric. 3. Leads Are tasks missing Predecessor tasks? 4. Lags Are tasks missing Successor tasks? 5. Logic Does the network diagram have Conditional Loops, Hangers, or many tasks running in parallel? 6. Relationships Are most tasks defined as simple Finish-to-Start dependency relationships? Are there an excessive number of tasks that have other dependencies (i.e., Start-to-Finish, Start-to-Start, Finish-to-Finish)? 7. Constraints Do tasks have constraining dates? An excessive amount of Date Constraints will affect the Logic and Relationships between tasks. 8. Long Durations Do lower level Work Packages have long durations? Work Package durations of more than 30 days make it difficult to assess earned value. 9. High Float Tasks with a high amount of Total Float/Slack. More than a month of float for any task on the Critical Path should generate attention and require an explanation. 10. Negative Float Any task with negative Total Float/Slack should generate attention and require an explanation. 11. Resources Are resources (i.e., Labor, Material, Travel, ODCs, subcontractors) assigned to at least the level of the Control Account (and ideally at Work Package level)? 12. Out of Sequence tasks Are all tasks on the schedule done in the correct technical sequence? Example: does testing logically follow after preliminary design and development? 13. Critical Path Test Can a single critical path be identified? Does the critical path include LOE tasks? 14. Bad dates Do any milestone dates fall outside of the Period of Performance? Are milestone dates tied to a specific deliverable? DCMA 14 Point Schedule AnalysisDCMA 14 Point Schedule Assessment TLO 3 30
- 31. Risk Identification • Do an Assumptions Analysis • Test the logic with an “If….Then” condition statement • Use a Fishbone/Ishikawa root cause analysis TLO 3 31
- 32. Cause and Effect (Ishikawa) Diagram CAUSES EFFECT Time EnvironmentPersonnelMeasurementEnergy MaterialMethodMachine Risk Risk Identification TLO 3 32
- 33. Risk Identification Fishbone Right Angle Tree1. Be sure that everyone agrees on the problem and its effect 2. Be succinct 3. For each node, identify causes and add them to the tree 4. Pursue each line of causality back to its root cause 5. Consider grafting relatively empty branches onto others 6. Consider splitting up overcrowded branches 7. Consider which root causes are most likely to merit further investigation. TLO 3 33
- 34. Risk Identification Is the assumption (????????) valid for (program dimension) with respect to (Who, What, Where, etc.)? TIME COST PERFORMANCE OTHER? WHO WHAT YES WHEN or WHERE NO WHY HOW Performing an Assumptions Analysis TLO 3 34
- 35. Meta-language heuristics Cause Event Effect verb preposition (will, do, are, etc.) (due to, as a result of) Risk Identification Floods will delay due to the at our the start non- availability Mid-west of my of key plant project personnel TLO 3 35
- 36. • The most important discipline of risk management • Use multiple tools to triangulate • Use tools appropriate to your industry and project • Validate/confirm/verify • Identify trigger points or tripwire conditions • Don’t overlook opportunities Risk Identification TLO 3 36
- 37. PMBOK® Guide Risk Management • Management Planning – how to approach, plan, execute • Identification – determine risks that might affect project • Qualitative Risk Analysis – prioritizing for further analysis • Quantitative Risk Analysis – numerically analyzing effect • Risk Response Planning – develop options and actions • Risk Monitoring and Control – track, monitor, execute TLO 5 37
- 38. Risk Analysis Tools • Qualitative – P-I Matrix: rank order relative importance of risks – Weighted Ranking: subjective ranking of risk factors – Mini-Max: subjective ranking of risks – Risk Rating Matrix: subjective ranking of risk factors – Failure Mode and Effects Analysis (FMEA): subjective relationship of variables • Quantitative – Monte Carlo simulation: analysis of risk alternatives based on statistical relationship of variables, e.g., Crystal Ball, ARM, or @Risk. – Program Evaluation and Review Technique (PERT): analysis of schedule risk based on normalized distribution. – Decision Tree Analysis: probabilistic analysis of alternatives – Sensitivity Analysis: probabilistic relationships between program variables TLO 5 38
- 39. Risk Analysis Tools TLO 5 39
- 40. Risk Analysis Tools Risk: CAD Contract award delayed Mitigation Plans: – Source selection process – Well defined selection criteria – Four versions of draft RFP – MS A scheduled for Aug 02 x Schedule Risk #1 Risk: IOC of July 2008 Mitigation Plans: – EVMS – Contract Incentives – Design off-ramps – Need funding stability x Schedule Risk #2 Risk: Cost estimates inaccurate Mitigation Plans: – Better system definition – Fund to CAIG estimate at MS B – Cross-check PO model – CAD Ktr bottoms-up estimate x Cost Risk #1 Risk: Cost Control Mitigation Plans: – CAIV – EVMS – Multi-year procurement – Incentives in SD&D x Cost Risk #2 x Technical Risk #1 Risk: System Integration Mitigation Plans: – JTRS MOA – Modeling/simulation – CAD demonstrations – Interface Control IPTs x Technical Risk #2 Risk: Software development Mitigation Plans: – Software development plan – SEI Level III certification – OPTEVFOR EOA – Independent assessment TLO 5 40
- 41. Level Technical Schedule Cost 1 Minimal Impact Minimal Impact Minimal Impact 2 Minor performance shortfall, same approach retained Additional tasks required, able to meet key dates Development or acquisition cost increase to < 1% 3 Moderate performance shortfall, workarounds Minor Schedule slip, will miss need date without workaround Development or acquisition cost increase to > 1% & < 5% 4 Unacceptable performance but workarounds available Program critical path impact but workarounds available Development or acquisition cost increase to > 5% & < 10% 5 Unacceptable performance and no workarounds available No known way to achieve program milestones Development or acquisition cost increase to > 10% Consequence Level Existing Approach and Process A Not Likely …will effectively avoid or mitigate this risk based on standard practices B Low Likelihood … have usually mitigated this type of risk with minimal oversight in similar cases. C Likely … may mitigate this risk, but workarounds will be required. D Highly Likely … cannot mitigate this risk, but a different approach might. E Near Certainty … cannot mitigate this type of risk; no known processes or workarounds are available Likelihood 1 2 3 4 5 A B C D E Likelihood Consequence Low Medium High FAA Risk Analysis: 5x5 Matrix What is the likelihood the risk will happen? Given the risk is realized, what would be the magnitude of the impact? Risk Analysis Tools TLO 5 41
- 42. Probability-Impact Matrix Risk Score for Specific Risk Probability Risk Score = P X I 0.9 0.05 0.09 0.18 0.36 0.72 0.7 0.04 0.07 0.14 0.28 0.56 0.5 0.03 0.05 0.10 0.20 0.40 0.3 0.02 0.03 0.06 0.12 0.24 0.1 0.01 0.01 0.02 0.04 0.08 0.05 0.10 0.20 0.40 0.80 Impact on an Objective (e.g., cost, time, schedule, or scope) Ratio Scale TLO 5 42
- 43. Qualitative Risk Analysis Source: A Guide to the Project Body of Knowledge, PMBOK® Guide , 4th ed Risk Objective Very Low 0.05 Low 0.10 Moderate 0.20 High 0.40 Very High 0.80 Cost Insignificant increase <10% increase 10%-20% increase 20%-40% increase >40% increase Schedule Insignificant increase <5% increase 5%-10% increase 10%-20% increase >20% increase Scope Change barely noticeable Minor change affected Major change affected Change unacceptable to sponsor Change defines new project Quality Change barely noticeable Minor change affected Major change affected Change unacceptable to sponsor Change defines new project Risk Rating Matrix TLO 5 43
- 44. Probability-Impact Matrix Risk Opportunit ProbabilityorLikelihoodofOccurrence Small Moderate High Moderate Sm all .1 .3 .5 .7 .9 .9 .7 .5 .3 .1 Impact or Consequence HighMediumLow .9.7.5.3.1 Risk Opportunity ProbabilityorLikelihoodofOccurrence Small Moderate High Moderate Small .1 .3 .5 .7 .9 .9 .7 .5 .3 .1 Impact or Consequence HighMediumLow .9.7.5.3.1 TLO 5 44
- 45. Analysis of Risk • Monte Carlo simulation – Analysis of risk alternatives based on statistical relationship of variables – Use a tool, e.g., Crystal Ball, ARM, or @Risk • Sensitivity analysis – Probabilistic in nature – Depends on ability to establish mathematical relationships between program variables • Decision Tree Analysis – Probabilistic in nature – Analysis of alternatives • Program Evaluation and Review Technique (PERT): ‒ Analysis of schedule risk based on normalized distribution. TLO 5 45
- 46. PMBOK® Guide Risk Management • Management Planning – how to approach, plan, execute • Identification – determine risks that might affect project • Qualitative Risk Analysis – prioritizing for further analysis • Quantitative Risk Analysis – numerically analyzing effect • Risk Response Planning – develop options and actions • Risk Monitoring and Control – track, monitor, execute TLO 5 46
- 47. Risk Responses • Avoid – Take action that side-steps or ends the threat – Reorganize the project deliverables, schedule, etc. • Mitigate – Take action that reduces the impact – Establish Management Reserve – Contingency plan or workaround • Transfer – Somebody else pays – Insurance and warranties • Accept – Low probability or small impact – EOCAWKI TLO 5 47
- 48. Risk Mitigation Options A strategy to avert the potential of occurrence and/or consequence by selecting a different approach or by not anticipating in the program. A strategy to shift the risk to another area, such as another requirement, an organization, a supplier, or a stakeholder. The transfer of the risk is accomplished primarily to optimize, in a sense, the overall program risk and to assign ownership to the party most capable of reducing the risk. It is possible that the risk level will change as a result of the risk transfer. A strategy of developing options and alternatives and taking actions that lower or eliminate the risk. A strategy of simply accepting the likelihood/probability and the consequences/impacts associated with a risk's occurrence. Assumption is usually limited to low risks. This is a program/senior management option, not a program option. FAA practice is to develop mitigation plans for all medium and high risks. A mitigation strategy through expanding research and experience. Since risk arises from uncertainty and inexperience, it may be possible to effectively mitigate risk simply by enlarging the knowledge pool, leading to reassessment that reduces the likelihood of failure or provides insight into how to lessen the consequences. Avoidance Transfer Control Assumption Research and Knowledge FAA Risk Mitigation Strategies *National Airspace System (NAS) Systems Engineering Manual - November 2002 – (http://www1.faa.gov/asd/SystemEngineering/index.htm). TLO 5 48
- 49. Management Reserve Budget At Completion Total Project/Contract Budget Time B u d g e t Program Risk-Adjusted Budget = Original Baseline C B A Project/Contract(s) Cost and Schedule Management Reserve Program Cost and Schedule Management Reserve Performance Measurement Baseline Program Risk-adjusted Budget A – Program Schedule B - Risk adjusted schedule C – Project/Contractor schedule • Award Fee • Authorized Unpriced Work • Negotiated Contract Changes TLO 5 49
- 50. Rules of Thumb for Estimating Management Reserve • Low risk = 0-5% of PMB • Moderate risk = 5-15% of PMB • High risk = 15-30% of PMB Estimating Management Reserve TLO 5 50
- 51. Estimating Management Reserve Expected Monetary Value or Expected Value EV = ($ at stake) x (Probability of an event happening) = ($100,000) x ( .3 ) = $30,000 EMV = ($ at stake)x(Probability of an event happening)x(Impact) = ($100,000) x ( .3 ) x (.9) = $27,000 Σ EV or Σ EMV = Amount of dollars for MR TLO 5 51
- 52. PMBOK® Guide Risk Management • Management Planning – how to approach, plan, execute • Identification – determine risks that might affect project • Qualitative Risk Analysis – prioritizing for further analysis • Quantitative Risk Analysis – numerically analyzing effect • Risk Response Planning – develop options and actions • Risk Monitoring and Control – track, monitor, execute TLO 5 52
- 53. Risk Monitoring and Control Risk Register TLO 5 53
- 54. Risk Tracking Form Organization: Project: RISK DESCRIPTION Risk ID: Date Risk Updated: Risk Name: Risk Category: Risk Status: Date Risk Identified: Risk Impact Statement: Warning Flags/Risk Milestones: Related Projects: Related Risks: Background: Comments: RISK ANALYSIS Probable Impact Date: Risk Timeframe: Risk Probability: Overall Risk Impact: Cost Impact Rating: Risk Consequence: Schedule Impact Rating: Risk Priority: Technical Impact Rating: Rank in Program: Compliance and Oversight Rating: Rank in Organization: Mitigation Plan: Rank in Project: Risk Monitoring and Control TLO 5 54
- 55. Intersection of Risk Management to Earned Value Management • Earned Value Metrics –Identify variance with respect to project dimensions of Cost, Schedule, and Performance –Quantify the variance with CPI, SPI •Manage risk at the WBS level of the element of work TLO 5 55
- 56. • Have a sensible, over-arching process that fits your industry and project • Know the tools and use them correctly • Triangulate…when you identify and quantify • Verify and validate • Track it and act on it • Iterate for each major phase of your project Conclusion TLO 2 56
- 57. Contact Information Dr. William G. Chadick, D.M., PMP, EVP, CSSMBB MCR, LLC wchadick@mcri.com www.mcri.com 719-330-0188 57
Notes de l'éditeur
- In the context of integrated program/project management…Risk management is a complementary and supplementary process that occurs alongside Earned Value. Therefore the learning objectives for this class are to provide an overview of risk management as it occurs in the project management framework.
- These are the agenda items that we’ll cover in the next 75 minutes. Discussion is encouraged.
- It is recommended that you have already taken these other modules. We are going to talk about certain tools and processes which I presume that you have more than a passing familiarity with. That is , I am proceeding under the assumption that you know how to do Critical Path Method and Schedule Analysis. And that you understand the Principles of Earned Value Management.
- So we always have to start by defining our terms. Risk can be as the dictionary defines it. However, we really want to work with the PMI definition of risk as our practice standard. The PMBoK definition of risk means that risk has a probabilistic nature. That is , It or may not occur, and there is a probability associated with that uncertainty. If you know for certain that an event is going to occur, its not a RISK.….that’s deterministic in character….rather, its an ISSUE that must be addressed.
- Chapter 11 of the PMBoK and the PMI Risk Management Standard define Risk Management as having these process areas. The process starts with Planning. When we deal with risk we must first have some sort of comprehensive plan of how to manage it. One of the most difficult challenges with risk is identifying it. More on this later. Presuming though, that we can identify risk, then the challenge is to quantify it. We quantify risk using both Qualitative and Quantitative tools. Identification and quantification taken together are often called ASSESSMENT or ANALYSIS. The PMI likes to differentiate however. If you identify and Quantify Risk….then surely you must develop a RESPONSE And you must continuously monitor, revise, update because Risk changes during your project life cycleHaving established what risk and opportunity are….this is how we define the process of managing them. If I don’t say “opportunity” enough…it’s because of the built in bias we all have to deal with the things that will cause our projects to fail.
- So let’s talk about the first component of the PMBoK risk process. That is, having a comprehensive, consistent, logical, process oriented approach to how one should deal with risk. The PMBoK does not prescribe your risk plan, nor the process by which it is developed. Rather, it simply asserts that you must have a planning process. And that your plan, to be complete, must address the functional processes of identification, analysis, response, and monitoring
- Here is a popular process model used by DoD that outlines the components of their Risk management process. The DoD model aligns well with the PMBoK construct of risk. In the DoD model: You can see that it’s a repetitive process flow Emphasis on root cause analysis Risk Management Boards (RMBs) are used Lists various examples of Risks Has a very comprehensive list of references/links There is a focus on strategies to mitigate risks Unfortunately the treatment of Opportunity is not substantive The AT&L Defense Systems Risk Guide is a replacement of the older DAU Risk Management Guide. The new guide does not include the extensive examples that were in the old guide.
- What if you don’t work in DoD? Here’s another process model, proposed by Chapman and Ward. In their risk management process there are nine steps, as depicted here. These nine steps align very closely with the sequential process steps outlined in the PMBOK …plan, identify, quantify, respond, and control/monitor.
- We could go on at some length. There are many more processes. Just pick up any risk book and compare. This could be bewildering Is this OK? To have so much diversity in process? In fact there should be different processes based on the industry, the company, and the nature of the project. This big secret is…..the PMI doesn’t really care what process model you use….as long as your process model has discernible processes that address planning for risk… identifying it….quantifying it….responding to it ….and monitoring and controlling it.
- Later on, as you develop a full fledged Project plan, your level of planning for risk will grow more sophisticated. One of the components of your overall project plan will be a separate Risk Management Plan, also called a Risk Directive in some places. This is what the PMBOK says ought to be addressed in the Risk Management Plan. Discuss individual scenario Discuss the handout Risk management plan, PMBOK and Schuyler Discuss expectations
- Let’s sum up so far. 1st…Have an overall process or methodology 2nd…Have a plan or directive customized for each program or project But also ensure that the process and/or the plan: identifies key people Established boards for review And specifies tools that are pertinent to the project or industry
- The plan and process are important, but anyone who has been in the business a while will tell you that IDENTIFICATION is the single hardest thing to do. So we’ll spend some time on Risk Identification tools.
- So let’s dwell on the process of IDENTIFICATION a bit. When you identify risk in a project…what is it that you want to know about risk? We want to know WHAT the risks are…as discretely as possible. We want to know WHERE the risks could occur….as precisely as possible. And we want to make sure that our analysis gets to the ROOT CAUSE of the risk. We don’t want to chase symptoms….we want to understand the basic cause. Your project is part of a program. Your program is part of the enterprise portfolio of programs. The risk that affects your project or program is likely to affect other projects programs, directly or indirectly.
- Here is a list of some basic identification tools. Risk Breakdown Structure is also known as risk taxonomy….that is…a categorical listing risks that decomposes into increasing detail. …kind of like a WBS. We can do Critical Path, and we can do a concept that leverages off that called Risk Critical Path. Flowchart Analysis takes several forms and is a highly useful visual process tool. A Network Diagram is a flowcharting tool developed by your master scheduler, and is a standard feature of most scheduling tools. Finally, you can use something as simple as checklisting.
- There are some more. The rule is to TRIANGULATE. A single tool may mis-represent a risk; or miss a risk. Verify and validate using multiple identification tools if possible. Where multiple tools coincide,…especially those that use a different approach….you have some sort of risk. But don’t discount if only a single identification establishes a risk. Some tools are better suited in one phase of a project life cycle than others. Example, SWOT is very useful at the start of a developmental project when there is much uncertainty. But as a project proceeds to execution, SWOT is too imprecise and loses utility. The professional risk manager needs to know when tools should be deployed, and what type of information the tools provide.
- So let’s look at one of the most widely used tools ….a Risk Breakdown Structure, or RBS. Max Wideman proposed this popular and simple, generic, one-size-fits-all, model. In this construct, Risks to projects generally fall within one of these five categories (External, Internal, Non-technical, Technical and Legal) Within those five categories Wideman further decomposes the categories of risk. If you have a WBS…using your RBS become easy. &lt;Why? Because you can map the risk in the RBS to the tasks in your WBS.&gt;
- This RBS diagram is very similar to Wideman. This RBS is proposed by Stephen Grey. I like this grouping of risks because it characterizes risks that can lead to risk cancellation called Implementation Risks…versus Product risks that can lead to personal injury or project failure Should you use Wideman’s RBS diagram with 5 major categories and 3 levels of detail…or Grey’s with 4 levels of detail? &lt;What’s the key point or principal? Start somewhere….use an RBS pertinent to your industry if you have one…or select a generic tool and customize it for your industry, company, or project. Then successively define risk in greater detail.&gt;
- Negative events cause us to lose real money, so we tend to focus on them. Opportunities , particularly revolutionary change, is often not fully considered by conventional thinkers. It takes far-sighted visionaries to capitalize on entrepreneurial ideas. Earlier I said that Opportunity is the flip side of Risk Here is a practical example of a taxonomy for Opportunity that can be used alongside the identification that you are doing for risk.
- The previous examples were generic in nature. An industry specific example for planning Water projects is this risk taxonomy that you can get of the USGS web page. It was developed by Sandia National labs for projects that involve water distribution. Point is to customize a risk taxonomy/category diagram /RBS pertinent to your project. Use established industry templates if they are available. So we have moved from a generic, 30,000 foot level RBS, to an industry specific RBS. So how do you use the RBS? Eutrophication = the nature of a substance transforms. Water, H2O, becomes hypoxic, usually attributed to nitrate runoff. Which leads to algae blooms and dead fish.
- Take the WBS structure for your project. Here is a sample WBS for a Waste Water Treatment Plan. It just happens to come from the PMBoK.
- Now lets do some real graduate level work. Take the Risk taxonomy provided by Sandia Labs for Water Distribution and compare it to your Wastewater project WBS. Where they intersect gives you a precise idea of where to consider risk in your project. For example, the sub-tasks under Design are normally not considered to be risky by your SME’s. Notice that the Sandia risk taxonomy does not have any risk events associated with the Design phase. However, there are several risk events or conditions associated with the WBS tasks Construction of the Aeration Basin and the Effluent Pumping Station. What did this tell you?.....To consciously consider the project risk associated with these two events. That is to say….you have identified potential technical risk associated with the Construction of the Aeration Basin and the Effluent Pumping Station.
- What is the SEI? Software Engineering Institute…chartered under Carnegie-Mellon University…and is the leading national, and international, authority for handling software development. Here is the taxonomy used by the SEI to classify risk to software development projects. It decomposes into a fourth level, into 64 discrete risk possibilities. And there is an assessment rating checklist that accompanies this RBS…which allows you to do some qualitative assessment. More on that later. And here is an RBS for Utilities projects. You get the idea by now. &lt;Here’s a neat trick. What if you had two different risk taxonomies to compare to your WBS? You could identify the risk to your software development project using the SEI risk taxonomy, plus perhaps your company unique taxonomy!&gt; &lt;What would the value be with using multiple taxonomies?&gt; CAREFUL: there is not necessarily a one-to-one relationship between your WBS TASKS and risk categories. You must do some interpretation that relates WBS TASKS to RISK categories. And there must be some level of expertise in using the tool.
- OK that’s enough on RBS’s Let’s change identification tools. Another simple, but powerful technique is flowcharting. This slide depicts a process that you ought to be familiar with by now. You should have covered it one of your earlier sessions. This is picture of the process by which we: take the WBS organize the sequence that the WBS tasks occur in then arrange the dependency relationships according to a calendar. Let’s talk about the middle of the process….FLOWCHARTING
- Let’s use the example of a rather well-known, conventional, 6 phase flow chart of the project steps for developing a software product It may be difficult to identify the risk, and opportunity in a software project. So we might begin by convening a brainstorming session with our system design engineer and developers. Our SMEs tell us that one of the riskiest phases of software development is testing. That unexpected things always go wrong. And get discovered by the testers; who send programs back for more development. And thereby keep the design---code---test cycle going endlessly. So lets decompose the TEST phase and see if we can identify risk
- We have our scheduler print the network diagram directly from our schedule tool. The network diagram demonstrates the precedence relationship, in a logical order, of all the tasks defined by the WBS. That is, we took the summary task of testing and decomposed it into the various tasks that comprise test. Understand that every other Summary Task should be similarly decomposed, but we only want focus on test at this point.
- So we call a brainstorming session with our our SMEs and team members, this time focusing on the actual test phase. Probably use some checklists to drive the discussion with them. Checklists were probably derived using our review of the historical documentation, or maybe we used the SEI checklists that correspond to their RBS. We could start by simply identifying points of DIVERGENCE and CONVERGENCE. Places where multiple activities must come together are always points of vulnerability. Places where a single line of control separates into multiple paths is another point of vulnerability. Plus, your SMEs probably told you things like, if the software is going to screwed up, that its going to occur at one of the points indicated. We could call failure at one of these risk points a TRIGGER POINT, and the test conditions would be a THRESH HOLD . These could be expressed as test criteria or as GO-NO GO conditions. Notice that we haven’t quantified anything yet. Haven’t even developed the critical path, yet we can begin to identify where there is risk using this simple flow chart technique.
- So let’s segue way into another flowcharting technique called Critical Path method. You should have taken a session on Critical Path already. So lets just say that you went through the steps to calculate your critical path for the network diagram pictured above. That is: you did your Forward pass, Backward pass, and calculated the Float and ended up with the critical path shown in red. The critical path is by definition, the longest path through the project activities, which represents the shortest time that the project can be completed. You must do all of the tasks on your WBS in order to complete the project. However, identifying the critical path means that certain tasks must be done exactly as planned or a risk to the project schedule will occur. In other words, the tasks that lie on your critical path should be a part of your risk identification. You manage risk by managing your critical path.
- You know that points of divergence and convergence indicate risk….flow chart analysis. And you know by doing an RBS that some WBS tasks have technical risk associated with them. So wouldn’t it be clever to combine the tasks on the Critical Path identified by doing a CPM….with the flow chart analysis…and the RBS! We would call that the collection of tasks the Risk Critical Path. In this example the Risk Critical Path would include: the critical juncture of converging and diverging activities of tasks 5, 6, and 7, and 14 and 15 Or perhaps we identified a single technically risky task like task 24. We might suppose that our analysis turned up a critical inspection, or a test, that must occur for project acceptance. Task 24 might represent such a technical challenge Our risk critical path is to manage 1-2-3-8-12-18-21-27-5-6-7-14-15-24-30.
- Let’s change gears and introduce another risk identification tool. The Master Scheduler should routinely (monthly) analyze the schedule using these DCMA approved dimensions. Dimensions of the schedule assessment that cannot be reconciled indicate risk to the schedule. GAO has a nine point assessment checklist. Some vendors have automated tools that will do a schedule assessment. Even with an automated tool, you still have to apply logic, however, the tool can help narrow the focus. This is especially useful if the schedule is really large. &lt;What is this an example of? Checklisting, a rather sophisticated checklist.&gt;
- So we covered a few of the identification tools (RBS, flowchart, CPM, Checklisting). I’d like to cover them all in detail, plus work some problems. That’s actually part of 40 hour academic course that I teach. But we simply don’t have time in 90 minutes. It’s up to you to do the deep dive and become expert with each tool. If you are a Program manager or an executive you might consider hiring a professional risk manager to do this for you. So let’s suppose that you rigorously employed several different tools to identify the risk in your project. What happens next? You have to confirm that what you identified is valid. There are a couple of useful tools that support the validation process. You could do an analysis of your assumptions. You could use meta-heuristics to test your logic with if …then condition statements. Or you might use a diagramming technique called root cause analysis
- Ishikawa diagram started out as a quality management tool, developed by Kaoru Ishikawa in the 1950’s, but can be used in risk identification. Also called a FAULT TREE or a FISHBONE. Ishikawa was one of the scientist-industrialists who played a key role in the rebuilding of Japanese industry in the 50’s-60’s. Ishikawa was a contemporary of Deming. Ishikawa contributed the concepts of Quality Circles and the Cause & Effect Diagram. He also added two more steps (Training and Planning Method) to Deming’s “Plan-Do-Check-Act cycle.” This is the original diagram developed for manufacturing an industrial product. But there are Root Cause diagrams that are customized to certain industries and processes. Idea is to identify a single risk and then analyze it to confirm that it is a valid risk.
- Drawing this gets really hard. You can go to SMARTDRAW.COM and download a free sample diagram to automate this. Some people prefer to use a right angle tree because its easier to read the tasks. In either case, follow these steps: Be sure that everyone agrees on the problem and its effect Be succinct For each node, identify causes and add them to the tree Pursue each line of causality back to its root cause Consider grafting relatively empty branches onto others Consider splitting up overcrowded branches Consider which root causes are most likely to merit further investigation. Suggest you take a Root cause Analysis class to become comfortable using this tool…as it is not at all simple. And requires some experience to condition each branch correctly.
- Another tool to validate your identification is an assumptions analysis. One method is to compare project dimensions using the most basic dimensions of Time, Cost, Performance…. against….the basic logic questions of who, what , when, where, why, and how. For example. Say you identified project staffing level as a risk. You would ask the question: “Does my project team (WHO) have enough people assigned to complete the project on TIME?” If the answer is NO, then you validated that lack of resources is a true risk to the project. Or, you assess lack of technical expertise as a risk. Do the members of my project team (WHO) have the right skillsets (QUALITY) to ensure technical performance objectives can be met? Yes or No? If the answer is NO, then that validates lack of qualified resources as a risk to the project. Do this for each risk. You can pose this as question or a statement. Just be consistent.
- This is another way to test assumption. Meta-language heuristics refers to the logic by which we construct assumptions about risk. Each assumption about a risk is analyzed to ensure that the cause, event, and effect have logical dependencies. Let’s say you identify season flooding as a risk to your project. Are floods, in fact, a likely or logical risk event for your project? If so…. Would floods actually have an impact on the start of your project? And is… This a result of, or an effect of, not being able to get key people to your project because the roads are impassable? If all three conditions hang together then the assumption…i.e., the risk… is valid. If not, then the assumption is wrong. Perhaps you can substitute a better cause, event, or effect that makes the assumption valid. For example, try Hurricanes instead of Floods for the Midwest. The assumption would not make sense.
- To summarize risk identification. A good project manager is also probably a good risk manager. The tools for risk identification are not hugely sophisticated. But they do require deliberate attention; and rigorous, disciplined use. Risk changes as your project life cycle matures. What is a huge risk at the start may disappear later on….and conversely some risks may be unknown at the start and emerge later…like unexpected technical risks in a project that is using new technology. So you must perform regular risk review boards and deploy multiple tools that are appropriate to the phase and nature of the project. Each tool tells you something different because the logic behind it is based on a different thought process. The tools are largely manual. Automated tools can be helpful for portraying the network diagram or calculating critical path. However the logic that is required to perform risk identification defies automation.
- If we identified risk, the next thing we need to do is quantify it. Quantify it as discretely as possible. Let me re-emphasize a key point., which is the importance of IDENTIFICATION first. Silly, dangerous, misleading to quantify risks that were not identified correctly. You might trip merrily down the path of precisely quantifying something that is not a risk.
- We want our measurement tools to do 2 things: Help assess relative priority or importance by rank ordering Help calculate a value of the risk event in $$$. These are some of the more popular tools. We’ll go over some of them. We have a suite of tools that we typically characterize as being either qualitative or quantitative in nature. The only distinction between a Qualitative versus a Quantitative analysis is the relative degree of certainty or precision in our data. We like certainty so it’s a typical practice to aim for analysis that is relatively more quantitative in character. However, risk is by nature uncertain. Sometimes we can only get in the general ballpark and our analysis is more qualitative in character.
- Here is an example of a P-I Matrix, Probability Impact Matrix that was used in the F-18 fighter program. Using a P-I matrix is a three step process. Construct the matrix diagram that compares a Likelihood (or Probability) against the Consequence (or Impact) Describe what is meant by the rating of probability and impact. Assign a color code to indicate levels of concern.
- Each risk that was identified is subsequently analyzed with respect to the impact on Schedule, Cost, or Technical Performance This allows us to rank order the risks from top to bottom Prioritization is the object of doing a P-I matrix. That is …sorting the risks by what we perceive to be the highest threat….and thereby helping to shape a response. F-18 was a big program. More than just these six risks. &lt;How did something get identified as a risk?&gt; &lt;By using an identification tool such as a RBS for technical risks, or a DCMA checklist for schedule&gt;
- The numbers in a P-I matrix are arbitrary You could use letters, or a combination of letters and numbers as indicated in the FAA version of a P-I matrix. You could construct a 3 by 3 matrix or a 5 by 7 matrix if you don’t like a 5 by 5 construct.
- Or you could associate a particular probability with your P-I matrix. In this case we have indicated to executive management that any Probability-Assessment greater than .18 is a risk to the project---and we ought to do something proactively to lessen the risk---avoid it or mitigate. Anything lower than .05 is not important and we’ll accept the risk. And anything in the .05-.18 range we should closely monitor and consider avoidance or mitigation. As a final tidy step, quantify the PROBABILITY-IMPACT to the organization in terms of Dollars. That is, what is the loss, in dollars or time, if the risk occurs; by multiplying each value times either Dollars or time. This is called EXPECTED VALUE. Example, say the COST of TESTING is $100,000, and probability of risk is .5 and the impact on project cost is .4…..then cross index .5 to .4 , you get .2. Now multiply .2 times 100,00 and the impact of risk in TESTING on the project cost would be $20,000. P-I matrix is widely misused. Many people point to this as their sole risk management process tool. Remember that it only helps you sort priority…it doesn’t identify anything.
- The ordinal rankings used in a P-I matrix don’t mean anything until you describe what happens at each threshold level… that is… the consequences of the risk happening . Compare the consequences against some dimension that is meaningful to your project. If you’re not sure what that dimension might be, you can always start with cost, schedule, scope and quality. But there might be other dimensions unique to your project, company or industry. Warning. One size does not fit all. This table must be thoughtfully reconsidered for each project anew.
- Opportunity is the flip side of Risk . I like this portrayal because it explicitly facilitates the assessment of opportunity. It’s easy to overlook the opportunity when you are up to your neck in alligators . Risks are typically perceived as threats to project success, therefore the possibility of failure gets out attention. However the process of risk identification leads to the prospect of uncovering positive effects. Risk and opportunity share the same tools…and have a symbiotic relationship.
- This chart lists some tools that would be more quantitative in character. Monte Carlo simulation… is a statistical analysis that simulates potential event outcomes by repetitively applying random numbers to multiple variables. The variables are factors that act on the risks that you uncovered during identification. Typically used to assess the viability of a schedule. Each work package is more or less achievable based on the risk embedded in it. Therefore you can get a range of completion dates based on the variability. The power of Monte Carlo is often under-used, because there are more variables than just schedule. …however, defining the algorithm that portrays that complex relationship is hard to do. A Sensitivity Analysis…establishes a probabilistic, algebraic relationship of each single risk to another uncertain element, based on known data and relationships. Decision Tree Analysis…is a diagram that describes a decision, or risk, under consideration and the implications of choosing one or another of the available alternatives. Incorporates probabilities of risk and the cost or rewards of each logical path of events and future decisions. PERT is also used to assess schedule risk. However, it is based on a normalized distribution for each task…not the interplay of multiple variables like Monte Carlo.
- There are a lot of quantitative tools that I did not cover. Did not talk about Weighted ranking, mini-max, PERT or others. One key thing to remember. Identification is more important than quantification. If you improperly identify a risk, then the quantification is a pointless, and possibly dangerous exercise. Nonetheless its good to try to quantify the risk. At the least it allows you to rank order the relative priority; and it also serves as the basis for developing your RESPONSE to the risk. Now on to the next step…if you identified it and quantified it…then you must do something abut it…that is…develop a response to the risk.
- The PMBoK identifies these four actions as the classic responses to dealing with risk. A classic AVOIDANCE strategy is to cancel a project in favor of something less risky. That’s rather drastic. Maybe you can simply re-organize the sequence of events in the schedule. Or maybe you can reorganize the staffing plan. Sometimes you must proceed anyway, so think about MITIGATING the risk by developing a CONTINGENCY plan to work around it. Management reserve is a mitigation strategy Sometimes you can TRANSFER the risk onto another party by purhasing insurance or warranties; or subbing the work to a vendor. The least desirable, but often, unavoidable response strategy is to ACCEPT it. Example, if risk occurs to a task that is not on the critical path then might be able to accept delay to that task
- This is the response strategy that the FAA customized for their agency and industry. They use a slightly different language, but demonstrate consistency with the basic principles with dealing with risk. Assumption is the same as Accept Control is the same as Mitigate. But the FAA adds “Research and Knowledge” as a specific mitigation strategy.
- Management Reserve is classic Mitigation strategy Response. This diagram portrays the concept of Management Reserve. The blue line is the budget if project costs exactly what we planned, that is, the Performance Measurement Baseline . Management reserve is the contingency budget that is set aside by higher management and is not part of the Performance Measurement Baseline. This RESPONSE strategy begins with evaluating the WBS for technical and schedule risk in each WBS element . Each known risk is mitigated internally if possible. Those cost of the risks that cannot be mitigated within the PMB, that is, the Known-Unknowns, are the basis of estimating the management reserve. If a project schedule slips…then there is invariably an impact to cost. Therefore the project schedule must also be analyzed for float/slack or buffer. This level of analysis required to accurately estimate schedule and budget reserve is hard to do. And sometimes we’re moving fast, especially in acquisition projects. So……..it’s not uncommon that …….
- We frequently see Management Reserve developed as Top-Down estimate using rule of thumb instead of detailed, WBS-based, bottoms up calculation….or some of the more precise statistical methods that are available….or some of the probabilistic models (Rayleigh distribution). It’s fingernails on the chalkboard to me….but nonetheless …this is the rule of thumb in much of our project world.
- How much you set aside for Management Reserve is a function of how well you can estimate the risk impact Essentially this is an Expected Monetary Value calculation. Simply put in the EMV (which is probability X cost) for each risk event and total it up. The total amount is what you would strive to create in your contingency reserve; or at least identify to your executive sponsor what you might need. This will help you estimate what you might need. But does not necessarily indicate what you will have available. The best way to estimate your management reserve is by estimating it at the lowest level of the WBS. That is, each element of the WBS has more or less risk associated with that work. We ought to be able to sum the risk that exists at each level of the WBS. An all to frequent practice is to simply SWAG the risk at the top level.
- Communication between team members, stake holders and sponsoring executives is imperative to avoid surprises The process of keeping track of the identified risks, monitoring residual risks and identifying new risk, ensuring the execution of risk plans, and evaluating their effectiveness in reducing risk.
- The Risk Register is the final output of the total process. If you get this far you did good. Don’t start here and work backwards—frequently the downfall of managers who do not understand the risk management methodology. This is one portrayal of the typical elements of a risk register. No school solution on this. Only matters that you catalog all of your work done to date in identifying, quantifying, and responding; A trigger point is the identified state or condition that constitutes a threshhold for taking corrective action. A popular alternative way to view a trigger point is as a GO/NO GO decision. GO/NO GO is the point where certain conditions have to be met in order for the next project phase to proceed. For example, budget approval can be a GO/NO GO decision point. Escalation criteria is employed in a similar manner. At what point, under what conditions, and according to what procedure, do you alert your program manager of a risk that has occurred or is about to occur? Is it time based, $$$ based, or condition based. Furthermore, what is the mechanism to communicate the risk? How high can you escalate if the normal chain of command is not available? Do you notify the next person in the chain, or jump levels immediately. Having a Risk Register constitutes the 90% solution, the terminal deliverable for most project managers. If you can create this, it implies that you have also performed the supporting risk identification processes, the quantitative assessment processes, and the decision-making processes to support the information that you filled into this big spreadsheet. You could customize this matrix to track a variety of other information pertinent to your project risk. Examples include: external points of contact, Recovery Point Objective, reference to Service Level Agreements, reference to Disaster Recovery Plans, etc.
- Some companies prefer a tracking form for each specific risk that you identified and quantified. Nothing wrong with tracking risk using this type of tool. Actually you can use this alongside a risk register. The register becomes a “table of contents” and the risk tracking form has more detail. Common mistake is start here and work backwards. Have often seen a project manager handed this form and told to fill it out, with no idea of all the work that led to this end point in the total process.
- This is an earned value conference, so we ought to establish the relationship of Risk Management to EVMS. This is mostly going to be the topic of the session CPM 600. However, the explicit relationship is that EVMS metrics provide insight into where risk is occurring. That is CPI, SPI, and Variance are concrete metrics that indicate risk with respect to Cost, Schedule, and Performance. Not only that the risk exists, but to which project dimension, and by how much.
- There are some automated tools that will help you do things like Tracking Statistical and probabilistic calculations Simulations But the processes are largely manual and require commonsense application. There is no single silver bullet You want a variety of tools that are based on seeing things different ways.