Cost Estimating Basics

Cost Estimating Basics
Why cost estimating (and an overview of how) Welcome to Module 1 Cost Estimating Basics, in which we discuss the basics of cost estimating and analysis and the reasons for doing cost estimates, and provide an overview of the process and methods for developing an estimate. Unit I - Module 1

Unit Index Unit I – Cost Estimating Unit II – Cost Analysis Techniques
Cost Estimating Basics Costing Techniques Parametric Estimating Unit II – Cost Analysis Techniques Unit III – Analytical Methods Unit IV – Specialized Costing Unit V – Management Applications Unit I provides an introduction to the fundamentals of cost estimating and how to go about developing your own cost estimate. In Module 1, you will be shown cost estimating basics. Many of the topics discussed herein are covered in greater detail in other modules. Next, in Module 2 Costing Techniques, you’ll learn the essential approaches to estimating cost, and Module 3 Parametric Estimating will further explore the costing technique which is often considered the hallmark of cost estimators. Unit I - Module 1

Outline Introduction to Cost Estimating and Analysis
Overview of Cost Estimating and Analysis Cost Estimating Products Cost Estimating Process & Methods Cost Estimating Certification Summary Resources In this module, we’ll provide the motivation for cost estimating, why and how it is used, and give an overview of the issues involved. We’ll talk about the basic kinds of products produced in cost estimating and briefly describe the process and methods used to develop cost estimates. The analytical techniques and details behind these processes and methods will be presented in much greater detail in future modules. We’ll give you the basic information on SCEA’s CCE/A certification, for which this course will help prepare you. As with all modules, we’ll end with a summary and present resources for reference and further study. In some of the later modules, there will be an optional Advanced Topics section at the very end, but this is the Basics, so let’s not get Advanced yet! Unit I - Module 1

Introduction to Cost Estimating and Analysis
Definition and Purpose Applications Organizations Skills In our introductory section, we’ll briefly present the definition and purpose of cost estimating and analysis; the most common applications; the types of organizations involved; and the variety of skills needed. Unit I - Module 1

Cost Estimating Cost Estimating: Purpose of cost estimating
The process of collecting and analyzing historical data and applying quantitative models, techniques, tools, and databases to predict the future cost of an item, product, program or task Purpose of cost estimating Translate system/functional requirements associated with programs, projects, proposals, or processes into budget requirements Determine and communicate a realistic view of the likely cost outcome, which can form the basis of the plan for executing the work What is cost estimating, and why do we do it? Cost estimating can be defined as the process of collecting and analyzing historical data and applying quantitative models, techniques, tools, and databases to predict the future cost of an item, product, program or task. Basically, cost estimating is the process of predicting the future based on today’s knowledge to bring to completion a program, project, or process. Often the cost estimator will be put in the position of adjusting for new materials, new technology, a new software programming language, and different team of individuals, etc., but the estimate must never become divorced from historical experience, or the estimate can be too easily assailed as mere soothsaying. The purpose of cost estimating is to translate system/functional requirements associated with programs, projects, proposals, or processes into budget requirements. It determines and communicates a realistic view of the likely cost outcome of a system or program. This outcome can form the basis of the plan for executing the work to develop, field, and support the system or program. Such a plan often begins in the proposal stages, and cost estimating serves as an important basis for a new business proposal, including the management bid/no-bid decision. Unit I - Module 1

Applications of Cost Estimating
As part of a total systems analysis, cost estimating helps decision makers to: Make decisions on program viability, structure, and resource requirements Establish and defend budgets Assess technology changes Conduct analysis of alternatives (AoA) Create new business proposals and perform source selection Perform design trade-offs Comply with public law Satisfy oversight requirements 13 14 16 How is cost estimating used, and what benefits does it provide? Cost estimating is a management tool used to help decision makers evaluate resource requirements at key milestones and decision points. It is not an end in itself, but is part of a total systems analysis process that includes programmatic, technical, and schedule analysis. Cost estimating supports various decision-making processes, including determining whether a program is viable, how it should be structured, and what resources are required to support it. It is used to help establish and defend budgets for these resources. Cost analysis can be used to assess impacts of changing technology, new equipment, or new operating or maintenance concepts. It can be applied as a tool to evaluate the cost implications of alternative systems when conducting an Analysis of Alternatives (AoA)). (AoAs are studies comparing technical, cost, and performance characteristics of multiple projects and are used to select among alternatives before committing to a particular project.) Costing or pricing is a vital part of the new business proposal development and source selection processes, and other aspects of contracting. Cost estimating enables design trade-offs by quantifying the cost impacts of different levels of performance. Finally, cost estimating is part of a sound management approach, and we should do it whether we are required or not. For government projects it may be a requirement of public law, and in both the public and private sectors there are oversight organizations whose requirements must be met. The bottom line is that cost estimating helps you and your team make better decisions, and because of its rigor, it also helps you defend those decisions to others outside your program. More information on AoAs, source selection, and design trade-offs may be found in Module 13 Economic Analysis, Module 14 Contract Pricing, and Module 16 Cost Management, respectively. Unit I - Module 1

Cost Estimating Organizations
1 Cost oversight organizations Program Offices and project teams Budgeting, contracting, and purchasing organizations Manufacturers Consultants 20 What kind of organizations perform or use cost estimates? Special purpose organizations exist within the government and industry to perform independent cost estimates (ICEs) and validate or adjust the estimates of other organizations. (A list of such government organizations will be presented shortly.) These are known as cost oversight organizations. There are also other organizations in government that oversee for fiscal responsibility at a broader level, including the Office of Management and Budget (OMB), the General Accounting Office (GAO) and the United States Congress. (Please don’t laugh that we use the words “fiscal responsibility” and “Congress” in the same sentence!) Government program offices and industry project teams use cost estimates both to justify obtaining resources from external sources and to help allocate resources internally. Budgeting, contracting, and purchasing organizations use cost analysis to make sure the cost/price of goods and services being budgeted for, contracted for, or purchased is reasonable and consistent, and cost estimating is often used to support the negotiation process. Manufacturers need to know their costs of operations in order to manage and reduce them. Finally, since any or all of the above groups may need assistance in the specialized skills of cost estimating or augmentation of their own capabilities, consultants play an important role in the cost community. Unit I - Module 1

Cost Estimating Skills
Cost estimating and analysis at its best is an interdisciplinary mix of: Mathematics, Probability, Statistics Economics, Econometrics, Business, Accounting, Budgeting Operations Research, Management Science, Industrial Engineering Mechanical Engineering, Systems Engineering, Physics, etc. Sales and Marketing 5 10 11 What kind of skills are needed for cost estimating and analysis? At its best, cost estimating and analysis requires a combination of many different skills and domains of expertise. Most of all, it requires the use of mathematics, from basic arithmetic to algebraic functions to rather sophisticated probability and statistics. If your background in prob/stat is not as strong, you will want to pay special attention to the foundations covered in Module 10 Probability and Statistics (and may even want to study ahead!). Because cost estimating involves the application of economic ideas like inflation and obtains much of its data from cost accounting systems, an understanding of economics, econometrics, business, and accounting is also important, and because cost estimates are used to justify allocation of resources, so is an understanding of the budgeting process. Since the application of cost estimates is most often in the arena of program and project management which seek to optimize all the aspects of system development, a familiarity with ideas from operations research (OR), the management sciences, and industrial engineering (IE) is helpful. IE can also be applied to detailed production analysis in a manufacturing environment (see Module 11 Manufacturing Cost Estimating). Finally, the more familiar you can be with the type of critter you are estimating (system, software, process, etc.), the better you’ll be able to identify cost drivers and find and understand the data you’ll need to develop cost estimates. While you’ll always rely on functional experts, mechanical engineering, systems engineering, physics, software development, even logistics knowledge will aid in your analysis and help you not appear so much like an outsider to the engineers and designers working on the project. Finally, a little bit of salesmanship is required, as you “sell” your estimate and achieve success with your own program leadership and those from external organizations. (Just make sure that your estimate is sold on the merits of its own methodology and documentation, and not on the slickness of your presentation!) Marketing insight is helpful in pricing a proposal to go after new work. Unless it was your childhood dream to grow up and become a cost estimator, chances are that if you’re studying this course, you’re coming to cost estimating from one of these fields. Though you may have significant background in one or more of above areas from your schooling and/or work experience, a combination of these skills is often required, so the good news is that almost everyone has something to learn from this course! (For a similar view of skills related to cost estimating, see the very bottom of the “Cost Estimating 101” page on the Naval Center for Cost Analysis (NCCA) website.) Cost Estimating 101, Naval Center for Cost Analysis (NCCA), Unit I - Module 1

Overview of Cost Estimating and Analysis
Requirements Benefits and Qualities Limitations and Concerns Types of Cost Estimates Government Entities The items we’ll discuss in our cost estimating overview are: the requirements for cost estimating and analysis; the benefits of cost estimating and analysis and the qualities or characteristics of a good cost estimate; the limitations of cost estimating and analysis and the concerns and issues that arise; the different types of cost estimates; and the government entities responsible for cost estimating. Unit I - Module 1

