Tải bản đầy đủ
2 Risk management process 259

2 Risk management process 259

Tải bản đầy đủ

260

Critical Chain Project Management

1
Identify
potential risk
events

5
Prevent risk
event

2
Estimate
the risk
probability
3
Estimate the
risk impact

4
Analyze risks

6
Plan for
mitigation

7
Insure
against risk
4
Identify
potential
risk triggers

Figure 10.1

10.2.1

8
Monitor for
risk triggers

The project risk management process.

The risk matrix

Table 10.1 illustrates the basic risk management matrix. It summarizes
the risk, the assessment of the risk, and the planned actions to monitor,
prevent, or mitigate the results of the risk. The content in the table is for
illustration only; your content should be much more specific to your
project. However, I do encourage you to follow the lead of combining
like risks to keep the overall length of the list to a reasonable number of
items. Define what a reasonable number of items is based on the overall
risk and size of your project. Relatively small projects (i.e., less than a few
million dollars and under one year) should not have a risk list in excess of
10 items. If your list for a project of this size just seems to have many more
high-impact, high-consequence risks, ask yourself if you really want to do
that project!
The columns in Table 10.1 start with a description of the potential risk
event. You can start with a list of many specific events that people
can imagine and then lump them together for subsequent analysis. You
can also categorize risks in terms of the probability and potential impact,
the next two columns. That is, you may have one event for low-impact
natural events and another for large-impact natural events. The reason
to do that is that the two types of events will lead to different mitigation
strategies.
The fifth column in Table 10.1 lists the triggers to monitor. They are
the items you should frequently assess to see if you should change your

No.

Risk Event

Probability

Project Impact

Trigger to Monitor

Prevention Actions

Mitigation Actions

1

Natural event

Low

High

Weather reports, trends

Plan outside work during
dry season

Use tents and tarps over
work areas, dikes around
facility, high-wind design,
seismic design, pumps for
rain and floods

2

Fire

Low

High

Fire prevention
inspections; alarm system

Use noncombustibles,
fireproof storage cabinets

Install fire suppression
ASAP

3

Technical
development

Medium

Medium

Development tests and
gates

Institute quality process

Use alternative technology

4

Regulatory
impact

Medium

Medium

Excessive questions or no
action from regulators

Employ face-to-face
discussions with
regulators; use consultants
to prepare applications

Form task team to respond
to causes of delay or
denial

5

Supplier
delay

High

Medium

Late contracts; delayed
delivery

Institute late-delivery
penalties; check supplier
delivery references

Use alternative suppliers,
alternative equipment

Project risk management

Table 10.1

The Risk Matrix

261

262

Critical Chain Project Management

risk assessment or activate your contingency plans. Of course, you should
try to come up with leading indicators whenever possible.
Columns 6 and 7 of Table 10.1 are the most important: listing the
actions you will take to prevent or mitigate the potential risk. Prevention
and mitigation may work on either the event probability or the event
impact. For example, a spill-control dike reduces the potential impact of a
spill, but not the probability. On the other hand, a double-wall tank
reduces the probability of a spill. Actions to prevent the risk should
become part of your project work plan. Actions to mitigate may require
actions in your project work plan to plan for mitigation, such as training
or purchasing emergency supplies.
10.2.2 Incorporating risk assessment into the
project process

Your risk assessment is only as valuable as what you do with it. Listing
risks might give you ammunition to say, “I told you so.” It also opens you
to the question, “And why didn’t you do anything about it?” You must
take action on the identified risks to have any result from your risk analysis. You may choose to use a consistent approach to applying those
alternatives, such as listed in Table 10.2.

10.3

Identifying risks

10.3.1

Risk list

You can use a variety of methods to identify risks. One method starts
with the assumptions your team felt necessary to develop project work
Table 10.2

Guideline for Processing Potential Risk Events

Consequence
of Risk

Probability of Risk
High

Medium

Low

High

Prevent event; reduce
consequences; plan to
mitigate; monitor

Plan to mitigate; monitor

Plan to mitigate;
monitor

Medium

Prevent; plan to mitigate;
monitor

Plan to mitigate; monitor

Monitor

Low

Monitor

Monitor

Ignore

Project risk management

263

estimates. Each of the assumptions represents a risk of not being true. You
can use checklists, such as those included in PMBOK [2]. You can use
computer assistants, such as included in some software offerings [6]. You
can simply get your project team together and brainstorm a list to start
with. You can evaluate the problems encountered by previous similar
projects. Coming up with the list is usually the easy part. You will never be
able to predict the future, so you will never be able to come up with a
complete project risk list. It would be infinitely long anyway and not very
useful to your team. Instead, you should obtain a representative list of
the types of risks likely to confront your specific project during its time
of execution. Table 10.3 identifies categories of risk, and lists examples
under each category. You can find checklist of potential risks in the project management literature.
Invite updates to the list as the project proceeds: additions, deletions,
and modifications.
10.3.1.1

Project assumptions

