The top-down approach to budgeting is based on the collective judgments and experiences of top and middle managers concerning similar past projects. These managers estimate the overall project cost by estimating the costs of the major tasks, which estimates are then given to the next lower level of managers to split up among the tasks under their control, and so on, until all the work is budgeted.

The advantage of this approach is that overall budget costs can be estimated with fair accuracy, though individual elements may be in substantial error. Another advantage is that errors in funding small tasks need not be individually identified because the overall budget allows for such exceptions. Similarly, the good chance that some small but important task was overlooked does not usually cause a serious budgetary problem. The experience and judgment of top management are presumed to include all such elements in the overall estimate. In the next section, we will note that the assumptions on which these advantages are based are not always true.

In bottom-up budgeting, the WBS identifies the elemental tasks, whose resource requirements are estimated by those responsible for executing them (e.g., programmer-hours in a software project). This can result in much more accurate estimates, but it often does not do so for reasons we will soon discuss. The resources, such as labor and materials, are then converted to costs and aggregated to different levels of the project, eventually resulting in an overall direct cost for the project. The PM then adds, according to organizational policy, indirect costs such as general and administrative, a reserve for contingencies, and a profit figure to arrive at a final project budget.

Bottom-up budgets are usually more accurate in the detailed tasks, but risk the chance of overlooking some small but costly tasks. Such an approach, however, is common in organizations with a participative management philosophy and leads to better morale, greater acceptance of the resulting budget, and heightened commitment by the project team. It is also a good managerial training technique for aspiring project and general managers.

Unfortunately, true bottom-up budgeting is rare. Upper level managers are reluctant to let the workers develop the budget, fearing the natural tendency to overstate costs, and fearing complaints if the budget must later be reduced to meet organizational resource limitations. Moreover, the budget is upper management's primary tool for control of the project, and they are reluctant to let others set the control limits. Again, we will see that the budget is not a sufficient tool for controlling a project. Top-down budgeting allows the budget to be controlled by people who play little role in designing and doing the work required by the project. It should be obvious that this will cause problems— and it does.

We recommend that organizations employ both forms of developing budgets. They both have advantages, and the use of one does not preclude the use of the other. Making a single budget by combining the two depends on setting up a specific system to negotiate the differences. We discuss just such a system below. The only disadvantage of this approach is that it requires some extra time and trouble, a small price to pay for the advantages. A final warning is relevant. Any budgeting system will be useful only to the extent that all cost/revenue estimates are made with scrupulous honesty.

The task of building a budget is relatively straightforward but tedious. Each work element is evaluated for its resource requirements, and its costs are then determined. For example, suppose a certain task is expected to require 16 hours of labor at $10 per hour, and the required materials cost $235. In addition, the organization charges overhead for the use of utilities, indirect labor, and so forth at a rate of 50 percent of direct labor. Then, the total task cost will be

Equation 4.1. 

In some organizations, the PM adds the overhead charges to the budget. In others, the labor time and materials are just sent to the accounting department and they run the numbers, add the appropriate overhead, and total the costs. Although overhead was charged here against direct labor, more recent accounting practices such as activity-based costing may charge portions of the overhead against other cost drivers such as machine time, weight of raw materials, or total time to project completion.

Direct resource costs such as for materials and machinery needed solely for a particular project are usually charged to the project without an overhead add-on. If machinery from elsewhere in the organization is used, this may be charged to the project at a certain rate (e.g., $/hr) that will include depreciation charges, and then will be credited to the budget of the department owning and paying for the machine. On top of this, there is often a charge for GS&A (general, sales, and administrative) costs that includes upper management, staff functions, sales and marketing, plus any other costs not included in the overhead charge. GS&A may be charged as a percentage of direct costs, all direct and indirect costs, or on other bases including total time to completion.

Thus, the fully costed task will include direct costs for labor, machinery, and resources such as materials, plus overhead charges, and finally, GS&A charges. The full cost budget is then used by accounting to estimate the profit to be earned by the project. The wise PM, however, will also construct a budget of direct costs for his or her own use. This budget provides the information required to manage the project without being confounded with costs over which he or she has no control.