Requirements for Cost Estimating
Must estimate and plan consumption of resources Capture impacts of changing resources Validated cost estimate necessary to continue through milestone reviews Estimates should be updated periodically as program matures technically and schedules change Efficient management of changing requirements under tight constraints Supports management decisions by quantifying the resource impact of alternatives 11 Cost estimating is a critical element in any acquisition process. The acquisition process revolves around and focuses on the cost of an item or job and the availability of resources and funding. A reasonable, supportable, and responsive budget is essential to the efficient and timely execution of a program or task, and the budget is founded on competent estimates. Since resources are not limitless, we must estimate and plan for the consumption of finite resources, such as labor, capital, and equipment, available to the program or job. Realistic estimates of the projected cost of an activity determine adequate resource allocation and leads to greater probability of a successful project. Within the DoD budgeting process (Programming, Planning, and Budgeting System (PPBS)), estimates are required for Program Objectives Memorandum (POM) submission, and these estimates are revised during service comptroller, OSD, and President’s budget reviews. Budget estimate justifications are needed for reclamas, white papers, analysis of impacts of budget cuts, etc. Similar, though perhaps not as detailed, requirements exist to support the budgeting process within commercial organizations. Within the government, in order for a major program to continue through milestone reviews, acquisition reviews, etc., there must be a validated cost estimate. DoD Instruction and DoD M require that both a program office estimate (POE) and a DoD component cost analysis (CCA) estimate be prepared in support of acquisition milestone reviews. This is similar to the scrutiny required to continue through a stage-gate development process in industry. As a program matures technically and schedules change, cost estimates should be updated periodically to account for these changes. Updating the estimate provides a level of management insight into the current program status in order to maintain effective control of the program and balance resources and the budget. Not only may resources (budgets) change and technical and schedule progress be made as the program progresses, but the requirements for the program may change, either due to external pressures from customers or resource sponsors or due to internal systems engineering decisions. Cost estimating is required to manage changing requirements efficiently under tight constraints and to quantify the resource impact of alternatives to support management decisions. The bottom line is that cost analysis is required whenever resources are to be allocated or reallocated. Cost analysis is required whenever resources are allocated Unit I - Module 1

Benefits of Cost Estimating
Supports budgeting process by enabling you to: Integrate the requirements and budgeting processes Assess reasonableness of program budgets Effectively defend budgets to oversight organizations Quickly/accurately determine impacts of budget cuts on program baselines and associated functionality Enhances profitability and organization’s future business potential Uses established, repeatable methods Enables identification of potential pitfalls such as cost growth, schedule slips early in a program’s life Enables identification of future cost improvement initiatives 15 Ultimately, the cost estimate will translate into a budget input. Cost estimating helps formulate budgets by integrating the requirements and budgeting processes, and cost estimating documentation usually translates easily to budget documentation. For a government agency, accurate estimates assess the reasonableness of contractor proposals and program budgets and help the program office effectively defend budgets to oversight organizations such as OSD, OMB, and the Community Management Staff (CMS), and even to Congress. They also assist in quickly and accurately determining the impacts of budget cuts on program baselines and the program/system functionality. For a manufacturer, it is necessary to have accurate estimates of the costs required to accomplish a task before it has started to ensure maximum productivity and profitability. Estimates that are too high will keep the manufacturer from effectively competing in the market place. Estimates that are too low will not realize profits and face bankruptcy. An organization’s success in completing projects within a reasonable budget is a direct link to future business opportunities. Accurate estimates of the cost of a system or program provide the framework for selling the system or program at a reasonable profit and avoid two potential situations: “buying in” and pricing out of the market. “Buying in” refers to advertising a cost significantly under the actual amount of effort for the purpose of winning a piece of work as the lowest bidder. As the system is developed, it becomes apparent the estimate was too low and to recover, either the customer or developer is faced with paying for the overrun. If the estimate is too high, the developer can price itself right out of the market and no longer remain competitive. Accurate estimating, therefore, prevents the occurrence of these situations, leading to a solid reputation which enhances future business potential. Cost estimating uses established, repeatable methods to which estimates can be clearly traced, replicated, and updated. This contributes to the credibility of an estimate, which is crucial. (These and other qualities of a good estimate will be discussed shortly.) Accurate cost estimates can help management avoid potential pitfalls such as cost growth and schedule slips. Depending on the detail of the cost estimate, cost drivers can be easily identified with the finished product. Focus can then be paid to these cost drivers for the purpose of driving the costs down with cost improvement initiatives. Unit I - Module 1

Benefits of Cost Estimating
Provides for the identification and objective quantification of the impact of program risks (technical and schedule risks) Provides basis for evaluating competing systems/initiatives (cost/benefit analyses and AoAs) Enables proposal pricing and evaluation of proposals for cost reasonableness Captures cost impacts of design decisions to facilitate tradeoffs in CAIV/DTC/Target Costing Facilitates evaluation of the impact of new ways of doing business (e.g., in-sourcing vs. outsourcing, COTS vs. custom software) 9 13 19 14 16 In management of a program, it is important to identify and manage schedule and technical risks. Cost estimating aids in this process by objectively quantifying the impact of these risks (see Module 9 Cost Risk Analysis). Cost estimates are the basis for evaluating competing systems or initiatives via a cost/benefit analyses and/or Analysis of Alternatives (AoA). Comparative studies evaluate candidate solutions to a problem from a technical, performance, and cost standpoint before the decision maker has committed to a particular solution. These types of studies are discussed in Module 13 Economic Analysis. Proposals can be evaluated for cost reasonableness. For government agencies, cost analysis reduces the dependence on the development contractor estimate of program costs and protects the government from low ball estimates or “buy-ins” (see Module 14 Contract Pricing). Cost estimating should capture the cost impacts of both design decisions and business decisions. In the former case, trade studies are conducted throughout the development of a system when multiple design solutions exist and cost is often a critical selection criterion. This approach is formalized in disciplines such as Cost As an Independent Variable (CAIV), Design to Cost (DTC), and Target Costing. Estimates can also be used to evaluate the impact of new ways of doing business (e.g., in-sourcing vs. outsourcing, COTS vs. Custom software). These types of applications are discussion in Module 16 Cost Management. Unit I - Module 1

Cost Estimate Qualities
The characteristics of high quality cost estimates are: Accuracy Comprehensiveness Replicability and Auditability Traceability Credibility Timeliness 10 The characteristics of high quality cost estimates are accuracy, comprehensiveness, replicability/auditability, traceability, credibility, and timeliness. Estimates should demonstrate these quality characteristics in the following ways: Accuracy: Cost Estimating Relationships (CERs) are the result of regression analyses with good curve fits and minimal error bands, making them valid predictors of cost. Estimates are unbiased, not “low-balled” or overly conservative, but based on an assessment of most likely costs. Underlying data have been correctly normalized for technical baseline, and for inflation using appropriate guidance. Time phasing of the estimate is logical and accurate. Comprehensiveness: Estimate uses a Work Breakdown Structure (WBS) that is at a level of detail appropriate to ensure that cost elements are neither omitted nor double-counted. (WBS will be discussed in detail later in this module.) All cost-driving ground rules and assumptions are detailed in the documentation of the cost estimate. Replicability and Auditability: Estimate is presented in a WBS fully traceable to the system specification. Estimate is thoroughly documented, including source data and significance and goodness of fit statistics for CERs, clearly detailed calculations and results, and explanations for why a particular method or reference was chosen. A reviewer can follow the estimate process, repeat the calculations, and arrive at the same answer. Traceability: Data is traceable back to the source documentation. WBS structure is aligned to organizational structure performing the work. WBS element tasks are traceable. Without these characteristics, the estimate will not be credible, which is the single most important quality of a good cost estimate, and the benefits just discussed will be much harder to realize. Finally, an estimate must be timely. The best estimate in the world does no good if it is too late to provide decision makers the value insight they need. Unit I - Module 1

Limitations of Cost Estimating
Cost estimating cannot Be applied with cookbook precision Produce results that are better than input data Predict political impacts Substitute for sound judgment, management, or control Make final decisions Analysts develop cost estimating methodologies with an imperfect understanding of the technical merits and limitations of the item. Applying historical data in an estimate is always subject to interpretation. Because of future uncertainties, there are limitations in determining the degree to which reality varies from the plan. Realistically, the cost analysis process cannot: Be applied with cookbook precision (it must be tailored to the situation/program); Produce results that are better than input data; Predict political and non-cost impacts; Substitute for sound judgment, management, or control; or Make the final decisions (cost estimates only support decision-making). Unit I - Module 1

