Project Risk Management
•
42 gostaram•9,270 visualizações
Project Risk Management presentation. Describes the standard process and typical practical implementation.
Recomendados
Mais conteúdo relacionado
Mais procurados
Mais procurados (20)
Destaque
Destaque (20)
Semelhante a Project Risk Management
Semelhante a Project Risk Management (20)
Último
Último (20)
Project Risk Management
- 1. Project Risk Management Oleksa Stelmakh PMP, SBU Manager 04/01/2011
- 2. Risk Management Trainings Page 2 of 50 ProjectRiskManagementbyOleksaStelmakh.SoftServe(c)2011
- 3. Project Risk 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, Quality Page 3 of 50 ProjectRiskManagementbyOleksaStelmakh.SoftServe(c)2011
- 4. Risk Management Objective Increase the probability and impact of positive events Decrease the probability and impact of events adverse to the project Page 4 of 50 ProjectRiskManagementbyOleksaStelmakh.SoftServe(c)2011
- 5. Risk Management Process Risk Management Planning Risk Identification Qualitative Risk Analysis Quantitative Risk Analysis Risk Response Planning Risk Monitoring and Control Page 5 of 50 ProjectRiskManagementbyOleksaStelmakh.SoftServe(c)2011
- 6. Risk Management Planning Page 6 of 50 ProjectRiskManagementbyOleksaStelmakh.SoftServe(c)2011
- 7. Risk Management Planning: Outputs Methodology Roles and responsibilities Timing Risk categories (RBS) Definitions of risk probability and impact Probability and impact matrix Page 7 of 50 ProjectRiskManagementbyOleksaStelmakh.SoftServe(c)2011
- 8. Type of Risks Technical Resource Personnel Communications Legal & Regulatory Force Majeure Page 8 of 50 ProjectRiskManagementbyOleksaStelmakh.SoftServe(c)2011
- 9. Risk Breakdown Structure (RBS) Technical Requirements Technology Performance Quality External Subcontractors Regulatory Market Customer Organizational Dependencies Resources Funding Prioritization Project Management Estimating Planning Controlling Communication Page 9 of 50 ProjectRiskManagementbyOleksaStelmakh.SoftServe(c)2011
- 10. Risk Impact Definition Project Objective Very low /.05 Low /.10 Moderate /.20 High /.40 Very high /.80 Cost Insignificant cost increase <10% cost increase 10-20% cost increase 20-40% cost increase >40% cost lincrease Time Insignificant time increase <5% time increase 5-10% time increase 10-20% time increase >20% time increase Scope Scope decrease barely noticeable Minor areas of scope affected Major areas of scope affected Scope/Quality reduction unacceptable to sponsor Project end item is effectively uselessQuality Quality degradation barely noticeable Only very demanding applications are affected Quality reduction requires sponsor approval Page 10 of 50 ProjectRiskManagementbyOleksaStelmakh.SoftServe(c)2011
- 11. Risk Identification Page 11 of 50 ProjectRiskManagementbyOleksaStelmakh.SoftServe(c)2011
- 12. Risk Identification Forms Checklist Sticky Notes Prompt list (RBS) Historical records Pre-mortem Brainstorming Affinity Diagrams Expert interview Nominal group interview Delphi technique Fishbone technique SWOT Page 12 of 50 ProjectRiskManagementbyOleksaStelmakh.SoftServe(c)2011
- 13. Identification Order • Brainstorming • Interview • Delphi Step-1 • Historical records • RBS • Checklist, forms Step-2 • Pre-mortem • Affinity Diagram • Other Step-3 When to stop? Page 13 of 50 Do it until it seems stupid ProjectRiskManagementbyOleksaStelmakh.SoftServe(c)2011
- 14. Risk Identification: Outputs Risk Register List of identified risks List of potential responses Root causes of risk Updated risk categories Page 14 of 50 ProjectRiskManagementbyOleksaStelmakh.SoftServe(c)2011
- 15. Qualitative Analysis Impact High-High High Medium Low Low-low 100% 80% 60% 40% 20% Probability High-high 85% 0.85 0.68 0.51 0.34 0.17 High 65% 0.65 0.52 0.39 0.26 0.13 Medium 45% 0.45 0.36 0.27 0.18 0.09 Low 25% 0.25 0.20 0.15 0.10 0.05 Low-low 5% 0.05 0.04 0.03 0.02 0.01 Page 15 of 50 ProjectRiskManagementbyOleksaStelmakh.SoftServe(c)2011
- 16. Quantitative Analysis Page 16 of 50 ProjectRiskManagementbyOleksaStelmakh.SoftServe(c)2011
- 17. Quantitative Analysis: Expected Monetary Value Risk Name Type Probability Cost Impact EMV Risk 1 Threat 30% $10,000 $3,000 Risk 2 Threat 20% $5,000 $1,000 Risk 3 Threat 80% $2,500 $2,000 Risk 4 Threat 15% $20,000 $3,000 Risk 5 Threat 20% $2,500 $500 Risk 6 Opportunity 5% -$20,000 -$1,000 Risk 7 Opportunity 50% -$10,000 -$5,000 Contingency Reserve $3,500 Cost of Activities Contingency Reserve Management Reserve Project Budget Page 17 of 50 ProjectRiskManagementbyOleksaStelmakh.SoftServe(c)2011
- 18. Quantitative Analysis: Decision Tree Net Path Value Chance Node Chance Node Decision Node Decision Definition Build or Upgrade? Invest 120K 65% Reward 200K 52K 35% Reward 80K -14K Invest 50K 65% Reward 100K 33K 35% Reward 80K 11K Page 18 of 50 ProjectRiskManagementbyOleksaStelmakh.SoftServe(c)2011
- 19. Quantitative Analysis: Decision Tree Cost Reward Net Path Net Path EMV EMV Build -$120 Strong demand 65% $200 $80 $52 $38 Weak demand 35% $80 -$40 -$14 Upgrade -$50 Strong demand 65% $100 $50 $33 $43 Weak demand 35% $80 $30 $11 Page 19 of 50 ProjectRiskManagementbyOleksaStelmakh.SoftServe(c)2011
- 20. Quantitative Analysis: Monte Carlo Simulation Estimate Distribution 0.0% 20.0% 40.0% 60.0% 80.0% 100.0% 20.0 25.0 30.0 35.0 40.0 45.0 50.0 55.0 60.0 65.0 70.0 75.0 80.0 85.0 90.0 95.0 100.0 105.0 110.0 115.0 120.0 Cumulative Estimate Probability Prob. Est. 50% 70.00 75% 72.50 90% 77.50 95% 80.00 98% 82.50 99% 82.50 100% 120.00 Task Optimistic (0%) Pessimistic (100%) Task-1 1 6 Task-2 1 6 Task-3 1 6 Task-4 1 6 Task-5 1 6 Task-6 1 6 Task-7 1 6 Task-8 1 6 Task-9 1 6 Task-10 1 6 Task-11 1 6 Task-12 1 6 Task-13 1 6 Task-14 1 6 Task-15 1 6 Task-16 1 6 Task-17 1 6 Task-18 1 6 Task-19 1 6 Task-20 1 6 Total 20 120 Page 20 of 50 ProjectRiskManagementbyOleksaStelmakh.SoftServe(c)2011
- 21. PERT Estimation Optimistic Most Likely Pessimistic Activity Name Optimistic Cost Most Likely Cost Pessimistic Cost PERT Cost Activity-1 2 3 5 3.17 Activity-2 7 10 15 10.33 Activity-3 10 12 20 13.00 Activity-4 15 20 30 20.83 Activity-5 1 2 6 2.50 Activity-6 2 2 5 2.50 Activity-7 3 4 6 4.17 Total 40 53 87 56.50 Page 21 of 50 ProjectRiskManagementbyOleksaStelmakh.SoftServe(c)2011
- 22. Risk Response Planning Page 22 of 50 ProjectRiskManagementbyOleksaStelmakh.SoftServe(c)2011
- 23. Risk Response Strategies PMBok PRINCE2 T-like Other Options Opportunities Avoidance Prevention Tolerate Exploit Mitigation Reducuction Terminate Control Enhance Transfer Transference Transfer Allocate Share Accept Acceptance Treat Accept -Active (Contingent strategy) Contingency -Pasive Avoid Transfer Mitigate Accept Active (Contingency) Passive (Do Nothing) Page 23 of 50 ProjectRiskManagementbyOleksaStelmakh.SoftServe(c)2011
- 24. Risk Response Planning Avoid Transfer Mitigate Accept Active (Contingency) Passive (Do Nothing) Page 24 of 50 ProjectRiskManagementbyOleksaStelmakh.SoftServe(c)2011 Mitigation or Contingency Risk Response owner Several options
- 25. Risk Management Process Long list of risks identified Short List (Qualitative & Quantitative) Risks eliminated by plan change Probability and impact reduced by plan change Residual risks Additional watchlist items Contingenc y plan Fallback plan Secondary risks Watchlist Risk Register Time & Cost Reserve Final Plan Monitoring & Control Page 25 of 50 ProjectRiskManagementbyOleksaStelmakh.SoftServe(c)2011
- 26. Risk Responses: Reserves Calculation Percent Guess EMV Monte Carlo Simulation Cost of Activities Continge ncy Reserve Managem ent Reserve Project Budget Critical path duration Continge ncy Reserve Managem ent Reserve Project Schedule Page 26 of 50 ProjectRiskManagementbyOleksaStelmakh.SoftServe(c)2011
- 27. Mitigation vs. Contingency vs. Recovery Planning Risk Management Accepting Risks Page 27 of 50 ProjectRiskManagementbyOleksaStelmakh.SoftServe(c)2011
- 28. Mitigation vs. Contingency vs. Recovery If contingency plans cost money, why shouldn't we just wait and see which problems arise? Mitigation, Contingency Recovery Recovery costs usually greatly outweighs… Page 28 of 50 ProjectRiskManagementbyOleksaStelmakh.SoftServe(c)2011
- 29. Strategies for Recovery Re-sequencing the project Adding resources Changing the scope Changing the approach Page 29 of 50 ProjectRiskManagementbyOleksaStelmakh.SoftServe(c)2011
- 30. Exercise: Mitigation vs. Contingency Mitigation vs. Contingency? 1. Unit integration early in the project; 2. Load test early in the project; 3. Rotating tasks among developers; 4. Buying more powerful server then actually needed; 5. Prototyping; 6. Peer code review; 7. Making sure there is an alternative way of integrating decoupled systems; Page 30 of 50 ProjectRiskManagementbyOleksaStelmakh.SoftServe(c)2011
- 31. Mitigation vs. Contingency Mitigation 1. Unit integration early in the project; 2. Load test early in the project; 5. Prototyping; 6. Peer code review; Contingency 3. Rotating tasks among developers; 4. Buying more powerful server then actually needed; 7. Making sure there is an alternative way of integrating decoupled systems; Page 31 of 50 ProjectRiskManagementbyOleksaStelmakh.SoftServe(c)2011
- 32. Risk Monitoring and Control ONGOING PROCESS for the life of the project Identifying, analyzing, planning for new Reanalyzing existing Monitoring triggers for contingency Monitoring residual Page 32 of 50 ProjectRiskManagementbyOleksaStelmakh.SoftServe(c)2011
- 33. Risk Management: Quiz • Mitigation • Transfer • Acceptance • Avoidance 1. “Limitations” and “Out of scope” sections of project proposal are examples of risk • Quantitative basis • Numerical basis • Qualitative basis • Econometric basis 2. You are finding it difficult to evaluate the exact cost impact of risks. You should evaluate on a(n) • A list of risks • A list of triggers • A list of the risk response owners • An understanding of project risks 3. Which of the following is the BEST way to describe the outputs of risk identification? • Risk identification • Qualitative risk analysis • Risk response planning • Risk monitoring and control 4. What risk management process MOST affects the project management plan? Page 33 of 50 ProjectRiskManagementbyOleksaStelmakh.SoftServe(c)2011
- 34. Risk Management: Quiz • Mitigation • Transfer • Acceptance • Avoidance 1. “Limitations” and “Out of scope” sections of project proposal are examples of risk • Quantitative basis • Numerical basis • Qualitative basis • Econometric basis 2. You are finding it difficult to evaluate the exact cost impact of risks. You should evaluate on a(n) • A list of risks • A list of triggers • A list of the risk response owners • An understanding of project risks 3. Which of the following is the BEST way to describe the outputs of risk identification? • Risk identification • Qualitative risk analysis • Risk response planning • Risk monitoring and control 4. What risk management process MOST affects the project management plan? Page 34 of 50 ProjectRiskManagementbyOleksaStelmakh.SoftServe(c)2011
- 35. The End of Part-1. Questions? Page 35 of 50 ProjectRiskManagementbyOleksaStelmakh.SoftServe(c)2011
- 36. Part 2 Typical Risk Management Errors Risk Management in Scrum Risk Management at SoftServe Page 36 of 50 ProjectRiskManagementbyOleksaStelmakh.SoftServe(c)2011
- 37. Typical Error #1 Project is estimated long BEFORE risks to the project are discussed Plan Scope Plan Schedule Plan Budget Contract Sign-off Plan Risks Plan Scope Plan Schedule Plan Budget Plan Risks & Reserve Contract Sign-off Page 37 of 50 ProjectRiskManagementbyOleksaStelmakh.SoftServe(c)2011
- 38. Typical Error #2 Risk identification happens only once before performance appraisal during project planning Risk Identification Risk Identification Risk Identification Risk Identification Page 38 of 50 ProjectRiskManagementbyOleksaStelmakh.SoftServe(c)2011
- 39. Typical Error #3 Risks are not identified using the cause-risk-effect format Cause Risk Effect Code quality produced by the team is insufficient Cause Risk Effect Due to lack of code review, pair programming, code inspections tools and junior project staff there were few cases of poor code inspected What means that overall code quality may be insufficient Causing huge number of defects causing rework and project delays Page 39 of 50 ProjectRiskManagementbyOleksaStelmakh.SoftServe(c)2011
- 40. Well-Defined Risks Page 40 of 50 ProjectRiskManagementbyOleksaStelmakh.SoftServe(c)2011 EVENT may occur, causing IMPACT If CAUSE, EVENT may occur, leading to EFFECT
- 41. Typical Error #4 The risks identified are general rather than specific Cause Risk Effect Communication issues Cause Risk Effect Due to time difference and just 1h of overlapping Requirements clarifications may not always be completed with PO Causing delay and reworks impacting the schedule Due to team co- location User story and acceptance may be not documented in details Saving extra project time Page 41 of 50 ProjectRiskManagementbyOleksaStelmakh.SoftServe(c)2011
- 42. Typical Error #5 Some things considered to be risks are not uncertain; they are facts, and are therefore not risks Cause Risk Effect There is no access to Hyland environment Continuous integration is missing on the project Lack of EMS knowledge Team Reduction Team member will be leaving for a maternity leave Requirements are unclear Requirements are unstable Junior project staff Page 42 of 50 ProjectRiskManagementbyOleksaStelmakh.SoftServe(c)2011
- 43. Different Fruits Work Package, Task, Defect Action Item Risk Assumptions, Decisions, Risks, Issues, Action items, Next Steps, Opportunities (ADRIANO) Page 43 of 50 ProjectRiskManagementbyOleksaStelmakh.SoftServe(c)2011
- 44. Typical Errors Page 44 of 50 ProjectRiskManagementbyOleksaStelmakh.SoftServe(c)2011 6. Whole categories of risks missed 7. Too brief list during risk identification 8. Team not familiar with risk management 9. Opportunities are not identified 10. Only estimation risks are managed 11. Sole person (usually PM) is doing whole risk management
- 45. Risk Management in Scrum Does Scrum encompass Risk Management process? Page 45 of 50 ProjectRiskManagementbyOleksaStelmakh.SoftServe(c)2011
- 46. Risk Management in Scrum Scrum itself covers majority of project risks Scrum does not automatically mean complete risk management process Release Planning Sprint Planning Sprint Demo Daily Scrums Scrum of Scrums Retrospective Page 46 of 50 ProjectRiskManagementbyOleksaStelmakh.SoftServe(c)2011
- 47. Thank You! Page 47 of 50 ProjectRiskManagementbyOleksaStelmakh.SoftServe(c)2011
Notas do Editor
- A risk may have one or more causes and, if it occurs, one or more impacts. For example, a cause may be requiring an environmental permit to do work, or having limited personnel assigned to design the project. The risk event is that the permitting agency may take longer than planned to issue a permit, or the design personnel available and assigned may not be adequate for the activity. If either of these uncertain events occurs, there may be an impact on the project cost, schedule, or performance. Risk conditions could include aspects of the project’s or organization’s environment that may contribute to project risk, such as poor project management practices, lack of integrated management systems, concurrent multiple projects, or dependency on external participants who cannot be controlled.
- Risk Management PlanningDeciding how to approach, plan, execute Risk IdentificationDetermining which risks might affect the project and documenting their characteristicsQualitative Risk AnalysisPrioritizing risks for subsequent further analysis or action by assessing and combining their probability of occurrence and ImpactQuantitative Risk AnalysisNumerically analyzing the effect on overall project objectives of identified risksRisk Response PlanningDeveloping options and actions to enhance opportunities & reduce threats to project objectivesRisk Monitoring and ControlTracking identified risks, Monitoring residual risks, Identifying new risks, Executing risk response plans, Evaluating their effectiveness throughout the project life cycle
- Risk Management Planning is the process of deciding how to approach and conduct the risk management activities for a project. Planning of risk management processes is important to establish an agreed-upon basis for evaluating risks. The Risk Management Planning process should be completed early during project planning.
- 1 Risk Management Plan: Output - The risk management plan describes how risk management will be structured and performed on the project. Methodology - Defines the approaches, tools, and data sources that may be used to perform risk management on the project.Roles and responsibilities - Defines the lead, support, and risk management team membership for each type of activity in the risk management plan, assigns people to these roles, and clarifies their responsibilities.Budgeting - Assigns resources and estimates costs needed for risk management for inclusion in the project cost baseline.Timing - Defines when and how often the risk management process will be performed throughout the project life cycle, and establishes risk managementactivities to be included in the project schedule.Risk categories - A risk breakdown structure (RBS) is one approach to providing such a structure, but it can also be addressed by simply listing the various aspects of the project. Definitions of risk probability and impact (by type of objective!!!) -“very unlikely”, “almost certainty”; general scale (e.g., 0.1, 0.3, 0.5, 0.7, 0.9)Probability and impact matrixRevised stakeholders’ tolerancesReporting formatsTracking
- TechnicalResource Uncertainty about whether materials, equipment and services will be available on time and at the expected level of qualityPersonnel Turnover, Cross-trained teamCommunicationsLegal & RegulatoryForce Majeure Events over which you have no control
- Different RBS for different projectsRBS for:PMIndustryCompanyDepartmentProject
- QUANTITATIVE RISK ANALYSIS IS USUALLY IS NOT REQUIRED IN RM PROCESS! Prioritize identified risks for further action Rapid and cost-effective Foundation for Quantitative Risk Analysis Should be revisited during the project’s life cycleQualitative Risk Analysis includes methods for prioritizing the identified risks for further action. Definitions of the levels of probability and impact, and expert interviewing, can help to correct biases that are often present in the data used in this process. Qualitative Risk Analysis is usually a rapid and cost-effective means of establishing priorities for Risk Response Planning, and lays the foundation for Quantitative Risk Analysis, if this is required. Qualitative Risk Analysis should be revisited during the project’s life cycle to stay current with changes in the project risks.
- Risk RegisterList of identified risksThe identified risks, including their root causes and uncertain project assumptions, are described. Risks can cover nearly any topic, but a few examples include the following: A few large items with long lead times are on critical path. There could be a risk that industrial relations disputes at the ports will delay the delivery and, subsequently, delay completion of the construction phase. Another example is a project management plan that assumes a staff size of ten, but there are only six resources available. The lack of resources could impact the time required to complete the work and the activities would be late. List of potential responsesPotential responses to a risk may be identified during the Risk Identification process. These responses, if identified, may be useful as inputs to the Risk Response Planning process.Root causes of riskThese are the fundamental conditions or events that may give rise to the identified risk.Updated risk categoriesThe process of identifying risks can lead to new risk categories being added to the list of risk categories. The RBS developedin the Risk Management Planning process may have to be enhanced or amended, based on the outcomes of the Risk Identification process.
- The number of risks should be hugeYou should not create mitigation/contingency for all of themWatch-listAccept: contingency reserveQualitative Risk Analysis includes methods for prioritizing the identified risks for further action. Definitions of the levels of probability and impact, and expert interviewing, can help to correct biases that are often present in the data used in this process. Qualitative Risk Analysis is usually a rapid and cost-effective means of establishing priorities for Risk Response Planning, and lays the foundation for Quantitative Risk Analysis, if this is required. Qualitative Risk Analysis should be revisited during the project’s life cycle to stay current with changes in the project risks.
- QUANTITATIVE RISK ANALYSIS IS USUALLY IS NOT REQUIRED IN RM PROCESS! Prioritize identified risks for further action Rapid and cost-effective Foundation for Quantitative Risk Analysis Should be revisited during the project’s life cycleQualitative Risk Analysis includes methods for prioritizing the identified risks for further action. Definitions of the levels of probability and impact, and expert interviewing, can help to correct biases that are often present in the data used in this process. Qualitative Risk Analysis is usually a rapid and cost-effective means of establishing priorities for Risk Response Planning, and lays the foundation for Quantitative Risk Analysis, if this is required. Qualitative Risk Analysis should be revisited during the project’s life cycle to stay current with changes in the project risks.
- Known UnknownUnknown Unknown
- Risk Management Planning is the process of deciding how to approach and conduct the risk management activities for a project. Planning of risk management processes is important to establish an agreed-upon basis for evaluating risks. The Risk Management Planning process should be completed early during project planning.
- Risk response owner…AvoidChanging the project management plan to eliminate the threat posed by an adverse risk, to isolate the project objectives from the risk’s impact (F. e.: clarifying requirements)Transfer (Insurance, Contracts, cost-type contract)Mitigate(пом'якшувати)(Prototyping, Early Integration, Unit testing)AcceptancePassive (no action) vs Active (contingency reserve)4 Contingent Response Strategy - alternative strategiesSome responses are designed for use only if certain events occur-------------------------------------------------------------------------------------------------------ExploitThis strategy may be selected for risks with positive impacts wherethe organization wishes to ensure that the opportunity is realized. Thisstrategy seeks to eliminate the uncertainty associated with a particular upsiderisk by making the opportunity definitely happen. Directly exploitingresponses include assigning more talented resources to the project to reducethe time to completion, or to provide better quality than originally planned.ShareSharing a positive risk involves allocating ownership to a third partywho is best able to capture the opportunity for the benefit of the project.Examples of sharing actions include forming risk-sharing partnerships, teams,special-purpose companies, or joint ventures, which can be established withthe express purpose of managing opportunities.EnhanceThis strategy modifies the “size” of an opportunity by increasingprobability and/or positive impacts, and by identifying and maximizing keydrivers of these positive-impact risks. Seeking to facilitate or strengthen thecause of the opportunity, and proactively targeting and reinforcing its triggerconditions, might increase probability. Impact drivers can also be targeted,seeking to increase the project’s susceptibility to the opportunity.
- Developing options and determining actions to reduce threats to the project’s objectives Identification and assignment of the “risk response owner” Addresses the risks by their priority Selecting the best risk response from several options
- Long list of risks identifiedShort ListRisks eliminated by plan changeProbability and impact reduced by plan changeResidual risksAdditional watchlist itemsContingency planFallback planSecondary risksWatchlist-------------------------------------1 Risk Register (Updates)2 Project Management Plan (Updates)The project management plan is updated as response activities are added after review and disposition through the Integrated Change Control. Risk response strategies, once agreed to, must be fed back into the appropriate processes in other Knowledge Areas, including the project’s budget and schedule.3 Risk-Related Contractual AgreementsContractual agreements, such as agreements for insurance, services, and other items as appropriate, can be prepared to specify each party’s responsibility for specific risks, should they occur.
- PMI defines mitigation as, "Taking steps to lessen risk by lowering the probability of a risk event's occurrence, or reducing its effect should it occur." Contingency planning is, "The development of a management plan that identifies alternative strategies to be used to ensure project success if specified risk events occur." Recovery is the process of dealing with a risk event after it has occurred. Recovery is the only response to unforeseen risk events, and it may be a strategy that is consciously chosen when the cost of mitigation or contingency is prohibitively high.
- From a business perspective, mitigation and contingency differ from recovery in a very fundamental way. They cost money upfront. They are like buying an insurance policy. For example, let's say a part of your contingency plan is to buy a backup server in case your main server fails. You've paid for that server whether or not the failure occurs.Project Managers need to make their clients and sponsors aware that CONTINGENCY PLANNING ISN'T FREE. After a risk management plan is developed, the project budget must be adjusted to cover the cost of the selected contingency and mitigation plans. If contingency plans cost money, why shouldn't we just wait and see which problems arise? Because the cost of recovery usually greatly outweighs the cost of mitigation or contingency. When you develop the risk management plan for your project, you'll be comparing the costs of contingency and recovery for each of the risks you identified.
- Re-sequencing the projectworks at the beginning and middle of the project. Towards the end there probably aren't many tasks to move around.Adding resourcescan be helpful during any phase of the project. Of course it is important to be mindful of the law of diminishing returns. If you wait until the last minute to try to recover, throwing resources at the project won't fix it. Changing the scopecan be applied during any phase of the project. If you realize you've bitten off more than you can chew, you can renegotiate with the customer to focus on the most important features and functions. Changing the approachto the project can usually only be done successfully at the beginning of the project. If your initial prototypes are dismal failures, you'll want to rethink your overall strategy. If you are forced to completely change your approach at the middle or end of the project, you'll probably be subject to significant overruns.
- Risk Monitoring and Control is the process ofidentifyinganalyzingplanning for newly arising risks keeping track of the identified risks and those on the watchlistreanalyzing existing risks monitoring trigger conditions for contingency plans monitoring residual risks reviewing the execution of risk responses while evaluating their effectiveness.IS an ONGOING PROCESS for the life of the projectRisk Monitoring and Control caninvolve choosing alternative strategiesexecuting a contingency or fallback plantaking corrective actionmodifying the project management plan1 Risk ReassessmentProject risk reassessments should be regularly scheduled2 Risk AuditsRisk audits examine and document the effectiveness of risk responses in dealing with identified risks4 Technical Performance MeasurementAccomplishments VS. plan5 Reserve Analysis… to determine if the remaining reserve is adequate6 Status Meetings… agenda item6 SoftServe Project Status Dashboard
- Project is estimated long BEFORE risks to the project are discussedRisk identification happens only once during project planningRisks are not identified using the cause-risk-effect formatThe risks identified are general rather than specificSome things considered to be risks are not uncertain; they are facts, and are therefore not risksWhole categories of risks missedToo brief list during risk identificationTeam not familiar with risk managementOpportunities are not identifiedOnly estimation risks are managed
- Project is estimated long BEFORE risks to the project are discussed.Risk identification is completed without knowing enough about the project.
- EVENT may occur, causing IMPACTor If CAUSE, EVENT may occur, leading to EFFECT
- (e.g., "communications" rather than "poor communication of customer's needs regarding installation of system Z could cause two weeks of rework").
- Whole categories of risks (such as technology, cultural, marketplace, etc.) are missedRisk identification ends too soon, resulting in a brief list (20 risks) rather than an extensive list (hundreds of risks).Project managers do not explain the risk management process to their team during project planning