Section 3.4.3 of this Guidebook primarily focused on procedures associated with life-cycle cost estimates which are subject to review by the Office of Cost Assessment for major defense acquisition programs. The estimate is prepared in support of major milestone or other program reviews held by the Defense Acquisition Board. This section is intended to be more generally applicable and somewhat more analytic in nature. It describes a recommended analytic approach for planning, conducting, and documenting a life-cycle cost estimate for a defense acquisition program (whether or not the estimate is subject to Office of Cost Assessment review). Much of the discussion in this section was written with the less experienced cost analyst in mind.

The recommended analytic approach for preparing a life-cycle cost estimate is shown in Figure 3.7.F1:

Figure 3.7.F1. A Recommended Analytic Approach for Life-Cycle Cost Estimates

The next few sections describe this process.

3.7.1. Develop Approach and Scope

The first step in preparing a credible cost estimate is to begin with the development of a sound analytic approach. During this planning phase, critical ground rules and assumptions are established, the scope of the estimate is determined, and the program to be costed is carefully defined and documented. The program definition includes not only a technical and physical description of the system (and perhaps major subsystems), but also a description of the system's program schedule, acquisition strategy, and operating and support concepts. In some cases, it is necessary to state explicitly the costs to be included, and the costs to be excluded. For example, when systems have complex interfaces with other systems or programs (that are outside the scope of the system being costed), the interfaces should be carefully defined.

For programs that will be reviewed by the Office of Cost Assessment, the program office is required to define its program in a comprehensive formal written document known as a Cost Analysis Requirements Description (CARD). The format for this document is briefly summarized in section 3.4.4.1 of this Guidebook, and is completely described in DoD 5000.4 M, "DoD Cost Analysis Guidance and Procedures," Section1. Much of the necessary information to prepare a written program description can be extracted and synthesized from common program source documents and contract specifications. The written program description should stand-alone as a readable document, but can make liberal use of suitable references to the source documents to minimize redundancy and effort.

It is important that the analytic approach to the cost estimate be documented and reviewed by all potentially interested parties, before the actual work on preparing the cost estimate begins. This helps ensure that there are no false starts or misunderstandings later in the process.

3.7.1.1. Work Breakdown Structure (WBS)

Part of the system definition typically includes the program work breakdown structure. The program WBS is a hierarchy of product-oriented elements (hardware, deliverable software, data, and services) that collectively comprise the system to be developed or produced. The program WBS relates the elements of work to each other and to the end product. The program WBS is extended to a contract WBS that defines the logical relationship between the elements of the program and corresponding elements of the contract work statement. The WBS provides the framework for program and technical planning, cost estimating, resource allocation, performance measurement, technical assessment, and status reporting. In particular, the contract WBS provides the reporting structure used in contract management reports or reports in the Contractor Cost Data Reporting system. Further information about the WBS can be found in MIL-STD-881C, Work Breakdown Structures for Defense Materiel Items, which is available at the Defense Cost and Resource Center web site.

A sample of the WBS for an air-to-air tactical missile is provided in Figure 3.7.1.1.F1

Figure 3.7.1.1.F1. Sample Work Breakdown Structure

Sample Work Breakdown Structure

3.7.1.2. Cost Estimating Functional Categories

In most cost estimates, selected WBS elements (usually high cost) often are further broken down into functional categories. A typical structure for the functional categories is provided in Figure 3.7.1.2.F1. In the tactical missile example discussed in the last section, most likely the cost estimate for the Airframe WBS element would be broken down by functional category, whereas the cost estimate for the Initial Spares and Repair Parts WBS element most likely would be estimated at the level of total cost, and not by functional category.

Standard terms and definitions for the various functional categories were developed to support the Cost and Software Data Reporting system (see section 3.4.4.2). The terms and definitions used in Figure 3.7.1.2.F1 can be found in the following:

DoD 5000.04-M-1, "Cost and Software Data Reporting (CSDR) Manual"
Data Item Description DI-FNCL-81565B, "Cost Data Summary Report (DD Form 1921)"
Data Item Description DI-FNCL-81566B, "Functional Cost-Hour Report (DD Form 1921-1)"