Cost Estimating Concerns
Support Critical Decisions May be difficult to quantify cost impacts of alternatives Cannot trade off non-cost variables Timeliness Schedule constraints on estimate delivery Estimate quality suffers with fast turnaround requirements Quick and easy access to historical data may not be possible Lower quality estimate limits utility to key decision makers Quality Definition of “good data” Adjustments to raw data may be made several times Inadequate documentation Undocumented or tacit knowledge Coordination Large number of organizations may be involved 16 18 4 Here we discuss concerns that the ideal execution of cost estimates will address and the pitfalls which may make reality fall short of that ideal. Cost estimates need to support decision making, but it may be difficult to quantify the cost impacts of various alternatives under consideration, whether due to difficulty in establishing CERs that are responsive to the right design parameters or in estimating new technologies or non-traditional approaches. Also, cost analysis cannot inherently trade off variables that cannot be directly related to cost. Such apples-and-oranges tradeoffs will require decision analysis techniques from operations research. These problems of “linkage” and “exchange rate” will be discussed in Module 16 Cost Management. Cost estimates must be delivered to decision makers in a timely manner, or they will be of no use (overcome by events (OBE)). However, if the schedule constraints on estimate delivery are too tight, estimate quality will suffer with too fast a turnaround, especially if historical data needed for the estimate are not readily available. If an estimate is of lower quality, its utility to key decision makers will be limited. Time constraints may also impact some of the concerns below. The quality of an estimate, as described previously, is reliant on both good data (input) and good documentation (output). Defining what constitutes “good data” and obtaining it is one of the most notoriously difficult problems in cost analysis (see Module 4 Data Collection and Normalization). You may only have access to secondary data which have been adjusted one or more times from the original raw data. If your estimate is inadequately documented, both its credibility and your preparedness for future estimates will suffer. Without good documentation, much crucial information, data, and experience and many estimating approaches may be lost, along with the tacit knowledge in the heads of analysts who could retire or leave the organization. Because costs for systems often cut across organizational boundaries, the data collection and estimate validation processes may involve coordination with a large number of organization, which requires time and energy. Unit I - Module 1

Cost Estimating Concerns
Consistency Estimates must track over time Estimates developed by other organizations must be based on same content and assumptions Historical data is not consistent between differing cost element or work breakdown structures Security/access Company-proprietary data Data classification/security Possible misuse of data A cost estimate must be internally consistent throughout a program’s lifespan, with a good track to previous estimates. An estimate must also be consistent in content and assumptions with estimates of the program developed by other organizations if these estimates are to be compared. (Because two estimates may not be directly comparable in practice, techniques for mapping costs between different structures or adjusting costs based on differing assumptions may be developed.) One barrier to consistency is that historical data is not consistent from one data source to another, or even within the same data source over time. One source of inconsistency in historical data is the use of differing cost element structures or work breakdown structures to collect the data. There may be reasons to restrict access to both the data you need to create your cost estimate and the resulting estimate when you are done. Some data may be considered proprietary. Within the national security arena, data may be classified as Secret or Top Secret, with a whole host of related gradations. These precautions to prevent misuse of data may make estimating a slower process. Unit I - Module 1

Types of Cost Estimates – Budget
Budget Estimate Estimate prepared for inclusion in budget to support acquisition programs Ensures project feasibility and attainable performance levels A reliable project cost estimate consistent with realistic schedules Used to establish baseline project definitions, schedules, and costs May or may not include risk 1 6 A Budget Estimate is an estimate developed to be used strictly for budgeting purposes in support of an acquisition program, in other words, to get authorization for funding. In theory, a "budget quality" estimate has a wider margin for error than other types of estimates. The fundamental purposes of a budget estimate are to ensure project feasibility and attainable performance levels, to develop a reliable project cost estimate consistent with realistic schedules, and to use it to establish baseline project definitions, schedules, and costs. A budget estimate would ideally include an assessment of risk, but depending on the organization, this may or may not be the case. Unit I - Module 1

Types of Cost Estimates – LCCE
Life Cycle Cost Estimate (LCCE) “Cradle to grave" estimate Includes research and development (R&D), production, operations and support (O&S), and disposal Commercial definitions are similar Life cycle is often confused with O&S but actually includes all of the above Should be performed as early in the life cycle as possible Estimate costs regardless of funding source AKA Total Ownership Cost (TOC) estimate 12 A Life Cycle Cost Estimate (LCCE) is a "cradle to grave" estimate that includes research and development (R&D), production, operations and support (O&S), and disposal costs. Commercial definitions are similar. Life cycle is often confused with O&S estimates but actually the LCCE covers all costs associated with the program for its complete life cycle. An LCCE should be performed as early in the life cycle as possible, even in proposal stages, as the opportunity to minimize the cost of ownership diminishes rapidly as the design and development of a system proceeds. LCCEs are generally required as supporting documentation for milestone decisions. The estimate covers costs regardless of funding source and is also known as a Total Ownership Cost (TOC) estimate. Unit I - Module 1

Types of Cost Estimates – ICE
Independent Cost Estimate (ICE) LCCE developed by an independent organization “True facts" assessment of what the program's most likely cost will be Provides an unbiased test of the reasonableness of the Program LCCE (PLCCE) Identifies potential budgetary excesses and shortfalls Reduces the cost risks associated with the project An Independent Cost Estimate (ICE) is an LCCE usually developed by an analyst outside the program or project office that tests the reasonableness of the program or project estimate. The ICE is developed using the same information employed by the program or project estimate, such as a Cost Analysis Requirements Description (CARD) or other baseline documentation, but employs an estimating methodology different from the one used to develop the program or project estimate. (CARDs will be discussed shortly.) It can be characterized as a "true facts" assessment of what the program's most likely cost will be and provides an unbiased test of the reasonableness of the Life Cycle Cost Estimate (LCCE). The ICE provides an independent source to critically examine the LCCE and identify potential budgetary excesses and shortfalls. The ICE reduces the cost risks associated with the project and provides supporting documentation at critical milestone reviews. “Independent” has many meanings when referring to cost estimates. The most stringent meaning is in Title 10 USC Section 2434 and involves an organization out of the chain of command of the acquiring agency. A looser meaning is an estimate done by an organization unbeholden to the program manager in funding or accountability. The loosest meaning is a separate estimate. In this case, we are using the term in its most stringent sense. Unit I - Module 1

Types of Cost Estimates – ROM & EA
Rough-Order-of-Magnitude (ROM) Very little specific information is known about the project The design effort has not begun Estimate uses ratios or factored historical information Used for feasibility studies and selection from among alternatives AKA “Quick Look” Economic Analysis (EA) Describes specific mission requirement(s) and lists specific alternative courses of action Framework for systematically investigating problems of choice Compares the costs and benefits associated with each alternative course of action 13 A Rough-Order-of-Magnitude (ROM) estimate is developed when very little specific information is known about the project. The design effort for the program or system has not begun, and the estimate is often based on ratios or factored historical information. A ROM is primarily used for feasibility studies and selection from among alternatives. It is also known as a “Quick Look” estimate. An Economic Analysis (EA) describes a specific mission requirement and lists specific alternative courses of action that will satisfy the requirement. An EA is a framework for systematically investigating problems of choice. The EA examines and compares the costs and benefits associated with each alternative course of action. Module 13 Economic Analysis is devoted to this topic. Unit I - Module 1

Types of Cost Estimates – AoA & ABC
Analysis of Alternatives (AoA) Evaluates the costs and benefits of different alternatives Shows advantages and disadvantages of the alternatives being considered Activity Based Costing (ABC) Accounting methodology that assigns all costs to activities Enables resources and overhead costs to be accurately assigned to products and services Assists in making decisions about pricing, outsourcing, capital expenditures and operational efficiency. 13 16 The Analysis of Alternatives, or AoA, evaluates the costs and benefits (i.e., operational effectiveness or utility) of different courses of action to meet recognized needs. AoA’s aid and document decision-making by showing the advantages and disadvantages of the alternatives being considered. Whereas an EA is more of a business case analysis, or BCA, where benefits can be quantified monetarily, an AoA (formerly known as Cost and Operational Effectiveness Assessment, or COEA within DoD) usually involves performance characteristics as well. These types of analysis are treated briefly in Module 13 Economic Analysis. Activity Based Costing (ABC) is an accounting methodology that assigns all costs to activities rather than directly to products or services. This enables resources, including costs previously treated as overhead, to be accurately assigned to the products and services that consume them. In order to correctly associate costs with products and services, ABC assigns cost to activities based on the use of resources. ABC then assigns cost to cost objects, such as customers or products, based on the use of activities. The resulting information assists in making decisions about pricing, outsourcing, capital expenditures, and operational efficiency. While ABC is not a cost estimate per se, ABC data is different enough from traditional cost data that we list it separately here. More information on ABC can be found in Module 16 Cost Management. Unit I - Module 1

Government Entities Responsible for Cost Estimating
OSD Cost Analysis Improvement Group (CAIG) Milestone review authority, has oversight of DoD service cost centers Intelligence Community CAIG (IC CAIG) Provides independent cost assessments to the Director of Central Intelligence (DCI) for selected IC programs Naval Center for Cost Analysis (NCCA) Prepares and briefs the Component Cost Analysis (CCA) to the CAIG Holds a reconciliation meeting prior to the formal CAIG meeting US Army Cost and Economic Analysis Center (CEAC) CEAC prepares CCA and briefs results to the CAIG Army Cost Review Board works with the Assistant Secretary of the Army (Financial Management) to develop the Army cost position briefed to the CAIG Air Force Cost Analysis Agency (AFCAA) Air Force Cost Directorate, SAF/FMCC, prepares the AF cost position, after reconciliation between the System Program Office estimate and the AFCAA’s CCA Here are listed the primary overarching cost monitoring agencies within the government. The OSD Cost Analysis Improvement Group (CAIG) is the milestone review authority for major DoD programs and has oversight of the DoD service cost centers (i.e., NCCA, CEAC, AFCAA). The Intelligence Community CAIG (IC CAIG) provides independent cost assessments (ICAs) to the Director of Central Intelligence (DCI) for selected IC programs. The Naval Center for Cost Analysis (NCCA) prepares and briefs the Component Cost Analysis (CCA) to the CAIG. The Navy holds a reconciliation meeting prior to the formal CAIG meeting. The Army Cost and Economic Analysis Center (CEAC) prepares the CCA and briefs the results to the CAIG. The Army Cost Review Board works with the Assistant Secretary of the Army (Financial Management) to develop the Army cost position briefed to the CAIG. The Air Force Cost Directorate, SAF/FMCC, prepares the AF cost position, after reconciliation between the System Program Office estimate and the CCA prepared by the Air Force Cost Analysis Agency (AFCAA). Other government organizations, agencies, and departments have their own oversight organizations. These include the Missile Defense Agency (MDA), the National Reconnaissance Office (NRO), the National Security Agency (NSA), the Federal Aviation Administration (FAA), and the National Air and Space Administration (NASA). The General Accounting Office (GAO) and Defense Contract Audit Agency (DCAA) play an auditing role. They don’t do before-the-fact cost estimating, but they are active second guessers, so be warned. Unit I - Module 1