Many of your project assumptions may translate to project risks if the
assumptions do not come true. For example, your assumption that regulatory permit reviews will take 60 days low-risk and 30 days average
duration may become a risk if the reviews take longer than two-thirds
your project buffer. You may have reason to expect that the reviews could
take much longer based on recent experience with the same regulatory
agency on another project.

Table 10.3

Examples of Project Risk Events (After [2])
External Unpredictable

External Predictable

Internal Nontechnical

Regulatory

Market

Management

Natural hazards

Operational

Schedule

Sabotage

Financial

Cost

Technical

Legal

General

Technology changes

Licenses

First-of-a-kind

Design

Contracts

Remote site

Performance

Lawsuits

Foreign culture

264

Critical Chain Project Management

On the other hand, you should guard against too many project
assumptions. You need to ensure that a rule of reason applies in specifying both the project assumptions and the associated risks.
10.3.1.2

Checklists

Checklists often help to identify risks you might otherwise overlook, but
they have two inherent problems:
◗ Checklists may suggest risks that are not significant to your project

but that become believable once suggested.
◗ Checklists can lead to overconfidence that you have considered every-

thing important, limiting your search for things beyond the checklist.
10.3.1.3

Plan scrutiny

You should scrutinize your plan by asking, “What could go wrong?” in
each of the major steps to aid in developing your risk list. You can let
the list get relatively long while you are preparing it; you will consolidate
it in the next step.
10.3.1.4

Consolidation

If your risk list begins to get long, group like items to consolidate the risk
list before going on to select the risk actions. Your purpose is to come up
with a reasonable set of risk items to manage. Increasing the detail of the
risk list does not increase its accuracy. There are an infinite number of
potential risk events, so you can never list them all. It is far more important that you capture the important types of risks and put in place the
appropriate information and response system to deal with the risks that
do arise. You lose focus if the list of individual risk events becomes too
long. It is impossible to plan realistic actions to prevent or mitigate the
effects of too long a list. Try to limit the list to, at most, a few tens of items.
For most reasonable size projects (i.e., less than about $10 million and one
or two years in duration), the list should be less than 10 items (if not, you
probably should not be doing the project).

10.3.2

Classifying risk probability

Make an estimate of the probability of each risk event actually occurring
during the life of your project to decide on a rational plan to manage the

Project risk management

265

risks. You do not want to spend a large amount of your project resources
guarding against low-probability events. On the other hand, you want to
prevent events that are likely to occur and be prepared to handle some
events even if they are unlikely, if the potential consequence is large enough.
Bernstein notes, “The essence of risk management lies in maximizing
the areas where we have some control over the outcome while minimizing the areas where we have absolutely no control over the outcome and
the linkage between effect and cause is hidden from us” [7]. He goes on to
note that insurance is available only when the law of large numbers is
observed, that is, where the laws of chance work in favor of the insurance
company or gambling institution. The very nature of risk, then, ensures
that we are dealing with relatively low-probability events to start with.
People’s ability to estimate probability is notoriously poor [8–10].
When considering probability, most people are subject to numerous logical biases and errors. Unfortunately, research demonstrates people are
likely to be unjustifiably confident in their erroneous “knowledge.” I will
just list the common errors here to make you aware of them. Overcoming
these biases and errors is the topic of another book.
◗ Failure to understand how probabilities combine. The probability of two

independent events is the product of the probabilities of the individual events. Because probabilities are always numbers less than 1,
the probability of the two events is always lower than the probability of either single event.
◗ Failure to consider the base rate. The base rate error fails to consider the

distribution in the population. For example, consider a bead drawn
from a population of 90% white beads and the probability of
correctly identifying a white bead in dim light of 50%. A person
looks at a bead under those conditions, and says “black bead.” What
is the probability that the bead was black? Most people answer
50%. The correct answer is only 5%.
◗ Availability. The availability error gives unjustified bias toward

whatever comes to mind, usually because of recent reminder but
also because it is something thought to be typical.
◗ Failure to understand the law of large numbers. People routinely accept

small samples as indicative of a larger population and fail to understand that the variance in small samples tends to be much larger
than the variance in larger samples or the population.

266

Critical Chain Project Management
◗ Representativeness error. People mistake “more typical” for “more

probable.” For example, people will claim that a description of
woman is more likely to be “a school teacher” than “a working
woman,” based on a description that includes traits people associate with schoolteachers. This answer is wrong because “working
women” also includes more women than just women schoolteachers, therefore it is more likely that she would be a working woman
than a schoolteacher.
◗ Anchoring. People tend to not deviate much from initial positions

put forth by others or themselves, especially in regard to numbers.
That bias also allows groups to significantly influence each other. If
you want independent input, you have to seek independent input
and not have one person review another’s work.
◗ Confirmation bias. Once people have made a statement or a decision,

they tend to look for instances that confirm that decision. Unfortunately, confirmatory cases have no value in scientific proof. People
should look for instances that would disconfirm their hypothesis.
That bias often results in worthless tests. Effective tests must always
seek to disconfirm the hypothesis.
You can use that list to critically review your list of risk events
and your categorization in terms of probability and impact. Ask, “Are we
making this error?”
10.3.2.1

High probability

