10.15. Relationship of Affordability and Should-Cost
For product development programs, some understandable confusion exists as to how to implement both “affordability as a requirement” and “should-cost,” particularly early in a program’s life cycle before Engineering and Manufacturing Development and Production. The two are compatible, but must be balanced differently across the product life cycle. The emphasis, prior to Milestone B approval for a program, should be on defining and achieving affordability targets. Past that point, the emphasis shifts to defining and achieving should-cost estimates.
10.15.1. Affordability as a Requirement
Affordability as a requirement directs that we establish quantified goals for unit production cost and sustainment coasts for our products, driven by what the Department or Component can afford to pay. These goals should be set early and used to drive design trades and choices about affordable priorities.
The Milestone Decision Authority (MDA) considers affordability at all major decision points of an acquisition program. In part, this consideration ensures that sufficient resources (funding and manpower) are programmed and budgeted to execute the program acquisition strategy. The MDA also examines the realism of projected funding over the programming period and beyond, given likely DoD Component resource constraints.
10.15.1.1. Affordability Analysis
Affordability Analysis is based upon the budgets we expect to have for the product over its life cycle and provides a design constraint on the product we will build, procure, and sustain. When the Department, i.e., the Milestone Decision Authority (MDA), establishes the affordability requirement,it represents a metric that captures the product’s expected capability against its expected (affordable) life cycle cost. From this point on, any future unit or sustainment cost increase above those levels, whatever the cause, must come back to the MDA and to the user to determine what requirements can be dropped to stay within the affordability requirement, or—if the program must be terminated. For further discussion of affordability and affordability assessments, see 3.2.
10.15.2. Should-Cost
Should-cost asks us consciously to do something different. It asks us to continuously fight to lower all of our costs, wherever that makes sense. Should-cost is a tool to manage all costs throughout the lifecycle, and it operates in parallel with the effort to constrain our requirements appetites in order to control the final product unit and sustainment costs. Should-cost is focused on controlling the cost of the actual work that we are doing and expect to do. In particular, should-cost estimates inform our negotiations with industry over contract costs and incentives. The should-cost approach challenges us to do our best to find specific ways to beat the Independent Cost Estimate (ICE) or Program Estimate (which should already reflect the affordability requirements) and other cost projections funded in our budgets (i.e., will-cost”), when we find sensible opportunities to do so. For example, should-cost does not mean trading away the long-term value of sound design practices and disciplined engineering management for short-term gain.
Should-cost can be applied to anything that we do and to any source of costs, including costs for services and internal government costs as well as contracted product costs. Should-cost targets are often stretch goals we expect our leaders to do their best to reach; we expect them to be based on real opportunities, but to be challenging to execute. Unlike affordability requirements, we do not expect them to always be achieved, but we do expect strong efforts to do so.
Should-cost and affordability can come into conflict early in programs, particularly before Milestone B, when an affordability requirement may have been defined based on expected budgets, but it is too early to define should-cost estimates for future production or sustainment of products because we have not yet defined the design. This is also the time when spending money on efforts to reduce future costs can have the biggest payoff. As a result, during the early stages of product development, the priority should be toward establishing affordability constraints and working to provide the enablers to achieve them in the ultimate design. In the early phases of programs, should-cost can still be constructively used to control program overhead and unproductive expenses and to generally reduce contracted development costs, but it should not keep us from making sound investments in product affordability. Prior to the pre-EMD Review or MS B, the ICE or Program Estimate for production and sustainment has not been finalized and any should-cost estimates for future production lots and sustainment would be premature. At that point, however, particularly if we are ready to ask for bids and negotiate low rate initial production prices, we need a should-cost estimate to inform negotiations. Once the requirements, design, and affordability goals are established and an CE or Program Estimate exists, then it is time to challenge the assumptions embedded in those analyses, formulate should-cost estimates for production and sustainment, and work to achieve those estimates
10.15.2.1. Annual Should-Cost Progress Reporting
On April 22, 2011, the Under Secretary of Defense (Acquisition, Technology and Logistics) directed the Component Acquisition Executives to deliver an annual progress report on their Should-Cost implementation.
The annual report must list all Major Defense Acquisition Programs (MDAPs) and Major Automated Information System (MAIS) programs for which should-cost estimates have been established. It should describe the challenges and successes in implementing these initiatives for each program from the perspectives of the respective Program Executive Officers and Program Managers, especially with regard to the programs the Services selected as models for Should-Cost implementation. The report should also describe the incentive plans the Service/Component has developed for Program Managers to reinforce and reward commitment to the Will-Cost and Should-Cost Management process.
Additionally, each Component should submit a Should-Cost datasheet for each MDAP and MAIS program that has established a Should-Cost estimate. The datasheet template is to be used as a guide and may be tailored to better present relevant information.
Questions regarding the annual Should-Cost Report may be directed to the Deputy Director, Resource Analysis in the Office of the Director, Acquisition Resources and Analysis.
10.15.2.2. Should-Cost Information for Defense Acquisition Board (DAB) Preparation
Information regarding the program’s should-cost efforts must be included in material prepared for presentation to the Overarching Integrated Product Team (OIPT), the DAB Planning Meeting, the DAB Readiness Meeting, and the DAB Review. See the current Should-Cost Template for guidance.
DAG Tutorial 