Note that the overhead and GS&A effect can result in a severe penalty when a project runs late, adding significant additional and possibly unexpected costs to the project. Again, we stress the importance of the PM thoroughly understanding the organization's accounting system, and especially how overhead and other such costs are charged to the project.

Of course, this process can also be reversed to the benefit of the PM by minimizing the use of drivers of high cost. Sometimes clients will even put clauses in contracts to foster such behavior. For example, when the state of Pennsylvania contracted for the construction of the Limerick nuclear power generating facility in the late 1980s, they included such an incentive fee provision in the contract. This provision stated that any savings that resulted from finishing the project early would be split between the state and the contractor. As a result, the contractor went to extra expense and trouble to make sure the project was completed early. The project came in 8 months ahead of its 49-month due date and the state and the contractor split the $400 million savings out of the total $3.2 billion budget.

In the previous chapter on planning, we described a process in which the PM plans Level 1 activities, setting a tentative budget and duration for each. Subordinates (and this term refers to anyone working on the project even though such individuals may not officially report to the PM and may be "above" the PM on the firm's organizational chart) then take responsibility for specifying the Level 2 activities required to produce the Level 1 task. As a part of the Level 2 specifications, tentative budgets and durations are noted for each Level 2 activity. The PM's initial budget and duration estimates are examples of top-down budgeting. The subordinate's estimates of the Level 2 task budgets and durations are bottom-up budgeting. As we promised, we now deal with combining the two budgets.

We will label the Level 1 task estimate of duration of the i^th task as t_t and the respective cost estimate as r_i the t standing for "time" and the r for "resources." In the meantime, the subordinate has estimated task costs and durations for each of the Level 2 tasks that comprise Level 1 task i We label the aggregate cost and duration of these Level 2 activities as r'_i and t'_t, respectively. It would be nice if r_i equaled r'_i, but the reality is rarely that neat. In general, r_i << r'_i (The same is true of the time estimates, t_i and t'_i.) There are three reasons why this happens. First, jobs always look easier, faster, and cheaper to the boss than to the person who has to do them (Gagnon and Mantel, 1987). Second, bosses are usually optimistic and never admit that details have been forgotten or that anything can or will go wrong. Third, subordinates are naturally pessimistic and want to build in protection for everything that might possibly go wrong.

It is important that we make an assumption for the following discussion. We assume that both boss and subordinate are reasonably honest. What follows is a win-win negotiation, and it will fail if either party is dishonest. (We feel it is critically important to remind readers that it is never smart to view the other party in a negotiation as either stupid or ignorant. Almost without fail, such thoughts are obvious to the other party and the possibility of a win-win solution is dead.) The first step in reducing the difference between the superior's and subordinate's estimates occurs when the worker explains the reality of the task to the boss, and r_i rises. Encouraged by the fact that the boss seems to understand some of the problems, the subordinate responds to the boss's request to remove some of the protective padding. The result is that r'_i falls.

The conversation now shifts to the technology involved in the subordinate's work and the two parties search for efficiencies in the Level 2 work plan. If they find some, the two estimates get closer still, or, possibly, the need for resources may even drop below either party's estimate.

To complete our discussion, let's assume that after all improvements have been made, r'_i is still somewhat higher than r_i. Should the boss accept the subordinate's cost estimate or insist that the subordinate accept the boss's estimate? To answer this question, we must recall the discussion of project life cycles from Chapter 1. We discussed two different common forms of life cycles and these are illustrated again, for convenience, in Figure 4-1. One curve is S-shaped and the other is J-shaped . As it happens, the shapes of these curves hold the key to our decision.

If the project life cycle is S-shaped, then with a somewhat reduced level of resources, a smaller than proportional cut will be made in the project's objectives or performance, likely not a big problem. If the project's life cycle is J-shaped, the impact of inadequate resources will be serious, a larger than proportional cut will be made in the project's performance. The same effect occurs during an "economy drive" when a senior manager decrees an across-the-board budget cut for all projects of, say, 5 or 10 percent. For a project with a J-shaped life cycle, the result is disaster. It is not necessary to know the actual shape of a project's life cycle with any precision. One needs merely to know the probable curvature (concave or convex to the baseline) of the last stage of the cycle for the project being considered.

Figure 4.1. Two project life cycles (cf. Figures 1-2 and 1-3).

The message here is that for projects with S-shaped life cycles, the top-down budgeting process is probably acceptable. For J-shaped life-cycle projects, it is dangerous for upper management not to accept the bottom-up budget estimates. At the very least, management should pay attention when the PM complains that the budget is insufficient to complete the project. An example of this problem is NASA's Space Shuttle Program, projected by NASA to cost $10-13 billion but cut by Congress to $5.2 billion. Fearing a cancellation of the entire program if they pointed out the overwhelming developmental problems they faced, NASA acquiesced to the inadequate budget. As a result, portions of the program fell three years behind schedule and had cost overruns of 60 percent. As the program moved into the operational flight stage, problems stemming from the inadequate budget surfaced in multiple areas, culminating in the Challenger explosion in January 1986.

Finally, in these days of increasing budget cuts and great stress on delivering project value, cuts to the organization's project portfolio must be made with care. Wheatly (2009) warns against the danger of focusing solely on ROI when making decisions about which projects will be kept and which will be terminated. We will have considerably more to say about this subject in Chapter 8.

Here and elsewhere, we have preached the importance of managers and workers who are willing to communicate with one another frequently and honestly when developing budgets and schedules for projects. Such communication is the exception, not the rule. The fact that only a small fraction of software development projects are completed even approximately on time and on budget is so well known as to be legend, as is the record of any number of high technology industries. Sometimes the cause is scope creep, but top-down budgeting and scheduling are also prime causes. Rather than deliver another sermon on the subject, we simply reprint Rule #25 from an excellent book by Jim McCarthy, Dynamics of Software Development (1995).

Traditional organizational budgets are typically activity oriented and based on historical data accumulated through an activity-based accounting system. Individual expenses are classified and assigned to basic budget lines such as phone, materials, fixed personnel types (salaried, exempt, etc.), or to production centers or processes. These lines are then aggregated and reported by organizational units such as departments or divisions.

Project budgets can also be presented as activity budgets, such as in Table 4-3 where one page of a six-page monthly budget report for a real estate management project is illustrated. When multiple projects draw resources from several different organizational units, the budget may be divided between these multiple units in some arbitrary fashion, thereby losing the ability to control project resources as well as the reporting of individual project expenditures against the budget.

This difficulty gave rise to program budgeting. illustrated in Table 4-4. Here the program-oriented project budget is divided by task and expected time of expenditure, thereby allowing aggregation across projects. Budget reports are shown both aggregated and disaggregated by "regular operations," and each of the projects has its own budget. For example, Table 4-3 would have a set of columns for regular operations as well as for each project.

The use of simple forms such as that in Figure 4-2 can be of considerable help to the PM in obtaining accurate estimates, not only of direct costs, but also when the resource is needed, how many are needed, who should be contacted, and if it will be available when needed. The information can be collected for each task on an individual form and then aggregated for the project as a whole.

Suppose a firm wins a contract to supply 25 units of a complex electronic device to a customer. Although the firm is competent to produce this device, it has never produced one as complex as this. Based on the firm's experience, it estimates that if it were to build many such devices it would take about four hours of direct labor per unit produced. With this estimate, and the wage and benefit rates the firm is paying, the PM can derive an estimate of the direct labor cost to complete the contract.

Unfortunately, the estimate will be in considerable error because the PM is underestimating the labor costs to produce the initial units that will take much longer than four hours each. Likewise, if the firm built a prototype of the device and recorded the direct labor hours, which may run as high as 10 hours for this device, this estimate applied to the contract of 25 units would give a result that is much too high.

In both cases, the reason for the error is the learning exhibited by humans when they repeat a task. In general, it has been found that unit performance improves by a fixed percent each time the total production quantity doubles. More specifically, each time the output doubles, the worker hours per unit decrease by a fixed percentage of their previous value. This percentage is called the learning rate, and typical values run between 70 and 95 percent. The higher values are for more mechanical tasks, while the lower, faster-learning values are for more mental tasks such as solving problems. A common rate in manufacturing is 80 percent. For example, if the device described in the earlier example required 10 hours to produce the first unit and this firm generally followed a typical 80 percent learning curve, then the second unit would require .80 × 10 = 8 hours, the fourth unit would require 6.4 hours, the eighth unit 5.12 hours, and so on. Of course, after a certain number of repetitions, say 100 or 200, the time per unit levels out and little further improvement occurs.

Figure 4.2. Form for gathering data on project resource needs.

Mathematically, this relationship we just described follows a negative exponential function. Using this function, the time required to produce the nth unit can be calculated as

T_n=T₁n^r

where T_n is the time required to complete the nth unit, T₁ is time required to complete the first unit, and r is the exponent of the learning curve and is calculated as the log(learning rate)/log(2). Tables are widely available for calculating the completion time of unit n and the cumulative time to produce units one through n for various learning rates; for example, see Shafer and Meredith (1998). The impact of learning can also be incorporated into spreadsheets developed to help prepare the budget for a project as is illustrated in the example at the end of this section.

The use of learning curves in project management has increased greatly in recent years. For instance, methods have been developed to approximate composite learning curves for entire projects (Amor and Teplitz, 1998), for approximating total costs from the unit learning curve (Camm, Evans, and Womer, 1987), and for including learning curve effects in critical resource diagramming (Badiru, 1995). The conclusion is that the effects of learning, even in "one-time" projects, should not be ignored. If costs are underestimated, the result will be an unprofitable project and senior management will be unhappy. If costs are overestimated, the bid will be lost to a savvier firm and senior management will be unhappy.

In Chapter 3, we noted that people do not seem to learn by experience, no matter how much they urge others to do so. PMs and others involved with projects spend much time estimating—activity costs and durations, among many other things. There are two types of error in those estimates. First, there is random error. Errors are random when there is a roughly equal chance that estimates are above or below the true value of a variable, and the average size of the error is approximately equal for over and under estimates. (Naturally, we try to devise ways of estimating that minimize the size of these random errors.) If either of the above is not true for an estimator—either the chance of over or under estimates are not about equal or the size of over or under estimates are not approximately equal—the estimates are said to be biased. Random errors cancel out, which means that if we add them up the sum will approach zero. Errors caused by bias do not cancel out. They are systematic errors.

Calculation of a number called the tracking signal can reveal if there is systematic bias in cost and other estimates and whether the bias is positive or negative. Knowing this can then be quite helpful to a PM in making future estimates or on the critically important task of judging the quality of estimates made by others. Consider the spreadsheet data in Figure 4-3 where estimated and actual values for some factor are listed in the order they were made, indicated for ease of reference by "period." In order to compare estimates of different resources measured in units and of different magnitudes, we will derive a tracking signal based on the ratio of actual to estimated values rather than the usual difference between the two.

Figure 4.3. Excel® template for finding bias in estimates.

To calculate the first period ratio in Figure 4-3, for example, we would take the ratio 163/155 = 1.052. This means that the actual was 5.2 percent higher than the estimate, a forecast that was low. In column D, we list these errors for each of the periods and then cumulate them at the bottom of the spreadsheet. Note that in columns D and E we subtract 1 from the ratio. This centers the data around zero rather than 1.0, which makes some ratios positive, indicating an actual greater than the forecast, and other ratios negative, indicating an actual less than the forecast. If the cumulative percent error at the bottom of the spreadsheet is positive, which it is in this case, it means that the actuals are usually greater than the estimates. The forecaster underestimates if the ratio is positive and overestimates if it is negative. The larger the percent error, the greater the forecaster's bias, systematic under- or overestimation.

Column E simply shows the absolute value of column D. Column F is the "mean absolute ratio," abbreviated MAR, which is the running average of the values in column E up to that period. (Check the formulas in the spreadsheet of Figure 4-3.) The tracking signal listed in column G is the ratio of the running sum of the values in column D divided by the MAR for that period. If the estimates are unbiased, the running sum of ratios in column D will be about zero, and dividing this by the MAR will give a very small tracking signal, possibly zero. On the other hand, if there is considerable bias in the estimates, either positive or negative, the running sum of the ratios in column D will grow quite large. Then, when divided by the mean absolute ratio this will show whether the tracking signal is > 1 or < 1, and therefore greater than the variability in the estimates or not. If the bias is large, resulting in large positive or negative ratios, the resulting tracking signal will be correspondingly positive or negative.

It should be noted that it is not simply the bias that is of interest to the PM, although bias is very important. The MAR is also important because this indicates the variability of the estimates compared with the resulting actual values. With experience, the MAR should decrease over time though it will never reach zero. We strive to find a forecasting technique that minimizes both the bias and the MAR. By observing her own errors, the PM can learn to make unbiased estimates. When meeting with her subordinates in order to coach them on improving their estimates, it is important to recognize that most overestimates of duration or resource requirements are the result of an attempt by the subordinate to make "safe" estimates, and underestimates result from overoptimism. If subordinates overcorrect, the PM should avoid sharp criticism. Reasonable accuracy is the goal, but the uncertainty surrounding all projects does not allow random estimate errors to vanish.

Studies consistently show that between 60 and 85 percent of projects fail to meet their time, cost, and/or performance objectives. The record for information system (IS) projects is particularly poor, it seems. For example, there are at least 45 estimating models available for IS projects but few IS managers use any of them (Lawrence, 1994; Martin, 1994). While the variety of problems that can plague project cost estimates seems to be unlimited, there are some that occur with high frequency; we will discuss each of these in turn.

Changes in resource prices, for example, are a common problem. The most common managerial approach to this problem is to increase all cost estimates by some fixed percentage. A better approach, however, is to identify each input that has a significant impact on the costs and to estimate the rate of price change for each one. The Bureau of Labor Statistics (BLS) in the U.S. Department of Commerce publishes price data and "inflators" (or "deflators") for a wide range of commodities, machinery, equipment, and personnel specialities. (For more information on the BLS, visit http://stats.bls.gov or www.bls.gov.)

Another problem is overlooking the need to factor into the estimated costs an adequate allowance for waste and spoilage. Again, the best approach is to determine the individual rates of waste and spoilage for each task rather than to use some fixed percentage.

A similar problem is not adding an allowance for increased personnel costs due to loss and replacement of skilled project team members. Not only will new members go through a learning period, which increases the time and cost of the relevant tasks, but professional salaries usually increase faster than the general average. Thus, it may cost substantially more to replace a team member with a newcomer who has about the same level of experience.

Then there is also the Brooks's "mythical man-month" effect^[10] which was discovered in the IS field but applies just as well in projects. As workers are hired, either for additional capacity or to replace those who leave, they require training in the project environment before they become productive. The training is, of course, informal on-t he-job training conducted by their coworkers who must take time from their own project tasks, thus resulting in ever more reduced capacity as more workers are hired.

And there is the behavioral possibility that, in the excitement to get a project approved, or to win a bid, or perhaps even due to pressure from upper management, the project cost estimator gives a more "optimistic" picture than reality warrants. Inevitably, the estimate understates the cost. This is a clear violation of the PMI's Code of Ethics. It is also stupid. When the project is finally executed, the actual costs result in a project that misses its profit goals, or worse, fails to make a profit at all—hardly a welcome entry on the estimator's résumé.

Even organizational climate factors influence cost estimates. If the penalty for overestimating costs is much more severe than underestimating, almost all costs will be underestimated, and vice versa. A major manufacturer of airplane landing gear parts wondered why the firm was no longer successful, over several years, in winning competitive bids. An investigation was conducted and revealed that, three years earlier, the firm was late on a major delivery to an important customer and paid a huge penalty as well as being threatened with the loss of future business. The reason the firm was late was because an insufficient number of expensive, hard to obtain parts was purchased for the project and more could not be obtained without a long delay. The purchasing manager was demoted and replaced by his assistant. The assistant's solution to this problem was to include a 10 percent allowance for additional, hard to obtain parts in every cost proposal. This resulted in every proposal from the firm being significantly higher than their competitors' proposals in this narrow margin business.

There is also a probabilistic element in most projects. For example, projects such as writing software require that every element work 100 percent correctly for the final product to perform to specifications. In programming software, if there are 1000 lines of code and each line has a .999 probability of being accurate, the likelihood of the final program working is only about 37 percent!

Sometimes, there is plain bad luck. What is indestructible, breaks. What is impenetrable, leaks. What is certified, guaranteed, and warranteed, fails. The wise PM includes allowances for "unexpected contingencies."

There are many ways of estimating project costs; we suggest trying all of them and then using those that "work best" for your situation. The PM should take into consideration as many known influences as can be predicted, and those that cannot be predicted must then simply be "allowed for."

Finally, a serious source of inaccurate estimates of time and cost is the all too common practice of some managers arbitrarily to cut carefully prepared time and cost estimates. Managers rationalize their actions by such statements as "I know they have built a lot of slop in those estimates," or "I want to give them a more challenging target to shoot at." This is not effective management. It is not even good common sense. (Reread the excerpt from McCarthy, 1995 appearing above.) Cost and time estimates should be made by the people who designed the work and are responsible for doing it. As we argued earlier in this chapter, the PM and the team members may negotiate different estimates of resources needs and task durations, but managerially dictated arbitrary cuts in budgets and schedules almost always lead to projects that are late and over budget. We will say more about this later.

Boston's Big Dig highway/tunnel project is one of the largest, most complex, and technologically challenging highway projects in U.S. history. The "Big Dig,"originally expected to cost less than $3 billion, was declared complete after two decades and $14.6 billion for planning and construction, almost a 500 percent cost overrun (Abrams, 2003 and PMI, August 2004). With an estimated benefit of $500 million per year in reduced congestion, pollution, accidents, fuel costs, and lateness, the project has an undiscounted payback of almost 30 years. This project was clearly one that offered little value to the city if it wasn't completed, and so it continued far past what planners thought was a worthwhile investment, primarily because the federal government was paying 85 percent of its cost. One clear lesson from the project has been that unless the state and local governments are required to pay at least half the cost of these mega-projects, there won't be serious local deliberation of their pros and cons. The overrun is attributed to two major factors: (1) underestimates of the initial project scope, typical of government projects; and (2) lack of control, particularly costs, including conflicts of interest between the public and private sectors.

Perceptually, the PM sees the uncertainty of the budget like the shaded portion of Figure 4-4, where the actual project costs may be either higher or lower than the estimates the PM has derived. As we will describe later, however, it seems that more things can go wrong in a project and drive up the cost than can go right to keep down the cost. As the project unfolds, the cost uncertainty decreases as the project moves toward completion. Figures 4-5 (a), (b), and (c) illustrate this. An estimate at the beginning of the project as in Figure 4-4 is shown as the t₀ estimate in Figure 4-5(a). As work on the project progresses, the uncertainty decreases as the project moves toward completion. At time t₁ the cost to date is known and another estimate is made of the cost to complete the project, Figure 4-5(b). This is repeated at t₂, Figure 4-5(c). Each estimate, of course, begins at the actual cost to date and estimates only the remaining cost to completion. The further the project progresses, the less the uncertainty in the final project cost. It is common in project management to make new forecasts about project completion time and cost at fixed points in the project life cycle, or at special milestones.

Figure 4.4. Estimate of project cost: estimate made at project start.

The reasons for cost uncertainty in the project are many: prices may escalate, different resources may be required, the project may take a different amount of time than we expected, thereby impacting overhead and indirect costs, and on and on. Earlier, we discussed ways to improve cost estimates, to anticipate such uncertainty, but change is a fact of life, including life on the project, and change invariably alters our previous budget estimates.

Three Causes for Change

There are three basic causes for change in projects and their budgets and/or schedules. Some changes are due to errors the cost estimator made about how to achieve the tasks identified in the project plan. Such changes are due to technological uncertainty: a building's foundation must be reinforced due to a fault in the ground that wasn't identified beforehand; a new innovation allows a project task to be completed easier than was anticipated, and so on.

Other changes result because the project team or client learns more about the nature of the scope of the project or the setting in which it is to be used. This derives from an increase in the team's or client's knowledge or sophistication about the project deliverables. The medical team plans to use a device in the field as well as in the hospital. The chemists find another application of the granulated bed process if it is altered to include additional minerals.

The third source of change is the mandate: A new law is passed, a trade association sets a new standard, a governmental regulatory agency adopts a new policy. These changes alter the previous "rules of conduct" under which the project had been operating, usually to the detriment of the budget.

Figure 4.5. Estimates of project cost: estimates made at time t₀, t₁, t₂.

The field of risk management has grown considerably over the last decade. The Project Management Institute's PMBOK (2008) devotes Chapter 11 to this topic. In general, risk management includes three areas: (1) risk identification, (2) risk analysis, and (3) response to risk. The process of accomplishing these three tasks is broken down into six subprocesses:

Alexander Jones was an experienced project manager of a small machine shop. He had always had complete authority when working with the clients on specifications of the projects as well as when working with the project team on the schedule. His boss, however, did not feel comfortable letting Alex determine project budgets. The boss always did that himself.

A client approached Alex about designing a piece of surgical equipment. Alex was excited about this project because his usual job was to design and make parts of factory equipment. He was delighted to have a chance to do something that might directly affect humankind. Alex knew what the surgical tool was intended to do and had figured out what had to be done to design and manufacture it. He had even estimated the labor-hour requirement. He wanted to do all the planning discussions with the client, including discussions on the budget.

Stealth Electronics manufactures secret electronic weapon systems. They have just engineered a new system. They bid for and won a contract with DARPA (Defense Advanced Research Projects Agency). Stealth Electronics negotiated a cost plus contract for development of the prototype. The prototype project was approximately on time and on budget. They are about to submit a bid to produce the first 25 electronic weapon systems. The production contract will be a fixed fee. The CFO of Stealth Electronics has examined the costs associated with building the prototype and thinks the proposed bid for production of the first 25 systems is significantly too low.

Justin Jordan has been named Project Manager of the General Sensor Company's new sensor manufacturing process project. Sensors are extremely price sensitive. General has done a great deal of quantitative work to be able to accurately forecast changes in sales volume relative to changes in pricing.

The company president, Guy General, has faith in the sensitivity model that the company uses. He insists that all projects affecting the manufacturing costs of sensors be run against the sensitivity model to generate data to calculate the return on investment. The net result is that project managers, like Justin, are under a great deal of pressure to submit realistic budgets so go/no-go project decisions can be made quickly. Guy has canceled several projects that appeared marginal during their feasibility stages and recently fired a project manager for overestimating project costs on a new model sensor. The project was killed early in the design stages, and six months later a competitor introduced a similar sensor that proved to be highly successful.

Justin's dilemma is how to construct a budget that accurately reflects the costs of the proposed new process. Justin is an experienced executive and feels comfortable with his ability in estimating costs of projects. However, the recent firing of his colleague has made him a little gun-shy. Only one stage of the four-stage sensor manufacturing process is being changed. Justin has detailed cost information about the majority of the process. Unfortunately the costs and tasks involved in the new modified process stage are unclear at this point. Justin also believes that the new modifications will cause some minor changes in the other three stages, but these potential changes have not yet been clearly identified. The stage being addressed by the project represents almost 50 percent of the manufacturing cost.