IT project management: The cost estimating process

Estimate versus target or goal

Sometimes the word "estimate" is confused with "target" and "goal." It shouldn't be. An estimate is a realistic assessment based upon known facts about the work, required resources, constraints, and the environment, derived from estimating methods, whereas a target or goal is a desired outcome, commitment, or promise. Other than by chance, the estimate usually will not be the same as the target or goal. That said, once computed the estimate can be compared to a target value or goal, and revised by making hard-headed changes to the cost origins—work tasks, resources, schedules, etc. The point is, an estimate should be determined independently of any target or goal; afterward it can be altered by adjusting the work and resources to bring it as close as possible to the target, but never should the estimate be a simple plug-in of the target value.

Accuracy versus precision

"Accuracy" represents the closeness of the estimated value to the actual value: the accuracy of a project estimated to cost $99,000 but actually costing $100,000 is very good. In contrast, " precision " is the number of decimal places in the estimate. An estimate of $75,321 is more precise than one of $75,000, though neither is accurate if the actual cost is $100,000. Accuracy is more important than precision: the aim is to derive the most accurate estimate possible.

Classifying work tasks and costs

The cost estimating process begins by breaking the project down into work phases such as design, engineering, development, and fabrication, or into work packages from the WBS. The project team, including members from the involved functional areas and contractors, meets to discuss the work phases or packages, and to receive specific work assignments.

The team tries to identify tasks in the project that are similar to existing designs and standard practices and can readily be adopted. Work is classified either as developmental or as an adaptation of existing or off-the-shelf (OTS) designs, techniques, or procedures. Because developmental work requires effort in design, testing, and fabrication, cost estimating is more difficult compared to OTS due to the greater uncertainty about what needs to be done. Overruns for developmental work are common, especially due to inaccurate labor estimates. In contrast, estimating for OTS items or duplicated work is straightforward because it is based upon known prices, or records of material and labor costs for similar systems or tasks. It is thus often beneficial to make use of existing designs and technology as much as possible.

Estimated costs are classified as recurring and nonrecurring. Recurring costs happen more than once and are associated with tasks periodically repeated, such as costs for quality assurance and testing. Nonrecurring costs happen once and are associated with development, fabrication, and testing of one-of-a-kind items, or procurement of special items.

In the pure project form of organization the project manager delegates the responsibility for the estimating effort, combines the estimated results, and presents the final figures to management. In a matrix organization, estimating is the joint responsibility of the project and functional managers, though the project manager coordinates the effort and accumulates the results. The estimating effort requires close coordination and communication between the estimating groups to avoid redundancies and omissions.

Although this typifies the cost estimating process, the actual method used to estimate cost figures will depend on the required accuracy of and the information available to make the estimate. Cost estimates are determined using variants of four basic techniques: expert opinion, analogy, parametric, and cost engineering.

Expert opinion

An expert opinion is an estimate provided by an expert -- someone who from breadth of experience and expertise is able to provide a reasonable, ballpark estimate. It is a "seat of the pants " estimate used when lack of information precludes a moredetailed, in-depth cost analysis. Expert opinion is usually limited to cost estimating during the conception phase and for projects that are poorly defined or unique, for which there are no previous, similar projects to compare.

Analogy estimate

An analogy estimate is developed by reviewing costs from previous, similar projects. The method can be used at any level: overall project cost can be estimated from the cost of an analogous project; work package cost can be estimated from other, analogous workpackages; and task cost can be estimated from analogous tasks. The cost for a similar project or work package is analyzed and adjusted for differences between it and the proposed project or work package, taking into account factors such as dates, project scale, location, complexity, exchange rates, and so on. If, for example, the analogy project was performed 2 years ago and the proposed project is to commence 1 year from now, costs from the analogy project must be adjusted for inflation and price changes during the 3-year interim. If the analogy project was conducted in California and the proposed project will be in New York, costs must be adjusted for site and regional differences. If the " size " (scope, capacity, or performance) of the proposed task is twice that of the analogy task, then the costs of the analogy task must be " scaled " up. However, twice the size does not mean twice the cost, and the size-cost relationship must be determined from analogy or formulas based on physical principles.

Example 3: Estimating project costs by scaling an analogy project

