McGraw-Hill/IrwinCopyright © 2008 by The McGraw-Hill Companies, Inc. All Rights Reserved. Managing Risk Chapter 7

7-2

7-3

7-4 Risk Management Process  Risk  An uncertain event that, if it occurs, has a positive or negative effect on project objectives

7-5 Risk Management Process  Risk Management  A proactive attempt to recognize and manage internal events and external threats that affect the likelihood of a project’s success oWhat can go wrong (risk event) oHow to minimize the risk event’s impact (consequences) oWhat can be done before an event occurs (anticipation) oWhat to do when an event occurs (contingency plans)

7-6 Risk Management Process  You can gain a lot of money if you deal with uncertain project events in a proactive manner. The result will be that you minimise the impact of project threats and seize the opportunities that occur. This allows you to deliver your project on time, on budget and with the quality results your project sponsor demands.

7-7 Example of correct risk identification  Consider a software utility project  You have developed a software that you must install at several teacher office computer However, not all teacher have the 5MB storage capacity or latest operating system (Window vista) - Is it a risk because you have to install? oNo, that is a requirement  - Is it a risk that the will not install for some reason? oYes, that is the uncertainty oYou will not know until you try

7-8 RISK MANAGMENT  The management of project risk, the act increasing the probability and impact of  Positive event, the act decreasing the probability and impact of negative event  Uncertainty create risk

7-9 RISK MANAGMENT Risk Management Proactive Approach Grater Control of Project Increase Probability of Positive event Decrease Probability of Negative event

7-10 The Risk Event Graph FIGURE 7.1

7-11 Risk Management’s Benefits  A proactive rather than reactive approach  Reduces surprises and negative consequences  Prepares the project manager to take advantage of appropriate risks  Provides better control over the future  Improves chances of reaching project performance objectives within budget and on time

7-12

7-13

7-14 What is the level of risk management required to reduce the likelihood of mission failures?  NASA is taking steps to address its workforce challenges. For example:  NASA is developing an agency wide integrated workforce planning and analysis system that aims to track the distribution of NASA’s workforce across programs, capture critical competencies and skills, determine management and leadership depth, and facilitate gap analyses.

7-15 The Risk Management Process FIGURE 7.2

7-16 Managing Risk  Step 1: Risk Identification  Generate a list of possible risks through brainstorming, problem identification and risk profiling. oMacro risks first, then specific events  Step 2: Risk Assessment  Scenario analysis  Risk assessment matrix  Failure Mode and Effects Analysis (FMEA)  Probability analysis oDecision trees, NPV, and PERT  Semiquantitative scenario analysis

7-17 Managing Risk  Risk identification process is too focus on objectives as well as event that produce consequences.  Failing to meet schedule --  Risk  Adverse weather, shipping delay -  event

7-18 Risk Identification  An event is only a risk  If there is a degree of uncertainty associated with it  Example:  The value of money will change during the project oFrom experience, that is certain  But by how much oIs uncertain  Therefore this is a risk oThough it may be negligible on a short project  When identifying project risks  Make sure you describe the risk itself oAnd not the cause, nor the effect

7-19 Risk Breakdown Structure

7-20

7-21 Risk Breakdown Structure  A risk breakdown structure is a hierarchy of potential risk categories for a project.  Similar to a work breakdown structure but used to identify and categorize risks.

7-22 Recurring-type Risk Events  Recurring risk events are predictable to some extent  You know they will happen, but not how seriously!  Some examples of this type are:  Changes in market conditions  Changes in operational requirements  Changes in social, political and environmental considerations oE.g. public opposition for one reason or another  Changes in taxation or currency exchange values  Changes in inflation  Extreme and unusual weather conditions

7-23 Non-Recurring Risk Events  Non-recurring risk events tend to be unpredictable  I.e. they happen at random  You know of them but hope to avoid them!  Some examples of this type are:  Natural hazards: off-site accidents, fire, flood, earthquake oAnd their side effects  Unavailability of resources, transportation, services

