HF week's
Managing Risk
CHAPTER SEVEN
PowerPoint Presentation by Charlie Cook
Copyright © 2014 McGraw-Hill Education. All Rights Reserved.
1
Chapter 7 Managing Risk
7–2
Where We Are Now
2
To put the processes discussed in this chapter in proper perspective one should recognize that project managers must engage in risk management activities to compensate for the uncertainty inherent in project selection, management and project planning.
Although risk assessment may depend on subjective judgment, standard methods for identifying, assessing, and responding to risks should be included in all projects. Contingency plans increase the chance that the project can be completed on time and within budget.
Using a formal, structured process to handle foreseen and unforeseen project risk events minimizes surprises, costs, schedule delays, stress, and misunderstandings. Ultimately successful risk management requires an organizational culture in which threats are embraced not denied and problems are identified not hidden.
7–3
Risk Management Process
Risk
Uncertain or chance events that planning can not overcome or control.
Risk Management
A proactive attempt to recognize and manage internal events and external threats that affect the likelihood of a project’s success.
What can go wrong (risk event).
How to minimize the risk event’s impact (consequences).
What can be done before an event occurs (anticipation).
What to do when an event occurs (contingency plans).
3
Risk is an uncertain event or condition (a cause) that, if it occurs, has a positive or negative effect (consequence) on project objectives. Risk management attempts to recognize risk events and manage or develop contingencies to control their effects when the project is implemented.
7–4
The Risk Event Graph
FIGURE 7.1
4
Figure 7.1 presents a graphic model of the risk management challenge during the project life cycle. The chances of a risk event occurring (e.g., an error in time estimates, cost estimates, or design technology) are greatest due to uncertainty that attends early stages of a project.. As the project reaches its later stages, risk declines as uncertainties are resolved. However, the consequences of a risk event increase in cost over the life of the project as it becomes more difficult to alter fully developed project features.
7–5
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.
5
Risk management is a proactive approach rather than reactive that ensures surprises are reduced and negative consequences of undesirable events are minimized. It also prepares the project manager to take action when a time, cost, and/or technical advantage is possible. Project risk management controls for present and future risk to improve management’s chances of reaching project objectives on time, budget, and technical performance.
7–6
The Risk Management Process
FIGURE 7.2
6
Figure 7.2 depicts the four steps of the risk management process. Step 1 entails identification of the sources of risk. Step 2 involves the assessment of the severity, likelihood of occurrence, and controllability of risks. Step 3 is focused on development of strategic and contingency plans for reducing and handling risks. Step 4 looks at the implementation of risk management strategy.
7–7
Managing Risk
Step 1: Risk Identification
Generate a list of possible risks through brainstorming, problem identification and risk profiling.
Macro risks first, then specific events
Step 2: Risk Assessment
Scenario analysis for event probability and impact
Risk assessment matrix
Failure Mode and Effects Analysis (FMEA)
Probability analysis
Decision trees, NPV, and PERT
Semiquantitative scenario analysis
7
Step 1 in managing risk is risk identification which involves generating a list of possible risks through brainstorming, problem identification and risk profiling. Typically, macro risks that can affect the whole project as opposed to a specific section of the project or network are considered first and then specific events.
Step 2 in managing risk is risk assessment in which scenario analysis is used to estimate risk event probabilities and their impact. Various methods used in this step are:
Risk assessment matrix
Failure Mode and Effects Analysis (FMEA)
Probability analysis
Decision trees, NPV, and PERT
Semiquantitative scenario analysis
7–8
The Risk Breakdown Structure (RBS)
FIGURE 7.3
8
Figure 7.3 provides a generic example of a risk breakdown structure (RBS ) that used in conjunction with work breakdown structures (WBSs) to help management teams identify and eventually analyze risks during Step 1 of risk management.
7–9
Partial Risk Profile for Product Development Project
FIGURE 7.4
9
Figure 7.4 provides a partial example of a risk profile. A risk profile is a list of questions that address traditional areas of uncertainty on a project. These questions have been developed and refined from previous, similar projects.
7–10
Defined Conditions for Impact Scales of a Risk on Major Project Objectives (Examples for negative impacts only)
FIGURE 7.5
10
Figure 7.5 provides an example of how impact scales could be defined given the project objectives of cost, time, scope, and quality. The impact scales offer relative assessments of how risks affect project objectives.
7–11
Risk Assessment Form
FIGURE 7.6
11
Figure 7.6 is a partial example of a risk assessment form used on an IS project involving the upgrade from Windows 7 to Windows 8. In addition to evaluating the severity and probability of risk events, The form assesses when the event might occur and its detection difficulty.
Detection difficulty is a measure of how easy it would be to detect that the event was going to occur in time to take mitigating action, that is, how much warning would the project manager have? In example, the detection scale would range from 5 (no warning) to 1 (lots of time to react).
7–12
Risk Severity Matrix
FIGURE 7.7
Failure Mode and Effects Analysis (FMEA) Impact × Probability × Detection = Risk Value
| User Backlash | Interface problems | |||
| System freezing | ||||
| Hardware malfunc-tioning |
Likelihood
Impact
Red zone (major risk)
Yellow zone (moderate risk)
Green zone (minor risk)
5
5
4
4
3
3
2
2
1
1
12
The risk matrix presented in Figure 7.7 consists of a 5 3 5 array of elements with each element representing a different set of impact and likelihood values. The matrix is divided into red, yellow, and green zones representing major, moderate, and minor risks, respectively. The red zone is centered on the top right corner of the matrix (high impact/high likelihood), while the green zone is centered on the bottom left corner (low impact/low likelihood). The moderate risk, yellow zone extends down the middle of the matrix.
7–13
Managing Risk (cont’d)
Step 3: Risk Response Development
Mitigating Risk
Reducing the likelihood an adverse event will occur.
Reducing impact of adverse event.
Avoiding Risk
Changing the project plan to eliminate the risk or condition.
Transferring Risk
Paying a premium to pass the risk to another party.
Requiring Build-Own-Operate-Transfer (BOOT) provisions.
Retaining Risk
Making a conscious decision to accept the risk.
13
Step 3 involves developing responses to risks. Possible responses to risk events include:
Mitigating risk by either reducing the likelihood an adverse event will occur or reducing impact of adverse event.
Avoiding risk by changing the project plan to eliminate the risk or condition.
Transferring risk by either paying a premium to pass the risk to another party or requiring Build-Own-Operate-Transfer (BOOT) provisions.
Retaining risk by making a conscious decision to accept the risk.
7–14
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.
14
Contingency planning involves developing an alternative plan that will be used if a possible foreseen risk event actually occurs to reduce or mitigate the negative impact (consequences) of a risk event.
Risks of not having a contingency plan include:
Having no plan which may slow managerial response.
Decisions made under pressure that can be potentially dangerous and costly.
7–15
Risk Response Matrix
FIGURE 7.8
15
Figure 7.8 shows a risk response matrix for the Windows 8 that summarizes how the project team plans to manage risks that have been identified. The first step is to identify whether to reduce, share, transfer, or accept each risk. The next step is to identify a contingency plan (response) for each risk if that risk is triggered (occurs).
7–16
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.
16
Technical risks require backup strategies if chosen technology fails. Project managers must continually assess whether technical uncertainties can be resolved.
Schedule risks arise when the use of slack increases the risk of a late project finish, imposed duration dates (absolute project finish date) leave no room for delays, and project schedules become compressed due to a shortened project duration date.
7–17
Risk and Contingency Planning (cont’d)
Costs Risks
Time/cost dependency links: costs increase when problems take longer to solve than expected.
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.
17
For long-duration projects, risks of changes in resource costs increase when problems take longer to solve than expected. Price protection risks (a rise in input costs) increase if the duration of a project is increased.
Funding risks reflect how increased risks associated with changes in the supply of funds for the project can dramatically affect the likelihood of implementation or successful completion of a project.
7–18
Opportunity Management Tactics
Exploit
Seeking to eliminate the uncertainty associated with an opportunity to ensure that it definitely happens.
Share
Allocating some or all of the ownership of an opportunity to another party who is best able to capture the opportunity for the benefit of the project.
Enhance
Taking action to increase the probability and/or the positive impact of an opportunity.
Accept
Being willing to take advantage of an opportunity if it occurs, but not taking action to pursue it.
18
Project managers can use several tactics to exploit an opportunity (take advantage of a positive risk by:
Taking exploitive actions that ensure the elimination of the uncertainty associated with an opportunity so that it definitely happens.
Sharing or allocating some or all of the ownership of an opportunity to another party who is best able to capture the opportunity for the benefit of the project.
Taking action to enhance the probability and/or the positive impact of an opportunity.
Being willing to accept taking advantage of an opportunity if it occurs, but not taking action to pursue it.
7–19
Contingency Funding and Time Buffers
Contingency Funds
Funds to cover project risks—identified and unknown.
Size of funds reflects overall risk of a project
Budget reserves
Are linked to the identified risks of specific work packages.
Management reserves
Are 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.
Severe risk, merge, noncritical, and scarce resource activities
19
Contingency funds are used to cover project risks—both identified and unknown. The size of funds reflects overall risk of a project. Budget reserves are fund-based contingencies linked to the identified risks of specific work packages.
Management reserves are large funds to be used to cover major unforeseen risks (e.g., change in project scope) of the total project.
Time buffers represent amounts of time used to compensate for unplanned delays in the project schedule. The buffers are added to critical project events that have severe risk severity, can be delayed due to waiting, noncritical events not on the critical path, and that use scarce resource activities
7–20
Contingency Fund Estimate ($000s)
TABLE 7.1
20
Table 7.1 shows the development of a contingency fund estimate for a hypothetical project. This format helps keep budget and management reserves separate; budget control is also easily tracked using this format.
7–21
Managing Risk (cont’d)
Step 4: Risk Response Control
Risk control
Execution of the risk response strategy
Monitoring of triggering events
Initiating contingency plans
Watching for new risks
Establishing a Change Management System
Monitoring, tracking, and reporting risk
Fostering an open organization environment
Repeating risk identification/assessment exercises
Assigning and documenting responsibility for managing risk
21
Step 4 in managing project risk involves:
Exercising risk response control by
Developing a risk register
Execution of the risk response strategy
Monitoring of triggering events
Initiating contingency plans
Watching for new risks
Establishing a change management system for
Monitoring, tracking, and reporting risk
Fostering an open organization environment
Repeating risk identification/assessment exercises
Assigning and documenting responsibility for managing risk
7–22
Change Management Control
Sources of Change
Project scope changes
Implementation of contingency plans
Improvement changes
22
Coping with and controlling project changes present a formidable challenge for most project managers. Most changes fall into three categories:
Scope changes in the form of design or additions to the project represent big changes
Implementation of contingency plans, when risk events occur, represent changes in baseline costs and schedules.
Improvement changes suggested by project team members represent another category.
7–23
Change Control System 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
23
Change management systems are designed to accomplish the following:
Identify proposed changes.
List expected effects of proposed change(s) on schedule and budget.
Review, evaluate, and approve or disapprove changes formally.
Negotiate and resolve conflicts of change, conditions, 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–24
The Change Control Process
FIGURE 7.9
24
Figure 7.9 depicts the change control process as a flow diagram where the need for change originates, a change request is submitted, the request is reviewed, if approved, then the change is noted in the updated plan of record and distributed for action.
7–25
Benefits of a Change Control System
Inconsequential changes are discouraged by the formal process.
Costs of changes are maintained in a log.
Integrity of the WBS and performance measures is maintained.
Allocation and use of budget and management reserve funds are tracked.
Responsibility for implementation is clarified.
Effect of changes is visible to all parties involved.
Implementation of change is monitored.
Scope changes will be quickly reflected in baseline and performance measures.
25
Benefits of a change control system are:
Inconsequential changes are discouraged by the formal process.
Costs of changes are maintained in a log.
Integrity of the WBS and performance measures is maintained.
Allocation and use of budget and management reserve funds are tracked.
Responsibility for implementation is clarified.
Effect of changes is visible to all parties involved.
Implementation of change is monitored.
Scope changes will be quickly reflected in baseline and performance measures.
7–26
Sample Change Request
FIGURE 7.10
26
Figure 7.10 depicts an example of a simplified change request form.
7–27
Change Request Log
FIGURE 7.11
27
Figure 7.1 presents an abridged version of a change request log for a construction project. These logs are used to monitor change requests. They typically summarize the status of all outstanding change requests and include such useful information as source and date of the change, document codes for related information, cost estimates, and the current status of the request.
7–28
Key Terms
Avoiding risk
Budget reserve
Change management system
Contingency plan
Management reserve
Mitigating risk
Opportunity
Retaining risk
Risk
Risk breakdown structure (RBS)
Risk profile
Risk register
Risk severity matrix
Scenario analysis
Time buffer
Transferring risk
28
Avoiding risk is the elimination of the risk cause before the project begins.
Budget reserve covers identified risks that may occur and influence baseline tasks or costs.
Change management system creates a defined process for authorizing and documenting changes in the scope of a project.
Contingency plan covers possible identified project risks that may materialize over the life of the project.
Management reserve is a percentage of the total project reserved as a risk-reduction contingency measure to cover unforeseen, new problems—not unnecessary overruns.
Mitigating risk involves taking action to either reduce the likelihood that a risk will occur and/or the impact the risk will have on the project.
Risk is the chance that an undesirable project event will occur and the consequences of all its possible outcomes.
Risk breakdown structure (RBS) is a hierarchical depiction of the identified project risks arranged by risk category and subcategory that identifies the various areas and causes of potential risks.
Risk profile is a list of questions that addresses traditional areas of uncertainty on a project.
Risk severity matrix is a tool used to assess the impact of risks on a project.
Time buffer is a contingency amount of time for an activity to cover uncertainty—for example, availability of a key resource or merge event.
Transferring risk is shifting responsibility for a risk to another party.