Project Cost Management: Cost Estimating

Project managers must take cost estimates seriously if they want to complete projects within budget constraints. After developing a good resource requirements list, project managers and members of their project team must develop several estimates of the costs for these resources. This section describes the various types of cost estimates, tools and techniques for cost estimation, typical problems associated with information technology cost estimates, and a detailed example of a cost estimate for an information technology project.

Types of Cost Estimates

One of the main outputs of project cost management is a cost estimate. Project managers normally prepare several types of cost estimates for most projects. These estimates -- rough order of magnitude, budgeting, and definitive -- vary primarily on when they are done, how they will be used, and how accurate they are.

• A rough order of magnitude (ROM) estimate provides a rough idea of what a project will cost. This estimate is usually done very early in a project or even before a project is officially started. Project managers and upper management use this estimate to help make project selection decisions. The time-frame for this type of estimate is often three or more years prior to project completion. A ROM estimate’s accuracy is typically -25 percent to +75 percent, meaning the project’s actual costs could be 25 percent below the ROM estimate or 75 percent above. For information technology project estimates, this accuracy range is often much wider. Many information technology professionals automatically double estimates for software development because of the history of cost overruns on information technology projects.



• A budgetary estimate is used to allocate money into an organization’s budget. Many organizations develop budgets at least two years into the future. Budgetary estimates are made one to two years prior to project completion. The accuracy of budgetary estimates is typically -10 percent, to +25 percent, meaning the actual costs could be 10 percent less or 25 percent more than the budgetary estimate.



• A definitive estimate provides an accurate estimate of project costs. Definitive estimates are used for making many purchasing decisions for which accurate estimates are required and for estimating final project costs. For example, if a project involves purchasing 1,000 personal computers from an outside supplier in the next three months, a definitive estimate would be required to aid in evaluating supplier proposals and allocating the funds to pay the chosen supplier. Definitive estimates are made one year or less prior to project completion. A definitive estimate should be the most accurate of the three types of estimates. The accuracy of this type of estimate is normally to +10 percent, meaning the actual costs could be 5 percent less or 10 percent more than the definitive estimate. The Table below summarizes the three basic types of cost estimates.

Two additional outputs of the cost estimating process are supporting details and a cost-management plan. It is very important to include supporting detail with all cost estimates. The supporting details include the ground rules and assumptions used in creating the estimate, a description of the project scope statement, WBS, and so on) used as a basis for the estimate, and details on the cost estimation tools and techniques used to create the estimate. This supporting detail should make it easier to prepare an updated estimate or similar estimate when one is needed.

A cost management plan is a document that describes how cost variances will be managed on the project. For example, if a definitive cost estimate provides the basis for evaluating supplier cost proposals for all or part of a project, the cost management plan describes how to respond to proposals that are higher or lower than the estimates. Some organizations assume that a cost proposal within 10 percent of the estimate is fine and only negotiate items that are over 10 percent higher or 20 percent lower than the estimated costs. The cost management plan is part of the overall project plan (for more info, Google “Project Integration Management”).

Cost Estimation Techniques and Tools

There are basic techniques for cost estimating: analogous, bottom-up estimating, and parametric modeling. There are also many computerized tools that can help you implement these techniques.

Analogous estimates, also called top-down estimates, use the actual cost of a previous, similar project as the basis for estimating the cost of the current project. It is a form of expert judgment. This method is generally less costly than others, but it is also less accurate. Analogous estimates are most reliable when the previous projects are similar in fact and not just in appearance. In addition, the groups preparing estimates must have the needed expertise to determine whether certain parts of the project will be more or less expensive than analogous projects. However, if the project to be estimated involves a new programming language or working with a new type of hardware or network, the analogous approach could easily result in too low an estimate.