Cost Products Cost Analysis Requirements Description (CARD)
Cost Estimate Estimate Documentation Completing our overview of cost estimating, we discuss the three basic cost products: the CARD, which gives us inputs to the cost estimating process (which we’ll present next); the estimate itself; and the accompanying documentation. Unit I - Module 1

Cost Analysis Requirements Description (CARD)
Detailed technical, programmatic, and schedule description Purpose of CARD Collect, integrate and coordinate technical, programmatic, and schedule information necessary to estimate the costs of a program Ensures that cost projections developed by the analyst are based on a common definition of the system and the acquisition program 2 The Cost Analysis Requirements Description, or CARD, is a detailed technical and schedule description of a program/system to be estimated. The CARD is intended to be comprehensive enough to facilitate identification of any area or issue that could have a significant cost impact and which therefore must be addressed by the cost estimator. It is also intended to be flexible enough to accommodate the use of various estimating methodologies. The purpose of the CARD is to collect, integrate and coordinate all the technical, programmatic, and schedule information necessary to estimate the costs of a program. Developing a CARD ensures that cost projections are based on a common definition of the system and the acquisition program. If the basis of the estimates is explicitly documented, it is easier to update the estimate and provide a verifiable trace to a new cost baseline as key assumptions change during the course of the project lifetime. The credibility of the cost estimate suffers if the analyst is unable to explain clearly the rationale used to derive each of the cost estimates. While the CARD is a DoD requirement for major programs, a CARD-like document should always be developed for an estimate for the reasons given above, regardless of whether it is for a government estimate or not. CARD is a DoD requirement for major programs but a CARD-like document should be developed for any estimate, government or private industry Unit I - Module 1

CARD Contents CARD includes: System Technical Description
Work Breakdown Structure (WBS) Predecessor System Description Manpower Requirements Risk Operational Concept Deployment Logistics Support Concept Training Acquisition Schedule Acquisition Strategy System Test and Evaluation (ST&E) Environmental Impact Analysis Track to Prior CARD The CARD features programmatic information such as program plan and purpose, and mandates or directives governing the program, and also includes: Detailed system technical description, key performance characteristics, replaced system, entity responsible for the system, system user, descriptions of hardware and software components including interactions, technical protocols or standards used, system architecture and equipment configurations, key performance parameters (KPPs), operational profile, reliability analysis, security requirements, and test and evaluation concepts/plans; Work Breakdown Structure (WBS) being used, determination of sufficiency of the WBS for cost estimating purposes, and whether the WBS accurately reflect the system baseline; A detailed description of predecessor systems, if any, reasons for replacing legacy system, detailed description of legacy system hardware and software components, technical protocols or standards used, Key Performance Parameters (KPPs), maintenance/logistics description, training description, and legacy phase out plan; Manpower requirements associated with system, how these compare to any legacy system, grade or salary levels, skill level requirements, and location of personnel; Program manager’s assessment of technical/performance, schedule, and cost risk; Operational Concept, including program management details, how and where the system will be operated, and platforms it will be installed on; Deployment details including platform/site deployment schedule, special preparations required, user preparations/training, rollout plan/FOU or IOC schedule, standard platform/site configurations, and transition plan between legacy and current system;… Unit I - Module 1

CARD Contents CARD includes: System Technical Description
Work Breakdown Structure (WBS) Predecessor System Description Manpower Requirements Risk Operational Concept Deployment Logistics Support Concept Training Acquisition Schedule Acquisition Strategy System Test and Evaluation (ST&E) Environmental Impact Analysis Track to Prior CARD Logistics Support details such as maintenance and sparing plan and handling of upgrades; Training plan, types of user training or certification, types of training or certification needed for system maintenance or administration personnel, training provider and location, seat requirements, and frequency of training; Acquisition Schedule and milestones; Acquisition Strategy including stated objectives of the program, any secondary program goals, details of vendor support, and contracting details; System Test and Evaluation plan, number of required tests, test schedule, testing entry/exit criteria, test bed locations and configuration, contingency plans; Environmental Impacts, if any, mitigation plan, and disposal concept; and finally, Changes from the prior CARD version defined and summarized including change pages with track changes and margin bars. The reader should be able to easily understand the differences without having to compare page by page. Unit I - Module 1

Cost Estimate Definition of a cost estimate
Cost estimate is an analysis of individual cost elements using established methodologies to project from data to estimated costs Various types of estimates can be developed Budget Estimate, LCCE, ICE, ROM Estimate, EA, AoA, ABC, etc. Developed using one or more estimating techniques Analyst should consider past and current actual data 2 The Cost Estimate is the analysis of individual cost elements using established methodologies to project from data and experience to estimated costs of a program or system. As previously discussed in this module, there are various types of cost estimates, including Budget Estimates, Life Cycle Cost Estimates, Independent Cost Estimates, Rough-Order-of-Magnitude estimates, Economic Analyses, Analyses of Alternatives, and Activity Based Costing. A cost estimate can be developed using one or more estimating techniques, which will be mentioned later in this module and discussed further in Module 2 Costing Techniques. When developing a cost estimate, the analyst should always consider past and current actual data relative to the system if such data is available. Unit I - Module 1

Cost Estimate Characteristics
Input rates Labor, materials, tooling, scrap, etc. Application of audited or negotiated direct and indirect rates Model structure Estimate developed to a varying level of detail depending on system and schedule Estimate is inflated and time phased Model execution Applies COTS or custom model May include sensitivity/risk analysis Some key characteristics or components of cost estimates include the following. Rates for labor, materials, tooling, scrap, etc., need to be provided, and audited or negotiated direct and indirect rates are usually applied. Rates can be affected by a variety of factors, from union demands to manufacturing shifts from one plant to another. It behooves you to get to know your rate development team. Depending on system maturity and scope and time and resources given to the estimator to conduct the estimate, the model structure may be developed at varying levels or detail. Depending on the time period covered by the estimate and the requirements and assumptions of the estimate, it may be both inflated, so that the dollars represent either the year they are spent or a base year or budget year, and time phased, indicating which costs are to be incurred in which years. As far as building and executing your model goes, you may choose to use commercially available software or a custom model, or both. Sensitivity and risk analysis can be included in the estimate to provide additional tools to management in decision-making. 9 Unit I - Module 1

Estimate Documentation
Why document the estimate? Provides reviewers with: Purpose of cost estimate Program background and system description Program Schedule Scope of cost estimate Ground rules and assumptions Robust and detailed documentation permits reviewers to follow estimate logic from assumptions to results Why document the estimate? Estimate documentation provides any reviewers (which will inevitably include you and your team in the future, by the way!) with: The purpose of the cost estimate, which states the reason for developing the estimate; whether it is an initial or updated prior estimate; if an update, identifies the prior estimate; the specific tasking and relevant correspondence; and cost estimating team composition. The program background and system description, which characterizes significant program and system aspects and status in terms of work accomplished to date, current position, work remaining, detailed technical and programmatic descriptions, major components, performance parameters, support concepts, contract types, acquisition strategy, and any other information that will assist the document user in fully understanding the system (see earlier CARD description for more detail). The program schedule, which should include the master schedule for development, production and deployment, as well as a detailed delivery schedule. The scope of the cost estimate in both time and space, describing phases (e.g., development, production, operations and support), specific time periods, and systems and processes encompassed by the estimate, and specific areas not addressed by the estimate and reasons why. The ground rules and assumptions, which list all technical and programmatic conditions that formed the basis for the estimate to assist management in understanding the conditions upon which the estimate was structured. When conditions are directed upon the estimating team, they become the ground rules by which the estimate will be conducted. In the absence of a firm ground rule, the estimator has the privilege of establishing assumptions which fill this void and allow the estimate to proceed. In exercising this privilege, the estimator must ensure that assumptions are not arbitrary but rather are founded on expert judgments rendered by experienced program and technical personnel. Estimate Documentation should be in sufficient detail to permit reviewers to follow the logic from assumptions to conclusion and to replicate or update the estimate at a later time. Specifically, Basis of Estimate (BOE) documentation for proposals must support audits or a firm may find itself in major legal trouble. Document not only for an external audience but for yourself! Unit I - Module 1