All of these are available at the Defense Cost and Resource Center web site.

Figure 3.7.1.2.F1. Functional Categories for Cost Estimating

Functional Categories for Cost Estimating

3.7.1.3. Operating and Support (O&S) Cost Element Structure

Another step in developing the analytic approach to the cost estimate is establishing the cost element structure that will be used as the format for the O&S cost estimate. The cost element structure describes and defines the specific elements to be included in the O&S cost estimate in a disciplined hierarchy. Using a formal cost element structure (prepared and coordinated in advance of the actual estimating) identifies all of the costs to be considered, and organizes the estimate results. The cost element structure is used to organize an O&S cost estimate similar to the way that a work breakdown structure is used to organize a development or procurement cost estimate. The intent is to capture all costs of operating, maintaining, and supporting a fielded system (and its associated manpower and facilities). A notional portrayal of these costs, organized into a cost element structure format, is provided in Figure 3.7.1.3.F1. Note that the use of a cost element structure provides considerably more detail than simply using budget appropriation categories (operations and maintenance, military personnel).

Figure 3.7.1.3.F1. O&S Costs Organized by a Cost Element Structure

O&S Costs Organized by a Cost Element Structure

A standard cost element structure used by the Office of Cost Assessment was introduced in section 3.1.3.3. Details can be found in the OSD CAPE O&S Cost-Estimating Guide. Although each DoD Component (military department or defense agency) may have its own preferred cost element structure, it is expected that each DoD Component will have a cross walk or mapping so that any presentation to the Office of Cost Assessment can be made using the standard structure.

3.7.2. Prepare the Estimate

This section describes the typical steps in preparing a life-cycle cost estimate. The discussion summarizes the steps entailed in selecting estimating techniques or models, collecting data, estimating costs, and conducting sensitivity or risk analysis.

In addition, the importance of good documentation of the estimate is explained.

3.7.2.1. Select Methods and/or Models

A number of techniques may be employed to estimate the costs of a weapon system. The suitability of a specific approach will depend to a large degree on the maturity of the program and the level of detail of the available data. Most cost estimates are accomplished using a combination of the following estimating techniques:

Parametric. The parametric technique uses regression or other statistical methods to develop Cost Estimating Relationships (CERs). A CER is an equation used to estimate a given cost element using an established relationship with one or more independent variables. The relationship may be mathematically simple or it may involve a complex equation (often derived from regression analysis of historical systems or subsystems). CERs should be current, applicable to the system or subsystem in question, and appropriate for the range of data being considered.
Analogy. An analogy is a technique used to estimate a cost based on historical data for an analogous system or subsystem. In this technique, a currently fielded system, similar in design and operation to the proposed system, is used as a basis for the analogy. The cost of the proposed system is then estimated by adjusting the historical cost of the current system to account for differences (between the proposed and current systems). Such adjustments can be made through the use of factors (sometimes called scaling parameters) that represent differences in size, performance, technology, and/or complexity. Adjustment factors based on quantitative data are usually preferable to adjustment factors based on judgments from subject-matter experts.
Engineering Estimate. With this technique, the system being costed is broken down into lower-level components (such as parts or assemblies), each of which is costed separately for direct labor, direct material, and other costs. Engineering estimates for direct labor hours may be based on analyses of engineering drawings and contractor or industry-wide standards. Engineering estimates for direct material may be based on discrete raw material and purchase part requirements. The remaining elements of cost (such as quality control or various overhead charges) may be factored from the direct labor and material costs. The various discrete cost estimates are aggregated by simple algebraic equations (hence the common name "bottoms-up" estimate). The use of engineering estimates requires extensive knowledge of a system's (and its components') characteristics, and lots of detailed data.
Actual Costs. With this technique, actual cost experience or trends (from prototypes, engineering development models, and/or early production items) are used to project estimates of future costs for the same system. These projections may be made at various levels of detail, depending on the availability of data. Cost estimates that support a full-rate production milestone decision should be based on actual cost data to the greatest extent possible. A common mistake is to use contract prices as a substitute for actual cost experience. Contract prices should not be used to project future costs (even when firm-fixed price) unless it is known that the contract prices are associated with profitable ventures, and that it is reasonable to assume that similar price experience will be obtained for subsequent contracts.

