Information Technology Project Management by Kathy Schwalbe

476 Chapter 11

IT Project

Business Technical Organizational Project
Management

Competitors Hardware Executive Estimates
support

Suppliers Software User support Communication

Cash flow Network Team support Resources

Figure 11-4  Sample risk breakdown structure

Table 11-3  Potential negative risk conditions associated with each knowledge area

Knowledge Area Risk Conditions

Integration Inadequate planning; poor resource allocation; poor integration
management; lack of post-project review

Scope Poor definition of scope or work packages; incomplete definition

Time Errors in estimating time or resource availability; errors in deter-
mining the critical path; poor allocation and management of float;
early release of competitive products

Cost Estimating errors; inadequate productivity, cost, change, or
contingency

Quality Poor attitude toward quality; substandard design, materials, and
workmanship; inadequate quality assurance program

Human resource Poor conflict management; poor project organization and defini-
tion of responsibilities; absence of leadership

Communications Carelessness in planning or communicating

Risk Ignoring risk; unclear analysis of risk; poor insurance management

Procurement Unenforceable conditions or contract clauses; adversarial relations

Stakeholders Lack of consultation with key stakeholder; poor sponsor
engagement

Source: R.M. Wideman

Project Risk Management 477

Identifying Risks

Identifying risks is the process of understanding what potential events might hurt or
enhance a particular project. It is important to identify potential risks early, but you must
also continue to identify risks based on the changing project environment. Also remember
that you cannot manage risks if you do not identify them first. By understanding
common sources of risks and reviewing a project’s project management plan, project
documents, agreements, procurement documents, enterprise environmental factors,
and organizational process assets project managers and their teams can identify many
potential risks.

Another consideration for identifying risks is the likelihood of advanced discovery,
which is often viewed at a program level rather than a project level. The Department of
Defense (DOD) Risk, Issue, and Opportunity Management Guide addresses this concept
and emphasizes the need to establish high-level indicators for an entire program. For
example, several experts track asteroids to enable a response in case one threatens our
planet. Although the likelihood of a deadly asteroid is very low, the impact is extremely
high. For IT programs, advanced discovery could involve monitoring an important supplier
who might remove support for software used on several projects. Some suppliers provide
early warning for this possibility, while others do not. It is important for organizations to
identify these advanced discovery risks early and track their status in case time is needed
to develop responses.

Suggestions for Identifying Risks

There are several tools and techniques for identifying risks. Project teams often begin
this process by reviewing project documentation, recent and historical information
related to the organization, and assumptions that might affect the project. Project
team members and outside experts often hold meetings to discuss this information and
ask important questions about it as they relate to risk. After identifying potential risks
at the initial meeting, the project team might then use different information-gathering
techniques to further identify risks. Some common techniques include brainstorming,
the Delphi technique, interviewing, root cause analysis, and SWOT analysis.

Brainstorming is a technique by which a group attempts to generate ideas or find a
solution for a specific problem by amassing ideas spontaneously and without judgment.
This approach can help the group create a comprehensive list of risks to address later
during qualitative and quantitative risk analysis. An experienced facilitator should run the
brainstorming session and introduce new categories of potential risks to keep the ideas
flowing. After the ideas are collected, the facilitator can group and categorize the ideas
to make them more manageable. Care must be taken, however, not to overuse or misuse
brainstorming. Although businesses use brainstorming widely to generate new ideas, the
psychology literature shows that individual people working alone produce a greater number
of ideas than they produce through brainstorming in small, face-to-face groups. Group effects,
such as fear of social disapproval, the effects of authority hierarchy, and domination of the
session by one or two vocal people, often inhibit idea generation for many participants.14

The Delphi technique is an approach to gathering information that helps prevent
some of the negative group effects found in brainstorming. The basic concept of the Delphi

478 Chapter 11

technique is to derive a consensus among a panel of experts who make predictions about
future developments. Developed by the Rand Corporation for the U.S. Air Force in the late
1960s, the Delphi technique is a systematic, interactive forecasting procedure based on
independent and anonymous input regarding future events. The Delphi technique uses
repeated rounds of questioning and written responses, including feedback to responses in
earlier rounds, to take advantage of group input while avoiding the possible biasing effects
of oral panel deliberations. To use the Delphi technique, you must select a panel of experts
for the particular area in question. For example, Cliff Branch from the opening case could
use the Delphi technique to help him understand why his company is no longer winning
many contracts. Cliff could assemble a panel of people with knowledge in his business area.
Each expert would answer questions related to Cliff’s situation, and then Cliff or a facilitator
would evaluate their responses, together with opinions and justifications, and provide that
feedback to each expert in the next iteration. Cliff would continue this process until the
group responses converge to a specific solution. If the responses diverge, the facilitator of
the Delphi technique needs to determine if there is a problem with the process.

Interviewing is a fact-finding technique for collecting information in face-to-face,
phone, e-mail, or virtual discussions. Interviewing people with similar project experience
is an important tool for identifying potential risks. For example, if a new project involves
using a particular type of hardware or software, people who had recent experience with
that hardware or software could describe their problems on a past project. If people have
worked with a particular customer, they might provide insight into the potential risks of
working for that customer again. It is important to be well prepared for leading interviews;
it often helps to create a list of questions to use as a guide during the interview.

It is not uncommon for people to identify problems or opportunities without really
understanding them. Before suggesting courses of action, it is important to identify the root
cause of a problem or opportunity. Root cause analysis (as you learned in Chapter 8, Project
Quality Management) often results in identifying even more potential risks for a project.

Another technique is a SWOT analysis of strengths, weaknesses, opportunities, and
threats, which is often used in strategic planning. SWOT analysis can also be used during
risk identification by having project teams focus on the broad perspectives of potential
risks for particular projects. (You first learned about SWOT analysis in Chapter 4, Project
Integration Management.) For example, before writing a particular proposal, Cliff Branch
could have a group of his employees discuss in detail their company’s strengths, their
weaknesses for the project, and what opportunities and threats exist. Do they know that
several competing firms are much more likely to win a certain contract? Do they know
that winning a particular contract will likely lead to future contracts and help expand their
business? Applying SWOT to specific potential projects can help identify the broad risks
and opportunities that apply in that scenario.

The Risk Register

One important output of risk identification is a list of identified risks and other
information needed to begin creating a risk register. A risk register is a document that
contains results of various risk management processes; it is often displayed in a table or
spreadsheet format. A risk register is a tool for documenting potential risk events and
related information. Risk events refer to specific, uncertain events that may occur to the

Project Risk Management 479

detriment or enhancement of the project. For example, negative risk events might include
the performance failure of a product created as part of a project, delays in completing
work as scheduled, increases in estimated costs, supply shortages, litigation against the
company, and strikes. Examples of positive risk events include completing work sooner or
cheaper than planned, collaborating with suppliers to produce better products, and good
publicity resulting from the project.

Table 11-4 provides a sample of the format for a risk register that Cliff and his
managers from the opening case might use on a new project. Actual data that might be
entered for one of the risks is included below the table. Notice the main headings often
included in the register. Many of these items are described in more detail later in this
chapter. Elements of a risk register include the following:

• An identification number for each risk event: The project team may want to
sort by risk events or quickly search for specific risk events, so they need to
identify each risk with a unique descriptor, such as an identification number.

• A rank for each risk event: The rank is usually a number, with 1 representing
the highest risk.

• The name of the risk event: Example names include defective server, late
completion of testing, reduced consulting costs, and good publicity.

• A description of the risk event: Because the name of a risk event is often
abbreviated, it helps to provide a more detailed description. Consider using
a risk statement format similar to the following: “Because of <one or more
causes>, <risk event> might occur, which would lead to <one or more
effects>.” For example, reduced consulting costs might be expanded to:
“Because this particular consultant enjoys working for our company and is
open to negotiating her rates, reduced consulting costs might occur, which
could lead to saving money on the project.”

• The category under which the risk event falls: For example, defective server
might fall under the broader category of technology or hardware technology.

• The root cause of the risk: The root cause of the defective server might be a
defective power supply.

• Triggers for each risk: Triggers are indicators or symptoms of actual risk
events. For example, cost overruns on early activities may be symptoms of
poor cost estimates. Defective products may be symptoms of a low-quality
supplier. Documenting potential risk symptoms for projects also helps the
project team identify more potential risk events.

Table 11-4  Sample risk register

Root Potential Risk

No. Rank Risk Description Category Cause Triggers Responses Owner Probability Impact Status

R44 1

R21 2

R7 3

480 Chapter 11

• Potential responses to each risk: A potential response to the defective server
might be to include a clause in the supplier’s contract to replace the server
within a certain time period at a negotiated cost.

• The risk owner or person who will take responsibility for the risk: For
example, a certain person might be in charge of any server-related risk events
and managing response strategies.

• The probability of the risk occurring: There might be a high, medium, or low
probability of a certain risk event. For example, the risk might be low that
the server would actually be defective.

• The impact to the project if the risk occurs: There might be a high, medium,
or low impact to project success if the risk event actually occurs. A defective
server might have a high impact on successfully completing a project on time.

• The status of the risk: Did the risk event occur? Was the response strategy
completed? Is the risk no longer relevant to the project? For example, a contract
clause may have been completed to address the risk of a defective server.

For example, the following data might be entered for the first risk in the register.
Notice that Cliff’s team is taking a proactive approach in managing this risk.

• No.: R44
• Rank: 1
• Risk: New customer
• Description: We have never done a project for this organization before and

don’t know too much about them. One of our company’s strengths is building
good customer relationships, which often leads to further projects with that
customer. We might have trouble working with this customer because they
are new to us.
• Category: People risk
• Root cause: We won a contract to work on a project without really getting to
know the customer.
• Triggers: The new customer asked a lot of questions in person and via e-mail
that our existing customers would not, so we could easily misunderstand
their needs and expectations.
• Potential responses: Make sure the project manager is sensitive to the
fact that this is a new customer and takes the time to understand them.
Have the PM set up a meeting to get to know the customer and clarify their
expectations. Have Cliff attend the meeting, too.
• Risk owner: Project manager
• Probability: Medium
• Impact: High
• Status: PM will set up the meeting within the week.

The Risk Report

Another important output of identifying risks is creation of a risk report. Overall project
risk is the effect of uncertainty on the project as a whole. Contents of a risk report
include sources of overall project risk, important drivers of overall project risk exposure,

Project Risk Management 481

and summary information on risk events, such as number of risks, total risk exposure,
distribution across risk categories, metrics, and trends. The risk report is developed
progressively during the entire risk planning processes.

After identifying risks, the next step is to understand which risks are most important
by performing qualitative risk analysis.

Performing Qualitative Risk Analysis

Qualitative risk analysis involves assessing the likelihood and impact of identified risks to
determine their magnitude and priority. This section describes how to use a probability/
impact matrix to produce a prioritized list of risks. It also provides examples of using the
Top Ten Risk Item Tracking technique to produce an overall ranking for project risks and
to track trends in qualitative risk analysis. Finally, this section discusses the importance
of expert judgment in performing risk analysis. Note that some organizations simply
determine that risks are high, medium, or low and color code them as red, yellow, and
green, with very little analysis. Using the methods described in this section can greatly
improve qualitative risk analysis.

Using Probability/Impact Matrixes to Calculate Risk Factors

People often describe a risk probability or consequence as being high, medium or
moderate, or low. For example, a meteorologist might predict a high probability or
likelihood of severe rain showers on a certain day. If that day happens to be your wedding
day and you are planning a large outdoor ceremony, the consequences or impact of severe
showers might also be high.

A project manager can chart the probability and impact of risks on a probability/
impact matrix or chart, which lists the relative probability of a risk occurring and the
relative impact of the risk occurring. Many project teams would benefit from using this
simple technique to help them identify risks that need attention. To use this approach,
project stakeholders list the risks they think might occur on their projects. They then
label a risk as having a high, medium, or low probability of occurrence and a high,
medium, or low impact if it does occur.

The project manager then summarizes the results in a probability/impact matrix
or chart, as shown in Figure 11-5. For example, Cliff Branch and some of his project
managers in the opening case could each identify three negative and positive potential
risks for a particular project. They could then label the probability of occurrence and
impact of each risk as being high, medium, or low. For example, one project manager
might list a severe market downturn as a negative risk that is low in probability but high
in impact. Cliff may have listed the same risk as being medium in both probability and
impact. The team could then plot all of the risks on a matrix or chart, combine common
risks, and decide where those risks should be on the matrix or chart. The team should
then focus on risks that fall in the high sections of the probability/impact matrix or chart.
For example, Risks 1 and 4 are listed as high in both probability and impact. Risk 6 is high
in probability but low in impact. Risk 9 is high in probability and medium in impact, and
so on. The team should then discuss how it plans to respond to the risks if they occur, as
you will learn later in this chapter in the section on risk response planning.

482 Chapter 11

High risk 6 risk 9 risk 1
risk 4

Probability Medium risk 3 risk 2
risk 7 risk 5
risk 11

Low risk 8 risk 12
risk 10

Low Medium High

Impact