What should be documented? The data, data sources, and normalization procedures Labor rates and hours, content, and how they were developed Material requirements and subcontracts Methodology for any applicable cost improvement curves Details regarding the factors and cost estimating relationships (CERs) applied 4 7 The estimate documentation details the primary methods, techniques, rationale, and data used to generate each element of the cost estimate. What should be documented? All data used, the data source, and normalization procedures (see Module 4 Data Collection and Normalization). Direct and indirect labor rates as industry averages or organization-specific, their content, and how they were developed, and how the labor hours were developed. The material, purchased parts, and subcontracted items that are required and the development of their costs (e.g., vendor quotes, catalog prices, etc.). Methodology used to develop cost improvement curves (if applicable) and description of the curve in terms of slope, source, and relevance to the cost elements and program being estimated. Any unique aspects of curve application should also be included. See Module 7 Learning Curve Analysis. The basis, development, and/or source of all factors and cost estimating relationships (CERs) used, to include a description of how they were applied, their relevance to the program being estimated, and regression statistics (see Module 3 Parametric Estimating). 3 Unit I - Module 1

What should be documented? Details regarding the applied cost models including Relevance to the system/program Inputs/outputs Calibrations performed Inflation indices used and time phasing details Detailed description of judgments applied by estimator(s) Any details of risk and confidence analysis The conclusion(s) resulting from the estimate Appendices and appropriate references In addition to the data and methodology described on the previous slide, the estimate documentation should include: All pre-existing cost models used and their relevance to the estimate, along with complete details regarding any parametric inputs and outputs and any calibration performed to ensure the model is the appropriate estimating tool for the cost element and program; The specific inflation indices and computations used and the approach used to time phase the estimate; The logic and rationale that led to specific conclusions reached by the analyst regarding various aspects of the estimate (so called expert judgments); The details of all risk analysis conducted and how it formed the basis for reaching conclusions regarding estimate confidence (see Module 9 Cost Risk Analysis); In the case of an ICE, a conclusion expressing the cost estimating team’s determination regarding the reasonableness of the program office estimate; and finally, Appendices containing any other information pertinent to the cost estimate, and a reference list. 9 Unit I - Module 1

Cost Estimating Process
Work Breakdown Structure (WBS) Development Program/System Baseline Development Data Collection and Analysis Cost Element Methodology Estimate Development and Validation Results and Report Generation WBS Baseline Data Collection Data Analysis Methodology Validation Reports 8 We’ll now take a look at the cost estimating process, which we sketch out as a seven-step process: Develop a Work Breakdown Structure (WBS) Develop a program/system baseline Collect data Analyze data Develop cost estimating methodology for each cost element Put together and validate cost estimate Generate results and other required output, such as reports This linear progression is a somewhat simplified view of the real process but is close enough to give you a very good idea of how to go about developing your own cost estimate. Unit I - Module 1

Work Breakdown Structure (WBS)
What is a WBS? Common frame of reference for relating job tasks to each other and relating project costs at the summary level of detail Framework for specifying the objectives, labor, materials, and contracts of the system/program Structure defining the total program/system Detailed definitions of individual elements required WBS varies by program and project phase WBS  Cost Element Structure (CES) MIL-STD-881B previously the DoD standard Now MIL-HDBK-881B is guidance Excellent resource for WBS components/content WBS Baseline Data Collection Data Analysis Methodology Validation Reports 3 What is a Work Breakdown Structure or WBS? A WBS establishes a common frame of reference for relating job tasks to each other and relating project costs at the summary level of detail. It provides a consistent and visible framework for specifying the objectives, labor, materials, and contracts of the system/program. The structure is used to define the total program/system by providing detailed definitions of individual elements required (via a WBS Dictionary). The WBS does not have to be the same across systems or program phases. A WBS should be tailored for each system or program for the purpose of capturing all the idiosyncrasies endemic to each system/program. Additionally, elements of the WBS vary significantly by phase, with the development WBS differing from the production WBS, and the production phase WBS differing from the operations and support WBS. However, there is an advantage to establishing the master WBS for the life cycle of the program which includes each phase WBS as early on as possible and keeping consistent from then on. In some cost estimating circles, WBS is also known as the Cost Element Structure (CES). These terms can be interchangeable, although usually WBS relates to system/program from an engineering standpoint while CES is specifically related to the cost estimating process. If developing a CES, it should encompass all the elements of the WBS. The DoD developed MIL-STD-881B to provide the framework and instructions for developing a WBS. It has since transitioned (as of 1994) from the standard to guidance, now known as MIL-HDBK-881B but remains an excellent resource for both government and private industry for assisting in the development of WBS by outlining the contents and components that should be considered. Unit I - Module 1

Purpose of a WBS Displays and defines the system/program to be developed as a product-oriented family tree Includes hardware, software, support, and/or service elements WBS should encompass complete life cycle of the system/program CARD (or similar type of document) is the source for this program plan Establishes the physical work packages or elements and the activities within those packages that completely define a project Organizes the physical work packages into levels that can be developed into a summary WBS Baseline Data Collection Data Analysis Methodology Validation Reports The purpose of a Work Breakdown Structure (WBS) is to display and define the system/program to be developed or produced in a product-oriented family tree composed of hardware, software, services, data, and facilities that describe the program components at the level necessary to capture all elements of cost, and relates the elements of work to each other and the end product. It defines the program in terms of hierarchically-related product-oriented elements and each element provides logical summary points for assessing technical accomplishments and for measuring cost and schedule performance. It is important that the WBS encompass the system-level activities such as system engineering, specific builds, integration, fielding, and support of the system throughout its life cycle until it is removed from the inventory. The Cost Analysis Requirements Description (CARD), or similar type of document, is the source for this program plan. A WBS is the result of project/program planning that establishes the physical work packages or elements and the activities within those packages that completely define a project. It organizes the physical work packages into levels that can be developed into a summary. Unit I - Module 1

Purpose of a WBS Relates the work scope elements to each other and to the end product(s) Makes the relationships of the components clear and the relationship of the tasks to be completed (to each other and to the end product) clear Key to developing/tracking costs Provides financial reporting framework Assists in tracking the status of efforts, resource allocations, cost estimates, expenditures, and cost and technical performance WBS Baseline Data Collection Data Analysis Methodology Validation Reports Since the WBS divides the system/program into work packages, it can also be used to interrelate the schedule and costs. It separates elements of the program/system into its component parts, making the relationships of the parts clear and the relationship of the tasks to be completed - to each other and to the end product - clear. The work packages or their activities can also be used as the schedule's activities. This enables resource loading of a schedule, resource budgeting against time, and the development of a variety of cost budgets plotted against time. A WBS is also key to developing and tracking costs associated with the system/program by providing a consistent financial reporting framework. It assists in tracking the status of efforts, resource allocations, cost estimates, expenditures, and cost and technical performance, forming the basis for communication throughout the acquisition process and is the common link which unifies the planning, scheduling, cost estimating, budgeting, contracting, configuration management, and performance reporting disciplines, permitting managers to evaluate progress in terms of contract performance. Through the WBS, work is documented as resources are allocated and expended. Technical, schedule, and cost data are routinely generated for reporting purposes. The work breakdown structures summarize data for successive levels of management and provide the appropriate information on the projected, actual, and current status of the elements for which they are responsible. The WBS keeps the program's status constantly visible so that the program manager, in cooperation with the contractor, can identify and implement changes necessary to assure desired performance. Module 15 Earned Value Management Systems (EVMS) has more on WBS from the perspective of planning work packages and tracking project cost and schedule performance. (Note that the WBS used for EVM may not capture engineering effort performed by government system engineering or system integration personnel. You’ll need to capture these from other sources.) 15 Unit I - Module 1

Work Breakdown Structure (WBS) Early Development
WBS development should start early in the conceptual stages of the program Provides structure to the design requirements and functional architecture WBS evolves as system/program evolves Evolves through iterative analysis of the development strategy, objectives and requirements Define detailed technical objectives and specify work tasks for each WBS element WBS Baseline Data Collection Data Analysis Methodology Validation Reports A WBS should be developed early in the conceptual stages of the program to provide a structure to the design requirements and functional architecture of the system/program before the physical architecture is able to be defined. It is not until later phases that the system is described in terms of its specifications. As the system/program evolves, so does the WBS. The WBS evolves through iterative analysis of the program objectives, functional design criteria, program scope, technical performance requirements, proposed methods of performance (including acquisition strategy, drawings, process flow charts), and other technical documentation. As development progresses the detailed technical objectives are defined and specified work tasks are assigned to each element, and assigned for the resources, materials, and processes required to attain the objectives. The linkage between the specification requirements, the work breakdown structure, the statement of work, and the master and detailed schedules provides specific insights into the relationship between cost, schedule, and performance. This relationship allows all items to be tracked to the same work breakdown structure element. Therefore, the levels of the WBS should be related to these requirements and conform to its product-oriented family tree. Unit I - Module 1

