83

UNIT 8:
Including Risks in Cost Estimations
This is the start of Part 2, which expands the estimation techniques cov-
ered in Part 1 to include risks and uncertainty. This unit shows how to
include risks when estimating costs.
Learning Objectives When you have completed this unit you should:
A. Know the major cost risk factors.
B. Be able to formulate likely scenarios.
C. Be able to assign probabilities to likely scenarios.
D. Know how to compute expected cost including risk effects.
8-1. How Much Is It Really Likely to Cost?
In a predictable, well-ordered world, cost estimation would simply follow
the procedure laid out in Unit 5. The categories that must be estimated
would be identified and costs assigned to each of them. Category costs
would be summed to produce an overall cost estimate, which would be
part of the overall cash flow. Unfortunately, the world is seldom as pre-
dictable or well-ordered as might be desired. Projects often deviate widely
from plan: hardware may not work as advertised; software may run into
unexpected difficulties. It is more likely that several possible scenarios
must be considered. Each scenario will have a set of cost cash flows and a
probability associated with it. A single expected cost can be produced by
combining scenario costs, each weighted according to its probability.
(8-1)
where estimate
i
is the estimated cost of ith scenario and p
i
is the probabil-
ity of ith scenario.
For two scenarios, this can be simplified to Eq. (8-2).
expected cost = estimate
1
p
1
+ estimate
2
(1 p
1
) (8-2)
expected cost estimate
i
p
i
( )
i 1 =
n

=
Friedmann05.book Page 83 Tuesday, June 13, 2006 11:31 AM
84 UNIT 8: Including Risks in Cost Estimations
The traditional method of handling cost uncertainty has been to estimate
costs with the assumption that everything will go according to plan, then
add a contingency factor (F) to cover risks, as shown in Eq. (8-3).
expected cost = estimated cost (1 + F) (8-3)
The size of the contingency factor is usually based on the type of project,
the effort put into estimation, and the track record of the estimator. Con-
tingency factors combine two effects: the likelihood that something will go
wrong, and its cost if it does. This can be seen by equating expected costs
in Eqs. (8-2) and (8-3) and setting estimate
1
in (8-2) equal to estimated cost
in (8-3). The resulting equation can be rearranged to solve for F, as shown
in Eq. (8-4).
(8-4)
If p
1
equals unity (nothing can go wrong) or estimate
1
equals estimate
2