Figure 11-5  Sample probability/impact matrix

It may be useful to create a separate probability/impact matrix or chart for negative
risks and positive risks to make sure that both types are adequately addressed. Some
project teams also collect data on the probability of risks and the negative or positive
impact they could have on scope, time, and cost goals. Qualitative risk analysis is
normally done quickly, so the project team has to decide what type of approach makes the
most sense for its project.

Some project teams develop a single number for a risk score simply by multiplying
a numeric score for probability by a numeric score for impact. A more sophisticated
approach to using probability/impact information is to calculate risk factors. To quantify
risk probability and consequence, the U.S. Defense Systems Management College (DSMC)
developed a technique for calculating risk factors—numbers that represent the overall
risk of specific events, based on their probability of occurring and the consequences to
the project if they do occur. The technique makes use of a probability/impact matrix that
shows the probability of risks occurring and the impact or consequences of the risks.

Probabilities of a risk occurring can be estimated based on several factors determined
by the unique nature of each project. For example, factors to evaluate for potential hardware
or software technology risks could include the technology not being mature, the technology
being too complex, and an inadequate support base for developing the technology. The
impact of a risk occurring could include factors such as the availability of fallback solutions
or the consequences of not meeting performance, cost, and schedule estimates.

Figure 11-6 provides an example of how risk factors were used to graph the
probability of failure and consequence of failure in a research study on proposed
technologies for designing more reliable aircraft. The figure classifies potential
technologies (dots on the chart) as high, medium, or low risk, based on the probability
of failure and consequences of failure. The researchers strongly recommended that the

Project Risk Management 483

1.0

0.8 High Risk

0.6 Medium
Probability Risk
of Failure
(Pf) 0.4

0.2 Low
Risk

0 0.2 0.4 0.6 0.8 1.0
Consequence of Failure (Cf)

Figure 11-6  Chart showing high-, medium-, and low-risk technologies

U.S. Air Force invest in the low- to medium-risk technologies and suggested that it not
pursue the high-risk technologies.15 The rigor involved in using the probability/impact
matrix and risk factors can provide a much stronger argument than simply stating that
risk probabilities or consequences are high, medium, or low.

Top Ten Risk Item Tracking

Top Ten Risk Item Tracking is a qualitative risk analysis tool. In addition to identifying
risks, it maintains an awareness of risks throughout the life of a project by helping to
monitor risks. Using this tool involves establishing a periodic review of the project’s most
significant risk items with management; similar reviews can also occur with the customer.
The review begins with a summary of the status of the top ten sources of risk on the
project. The summary includes each item’s current ranking, previous ranking, number
of times it appears on the list over a period of time, and a summary of progress made in
resolving the risk item since the previous review.

Table 11-5 provides an example of a Top Ten Risk Item Tracking chart that could
be used at a management review meeting for a project. This example includes only the
top five negative risk events. Notice that each risk event is ranked based on the current
month, previous month, and how many months it has been in the top ten. The last
column briefly describes the progress for resolving each risk item. You can have separate
charts for negative and positive risks or combine them into one chart.

A risk management review accomplishes several objectives. First, it keeps
management and the customer (if included) aware of major influences that could
prevent or enhance the project’s success. Second, by involving the customer, the project
team may be able to consider alternative strategies for addressing the risks. Third, the

484 Chapter 11

Table 11-5  Example of top ten risk item tracking

MONTHLY RANKING

Risk Event Rank This Rank Last Number of Risk Resolution Progress
Month Month Months in
Top Ten Working on revising the
entire project manage-
Inadequate 1 2 4 ment plan
planning
Holding meetings with
Poor 2 3 3 project customer and
definition sponsor to clarify scope

Absence of 3 1 2 Assigned a new project
leadership manager to lead the
project after the previous
Poor cost 4 4 3 one quit
estimates 5 5 3
Revising cost estimates
Poor time
estimates Revising schedule
estimates

review promotes confidence in the project team by demonstrating to management and
the customer that the team is aware of significant risks, has a strategy in place, and is
effectively carrying out that strategy.

The main output of qualitative risk analysis is updating the risk register. The ranking
column of the risk register should be filled in, along with a numeric value or rating of high,
medium, or low for the probability and impact of the risk event. Additional information
is often added for risk events, such as identification of risks that need more attention in
the near term or those that can be placed on a watch list. A watch list is a list of risks that
have low priority but are still identified as potential risks. Qualitative analysis can also
identify risks that should be evaluated quantitatively, as you learn in the next section.

Media Snapshot

Even more than 100 years after the Titanic sank on April 15, 1912, people mark the
anniversary on which more than 1,500 of the ship’s passengers and crew died. A recent
article in PMI’s Virtual Library explains how to avoid “the Titanic factor” in your proj-
ects by analyzing the interdependence of risks. For example, the probability of one risk
event occurring might change if another one materializes, and the response to one risk

(continued)

Project Risk Management 485

event might affect another. The article’s author addresses the issue of how project risks
interact and how project teams can address those risks. Some of the interdependent risk
events on the Titanic included the following:

• The design of the bulkheads, rudder, and engines were integrated. As six of the
16 watertight compartments were breached and began flooding, the weight of
the water in the bow pulled the ship under until the bulkheads overtopped.
The rudder design was considered adequate for use on the open seas, but it
was undersized for the tight maneuvers required that fateful night. The central
propeller had a steam turbine as its power source, but this engine could not be
reversed and was stopped during the run up to the iceberg. This stopped the
water flow past the rudder and became a critical problem for the ship.

• Several procedures were not followed, which had the cumulative effect of
creating other major problems. Iceberg reports from two other ships were not
passed on to the bridge. The wireless radio did not work most of the day, so
another critical iceberg warning failed to reach the Titanic’s captain. The ship
was traveling too fast for the amount of ice in the area, and visibility was ter-
rible that night.

• Unknown risk events also contributed to the sinking of the Titanic. For exam-
ple, the steel in the hull could not withstand the cold temperatures, causing it
to break without bending. Iron rivet heads also burst due to the cold.16

Performing Quantitative Risk Analysis

Quantitative risk analysis often follows qualitative risk analysis, yet both processes can be
done together or separately. On some projects, the team may only perform qualitative risk
analysis. The nature of the project and availability of time and money affect which risk
analysis techniques are used. Large, complex projects involving leading-edge technologies
often require extensive quantitative risk analysis. This section focuses on using the
quantitative risk analysis and modeling techniques of decision tree analysis, simulation,
and sensitivity analysis.

Decision Trees and Expected Monetary Value

A decision tree is a diagramming analysis technique used to help select the best course
of action when future outcomes are uncertain. A common application of decision tree
analysis involves calculating expected monetary value. Expected monetary value (EMV)
is the product of a risk event probability and the risk event’s monetary value. To illustrate
this concept, Figure 11-7 uses the issue of which project(s) an organization might pursue.
Suppose Cliff Branch’s firm was trying to decide if it should submit a proposal for Project 1,
Project 2, both projects, or neither project. The team could draw a decision tree with
two branches, one for Project 1 and one for Project 2. The firm could then calculate the
expected monetary value to help make this decision.

To create a decision tree, and to calculate expected monetary value specifically, you
must estimate the probabilities or chances of certain events occurring. For example,
Figure 11-7 shows a 20 percent probability ( P 5.20) that Cliff’s firm will win the contract

486 Chapter 11

Probability (P) times EMV of Outcome

P = .20 * $300,000 = +$60,000

Project 1

Decision P = .80 * –$40,000 = –$32,000

P = 20 * –$50,000 = –$10,000

Project 2 P = .10 * –$20,000 = –$2,000

P = .70 * $60,000 = $42,000

Project 1's EMV = $60,000 – $32,000 = $28,000
Project 2's EMV = –$10,000 – $2,000 + $42,000 = $30,000

Figure 11-7  Expected monetary value (EMV) example

for Project 1, which is estimated to be worth $300,000 in profits—the outcome of the top
branch in the figure. There is an 80 percent probability ( P 5.80) that the firm will not win
the contract for Project 1, and the outcome is estimated to be −$40,000, meaning that
the firm will have invested $40,000 into Project 1 with no reimbursement if it does not
win the contract. The sum of the probabilities for outcomes for each project must equal
one (for Project 1, .20 plus .80). Probabilities are normally determined based on expert
judgment. Cliff or other people in his firm should have a sense of the likelihood of winning
certain projects.

Figure 11-7 also shows probabilities and outcomes for Project 2. Suppose there is
a 20 percent probability that Cliff’s firm will lose $50,000 on Project 2, a 10 percent
probability that it will lose $20,000, and a 70 percent probability that it will earn $60,000.
Again, experts would need to estimate these dollar amounts and probabilities.

To calculate the EMV for each project, multiply the probability by the outcome value
for each potential outcome for each project and sum the results. To calculate the EMV for
Project 1, going from left to right, multiply the probability by the outcome for each branch
and sum the results. In this example, the EMV for Project 1 is $28,000.

.2($300, 000)1.8($40, 000) 5$60, 0002 $32, 000 5$28, 000

The EMV for Project 2 is $30, 000.

.2(2 $50, 000)1.1(2 $20, 000)1.7($60, 000) 5 2 $10, 0002 $2, 000 1 $42, 000 5$30, 000

Because the EMV provides an estimate for the total dollar value of a decision, you want
to have a positive number; the higher the EMV, the better. Because the EMV is positive for
both Projects 1 and 2, Cliff’s firm would expect a positive outcome from each and could bid

Project Risk Management 487

on both projects. If it had to choose between the two projects, perhaps because of limited
resources, Cliff’s firm should bid on Project 2 because it has a higher EMV.

Notice in Figure 11-7 that if you just look at the potential outcome of the two
projects, Project 1 looks more appealing. You could earn $300,000 in profits from
Project 1, but you could only earn $60,000 for Project 2. If Cliff were a risk seeker, he
would naturally want to bid on Project 1. However, there is only a 20 percent chance
of earning the $300,000 on Project 1, as opposed to a 70 percent chance of earning
$60,000 on Project 2. Using EMV helps account for all possible outcomes and their
probabilities of occurrence, thereby reducing the tendency to pursue overly aggressive
or conservative risk strategies.

Simulation

A more sophisticated technique for quantitative risk analysis is simulation, which uses
a representation or model of a system to analyze its expected behavior or performance.
Most simulations are based on some form of Monte Carlo analysis. Monte Carlo analysis
simulates a model’s outcome many times to provide a statistical distribution of the
calculated results. For example, Monte Carlo analysis can determine that a project will
finish by a certain date only 10 percent of the time, and determine another date for which
the project will finish 50 percent of the time. In other words, Monte Carlo analysis can
predict the probability of finishing by a certain date or the probability that the cost will be
equal to or less than a certain value.

You can use several different types of distribution functions when performing a Monte
Carlo analysis. The following example is a simplified approach. The basic steps of a Monte
Carlo analysis are as follows:

1. Collect the most likely, optimistic, and pessimistic estimates for the variables
in the model. For example, if you are trying to determine the likelihood of
meeting project schedule goals, the project network diagram would be your
model. You would collect the most likely, optimistic, and pessimistic time
estimates for each task. Notice that this step is similar to collecting data for
performing PERT estimates. However, instead of applying the same PERT
weighted average formula, you perform the following steps in a Monte Carlo
simulation.

2. Determine the probability distribution of each variable. What is the
likelihood of a variable falling between the optimistic and most likely
estimates? For example, if an expert assigned to a particular task provides
a most likely estimate of 10 weeks, an optimistic estimate of 8 weeks, and
a pessimistic estimate of 15 weeks, you then ask about the probability of
completing that task between 8 and 10 weeks. The expert might respond that
there is a 20 percent probability.

3. For each variable, such as the time estimate for a task, select a random value
based on the probability distribution for the occurrence of the variable. For
example, using the preceding scenario, you would randomly pick a value
between 8 weeks and 10 weeks 20 percent of the time and a value between
10 weeks and 15 weeks 80 percent of the time.

488 Chapter 11

4. Run a deterministic analysis or one pass through the model using the
combination of values selected for each of the variables. For example,
one task described in the preceding scenario might have a value of 12
on the first run. All of the other tasks would also have one random value
assigned to them on the first run, based on their estimates and probability
distributions.

5. Repeat Steps 3 and 4 many times to obtain the probability distribution of
the model’s results. The number of iterations depends on the number of
variables and the degree of confidence required in the results, but it typically
lies between 100 and 1,000. Using the project schedule as an example, the
final simulation results will show you the probability of completing the entire
project within a certain time period.

Figure 11-8 illustrates the results from a Monte Carlo–based simulation of a project
schedule. The simulation was done using Microsoft Project and Risk+ software. On the
left side of Figure 11-8 is a chart displaying columns and an S-shaped curve. The height
of each column indicates how many times the project was completed in a given time
interval during the simulation run, which is the sample count. In this example, the time
interval was two working days, and the simulation was run 250 times. The first column
shows that the project was completed by January 29 only two times during the simulation.
The S-shaped curve shows the cumulative probability of completing the project on or
before a given date. The right side of Figure 11-8 shows the information in tabular form.
For example, there is a 10 percent probability that the project will be completed by 2/8
(February 8), a 50 percent chance of completion by 2/17 (February 17), and a 90 percent
chance of completion by 2/25 (February 25).

