5 Project Risk Managementadrian825iStockThinkstockLe.docx

5 Project Risk Management
adrian825/iStock/Thinkstock
Learning Objectives
By the end of this chapter, you will be able to:
• Define and describe project risk.
• Understand the risk management process.
• Discuss the risk identification process.
• Explain the risk analysis process.
• Describe the risk response process.
• Explain the role of risk monitoring and control.
CO_CRD
CN
CT
CO_LO
CO_TX
CO_BL

co-cn
co-cr
co-box
co-intro
co-photo
co
bar81677_05_c05_149-172.indd 149 9/9/14 10:49 AM
Introduction
Pretest
1. Brainstorming is a good initial approach for identifying risks
to a project.
a. True
b. False
2. The risk management process is a three-step process.
a. True
b. False
3. When risks are identified later in the project process, the cost
to address these issues
will increase.
a. True
b. False
4. A risk that has a high probability of occurring might have

little impact on a project.
a. True
b. False
5. A project manager who has not created a documented risk
response plan has not
considered risks fully enough.
a. True
b. False
6. An output of risk monitoring and control includes updating
the risk database.
a. True
b. False
Answers can be found at the end of the chapter.
Introduction
Have you ever visited a public park facility and seen an
observation tower with a sign reading
“Climb at your own risk?” That is a good example of risk, the
chance that something could go
wrong. The park is not only warning you about the risks of
climbing the tower, but also saying
that it is not liable should something happen during the climb.
In other words, the park is not
willing to share in the risk—it is all yours. In project
management there are similar risks that
something will go wrong. The best way to handle anticipated
risks is to document and analyze
them beforehand and decide what to do about them should they
occur.
Good managers look for risks throughout the project cycle,
know what the risks are before they
occur, and work to communicate, prevent, and offset them in

their daily decisions and routines.
For instance, if the project manager is aware that a supplier of a
key product component might
not keep an adequate inventory of that component on hand and
could potentially delay the
project when it is due, the manager may adjust the relevant
supply contract to include a penalty
clause for late delivery or make other changes in the way the
supplier’s inventory is handled.
The principle is that project managers should be able to identify
what might happen, what
the probabilities are that a risk event might occur, what the
impacts will be, and how to
prevent or mitigate risks. This principle assumes that failure can
be attributed to key events
or circumstances.
H1
sec_n sec_t
bar81677_05_c05_149-172.indd 150 9/9/14 10:49 AM
Section 5.1 The Risk Problem
Risk management is the process of recognizing risks and
dealing with them in a project. This
means that risks are identified, analyzed, tracked, and
controlled through proactive project
actions. The primary function of risk management is to prevent
risks; but if they occur, the
risk management plan includes actions to mitigate the risk—in
other words, to take correc-

tive actions to control its impacts.
5.1 The Risk Problem
The root causes of risk and project failure are rarely a
mystery—they often have to do with
business or project performance, competition, social and
economic conditions, technology
developments, and lack of top management support.
Project managers and teams face risks in both process and
product. Process risks have to do
with the project cycle and all the risks in managing the work.
Product risks have to do with
the performance of the product and the risks associated with
failure of the product to meet
customer requirements.
What Is Risk?
Risk is uncertainty about the future and what things can go
wrong. In a way most projects
are risky by definition or they would not be important. Projects
take on risks that customers
decide they do not want to take on themselves.
For instance, if a customer needs a new information system to
handle future demand but
does not have the in-house capacity to develop the system
without major risk of failure, that
customer will often outsource the project and pay a contractor
to take on those risks. Thus,
outsourcing becomes a way of lessening the risk because an
expert contractor will be in a bet-
ter position to anticipate and handle risks.
Possible Risks

There are a number of different kinds of project risks that can
occur:
• Internal. Internal risk is organizational and system related,
which poses challenges
to the company itself to support successful project management.
• Technical. Technical and technology risk can be managed
using reliability and test-
ing methods, which must be built into the project itself.
Technical risk is handled by
embedding testing in the design and development of the
product.
• Nontechnical. Nontechnical risks are personnel,
organizational, and process risks
that the project manager faces. Some would say nontechnical
risks are the most
common because they stem from individual and workforce
performance or from
problems in trying to change social behavior (Hanson & Lynch,
2013). For instance,
if a project staff member is assigned a task that is not feasible
because of the lack of
required equipment, the staff member may try unsuccessfully to
complete the task
without the equipment because it is not in the budget.
bar81677_05_c05_149-172.indd 151 9/9/14 10:49 AM
Section 5.1 The Risk Problem
• External. External risk is generated by the environment and

the market and can be
anticipated through environmental scanning, or the process of
looking out in the
world for factors that will impact the success of a given project,
such as economic
demand, technology, demographics, and strategic planning.
• Predictable. Predictable uncertainty becomes risk because it
can be anticipated,
dimensioned, and mitigated. For instance, weather is typically
predictable and can
be incorporated in project planning if necessary.
• Unpredictable. Unpredictable risk is uncertainty that cannot be
anticipated or man-
aged. For instance, changes in demand for a given product are
unpredictable because
of the impact of competition and market, economic, and social
factors.
• Legal. Legal risk is the probability that a project will generate
legal action focused on
the deliverable or proprietary information.
Sometimes risks are not initially apparent in a project because
the project team is unable
to predict how some risk factors might change a process or
outcome. But because there is
always a chance of failure in a project, it pays to find ways to
identify risks and plan to prevent
or control them. If a project manager ignores risks, the project
could fail simply because the
team cannot adjust to an unanticipated risk.
Sources of Project Risk

There are many sources or causes of risk. Many risks can be
identified and prevented through
good planning and by following prescribed activities in the
project cycle. A good approach
to initial risk identification is to ask top management and the
project team to think through,
or brainstorm, what can go wrong in a given project and what
ought to be done about it if it
happens. That process can be done in a meeting or through
electronic communication tools.
Poorly Defined Scope
Projects can go beyond their original scope and create risks of
failure. Since there is no indus-
try standard on what is involved in a scope of work, the quality
of the scope is typically mea-
sured against the number of changes or the scope creep the
project experiences. Risks and
cost and schedule impacts are widespread in most project areas,
particularly in software and
system development (Kerzner, 2014).
The scope of work statement should include all the work
necessary to complete the project
and meet customer requirements. If the work goes beyond the
scope and incurs unantici-
pated costs and time (scope creep), the project could overrun its
budget, miss its deadlines,
and fail to satisfy the customer.
Unrealistic Timeline and Cost Estimates
Bad estimates of the duration of a project create a major risk.
The natural tendency is to be
overly optimistic in estimating schedule durations and costs;
thus, the risk is that the schedule
is not feasible and the project budget inadequate to support the

job. This is why estimating is
bar81677_05_c05_149-172.indd 152 9/9/14 10:49 AM
Section 5.2 The Project Risk Management Process
so important in project management. Since there will always be
the tendency to promise too
much in a project proposal, a risk analysis helps bring some
reality to the estimating process.
Changing Customer Expectations
There is always the risk that, as a project nears completion, a
customer will have different
expectations for it. This is a risk that can lead to project failure
simply because the customer’s
views change over time. This major source of risk can be
addressed by constant communica-
tion with the customer, but even good communication cannot
always overcome the custom-
er’s changing views of the project as it progresses.
Project Team Performance
There is always a risk that the project team will not perform as
anticipated because of team
collaboration issues or because of individual performance
problems. This risk is prevalent
because even the best project managers cannot always predict
how individual team members
are going to handle their task assignments or how the team will
work together.
Unanticipated Outside Factors
Many outside factors can create project risks. For instance, the

market demand for a given
project deliverable or product can change during the course of
the project. New sources of
competition can appear unexpectedly. New technologies can be
developed that negatively
impact the success of project deliverables.
In sum, there are many potential sources of risks. However,
experienced project managers can
sometimes predict certain risks simply because these have
impacted previous projects; the
kinds of risks that might occur could be related to the nature of
a given project. For instance,
in an IT project, there is likely to be a risk associated with
integrating a new system into the
customer’s other systems. In a construction project, it is a likely
risk that low-quality materi-
als will affect the project.
Now that we know various sources of risk, we can discuss the
project risk management pro-
cess that is designed to anticipate and address risks before they
hurt the project.
5.2 The Project Risk Management Process
The Project Management Institute is a good source on project
risk management (Project
Management Institute, 2013). Risk management is described as
a process of identifying and
assessing risks in a project, then preparing to prevent or control
them. The concept aims to
maximize the probability and consequences of positive events
and to minimize the probabil-
ity and consequences of adverse events.
bar81677_05_c05_149-172.indd 153 9/9/14 10:49 AM

Risk
identification
Qualitative
analysis
Quantitative
analysis
Response
planning
Monitoring
and control
Section 5.2 The Project Risk Management Process
There are six steps that make up the process of risk
management: risk management planning,
risk identification, qualitative risk analysis, quantitative risk
analysis, risk response planning,
and risk monitoring and control. Figure 5.1 shows these steps in
sequence.
The following is a brief description of each step,
each of which will be discussed in more detail later.
Step 1: Risk management planning—deciding how
to approach and plan the risk management activities
for a project
Step 2: Risk identification—determining which
risks might affect the project and documenting their

characteristics
Step 3: Qualitative risk analysis—performing a quali-
tative analysis of risks and conditions to prioritize
their effects on project objectives
Step 4: Quantitative risk analysis—measuring the
probability and consequences of risks and estimat-
ing their implications for project objectives
Step 5: Risk response planning—developing proce-
dures and techniques to enhance opportunities and
reduce threats to the project’s objectives
Step 6: Risk monitoring and control—monitoring
residual risks, identifying new risks, and executing
risk reduction plans and evaluating their effectiveness
throughout the project life cycle
Each step produces an output of some kind, usually
a document containing relevant information about
project risks. Perhaps the most important output
of each step is that the project team becomes more
aware of the things that can go wrong and thinks
through ways to prevent or control them as part of
their task assignment.
Table 5.1 shows the outputs, or the information and
documentation produced, in each step of the risk
management process.
Figure 5.1: Risk management
planning process
This figure shows an “idealized” risk

