1 / 38

Managing Project Risk

Managing Project Risk. Assessing the project. What is risk?. A Risk is characterised by the combination of the probability that a program or project will experience an undesired event and the consequences, impact, or severity of the undesired event, were it to occur. What is risk?.

Faraday
Télécharger la présentation

Managing Project Risk

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. Managing Project Risk Assessing the project

  2. What is risk? A Risk is characterised by the combination of the probability that a program or project will experience an undesired event and the consequences, impact, or severity of the undesired event, were it to occur

  3. What is risk? Risk always involves the probability that an undesired event will occur Risk should consider the impact of the event should it occur Risk = Probability x Impact

  4. Risks and Risk Management • Risks and rewards go hand in hand • Undertaking a project that promises any sort of reward almost always entails risk • A risk is a problem that has yet to occur; a problem is a risk that has already materialised • Risk management is a process of anticipating problems and minimising their impact • But . . . If your corporate culture won’t allow people to admit uncertainty, you can’t do risk management

  5. Risk Management & Project Management Project Management

  6. Risk Management Approaches Proactive Risk Management: the process of assessing continuously what can go wrong, determining what risks are important, their impact, and implementing a strategy to deal with those risks

  7. Risk Management Approaches Reactive risk management: This risk management approach is better known as crisis management or putting out fires. This type of risk management almost always negatively affects the project’s schedule, cost and quality. In addition, process improvement opportunities are ignored – fire fighting has priority

  8. Risk comes from all aspects of the job

  9. Risk Management An organised, systematic decision making process that efficiently identifies, analyses, plans, tracks, controls, Communicates, and documents risk to increase the likelihood of achieving program/project goals

  10. Risk Management Cycle Risk Monitoring Risk Identification Risk Handling Risk Analysis

  11. Risk Management Process • Step 1: Risk Identification • Step 2: Risk Assessment • Step 3: Risk Response Development • Contingency Planning • Contingency Funding • Step 4: Risk Response Control • Change Control Management • Summary

  12. Risk Management Process

  13. Risk Management Process

  14. Risk Management Process

  15. Risk Management Process The chances of a risk event occurring e.g. • Time estimate • Cost estimate • Design error are greater in the concept, planning & start-up phases of the project

  16. Risk Event Graph

  17. Risk Identification Business risk – Market risk – Shifts in business strategy or senior management Technical risk – Design and development problems – Testing and maintenance problems – Technical uncertainty Project risk – Budget – Schedule – Personnel – Requirements problems

  18. Tools for identifying risk • Checklists (e.g., Boehm’s top ten risk list) • Frameworks (e.g., McFarlan’s framework) • Questionnaires (e.g., Barki, Rivard – IT industry, and Talbot survey – Health Service)

  19. Boehm’s Top Ten Risks • Personnel Shortfalls: Staffing with top talent; job matching; team-building; morale-building; cross-training; pre-scheduling key people. • Unrealistic Schedules and Budgets: Detailed, multi-source cost and schedule estimation; design to cost; incremental development; software reuse; requirements scrubbing. • Developing the wrong functions & properties: Organisational analysis; mission analysis; operational concept formulation; user surveys; prototyping; early users’ manuals. • Developing the wrong user interface: Prototyping; scenarios; task analysis. • Gold-plating. Requirements scrubbing: prototyping; cost-benefit analysis; design to cost. • Continuing stream of requirements changes: High change threshold; information-hiding; incremental development (defer changes to later increments). • Shortfalls in externally-performed tasks: Reference-checking; pre-award audits; award-fee contracts; competitive design or prototyping; team-building. • Shortfalls in externally-furnished components: Benchmarking; inspections; reference checking; compatibility analysis. • Real-time performance shortfalls: Simulation; benchmarking; modelling; prototyping; instrumentation; tuning. • Straining computer science capabilities: Technical analysis; cost-benefit analysis; prototyping; reference checking.

  20. McFarland Framework 1981

  21. Risk Factors • Technological newness • Application size • Application complexity • Task complexity • Project team expertise • Organisational environment • Magnitude of potential loss Barki, Rivard, and Talbot, 1993

  22. Risk Exposure • Risk exposure = probability x impact • Probability refers to the chances that a risk will materialise • Impact refers to the magnitude of potential loss should a risk materialise and is often • measured in £’s • E.G. Three mile island

  23. Risk Analysis • For each identified risk, evaluate the probability of occurrence • For each identified risk evaluate the impact if the risk should occur • Prioritise your risk handling effort based on both probability and impact

  24. Assigning Probabilities • What is the likelihood that something will go wrong? • Establish a scale that reflects the perceived likelihood of a risk – Probability scales are commonly used – Can be qualitative or quantitative e.g. highly improbable, improbably, moderate, likely, highly likely 0-100% probability

  25. Scale of Probability

  26. Assessing Impact • What is the damage or impact if something does go wrong? • Three factors can be used to assess impact – Nature of the risk (i.e. the problems that are likely if it occurs) – Scope of the risk (i.e. how serious is the risk and how much of the project will be affected?) – Timing of the risk (i.e. when and for how long will the impact be felt)

  27. Evaluation of Impact

  28. Risk matrix

  29. Risk Handling • Risk avoidance – Don’t do the project or the part of the project that entails the risk • Risk containment – Containment involves setting aside sufficient time and money to pay for it, should it materialise • Risk reduction and risk prevention – Obtaining additional information that will reduce risk (e.g. prototyping, incremental development), or developing options to reduce the potential of the problem occurring • Risk mitigation – Taking steps before a risk materialises to reduce eventual containment costs

  30. Risk Monitoring • Should be done periodically – (e.g., when certain milestones are reached, at the end of project phases, at steering committee meetings, etc.) • Useful to regularly assess and update project risk exposure • Senior management should be involved in monitoring and should be aware of exposures • Listen to the project group

  31. Risk Referent Levels • Risk referent levels can be set to define regions of acceptable and unacceptable risks • Three typical risk referent levels – Cost overrun – Schedule slippage – Performance criteria Region in which project termination will occur Referent level for cost/schedule overruns Projected Schedule Overrun Projected Cost Overrun Projected Cost Overrun Projected Cost Overrun

  32. Scenario Analysis Assess in terms of; • The undesirable event • All the outcomes of the event’s impact • The magnitude or severity of the event’s impact • Chances/probability of the event happening • When the event might occur in the project • Interaction with other parts of this or other projects

  33. Interface problems User backlash System freezing Hardware mal- functioning Risk Severity Matrix

  34. Risk Matrix - NASA

  35. Risk Matrix - NASA Mission Risks (9 total) Element Risks (27 total) Impact Impact Probability Probability

  36. Failure Mode & Effects Analysis Often known as FMEA Is a version of the Risk Severity Matrix Impact x Probability x Detection = Risk Value 4 x 4 x 5 = 80

  37. Risk Assessment Form

  38. Contingency Plan “……..is an alternative plan that will be used if a possible foreseen risk event becomes a reality” C. Gray & E. Larson

More Related