(going wrong won't cost anything), no contingency factor is needed, so F
equals zero. An unlikely but expensive mishap (p
1
= 0.9, estimate
2
= 2
estimate
1
) will have the same effect on F as a more probable but lower cost
problem with = 0.5 and estimate
2
= 1.2 estimate
1
. Contingency factors
are a defensible method, especially if they are backed by historical data on
similar projects. This unit assumes that it is better to estimate costs and
probabilities separately. Separate estimates have several advantages over
contingency factors. A major one is preservation of the time dimension.
Problems often have more effect on project timing than on cost. Also,
recalculation after a change in circumstances is much easier.
Example 8.1: Controls for a food processing plant are to be updated so that
batches can be processed automatically. Equipment will include several
PLCs and PCs. The project plan includes an estimate of $300,000 for equip-
ment costs and $200,000 for installation. Application software, including
engineering, is estimated to cost $500,000 if there are no interface prob-
lems. The project is expected to be completed in one year.
The likelihood of meeting the project plan is estimated at 60%. There is a
40% chance that interface problems will cause a 50% time and money
overrun for application software. The first two columns of Table 8-1 show
cost cash flows for the two scenarios. Eq. (8-2) can be used to produce a
combined estimate of expected cash flows, which is shown in the third col-
umn of Table 8-1. The expected cost can also be expressed in terms of esti-
mated cost and a contingency factor. From Eq. (8-4), F can be calculated as
(1 0.6) (1,250,000/1,000,000 1) = 0.4 0.25 = 0.1. Expected cost can
then be calculated from Eq. (8-3) as $1,000,000 1.1 = $1,100,000. This
F 1 p
1
( )
estimate
2
estimate
1
--------------------------- 1



=
Friedmann05.book Page 84 Tuesday, June 13, 2006 11:31 AM
UNIT 8: Including Risks in Cost Estimations 85
value agrees with the total of column three of Table 8-1, but nothing in the
contingency factor calculation reflects the possibility that the project may
take longer to implement, thereby delaying benefits.
8-2. Cost Risk Factors
Two major causes of cost risk are novelty and complexity. Simple, already
proven control applications are easy to implement and easy to estimate.
Risk comes from doing something new and/or difficult. Novelty may
assume several guises. The instrumentation or control system may be
newly developed. A common maxim warns the user to beware of any-
thing with a single-digit serial number. The software may be newly
developed or untried on the type of computer that the system requires.
Individual hardware and software items may be proven, but the particular
combination to be used on the project (e.g., brand X PLC, brand Y work-
station, brand Z operator interface software) may never have been used
together.
A commonly overlooked aspect of novelty risk is the use of hardware or
software, however field-proven, that no one on the project has used
before. It is difficult to estimate the time that an inexperienced engineer
may have to spend in learning the pitfalls of an unfamiliar system.
Complexity was discussed in Unit 5. Complex systems, in which many
independent entities must communicate, are prone to unforeseen prob-
lems. Implementation cost estimation is difficult.
Another major source of risk is underdesign. An underdesigned system
must operate at its performance limit to achieve its objective (pushing the
envelope in aerospace jargon). This situation greatly increases risk in air-
planes and control systems. Process control examples might include inter-
connection lengths at the limit of communications system capability or
control algorithms that require unusual measurement precision. A system
designed to have little or no idle time is particularly dangerous. The soft-
ware engineer will be forced to optimize code and may have to use assem-
Cash Flows, $
Year Sc. A (p = 0.6) Sc. B (p = 0.4) Expected Cost
0 -300,000 -300,000 -300,000
1 -700,000 -700,000 -700,000
2 -250,000 -100,000
Table 8-1. Cost Cash Flows for Food Processing Control Upgrade
Friedmann05.book Page 85 Tuesday, June 13, 2006 11:31 AM
86 UNIT 8: Including Risks in Cost Estimations
bly language for some applications. Hardware cost savings will almost
certainly be exceeded by added software expenditures.
8-3. The Most Likely Source of Cost Overruns
In Unit 5, application software was described as the most difficult item to
estimate correctly. For the same reasons, it is also the most likely source
of cost overruns. Table 8-2 is a list of key questions that define application
software risk. If all the questions can be answered yes, application soft-
ware costs can be estimated with no more difficulty than other categories.
Each no answer is an indication of increased uncertainty. Application
software cost for a project with two or more no answers is difficult to
estimate. The project may be fortunate and avoid major problems, but it is
likely that at least one problem will increase cost significantly. A project
for which all four questions are answered no will almost certainly
encounter major problems.
8-4. Assigning Probabilities
In some cases, one or two likely events will have a significant effect on
project cost. Probabilities can be assigned individually to these events and
appropriately combined to produce probabilities for all likely scenarios.
Example 8-2: In Example 8-1, an interface problem with 40% probability
was anticipated. Suppose that in addition, the PLCs to be used include a
new and untried feature. It is estimated that there is a 30% probability that
this feature will not perform as expected. If so, PLCs will have to be
replaced with more expensive models at a total cost of $100,000. If the
problem exists, it will be seen quickly, so no effect on project schedule is
expected. There are now four possible scenarios, which can be categorized
as (1) no problem, (2) interface problem, (3) PLC problem, and (4) both
problems. The problems are independent, so probabilities are easy to cal-
culate. Scenario probabilities are shown in Table 8-3.
Events are often interlinked. Two events may share a common cause, or
the occurrence of one event may change the probability of another. For
instance, in Example 8-2, if the use of replacement PLCs increases the like-
lihood of an interface problem to 70%, the two problems are not indepen-
(a) Are all system components (hardware and software) field-proven?
(b) Are all communications between interconnected components field-proven?
(c) Are the software engineers familiar with the system?
(d) Does the system as originally designed have at least 40% idle time?
Table 8-2. Key Questions That Affect Software Costs
Friedmann05.book Page 86 Tuesday, June 13, 2006 11:31 AM
UNIT 8: Including Risks in Cost Estimations 87
dent. The probability of scenario (3) is decreased and the probability of
scenario (4) is increased.
Risk may be present but not associated with any particular event. For
example, the key questions in Table 8-2 may indicate that something is
likely to go wrong with application software, but no specific event can be
targeted. In this situation, a useful method is formulation of best-case
and worst-case scenarios, with equal probabilities. Quotation marks are
used since these scenarios are the best and worst reasonably likely cases
rather than the absolute best and worst cases that can be imagined. There
is a natural human tendency to avoid extremes. One risk analysis study at
a major engineering company (Ref. 1) found that when experts were asked
for maximum and minimum cost estimates, their estimates were plus or
minus one standard deviation from the most likely value.
Example 8-3: Instrumentation at an existing plant is to be replaced by a
DCS. The DCS is a field-proven type, but the software engineers available
to work on the project have no experience with it. The software prepara-
tion effort is estimated at 12 man-months, using persons familiar with the
equipment. A best-case estimate is that the software engineers, after one
month of training on the new system, will be as competent as experienced
personnel and will complete the job after 12 more man-months. A worst-
case estimate is that even after training, the engineers will only gradually
progress toward full competence and will on the average accomplish only
half as much as experienced personnel. Table 8-4 summarizes the scenar-
ios. Note that even the best-case scenario assumes that because of training
time, the job will be slightly longer and more expensive using inexperi-
enced engineers. Even the worst-case scenario assumes that the engineers
Scenario Probability
No Problems 0.42 = (1 0.4) (1 0.3)
Interface Problem 0.28 = 0.4 (1 0.3)
PLC Problem 0.18 = (1 0.4) 0.3
Both Problems 0.12 = 0.4 0.3
Table 8-3. Scenario Probabilities
Scenario Probability
Effort
(Man-Months)
Time
(Months)
Best Case 0.5 14 7
Worst Case 0.5 26 13
Table 8-4. Best-Case and Worst-Case Scenarios
Friedmann05.book Page 87 Tuesday, June 13, 2006 11:31 AM
88 UNIT 8: Including Risks in Cost Estimations
will eventually reach full competence. One can imagine better and worse
outcomes but perhaps not likely ones.
8-5. Estimating Expected Cost
Each likely scenario has a cost that is expressed as a series of negative cash
flows. These costs must be estimated before they can be combined to form
an expected cost. A good procedure is to start by estimating the lowest-
cost scenario. This is the best-case situation or the no problem alterna-
tive if scenarios are based on possible events. This estimate then can be
used as a base from which costs of more expensive scenarios can be esti-
mated. In Example 8-3, the worst-case costs are equal to the best-case costs
plus twelve man-months of software engineer effort.
Only likely outcomes with probabilities of at least 10% should be consid-
ered. Once individual costs have been estimated, they can be combined
into an expected cost, as shown in Eq. (8-1). Expected cost is the sum of the
costs of likely scenarios, each weighted by its respective probability. Indi-
vidual scenario costs should not be discarded once expected cost has been
estimated. They will still be needed for project evaluation, as discussed in
Unit 10.
Reference
1. Deshmukh, S. S., 1979. Risk Analysis, Modern Cost Engineering:
Methods and Data, pp. 220-223. New York: Chemical Engineering
McGraw-Hill.
Exercises
8-1. A novel sensor, costing $10,000, is to be installed on each of 10 production
lines. Installation and calibration will cost $5,500 per sensor, of which
$500 is for calibration. There is a 20% probability that the sensors will not
stand up to the environment. If so, all will be replaced by proven sensors
that cost $20,000 each. What are the likely cost scenarios? Assume the
following:
Installation and calibration of original sensors will take 3 months.
Evaluation of original sensors will take 10 months.
Replacement sensors are similar in size and use the same connections as
the original sensors.
8-2. What is the expected cost of the project described in Exercise 8-1? What is
the equivalent contingency factor?
Friedmann05.book Page 88 Tuesday, June 13, 2006 11:31 AM
UNIT 8: Including Risks in Cost Estimations 89
8-3. What will the scenarios be for the project described in Exercise 8-1 if only
two sensors are installed originally? After evaluation, either 8 more of the
original sensors or 10 replacement sensors will be installed.
8-4. The lowest bidder on application software for a large system is a small, new
systems integrator, who bids $1,000,000. The large corporation supplying
the hardware and system software guarantees that even if the integrator
fails, the job will be completed for the original bid price. Does this eliminate
all risk for this part of the project?
8-5. A company has a blending control system operating in plant A. The system
has 50% idle time. Plant B, which is similar but makes twice as many
blends, wants a similar system. The computer hardware vendor suggests
that if a new, faster computer is used, the software from plant A can be used
for plant B with only minor changes and system loading can be kept at
50%. What are the risks?
8-6. In Section 8-4, it was suggested that in Example 8-2, use of replacement
PLCs might increase the likelihood of an interface problem to 70%. If this
suggestion is true, how are scenario probabilities changed?
8-7. In Example 8-2, if it is certain (probability = 1.0) that the use of
replacement PLCs will cause interface problems, what scenarios must be
considered? What are their probabilities?
Friedmann05.book Page 89 Tuesday, June 13, 2006 11:31 AM