7-24 Project Management Risk Events  Lack of planning, risk analysis, contingencies  Inadequate tracking and control response  Milestone failure due to unrealistic schedule  Failure due to inappropriate delivery system  Realization of error in a planning assumption  Hiding the truth for fear of recrimination  Damage to professional reputations

7-25 Technological Risk Events  Working in unsafe conditions resulting in accident  Unacceptable operational and maintenance or safety  Design unsuitable or inappropriate as a solution  Design not completed or not feasible  Technology suddenly becomes obsolete  Performance unattainable  Sheer size of project or its complexity causes collapse  Technological incompetence revealed

7-26 Legal Risks  Unexplained contractual failure  Liability claim  Licensing challenge or delay  Force majeure:  "Irresistible compulsion excusing contract completion"  E.g. war, strike, act of god, etc

7-27 Partial Risk Profile for Product Development Project FIGURE 7.3

7-28 Risk Analysis

7-29 Risk Analysis  Probability of event  Impact of the event  Term of project priority-  impact  Numeric weight-  1-5  Low,moderate, high, very high

7-30 Risk Assessment Form FIGURE 7.4

7-31 Impact Scales

7-32 Risk Severity Matrix FIGURE 7.5

7-33 Managing Risk (cont’d)  Step 3: Risk Response Development  Mitigating Risk oReducing the likelihood an adverse event will occur oReducing impact of adverse event  Transferring Risk oPaying a premium to pass the risk to another party  Avoiding Risk oChanging the project plan to eliminate the risk or condition  Sharing Risk oAllocating risk to different parties  Retaining Risk oMaking a conscious decision to accept the risk

7-34 Mitigating Risk  Testing and prototyping are frequently used to prevent problem from surfacing later in a project

7-35 Mitigating Risk  The project team was responsible for installing a new system in a company  How they reduce risk  The team must tested the new system in a smaller network

7-36 Mitigating Risk  Example 2 fear that a vendor will unable to supply component on time  A) poor vendor relation ship  b) Design miscommunication  C) lack of motivation  Scheduled outdoor work during summer

7-37 Risk avoidance  It is often the best strategy — prevent the risk happening in the first place. An  example might be: ‘My staff are not fully up to speed with that new visual  programming environment for Java, so we’ll use C++ instead and traditional tools,  with which they are familiar.’ Of course, this strategy might well introduce a new risk,  since avoiding the original risk will result in the loss of any benefits that may have  accrued from taking that risk

7-38 Risk transfer  This does not mean that the project manager abdicates responsibility for the risk, but that the costs resulting from an occurrence of the risk event are passed on to a third party. An example is taking out an insurance policy.

7-39 Sharing Risk Risk sharing allocate proportion of risk to different parties

7-40 Risk retention  If the risk is seen as low probability and low cost, in other words the risk is unlikely to occur and if it did the effects would be minimal, the project manager might  recommend that the risk be accepted. This, in particular, would be the strategy to  adopt if the costs of avoiding the risk were significantly higher than the costs of the  risk event occurring.

7-41 Contingency Planning  Contingency Plan  An alternative plan that will be used if a possible foreseen risk event actually occurs  A plan of actions that will reduce or mitigate the negative impact (consequences) of a risk event  Risks of Not Having a Contingency Plan  Having no plan may slow managerial response  Decisions made under pressure can be potentially dangerous and costly

7-42 Risk Response Matrix FIGURE 7.7

7-43 Risk and Contingency Planning  Technical Risks  Backup strategies if chosen technology fails  Assessing whether technical uncertainties can be resolved  Schedule Risks  Use of slack increases the risk of a late project finish  Imposed duration dates (absolute project finish date)  Compression of project schedules due to a shortened project duration date

7-44 Risk and Contingency Planning (cont’d)  Costs Risks  Time/cost dependency links: costs increase when problems take longer to solve than expected.  Deciding to use the schedule to solve cash flow problems should be avoided.  Price protection risks (a rise in input costs) increase if the duration of a project is increased.  Funding Risks  Changes in the supply of funds for the project can dramatically affect the likelihood of implementation or successful completion of a project.