Date: 1/14 11:13:56 AM Completion Std Deviation: 5.2 days
Number of Samples: 250 95% Confidence Interval: 0.6 day
Unique ID: 1 Each bar represents 2 days.
Name: Widget
Completion Probability Table

45.0Sample Count 1.0 Prob Date Prob Date
40.5 Cumulative Probability0.9 0.05 2/4 0.55 2/17
36.0 0.8 0.10 2/8 0.60 2/18
31.5 0.7 0.15 2/9 0.65 2/19
27.0 0.6 0.20 2/10 0.70 2/22
22.5 0.5 0.25 2/11 0.75 2/22
18.0 0.4 0.30 2/12 0.80 2/23
13.5 0.3 0.35 2/15 0.85 2/24
0.2 0.40 2/15 0.90 2/25
9.0 0.1 0.45 2/16 0.95 2/26
4.5 0.50 2/17 1.00 3/10

1/29 2/17 3/10

Completion Date

Figure 11-8  Sample Monte Carlo–based simulation results for project schedule

Project Risk Management 489

Several PC-based software packages that perform Monte Carlo simulations are
available. Many products display the major risk drivers for a project based on the
simulation results. This enables you to identify the chief source of uncertainty in a project
schedule. For example, a wide range for a certain task estimate might cause most of the
uncertainty in the project schedule. You will learn more about using simulation software
and other software related to project risk management later in this chapter.

What Went Right?

Microsoft Excel is a common tool for performing quantitative risk analysis. Microsoft
provides examples of how to use Excel to perform Monte Carlo simulation on its website,
and explains how several companies use Monte Carlo simulation as an important tool for
decision making:

• General Motors uses simulation for forecasting its net income, predicting struc-
tural costs and purchasing costs of vehicles, and determining the company’s
susceptibility to different kinds of risk, such as interest rate changes and
exchange rate fluctuations.

• Eli Lilly uses simulation to determine the optimal plant capacity that should be
built for developing each drug.

• Procter & Gamble uses simulation to model and optimally hedge foreign
exchange risk.17

Monte Carlo simulation can also help reduce schedule risk on agile projects. For
example, instead of using linear techniques, which assume a fixed future velocity and
a discrete completion date, you can use Monte Carlo simulation to estimate a range
of completion dates. “Consider a simple scenario where two teams both have an aver-
age velocity of 7.5. Using this average, either team could deliver the next 45 points in
6 iterations. However, suppose Team A’s historical velocity values were 10, 4, 5, and 11,
and Team B’s historical velocity values were 7, 8, 8, and 7. The average is the same, but
because the velocity values for Team A have a higher variance, there is greater risk when
predicting future results.”18

Sensitivity Analysis

Many people are familiar with using sensitivity analysis to see the effects of changing one
or more variables on an outcome. For example, many people perform a sensitivity analysis
to determine their monthly payments for a loan given different interest rates or periods
of the loan. What will your monthly mortgage payment be if you borrow $100,000 for
30 years at a 6 percent rate? What will the payment be if the interest rate is 7 percent?
What will the payment be if you decide to pay off the loan in 15 years at 5 percent?

Many professionals use sensitivity analysis to help make several common business
decisions, such as determining break-even points based on different assumptions. People
often use spreadsheet software like Microsoft Excel to perform sensitivity analysis. Figure 11-9

490 Chapter 11

Figure 11-9  Sample sensitivity analysis for determining break-even point
shows an example Excel file created to quickly show the break-even point for a product based
on various inputs: the sales price per unit, the manufacturing cost per unit, and fixed monthly
expenses. The current inputs result in a break-even point of 6,250 units sold. Users of this
spreadsheet can change inputs and see the effects on the break-even point in chart format.
Project teams often create similar models to determine the sensitivity of various project
variables. For example, Cliff’s team could develop sensitivity analysis models to estimate their
profits on jobs by varying the number of hours required to do the jobs or by varying costs
per hour.

The main outputs of quantitative risk analysis are updates to project documents,
such as the risk report and risk register. The quantitative analysis also provides high-level
information about the probabilities of achieving certain project objectives. This information
might cause the project manager to suggest changes in contingency reserves. In some cases,
projects may be redirected or canceled based on the quantitative analysis, or the quantitative
analysis might be used to help initiate new projects to help the current one succeed.

Planning Risk Responses

After an organization identifies and quantifies risks, it must develop an appropriate
response to them. Developing a response to risks involves developing options and defining
strategies for reducing negative risks and enhancing positive risks.

Project Risk Management 491

The five basic response strategies for negative risks are as follows:

• Risk avoidance or eliminating a specific threat, usually by eliminating
its causes. Of course, not all risks can be eliminated, but specific risk
events can be. For example, a project team may decide to continue using
a specific piece of hardware or software on a project because the team
knows it works. Other products that could be used on the project may
be available, but if the project team is unfamiliar with them, they could
cause significant risk. Using familiar hardware or software eliminates
this risk.

• Risk acceptance or accepting the consequences if a risk occurs. For example,
a project team planning a big project review meeting could take an active
approach to risk by having a contingency or backup plan and contingency
reserves if the team cannot get approval for a specific meeting site. On the
other hand, the team could take a passive approach and accept whatever
facility the organization provides.

• Risk transference or shifting the consequence of a risk and responsibility
for its management to a third party. For example, risk transference is often
used in dealing with financial risk exposure. A project team may purchase
special insurance or warranty protection for specific hardware needed for a
project. If the hardware fails, the insurer must replace it within a specified
period of time.

• Risk mitigation or reducing the impact of a risk event by reducing the
probability of its occurrence. Suggestions for reducing common sources
of risk on IT projects were provided at the beginning of this chapter.
Other examples of risk mitigation include using proven technology,
having competent project personnel, using various analysis and validation
techniques, and buying maintenance or service agreements from
subcontractors.

• Risk escalation or notifying a higher level authority. If the risk is outside of
the scope of the project or the proposed response is outside of the project
manager’s authority, it would make sense to escalate the risk to a higher-level
manager within the organization.

Table 11-6 provides general mitigation strategies for technical, cost, and schedule
risks on projects.19 Note that increasing the frequency of project monitoring and using
a WBS and Critical Path Method (CPM) are strategies for all three areas. Increasing the
project manager’s authority is a strategy for mitigating technical and cost risks, and
selecting the most experienced project manager is recommended for reducing schedule
risks. Improving communication is also an effective strategy for mitigating risks.

The five basic response strategies for positive risks are as follows:

• Risk exploitation or doing whatever you can to make sure the positive risk
happens. For example, suppose that Cliff’s company funded a project to
provide new computer classrooms for a nearby school in need. They might
select one of their top project managers to organize news coverage of the
project, write a press release, or hold some other public event to ensure that

492 Chapter 11

Table 11-6  General risk mitigation strategies for technical, cost, and schedule risks

Technical Risks Cost Risks Schedule Risks

Emphasize team support Increase the frequency of Increase the frequency of
and avoid stand-alone project monitoring project monitoring
project structure
Use WBS and CPM Use WBS and CPM
Increase project manager
authority Improve communication, Select the most experienced
understanding of project project manager
Improve problem han- goals, and team support
dling and communication Increase project manager
authority
Increase the frequency of
project monitoring

Use WBS and CPM

Source: J. Couillard

the project produces good public relations for the company, which could lead
to more business.
• Risk sharing or allocating ownership of the risk to another party. Using
the same example of implementing new computer classrooms, the
project manager could form a partnership with the school’s principal,
school board, or parent–teacher organization to share responsibility for
achieving good public relations for the project. On the other hand, the
company might partner with a local training firm that agrees to provide
free training for all of the teachers on how to use the new computer
classrooms.
• Risk enhancement or changing the size of the opportunity by identifying and
maximizing key drivers of the positive risk. For example, an important driver
of getting good public relations for the computer classrooms project might
be to generate awareness and excitement about it among students, parents,
and teachers. These groups might then do their own formal or informal
advertising of the project and Cliff’s company, which in turn might interest
other groups and generate more business.
• Risk acceptance also applies to positive risks when the project team does
not take any actions toward a risk. For example, the computer classrooms
project manager might assume that the project will result in good public
relations for the company and not feel compelled to do anything extra.
• Risk escalation or notifying a higher level authority also applies to positive
risks. The computer classrooms project manager might escalate the risk of
partnering with another firm to a higher-level manager who may have more
influence with the firm.

Project Risk Management 493

The main outputs of risk response planning include updates to the project
management plan and other project documents and change requests. For example, if
Cliff’s company decided to partner with a local training firm on the computer classrooms
project to share the opportunity of achieving good public relations, it could issue a change
request to write a contract with that firm. The project management plan and its related
plans might need to be updated if the risk response strategies require additional tasks,
resources, or time to accomplish. Risk response strategies often result in changes to the
WBS and project schedule, so plans that contain this information must be updated as
well. The risk response strategies also provide updated information for the risk register by
describing the risk responses, risk owners, and status information.

Risk response strategies often include identification of residual and secondary risks
as well as contingency plans and reserves, as described earlier. Residual risks are risks
that remain after all of the response strategies have been implemented. For example, even
though a stable hardware product may have been used on a project, there may still be a
risk that it fails to function properly. Secondary risks are a direct result of implementing
a risk response. For example, using the more stable hardware may have caused a risk of
peripheral devices failing to function properly.

Implementing Risk Responses

The main executing process performed as part of project risk management is
implementing risk responses as defined in the process to plan risk responses. Key outputs
include change requests and project documents updates (i.e. issue log, lessons-learned
register, project team assignments, risk register, and risk report). For example, Cliff’s team
had identified the risk event of having a new customer. They listed several activities they
could perform to help manage this risk, such as making sure the project manager took
the time to understand the customer, setting up a meeting to get to know the customer
and clarify expectations, and having Cliff attend the meeting. In this case, Cliff’s team was
proactive in identifying this risk and would take actions to prevent any negative events
from happening by implementing their risk responses.

Monitoring Risks

Monitoring risks involves ensuring the appropriate risk responses are performed, tracking
identified risks, identifying and analyzing new risk, and evaluating the effectiveness of
risk management throughout the entire project. Project risk management does not stop
with the initial risk analysis. Identified risks may not materialize, or their probabilities of
occurrence or loss may diminish. Previously identified risks may be determined to have a
greater probability of occurrence or a higher estimated loss value. Similarly, new risks will
be identified as the project progresses. Newly identified risks need to go through the same
process as those identified during the initial risk assessment. A redistribution of resources
devoted to risk management may be necessary because of relative changes in risk exposure.

Carrying out individual risk management plans involves monitoring risks based on
defined milestones and making decisions regarding risks and their response strategies.

494 Chapter 11

It may be necessary to alter a strategy that becomes ineffective, implement a planned
contingency activity, or eliminate a risk from the list of potential risks when it no longer
exists. Project teams sometimes use workarounds—unplanned responses to risk events—
when they do not have contingency plans in place.

Tools and techniques for monitoring risks include data analysis, audits, and meetings.
Outputs include work performance information, change requests, and updates to the
project management plan, project documents, and organizational process assets.

Using Software to Assist in Project Risk Management

As you saw in several parts of this chapter, you can use a variety of software tools to
enhance various risk management processes. Most organizations use software to create,
update, and distribute information in their risk registers. The risk register is often a simple
Microsoft Word or Excel file, but it can also be part of a more sophisticated database.
Spreadsheets can aid in tracking and quantifying risks, preparing charts and graphs, and
performing sensitivity analysis. Software can be used to create decision trees and estimate
expected monetary value.

More sophisticated risk management software, such as Monte Carlo simulation software,
can help you develop models and use simulations to analyze and respond to various risks.
Several high-end project management tools include simulation capabilities. Several software
packages have also been created specifically for project risk management. Although it has
become easier to do sophisticated risk analysis with new software tools, project teams must
be careful not to rely too heavily on software when performing project risk management. If a
risk is not identified, it cannot be managed, and intelligent, experienced people are needed
to do a good job of identifying risks. It also takes hard work to develop and implement good
risk response strategies. Software should be used as a tool to help make good decisions in
project risk management, not as a scapegoat when things go wrong.

Considerations for Agile/Adaptive Environments

The PMBOK® Guide – Sixth Edition provides the following information for project risk
management:

High-variability environments, by definition, incur more uncertainty and risk. To
address this, projects managed using adaptive approaches make use of frequent
reviews of incremental work products and cross-functional project teams to
accelerate knowledge sharing and ensure that risk is understood and managed. Risk
is considered when selecting the content of each iteration, and risks will also be
identified, analyzed, and managed during each iteration.

Additionally, the requirements are kept as a living document that is updated regularly,
and work may be reprioritized as the project progresses, based on an improved
understanding of current risk exposure.20

All type of projects should share knowledge related to risks as quickly as possible and
keep documents up to date. It is true that risk is considered during each iteration for