Bottom-up estimating involves estimating individual work items and summing them to get a project total. The size of the individual work items and the experience of the estimators drive the accuracy of the estimates. If a detailed WBS is available for a project, the project manager could have each person responsible for a work package develop his or her own cost estimate for that work package. All of the estimates would then be added to create estimates for each higher level WBS item and finally for the entire project. Using smaller work items increases the accuracy of the estimate because the people assigned to do the work develop the estimate instead of someone unfamiliar with the work. The drawback of bottom-up estimates is that they are usually time-intensive and therefore expensive to develop.

Parametric modeling uses project characteristics (parameters) in a mathematical model to estimate project costs. A parametric model might provide an estimate of $50 per line of code for a software development project based on the programming language the project is using, the level of expertise of the programmers, the size and complexity of the data involved, and so on. Parametric models are most reliable when the historical information that was used to create the model is accurate, the parameters are readily quantifiable, and the model is flexible in terms of the size of the project. For example, in the 1980s, engineers at McDonnell Douglas Corporation (now part of Boeing) developed a parametric model for estimating aircraft costs based on a large historical database. The model included the following parameters the type of air craft (fighter aircraft, cargo aircraft, or passenger aircraft), how fast the plane would fly, the thrust-to-weight ratio of the engine, the estimated weights of various parts of the aircraft, the number of aircraft produced, the amount of time available to produce them, and so on. In contrast to this sophisticated model, some parametric models involve very simple heuristics or rules of thumb. For example, a large office automation project might use a ballpark figure of $10,000 per workstation based on a history of similar office automation projects developed during the same time period. More complicated parametric models are usually computerized.

One popular parametric model is the Constructive Cost Model (COCOMO), which is used for estimating software development costs based on parameters such as the source lines of code or function points. COCOMO was developed by Barry Boehm, a well-known expert in the field of software development and cost estimating. Function points are technology-independent assessment of the functions involved in developing a system. For example, the number of inputs and outputs, the number of files maintained, and the number of updates are examples of function points. COCOMO II is a newer, computerized version of Boehm’s model that allows you to estimate the cost, effort, and schedule when planning a new software development activity. Boehm suggests that only algorithmic or parametric models do not suffer from the limits of human decision- making capability. As a consequence, Boehm and many other software experts favor using algorithmic models when estimating software project costs.

Computerized tools, such as spreadsheets and project management soft ware, can make working with different cost estimates and cost estimation tools easier. Computerized tools, when used properly, can also help improve the accuracy of estimates. In addition to spreadsheets and project management software, more sophisticated tools are available for estimating software project costs.

Typical Problems with Information Technology Cost Estimates

Although there are many tools and techniques to assist in creating project cost estimates, many information technology project cost estimates are still very inaccurate, especially those involving new technologies or software development. Tom DeMarco, a well-known author on software development, suggests four reasons for these inaccuracies and sonic ways to overcome them (7).

1. Developing an estimate for a large software project is a complex task requiring a significant amount of effort. Many estimates must be done quickly and before clear system requirements have been produced. For example, the surveyor’s assistant project described in the opening case involves a lot of complex software development. Before fully understanding what information surveyors really need in the system, someone would have to create a rough order-of-magnitude estimate and budgetary estimates for this project. Rarely are the more precise, later estimates less than the earlier estimates for information technology projects. It is important to remember that estimates are done at various stages of the project, and project managers need to explain the rationale for each estimate.

2. The people who develop software cost estimates often do not have much experience with cost estimation, especially for large projects. There is also not enough accurate, reliable project data available on which to base estimates. If companies use good project management and develop a history of keeping good project information, including estimates, it should help them to improve their estimates. Enabling information technology people to receive training and mentoring on cost estimating will also improve cost estimates.

3. Human beings have a bias toward underestimation. For example, senior information technology professionals or project managers might make estimates based on their own abilities and forget that many junior people will he working on a project. Estimators might also forget to allow for extra costs needed for integration and testing on large information technology projects. It is important for project managers and senior management to review estimates and ask important questions to make sure the estimates are not biased.