management planning process. It begins
with risk identification, then moves to
analysis (both qualitative and
quantitative), then continues with
response, and ends with monitoring. In
fact, the monitoring step actually is a
continuing process that goes on
throughout all the other steps to make
sure the project is on track and moves
from one step to another successfully.
Risk
identification
Qualitative
analysis
Quantitative
analysis
Response
planning
Monitoring
and control
bar81677_05_c05_149-172.indd 154 9/9/14 10:49 AM
Section 5.3 Risk Identification
Table 5.1: Risk management outputs
Risk
manage-

ment
step
Step 1: risk
manage-
ment
planning
Step 2: risk
identification
Step 3: quali-
tative risk
analysis
Step 4:
quantitative
risk analysis
Step 5: risk
response
planning
Step 6: risk
monitoring
and control
Outputs • Risk
manage-
ment
plan
• Risks
• Sources
• Impacts
• Corrective

actions
• Over-
all risk
ranking
• List of pri-
oritized
tasks
• List of
risks for
additional
analysis
and man-
agement
• Priori-
tized list
of quanti-
fied risks
• Proba-
bilistic
analysis
of the
project
• Residual
risks
• Second-
ary risks
• Contrac-

tual risks
• Contin-
gency
reserve
amounts
needed
• Work-
around
plans
• Corrective
action
• Project
change
requests
• Updates
to the risk
response
plan
• Risk
database
In sum, there are many sources of project risk. The best way to
address and control them is
to conduct a risk management planning process. We will discuss
the risk planning process in
terms of the outputs of the step—that is, what is produced.
5.3 Risk Identification
Risk identification helps start the process by drawing on the
team and stakeholders to list

potential risks. There are many ways to initially identify project
risks. Top management, proj-
ect sponsors, the project team, stakeholders, and customers
participate in anticipating and
addressing risks. The project manager can ask, “What can go
wrong in this project, and how
can we prevent things from going wrong and offset them if they
do?” Out of this process will
come a wide variety of potential risks that could challenge the
project team.
For instance, a member of a new product project team might
identify the risk that a competi-
tor could create a new product similar to his or her team’s and
bring it to the market faster,
at a lower price, or at a higher performance level. This potential
risk is then associated with
a task, such as initial requirements analysis and product design;
an impact, such as failure to
obtain customer acceptance; an intensity, such as a
showstopper; and a contingency action,
such as to monitor a competitor’s new product development
activities or to seek a partner-
ship should a competitor beat the team product to market.
Problems result from not identifying a task in the WBS that
later creates real risk exposure,
such as if a project manager misses a major risk in the initial
stages because of a missing
function or component. If it is not visible early, a major risk can
show up later. For instance,
a project manager may have identified a major software
engineering task in the WBS that is
not very challenging, so it is considered low risk. But the real
risk lies in the availability of a

bar81677_05_c05_149-172.indd 155 9/9/14 10:49 AM
Section 5.3 Risk Identification
key software engineer to do the work—which was not identified
in the WBS and can cause
issues later.
The risk identification process is important—if risks are not
identified early in project plan-
ning, the problems and costs of dealing with them later will
increase. Unanticipated risks dis-
rupt projects simply because the team has not thought them
through. No project team wants
to be surprised by a development that no one anticipated.
The output of risk identification is a listing of project risks and
documentation on the poten-
tial impact of each on the project. In addition, this step
describes what actions can be taken to
prevent the risk or control its impacts.
Identify Sources of Risk
All potential sources of risk must be identified. These include
indicators of possible risk
events during or after the project that could result in project
problems and even failure. Risks
are normally associated with project tasks.
For instance, in a contract negotiation in the outsourcing
process, a contractor might enter
into a contract that requires successful completion of the project
on a tight schedule even

though the contractor knows the schedule cannot be met. This
happens when contractors
assume that they can overestimate their capacity to meet a
schedule and underestimate con-
tract costs in order to secure the contract based on a low bid,
then in the middle of the project
when it is clear they cannot meet requirements, get more
funding.
The same risk can occur with any project in which the project
manager assumes the best case
in meeting requirements in order to please the customer and get
approval and funding, but in
practice cannot perform as promised.
Identify Impacts
Here the risks are reviewed to identify what impacts are
possible, from schedule slippage
to budget overruns to quality problems. This step is in
preparation for the next step, risk
analysis, where each risk is analyzed to help understand its
probability of occurring and the
severity of its impact.
Risk identification is an important step because it establishes
the agenda for later risk analy-
sis and control. It is in this step that initial ideas on how to
prevent a risk event from occur-
ring or how to control its impact is first documented. Later, in
risk response planning, these
actions are fleshed out, but it is here that connections are first
made between a project risk
and actions that might be taken to control it. If this initial
process misses big risks and actions
to control them, it can be costly down the road.

bar81677_05_c05_149-172.indd 156 9/9/14 10:49 AM
Section 5.4 Risk Analysis
5.4 Risk Analysis
Risk assessment or analysis is the process of analyzing project
risks to learn more about
them, quantify probabilities when it makes sense, and help
decide what to do about them. The
PMBOK separates the risk analysis process into two parts: (a)
qualitative and (b) quantitative.
Qualitative risk analysis connotes a better description of the
risk, its dimensions, and its char-
acteristics. Risk qualification involves listing risks and using a
risk matrix to determine how
they should be categorized and ranked according to their
impacts on schedule, quality, cost,
and overall success of the project.
Quantitative risk analysis involves getting a finer view of risk
by applying mathematical and
other quantitative tools. Quantitative assessment applies
probability and other analytic tools
such as decision trees to pin down the extent of risk and risk
impacts.
The Links Corporation Private Sector Case Study
As you will recall from the last meeting at Links Corporation,
the project goal, objective, charter,
and scope of work were proposed by the vice president of
manufacturing, Stewart Levi.

Now the vice president of project management, Desiree Aubert,
and the project manager,
Lorenzo Costa, are meeting to discuss the risks associated with
their proposed project.
Aubert is concerned about the risks involved in the new product
project. She knows that if the
manufacturing department does not accept it or its outputs, the
project will fail, since one of its
goals is to convince the department that new product projects
can be useful to them. She wants
to spend time anticipating risks that would hinder their ability
to meet this objective.
Luckily, Costa already has a plan. He plans to prepare a risk
document that summarizes the
actions of selecting and communicating the project deliverable
and how to offset any prob-
ability that manufacturing will not agree with the selection. He
knows that they must choose
the right project from the get-go and plans to include the
department in the discussion on
risks to ensure that the project is considered from their
perspective.
Costa points out that one of the key challenges will be to
anticipate how this new project will
affect manufacturing schedules. He uses the example of creating
a prototype product and the
effect that it will have on manufacturing to produce one unit for
testing. He states that the
risk is that the department will likely regard prototype
production as interfering in manufac-
turing’s revenue-producing operations.

Questions for Discussion
1. What do you think about the company’s plan to identify
risks?
2. Did they include the key risk that the manufacturing
department would not
cooperate in a project to produce a new product?
bar81677_05_c05_149-172.indd 157 9/9/14 10:49 AM
In practice, companies rarely split the two. The point of risk
analysis is to zero in on poten-
tially high-risk tasks and obtain a more detailed picture of their
impacts.
The goals of risk assessment include:
1. to increase understanding of the project; the more project
managers know about
risks, the more they know about the project;
2. to rank order risks in terms of severity and impact so that
project managers know
which to address first;
3. to serve as the basis for identifying alternative approaches to
response and risk
management and integrating risk into the risk management
process; and
4. to offset the normal tendency to be optimistic in project

planning; that is, the basic
human trait of expecting the best will take over unless you
weigh it against a risk
analysis that identifies impacts and pessimistic scenarios. A
scenario is a projection
into the future to see what might happen under given conditions,
helping manage-
ment prepare for action steps it might have to take.
Now that you have an idea of the types of risk analysis, we will
take a closer look at the quali-
tative process.
Qualitative Analysis
Qualitative risk analysis describes each risk in detail and
establishes the relative priority of
each risk, given its probabilities and impacts. The major outputs
of this type of analysis are a
risk ranking and risk description.
Risk Ranking
Once the qualitative process is finished, two rankings are
produced: (a) how the project’s
overall risk is ranked compared to others (this may be
completed by comparing and selecting
a portfolio of projects); and (b) how individual risks rank within
the project, usually limiting
the list to five or less. The list of prioritized risks is
incorporated in a project report to stake-
holders along with supportive information, including the risk
matrix and contingency plans.
For instance, a new product project in the field of remote home
controls has been selected for
approval and funding and is ranked against two other related
projects. One project is aimed at

solar home energy systems and the other at delivering new home
irrigation and landscaping
systems. Because the company has discovered a fast-growing
market in remote home con-
trols, the home control project is ranked higher than the other
two and is fully funded first.
Within the project, of the three major risks identified—market
risk, technical risk, and safety
risk—technical risk is ranked highest because of a new
discovery that the radio signals for
remote home controls can interfere with satellite TV reception;
thus, the risk exists that they
will not sell well.
bar81677_05_c05_149-172.indd 158 9/9/14 10:49 AM
Risk Description
The risk description describes risks in terms of how they might
occur and what impacts they
might have. The purpose of the description is to communicate to
the team and stakeholders
what is known about each risk and to alert the team—and
potentially the customer—to the
need to reflect each risk into their thinking about the project
and their planning. The key point
in describing risk is to communicate the risk and its impacts to
those who will have to address it.
Sometimes risks occur regardless of good planning to avoid
them. For instance, in managing
projects in the public sector, there will always be a risk of
outside interference and criticism