Project Risk Management 495

agile/adaptive projects, which does elevate its importance. Changing priorities can be
addressed more easily by changing the product backlog for each iteration.

Well-run projects, like a master violinist’s performance, an Olympic athlete’s gold
medal win, or a Pulitzer Prize–winning book, appear to be almost effortless. Those on the
outside—whether audiences, customers, or managers—cannot observe the effort that goes
into a superb performance. They cannot see the hours of practice, the edited drafts, or
the planning, management, and foresight that create the appearance of ease. To improve
IT project management, project managers should strive to make their jobs look easy—it
reflects the results of a well-run project. You can be a change agent in your organization
by stressing the need for good project risk management to help more projects succeed.

Case Wrap-Up

Cliff Branch and two of his senior people attended a seminar on project risk management
where the speaker discussed several techniques, such as estimating the expected mon-
etary value of projects and Monte Carlo simulations. Cliff asked the speaker how these
techniques could help his company decide which projects to bid on, because bidding
on projects often required up-front investments with the possibility of no payback. The
speaker walked through an example of EMV and then ran a quick Monte Carlo simula-
tion. Cliff did not have a strong math background and had a hard time understanding the
EMV calculations. He thought the simulation was much too confusing to have any practi-
cal use for him. He believed in his gut instincts much more than any math calculation or
computer output.

The speaker finally sensed that Cliff was not impressed, so she explained the impor-
tance of looking at the odds of winning project awards and not just at the potential prof-
its. She suggested using a risk-neutral strategy by bidding on projects that the company
had a good chance of winning (50 percent or so) and that had a good profit potential,
instead of focusing on projects that they had a small chance of winning and that had a
larger profit potential. Cliff disagreed with this advice, and he continued to bid on high-
risk projects. The two other managers who attended the seminar now understood why
the firm was having problems—their leader loved taking risks, even if it hurt the com-
pany. They soon found jobs with competing companies, as did several other employees.

496 Chapter 11

Chapter Summary

Risk is an uncertainty that can have a negative or positive effect on meeting project objectives.
Many organizations do a poor job of project risk management, if they do any at all. Successful
organizations realize the value of good project risk management.

Risk management is an investment; in other words, costs are associated with identifying
risks, analyzing those risks, and establishing plans to address them. Those costs must be
included in cost, schedule, and resource planning.

Risk utility or risk tolerance is the amount of satisfaction or pleasure received from a
potential payoff. Risk seekers enjoy high risks, risk-averse people do not like to take risks, and
risk-neutral people seek to balance risks and potential payoff.

Project risk management is a process in which the project team continually assesses
what risks may negatively or positively affect the project, determines the probability of such
events occurring, and determines the impact if such events occur. Risk management also
involves analyzing and determining alternate strategies to deal with risks. The processes of
risk management are planning risk management, identifying risks, performing qualitative risk
analysis, performing quantitative risk analysis, planning risk responses, implementing risk
responses, and monitoring risks.

Planning risk management is the process of deciding how to approach risk management
activities and plan for them in a project. Contingency plans are predefined actions that a project
team will take if an identified risk event occurs. Fallback plans are developed for risks that have a
high impact on meeting project objectives and are implemented if attempts to reduce the risk are
not effective. Contingency reserves or contingency allowances are provisions held by the project
sponsor or organization to reduce the risk of cost or schedule overruns to an acceptable level.

IT projects often involve several risks, including lack of user involvement, lack of executive
management support, unclear requirements, and poor planning. Lists developed by the
Standish Group and other organizations can help you identify potential risks on IT projects.
A risk breakdown structure is a useful tool that can help project managers consider potential
risks in different categories. Lists of common risk conditions in project management knowledge
areas can also be helpful in identifying risks, as can techniques such as brainstorming, the
Delphi technique, interviewing, and SWOT analysis. A risk register is a document that contains
results of various risk management processes; it is often displayed in a table or spreadsheet
format. A risk register is a tool for documenting potential risk events and related information.
Risk events refer to specific, uncertain events that may occur to the detriment or enhancement
of the project.

Risks can be assessed qualitatively and quantitatively. Tools for qualitative risk analysis
include a probability/impact matrix and the Top Ten Risk Item Tracking technique. Tools for
quantitative risk analysis include decision trees and Monte Carlo simulation. Expected monetary
value (EMV) uses decision trees to evaluate potential projects based on their expected value.
Simulations are a more sophisticated method for creating estimates to help you determine the
likelihood of meeting specific project schedule or cost goals. Sensitivity analysis is used to show
the effects of changing one or more variables on an outcome.

Project Risk Management 497

The five basic responses to negative risks are avoidance, acceptance, transference,
mitigation, and escalation. Risk avoidance involves eliminating a specific threat or risk. Risk
acceptance means accepting the consequences of a risk if it occurs. Risk transference is
shifting the consequence of a risk and responsibility for its management to a third party. Risk
mitigation is reducing the impact of a risk event by reducing the probability of its occurrence. Risk
escalation is elevating the risk event to a higher-level authority. Five basic response strategies
for positive risks are risk exploitation, risk sharing, risk enhancement, risk acceptance, and risk
elevation.

Implementing risk responses involves putting the appropriate risk response plans into
action. Monitoring risks involves monitoring the implementation of risk response plans, tracking
identified risks, identifying and analyzing new risks, and evaluating the effectiveness of risk
management throughout the entire project.

Several types of software can assist in project risk management. Monte Carlo–based
simulation software is a particularly useful tool to help you get a better idea of project risks and
top sources of risk or risk drivers.

Be sure to consider how project risk management can differ in agile/adaptive environments.

Discussion Questions

1. Discuss the risk utility function and risk preference chart in Figure 11-2. Would you rate
yourself as being risk-averse, risk-neutral, or risk-seeking? Give examples of each approach
from different aspects of your life, such as your current job, your personal finances,
romances, and eating habits.

2. What are some questions that should be addressed in a risk management plan?

3. Discuss the common sources of risk on IT projects and suggestions for managing them.
Which suggestions do you find most useful? Which do you feel would not work in your
organization? Why?

4. What is the difference between using brainstorming and the Delphi technique for risk
identification? What are some of the advantages and disadvantages of each approach?
Describe the contents of a risk register and how it is used in several risk management
processes.

5. Describe how to use a probability/impact matrix and the Top Ten Risk Item Tracking
approaches for performing qualitative risk analysis. How could you use each technique on a
project?

6. Explain how to use decision trees and Monte Carlo analysis for quantifying risk. Give an
example of how you could use each technique on an IT project.

7. Provide realistic examples of each of the risk response strategies for both negative and
positive risks.

8. List the tools and techniques for performing risk control.

9. How can you use Excel to assist in project risk management? What other software can help
project teams make better risk management decisions?

498 Chapter 11

Quick Quiz

1. is an uncertainty that can have a negative or positive effect on meeting
project objectives.

a. Risk utility

b. Risk tolerance

c. Risk management

d. Risk

2. A person who is risk- receives greater satisfaction when more payoff is at

stake and is willing to pay a penalty to take risks.

a. averse

b. seeking

c. neutral

d. aware

3. Which risk management process involves prioritizing risks based on their probability and
impact of occurrence?

a. Planning risk management

b. Identifying risks

c. Performing qualitative risk analysis

d. Performing quantitative risk analysis

4. Your project involves using a new release of a common software application, but if that

release is not available, your team has plans to use the current release.

a. contingency

b. fallback

c. reserve

d. mitigation

5. Which risk identification tool involves deriving a consensus among a panel of experts by
using anonymous input regarding future events?

a. Risk breakdown structure

b. Brainstorming

c. Interviewing

d. Delphi technique

6. A risk is a document that contains results of various risk management

processes, and is often displayed in a table or spreadsheet format.

a. management plan

b. register

c. breakdown structure

d. probability/impact matrix

Project Risk Management 499

7. are indicators or symptoms of actual risk events, such as a cost overrun on
early activities being a symptom of poor cost estimates.
a. Probabilities
b. Impacts
c. Watch list items
d. Triggers

8. Suppose there is a 30 percent chance that you will lose $10,000 and a 70 percent chance
that you will earn $100,000 on a particular project. What is the project’s estimated monetary
value?
a. −$30,000
b. $70,000
c. $67,000
d. −$67,000

9. is a quantitative risk analysis tool that uses a model of a system to analyze
its expected behavior or performance.
a. Simulation
b. Sensitivity analysis
c. Monte Carlo analysis
d. EMV

10. Your project team has decided not to use an upcoming release of software because it might
cause your schedule to slip. Which negative risk response strategy are you using?
a. avoidance
b. acceptance
c. transference
d. mitigation

Quick Quiz Answers

1. d; 2. b; 3. c; 4. a; 5. d; 6. b; 7. d; 8. c; 9. a; 10. a

Exercises

1. Suppose your college or organization is considering a project to develop an information
system that would allow all employees, students, and customers to access and maintain
their own human resources information, such as address, marital status, and tax
information. The main benefits of the system would be a reduction in human resources
personnel and more accurate information. For example, if an employee, student, or
customer had a new telephone number or e-mail address, he or she would be responsible
for entering the data in the new system. The new system would also allow employees to

500 Chapter 11

change their tax withholdings or pension plan contributions. Identify five potential risks for
this new project, and be sure to list some negative and positive risks. Provide a detailed
description of each risk and propose strategies for addressing each risk. Document your
results in a short paper.

2. Review a document related to risk management, such as the Microsoft Security Risk
Management Guide. Does this guide address most of the topics related to risk management
planning, as described in this text? Document your analysis in a short paper.

3. Research risk management software. Are many products available? What are the main
advantages of using them in managing projects? What are the main disadvantages? Write a
short paper to discuss your findings, and include at least three references.

4. Suppose that your organization is deciding which of four projects to bid on, as summarized
in the following table. Assume that all up-front investments are not recovered, so they are
shown as negative profits. Draw a diagram and calculate the EMV for each project. Write
a few paragraphs explaining which projects you would bid on. Be sure to use the EMV
information and your personal risk tolerance to justify your answer.

Project Chance of Outcome Estimated Profits
Project 1
Project 2 50 percent $120,000
50 percent −$50,000
Project 3
Project 4 30 percent $100,000
40 percent $ 50,000
30 percent −$60,000

70 percent $ 20,000
30 percent −$ 5,000

30 percent $ 40,000
30 percent $ 30,000
20 percent $ 20,000
20 percent −$50,000

5. Open the template file called breakeven using Microsoft Excel. Examine the formulas in
the file to understand the relationships between the variables (such as sales price per
unit, manufacturing cost per unit, and fixed monthly expenses) and the outputs (such as
break-even point and revenue at break-even point). Run at least three different scenarios,
changing the inputs as desired and noting the outputs. Write a short paper to summarize
the results, including screenshots of the three scenarios and your opinions on sensitivity
analysis in general and in this example.

6. Find an example of a company that took a big risk on an IT project and succeeded. In
addition, find an example of a company that took a big risk and failed. Summarize each
project and situation in a short paper. In the paper, you should also discuss whether you
believe that anything besides luck makes a difference between success and failure.

Project Risk Management 501

Running Case

You and your team identified some risks during the first week of the Global Treps Project.
However, you never ranked the risks or developed any response strategies. Because several
negative risk events have already occurred (such as Ashok breaking his wrist and poor
communications with a key stakeholder in Ethiopia, as described in Chapter 10), you have
decided to be more proactive in managing risks. You also want to address positive risks as well
as negative risks.

1. Create a risk register for the project, using Table 11-4 and the template called risk register.
Identify six potential risks, including risks related to the problems described in the preceding
paragraph. Include three negative and three positive risks. Describe the risks using the
format: “Because of <one or more causes>, <risk event> might occur, which would lead to
<one or more effects>.”

2. Plot the six risks on a probability/impact matrix, using Figure 11-5 as a guide and the
template called probability impact matrix. Also assign a numeric value for the probability that
a risk will occur and the impact of each risk on meeting the main project objectives. Use a
scale of 1 to 10 to assign the values, with 1 representing the lowest value. For a simple risk
factor calculation, multiply the probability score and the impact score. Add a column called
Risk Score to your risk register to the right of the impact column. Enter the new data in the
risk register. Write your rationale for how you determined the scores for one of the negative
risks and one of the positive risks.

3. Develop a response strategy for one of the negative risks and one of the positive risks. Enter
the information in the risk register. Also write a separate paragraph describing what specific
tasks would be required to implement the strategy. Include time and cost estimates for each
strategy as well.

Key Terms Monte Carlo analysis
probability/impact matrix or chart
brainstorming residual risks
contingency allowances risk
contingency plans risk acceptance
contingency reserves risk appetite
decision tree risk-averse
Delphi technique risk avoidance
expected monetary value (EMV) risk breakdown structure
fallback plans risk enhancement
flowcharts risk events
influence diagram risk exploitation
interviewing risk factors
known risks
management reserves