Work Breakdown Structure (WBS) Continued Development
As the program/system matures Engineering efforts focus on system-level performance requirements and top-level specifications Major subsystems and configuration items are identified WBS continues to be defined at lower levels Eventually the total system definition is complete During production, maintain and update the WBS WBS Dictionary Develop WBS dictionary while developing WBS Should be routinely revised to incorporate changes and current status of the program throughout the program's life WBS Baseline Data Collection Data Analysis Methodology Validation Reports When developing a WBS, the engineering efforts throughout the life cycle will aid in defining the description of the system and its related levels. The work breakdown structure is developed out of the products which are considered to meet these requirements. As the program/project matures, engineering efforts will focus on system level performance requirements, specifically validating critical technologies and processes, and developing top level specifications. As these specifications are further defined, the work breakdown structure better defines the system in terms of its specifications and the configuration items that make up the system. Once the system concept is determined, then major subsystems and configuration items can be identified and lower level functions defined, so that lower level system elements can be defined. Detailed design activities are ongoing, and eventually the total system definition is complete. The levels of the work breakdown structure are directly linked with the detailed configuration of the system. During the production phase of the program, the system is produced as defined throughout the previous phases. Production usually includes the actual fabrication, modification, purchase, or some combination thereof, of hardware/software/firmware. The engineering efforts are actively involved in maintaining the configuration of the system being produced. The work breakdown structure is defined to the level appropriate for contract management and maintenance. When major modifications occur, the same WBS can be used; or, if the changes are substantial, a new work breakdown structure can be developed according to the same rules identified. As part of developing a WBS, the program manager will also develop a WBS Dictionary. The dictionary lists and defines the work breakdown structure elements. The WBS Dictionary can be based on the generic definitions in MIL-HDBK-881, made program specific to define the products being acquired. The dictionary shows the hierarchical relationship of the elements and describes each work breakdown structure element and the resources and processes required to produce it. It also provides a link to the detailed technical definition documents. The work breakdown structure dictionary should be routinely revised to incorporate changes and should reflect the current status of the program throughout the program's life. Any such changes should be documented for future reference. Tip: Dictionaries are often overlooked and are critical to use of a WBS Unit I - Module 1

Program/System Baseline Definition
Program/system baseline definition encompasses all the information of a CARD Process for defining program/system baseline Determine the programmatic scope of estimate Period to be estimated Phases estimated Determine the technical scope of estimate Program requirements Work not included Deliverables WBS Baseline Data Collection Data Analysis Methodology Validation Reports Program/system baseline definition is roughly synonymous with a CARD or CARD-like document. It includes ground rules and assumptions, and provides the basis for the cost estimate. It is key in enabling the translation of program requirements into a reliable and defendable program cost estimate. It describes the system’s important features, including required resources (such as hardware and personnel), program quantities, operational concepts, and milestones, and should correspond to EVMS baseline. At the beginning of each cost estimate, you must determine the programmatic and technical scope. The programmatic scope should indicate the window in the life of the program covered by the estimate, whether it includes the entire life cycle or a specific period. The phases (research and development, production, operations and support, disposal) covered by the estimate should also be determined. The technical scope should include all requirements for the program, including a detailed description of work to be performed, work not included in the scope, deliverables, any constraints or special conditions, sequence of events and any interdependencies, and milestones. It is critical to document the impact to the Project Baseline of any applicable contractual changes. Unit I - Module 1

Process for defining program/system baseline Develop detailed system technical description Include key performance characteristics, hardware/software components, architecture, configurations, reliability and security requirements, etc. Include previously developed WBS Develop detailed description of predecessor systems, if any Include technical details, reason for replacing, legacy hardware/software, phase-out plan, etc. WBS Baseline Data Collection Data Analysis Methodology Validation Reports Here, and on the following slides, we see that the program/system baseline needs to include the information previously discussed as part of the CARD. In addition to the current WBS, it should include any WBS that was previously developed. Unit I - Module 1

Process for defining program/system baseline Determine manpower requirements Include skills, salaries, location, etc. Incorporate technical/performance, schedule, and cost risk Determined by management and/or engineers Define the operational concept Include program management details, operation specifics, platforms Determine deployment details Include sites, schedules, special preparations, site configurations, transition plans, etc. WBS Baseline Data Collection Data Analysis Methodology Validation Reports Here are further steps in developing a program/system baseline, again collecting information that you would find in a CARD. Unit I - Module 1

Process for defining program/system baseline Detail logistics support Include maintenance, sparing, and upgrade plans Define the training plan Include types of training/certification, providers, locations, frequency, etc. Establish the acquisition schedules Include milestones, strategy, contracting details, etc. WBS Baseline Data Collection Data Analysis Methodology Validation Reports 7 Here are additional CARD components that also go into defining the program/system baseline. Unit I - Module 1

Process for defining program/system baseline Detail the system test and evaluation plan Include schedule, number of tests, criteria, locations, etc. Describe any environmental impacts Include disposal concept, mitigation plans, conditions, materials, etc. Maintain track to the original baseline As programs mature, define changes WBS Baseline Data Collection Data Analysis Methodology Validation Reports Here are the final CARD components that go into defining the program/system baseline. The system test and evaluation plan should include test schedule, number of tests, criteria, locations, subsystem tests, and subcontractor test review. Under the description of environmental impacts, the following should also be included: mitigation plans; disposal concept; environmentally acceptable alternatives; environmental conditions expected to be encountered during development, production, transportation, storage, and operation of the subsystem; hazardous, toxic, or radiological materials that may be encountered or generated during the subsystem’s development, manufacture, transportation, storage, operation, and disposal. The quantities of each hazardous material used or generated over the subsystem’s lifetime should be estimated based on the most current operations and maintenance concepts. Finally, programs can be re-baselined as they mature, but some track to the original baseline should be maintained. As with the CARD, the reader should be able to easily understand the differences between the current baseline and previous one without having to do a detailed page-by-page comparison. The track to a previous baseline may include a mapping to an old WBS. Unit I - Module 1

Data Collection and Analysis
Obtaining data Normalizing data Data Analysis Methods and process WBS Baseline Data Collection Data Analysis Methodology Validation Reports 4 4 5 6 8 Tip: These two steps of the process go hand in hand and are somewhat iterative. Data is the raw material for cost estimating. Data provides credibility and defensibility to all estimates, without which the estimate would be looked upon as merely a guess or at best the opinion of the analyst. It is critical to every estimate. Cost estimates are merely extrapolations of actual cost history data modified to reflect the future based on technical and programmatic data collected by the cost analyst. Data provides information on cost trends over a variety of related programs; insight into cost structures; and the information used to develop Cost Estimating Relationships (CERs), parametric estimates, and models. In addition, data, when properly analyzed, allows you to provide assessments of the statistical accuracy and fidelity of an estimate. These two crucial steps of the cost estimating process are discussed further in Module 4 Data Collection and Normalization and Module 5 Index Numbers/Inflation; and Module 6 Basic Data Analysis Principles and Module 8 Regression Analysis, respectively. Data collection and data analysis go hand in hand, and the two steps of the process are somewhat iterative. Data analysis may uncover the need for further data collection. Unit I - Module 1

Data Collection Understand total picture of estimating task
Intended use of the estimate Scope of the estimate Establish cost element structure Based on WBS Understand estimating techniques and data collection needs Identify proposed estimating technique(s) Identify potential data sources WBS Baseline Data Collection Data Analysis Methodology Validation Reports 4 There are five steps in the data collection process. They are: developing an understanding of the total picture of the estimating task; establishing a Cost Element Structure and boundaries around the estimate; understanding the estimating technique to be employed and its associated data collection needs; developing a data collection plan; and finally collecting the data. Successful execution of this plan should ensure that the right data are collected efficiently. Before the data is examined, the cost analyst must thoroughly understand what needs to be estimated. The analyst must understand the intended use of the estimate, and the scope of the estimate, both of which should have been made apparent in the program/system baseline definition. A cost element structure must be developed. This structure should be based on the WBS developed earlier. You may need to map existing data in different structures to the new structure. The analyst must understand the data requirements for the estimate. To understand data needs, the analyst must have an idea of the estimating technique(s) that will be employed in the estimate. The next step is to identify potential data sources for each component of the estimate. Keep in mind that different estimating techniques may require different data. This data collection process is explained in much more detail in Module 4 Data Collection and Analysis. Unit I - Module 1

Data Collection Develop data collection plan Collect the data
Ensure sources identified for all needed cost elements Identify alternative/backup data sources Identify sources for cross-checks Establish a timeline/schedule Collect the data Normalize the data Make data consistent and comparable Types of normalization include Cost Units, Sizing Units, Key Groupings, State-Of-Development Variables, and End Terms for Homogeneity WBS Baseline Data Collection Data Analysis Methodology Validation Reports 4 Next, the cost analyst must develop and execute a data collection plan. The plan should discuss capturing primary or secondary cost, technical, and programmatic data and ensure every cost element is covered, encompassing the full scope of the estimate. Primary and backup data sources should be identified and attempts should be made to identify data sources for cross-checks. In order to keep the estimating effort on schedule, a projected data collection timeline should be included with the plan. Finally, collect the data. Selecting and collecting appropriate data for the estimate requires sound analytic judgment, because the estimating process benefits from organized and structured data. For data to be usable in estimating, the data needs to be consistent and comparable to other data being used in the estimate. The process followed to do this is called Normalization. The types of data normalization include: by cost units; by sizing units; by special groupings such as mission application, by platform operating environment, and by recurring/non-recurring costs; by development state; and finally of end terms for homogeneity. Normalization should be done in an objective and reasonable manner, and not to make the data fit a desirable outcome. This data collection process is explained in much more detail in Module 4 Data Collection and Analysis. Unit I - Module 1