7-45 Contingency Funding and Time Buffers  Contingency Funds  Funds to cover project risks—identified and unknown oSize of funds reflects overall risk of a project  Budget reserves oAre linked to the identified risks of specific work packages  Management reserves oAre large funds to be used to cover major unforeseen risks (e.g., change in project scope) of the total project  Time Buffers  Amounts of time used to compensate for unplanned delays in the project schedule

7-46 Contingency Fund Estimate (000s) TABLE 7.1

7-47 Managing Risk (cont’d)  Step 4: Risk Response Control  Risk control oExecution of the risk response strategy oMonitoring of triggering events oInitiating contingency plans oWatching for new risks  Establishing a Change Management System oMonitoring, tracking, and reporting risk oFostering an open organization environment oRepeating risk identification/assessment exercises oAssigning and documenting responsibility for managing risk

7-48 Change Management Control  Sources of Change  Project scope changes  Implementation of contingency plans  Improvement changes

7-49 Change Management Control  The Change Control Process  Identify proposed changes.  List expected effects of proposed changes on schedule and budget.  Review, evaluate, and approve or disapprove of changes formally.  Negotiate and resolve conflicts of change, condition, and cost.  Communicate changes to parties affected.  Assign responsibility for implementing change.  Adjust master schedule and budget.  Track all changes that are to be implemented.

7-50 The Change Control Process FIGURE 7.8

7-51 Benefits of a Change Control System 1. Inconsequential changes are discouraged by the formal process. 2. Costs of changes are maintained in a log. 3. Integrity of the WBS and performance measures is maintained. 4. Allocation and use of budget and management reserve funds are tracked. 5. Responsibility for implementation is clarified. 6. Effect of changes is visible to all parties involved. 7. Implementation of change is monitored. 8. Scope changes will be quickly reflected in baseline and performance measures.

7-52 Change Request Form FIGURE 7.9

7-53 Change Request Log FIGURE 7.10

7-54 Key Terms Avoiding risk Budget reserve Change management system Contingency plan Management reserve Mitigating risk Risk Risk profile Risk Breakdown Structure Risk severity matrix Scenario analysis Sharing risk Time Buffer Transferring risk

McGraw-Hill/IrwinCopyright © 2008 by The McGraw-Hill Companies, Inc. All Rights Reserved. PERT and PERT Simulation Chapter 7 Appendix

7-56 PERT—Program Evaluation Review Technique  Assumes each activity duration has a range that statistically follows a beta distribution.  PERT uses three time estimates for each activity: optimistic, pessimistic, and a weighted average to represent activity durations.  Knowing the weighted average and variances for each activity allows the project planner to compute the probability of meeting different project durations.

7-57 Activity and Project Frequency Distributions FIGURE A7.1

7-58 Activity Time Calculations The weighted average activity time is computed by the following formula: (7.1)

7-59 Activity Time Calculations (cont’d) The variability in the activity time estimates is approximated by the following equations: The standard deviation for the activity: The standard deviation for the project: Note the standard deviation of the activity is squared in this equation; this is also called variance. This sum includes only activities on the critical path(s) or path being reviewed. (7.2) (7.3)

7-60 Activity Times and Variances TABLE A7.1

7-61 Probability of Completing the Project The equation below is used to compute the “Z” value found in statistical tables (Z = number of standard deviations from the mean), which, in turn, tells the probability of completing the project in the time specified. (7.4)

7-62 Hypothetical Network FIGURE A7.2

7-63 Hypothetical Network (cont’d) FIGURE A7.2 (cont’d)

7-64 Possible Project Duration FIGURE A7.3

7-65 Z Values TABLE A7.3

7-66 A project has identified a number of risks, and has adopted the following strategies to contain the risks:  send all software engineers on an UML training course;  do not use Java, because the software engineers have no experience of Java.  Say what kind of risk containment strategy has been adopted (from avoidance,  retention, reduction and transfer) in each case, and discuss the appropriateness of the strategy.

7-67 Use MS Project Do pert Analysis

7-68 Use MS Project Do pert Analysis  View>Toolbars>PertAnalysis  Click Pert entry sheet