502 Chapter 11 risk utility
secondary risks
risk management plan sensitivity analysis
risk mitigation Top Ten Risk Item Tracking
risk-neutral triggers
risk owner unknown risks
risk register watch list
risk-seeking workarounds
risk sharing
risk tolerance
risk transference

Endnotes

1 C. William Ibbs and Young Hoon Kwak, “Assessing Project Management Maturity,” Project
Management Journal 31, no. 1 (March 2000), pp. 32–43.

2 Aneerav Sukhoo, Andries Barnard, Mariki M. Eloff, and John A. Van der Poll, “An
Assessment of Software Project Management Maturity in Mauritius,” Issues in Informing
Science and Information Technology 2 (May 2003), pp. 671–690.

3 Peter Kulik and Catherine Weber, “Software Risk Management Practices—2001,” KLCI
Research Group (August 2001).

4 David Hillson, “Boom, bust, and risk management,” Project Manager Today (September
2008).

5 SAS, “Survey: Better risk management would have lessened credit crisis,” SAS Press
Release (September 18, 2008).

6 Michael Versace, “Forecast: Financial Services Industry Will Continue to Spend Big on Risk
IT,” Global Association of Risk Professionals (May 15, 2015).

7 David Hillson, “Integrated Risk Management as a Framework for Organisational Success,”
PMI Global Congress Proceedings (2006).

8 Hilson, David, “Managing Overall Project Risk,” PMI Global Congress Proceedings (2014).

9 The Standish Group, CHAOS Manifesto 2015 (2015).

10 Andy Cole, “Runaway Projects—Cause and Effects,” Software World 26, no. 3 (1995), pp. 3–5.

11 KPMG International, “Expectation of Risk Management Outpacing Capabilities – It’s Time
for Action” (2013).

12 The Guardian, “Germanwings crash: Call for technology to enable remote command of
plane,” The Guardian (April 15, 2015).

13 R. Max Wideman, “Project and Program Risk Management: A Guide to Managing Project
Risks and Opportunities” (Upper Darby, PA: Project Management Institute, 1992), II–4.

14 J. Daniel Couger, Creative Problem Solving and Opportunity Finding (New York: Boyd &
Fraser Publishing Company, 1995).

15 McDonnell Douglas Corporation, “Hi-Rel Fighter Concept,” Report MDC B0642 (1988).

Project Risk Management 503

16 Bruce J. Weeks, “Risk Determination in Highly Interactive Environments: How to Avoid the
Titanic Factor in Your Project,” PMI Virtual Library (2010).

17 Microsoft Corporation, “Introduction to Monte Carlo simulation,” support.office.com/en-ca/
article/Introduction-to-Monte-Carlo-simulation-64c0ba99-752a-4fa8-bbd3-4450d8db16f1
(accessed June 18, 2015).

18 Jerry Odenwelder, “How to Reduce Agile Risk with Monte Carlo Simulation,” VersionOne
(March 21, 2015).

19 Jean Couillard, “The Role of Project Risk in Determining Project Management Approach,”
Project Management Journal 25, no. 4 (December 1995), pp. 3–15.

20 Project Management Institute, Inc., A Guide to the Project Management Body of
Knowledge (PMBOK® Guide) – Sixth Edition (2017), p. 400.



1 2C h a p t e r

Project Procurement
Management

Learning Objectives

After reading this chapter, you will be able to:
• Explain the importance of project procurement management and the

increasing use of outsourcing for information technology (IT) projects
• Describe the work involved in planning procurements for projects,

including determining the proper type of contract to use and preparing
a procurement management plan, statement of work, source selection
criteria, and make-or-buy analysis
• Discuss how to conduct procurements and strategies for obtaining seller
responses, selecting sellers, and awarding contracts
• Describe the process of controlling procurements by managing
procurement relationships and monitoring contract performance
• Discuss types of software that are available to assist in project
procurement management
• Discuss considerations for agile/adaptive environments

506 Chapter 12

Opening Case

Marie McBride could not believe how much money her company was paying for outside
consultants to help finish an important system conversion project. The consulting
company’s proposal said it would provide experienced professionals who had completed
similar conversions, and that the job would be finished in six months or less with four
consultants working full time. Nine months later her company was still paying high
consulting fees, and half of the original consultants on the project had been replaced
with new people. One new consultant had graduated from college only two months
before and had extremely poor communications skills. Marie’s internal staff complained
that they were wasting time training some of these “experienced professionals.” Marie
talked to her company’s purchasing manager about the contract, fees, and special clauses
that might be relevant to the problems they were having.

Marie was dismayed at how difficult it was to interpret the contract. It was very
long and obviously written by someone with a legal background. When she asked what
her company could do because the consulting firm was not following its proposal, the
purchasing manager stated that the proposal was not part of the official contract. Marie’s
company was paying for time and materials, not specific deliverables. There was no
clause stating the minimum experience level required for the consultants, nor were there
penalty clauses for not completing the work on time. There was a termination clause,
however, meaning that the company could terminate the contract. Marie wondered
why her company had signed such a poor contract. Was there a better way to procure
services from outside the company?

The Importance of Project Procurement Management

Procurement means acquiring goods and services from an outside source. The term
procurement is widely used in government; many private companies use the terms
purchasing and outsourcing. Organizations or individuals who provide procurement
services are referred to as suppliers, vendors, contractors, subcontractors, or sellers; of
these terms, suppliers is the most widely used. Many IT projects involve the use of goods
and services from outside the organization. The Project Management Institute defines
an outside source as a source outside the project team, so the same organization can be
a supplier to the project team, or the project team can be a supplier to another group in
the organization. In fact, many IT departments in organizations are in direct competition
with outside vendors, and they are subject to the same kind of requirements definition,
statements of work, and bids. The rules and methods of sound project procurement
practices are good to follow regardless of who provides the services to whom.

As you learned in Chapter 2, outsourcing is a hot topic for research and debate,
especially the implications of outsourcing to other countries, which is called offshoring.
Gartner estimated the value of the global IT industry to reach $3.7 trillion, an increase
of 4 percent from 2017. The largest spending category is communications services at
39 percent of the total or about $1.4 trillion.1 According to a study by Deloitte, the
outsourcing market continues to grow:

Project Procurement Management 507

• Outsourcing more mature business functions such as IT, human resources,
and finance continued to grow, as did additional functions, like real estate,
facilities management, and procurement.

• Survey respondents cited the top reasons for outsourcing as cost cutting,
focusing on core business, and solving capacity issues.

• “Companies are redefining the benefits of outsourcing by asking their service
providers to add value in ways beyond cost cutting, such as enabling mergers
and acquisitions (M&A activity, providing needed capacity, and advancing
functional capabilities).”2

Glo b a l I s s u e s

A recent approach to bringing IT jobs back to the U.S. is called urban onshoring. Soft-
ware testing in particular has sparked several organizations to work together to meet the
need for jobs in low income, high unemployment urban areas, improve quality and effi-
ciency, and reduce overseas costs. For example, Doran Jones Inc., a startup consulting
firm that does testing work for banks and media companies in Manhattan, partnered with
Per Scholas to create the first Urban Development Center (UDC) for software testing
projects. The UDC model develops the infrastructure, resources, and jobs in low-income
urban neighborhoods as part of a company’s Corporate Social Responsibility strategy. Per
Scholas is the oldest and largest professional IT workforce development program in New
York City. They provide technology education, training, and job placement services for
over 4,500 unemployed and low-income adults.

Several start-up companies are applying similar models in an effort to improve bleak
neighborhoods, like Hunts Point in the South Bronx. Startup Box, founded by husband
and wife team Majora Carter and James Chase, is initially focusing on quality assurance
testing for games and apps like Game Chaser. To recruit testers, they hold gaming tour-
naments in and around Hunts Point and provide feedback on the games to developers,
similar to a focus group.

Doran Jones Inc. and Startup Box do not want their work to be viewed as charity
projects. “As offshoring becomes more and more problematic in the ever-changing tech
world … on-shoring is a major market opportunity. They can make outsourcing more
efficient and diversify the talent pipeline in tech, in addition to bringing some much
needed jobs back to the US. Both Startup Box and Doran Jones have plans to replicate
this urban on shoring thing in other cities.”3

Politicians debate whether offshoring helps their own country or not. Andy Bork,
chief operating officer of a computer network service provider, described outsourcing
as an essential part of a healthy business diet. He described the idea of good versus bad
outsourcing as something like good versus bad cholesterol. He said that most people view
offshoring as being bad because it takes jobs away from domestic workers. However, many
companies are realizing that they can use offshoring and create more jobs at home.4
Other companies, like Walmart, successfully manage the majority of their IT projects

508 Chapter 12

in-house with very little commercial software and no outsourcing at all. Other organiza-
tions are moving IT services back in-house, such as General Motors (GM). Randy Mott,
the CIO of GM and former CIO of Walmart, Dell, and Hewlett-Packard, overhauled GM’s IT
operations and switched from outsourcing 90 percent of its IT services to only 10 percent
from 2012 to 2015. See the What Went Right? feature for a description of how Zulily con-
tinues to use in-house software development to provide a competitive advantage.

What Went Right?

Retailer Zulily, a $1.5 billion company that celebrated its eight birthday in 2018, is one
of a growing number of organizations developing software in-house to meet their need for
speed and innovation. CIO Luke Friang said it would be nearly impossible for off-the-shelf
software to keep up with their pace. Zulily offers flash sales where items are available for
limited times only, and its website technology to track and customize the shopping expe-
rience are an essential part of their business strategy. Other companies gaining competi-
tive advantages by developing innovative, in-house software include G­ eneral Motors and
Tesla Motors Inc.

Zulily developed proprietary algorithms that track customers throughout the site
and quickly make adjustments to meet changing consumer preferences. The retailer,
based in Seattle, sends customers e-mails containing deals targeted to what they’ve
bought from the site and to their page viewing patterns.

Under Friang’s leadership for over seven years, the technology team has grown
20-fold. “We’re currently making huge investments in our Big Data platform, our AWS
migration and our proprietary warehouse management software,” Friang said. “We’re
looking to make significant technology hires this year—currently hiring across product,
data science, supply chain and operations.”5

Deciding whether to outsource, what to outsource, and how to outsource are impor-
tant topics for many organizations throughout the world. Organizations are turning to out-
sourcing to accomplish the following:

• Access skills and technologies. Organizations can gain access to specific
skills and technologies when they are required by using outside resources. As
mentioned earlier, a shortage of qualified personnel is the main reason that
companies outsource IT services. A project may require experts in a particu-
lar field for several months, or it might require specific technologies from an
outside source. Planning for this procurement ensures that the needed skills
and technologies will be available for the project.

• Reduce both fixed and recurrent costs. Outsourcing suppliers often can use
economies of scale that may not be available to the client alone, especially
for hardware and software. It can also be less expensive to outsource some
labor costs to other organizations in the same country or offshore. Compa-
nies can use outsourcing to reduce labor costs on projects by avoiding the
costs of hiring, firing, and reassigning people to projects or paying their sala-
ries when they are between projects.

Project Procurement Management 509

• Allow the client organization to focus on its core business. Most organiza-
tions are not in business to provide IT services, yet many have spent valuable
time and resources on IT functions when they should have focused on core
competencies such as marketing, customer service, and new product design.
By outsourcing many IT functions, employees can focus on jobs that are
critical to the success of the organization.

• Provide flexibility. Outsourcing to provide extra staff during periods of peak
workloads can be much more economical than trying to staff entire projects
with internal resources. Many companies cite better flexibility in staffing as a
key reason for outsourcing. As you learned in Chapter 2, Apple says it could
not produce several of its products fast enough without outsourcing.

• Increase accountability. A well-written contract—a mutually binding agree-
ment that obligates the seller to provide specified products or services and
obligates the buyer to pay for them—can clarify responsibilities and sharpen
focus on key deliverables of a project. Because contracts are legally binding,
there is more accountability for delivering the work as stated in the contract.

Organizations must also consider reasons they might not want to outsource. When an
organization outsources work, it often does not have as much control over the aspects of
projects that suppliers carry out. In addition, an organization could become too dependent
on particular suppliers. If those suppliers went out of business or lost key personnel, it could
cause great damage to a project. Organizations must also be careful to protect strategic infor-
mation that could become vulnerable in the hands of suppliers. According to Scott McNealy,
co-founder and former CEO of Sun Microsystems, Inc., “What you want to handle in-house is
the stuff that gives you an edge over your competition—your core competencies. I call it your
‘secret sauce.’ If you’re on Wall Street and you have your own program for tracking and ana-
lyzing the market, you’ll hang onto that. At Sun, we have a complex program for testing micro-
processor designs, and we’ll keep it.”6 Project teams must think carefully about procurement
issues and make wise decisions based on the unique needs of their projects and organizations.
They must also be aware of political issues, as described in the following example.

What Went Wrong?