since almost all projects can create conflict among interest
groups.
State Department of Health and Human Services Public
Sector Case Study
When we last saw our health leaders in Chapter 4, they had a
proposed project goal, objec-
tive, charter, and scope of work.
Now the secretary, Robert Mikawa, and the assistant secretary
for programs, Rebecca Daw-
son, have scheduled a meeting to analyze the risks involved in
their project, particularly the
risk that their program and projects may fail because of the
weight of public criticism.
Dawson begins by listing the many different levels of risk in
their project, from broader
political and socioeconomic risks to operational risks. She
knows that they will be inter-
related because of the public nature of the project and their
agency. If the HHS website
does not identify and secure critical health information for
various stakeholders, it will be
a product failure and a political and program-wide failure.
Mikawa plans to create a checklist of how to position the
project for political acceptance,
while Dawson continues to evaluate risks from a project and
product standpoint. Then
Mikawa would like to integrate the two and move forward from
there. He believes one
of their challenges is to demonstrate to all stakeholders,
political leaders, and interest
groups that they anticipated all possible risks and developed

plans to address them. He
knows that if they miss any key risks, they will be criticized for
bad planning, but if they
anticipate all potential risks and involve stakeholders in
identifying them, then they can
defend their actions.
Questions for Discussion
1. The secretary mentions political risk; how does political risk
figure into risk
management?
2. What is political risk for a public agency, and how does it
differ from risks facing a
private sector organization?
Quantitative Risk Analysis
Quantitative risk analysis measures potential risks and produces
detailed data on potential
impacts. Quantitative data includes detailed impacts,
probabilities, and analysis of all impacts.
bar81677_05_c05_149-172.indd 159 9/9/14 10:49 AM
Section 5.5 Risk Response
For instance, in an IT project, quantitative analysis would
assess how a given risk—say poten-
tial incompatibility of a new system with existing platforms or
the failure of a product to pass
required performance tests—would impact management and
decision making.

This information helps calculate the risk ranking and
probability analysis of the risk occurring.
Prioritized Risk List
Based on the quantitative analysis, each risk is ranked again,
this time based on more data
and information on the risk. Sometimes the original ranking in
the risk identification pro-
cess is fundamentally changed after quantitative analysis. For
instance, a new product may
be ranked high initially because of potentially high sales in a
growing market, but after more
testing the product fails to perform to standards 10 times in 100
tests, and its ranking is
reduced and funding disapproved.
Probability Analysis
In this analysis the probabilities are worked to a finer level of
detail. A probability set at 25%
in the qualitative phase might be fine-tuned to 38% with more
input from intensive analysis of
past projects and simulations, and perhaps some experiments.
The qualitative risk is simply a
judgment made based on observations and past experiences,
with little or no real data or facts.
A project manager in an environmental cleanup project may
decide that the probability of find-
ing a toxic chemical in the process is low, say 25%, based on
comments from other project man-
agers and their experiences with similar projects. But later the
project manager finds research
in the literature that suggests a highly toxic agent is likely to
exist in the particular location of
the project. As a result, the probability is raised from 25% to
38% based on technical advice

from experts in the field. The higher the risk probability,
especially if there are potential severe
impacts, the more resources are likely to go into risk prevention
and control in the project.
Risk analysis is extremely important to project success; if the
project team does not complete
a detailed review of risks and impacts, it will not have enough
information to set priorities
and plan for risk control.
5.5 Risk Response
Risk response covers all of the possible actions to prevent or
control risks. The key purpose
of response planning is to outline preventive and corrective
actions and to incorporate those
actions in the plan.
Factors in Determining a Risk Response
There are many potential factors in determining a risk response.
These include earned value,
risk intensity, people, technology, customers, processes, costs
and benefits, and corrective
action. This is represented in Figure 5.2.
bar81677_05_c05_149-172.indd 160 9/9/14 10:49 AM
Risk
Response
People
Cost/Benefit

Technology
Customer
Processes
Earned Value:
Cost/Schedule
Variance
Risk
Intensity
Corrective
Action
Earned Value
Cost and schedule variance are key inputs to risk response,
particularly root causes. Variance
is a measure of how much a given indicator of project
performance, such as schedule or cost, is
varying from the plan. A minor (3%) variance is nothing to
worry about, but a major (15% or
more) variance suggests either that the original estimate was
inaccurate or that new factors
have changed performance from the original plan. A variance is
followed up by an analysis of
root causes—looking for what underlying factors caused
performance to divert from the plan.
The root causes of schedule slippage and cost escalation are
typically related to underlying
risks that should have been addressed in the planning process.

Risk planning should uncover
potential root causes before the final baseline schedule is
completed. Earned value can be
seen as an indicator that a risk has not been attended to; a late
wake-up call that is often diffi-
cult to address. Earned value is the measurement of whether a
project is “earning” its funding
by performing according to plan, or whether its variance from
the plan suggests a problem.
Figure 5.2: Risk response factors
Note that there are a wide variety of factors to consider in
determining a response to a given risk. This
figure helps identify a checklist of factors that would be
analyzed as a project manager considers
potential responses.
Risk
Response
People
Cost/Benefit
Technology
Customer
Processes
Earned Value:
Cost/Schedule
Variance

Risk
Intensity
Corrective
Action
bar81677_05_c05_149-172.indd 161 9/9/14 10:49 AM
Risk Intensity
Despite quantitative tools for calculating probabilities and
intensities, there is considerable
personal and professional judgment involved in aligning a risk
response with the intensity
and impact of that risk. In the end a project manager must make
the decision on the expected
value of a given decision at a key project milestone or
crossroad. Intensity is best described
by those closest to the point of impact, like customers, project
team members, and functional
and technical professionals, so they are the most accurate
sources for evaluating intensity.
People
Risk management is essentially a people issue, not a technical
or analytic issue. Project man-
agers must depend on the awareness and judgment of those
closest to the work to assess and
respond to risk. The key is placing responsibility for risk
identification and response in the
hands of those planning and designing the work early enough to
incorporate all worst-case
scenarios. Key stakeholders will respond to a culture that

encourages and enables early con-
tingency planning by anticipating risks and integrating them
into project schedules and bud-
gets. In the absence of such a culture, the organization can
deteriorate into finger-pointing
when unanticipated risks impact a project schedule or budget
(Irwin, 2008).
Technology
Technology creates risk simply because projects often involve
designing and testing new tech-
nologies or integrating new systems. New systems and products
are risky by definition and
involve key decision points based on risk. But these risks
should be addressed in the design
and testing process itself—in other words, technology risk is
integrated into every step of the
design process. For instance, in the development of a new
electronic instrument, the project
team faces the risk that the instrument will fail in tough
industrial applications. That risk is
translated into a design function to test the instrument in those
conditions, thereby respond-
ing to the risk at the point of design.
Customers
The customer is a major factor in responding to risk since it is
the customer who will likely
foot the bill for response and pay the price for unanticipated
risk impacts. Thus, the customer
must be involved in every step, from concept through
prototyping and production. The most
practical approach here is to report any risks in a project,
specifically in terms of customer
expectations. That involves a firm understanding of the
requirements and regular reporting

on progress against those expectations.
Processes
Often a key process will determine how a risk is addressed and
how risk response is man-
aged. For instance, if prototyping is built into a systems
development process, the risk of cus-
tomer rejection of the product can be offset early. It is in
defining the process that key risks
and responses are designed into the way work is done.
bar81677_05_c05_149-172.indd 162 9/9/14 10:49 AM
Costs and Benefits
Two kinds of costs occur in risk management: the costs of
responding to unanticipated impacts
of risk and the costs of planning and addressing risk proactively
as part of the process. It is
not the cost of risk response that determines next steps as much
as the relationship between
costs and benefits, as well as the timing of the response. “Pay
me now or pay me later” might
well be the guiding principle. The cost of a given product test in
the design process is likely
to be much lower than the cost of responding to a product
failure on a performance standard
that was not tested in design.
Corrective Action
Despite the best-laid plans and schedules, project management
is largely a process of midstream
adjustments and corrections based on the dynamics of a project

in progress. That means that
close monitoring of key project indicators is imperative to real-
time response to actual progress.
Corrective action, the process of continually bringing a project
in line with its performance
objectives and aiming the process to completion, is facilitated
by contingency plans already
built into the schedule in anticipation of risks and uncertainties.
Without such plans, correc-
tive actions are often ill conceived in the heat of the crisis and
often generate counterintuitive
results. What is expected as a result of a given action not only
does not happen, but other
things happen in the project as a result, which creates new
problems.
Here the project manager and team identify possible corrective
actions to prevent the risk
from happening in the first place and to correct or control its
impacts if it does occur. These
actions are sometimes called contingencies: Taking an action is
dependent on the risk event
actually occurring.
In sum, it is important to come up with responses to various
risks and plan them into the proj-
ect instead of simply reacting as they occur. This gives the
project team information that may
help in preventing risks simply by making them visible early in
the project.
Outputs from Risk Response Planning
Once the project manager knows what the project risks are
likely to be, the next step is to plan

a response, an action to prevent or control the risk. The outputs
from this step include a risk
response plan, residual risks, and possibly a contingency
reserve.
Risk Response Plan
Although a formal, written risk response plan is not always
feasible because of the cost and
effort involved, it is via the process of preparing the risk plan
that the project team actually
discovers risks, not in writing the plan. Once a project manager
is past the process of defining
risks, planning to respond, and folding the results into planning
documents such as the sched-
ule and budget, he or she “owns” those risk responses and
incorporates them into the plan.
A separate, documented risk response plan is not always
necessary. The point is to make sure
that the team thinks through what actions can be taken in the
event of a given risk and to
bar81677_05_c05_149-172.indd 163 9/9/14 10:49 AM
Section 5.6 Risk Monitoring and Control
incorporate those actions into the project plan and schedule.
The danger of relying entirely
on a document is that once it is prepared, team members may
ignore it, especially if they have
not been involved in its preparation.
Identify Residual Risks
Residual risks continue to exist after corrective action.