4. Management might ask for an estimate, but really desire a number to help them create a bid to win a major contract or get internal funding. This problem is similar to the situation discussed in Project Time Management, in which senior managers or other stakeholders want project schedules to he shorter than the estimates. It is important for project managers to help develop good cost and schedule estimates and to use their leadership and negotiation skills to stand by those estimates.

7. DeMarco Tom, Controlling Software Projects. New York: Yourdon Press, 1982.

Sample Cost Estimates and Supporting Detail for an Information Technology Project

One of the best ways to learn how the cost estimating process works is by studying a sample cost estimate. Every cost estimate is unique, just as every project is unique. This section provides information from an actual information technology project cost estimate. The entire estimate was much longer, but parts of it are provided here to illustrate what a good cost estimate entails.

Before beginning the creation of any cost estimate, you must first know how the estimate will be used. If the estimate will be the basis for contract awards and performance reporting, it should be a definitive estimate and fairly accurate, as described earlier. In the example presented here, a budgetary estimate was done for replacing legacy systems, older information systems that run on old mainframe computers. Legacy systems support basic business processes such as general ledger, accounts payable and receivable, and project accounting. The name of this project was the Business Systems Replacement project. The total cost estimate for this three-year project was about $7.5 million. The life of the new system was estimated to be eight years.

The main objective of the Business Systems Replacement (BSR) project was to replace several legacy systems with a suite of packaged financial applications software (provided by Oracle). The suite of financial applications would pro vide more timely information for management decision making, easier access to data by end users, and reduced costs through productivity improvements throughout the company. The legacy systems were all written in-house specifically for that company. By purchasing packaged software, the company would no longer need its old mainframe computer and would benefit from having additional features and regular upgrades to the software without needing to write its own code.

The Table below shows the overview for the BSR cost estimate. Notice the main categories found in the cost estimate overview: objective, scope, assumptions, and cost/benefit analysis and internal rate of return (IRR). The overview high lights information important to senior management and others interested in the cost estimate for the project.

Table of: Business Systems Replacement Project Cost Estimate Overview

Another important part of the BSR cost estimate was the cash flow analysis. The table below shows the estimated costs, benefits or savings, and net cost or savings from fiscal year (FY) 1995 through 1997. Numbers in parentheses represent negative numbers or costs. The table also shows the total project costs and savings and projected a savings in future years beyond 1997. Notice that this company chose to f on the first three years of the project in this summary cash flow analysis and estimated all future annual savings in one column. Estimates are less reliable the farther out in time you go, so some estimates use this approach.

Table of: Business Systems Replacement Project Cash Flow Analysis

click here or image to enlarge

In the Table above, you can see that the main cost categories for this estimate include the purchase cost for Oracle’s software, hardware and software maintenance related to the project, consulting and training, tax and acquisition, Information Services and Technology (IS&T) effort, and Finance/other departments’ effort. These cost categories are the same as summary tasks from the project’s work breakdown structure. In this example, the main supplier, Oracle, provided detailed information for determining the cost of purchasing their software. The company received discounts and credits from previous purchases that made the net cash cost for the purchased software equal to zero. Oracle also provided estimates for software maintenance, consulting, and training costs. Note that the largest item in this cost estimate is the Information Services and Technology (IS&T) effort, which involves the people in the company’s IS&T department who worked with Oracle and other internal departments to plan, implement, and support the new system. Major savings or benefits items were the savings from replacing the mainframe system, savings in various departments, a reduction in Information Services and Technology staff needed to support the legacy system, and interest savings from loans related to the old system.

The cash flow analysis provided the basis for determining the internal rate of return (IRR) for the life of the project. In this example, the IRR was 35 percent over eight years, which is a very good return.

Estimates provide the basis for cost budgeting and cost control, as described in the following sections. To use an estimate as the basis for budgeting, the estimator must understand how his or her organization prepares budgets. Likewise, to use estimates as the basis for cost control, the estimator must understand how the organization performs cost control.