Project Management
The Managerial Process
Chapter 7: Managing Risk
LEARNING OBJECTIVES
After reading this chapter you should be able to:
1.
2.
3.
4.
5.
Describe risk management process.
Understand how to identify project risks.
Assess the significance of different project risks.
Describe four different responses to managing risks.
Understand the role contingency plans play in risk
management process.
6. Understand opportunity management and describe the four
different approaches to responding to opportunities in a
project.
7. Understand how contingency funds and time buffers are
used to manage risks on a project.
8. Recognize the need for risk management being an ongoing
activity.
9. Describe the change control process.
 Every project manager understands risks are inherent in
projects, deliveries are delayed, accidents happen, people get
sick, etc.
 No amount of planning can overcome risk.
 In the context of projects, risk is an uncertain event or
condition that, if it occurs, has a positive or negative effect on
project objectives.
• Some potential risk events can be identified before the project
starts
 For example, equipment malfunction or change in technical
requirements
 Anticipated consequences, could be schedule slippages or cost
overruns
• Some other risks can be beyond imagination
For example, 2008 financial meltdown
• Although risks can have positive consequences such as
unexpected price reduction in materials, the primary focus of
this chapter is on what can go wrong and the risk management
process
Risk Management Process
 Risk management is a proactive approach rather than
reactive.
 It is a preventive process designed to ensure that surprises are
reduced and that negative consequences associated with
undesirable events are minimized.
 It also prepares the project manager to take action when a
time, cost, and/or technical advantage is possible.
• The sources of project risks are unlimited.
• There are external sources, such as:
 inflation
 market acceptance
 exchange rates, and
 government regulations
• In practice, these risk events are often referred to as “threats”.
Figure 7.2 presents the major
components of risk management
process
Step 1: Risk Identification
• The risk management process begins by trying to generate a
list of all the possible risks that could affect the project.
• The team uses brainstorming and other problem identifying
techniques to identify potential problems.
• One common mistake that is made early in the risk
identification process is to focus on objectives and not on the
events that could produce consequences.
For example:
team members may identify failing to meet schedule as a
major risk.
What they need to focus on are the events that could cause
this to happen
o poor estimates
o adverse weather
o shipping delays, etc
• Organizations use risk breakdown structures (RBSs) in conjunction
with work breakdown structures (WBSs) to help management teams
identify and eventually analyze risks. Figure 7.3 provides a generic
example of a RBS.
At the beginning the focus should macro risk (risks that affects
whole project) as opposed to a specific section of the project or
network.
• For example:
 Project funding related risks: The team may identify possible
budget cut after the project started.
 Market related risk: The team may identify possible competitors
response after a new product is released.
• Benefit- RBS reduces the chance a risk event will be missed.
• An other useful tool is 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.
Figure 7.4 provides a partial example of a risk profile.
• The risk identification process should not be limited to just the
core team.
Input from customers, sponsors, subcontractors, vendors,
and other stakeholders should be solicited.
Step 2: Risk Assessment
• Step 1 produces a list of potential risks. Not all of these risks
deserve attention.
• Some are trivial and can be ignored, while others pose serious
threats to the welfare of the project.
• Managers have to develop methods for sifting through the list
of risks:
eliminating inconsequential or redundant ones and
focusing worthy ones in terms of importance and need for
attention
• Scenario analysis is the easiest and most commonly used
technique for analyzing risks.
• Team members assess the significance of each risk event in
terms of:
 Probability of the event
 Impact of the event
• For example
The risk of a project manager being struck by lightning at a
work site would have major negative impact on the
project, but the likelihood is so low it is not worthy of
consideration.
• Conversely
people do change jobs, so an event like the loss of key
project personnel would have not only an adverse impact
but also a high likelihood of occurring in some
organizations
• The impact ultimately needs to be assessed in terms of project
priorities, different kinds of impact scales are used.
• Some scales may simply use rank-order descriptors, such as:
Low,
Moderate
High, and
Very high
• Whereas others use numeric weights (e.g., 1–10).
• Figure 7.5 provides an example of how impact scales could be
defined given the project objectives of cost, time, scope, and
quality.
• Figure 7.6 is a partial example of a risk assessment form used on an
IS project involving the upgrade from Windows 10 to Windows 11.
• In figure 7.6 above “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 we have?
• So in the Windows 11 conversion example, the detection
scale would range from:
5 = no warning to 1 = lots of time to react
FIGURE 7.7 Risk
Severity Matrix
• The matrix is typically structured around the impact and
likelihood of the risk event.
o For example, the risk matrix presented in Figure 7.7 consists of
a 5 × 5 array of elements with each element representing a
different set of impact and likelihood values
• The risk severity matrix provides a basis for prioritizing
which risks to address.
Red zone risks receive first priority
Followed by yellow zone risks.
Green zone risks are typically considered inconsequential and
ignored unless their status changes.
Failure Mode and Effects Analysis (FMEA) extends the risk
severity matrix by including ease of detection in the equation:
Impact × Probability × Detection = Risk Value
For example
• A risk with an impact in the “1” zone with a very low probability
and an easy detection score might score a 1 (1 × 1 × 1 = 1)
Conversely
• A high-impact risk with a high probability and impossible to
detect would score 125 (5 × 5 × 5 = 125)
Step 3: Risk Response Development
• When a risk event is identified and assessed, a decision must
be made concerning which response is appropriate for the
specific event.
• Responses to risk can be classified as:
i. mitigating
ii. avoiding
iii. transferring, or
iv. retaining
I. Mitigating Risk
• Reducing risk is usually the first alternative considered. There are
basically two strategies for mitigating risk:
(1) reduce the likelihood that the event will occur and/or
(2) reduce the impact that the adverse event would have on the
project.
• Most risk teams focus first on reducing the likelihood of risk events
since, if successful, this may eliminate the need to consider the
potentially costly second strategy.
• Often identifying the root causes of an event is useful.
• For example, the fear that a vendor will be unable to supply
customized components on time may be attributable to
(1) poor vendor relationships
(2) design miscommunication, and
(3) lack of motivation
• As a result of this analysis the project manager may decide to
take his counterpart to invite the vendor to attend design
meetings, and restructure the contract to include incentives
for on-time delivery.
• An alternative mitigation strategy is to reduce the impact of
the risk if it occurs.
II. Avoiding Risk
• Risk avoidance is changing the project plan to eliminate the risk or
condition.
• Although it is impossible to eliminate all risk events, some specific
risks may be avoided before you launch the project.
• For example,
 Adopting proven technology instead of experimental