Sometimes residual risks are created
that were not anticipated in the original project planning
process. For instance, suppose there
is a risk in a construction project that a supplier will deliver bad
construction materials and
supplies to the site, and that risk occurs. A corrective action is
then taken to change suppliers,
but the new supplier brings on a new, unanticipated risk of late
delivery.
Assess the Need for a Contingency Reserve
A risk response plan must include the cost of response because
there is always a trade-off
between the cost of corrective action and the benefits it brings.
The cure might be more costly
than the damage from the risk impact. Sometimes a project must
be protected with a reserve
fund or insurance program so that the company is not
financially exposed from a given risk
even though it is mitigated.
5.6 Risk Monitoring and Control
The PMBOK places emphasis on monitoring controlling and
risks, but this process is again an
integral part of the project review and control process. Keeping
up with risk involves equip-
ping team members and suppliers with the tools necessary to
monitor risk and the sensitivity
to catch risk problems before they occur. It is mostly an
interpersonal process, rather than a
formal project review process.
It takes some planning and effort to monitor how risks change
as the project progresses, how
those changes affect the original risk assessments, and how they
will affect project outcomes. This

is typically done through a project review process in which
individual project risks are reviewed
as part of the broader review of the whole project. For instance,
when a software design project
has some bugs, a software design review might be scheduled,
and during the project review prior
to that design review, a checklist might be constructed to “flag”
debug issues.
The other part of the monitoring process is making sure that the
team members closest to the
job are aware of risks and communicate risk information while
the design and development
is occurring. They are the most likely to know the extent of
change in a risk assessment and
how it will impact the project.
Project Control Systems
Since one purpose of risk management planning is to control
risks and their impacts, we will
discuss the control process here. Project control implies a
systematic response that attempts
to control risks and their impacts. Below are some of those
systems.
bar81677_05_c05_149-172.indd 164 9/9/14 10:49 AM
Cost and Schedule Integration
If the project schedule is integrated with the cost estimate, or
each cost item is associated
with a project task, then when a risk associated with a task

occurs, the new costs of respond-
ing can be added to the current task costs.
Information Flow and Ties to the WBS
Baseline schedules are developed from the WBS, and schedule
and cost data are related to
particular tasks. Since costs are directly associated with tasks,
each task can be assessed in
terms of cost and schedule impacts.
Network Planning and Schedule Development
Scheduling is the most important function of project managers,
and risk determines the
amount of buffer that is withheld by the project manager based
on the probabilities of risk
occurrence and contingency action.
Project Cash Flows and Commitments
Cash flows committed beyond customer agree-
ments or contracts represent separate risks; thus,
cash flows are aligned with work performed and
scope boundaries.
Reporting Responsibilities
Project managers report risk and cost information
to top management, stakeholders, and customers;
functional managers report technical and technol-
ogy risks and costs to top management.
Outputs From Risk Monitoring
and Control
Good monitoring alerts project managers that a
risk is about to occur or has occurred. As risks actu-
ally occur, actions are taken to address them. These
actions rely on earlier listings of preventive and

corrective actions in the risk management plan, but
when bad things actually happen, the project man-
ager has to do something—sometimes quickly and
deliberately. The more plans and potential actions
have already been proposed, the easier it is for a
project manager to act and control impacts.
Monkeybusinessimages/iStock/Thinkstock
A major role in project management
is reporting the project’s current state
to key stakeholders. Reporting is an
aspect of the risk management process.
bar81677_05_c05_149-172.indd 165 9/9/14 10:49 AM
There are a number of outputs of risk monitoring and control,
including workaround plans,
corrective action, project change requests, and updated risk
response plans or risk databases.
Workaround Plans
The workaround plan is a way of avoiding the impact of a risk
by taking an action that off-
sets it. Workaround sometimes takes advantage of innovative
options to overcome or avoid
a project risk, and is often the result of outside-the-box thinking
that can be generated in a
brainstorming session. For instance, consider a project to test a
new business aircraft design
that has planned to pay the local airport fee every time it
conducts the many required tests,

but finds that the risk of higher airport runway fees has actually
happened. This increase has
made the aircraft testing too expensive for the budget, so the
workaround may be to test the
aircraft in simulations in its early stages instead of flying it
every time.
Corrective Action
Corrective action is taken when the project is not performing to
plan, according to schedule,
cost, and quality. Corrective actions could include changes in
the schedule or budget, changes
in task assignments, or actions to train or even replace team
members. Corrective action is
an adjustment in how the project is managed based on the
occurrence of risk events that
threaten the project.
Project Change Requests
Often in monitoring, there is a need to fundamentally change a
project scope or key deliver-
able, which triggers a change request. This corrective action is a
formal one that may result in
a new set of plans, requirements, schedules, budgets, and
assignments.
Update the Risk Response Plan
Updates to the risk response plan result from lessons learned in
the monitoring process. As a
result of monitoring data on project progress, the plan of
response is typically updated.
Update Risk Database
The risk database, or the documentation of project risks,
impacts, and potential corrective
actions, is usually an electronic documentation of risk

information that is useful in designing
corrective actions and in identifying lessons learned for future
projects. Updating the risk
database involves entering new data and analyzing it for new
impacts. For instance, if a risk
database on a military surveillance software product is updated
to reflect new threats from
terrorists that involve new security-breaching technologies, the
risks inherent in the new
technologies and their impacts on schedule, cost, quality, and
overall performance must be
analyzed and corrective actions reevaluated.
bar81677_05_c05_149-172.indd 166 9/9/14 10:49 AM
Summary and Resources
In sum, the risk management process involves systematic steps,
but the actions involved in
these steps should be integrated and embedded in the project
process, rather than exist sepa-
rately from them. The whole idea of risk management is to
enable good decision making to
address risks, not simply to document them.
Chapter Summary
• Risks are uncertainties that could affect project success.
• Risks can have a variety of impacts on schedule, cost, quality,
and other measures of
project performance.
• It is important to find the root causes of risks so these risks

can be controlled at
the source.
• The steps in risk management planning are identification,
analysis, response, and
monitoring and corrective action.
• Risk identification is the process of anticipating risks and
documenting them.
• Risk analysis helps to define and describe a project risk and
its impacts in detail so
that it is easier for the team to determine preventive or
corrective action.
• Qualitative risk analysis describes and ranks risks in terms of
their impacts and costs.
• Quantitative risk analysis involves actually testing the risks to
get more detailed
information on impacts and probabilities.
• Risk response is the process of determining what actions to
take to adjust the proj-
ect either to prevent or control the risk.
• Risk monitoring is the process of monitoring, or tracking, the
project to make sure
any major variances are identified early and controlled.
• Corrective actions are actions that can prevent or control
risks, and they include
changes in schedule, resources, budget, materials, processes,
documents, and
team composition.
Posttest

1. Risks related to managing work and the project cycle are
called __________.
a. product risks
b. scale risks
c. technical risks
d. process risks
2. Risk is best understood as __________.
a. separate from the process of management
b. an integral part of business and planning
c. an unfortunate but unavoidable rare occurrence
d. a common problem that is nonetheless preventable
bar81677_05_c05_149-172.indd 167 9/9/14 10:49 AM
3. Which of the following is a reason the author suggests the
PMI’s PMBOK framework
needs updating?
a. The PMBOK underemphasizes quantitative tools for risk
management.
b. The current PMBOK guide places too much emphasis on the
human element of
the risk process.
c. The PMI’s guide does not cover how to plan for risk when
necessary inputs are
missing.
d. The PMBOK’s focus on process is practical in work settings
but not useful for

ensuring discipline and quality.
4. The BEST way to avoid scope creep, a major risk in any
project, is to __________.
a. allow team members and contractors to add tasks to the
project as needed
b. use a realistic timeline and cost estimate to create the project
schedule
c. focus only on high-risk, resource-consuming tasks
d. make sure the WBS is well prepared and complete
5. On which documents is risk identification generally based?
a. qualitative or quantitative analysis results
b. risk management plan or WBS
c. strategic plan or meeting notes
d. probabilistic analysis of the project
6. Identifying risk impacts is the step before __________.
a. risk analysis
b. risk correction
c. risk identification
d. risk reporting
7. Which of the following is NOT a goal of risk assessment?
a. Understand the project better.
b. Prioritize the order in which risks should be addressed.
c. Determine different approaches to respond to risk.
d. Improve the optimism in project planning.
8. __________ risk analysis involves describing risks to learn
more about them, whereas
__________ risk analysis includes categorizing and ranking
risks based on their antici-
pated impacts.
a. Quantitative; qualitative

b. Assumptive; sensitivity
c. Qualitative; quantitative
d. Sensitivity; assumptive
9. In risk response, plans for corrective action should be
__________.
a. incorporated into baseline schedules so corrections are not
considered changes
later on
b. prioritized so that only the corrective actions that least
affect project costs are
undertaken first
c. simulated using mathematical representations so that project
managers can see
how effective they will be
d. linked to the optimistic estimates of duration in a PERT
analysis to make sure
risks that are only potential do not distort the schedule
bar81677_05_c05_149-172.indd 168 9/9/14 10:49 AM
10. The BEST way to make sure all worst-case scenarios are
considered and planned is
to __________.
a. use data-precision ranking to determine how the project’s
overall risk compares
to others