In many instances, it is a common practice to employ more than one cost estimating method, so that a second method can serve as a cross-check to the preferred method. Analogy estimates are often used as cross-checks, even for estimates of mature systems based on actual costs.

The next two sections provide two illustrative examples of common cost estimating techniques.

3.7.2.1.1. Example #1—Cost Estimating Relationship

An exemplar cost estimating relationship is provided in Figure 3.7.2.1.1.F1. The relationship is used to estimate production costs for a component of a tactical missile, using various technical characteristics as independent variables. Developing a good relationship requires not only sound statistical practice, but also considerable experience and insight on the part of the cost analyst. It also requires detailed and well-understood data.

Figure 3.7.2.1.1.F1. Illustrative Cost Estimating Relationship

Illustrative Cost Estimating Relationship

3.7.2.1.2. Example #2—Analogy

An exemplar cost estimate by analogy is provided in Figure 3.7.2.1.2.F1. In this case, an estimate for one of the Operating and Support (O&S) cost elements (depot level reparables) for a future aircraft system is made by direct analogy to a predecessor aircraft system with a similar mission. Note that the analogy uses scaling parameters for operating (i.e., flying) hours, reliability, and system unit cost. In many analogy estimates, unit cost is often used as a proxy for complexity.

Figure 3.7.2.1.2.F1. Illustrative Cost Estimate by Analogy

Illustrative Cost Estimate by Analogy

3.7.2.2. Collect, Validate, and Adjust Data

There are many possible sources of data that can be used in cost estimates. Regardless of the source, the validation of the data (relative to the purpose of its intended use) always remains the responsibility of the cost analyst. In some cases, the data will need to be adjusted or normalized. For example, in analogy estimates, the reference system cost should be adjusted to account for any differences in system characteristics (technical, physical, complexity, or hardware cost) or operating environment between the reference system and the proposed system being costed.

3.7.2.2.1. Acquisition Cost Data

Actual cost experience on past and current acquisition programs often forms the basis of estimates of future systems. The Cost and Software Data Reporting (CSDR) system is the primary means within the Department of Defense to systematically collect data on the development and production costs and other resource usage incurred by contractors in performing DoD acquisition program contracts associated with major defense acquisition programs. DoD Instruction 5000.02 makes CSDR reporting mandatory for all major contracts and subcontracts, regardless of contract type valued at more than $50 million (then-year dollars). Program managers use the CSDR system to report data on contractor development, production, and sustainment costs and resource usage incurred in performing DoD programs. Further, the Defense Federal Acquisition Regulation Supplement (DFARS) establishes requirements for CSDR Reporting to be included in the proposals and contract performance for major acquisition programs (MDAPs) and Major Automated Information Systems (MAIS). Additional information on cost data reporting is found in section 3.4.4.2. of this Guidebook.

3.7.2.3. Estimate Costs

With the completion of the steps described earlier in this chapter, the actual computations of the cost estimate can begin. It is important to assess critically the outputs from the estimating methods and models, drawing conclusions about reasonableness and validity. Peer review is often helpful at this point. For complex cost estimates, with many elements provided from different sources, considerable effort and care are needed to deconflict and synthesize the various elements.

3.7.2.4. Assess Risk and Sensitivity

For any system, estimates of future life-cycle costs are subject to varying degrees of uncertainty. The overall uncertainty is not only due to uncertainty in cost estimating methods, but also due to uncertainties in program or system definition or in technical performance. Although these uncertainties cannot be eliminated, it is useful to identify associated risk issues and to attempt to quantify the degree of uncertainty as much as possible. This bounding of the cost estimate may be attempted through sensitivity analyses or through a formal quantitative risk analysis.