In 2011, New York City’s mayor, Michael Bloomberg, acknowledged that City Hall had
mismanaged its major IT projects and vowed to improve their oversight. He even said that
city administrators would not oppose legislation requiring them to alert the City Council
when projects ran into serious problems. These statements were made at a Council hear-
ing called in response to reports of troubled technology projects. For example, prosecu-
tors said the $700 million price tag for the CityTime payroll system was inflated by fraud,
and the mayor demanded $600 million back from the main contractor. The automated
personnel system, Nycaps, suffered significant delays and cost overruns due to leader-
ship issues, increasing from an original estimate of $66 million to over $363 million.

(continued)

510 Chapter 12

Caswell F. Holloway, the deputy mayor for operations, testified at the hearing that
the administration had begun an overhaul of how it manages complex technology proj-
ects. He said it would seek more use of off-the-shelf software and avoid paying consul-
tants by the hour when it could specify completion of key deliverables for payment. He
also said the city would stop letting individual agencies negotiate their own contracts
and bring in the city’s Law Department and the Mayor’s Office of Contract Services to
negotiate IT contracts worth more than $5 million.

“Other speakers at the hearing said that much of what Mr. Holloway was promising
to do was already written into city policy, to little effect. Henry Garrido, research direc-
tor for District Council 37, the municipal workers’ union, said a standard clause in the
city’s IT contracts allowed the city to sue contractors for damages. ‘But the city doesn’t
exercise it,’ he said.”7

Outsourcing can also cause problems in other areas for companies and nations as a
whole. For example, in 2004 many people in Australia were concerned about outsourcing
software development. “The Australian Computer Society says sending work offshore
may lower the number of students entering IT courses, deplete the number of skilled IT
professionals, and diminish the nation’s strategic technology capability. Another issue is
security, which encompasses the protection of intellectual property, integrity of data, and
the reliability of infrastructure in offshore locations.”8 A 2018 article stated that the job
market for IT workers in Australia did improve as several companies brought jobs back
to the country. “We start 2018 off the back of a strong, stable run of jobs growth where
the labour market grew by over 383,000 positions in the past 12 months,” said Nick
Deligiannis, Managing Director of Hays in Australia and New Zealand. “Basically, more
people are looking for and finding work.”9

The success of many IT projects that use outside resources is often due to good
project procurement management. Project procurement management includes the
processes required to acquire goods and services for a project from outside the performing
organization. Organizations can be either the buyer or the seller of products or services
under a contract or other agreement.

There are three main processes in project procurement management:

1. Planning procurement management involves determining what to procure
and when and how to do it. In procurement planning, one must decide what
to outsource, determine the type of contract, and describe the work for
potential sellers. Sellers are providers, contractors, or suppliers who provide
goods and services to other organizations. Outputs of this process include
a procurement management plan, procurement strategy, bid documents,
procurement statement of work, source selection criteria, make-or-buy
decisions, independent cost estimates, change request, project documents
updates, and organizational process assets updates.

2. Conducting procurements involves obtaining seller responses, selecting sell-
ers, and awarding contracts. Outputs include selected sellers, agreements,

Project Procurement Management 511

change requests, and updates to the project management plan, project docu-
ments, and organizational process assets.
3. Controlling procurements involves managing relationships with sellers, mon-
itoring contract performance, making changes as appropriate, and closing
out contracts. The main outputs of this process include closed procurements,
work performance information, procurement documentation updates, change
requests, project management plan updates, project documents updates, and
organizational process assets.

Figure 12-1 summarizes the inputs, tools and techniques, and outputs of project pro-
curement management.

Project Procurement
Management Overview

12.1 Plan Procurement 12.2 Conduct 12.3 Control
Management Procurements Procurements

.1 Inputs .1 Inputs .1 Inputs
.1 Project charter .1 Project management plan .1 Project management plan
.2 Business documents .2 Project documents .2 Project documents
.3 Project management plan .3 Procurement documentation .3 Agreements
.4 Project documents .4 Seller proposals .4 Procurement documentation
.5 Enterprise environmental .5 Enterprise environmental .5 Approved change requests
factors factors .6 Work performance data
.6 Organizational process .6 Organizational process .7 Enterprise environmental
assets assets factors
.8 Organizational process
.2 Tools & Techniques .2 Tools & Techniques assets
.1 Expert judgment .1 Expert judgment
.2 Data gathering .2 Advertising .2 Tools & Techniques
.3 Data analysis .3 Bidder conferences .1 Expert judgment
.4 Source selection analysis .4 Data analysis .2 Claims administration
.5 Meetings .5 Interpersonal and team .3 Data analysis
skills .4 Inspection
.3 Outputs .5 Audits
.1 Procurement management .3 Outputs
plan .1 Selected sellers .3 Outputs
.2 Procurement strategy .2 Agreements .1 Closed procurements
.3 Bid documents .3 Change requests .2 Work performance
.4 Procurement statement .4 Project management plan information
of work updates .3 Procurement documentation
.5 Source selection criteria .5 Project documents updates updates
.6 Make-or-buy decisions .6 Organizational process .4 Change requests
.7 Independent cost estimates assets updates .5 Project management plan
.8 Change requests updates
.9 Project documents updates .6 Project documents updates
.7 Organizational process
.10 Organizational process assets updates
assets updates

Source: PMBOK® Guide – Sixth Edition. Project Management Institute, Inc. (2017). Copyright and
all rights reserved. Material from this publication has been reproduced with permission of PMI.

Figure 12-1  Project procurement management overview

512 Chapter 12

Planning Procurement Management

Planning procurements involves identifying which project needs can best be met by using
products or services outside the organization. It involves deciding whether to procure,
how to procure, what to procure, how much to procure, and when to procure. An impor-
tant output of this process is the make-or-buy decision, in which an organization decides
whether it should make certain products and perform certain services inside the organi-
zation, or if it is better to buy those products and services from an outside organization.
If there is no need to buy products or services from outside the organization, then further
procurement management is not needed.

Inputs needed for planning procurements include the project charter, business docu-
ments, the project management plan, project documents enterprise environmental fac-
tors, and organizational process assets, such as types of contracts.

Types of Contracts

Contract type is an important consideration in procurement management. Different types
of contracts can be used in different situations. Three broad categories of contracts are
fixed price or lump sum, cost reimbursable, and time and material. A single contract can
actually include all three of these categories if it makes sense for a particular procure-
ment. For example, you could have a contract with a seller that includes purchasing
specific hardware for a fixed price or lump sum, some services that are provided on a
cost-reimbursable basis, and other services that are provided on a time-and-material basis.
Project managers and their teams must understand and decide which approaches to use to
meet their project needs. It is also important to understand when and how to take advan-
tage of unit pricing in contracts.

Fixed-price or lump-sum contracts involve a fixed total price for a well-defined
product or service. The buyer incurs little risk in this situation because the price is
predetermined. The sellers often pad their estimate to reduce their risk, although they
realize their price must still be competitive. For example, a company could award a
fixed-price contract to purchase 100 laser printers with a certain print resolution and
print speed to be delivered to one location within two months. In this example, the
product and delivery date are well defined. Several sellers could create fixed-price
estimates for completing the job. Fixed-price contracts may also include incentives
for meeting or exceeding selected project objectives. For example, the contract could
include an incentive fee paid if the laser printers are delivered within one month.
A firm-fixed-price (FFP) contract has the least amount of risk for the buyer, followed by
a fixed-price incentive fee (FPIF) contract. A fixed-price with economic price adjust-
ment contract (FP-EPA) includes a special provision for predefined final adjustments to
the contract price due to changes in conditions such as inflation or the cost of specific
commodities. An FP-EPA contract is intended to protect both the buyer and seller from
external conditions beyond their control.

Contracts can also include incentives to prevent or reduce cost overruns. For exam-
ple, according to the U.S. Federal Acquisition Regulation (FAR) 16.4, fixed-price incentive
fee contracts can include a Point of Total Assumption (PTA), which is the cost at which
the contractor assumes total responsibility for each additional dollar of contract cost.

Project Procurement Management 513

Contractors do not want to reach the PTA because it hurts them financially, so they have
an incentive to prevent cost overruns. The PTA is calculated with the following formula:

PTA 5 (ceiling price 2 target price) / government share 1 target cost

For example, given the following information, and assuming that all dollar amounts
are in thousands, the PTA will be $1.2 million:

Ceiling price 5 $1, 250
Target price 5 $1,100
Target cost 5 $1, 000
Government share: 75 percent

PTA 5 ($1, 250 2 $1,100)/ .75 1 $1, 000 5 $1, 20010

Contracts for the U.S. federal government can be very complex. Consult FAR 16.4 and
similar references for more details.

Cost-reimbursable contracts involve payment to the supplier for direct and indirect
actual costs. Recall from Chapter 7 that direct costs can be directly related to producing a
project’s products and services. Normally, these costs can be traced back to a project in a
cost-effective way. Indirect costs are not directly related to the products or services of the
project, but they are indirectly related to performing the project. Normally, these costs can-
not be traced back to the project in a cost-effective way. For example, direct costs include
the salaries for people working directly on a project and hardware or software purchased for
a specific project. Indirect costs include the cost of providing a work space with electricity
and an employee cafeteria. Indirect costs are often calculated as a percentage of direct costs.
Cost-reimbursable contracts often include fees, such as a profit percentage or incentives for
meeting or exceeding selected project objectives. These contracts are often used for projects
that include providing goods and services that involve new technologies. The buyer absorbs
more of the risk with cost-reimbursable contracts than with fixed-price contracts. Three
types of cost-reimbursable contracts, in order of lowest to highest risk to the buyer, include
cost plus incentive fee, cost plus fixed fee, and cost plus percentage of costs.

• With a cost plus incentive fee (CPIF) contract, the buyer pays the supplier
for allowable costs (as defined in the contract) along with a predetermined
fee and an incentive bonus. See the Media Snapshot for an example of provid-
ing financial incentives to complete an important construction project ahead
of schedule. Also, incentives are often provided to suppliers for reducing
contract costs. If the final cost is less than the expected cost, both the buyer
and the supplier benefit from the cost savings, according to a negotiated
share formula. For example, suppose that the expected cost of a project is
$100,000, the fee to the supplier is $10,000, and the share formula is 85/15,
meaning that the buyer absorbs 85 percent of the uncertainty and the sup-
plier absorbs 15 percent. If the final cost is $80,000, the cost savings are
$20,000. The supplier would be paid the final cost and the fee plus an incen-
tive of $3,000 (15 percent of $20,000), for a total reimbursement of $93,000.

• With a cost plus fixed fee (CPFF) contract, the buyer pays the supplier for
allowable costs (as defined in the contract) plus a fixed fee payment that

514 Chapter 12

Media Snapshot

Contract incentives can be extremely effective. On August 1, 2007, tragedy struck
M­ inneapolis, Minnesota, when an Interstate bridge over the Mississippi River suddenly
collapsed, killing 13 motorists and injuring 150 people. The Minnesota Department
of Transportation (MnDOT) acted quickly to find a contractor to rebuild the bridge.
MnDOT also provided a strong incentive to finish the bridge as quickly as possible,
ensuring quality and safety along the way.

Peter Sanderson, project manager for the joint venture of Flatiron-Manson, led his
team in completing the rebuilding project three months ahead of schedule, and the new
bridge opened on September 18, 2008. The contractors earned $25 million in incentive
fees on top of their $234 million contract for completing the bridge ahead of schedule.

Why did MnDOT offer such a large incentive fee for finishing the project early?
“I-35W in Minneapolis is a major transportation artery for the Twin Cities and entire
state. Each day this bridge has been closed, it has cost road users more than $400,000,”
MnDOT Commissioner Tom Sorel remarked. “Area residents, business owners, motor-
ists, workers and others have been affected by this corridor’s closure. The opening of this
bridge reconnects our community.”11

is usually based on a percentage of estimated costs. This fee does not vary,
however, unless the scope of the contract changes. For example, suppose that
the expected cost of a project is $100,000 and the fixed fee is $10,000. If the
actual cost of the contract rises to $120,000 and the scope of the contract
remains the same, the contractor will still receive the fee of $10,000.
• With a cost plus award fee (CPAF) contract, the buyer pays the supplier
for allowable costs (as defined in the contract) plus an award fee based on
the satisfaction of subjective performance criteria. A tip or gratuity that you
would give a server in a restaurant would qualify as a simple example, as long
as there is no set gratuity percentage. You still pay for the cost of your meal,
but you can decide on the tip amount based on your satisfaction with the
food, drinks, and service provided. This type of contract is not usually sub-
ject to appeals.
• With a cost plus percentage of costs (CPPC) contract, the buyer pays the
supplier for allowable costs (as defined in the contract) along with a prede-
termined percentage based on total costs. From the buyer’s perspective, this
is the least desirable type of contract because the supplier has no incentive
to decrease costs. In fact, the supplier may be motivated to increase costs,
because doing so will automatically increase profits based on the percentage
of costs. This type of contract is prohibited for U.S. government use, but it is
sometimes used in private industry, particularly in the construction industry.
All of the risk is borne by the buyer.

Project Procurement Management 515