b. test assumptions by confirming that the assigned risk
probability is a good
estimation
c. incorporate the risk causes common to the industry into all
risk planning
d. place responsibility for identifying risks in the hands of
those closest to the work
early on
11. Project control is defined as __________.
a. managing the flow of information to stakeholders
b. using a systematic response to control risk and its impact
c. maintaining the baseline schedule and cost estimate
d. employing a hierarchical structure to meet a project’s needs
12. Which of the following is an output that may result from the
risk monitoring and
control process?
a. a list of prioritized risks
b. a project change request
c. a probability of achieving the cost and time objective
d. an overall risk ranking for the project
Review Questions
1. How is risk identified, categorized, and documented in the
project planning process?
2. What is the difference between uncertainty and risk?
3. What is the difference between qualitative and quantitative
risk assessment?
4. What are the key steps in project risk management according
to the Project Manage-

ment Institute’s PMBOK?
Think About It! Reflective Exercises to Enhance Your Learning
1. Choose a project and identify the risks.
2. Associate the risks listed with specific tasks in the WBS.
3. Prepare a risk matrix and include all risks and required
information to complete
the matrix.
Additional Resources
Barkley, B. T. (2004). Project risk management. New York:
McGraw-Hill.
Project Management Institute. (2012). Practice standard for
project risk management. New
York: Author.
An article on project risk management that emphasizes early
identification and analysis of
risks: Symonds, M. (2013). Risk management for project
managers. Retrieved from Project
Management Hut website: http://www.pmhut.com/risk-
management-for-project-managers
bar81677_05_c05_149-172.indd 169 9/9/14 10:49 AM
http://www.pmhut.com/risk-management-for-project-managers
Answers and Rejoinders to Chapter Pretest
1. True. A good method for beginning to think about a project’s
risks is to ask the proj-

ect team and top management to brainstorm, either in a meeting
or electronically, a
list of things that might go wrong with a particular project and
what could be done
about these possibilities.
2. False. The PMI’s PMBOK is a good guide for project risk
management. The process of
risk management consist of six steps, which include risk
planning, identifying risk,
qualitative risk analysis, quantitative risk analysis, response
planning, and monitor-
ing and control.
3. True. As the project progresses, unplanned risks that arise
can disrupt the project
because the team has been taken by surprise and will need to
take time to address
them, which can impact the cost of the project.
4. True. A risk matrix ranks all risks in terms of severity. It is
possible for a risk that is
very likely to occur to have a low severity ranking if it would
not greatly affect the
project’s cost, schedule, or deliverables. On the other hand, it is
possible for a risk
that has a low probability to occur to have a high severity
ranking if it were to occur.
5. False. A formal response plan cannot always be drafted, due
to constraints of cost
and effort. However, more important than having a written plan
is the incorpora-
tion of risk into the project schedule and the expected,
optimistic, and pessimistic
estimates.

6. True. Risk management involves documenting, tracking, and
organizing risk data.
This information is commonly stored electronically. Updating
the risk database can
help determine decisions to address problems and can be used to
plan future proj-
ects better.
Answers and Rejoinders to Chapter Posttest
1. d. While product risks are related to a product’s performance
and possible failure,
process risks have to do with the project life cycle and all the
risks involved in
managing the work.
2. b. Another way of thinking about risk is that it simply means
the things that can go
wrong. These things should be anticipated and addressed when
work is defined
and scheduled, and in fact, they are the reason that projects are
planned in the
first place. Thus, risk is central to doing business and to
planning.
3. c. The PMI’s PMBOK guide emphasizes methods and
process for managing risk will
be in place. However, this is not always the case in practical
work settings.
4. d. The scope of work should define all of the work needed to
complete the project
in a WBS. To make sure tasks outside the WBS are not added
later in the project
process, a thorough WBS takes into account the perspectives of

the team, stake-
holders, customers, and top management.
5. b. If a risk management plan has been created, it is used as
the major input to risk
identification. If there is no risk management plan, the
identification of risk usu-
ally begins with review and finalization of the WBS.
6. a. Identifying risk impacts is an important stage in risk
identification because it pre-
cedes the next step of risk analysis in the risk management
process. Identifying
impacts considers how risks can affect the project schedule,
budget, and quality.
During risk analysis, each of these risks are further analyzed to
assess the prob-
ability that the risk will happen and how severely it can impact
the project.
bar81677_05_c05_149-172.indd 170 9/9/14 10:49 AM
7. d. One of the goals of risk assessment is to offset the human
trait of expecting the
best outcomes for a project. Implementing risk analysis can help
identify prob-
lems that can occur, their impacts, and possible solutions to
address these prob-
lems, which can improve the overall success of the project.
8. c. The risk analysis process is composed of two parts:
qualitative and quantitative. In

qualitative risk analysis, the dimensions and characteristics of
the risk are defined.
In quantitative risk analysis, the risks are listed and a risk
matrix is used to catego-
rize and rank risks according to how they might affect the
project’s success.
9. a. The project manager should outline corrective actions and
incorporate them into
the baseline schedule to prevent them from being viewed as
changes or addi-
tional tasks in the future. Later on, corrective actions can be
included in the pes-
simistic duration estimates in the PERT analysis.
10. d. In assessing and responding to risk, the project manager
has to rely on the judg-
ment and awareness of the people closest to the work. Doing
this early in the
process is essential so that all possible risk can be identified
and planned for.
11. b. Project control is not the use of a command-and-control
organizational structure,
nor the control of information or even schedule. Instead, it
implies a systematic
attempt to control risk and its impact on a project by using
cost–schedule integra-
tion, network planning, schedule development, and project cash
flows and com-
mitments, among other methods.
12. b. In the risk monitoring and control process, a plan for
responding to previously
identified risks is in place, and the project is being monitored so
corrective action

can be taken as needed. This can lead to project change
requests, since monitor-
ing may uncover the need to change a project’s scope or key
deliverable. The
other outputs listed here tend to result from the earlier stage of
risk analysis, in
which more is learned about risks that have been identified.
Key Terms
earned value A term used to represent, in
dollar terms, what portion of a project task
has been completed successfully.
process risk Uncertainties on how long a
given process or procedure such as product
testing will take and whether it will be suc-
cessful, leading to a project risk of schedule
delay or inadequate quality control.
product risk Uncertainty that the product
deliverable will meet customer performance
requirements even if it passes testing.
risk assessment The process of reviewing
and analyzing risks to identify intensity of
impact, probability, and contingency actions
to prevent or control the risk.
scenario A graphic projection or “scene” of
the way things might work in the future for a
project in order to anticipate problems and
identify corrective actions before they occur.
bar81677_05_c05_149-172.indd 171 9/9/14 10:49 AM

bar81677_05_c05_149-172.indd 172 9/9/14 10:49 AM
13 Monitoring and Corrective Action
Chris Clinton/Digital Vision/Thinkstock
Learning Objectives
By the end of this chapter, you will be able to:
• Explain the purpose of project monitoring.
• Participate in the project monitoring process.
• Perform the four types of corrective actions.
• Describe the project monitoring model.
• Provide project reports for stakeholders, top management, and
the project team.
• Prepare for a phase-gate review.
• Discuss current trends in project monitoring.
CO_CRD
CN
CT

CO_LO
CO_TX
CO_BL
co-cn
co-cr
co-box
co-intro
co-photo
co
bar81677_13_c13_391-422.indd 391 9/11/14 10:45 AM
Introduction
Pretest
1. The PMBOK guidelines assume that following guidelines and
correctly monitoring a
project will lead to the project staying on track.
a. True
b. False
2. Costing less than estimated is a clear indicator of a project’s
success.
a. True
b. False

3. A project manager will sometimes choose not to make any
adjustments to schedules or
cost estimates, even when variance from that schedule or
estimate has occurred.
a. True
b. False
4. If customer requirements are being met, it is safe to assume
the customer is satisfied.
a. True
b. False
5. Project managers can never provide too many status reports
for stakeholders.
a. True
b. False
6. Projects are reviewed after each phase so that bad projects
can be stopped before they
use up too many resources.
a. True
b. False
7. Today task leaders have become less likely to gather data and
make routine reports.
a. True
b. False
Answers can be found at the end of the chapter.
Introduction
Whether or not something goes wrong in a project, project
managers need to keep the team
and various stakeholders aware of project progress. In addition,
the project manager must

make changes and adjustments in the project when things are
not going as planned. The only
way the project manager is going to know how things are going
is to design and conduct
a monitoring process that tracks key indicators in the project—
and takes corrective action
if necessary. Monitoring is not easy if you have not first
planned to collect information on
important aspects of the project, such as schedule, cost, and
quality. Some stakeholders may
have special interests that require tracking other measures such
as product test results or
contractor performance. If project managers and teams are not
keeping track of how the proj-
ect is performing, then it is difficult to know what to do when
things go wrong or vary sub-
stantially from the plan. The purpose of a monitoring and
corrective process is to make sure
you know how a project is performing and that you have
thought through actions you can take
to solve problems as they become clear through the monitoring
process.
H1
sec_n sec_t
bar81677_13_c13_391-422.indd 392 9/11/14 10:45 AM
Section 13.1 Project Monitoring
This chapter covers the monitoring process, including how to
set up a monitoring process and
measures to track what kinds of corrective actions are typical,

how to report on monitoring
data, and how to conduct a phase-gate review after each project
phase is completed. Monitor-
ing feeds the project decision process because it is a systematic
source of facts and data on
the project.
13.1 Project Monitoring
We will first address how a project is tracked, called the
monitoring process. Preparing the
monitoring system is important because project managers need
to collect the right informa-
tion to see how the project is performing.
Project Monitoring Versus Evaluation
This chapter will address project monitoring, and Chapter 14
will cover evaluation. Moni-
toring and evaluation are closely related, but there is a basic
difference. Monitoring is the
process of tracking progress and identifying necessary
adjustments during the course of the
project. Its results feed decision making and, later, evaluation.
It is conducted in close contact
with the project execution process to determine if the project is
on track and what unantici-
pated changes have occurred.
Evaluation involves stepping back from a project after its
completion and assessing which
outputs and outcomes were produced—and how efficiently and
effectively they were pro-
duced. It involves more analysis and a broad perspective on
project objectives, outcomes,
benefits, and impacts. Evaluation addresses the anticipated
outcomes and unexpected, unin-