Because the analogy method involves comparisons to previous, similar projects, it requires an extant information database about prior projects. Companies that are serious about using the analogy method must rely on good project cost documentation and a database that classifies cost information according to type of project, work package, task, and so on. When a new project is proposed, the database is used to provide cost details about prior similar projects and work packages. Of course, the first assumption in the analogy method is that the analogy to be used is valid; sometimes this is where things go awry.

Example 4: A case of costly mistaken analogy

Parametric estimate

A parametric estimate is an estimate derived from an empirical or mathematical relationship. The parametric method can be used with an analogy project (the case in Example 3) to scale costs up or down, or it can be applied directly—without an analogy project—when costs are a function of system or project " parameters. " The parameters can be physical features such as area, volume, weight, or capacity, or performance features such as speed, rate of output, power, or strength. Parametric cost estimating is especially useful when preliminary design characteristics are first being set and a cost estimate is needed quickly.

Example 5: Parametric estimate of material costs

Cost engineering

Cost engineering refers to detailed cost analysis of individual cost categories at the work package or task level. It is a bottom-up approach that not only provides the most accurate estimates of all the methods but also is the most time-consuming; it requires considerable work-definition information -- which often is not be available until later in the project. The method starts by breaking down the project into activities or work packages, then further divides these into cost categories. For small projects like Example 6 the approach is simple and straightforward.

Example 6: Cost engineering estimate for a small project

Figure 8-3 Schedule showing hours allocated to work packages by labor grade.

Table 8-1 Labor hours and nonlabor costs.

At the work package or lower level, detailed estimates are sometimes derived with the aid of standards manuals and tables. Standards manuals contain time and cost information about labor and materials to perform particular tasks. In construction, for example, the numbers of labor hours to install an electrical junction box or a square foot of wall forms are both standard times. To determine the labor cost of installing junction boxes in a building, the estimator determines the required number of junction boxes, multiplies this by the labor standard per box, and then multiplies that by the hourly labor rate. For software development the industry standard is one person-year to create 2,000 lines of bug-free code.

For larger projects the estimating procedure is roughly the same as illustrated in Example 6 although more involved. First, the manager of each work package breaks the work package down into more fundamental or "basic" areas of work. For example, a work package might be divided into two basic areas: " engineering " and " fabrication." The manager of the work package then asks his supervisors to estimate the hours and materials needed to do the work in each basic area. The supervisor overseeing engineering might further divide work into the tasks of structural analysis, computer analysis, layout drawings, installation drawings, manuals, and reproduction, then develop an estimate for each task duration and the labor grade or skill level required. In similar fashion, the fabrication supervisor might break the work down into fabricated materials (steel, piping, wiring), hardware, machinery, equipment, insurance, and so on, then estimate how much (quantity, size, length, weight, etc.) of each will be needed. Estimates of time and materials are determined by reference to previous, similar work, standards manuals, reference documents, and rules of thumb ( "one hour for each line of code "). The supervisors submit their estimates to the work package manager who checks, revises, and then passes them on to the project manager. The more developmental and the less standardized the task, the more guesswork involved; even with routine or OTS items, accurate estimating is somewhat of an art.

The project manager and independent estimators or pricing experts on the project staff review the submitted time and material estimates to be sure that no costs were overlooked or duplicated, estimators understood what they were estimating, correct estimating procedures were used, and allowances made for risk and uncertainty. 13 The estimates are then aggregated as shown in Figure 8-4 and converted into dollars using standard wage rates and material costs (current or projected). Finally, the project manager tallies in any project-wide overhead rates (to cover project management and administrative costs) and company-wide overhead rates (to cover the burden of general company expenses) to come up with a cost estimate for the total project. The accumulation of work package estimates (upward arrows in Figure 8-4 ) to derive the project estimate is called the "bottom-up" approach.

Figure 8-4 The cost estimating process.

Contingency amount

Contingency amounts are added to estimates to offset uncertainty. In general, the less well defined or more complex the situation, the greater the required amount. Contingency amounts can be developed for individual activities or work packages, or the project as a whole. Activity contingency is an amount estimated to account for "known unknowns" in an activity or work package, i.e., sources of cost increases that could or likely will occur; they include scrap and waste, design changes, increases in the scope, size, or function of the end-item, and delays due to weather. Later, when the project budget is established, this amount should be included in a special budget, subdivided into work package accounts and strictly controlled by the project manager. For the project cost estimate, the project manager sums these activity contingencies and adds them to the total project cost, yielding the base estimate.