Sensitivity analysis attempts to demonstrate how cost estimates would change if one or more assumptions change. Typically, for the high-cost elements, the analyst identifies the relevant cost-drivers, and then examines how costs vary with changes in the cost-driver values. For example, a sensitivity analysis might examine how maintenance manning varies with different assumptions about system reliability and maintainability values, or how system manufacturing labor and material costs vary with system weight growth. In good sensitivity analyses, the cost-drivers are not changed by arbitrary plus/minus percentages, but rather by a careful assessment of the underlying risks. Sensitivity analysis is useful for identifying critical estimating assumptions, but has limited utility in providing a comprehensive sense of overall uncertainty.

In contrast, quantitative risk analysis can provide a broad overall assessment of variability in the cost estimate. In risk analysis, selected factors (technical, programmatic and cost) are described by probability distributions. Where estimates are based on cost models derived from historical data, the effects of cost estimation error may be included in the range of considerations included in the cost risk assessment. Risk analysis assesses the aggregate variability in the overall estimate due to the variability in each input probability distribution, typically through Monte-Carlo simulations. It is then possible to derive an estimated empirical probability distribution for the overall life-cycle cost estimate. This allows the analyst to describe the nature and degree of variability in the estimate.

Sensitivity and risk analyses also have uses beyond addressing the uncertainty in cost estimates. They also can be used to help better understand what can go wrong with a program, and focus appropriate management attention to risk areas that are concerns. The history of DoD weapon system acquisition would indicate that cost growth and schedule delays can occur as a direct result of one or more of the following concerns:

Immaturity of critical technologies at the start of development
Inadequate understanding of design challenges at the start of development (often due to the absence of prototyping)
Requirements uncertainty, instability, or creep
Failure to acknowledge (or deal with) funding shortfalls
Funding instability in the programming, budgeting or appropriations process
Failure to detect (or deal with) unrealistic contractor cost proposals in competitive source selections (from either the prime or major subcontractors)
Excessive concurrency between development and procurement schedules
Inadequate understanding of software development size and integration challenges
Failure to achieve design stability by the time of the critical design review
Failure to achieve stable manufacturing processes by the time of early production

3.7.2.5. Document and Present Results

A complete cost estimate should be formally documented. The documentation serves as an audit trail of source data, methods, and results. The documentation should be easy to read, complete and well organized-to allow any reviewer to understand the estimate fully. The documentation also serves as a valuable reference for future cost analysts, as the program moves from one acquisition milestone to the next.

The documentation should address all aspects of the cost estimate: all ground rules and assumptions; the description of the system and its operating and support concepts; the selection of cost estimating methods; data sources; the actual estimate computations; and the results of any sensitivity or risk analyses. The documentation for the ground rules and assumptions, and the system description, should be written as an updated (final) version of the Cost Analysis Requirements Description (CARD) or CARD-like document described earlier. The documentation for the portion of the cost estimate dealing with data, methods, and results often is published separately from the CARD or CARD-like document, but if that is the case, the two documents should be completely consistent.

3.7.3. Coordination

Managing the preparation of a life-cycle cost estimate requires continual coordination among all of the stakeholders. Normally, cost estimates are sponsored by a system program office and are prepared by a multi-disciplinary team with functional skills in financial management, logistics, engineering, and other talents. The team also should include participants or reviewers from major affected organizations, such as the system's operating command, product support center, maintenance depot, training center or command, and so forth. Typically, the analytic approach to the cost estimate is documented in a written study plan that includes a master schedule (of specific tasks, responsible parties, and due dates). For sufficiently complex efforts, the estimating team may be organized as a formal Integrated Product Team. Throughout the preparation of the estimate, coordination with all interested parties remains important. Frequent in-progress reviews or meetings are usually a good practice.

For independent cost estimates, the team may be smaller and less formal, but the basic principle—complete and continual coordination of the cost estimate with all interested parties—still applies.

Top of page

Previous and Next Page arrows