tended consequences.
Table 13.1 outlines the differences between project monitoring
and project evaluation.
Table 13.1: Monitoring and evaluation: A comparison
Project monitoring Project evaluation
Tracks key indicators during the execution phase Conducted at
end of project to assess achievement
of project goals, impacts, and outcomes
Focused on variances from schedule, budget, and
other plans
Focused on whole project and achievement of
project goals, objectives, impacts, and sustained
outcomes
Emphasis on inputs, milestones, problem solving,
trends, risks
Emphasis on customer satisfaction, benefits and
costs, overall contribution to enterprise growth and
profitability
Links project activities to outputs, efficiency Links project
deliverables to achievement of goals,
impacts, outcomes, and integration with other proj-
ects in the enterprise portfolio
continued
bar81677_13_c13_391-422.indd 393 9/11/14 10:45 AM

Section 13.1 Project Monitoring
Project monitoring Project evaluation
Starts with baseline plans, schedules, budget, and
risk management plan
Starts with review of impacts, outcomes, and
linkage to project activities regardless of original
baseline
Tracks functional support issues such as procure-
ment, finance, configuration management, and
production
Tracks functional support indicators to see how
they contributed to overall project success
Conducted by project manager and team Conducted by outside
interests such as stakeholders
and academic evaluators
Links to program control and process Links to enterprise
strategy, policy, and long-term
plans
Produces lessons learned for project management
process and managing the project right
Produces lessons learned for choosing the right
projects
Now that we have explored the differences between monitoring
and evaluation, we can now

dive into the monitoring process, the central theme of this
chapter.
The PMBOK Guidelines on Project Monitoring
The PMBOK includes a section called “Monitor and Control
Project Work” in its project inte-
gration process. This involves setting up a project to monitor
key measures of progress.
Monitoring is presented as a combination of expert judgment,
analytic techniques, project
information, and meetings. It produces change requests, work
performance reports, a plan,
and document updates as its outputs.
The PMBOK indicates that monitoring focuses on:
1. comparing actual project performance against the project
management plan;
2. assessing performance to determine whether any corrective or
preventive actions
are indicated, and then recommending those actions as
necessary;
3. identifying new risks and analyzing, tracking, and monitoring
existing project risks
to make sure the risks are identified, their status reported, and
the appropriate
response plans are executed;
4. maintaining an accurate, timely information base concerning
the products and their
associated documentation through project completion;
5. providing information to support status reporting, progress

measurement, and
forecasting;
6. providing forecasts to update current cost and schedule
information;
7. monitoring implementation of approved changes as they
occur; and
8. providing appropriate reporting on project progress and status
to program man-
agement when the project is part of an overall program (Project
Management
Institute, 2013).
Table 13.1: Monitoring and evaluation: A comparison
(continued)
bar81677_13_c13_391-422.indd 394 9/11/14 10:45 AM
Section 13.2 Project Monitoring Process
The PMBOK guidelines do not address project evaluation per se
or equate it with monitoring
and review, because the writers of the guidelines see any major,
postmortem evaluation to be
beyond the control and responsibility of the project manager
and team. The PMBOK assumes
that if a project is monitored correctly and guidelines are
followed in initiation and planning,
accurate reading of monitoring and performance indicators will
lead to actions that realign
the project with the baseline, or close to it. If change and
monitoring trends suggest major
restructuring and change order action, and if the project

manager acts appropriately to find
root causes and fix them, then the completed project will align
with the revised baseline plan.
The PMBOK also sees the major purpose of a project as
production of outputs and deliver-
ables that satisfy customers according to the project goals,
requirements, and scope of work.
Any long-term impacts and outcomes beyond the immediate
closeout and final project review
are left to other parties and interests beyond the project itself.
13.2 Project Monitoring Process
Project monitoring is the continuous process of watching the
project to see where it is headed
and set the stage for corrective action if necessary. Corrective
action is the process of taking
steps that are designed to adjust a project that is off course and
put it back on course. The
monitoring process parallels the execution process. Monitoring
involves the following steps:
1. Establishing priorities in terms of project goals. This means
asking questions to
determine what the main priorities are. For example, it is
important to establish if
the main priority is to deliver the product on time and within
budget or to build a
long-term relationship with the customer even if it means
overrunning the budget
and absorbing the loss of profit margin.
2. Setting up the project plan, objectives, and performance
indicators, as well as a
supporting information system so that the right data can be
gathered and analyzed.

This is sometimes called data analytics. Indicators are measures
of a key aspect of
the project; a key indicator of overspending could be the
existence of high volumes
of unused supplies and materials. Data is quantified
information, usually presented
in terms of numbers and figures; the data performance on a
given task is presented
in percent complete.
3. Looking back to the project plans and documents to
determine which aspects of the
project were not anticipated in the planning phase, called
change management or
variance analysis.
4. Determining what needs to be corrected or adjusted, which is
known as corrective
action or project adjustment.
5. Identifying what risk events are occurring that need to be
mitigated, which is called
risk management and contingencies.
6. Looking forward to the remaining work and cost to complete,
which is called for-
ward mapping.
7. Keeping in touch with stakeholders and customers and
collecting their feedback,
also known as customer or stakeholder relationship
management.
Monitoring data is shared with stakeholders through electronic
tools such as e-mails, tele-
conferences, and text messaging. If there are major implications

generated by tracking data,
bar81677_13_c13_391-422.indd 395 9/11/14 10:45 AM
a phone call to key top managers, project sponsors, and
stakeholders may be in order. The
data is stored in project software and may also be stored in a
cloud system by a contractor
if appropriate.
Preparing for Monitoring in the Planning Process
To illustrate how monitoring is integrated into a project, we
will show how the project man-
ager handles the process using the example of a new town hall
project. The project has been
planned using the PMBOK process, including a project
management plan with schedule and
budget in a project management software program, risk
management plan, and other associ-
ated plans for communication, stakeholder management, and
project integration. To set up
the project for monitoring, the project manager has established
a project baseline, starting
task plan, schedule, and budget that will serve as the base for
project execution and monitor-
ing. Everything will be measured against the baseline.
The project manager has briefed all team members on their
responsibility to enter actual
durations for their tasks at given points so that variance can be
calculated. The team is also

trained in the use of electronic time sheets that have been
integrated into the project manage-
ment software program so that actual task durations and costs
will be entered by each team
member at designated points to support monitoring. In addition,
project cost capture codes
have been set up to document all acquisitions and related costs
incurred by functional depart-
ments supporting the project and to integrate them into the
project management program’s
cost templates by task.
A defined process for monitoring has also been established.
Progress will be reviewed infor-
mally every 2 weeks, with formal project data pulls and reviews
every 4 weeks. A project
management information system network has been set up to
enable all team members to
have full transparency and access to project data.
In the early stages of the project planning process, a small
project task force including team
members and IT staff was created to establish the data gathering
and analysis process to
support monitoring. The group recommended that the key
project objective was to complete
a new town hall (the deliverable) for turnover to the city in 12
months, on time and within
budget. The customer signed off on the baseline to confirm the
project’s starting point.
Key indicators of progress and associated data needs were
established based on the proj-
ect manager’s previous experience with town hall projects.
Three key indicators were deter-
mined to be drivers of project success. A driver indicator is a

determining factor of project
success based on previous, similar projects. Monitoring these
key indicators can help the
project manager see early indications that the project is on
track. The assumption is that if
these indicators are going well, the project will succeed. If they
are not on time and within
budget, the project will be late.
In this project it was decided that in addition to the regular
monitoring of schedule, budget, and
quality, three key indicators would be closely tracked: (a)
construction blueprints, (b) building
wiring completion, and (c) customer acceptance. If these tasks
are successfully finished on time
bar81677_13_c13_391-422.indd 396 9/11/14 10:45 AM
Task Name FinishStartDuration
15 days
40 days
50 days
14 days
221 days
30 days
30 days

Milestone (0 days)
10 days
15 days
16 days
20 days
10 days
1 day
15 days
60 days
60 days
15 days
1.1
2.1
1.2
1.3
2.2
2.3
3.8
3.1

3.3
3.5
3.2
3.4
3.6
3.7
1.2 Initial concept design
1.0 Prepare Facility Concept
2.0 Plans
2.2 Final blueprint
3.0 Construction Plans and Installation
3.2 Supply delivery
3.4 Complete HVAC duct work
3.6 Complete wiring system installation
1.3 Final concept design
1.1 Requirements
2.1 Draft blueprint
2.3 Blueprint complete

3.1 Supply acquisition
3.3 Complete foundations
3.5 Complete wiring diagram
3.7 IT systems installation
3.8 Final building installations
3.9 Customer acceptance
Predecessors
08/15/18
08/30/18
09/10/18
10/01/18
11/06/18
11/17/18
01/02/19
02/19/19
09/01/18
07/30/18
09/10/18
10/15/18

11/06/18
12/31/18
02/03/19
02/20/19
04/21/19
06/22/19
09/01/18
09/10/18
11/05/18
10/14/18
07/07/18
12/30/18
02/02/19
02/19/19
09/10/18
08/14/18
10/01/18
11/05/18
11/16/18

01/01/19
02/18/19
04/20/19
06/21/19
07/19/19
iDriver Project MilestoneID FinishStart
3
1
2
Customer Acceptance
Complete Blueprint
Complete Wiring System
06/22/19
10/15/18
02/19/19
07/07/19
11/05/18
02/19/19
and within budget, the assumption is that the project will likely
succeed. This does not mean

