Managing Project Risk

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