Do not have any items on your risk list that exceed a 50% probability of
occurring during the life of your project. Count on items with a greater
than 50% probability and include them in your project assumptions and
baseline plan. Consider defining high risk as less than a 50% chance of
happening during the life of the project but more than a moderate risk,
which you might define as ranging from a 5% to 15% chance.
10.3.2.2

Moderate probability

The cop-out definition is that moderate-probability risk events are less than
high probability and greater than low probability. They are events that may
occur during the life of your project, but you would not bet on them
happening (at least, you would want very favorable odds on the bet).

Project risk management
10.3.2.3

267

Low probability

Low-probability risks include risks unlikely to occur during the life of
your project (i.e., less than a 5% chance of happening), down to a very
low probability, perhaps on the order of 1% or less. Your project design
may have to account for risks of lower probability during the life of the
project result, such as earthquakes or extreme weather, but that is not
the topic of project risk assessment. Exceptions may include insurance
for events such as extreme weather (e.g., hurricane, fire, and flood) on a
construction project.

10.3.3

Classifying risk impact

To define the risk, you must classify the risk impact because risk is the
product of probability multiplied by impact. You could qualify impact in
terms of the overall project schedule and cost or of the expected return on
investment for the project. CCPM provides a unique measure of classifying the risk impact in terms of the project buffers for time and cost. The
buffer size is an indicator of the common cause risk in the project
and therefore is a reasonable basis to measure special cause variation.
Sometimes fiduciary responsibility may require insurance for risks with
chances greater than or equal to 1 in 1,000.
10.3.3.1

High impact

High impact is anything that could cause an impact in excess of the project
buffer on schedule or in excess of the cost buffer on cost or otherwise
result in client or project team dissatisfaction.
10.3.3.2

Moderate impact

Moderate impact is an impact that would consume on the order of
two-thirds of your project buffers or all of your feeding buffers but at
least one-third of the respective buffers.
10.3.3.3

Low impact

Low-impact consequences would not exceed one-third of your project
schedule or cost buffers and would not be a significant concern to your
client or project team.

268

Critical Chain Project Management

10.4

Planning to control risks

10.4.1

Risk monitoring

Plan on monitoring for the risks you elect to keep in your risk management list. That means you should, at a minimum, review the list with the
team members at your weekly project meetings and ask the question if
any of the risk triggers seems to be imminent. Sometimes, you may need
more formal monitoring for the risk triggers.
10.4.2

Prevention

Risk prevention activities you have elected to implement become part of
your project plan. All you have to do to ensure that they are in place is to
follow through on your project measurement and control process.
10.4.3

Mitigation planning

Plans for risk mitigation should also be part of your project plan. Include
routine activities necessary to ensure the viability of your risk mitigation
plans, such as fire inspections or emergency drills, as part of your project
monitoring and control process. You need not include such periodic or
ongoing activities as specific activities in your project network.

10.5

Summary

Project risk management controls special cause variation through monitoring, prevention, mitigation, or insurance.
◗ CCPM simplifies project risk management by eliminating the need

to address common cause variation. CCPM risk management
addresses only special causes of variation.
◗ You must include a risk management process in your project work

plan. You should scale the implementation of risk management to
overall project risk.
◗ Project risks must identify the risk event, the probability of the

event occurring, and the potential impact or consequence of
the risk event to the project.

Project risk management

269

◗ The CCPM project plan helps to define the relative risk in terms of

the project buffers.
◗ The project team must decide among options, including preven-

tion, mitigation, insurance, monitoring, and ignoring risks.
Risk monitoring, prevention, and preparations for mitigation should
be part of your project plan. You should assign specific responsibility to
monitor risks throughout the performance of the project and update your
risk plans as appropriate.

References
[1] Duncan, W. R., et al., A Guide to the Project Management Body of Knowledge,
Upper Darby, PA: Project Management Institute, 1996.
[2] Wideman, R. M., Project and Program Risk Management, A Guide to Managing
Project Risk and Opportunities, Upper Darby, PA: Project Management Institute,
1992.
[3] Meredith, J. R. and S. J. Mantel, Project Management, A Managerial Approach,
New York: Wiley, 1985, pp. 68–71.
[4] Wysocki, R. K., R. Beck, Jr., and D. B. Crane, Effective Project Management,
New York: Wiley, 1995.
[5] Deming, W. E., The New Economics, Cambridge: MIT Press, 1993.
[6] RiskTrak, Risk Services & Technology, Amherst, NH.
[7] Bernstein, P. L., Against the Gods, The Remarkable Story of Risk, New York:
Wiley, 1996.
[8] Kahneman, D., P. Slovic, and A. Tversky, Judgment Under Uncertainty:
Heuristics and Biases, Cambridge: Cambridge University Press, 1982.
[9] Belsky, G., and T. Gilovich, Why Smart People Make Big Money Mistakes, And
How to Correct Them, New York: Simon & Schuster, 1999.
[10] Russo, J. E., and P. J. H. Schoemaker, Decision Traps: The Ten Barriers to
Brilliant Decision Making, and How to Overcome Them, New York: Simon &
Schuster, 1989.