other indicators are not monitored, but the project manager will
give special attention to data
on these measures.
Figure 13.1 shows the basics of the town hall project schedule
from a high level.
The project schedule shows these three driver milestones in
Figure 13.2.
Figure 13.1: Town hall construction project: High-level project
schedule
This Gantt chart shows the basics of the town hall project
schedule.
Adapted from Smartsheet.com.
Task Name FinishStartDuration
15 days
40 days
50 days
14 days
221 days
30 days
30 days
Milestone (0 days)

10 days
15 days
16 days
20 days
10 days
1 day
15 days
60 days
60 days
15 days
1.1
2.1
1.2
1.3
2.2
2.3
3.8
3.1
3.3

3.5
3.2
3.4
3.6
3.7
1.2 Initial concept design
1.0 Prepare Facility Concept
2.0 Plans
2.2 Final blueprint
3.0 Construction Plans and Installation
3.2 Supply delivery
3.4 Complete HVAC duct work
3.6 Complete wiring system installation
1.3 Final concept design
1.1 Requirements
2.1 Draft blueprint
2.3 Blueprint complete
3.1 Supply acquisition

3.3 Complete foundations
3.5 Complete wiring diagram
3.7 IT systems installation
3.8 Final building installations
3.9 Customer acceptance
Predecessors
08/15/18
08/30/18
09/10/18
10/01/18
11/06/18
11/17/18
01/02/19
02/19/19
09/01/18
07/30/18
09/10/18
10/15/18
11/06/18

12/31/18
02/03/19
02/20/19
04/21/19
06/22/19
09/01/18
09/10/18
11/05/18
10/14/18
07/07/18
12/30/18
02/02/19
02/19/19
09/10/18
08/14/18
10/01/18
11/05/18
11/16/18
01/01/19

02/18/19
04/20/19
06/21/19
07/19/19
Figure 13.2: Key milestones in town hall construction project
Key milestones in the town hall construction project include
completing the blueprint, completing the
wiring system, and achieving customer acceptance.
Adapted from Smartsheet.com.
iDriver Project MilestoneID FinishStart
3
1
2
Customer Acceptance
Complete Blueprint
Complete Wiring System
06/22/19
10/15/18
02/19/19
07/07/19
11/05/18

02/19/19
bar81677_13_c13_391-422.indd 397 9/11/14 10:45 AM
Monitoring During Execution
During execution, the project manager collects monitoring data
on project progress, such
as schedule and cost information, then interprets the data,
prepares reports, and discusses
issues with the appropriate people. The process is ongoing, and
the project manager will
regularly refer to monitoring data on key measures before
acting.
The project manager uses monitoring results to take corrective
action if necessary. If results
show schedule or cost variance, the project manager drills down
to understand what is really
happening. If the results are positive, such as if positive cost
variance indicates that the proj-
ect is saving money and will contribute to the margin, the
project manager does not immedi-
ately assume that this is good news, because the positive
variance could be the result of bad
workmanship or bad cost estimates. The project manager must
ensure that the cost savings
is not an indication of lower quality, but rather the result of real
efficiency in accomplishing
the task.
The project manager is constantly asking, “What is going on in

this project, what things are
happening that we did not anticipate, and how do we see the
changes before they hurt us or
before we miss opportunities to exploit them?” and “What can
be learned from the moni-
toring process for this project and future ones?” If the project
manager has the benefit of
past experiences with similar projects and can conclude from
the earlier project profiles and
State Department of Health and Human Services Public
Sector Case Study
As we return to HHS, the secretary, Robert Mikawa, meets with
the assistant secretary for
programs, Rebecca Dawson, and project manager, Shannon
Adams, to discuss a monitor-
ing program for their health records project.
Mikawa asks Dawson and Adams who will oversee the project
and monitor performance
at a department level. He wants to ensure that they know what is
happening in the project
and are not surprised by any issues that arise.
Adams informs him that they plan to institute a macro-
monitoring system that looks at
high-level indicators from more detailed projects. They will
require all partner teams in
the project to monitor performance against a common set of
indicators in addition to their
own measures, and they will use the high-level indicators to
track how the overall project
is going. She plans to monitor overall schedule or cost
variations from the plan by 25%,
problems that have not been resolved and need a broader view,

problems that involve
network partners, and successful decisions (best practices).
Dawson thinks this is a good plan but asks Adams how she can
ensure the quality of the
assessment at this portfolio level of projects. She reminds
Adams of the errors and varia-
tions in data that could occur before getting the results.
Question for Discussion
1. How do you think Adams should track quality?
bar81677_13_c13_391-422.indd 398 9/11/14 10:45 AM
lessons learned that there were key indicators, or drivers, of
project success in all of these
projects, the emphasis in monitoring is targeted on those
indicators.
There must be a balance between quantitative and qualitative
measures in project monitor-
ing. Quantitative measures reduce the subjectivity of the review
and base conclusions on
numbers and facts. The more facts and quality data are
integrated into the monitoring pro-
cess, the more the project manager can rely on them.
Qualitative measures are also important and may not be
captured in data gathering. Quali-
tative measures are physical or social indicators of project
progress, such as customer sat-

isfaction or team morale, that are important but difficult to
quantify. Qualitative measures
sometimes suggest problems that quantitative indicators do not,
such as the extent to which
a customer may have lost interest in a project or lacks
confidence that it will be successful.
For instance, if a task leader is not communicating about task
performance and does not
appear to be engaging the task members in project reports and
activities, the project manager
will need to act on this soft but real indicator of a problem. And
if a project manager receives a
report on task performance for an earned value analysis that
suggests 100% completion of a
task before it is due, the project manager must be aware of the
possibility that the task is not
actually finished. This is a sensitive piece of project manager
responsibility since question-
ing the quality or integrity of a task leader report on progress
can be debilitating to the task
leader and team if it turns out to be unwarranted.
Data Collection
Sometimes, monitoring involves the analysis of hard data that
targets specific indicators and
quantifies performance. Other times, the monitoring process
requires an intuitive sense that
helps management anticipate project problems and the need for
preventive change. The focus
of project monitoring is determined by the particular interest
and interpretation of success.
Whereas one stakeholder may be more interested in scheduling,
another may be more inter-
ested in profit margin and avoiding overruns. A third party may

be more interested in the
quality of the product deliverable and is not worried about time
or cost. The traditional proj-
ect manager is focused on delivering a quality product on time
and within budget, but other
factors can determine project success.
In the process of selecting indicators, the project manager will
look to two kinds of indica-
tors: time driven and event driven. A time-driven indicator is a
measure such as a mile-
stone that is triggered at a given point in the project and
generates monitoring information
on that milestone. A measure is the actual data point for an
indicator. For instance, whereas
a project manager may be looking for an indicator of project
quality, the technical measure
that is gathered in monitoring to support that indicator might be
actual product test results.
A time-driven indicator is scheduled and conducted to take a
snapshot of the project on that
date, regardless of other indicators.
An event-driven indicator is a measure that is driven by an
event or unanticipated and dis-
ruptive change, such as if a risk event occurs, a supply
deliverable is not delivered, or a team
member leaves the team. Time-driven indicators must be
addressed when planning the moni-
toring system, but the project manager must be ready to deal
with unanticipated event-driven
bar81677_13_c13_391-422.indd 399 9/11/14 10:45 AM

indicators when they occur. A formal change order process is a
useful tool to give the project
manager a process to respond to event-driven indicators.
The project manager must also be sensitive to the cost of data
collection and relate costs
to benefits. Obtaining finely tuned and accurate data quality
may satisfy the need to “know
everything,” but it may cost more than it is worth to collect.
Thus, trade-offs are made in the
decision to collect indicators. For instance, if the test technician
indicates that the product is
not likely to meet requirements after data is gathered from a
preliminary test, fine-tuning the
data so that it can be presented in more detail is not necessary
to generate corrective action.
Data Points
Data points are times in the project when monitoring data are
gathered for analysis. Data
points are usually associated with the dates on which key
milestones are completed or in
preparation for project reviews. Data can be in the form of
quantitative measures of quality
or process, dates and transactions, or technical details on an
intermediate or final deliverable.
Here are some of the key data points for the town hall project.
1. Blueprints complete; data to be pulled (gathered) for
monitoring on November 5,
2018, include:
a. Planned start and finish dates in baseline schedule
b. Actual start date for blueprint task
c. Actual finish date for blueprint task

d. Quality control and technical acceptance for blueprint
graphics and document
e. Narrative comments from blueprint task leader and drafter
f. Source: blueprint task leader and quality control staff in PMO
2. Wiring complete; data to be pulled on February 19, 2019:
a. Planned start and finish dates in baseline schedule
b. Actual start date for wiring task
c. Actual finish date for wiring task
d. Quality control and city code approval and signature for
wiring
e. Narrative comments from wiring contractor
f. Source: wiring contractor and quality control staff in PMO
3. Customer acceptance; data to be pulled on July 7, 2019:
a. Planned start and finish dates in baseline
b. Actual start date for customer acceptance
c. Actual finish date for customer acceptance
d. Customer sign-off confirming acceptance
e. Narrative from customer on project outcome
f. Source: project manager
4. Pull actual labor and resource costs from Microsoft Project®
and the financial
accounting system to calculate cost variance by comparing
BCWP to ACWP. (Remem-
ber that BCWP − ACWP = cost variance, and if negative it
indicates a cost overrun.)
5. Calculate schedule variance by determining the percent
complete from task leaders
on work performed to date and comparing the BCWP, based on
percent complete, to
BCWS. (Remember that BCWP − BCWS = schedule variance,
and if negative it indi-
cates a schedule delay.)