Time and material (T&M) contracts are a hybrid of fixed-price and cost-reimbursable
contracts. For example, an independent computer consultant might have a contract with a
company based on a fee of $80 per hour for services, plus a fixed price of $10,000 for provid-
ing specific project materials. The materials fee might also be based on approved receipts
for purchasing items, with a ceiling of $10,000. The consultant would send an invoice to
the company each week or month; the invoice would list the materials fee, the number of
hours worked, and a description of the work produced. This type of contract is often used
for required services when the work cannot be specified clearly and total costs cannot be
estimated in a contract. Many contract programmers and consultants, such as those Marie’s
company hired in the chapter’s opening case, prefer time and material contracts.

Unit pricing can also be used in various types of contracts to require the buyer to pay
the supplier a predetermined amount per unit of product or service. The total value of the
contract is a function of the quantities needed to complete the work. Consider an IT depart-
ment that might have a unit price contract for purchasing computer hardware. If the com-
pany purchases only one unit, the cost might be $1,000. If the company purchases 10 units,
the cost might be $10,000. This type of pricing often involves volume discounts. For exam-
ple, if the company purchases between 10 and 50 units, the contracted cost might be $900
per unit. If the company purchases more than 50 units, the cost might go down to $800 per
unit. This flexible pricing strategy is often advantageous to both the buyer and the seller.

Any type of contract should include specific clauses that account for unique project
issues. For example, if a company uses a time and material contract for consulting ser-
vices, the contract should stipulate different hourly rates based on the level of experience
of the individual contractors. The services of a junior programmer with no Bachelor’s
degree and less than three years’ experience might be billed at $40 per hour, whereas the
services of a senior programmer with a Bachelor’s degree and more than 10 years of expe-
rience might be billed at $80 per hour.

Figure 12-2 summarizes the spectrum of risk to the buyer and the supplier for differ-
ent types of contracts. Buyers have the least risk with firm-fixed-price contracts, because
they know exactly what they must pay the supplier. Buyers have the most risk with cost
plus percentage of costs (CPPC) contracts because they do not know the supplier’s costs
in advance, and the suppliers may be motivated to keep increasing costs. From the sup-
plier’s perspective, a CPPC contract carries the least risk and a firm-fixed-price contract
carries the most risk.

high Buyer risk low
FFP
CPPC CPFF CPIF CPAF FPI FP-EPA Firm-
Cost plus Cost plus Cost plus Cost plus Fixed-price Fixed-price fixed
percentage fixed fee incentive award fee incentive economic price
of costs Seller risk
fee price high
adjustment

low

Figure 12-2  Contract types versus risk

516 Chapter 12

Time and material contracts and unit-price contracts can be high or low risk, depend-
ing on the nature of the project and other contract clauses. For example, if an organization
is unclear in describing the work that needs to be done, it cannot expect a supplier to sign
a firm-fixed-price contract. However, the buyer could find a consultant or group of consul-
tants to work on specific tasks based on a predetermined hourly rate. The buying organiza-
tion could evaluate the work produced each day or week to decide if it wants to continue
using the consultants. In this case, the contract would include a termination clause—a
contract clause that allows the buyer or supplier to end the contract. Some termination
clauses state that the buyer can terminate a contract for any reason and give the supplier
only 24 hours’ notice. Suppliers, by contrast, must often give a one-week notice to termi-
nate a contract and must have sufficient reasons for the termination. The buyer could also
include a contract clause that specifies hourly rates based on the education and experi-
ence of consultants. These contract clauses reduce the risk incurred by the buyer while
providing flexibility for accomplishing the work.

It is important to understand why a company would want to procure goods or ser-
vices and what inputs are needed to plan purchases and acquisitions. In the opening
case, Marie’s company hired outside consultants to help complete an operating system
conversion project because it needed people with specialized skills for a short period of
time. This is a common occurrence in many IT projects. It can be more effective to hire
skilled consultants to perform specific tasks for a short period of time than to hire or keep
employees on staff full time.

However, it is also important to define clearly the scope of the project, the products,
services, or results required, market conditions, and constraints and assumptions. In
Marie’s case, the scope of the project and services required were relatively clear, but her
company may not have adequately defined the market conditions or constraints and
assumptions involved in using outside consultants. Could other companies provide con-
sultants to help with similar conversion projects? Did the project team investigate the
background of the company that provided the consultants? Did the team list important
constraints and assumptions for using the consultants, such as limiting the time that the
consultants had to complete the conversion project or the minimum years of experience
for any consultant assigned to the project? It is important to answer these types of ques-
tions before signing an outsourcing agreement.

Tools and Techniques for Planning Procurement Management

Several tools and techniques are available to help project managers and their teams in
planning procurement management, including make-or-buy analysis (a type of data gath-
ering), expert judgment, and market research (a type of data gathering).

Make-or-Buy Analysis

Make-or-buy analysis is a general management technique used to determine whether an
organization should make a product or perform a service inside the organization or buy it
from someone else. This form of analysis involves estimating the internal costs of provid-
ing a product or service and comparing the estimate to the cost of outsourcing. Consider
a company that has 1,000 international salespeople with laptops. Using make-or-buy

Project Procurement Management 517

analysis, the company could compare the cost of providing those services using inter-
nal resources to the cost of buying the same services from an outside source. If supplier
quotes were less than the company’s internal estimates, the company would have to con-
sider outsourcing the training and user support services. Another common make-or-buy
decision, though more complex, is whether a company should develop an application itself
or purchase software from an outside source and customize it to the company’s needs.

Many organizations also use make-or-buy analysis to decide whether to purchase or
lease items for a project. For example, suppose that a project requires a piece of equip-
ment that has a purchase price of $12,000 and daily operating costs of $400. Suppose that
you could lease the same piece of equipment for $800 per day, including the operating
costs. You can set up an equation so that you can see when the purchase cost equals the
lease cost and determine when it makes sense financially to lease or buy the equipment.
In this example, d is the number of days you need the piece of equipment. The equation
would be

$800/day 5 $12, 000 1 $400 /day

Subtracting $400/day from both sides, you get

$400/day 5 $12, 000

Dividing both sides by $400, you get

d 530

In other words, the purchase cost would equal the lease cost in 30 days. So, if you
need the equipment for less than 30 days, leasing would be more economical. If you need
the equipment for more than 30 days, you should purchase it. In general, leasing is often
cheaper for meeting short-term needs, but more expensive for long-term needs.

Expert Judgment

Experts both from inside and outside an organization can provide excellent advice in plan-
ning purchases and acquisitions. Project teams often need to consult experts within their
organization as part of good business practice. Internal experts might suggest that the
company in the preceding example could not provide training and support for the 1,000
laptop users because the service involves so many people with different skill levels in so
many different locations. Experts in the company might also know that most of their com-
petitors outsource this type of work and know who the qualified outside suppliers are. It
is also important to consult legal experts because contracts for outsourced work are legal
agreements.

Experts outside the company, including potential suppliers themselves, can also pro-
vide expert judgment. For example, suppliers might suggest an option for salespeople to
purchase the laptops themselves at a reduced cost. This option would solve problems that
would otherwise be created during employee turnover—exiting employees would own
their laptops and new employees would purchase a laptop through the program. An inter-
nal expert might then suggest that employees receive a technology bonus to help offset
what they might view as an added expense. Expert judgment, both internal and external,
is an asset in making many procurement decisions.

518 Chapter 12

Market Research

Market research is very important in planning procurements. Many potential suppliers are
often available for goods and services, so the project team must choose suppliers carefully.
Some organizations have a preferred vendor list and detailed information about them. A
wealth of information is also available online, and numerous conferences are held where
attendees can see and discuss new products.

Procurement Management Plan

As you have learned, every project management knowledge area includes some planning.
The procurement management plan is a document that describes how the procurement
processes will be managed, from developing documentation for making outside purchases
or acquisitions to contract closure. Like other project plans, contents of the procurement
management plan will vary with project needs. The following materials can be included in
a procurement management plan:

• Guidelines for types of contracts to be used in different situations
• Standard procurement documents or templates to be used, if applicable
• Guidelines for creating contract work breakdown structures, statements of

work, and other procurement documents
• Roles and responsibilities of the project team and related departments, such

as the purchasing or legal department
• Guidelines for using independent estimates to evaluate sellers
• Suggestions for managing multiple providers
• Processes for coordinating procurement decisions with other project areas,

such as scheduling and performance reporting
• Constraints and assumptions related to purchases and acquisitions
• Lead times for purchases and acquisitions
• Risk mitigation strategies for purchases and acquisitions, such as insurance

contracts and bonds
• Guidelines for identifying prequalified sellers and organizational lists of pre-

ferred sellers
• Procurement metrics to assist in evaluating sellers and managing contracts

Statement of Work

The statement of work (SOW) is a description of the work required for the procure-
ment. Some organizations use the term statement of work for a document that describes
internal work as well. If a SOW is used to describe only the work required for a particular
contract, it is called a contract statement of work. The contract SOW is a type of scope
statement that describes the work in sufficient detail to allow prospective suppliers to
determine if they can provide the required goods and services and to determine an appro-
priate price. A contract SOW should be clear, concise, and as complete as possible. It
should describe all services required and include performance reporting. It is important
to use appropriate wording in a contract SOW, such as must instead of may. For example,
must means that something has to be done; may implies that a choice is involved in doing
something or not. The contract SOW should specify the products and services required for
the project, use industry terms, and refer to industry standards.

Project Procurement Management 519

Statement of Work (SOW)
I . Scope of Work: Describe the work to be done in detail. Specify the hardware

and software involved and the exact nature of the work.
I I . Location of Work: Describe where the work must be performed. Specify the

location of hardware and software and where the people must perform the work.
I I I . Period of Performance: Specify when the work is expected to start and end,

working hours, number of hours that can be billed per week, where the work must
be performed, and related schedule information.
I V. Deliverables Schedule: List speci c deliverables, describe them in detail, and
specify when they are due.
V. Applicable Standards: Specify any company or industry-speci c standards that
are relevant to performing the work.
V I . Acceptance Criteria: Describe how the buyer organization will determine if the
work is acceptable.
V I I . Special Requirements: Specify any special requirements such as hardware or
software certifications, minimum degree or experience level of personnel, travel
requirements, and so on.

Figure 12-3  Statement of work (SOW) template

Many organizations use samples and templates to generate SOWs. Figure 12-3 pro-
vides a basic outline or template for a contract SOW that Marie’s organization could use
when hiring outside consultants or purchasing other goods or services. For example, for
the operating system conversion project, Marie’s company should specify the manufac-
turer and model number for the hardware involved, the former operating systems and new
ones for the conversion, and the number of pieces of each type of hardware involved. The
contract SOW should also specify the location of the work, the expected period of perfor-
mance, specific deliverables and when they are due, applicable standards, acceptance cri-
teria, and special requirements. A good contract SOW gives bidders a better understanding
of the buyer’s expectations. A contract SOW should become part of the official contract to
ensure that the buyer gets what the supplier bid on.

Procurement or Bid Documents

Planning procurements also involves preparing the documents needed for potential
sellers to bid on a project and determining the evaluation criteria for the contract award.
The project team often uses standard forms and expert judgment as tools to help create
relevant procurement documents and evaluation criteria.

520 Chapter 12

Three common examples of procurement documents include a Request for Proposal
(RFP), a Request for Quote (RFQ), and a Request for Information (RFI). A Request for
Proposal (RFP) is a document used to solicit proposals from prospective suppliers. A pro-
posal is a document prepared by a seller when there are different approaches for meeting
buyer needs. For example, if an organization wants to automate its work practices or solve
a business problem, it can write and issue an RFP so suppliers can respond with proposals.
Suppliers might propose various hardware, software, and networking solutions to meet the
organization’s need. Selections of winning sellers are often made on a variety of criteria, not
just the lowest price. Developing an RFP is often a time-consuming process. Organizations
must plan properly to ensure that they adequately describe what they want to procure,
what they want sellers to include in their proposals, and how they will evaluate proposals.

Although RFPs have been used for many years, outsourcing experts say the process is
becoming less appealing in several IT procurement processes. “In today’s dynamic era of
technology change, the traditional RFP simply takes too long and costs too much. By the time
the proposals come in, the business requirements have often changed.”12 Enterprise mar-
ketplaces, such as app stores that provide a collection of software and services for sale (i.e.,
Google Play, App Store, and IBM Cloud Marketplace) and other new purchasing processes will
emerge as companies collaborate with service providers to figure out better IT solutions.

A Request for Quote (RFQ) is a document used to solicit quotes or bids from pro-
spective suppliers. A bid, also called a tender or quote (short for quotation), is a docu-
ment prepared by sellers to provide pricing for standard items that the buyer has clearly
defined. Organizations often use an RFQ for solicitations that involve specific items. For
example, if a company wanted to purchase 100 personal computers with specific features,
it might issue an RFQ to potential suppliers. RFQs usually do not take nearly as long to
prepare as RFPs, nor do responses to RFQs. Selections are often based on the lowest bid.
A Request for Information (RFI) is sometimes used before issuing an RFP or RFQ to get
more information on the goods and services to be acquired.