To the base estimate the project manager might add yet another amount, a project contingency . This is to account for " unknown unknowns " —external factors that affect project costs but cannot be pinpointed. Examples include unforeseen fluctuation in exchange rates, shortages in resources, and changes in the market or competitive environment. The size of the contingency depends on the perceived risk and likelihood of cost escalation due to unknowns. Computing the contingency based on the perceived project risk is covered in Chapter 10. Any subsequent usage of project contingency funds, like that of the activity contingency, is controlled by the project manager. Adding the project contingency to the base estimate gives the final cost estimate, which is the most likely cost.

Besides the activity and project contingencies, the corporation might also set aside an additional allowance to cover overruns. This amount, the overrun allowance , is added to the most likely cost to yield a cost where the probability of exceeding it is less than 10 percent. The overrun allowance is controlled by a program manager or corporate managers and is ordinarily not available to the project manager without approval.

Top-down versus bottom-up

In general, the application of the estimating techniques listed previously occur in two ways: top-down and bottom-up. Top-down refers to estimating the cost by looking at the project as a whole. A top-down estimate is typically based upon an expert opinion or analogy to other, similar projects. Bottom-up refers to estimating costs by breaking the project down into elements—individual project work packages and end-item components. Costs for each work package or end-item element are estimated separately and then aggregated to derive the total project cost. Example 6 is a bottom-up approach; Example 3 is a top-down approach. The two approaches can be used in combination: portions of a project that are well defined can be broken down into work packages and estimated bottom-up; other less-defined portions can be estimated top-down. In turn, the cost of each work package can be estimated by breaking the package into smaller elements and estimating the cost of each (bottom-up), or by making a gross estimate from analogy or expert opinion (top-down). The bottom-up method provides more accurate estimates than the top-down method but requires more data and concise definition of tasks.

Reconciling estimates

The project manager submits the final cost estimate to company management along with forecasts showing the effects of likely, potential escalation factors such as inflation and risks. The estimate is compared against top management's gross estimate, the goal or target set by the company or customer. Based on the difference between the gross and bottom-up estimates, management either accepts the estimate or mandates a revision. If the gross estimate is larger, the project manager reviews each work package estimate for possible oversights or over-optimism. If the bottom-up estimate is larger, the project manager reviews the work package estimates for incorrect assumptions, excesses, and other sources of excess cost.

Reducing costs

What happens if competition or insufficient funding forces management to reduce costs? Managers will want to retain their share of the project and none will want to see budget or staff reduced. Nonmanagement professionals such as engineers, scientists, or systems analysts, unless actively involved in the budgeting process, are often unaware of budget constraints and resist cuts. Here is where communication, negotiation, and diplomacy between project managers and functional managers and staff are necessary to convince the latter to accept a share of budget reductions. When this fails the project manager must look for ways to reduce costs (e.g., reduce work scope or labor requirements or use less costly resources) and convince the team to accept the reductions (dashed arrows in Figure 8-4 ). If that fails, the final resort is to appeal to top management. To reconcile differences between estimates, top management sometimes exercises an across-the-board cut on all estimates. This is poor practice because it fails to account for judgmental errors or excessive costs on the part of just a few units. It also unfairly penalizes managers who tried to produce fair estimates and were honest enough not to pad them. Such indiscriminate, acrossthe- board cuts induce everyone to pad estimates for their own protection.

Suppose you are the project manager and it is clear that management insists on a budget that is too low to perform the work. There are only two courses of action: either undertake the project and attempt wholeheartedly to meet the budget, or hand it over to another manager. If you decide on the former, you should document your disagreement and report it to top management; later, the client might agree to changes that would reduce costs and enable it to be completed within budget. If the contract is cost-plus, then the risk is low because additional costs will be reimbursed. If the contract is fixed price and the budget is so underfunded as to likely require cutting corners or stalling the project, then you should suggest to management that they appoint another project manager (who, assuming your argument is valid, might then argue the same case). Not only is this good business practice, it is the only ethical alternative.

More about cost estimation and project management

• Download a free .pdf of this chapter to learn more about cost estimation and budgeting for IT project management: "IT project management: The cost estimating process."

  More about project management

• Business intelligence project management: Five must-have pieces of advice