bar81677_13_c13_391-422.indd 400 9/11/14 10:45 AM
This case reminds us that variance analysis, or discovering
whether the project is on schedule
and within budget, tends to focus backward on the original plan
and schedule. This tendency
can mask the real issue, particularly how the remaining work
should be scheduled and bud-
geted to complete the project on time and within budget. If
there have been major changes
and shifts in the project that make the baseline schedule
unworkable, then simply trying to
bring the project into alignment with a bad baseline will not be
effective.
The project manager has to understand this problem and create a
new plan, with a revised
schedule and budget, and perhaps an updated task structure, to
look ahead to completion.
This proactive move will also help shift the team’s focus from
how to stay with the original
plan to how to complete the remaining work, given the changes
that have occurred.
This case has been made simpler than a project might be in the
real world, but the point
remains that project managers must set up a project for effective
monitoring during the plan-
ning process. If the project is not set up correctly by focusing
on what is to be measured and
how, when it comes time to monitor those measures, the data

will be difficult, if not impos-
sible, to gather.
For special, in-depth reviews, the monitoring process supports a
full-effort data analysis to
prepare for review. To accomplish a special analysis such as a
phase-gate review, the process
of data gathering, analysis, reporting, and agenda setting may
be handled by the PMO working
with the team.
Earned Value
Earned value is a traditional project performance measure that
has been emphasized by the
PMBOK for years. Earned value is the process by which a
project stays on schedule and within
budget. If the project varies from the schedule or budget, this is
termed schedule and cost
variance—two measures of earned value. Earned value is
frequently used because it sepa-
rates performance on schedule from cost (Fleming &
Koppelman, 2010).
Projects may be performing well on one measure but not on
another. It is normal for a project
to be ahead of schedule but have negative cost variance because
the expenses are much more
than anticipated (Fleming & Koppelman, 2010). On the other
hand, it is also common for a
project to be behind schedule but have positive cost variance
because the spending rate is
consistent with the planned costs for slower progress at that
point in the project.
Earned value helps the project manager and team look at both
measures before determin-

ing the overall performance of the project. The downside of
earned value is that it assumes
that the original schedule and cost estimate were correct, and it
looks backward to align
with them rather than learning from the factors that changed the
performance of the proj-
ect from the original plan and looking forward by rescheduling
the remaining work. In addi-
tion, a limitation of earned value is that the project manager
must ask the task leader for
the percent complete for the task to calculate earned value and
relate percent progress to a
budget number for that exact percent complete.
It is important to understand that an accurate assessment of
earned value is difficult, given
the problem of identifying the actual budgeted cost of the
project at the review point and the
bar81677_13_c13_391-422.indd 401 9/11/14 10:45 AM
additional problem of determining the percent of work
completion at that point. But earned
value is important, because it helps the project manager and the
team look at the two mea-
sures separately.
Regardless of the limitations of earned value as an indicator, it
is important for tracking the
project because substantial variance from the baseline schedule
and budget is an important
trend. Variation can indicate that the original baseline was

wrong in predicting the durations
and sequences of tasks, or it can indicate that the work is not
progressing as planned because
of other root causes. In either case earned value is an important
mindset for those doing the
job. Team members should be aware that a task is not shaping
up as planned and that this
development should be flagged early. It is not easy for a task
manager to admit that the task
is taking longer than planned, simply because it may reflect on
that manager’s commitment
or competence.
To mitigate this issue, the project manager should promote the
concept that finishing on time
and within budget is not the key objective in any project and
that milestones are just guide-
lines. The problem is compounded when the budget allocated to
a project does not provide
enough resources to do the job. Sometimes this happens when
top management or the cus-
tomer is convinced that budgets and schedules are padded and
that taking a percentage off
the top of a project cost estimate is a natural offset to that
practice.
Correcting a major variation in earned value revealed in
monitoring data is not always advis-
able, especially in the early phases of a project. Overreaction
with the wrong corrective action
in response to such indicators is worse than no action at all.
This is why the project manager
must see earned value as a learning tool, not an intervention
tool. Intervention in a project
process should occur only if there is sustained information over
time that substantiates the

need for correction, and even then the project manager should
be aware of the tendency to
overreact or to address corrective actions to a symptom rather
than to a true root cause.
Informal Feedback
Project managers should heed informal indicators of project
progress as well as quantitative
measures and data (Fleming & Koppelman, 2010). Sometimes
team members and stakehold-
ers will express feelings and personal views about a project that
may not be made public but
that deserve attention. This is the process of reading the
project’s status from personal views
that can signal developing trends and issues that are not visible
in monitoring data.
For instance, a stakeholder may express concern that the project
team is experiencing conflict
and tension that may not be visible to the project manager but is
evident in communications
with stakeholders. Some team members may indicate that the
project is not going well sim-
ply to vent their dissatisfaction with their roles or their
compensation but are unwilling to
express their views inside the team.
Project managers need to have a good relationship with
stakeholders so that these kinds of
messages can be informally delivered without major
consequences. When this kind of devel-
opment occurs, project managers may find that they do not have
the confidence of the team
they thought they had, and that team members fear retribution if
they express negative views
within the team and enterprise.

bar81677_13_c13_391-422.indd 402 9/11/14 10:45 AM
Using the Logical Framework
The approach to monitoring a project should reflect an overall
strategy to track inputs and
outputs, activities, impacts, and outcomes. This progression is
sometimes called the logical
framework, which shows a causal linkage from project activities
all the way through to out-
comes, called result chains or value chains. This process begins
by tracking project perfor-
mance against plans and deliverables, but the actual evaluation
of the project (covered in
Chapter 14) will focus on outputs, impacts, and outcomes. This
way of thinking through the
actual value of the project in terms of outcomes is called the
logical framework, or logframe,
because it traces the logic from initial activity to result.
Table 13.2 shows an example of a logical framework for the
town hall project. Note that
each activity results in a planned result and outcome, an
indication of a logical relationship
between an activity and a project result. The logical framework
is a way of ensuring that each
project activity can be tracked to a project result and outcome.
Table 13.2: Logical framework for town hall project
Activity or output of

project enterprise Measure Result Outcome
Blueprint Customer sign-off Customer approves
move to design and
construction
No additional costs to
change basic construc-
tion blueprint
Completed wiring Quality control
approval and city code
sign-off
Assures quality of
wiring system to meet
requirements and that
building will meet
code requirements if
constructed according
to the wiring plan
No additional costs to
mitigate construction
code violations
Final customer
acceptance
Customer sign-off Customer satisfaction Customer financial
support
Overall project Customer acceptance of
final deliverable
Customer promptly

pays for project in full
Owner (the city) profits
from project, project
enterprise profits
from tight project cost
control, community
benefits from jobs and
economic development
Follow-on contract Successful new project
work with customer
New project approved Owner (the city) profits
from new project, proj-
ect enterprise profits
from tight project cost
control, community
benefits from jobs and
economic development
The logical framework helps the project manager see the big
picture: in this case, that the
disciplined management and control of schedule and costs, as
well as the key indicators of
bar81677_13_c13_391-422.indd 403 9/11/14 10:45 AM
Section 13.3 Corrective Action
project success, will lead to customer satisfaction, financial
profitability of the project enter-
prise, and overall beneficial outcomes to society, such as jobs
and economic development.

Whereas the project manager cannot control outcomes, the
logical framework suggests that
the chance of realizing planned project outcomes is enhanced,
but not guaranteed, when basic
controls are in place so that schedule, cost, and quality are
assured.
13.3 Corrective Action
When the project manager sees change or variation in the
performance of a project, the next
step is to interpret the indicator or measure and determine the
extent of the change and the
need for corrective action. In some cases the change or variation
has been anticipated, such as
in the risk matrix. If the variation appears to be the result of an
anticipated risk event, there
should be documentation available on intensity, impact, and
contingency actions. If the varia-
tion is due to an unanticipated factor, the root causes must be
uncovered to understand the
extent of the disruption.
Corrective action is the process of adjusting the project based
on monitoring results that sug-
gest variation in performance. Sometimes this is called
contingency planning, because the
corrective action to be taken is contingent on the indicator and
root cause of the variation.
Actions to adjust the project can take four basic shapes: (a)
minor tweaks (small changes) to
the project schedule, budget, or resources; (b) actions to prevent
risk events or other disrupt-
ing influences from happening; (c) mitigation actions or change
orders to control the risk event
or variation and its impacts in order to bring the project back
under control; and (d) major

restructuring of the project based on major impacts.
Minor Tweaks
Minor tweaks include changes in schedule based on
performance, such as changing task dura-
tions, start and finish dates, and predecessors. For example,
project monitoring might show
that the requirements subtask for a construction project was
completed in 10 days rather
than the estimated 15 days. If this subtask is on the critical
path, this could mean submitting
the deliverable 5 days early. If an early delivery is attractive to
the customer, the schedule is
adjusted to reflect the new subtask duration and its impact on
the whole schedule, and a new
baseline schedule would be distributed.
The project manager must also determine that the change in the
time necessary to complete
the requirements document in this project is worth making an
adjustment for, given that a
new schedule would have a ripple effect and impact many team
members’ current calendars
and due dates. The optional approach would be to do nothing
and keep the requirements sub-
task on the baseline schedule despite the potential savings in
cycle time of 5 days.
Major Preventive Actions
Major preventive actions are considered when there are
fundamental shifts occurring in the
project that could alter the quality and timing of the project
deliverable. These shifts may be
the result of identified risks that would have major impacts on

5 Project Risk Managementadrian825iStockThinkstockLe.docx

5 Project Risk Managementadrian825iStockThinkstockLe.docx

Recommended

Recommended

More Related Content

Similar to 5 Project Risk Managementadrian825iStockThinkstockLe.docx

Similar to 5 Project Risk Managementadrian825iStockThinkstockLe.docx (20)

More from gilbertkpeters11344

More from gilbertkpeters11344 (20)

Recently uploaded

Recently uploaded (20)

5 Project Risk Managementadrian825iStockThinkstockLe.docx