technology can eliminate technical failure.
 Choosing an Australian supplier as opposed to an Indonesian
supplier would virtually eliminate the chance that political
unrest would disrupt the supply of critical materials.
III.Transferring Risk
• Passing risk to another party is common; this transfer does
not change risk.
• Passing risk to another party almost always results in paying
a premium for this exemption.
• Fixed price contracts are the classic example of transferring
risk from an owner to a contractor.
• Another more obvious way to transfer risk is insurance.
IV. Accept Risk
• In some cases a conscious decision is made to accept the risk
of an event occurring.
• Some risks are so large it is not feasible to consider
transferring or reducing the event:
(e.g., an earthquake or flood).
• The project owner assumes the risk because the chance of
such an event occurring is slim.
• The more effort given to risk response before the project
begins, the better the chances are for minimizing project
surprises.
• Knowing that the response to a risk event will be retained,
transferred, or mitigated greatly reduces stress and
uncertainty.
• Again, control is possible with this structured approach.
Contingency plan
• A contingency plan is an alternative plan that will be used if a possible
foreseen risk event becomes a reality.
• The contingency plan represents actions that will reduce or mitigate the
negative impact of the risk event.
• A key distinction between a risk response and a contingency plan is that:
 A response is part of the actual implementation plan and action is
taken before the risk can materialize,
 While a contingency plan is not part of the initial implementation plan
and only goes into effect after the risk is recognized.
• The availability of a contingency plan can significantly increase the chances
for project success.
Some of the most common methods for handling risk:
1) Technical Risks
• Technical risks are problematic; they can often be the kind
that cause the project to be shut down.
• What if the system or process does not work?
• Contingency or backup plans are made for those
possibilities that are foreseen.
2) Schedule Risks
• Often organizations will postpone the threat of a project coming
in late until it surfaces.
• Here contingency funds are set aside to reduce the project
duration to get it back on track.
• Reduction of project duration is accomplished by shortening
(compressing) one or more activities on the critical path. This
comes with additional costs and risk.
o For example, schedules can be altered by working activities
in parallel or using start-to-start lag relationships.
3) Cost Risks
• Cost Risks Projects of long duration need some contingency for
price changes—which are usually upward.
• On cost sensitive projects, price risks should be evaluated item
by item; especially, those that may change should be identified
and estimates made of the magnitude of change.
4) Funding Risks
• What if the funding for the project is cut by 25 percent or
completion projections indicate that costs will greatly exceed
available funds?
 For example, a building contractor may find that due to a sudden
downturn in the stock market the owners can no longer afford to build
their dream house.
An opportunity
• An opportunity is an event that can have a positive impact
on project objectives.
For example, unusually favorable weather can accelerate
construction work, or a drop in fuel prices may create savings
that could be used to add value to a project.
Step 4: Risk Response Control
• Typically the results of the first three steps of the risk management
process are summarized in a formal document often called the risk
register.
• A risk register details all identified risks, including descriptions,
category, and probability of occurring, impact, responses, contingency
plans, owners, and current status.
• The register is the backbone for the last step in the risk management
process: risk control.
• Risk control involves executing the risk response strategy,
monitoring triggering events, initiating contingency plans,
and watching for new risks.
• Change Control Management
• A major element of the risk control process is change management.
Every detail of a project plan will not materialize as expected.
• Coping with and controlling project changes present a formidable
challenge for most project managers.
• Changes come from many sources such as the project customer, owner,
project manager, team members, and occurrence of risk events.
• Most changes easily fall into three categories:
1) Scope changes in the form of design or additions represent big changes
For example, customer requests for a new feature or a redesign that will
improve the product.
2) Implementation of contingency plans
When risk events occur, represent changes in baseline costs and
schedules.
3) Improvement changes suggested by project team members represent
another category
• Most change management systems are designed to
accomplish the following:
1. Identify proposed changes.
2. List expected effects of proposed change(s) on schedule and budget.
3. Review, evaluate, and approve or disapprove changes formally.
4. Negotiate and resolve conflicts of change, conditions, and cost.
5. Communicate changes to parties affected.
6. Assign responsibility for implementing change.
7. Adjust master schedule and budget.
8. Track all changes that are to be implemented.
The END