1813_08

8/11/2019 1813_08

1/7

8/11/2019 1813_08

2/7

84 UNIT 8: Including Risks in Cost Estimations

The traditional method of handling cost uncertainty has been to estimatecosts with the assumption that everything will go according to plan, thenadd 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 gowrong, and its cost if it does. This can be seen by equating expected costsin Eqs. (8-2) and (8-3) and setting estimate1in (8-2) equal to estimated costin (8-3). The resulting equation can be rearranged to solve for F, as shownin Eq. (8-4).

(8-4)

If p1equals unity (nothing can go wrong) or estimate1equals estimate2(going wrong won't cost anything), no contingency factor is needed, so Fequals zero. An unlikely but expensive mishap (p1= 0.9, estimate2= 2 estimate1) will have the same effect on F as a more probable but lower costproblem with = 0.5 and estimate2= 1.2 estimate1. Contingency factors

are a defensible method, especially if they are backed by historical data onsimilar projects. This unit assumes that it is better to estimate costs andprobabilities separately. Separate estimates have several advantages overcontingency 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 thatbatches can be processed automatically. Equipment will include severalPLCs and PCs. The project plan includes an estimate of $300,000 for equip-

ment costs and $200,000 for installation. Application software, includingengineering, 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 a40% chance that interface problems will cause a 50% time and moneyoverrun for application software. The first two columns of Table 8-1 showcost cash flows for the two scenarios. Eq. (8-2) can be used to produce acombined 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 canthen be calculated from Eq. (8-3) as $1,000,000 1.1 = $1,100,000. This

F 1 p1( )estimate2estimate1--------------------------- 1

=

8/11/2019 1813_08

3/7

UNIT 8: Including Risks in Cost Estimations 85

value agrees with the total of column three of Table 8-1, but nothing in thecontingency factor calculation reflects the possibility that the project maytake longer to implement, thereby delaying benefits.

8-2. Cost Risk Factors

Two major causes of cost risk are novelty and complexity. Simple, alreadyproven control applications are easy to implement and easy to estimate.Risk comes from doing something new and/or difficult. Novelty mayassume several guises. The instrumentation or control system may benewly developed. A common maxim warns the user to beware of any-thing with a single-digit serial number. The software may be newlydeveloped or untried on the type of computer that the system requires.

Individual hardware and software items may be proven, but the particularcombination to be used on the project (e.g., brand X PLC, brand Y work-station, brand Z operator interface software) may never have been usedtogether.

A commonly overlooked aspect of novelty risk is the use of hardware orsoftware, however field-proven, that no one on the project has used

before. It is difficult to estimate the time that an inexperienced engineermay have to spend in learning the pitfalls of an unfamiliar system.

Complexity was discussed in Unit 5. Complex systems, in which manyindependent entities must communicate, are prone to unforeseen prob-lems. Implementation cost estimation is difficult.

Another major source of risk is underdesign. An underdesigned systemmust operate at its performance limit to achieve its objective (pushing theenvelope 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 orcontrol algorithms that require unusual measurement precision. A systemdesigned 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

8/11/2019 1813_08

4/7


bly language for some applications. Hardware cost savings will almostcertainly 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 toestimate correctly. For the same reasons, it is also the most likely sourceof cost overruns. Table 8-2 is a list of key questions that define applicationsoftware 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. Applicationsoftware cost for a project with two or more no answers is difficult toestimate. The project may be fortunate and avoid major problems, but it is

likely that at least one problem will increase cost significantly. A projectfor which all four questions are answered no will almost certainlyencounter major problems.

8-4. Assigning Probabilities

In some cases, one or two likely events will have a significant effect onproject cost. Probabilities can be assigned individually to these events andappropriately combined to produce probabilities for all likely scenarios.

Example 8-2:In Example 8-1, an interface problem with 40% probabilitywas 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 thatthis feature will not perform as expected. If so, PLCs will have to bereplaced with more expensive models at a total cost of $100,000. If theproblem exists, it will be seen quickly, so no effect on project schedule isexpected. There are now four possible scenarios, which can be categorizedas (1) no problem, (2) interface problem, (3) PLC problem, and (4) bothproblems. 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, orthe occurrence of one event may change the probability of another. Forinstance, 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

8/11/2019 1813_08

5/7


dent. The probability of scenario (3) is decreased and the probability ofscenario (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 islikely to go wrong with application software, but no specific event can betargeted. In this situation, a useful method is formulation of best-caseand worst-case scenarios, with equal probabilities. Quotation marks areused since these scenarios are the best and worst reasonably likely casesrather than the absolute best and worst cases that can be imagined. Thereis a natural human tendency to avoid extremes. One risk analysis study ata major engineering company (Ref. 1) found that when experts were askedfor maximum and minimum cost estimates, their estimates were plus orminus 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 availableto work on the project have no experience with it. The software prepara-tion effort is estimated at 12 man-months, using persons familiar with theequipment. A best-case estimate is that the software engineers, after onemonth of training on the new system, will be as competent as experiencedpersonnel and will complete the job after 12 more man-months. A worst-case estimate is that even after training, the engineers will only graduallyprogress toward full competence and will on the average accomplish onlyhalf as much as experienced personnel. Table 8-4 summarizes the scenar-ios. Note that even the best-case scenario assumes that because of trainingtime, 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 ProbabilityEffort

(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

8/11/2019 1813_08

6/7


will eventually reach full competence. One can imagine better and worseoutcomes but perhaps not likely ones.

8-5. Estimating Expected Cost

Each likely scenario has a cost that is expressed as a series of negative cashflows. These costs must be estimated before they can be combined to forman 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 beused 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 costsplus 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 combinedinto an expected cost, as shown in Eq. (8-1). Expected cost is the sum of thecosts of likely scenarios, each weighted by its respective probability. Indi-vidual scenario costs should not be discarded once expected cost has beenestimated. They will still be needed for project evaluation, as discussed inUnit 10.

Reference

1. Deshmukh, S. S., 1979. Risk Analysis,Modern Cost Engineering:Methods and Data, pp. 220-223. New York: Chemical EngineeringMcGraw-Hill.

Exercises

8-1. A novel sensor, costing $10,000, is to be installed on each of 10 productionlines. Installation and calibration will cost $5,500 per sensor, of which

$500 is for calibration. There is a 20% probability that the sensors will notstand up to the environment. If so, all will be replaced by proven sensorsthat cost $20,000 each. What are the likely cost scenarios? Assume thefollowing:

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?

8/11/2019 1813_08

7/7


8-3. What will the scenarios be for the project described in Exercise 8-1 if onlytwo sensors are installed originally? After evaluation, either 8 more of theoriginal sensors or 10 replacement sensors will be installed.

8-4. The lowest bidder on application software for a large system is a small, newsystems integrator, who bids $1,000,000. The large corporation supplyingthe hardware and system software guarantees that even if the integratorfails, the job will be completed for the original bid price. Does this eliminateall risk for this part of the project?

8-5. A company has a blending control system operating in plant A. The systemhas 50% idle time. Plant B, which is similar but makes twice as manyblends, wants a similar system. The computer hardware vendor suggeststhat 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 at50%. What are the risks?

8-6. In Section 8-4, it was suggested that in Example 8-2, use of replacementPLCs might increase the likelihood of an interface problem to 70%. If thissuggestion is true, how are scenario probabilities changed?

8-7. In Example 8-2, if it is certain (probability = 1.0) that the use ofreplacement PLCs will cause interface problems, what scenarios must beconsidered? What are their probabilities?

1813_08

Documents