Data Analysis Scatter plot the data Calculate descriptive statistics
Develop visual depiction of the relationships in the data Calculate descriptive statistics For example, the means and CVs Look for outliers Points far from the center of the data Compare to history Standard factors, rules of thumb, other historical data WBS Baseline Data Collection Data Analysis Methodology Validation Reports 6 14 After thinking about the type of data you have (univariate, bivariate, multivariate, time series), scatter plot the data. Scatter plots provide the analyst with uncanny insight, a wealth of important information, and give a good idea of the relationships and trends present in the data. Next, calculate descriptive statistics for the variables of interest (presumably particular cost elements). Descriptive statistics characterize and describe the data, and should be calculated for each data group, especially the cost data for the element in question. This allows the analyst to see the central tendency of the data (most commonly captured by the mean) as well as the dispersion present (most commonly captured by the coefficient of variation, or CV). It is important to check data for outliers, points which fall far from the center of the data. Legitimate outliers may distort both descriptive and inferential statistics. If solid reasons exist, outliers can be removed from the data set. Finally, compare your descriptive statistics to standard factors, rules of thumb, or other historical data wherever possible. Don’t worry if you don’t understand all the terms presented here yet. There is more detail on this step of the process in Module 6 Basic Data Analysis Principles. Unit I - Module 1

Cost Element Methodology
Select estimating methodology that most reliably estimates program costs Primary cost estimating techniques or methodologies Analogy Parametric Engineering build-up Other methods Expert opinion Extrapolation from actuals WBS Baseline Data Collection Data Analysis Methodology Validation Reports 2 16 3 8 The three basic costing techniques or methodologies available when developing a cost estimate are analogy, parametric, and build-up. The analogy compares the cost of an item to be estimated to a similar item. A parametric estimate is a mathematical relationship based on historical data that relates cost to one or more technical, performance, cost, or programmatic parameters. Engineering build-up involves estimating costs at the lowest definable level, frequently making use of industrial engineering techniques such as time standards. These three methods will be discussed at length in the next module (Module 2 Costing Techniques). The parametric technique and the mathematics of regression behind it are the topics of Module 3 Parametric Estimating and Module 8 Regression Analysis, respectively. The estimator must determine which of these techniques is most appropriate for the task at hand based on the available data and phase of the program/system. Multiple techniques may be employed in an estimate but each technique has strengths and weaknesses, and varying degrees of applicability at different times during a program’s life cycle and for different levels of fidelity required for an estimate. Other methods or costing techniques include expert opinion and extrapolation from actuals. Expert opinion utilizes the subjective opinion of Subject Matter Experts (SMEs) to corroborate or adjust cost estimates. On the other end of the spectrum, extrapolation from actuals uses of data from prototypes or complete or incomplete units to project the cost of future units. When using different methods for different cost elements, make sure you don’t double count. A high-level CER may already capture detail in a build-up at a lower level. Unit I - Module 1

Estimate Development and Validation
Develop estimate with appropriate costing techniques Validate estimate Crosscheck with historical data for similar programs, another estimating methodology, or another model Compare estimate with industry “rules of thumb” Crosscheck proprietary models with Excel backups Document estimate while developing WBS Baseline Data Collection Data Analysis Methodology Validation Reports 17 Using the WBS to break down the system and applying the appropriate costing techniques, the estimator should begin developing the cost estimates for each of the WBS elements. Remember that when developing the cost estimate, more than one cost estimating technique may be used. For example, if a system involves a key piece of state-of-the-art equipment which has never been built before, a detailed engineering cost estimate would not be possible, since the system description is minimal and historical data does not exist. Therefore, an analogy would be applied in the cost estimates when historical cost data exist for one or more items that are similar to those proposed. Parametric cost estimates can be applied when relationships between cost and system characteristics can be authenticated. After the cost estimate is developed, it must be validated. The purpose of testing the estimate is to ensure reasonableness and completeness. The analyst should test key cost elements for sensitivity to the cost-estimating techniques used and to key ground rules and assumptions. Testing should include crosschecking the results with historical data from similar programs/systems, applying a different estimating methodology, and/or applying a different cost model (proprietary models versus custom model, e.g., in Excel). The estimate can also be compared to industry “rules of thumb.” These must be based on publicly available data, since proprietary data from another company may not be used. Finally, the analyst should conduct a cost risk assessment. Documenting the cost estimate as it is developed lends efficiency to its preparation and quality to its content. It is extremely difficult to recapture the rationale and judgments applied to the cost estimate after the fact. Unit I - Module 1

Results and Report Generation
Document the estimate Written justification of the estimate Well-documented estimate withstands scrutiny and increases credibility Provide sufficient information to replicate the estimate Develop results and report at appropriate level of detail Crisp and complete Easy to comprehend Address important details Convey competence WBS Baseline Data Collection Data Analysis Methodology Validation Reports 13 Cost estimate documentation provides a written justification for the cost estimate. The documentation clearly should be viewed as a substantive and professional effort. A well-documented cost estimate withstands scrutiny. If rigorous documentation and estimation procedures are followed, the credibility of the estimate increases. It is important to document all steps of the estimate process. A general rule of thumb is that the final product should provide sufficient information on how the estimate was developed so that other analysts could reproduce the estimate. The means by which each part of an estimate was produced must be fully explained. All steps in the development of a cost estimate must be documented, including definitions, ground rules, and assumptions. The estimator must state the source of all data and the processes used to analyze the data. In addition to the identification of the methods employed for each cost element, the documentation should address the rationale for that selection. When developing the cost estimate results and report, the level of detail presented will depend on the audience and estimate effort. The report must be crisp and complete; be easily comprehended, in a short period of time, by audiences unfamiliar with the estimate; address the important details of the estimate; and convey competence that underlies the estimate results. In proposals, for example, it is an excellent idea to develop an Executive Volume (say ten pages) to accompany the Cost Volume that summarizes the technical aspects of the program in layman’s terms, since many of the cost analysts evaluating the proposal may have had no exposure to the Technical or Management Executive Summary. If cost analysts (and auditors) have a better understanding of the system, they will much more easily follow the rationale and estimating methodology. Unit I - Module 1

Results and Report Generation
Conduct other analysis Cost As an Independent Variable (CAIV) Making performance and schedule a function of available resources Sensitivity analysis Tool for determining effect of changes for decision-making Risk analysis Analyzing technical, schedule, performance and other risks Used to adjust cost estimate Final result is defendable cost estimate for decision making WBS Baseline Data Collection Data Analysis Methodology Validation Reports 16 9 It is at this stage that other analyses can be conducted and incorporated in the final cost estimate, such as Cost As an Independent Variable (CAIV), sensitivity, and risk analyses. CAIV is a strategy that entails setting aggressive, yet realistic cost objectives when defining operational requirements and acquiring systems and managing achievement of these objectives. Basically, a program is made up of three parameters, schedule, performance, and cost. In a simplistic view, two of these variables must depend on the third. CAIV means making performance and schedule a function of available resources, namely cost. CAIV will be covered in greater detail in Module 16 Cost Management. Sensitivity analysis should be performed to include the cost of changing significant input parameters. Sensitivity analysis identifies key assumptions and variables within the estimate and determines how the effect of changes. Its value lies in the additional information and understanding it brings to bear on the decision. For decision makers facing an investment decision, sensitivity analysis is a tool for determining how changes in costs or benefits (e.g., due to forecast errors) affect the estimate. Risk analysis can also be a part of cost estimation. Today’s systems are increasing in technical complexity, and this increases technical risk. Increased technical risk increases the risk of schedule delays and cost overruns. Other areas of risk and uncertainty that should be analyzed after developing a cost estimate include pending negotiations, concurrency, schedule risk, performance requirements that are not yet firm, appropriateness of analogies, level of knowledge about support concepts, and critical assumptions. Risk analysis is used to adjust cost estimates, normally increasing the cost estimate—risk is added to initial point estimate resulting in a range or distribution of costs. This is discussed in further detail in Module 9 Cost Risk Analysis. After following the cost estimating process and applying the appropriate tools and techniques, the result is a defendable cost estimate that can be used by management in decision making. Unit I - Module 1