Writing a good RFP is a critical part of project procurement management, but many
people have never had to write or respond to one. To generate a good RFP, expertise is
invaluable. Many examples of RFPs are available within different companies, from poten-
tial contractors, and from government agencies. Legal requirements are often involved in
issuing RFPs and reviewing proposals, especially for government projects. It is important
to consult with experts who know the contract planning process for particular organiza-
tions. To make sure that an RFP has enough information to provide the basis for a good
proposal, the buying organization should try to put itself in the suppliers’ shoes. Could the
organization develop a good proposal based on the information it provided in the RFP?
Could it determine detailed pricing and schedule information based on the RFP? Develop-
ing a good RFP is difficult, as is writing a good proposal.

The main sections of an RFP usually include its statement of purpose, background
information on the organization issuing the RFP, the basic requirements for the products
and services being proposed, the hardware and software environment (which is usually
important for IT-related proposals), a description of the RFP process, the statement of
work and schedule information, and possible appendices. A simple RFP might be three to
five pages long, but an RFP for a larger, more complicated procurement might take hun-
dreds of pages.

Project Procurement Management 521

Other terms used for RFQs and RFPs include invitations for bid, invitations for negotia-
tion, and initial contractor responses. Regardless of what they are called, all procurement
documents should be written to facilitate accurate and complete responses from prospective
sellers. Procurement documents should include background information on the organization
and project, a relevant statement of work, a schedule, a description of the desired form of
response, evaluation criteria, pricing forms, and any required contractual provisions. The docu-
ments should also be rigorous enough to ensure consistent, comparable responses, but flexible
enough to allow consideration of sellers’ suggestions for better ways to satisfy the requirements.

Examples from a Real RFP

Government agencies are often required to make procurement information open to the
public. For example, Houston First Corporation provides access to several documents from
www.houstonfirst.com/do-business/. One of these documents is an RFP issued in October,
2017 for project management services to assist the organization in overseeing rebuilding
after flooding from Hurricane Harvey. The initial RFP was nine pages long. A few excerpts
are provided in Table 12-1. Notice the detailed list of tasks in the section called “Scope of
Services.” Also notice the detailed instructions in the section called “Proposal Format.”
This RFP included the evaluation criteria, as discussed in more detail in the next section.

Even though the RFP in Table 12-1 seems pretty detailed, there were several questions
submitted from potential proposers. As a result, HFC issued three letters of clarification.
Table 12-2 lists a few items from these letters. Notice that the first item asks for hourly rates
instead of a lump-sum fee as initially requested. Proposers must have questioned the appro-
priateness of a lump-sum or fixed-price contract for this type of work. HFC responded by ask-
ing for rates and mentioning a “not-to-exceed amount” for the eight-month contract. There
is also a new section describing a pre-proposal conference, which the initial RFP said would
not be held. Again, potential proposers must have asked for this conference to help clarify the
procurement. Also notice the straightforward questions that were asked. As you can see, it’s
very important for buyers to clarify what they want so that sellers can respond appropriately.

Table 12-1  Example RFP for project management services

I. Purpose of RFP: Houston First Corporation (“HFC”) requests proposals from expe-
rienced project management firms with the ability to assist HFC in the oversight of
recovery and reconstruction projects at Wortham Theater Center and the Theater
District Underground Parking Garages in downtown Houston, Texas. . . . The rough
order of magnitude for the reconstruction phase, including ongoing emergency services
underway as of October 5, 2017, is estimated at 40–45 million dollars. Potential propos-
ers are advised that the contract resulting from the RFP will be a professional services
contract. This RFP is not for construction work.

II. Scope of Services: As the emergency remediation phase draws to a close, HFC seeks
to engage a project management firm to provide comprehensive coordination and sup-
port services throughout the reconstruction phase, including the following tasks:

(continued)

522 Chapter 12

Table 12-1  Example RFP for project management services (continued)

a. Cost-estimating individual projects and advising HFC on matters pertaining to the
overall project budget;

b. Regular meetings with HFC, City of Houston officials, and their contractors;
c. Assisting HFC in the preparation of contract documents, including review of draw-

ings and specifications;
d. Reviewing questions received from potential contractors during the bidding

process;
e. Providing recommendations on construction feasibility, availability of materials

and labor, time requirements for installation and construction, and factors related
to cost;
f. Overall project management, including facilitating all phases of projects concur-
rently, from predesign through construction completion;
g. Project schedule development, including adjustments based on the progress of
work and specific recommendations for prioritizing and accelerating critical path
items;
h. Identification of long-lead items to facilitate the earliest feasible date for project
completion;
i. Value engineering assistance and best construction practices recommendations;
j. Project worksheet and other pertinent report preparation, review, content recom-
mendations, and hazard mitigation proposals required for reimbursement by FEMA
and any other applicable agency;
k. Collecting and organizing contracts, reports, logs, and other supporting documen-
tation necessary for project worksheets;
l. Managing third-party architectural and engineering contracts entered into by HFC
and meeting with design professionals;
m. Reviewing, reconciling and validating payment applications and invoices from
third-party construction contractors, architects and engineers;
n. Ensuring compliance with prevailing wage and hour requirements;
o. Close-out document review, including punch-list documentation; and
p. Other tasks and matters reasonably relating to the foregoing.

III. Term/Schedule Information: The duration of services to be performed by the pro-
poser selected is eight calendar months, subject to extension under the Project Manage-
ment Services Agreement.

IV. Proposal Format: Proposers are asked to include all of the following information in
their proposal:

a. Transmittal Letter: Briefly summarizing the proposer’s understanding of the work to
be completed signed by a person authorized to make representations on behalf of the
firm, including a direct phone number and email address. Proposers must make a spe-
cific, unambiguous statement accepting and agreeing to comply, if selected, with the
Material Contract Terms and Conditions. Proposers may identify any objections within
or immediately following the letter; provided, however, that proposals including mate-
rial exceptions are deemed non-responsive and will be rejected without consideration.

(continued)

Project Procurement Management 523

Table 12-1  Example RFP for project management services (continued)

b. Project Team: A seasoned project management team is an essential element of a
successful proposal. Please identify the essential personnel who would be assigned
to work with HFC and provide a summary of their qualifications and experience.

c. Experience: The proposer selected must have substantial experience in disaster-
recovery projects and demonstrable ability to manage a broad multi-disciplinary
construction and professional services contracts simultaneously. Please discuss (no
more than) three completed project management contracts completed by members
of the Project Team that are comparable, in scope and complexity, to the require-
ments of this solicitation. Provide references for each project.

d. Pricing: Proposers must include a single lump-sum fee based on the information
provided in the RFP, including the Material Contract Terms and Conditions and
assuming an eight-month term. Additionally, proposers must provide a written and
formulaic explanation of how the proposer calculated the lump-sum fee.

e. Diversity Commitment: Proposers should indicate how they intend to meet the
30 percent Diversity Goal for this solicitation. Proposers are asked to identify any
probable MWBE and HUB subcontractors or consultants.

Proposals should be organized, clear and concise. Proposers are asked to avoid
excessive graphics, title pages, or other information other than requested in this
Proposal Format section.

V. Evaluation: HFC will review and rank every proposal received in response to this RFP
based on the following weighted criteria: Transmittal Letter (15 percent); Project Team
(25 percent); Experience (25 percent); Pricing (25 percent); and Diversity (10 percent).

HFC reserves the right to select or reject all or part of any proposal, waive minor technicali-
ties, and select proposals in the manner and to the extent that they serve the best interests
of HFC. This RFP does not commit HFC to award a contract, issue a purchase order, or
to pay any costs incurred in the preparation of a proposal in response to this RFP. HFC
reserves the right to request oral interviews, proposal clarifications/additional information,
and/or best-and-final offers from some or all proposers prior to making a final selection.

Source: Houston First Corporation (2017).

Table 12-2  Letters of clarification information from RFP

Proposal Format: Subsection “d” of the “Proposal Format” section of the RFP, titled
“Pricing” is hereby deleted in its entirety and replaced with the following provision:

• Proposers must provide a current hourly rate service schedule for their project
team, including all personnel expected to provide services for HFC.

• Salaries and other employment costs of the project manager’s personnel, over-
head, other general/administrative costs, and the cost of insurance required to
be maintained must be included in such rates.

• The proposer selected will be reimbursed for the actual amount of reasonable
expenses incurred in the performance of contractual services for HFC to the
extent such expenses are approved in advance and in writing by HFC.

(continued)

524 Chapter 12

Table 12-2  Letters of clarification information from RFP (continued)

• Subcontracts for estimators, schedulers, payment-application reviewers, docu-
ment controllers and, subject to mutual agreement, other project consultants
also constitute at-cost reimbursable expenses, provided that the selection pro-
cess is approved in advance by HFC.

• HFC intends to negotiate a not-to-exceed amount with the top-ranked
proposer(s) for the eight-month period based on the foregoing. The finalist rep-
resenting the best value to HFC will be selected.

Pre-Proposal Conference: The “Pre-Proposal Conference” section of the RFP is hereby
deleted in its entirety and replaced with the following provision:

• A tour of Wortham Theater Center and the Theater District Parking Garages will
be held for the benefit of all prospective proposers at 9:00 a.m. on October 16,
2017.

• A pre-proposal conference will be held on October 16, 2017 at approximately
11:00 a.m. All potential proposers are urged to be present.

Project Questions and Answers

1. How many Project Team members does HFC expect proposers to provide?
Answer: HFC envisions a minimal, experienced Project Team equating to two full-
time positions for the duration of the eight-month term.
2. Will HFC provide office space for the Project Team?
Answer: Office space will not be provided; HFC will, however, make meeting space at
one or more of its operable facilities as needed. Note that jobsite trailers are not nec-
essary to perform services under this RFP.
3. How many meetings are needed with HFC, City of Houston officials, and their

contractors?
Answer: Regular, in-person meetings are an essential element of the project manage-
ment services required by HFC. HFC anticipates 5–8 meetings per week.
4. Is the project manager expected to be on-site at all times while construction activi-

ties are ongoing?
Answer: No.
5. Does HFC require use of any specific project-management software programs?
Answer: No

Source Selection Criteria

It is very important for organizations to prepare some form of evaluation criteria for source
selection, preferably before they issue a formal RFP. Organizations use criteria to rate or
score proposals, and they often assign a weight to each criterion to indicate its importance.
Some examples of criteria and weights include the technical approach (30 percent weight),
management approach (30 percent weight), past performance (20 percent weight), and

Project Procurement Management 525

price (20 percent weight). Notice the criteria provided in Table 12-1: Transmittal Letter
(15 percent); Project Team (25 percent); Experience (25 percent); Pricing (25 percent);
and Diversity (10 percent). The criteria should be specific and objective. For example, if
the buyer wants the supplier’s project manager to be a certified Project Management Pro-
fessional (PMP®), the procurement documents should state that requirement clearly and
follow it during the award process. Losing bidders may pursue legal recourse if the buyer
does not follow a fair and consistent evaluation process.

Organizations should heed the saying, “Let the buyer beware.” It is critical to evaluate
proposals based on more than the professionalism of the paperwork submitted. A key factor
in evaluating bids, particularly for projects involving IT, is the past performance record of
the bidder. The RFP should require bidders to list other similar projects they have worked
on and provide customer references for those projects. Reviewing performance records and
references reduces the risk of selecting a supplier with a poor track record. Suppliers should
also demonstrate their understanding of the buyer’s need, their technical and financial capa-
bilities, their management approach to the project, and their price for delivering the desired
goods and services. It is also crucial to write the contract to protect the buyer’s interests.

Some IT projects also require potential sellers to deliver a technical presentation as
part of their proposal. The proposed project manager should lead the potential seller’s
presentation team. When the outside project manager leads the proposal presentation, the
organization can build a relationship with the potential seller from the beginning. Visits to
contractor sites can also help the buyer get a better feeling for the seller’s capabilities and
management style.

Conducting Procurements

After planning for procurement management, the next process involves deciding whom to
ask to do the work, sending appropriate documentation to potential sellers, obtaining pro-
posals or bids, selecting a seller, and awarding a contract. Prospective sellers do some of
the work in this process, normally at no cost to the buyer or project. The buying organiza-
tion is responsible for advertising the work, and for large procurements, the organization
often holds some sort of bidders’ conference to answer questions about the job. Two of the
main outputs of this process are a selected seller and agreements.

Organizations can advertise to procure outside goods and services in many different
ways. Sometimes a specific supplier might be the top choice for the buyer. In this case,
the buyer gives procurement information just to that company. If the preferred supplier
responds favorably, the organizations proceed to work together. Many organizations have
formed good working relationships with certain suppliers.

In many cases, however, more than one supplier might be qualified to provide the
goods and services. Providing information to multiple sources and receiving bids from
them often takes advantage of the competitive business environment. Offshore outsourc-
ing, as you learned earlier, has increased tremendously as organizations find suitable sell-
ers around the globe. As a result of pursuing a competitive bidding strategy, the buyer can
receive better goods and services than expected at a lower price.

A bidders’ conference, also called a supplier conference or pre-bid conference, is a
meeting with prospective sellers prior to preparation of their proposals or bids. These