Cost Estimating Certification
So you want to be a cost analyst… Society of Cost Estimating and Analysis (SCEA) offers the important professional certification Certified Cost Estimator/Analyst (CCE/A) Combination of educational and job experience requirements (minimum 2 years) CCE/A exam ($85) More details on SCEA website ( under Certification Now that you’ve seen a brief overview of cost estimating and analysis, we hope you’re interested in the profession (if you’re not committed to it already). An important step in joining the profession is to take SCEA’s Certified Cost Estimator/Analyst (CCE/A) exam, for which this training is in large part designed to help you prepare. The exam is given both at the SCEA annual conference in June and at other locations through the year. Certain eligibility requirements must be met, including a minimum of two years’ job experience, and the application fee is $85. More details can be found by clicking the “Certification” link on SCEA’s web page. The Director of Certification is currently Bob Carlton. Unit I - Module 1

Summary Rigorous and systematic estimating leads to a better understanding of the problem Quality and accuracy depend on the expertise of the estimator Estimator must understand complexity, technology, and programmatic issues Don’t lose sight of the forest for the trees Leaving out components Double-counting components Forgetting integration costs Ability to reproduce the estimate Estimator must understand all estimating methods applied Rigorous and systematic estimating of a program/system leads to a better understanding of the problem. It improves management insight into the allocation of resources. The future is uncertain, and even our best estimate will differ from reality, but a high quality cost estimate is an invaluable aid in decisions about resource allocation. The quality and accuracy of an estimate depend on the expertise of the estimator, which is why this training is so important. You must understand all underlying complexity, technology, and programmatic trends and which populations you are dealing with for the new estimate. Don’t lose sight of the forest for the trees. You must avoid leaving out or double-counting components, and don’t forget about integration costs. The estimate and documentation must be developed in sufficient detail so as to be easily reproducible, and the estimator must understand the estimating concepts and methods applied. We continue on the road to that understanding with the next module, Module 2 Costing Techniques. Unit I - Module 1

Resources Cost Estimating Handbook, 2nd ed., Rodney D. Stewart, Wiley, 1991 Engineering Cost Estimating, 3rd ed., Phillip F. Ostwald, Prentice-Hall, 1991 DoD MIL-HDBK-881 “Work Breakdown Structure,” 02 Jan 1998 Listed here are a couple of seminal general texts on cost estimating and the aforementioned WBS reference. Unit I - Module 1

Resources – Agencies Oversight agencies NCCA Cost Analysis 101
CEAC, AFCAA, NCCA Cost Analysis 101 Budget/financial organizations GAO, OMB, USD(C), DCAA, Listed here are various government agencies associated with cost estimating and analysis. First, the service cost centers: Naval Center for Cost Analysis (NCCA), the Army’s Cost and Economic Analysis Center (CEAC), and the Air Force Cost Analysis Agency (AFCCA). The NCCA website has an excellent and very brief introduction to cost analysis, which is also referenced above. Finally, the General Accounting Office (GAO) and the Office of Management and Budget (OMB) provide financial oversight on behalf of the legislative and executive branches, respectively, while the Under Secretary of Defense (Comptroller) (USD(C)) does so for the Department of Defense (DoD), with the Defense Contract Audit Agency (DCAA) focusing on the activities of defense contractors. Unit I - Module 1

Resources – Regulatory
Title 10, United States Code, Section 2434 Independent Cost Estimates; Operational Manpower Requirements Clinger-Cohen Act of 1996 Title 10, United States Code, Section 2434 states that the Secretary of Defense may not approve the engineering and manufacturing development, or the production and deployment, of a major defense acquisition program unless an independent estimate of the full life-cycle cost of the program and a manpower estimate for the program have been considered by the Secretary. The Secretary of Defense prescribes regulations governing the content and submission of the estimates. The regulations require that the independent estimate of the full life-cycle cost of a program be prepared by an office or other entity that is not under the supervision, direction, or control of the military department, Defense Agency, or other component of the Department of Defense that is directly responsible for carrying out the development or acquisition of the program; and include all costs of development, procurement, military construction, and operations and support, without regard to funding source or management control. Additionally, the manpower estimate must include an estimate of the total number of personnel required to operate, maintain, and support the program upon full operational deployment; and train personnel to carry out the activities referred to in subparagraph (A). Unit I - Module 1

Title 10, United States Code, Section 2434 Independent Cost Estimates; Operational Manpower Requirements Clinger-Cohen Act of 1996 To streamline information technology, or IT, acquisitions and minimize layered approvals, the Clinger-Cohen Act of 1996 rescinded the Brooks Act, eliminating the delegation of procurement authority at the General Services Administration. It requires that major Federal Agencies establish the position of Chief Information Officer, or CIO, having clear authority, responsibility, and accountability for the Agency’s information resources management activities, and providing for greater coordination among the Agency’s information. The CIO’s job is critical to ensuring that the mandates of the Act are implemented to include ensuring that IT investments: • Support core mission functions, be undertaken because no alternative private sector or other government source can effectively support the function, and support work processes that have been redesigned or otherwise improved; • Are consistent with the Agency’s architecture that integrates work processes and information flows with technology to achieve the Agency’s mission and strategic plan; • Reflect a portfolio management approach where decisions on whether to invest in IT are based on potential return, and decisions to terminate or make additional investments are based on performance – much like an investment broker is measured and rewarded based on managing risk and achieving results; and • Reduce risk and enhance manageability by discouraging “grand” information system projects, and encouraging incremental, phased approaches. Unit I - Module 1

Title 10, United States Code, Section 2434 Independent Cost Estimates; Operational Manpower Requirements Clinger-Cohen Act of 1996 The Clinger-Cohen Act provides a number of significant opportunities for DoD to further streamline and reduce non-value added steps in the acquisition process. Among the most significant changes authorized by the Act is a test of the use of the Simplified Acquisition Procedures (SAP) for commercial items between the simplified acquisition threshold of $100,000 and $5 million. This should allow DoD to reduce its administrative costs and the overhead costs for DoD's vendor base for purchases of relatively low risk items. This change eliminated government-unique requirements previously cited by industry as a barrier to doing business with DoD. The Act also provides the authority for contracting activities to use SAPs for all requirements between $50,000 and the SAP while the government works to fully implement Electronic Commerce/ Electronic Data Interchange (EC/EDI). “The Clinger-Cohen Act also provides substantial relief from cumbersome processes that add little value, but significant cost to the acquisition of information technologies. The passage of the Act allows DoD to focus on the appropriate use and management of information technology resources. It should also reduce the amount of time an information technology acquisition takes by reducing the number and frequency of protests, while moving the Department in the direction of the use of sound acquisition strategies.” Unit I - Module 1

Resources – Policy DoDD , DoDI “Defense Acquisition System,” 23 October 2000 (incl Change 1, 4 Jan 2001) DoD R “Mandatory Procedures for MDAPs and MAIS Acquisition Programs,” 11 Jun 2001 DoDD “OSD Cost Analysis Improvement Group (CAIG)” DoD M “Cost Analysis Guidance and Procedures,” 11 Dec 1992 DoDI Economic Analysis and Program Evaluation for Resource Management DoDD applies to efforts to provide new, improved, or continuing systems, weapons and information systems. Based on validated needs. Does not address purchasing unless a part of the program, non-operational supplies or services. Top-level guidance for translating operational needs into programs, acquiring quality products, and organizing for efficiency and effectiveness This Directive provides mandatory policies and procedures for the management of acquisition programs. The Cost and Affordability section (4.5.2) reads: “Cost must be viewed as an independent variable, and the DoD Components shall plan programs based on realistic projections of funding likely to be available in future years. To the greatest extent possible, the DoD Components shall identify the total costs of ownership, and at a minimum, the major drivers of total ownership costs. Consistent with the Chairman of the Joint Chiefs of Staff guidance on requirements generation, the user shall treat cost as a military requirement and state the amount the Department should be willing to invest to obtain, operate, and support the needed capability over its expected life cycle. Acquisition managers shall establish aggressive but realistic objectives for all programs and follow through by working with the user to trade off performance and schedule, beginning early in the program (when the majority of costs are determined).” Unit I - Module 1

Resources – Policy DoDD , DoDI “Defense Acquisition System,” 23 October 2000 (incl Change 1, 4 Jan 2001) DoD R “Mandatory Procedures for MDAPs and MAIS Acquisition Programs,” 11 Jun 2001 DoDD “OSD Cost Analysis Improvement Group (CAIG)” DoD M “Cost Analysis Guidance and Procedures,” 11 Dec 1992 DoDI Economic Analysis and Program Evaluation for Resource Management Department of Defense (DoD) Regulation R establishes a management framework; describes translating mission needs and technological opportunities into acquisition programs; and establishes a general approach for managing acquisition programs. It authorizes Milestone Decision Authorities to ensure that programs meet cost, schedule, and performance goals. It sets forth mandatory procedures for Major Defense Acquisition Programs (MDAPs) and Major Automated Information System (MAIS) acquisition programs and, specifically where stated, for other than MDAPs or MAIS acquisition programs; serves as a general model for other than MDAPs or MAIS acquisition programs to include highly sensitive classified, cryptologic, and intelligence programs; implements DoD Instruction (reference (a)), the guidelines of Office of Management and Budget (OMB) Circular A-11 (reference (b)), and current statutes; and contains formats to be used to prepare various milestone documentation, periodic in-phase status reports, and statutory certifications. DoDD establishes the CAIG and describes its responsibilities as the cost-estimating advisor to the DAB. It also establishes requirements for preparing and presenting estimates to the CAIG. DoD M establishes guidance on the preparation of the "Cost Analysis Requirements Description (CARD),” guidance on the scope of the cost analysis, the analytical methods to be used in preparing cost estimates, and the procedures and presentation of the estimates to the cost analysis improvement group, and definitions for cost terms and how they relate to life-cycle cost categories, work breakdown structure elements, and appropriation. The CARD describes the complete program and is used as the basis for preparing life-cycle cost estimates, and will be discussed later in this module. DoD Instruction establishes policy and responsibility for conducting cost-effectiveness economic analyses of investment alternatives and authorizes the Defense Economic Analysis Council and its charter. The policies established apply to all DOD components and their investment decisions including the acquisition, leasing, conversion, upgrade, or expansion of real property. The DOD policy is to include economic analysis as an integral part of its planning and budgeting process and to ensure that specific guidelines are followed for budget items exceeding the investment-expense criteria established in DOD The instruction also gives procedures for economic analyses supporting decisions based on life-cycle costs. Unit I - Module 1

Cost Estimating Basics

Similar presentations

Presentation on theme: "Cost Estimating Basics"— Presentation transcript:

Similar presentations

About project

Feedback

Log in

Auth with social network:

Cost Estimating Basics

Similar presentations

Presentation on theme: "Cost Estimating Basics"— Presentation transcript:

Similar presentations

About project

Feedback