Software Acquisition

AAF  >  Software Acquisition  >  Cost Estimation

Cost Estimation

How To Use This Site

Each page in this pathway presents a wealth of curated knowledge from acquisition policies, guides, templates, training, reports, websites, case studies, and other resources. It also provides a framework for functional experts and practitioners across DoD to contribute to the collective knowledge base. This site aggregates official DoD policies, guides, references, and more.

DoD and Service policy is indicated by a BLUE vertical line.

Directly quoted material is preceeded with a link to the Reference Source.

Reference Source: DODI 5000.87 Section 3.2.g

 

Before the execution phase begins, a cost estimate must be developed for the program.

  • The cost estimate will be developed in accordance with DoDI 5000.73.  The estimate should consider the technical content of the program described in the CNS, UA, acquisition strategy, and test strategy.
  • The initial cost estimate must be completed before entry into the execution phase and must be updated annually.
  • Where applicable, cost and software data reporting, to include software resources data reports, must be submitted in accordance with the policies and procedures in DoDI 5000.73.
  • Cost estimates for programs using the embedded pathway will align and integrate with those of the systems in which the software is embedded.

SWP Cost Estimating Characteristics

Reference Source: USD(A&S) Guidance

A good cost estimate should balance program flexibility with credibility.  It should comply with external policy, processes, and oversight demands while also adapting to the use of modern software practices.  Fundamentally, it should be:

  1. Timely. Cost estimates should support short decision timelines.  Acquisition programs using the software pathway are expected to move rapidly from planning to execution phase. A cost estimate that cannot inform key decision points or budget requests will be less useful.
  2. Iterative. Cost estimates should be developed with the available information and refined as more information is presented. It is impracticable for an initial cost estimate to capture the entire scope of the program and all lifecycle costs given the many unknowns such as length and growth potential of the program.
  3. Informative. Cost estimates should incorporate all available information including artifacts that may not be part of standard legacy practices such as program roadmaps and backlogs.
  4. Flexible. Cost estimates should be responsive to shifting operational needs and program priorities.  Software programs adopting modern software development approaches need an equally responsive cost estimating process.  Cost estimators should accept a higher level of abstraction than what might be normal for a hardware-centric program.
  5. Credible. Cost estimates should strive to achieve being as informative and flexible as possible while providing adequate justification to defend the proposed budget through the resourcing process.  This requires a reasonable level of documentation such as near-term release planning, contracted labor rates, number/composition of teams, product roadmap changes, retrospective reports, value assessments (as they become available), access to product backlog, and burnup/burndown charts.

Key Differences with Agile Cost Estimation

Cost Estimation for Traditional Development Cost Estimation for Agile Development
Exhaustive upfront analysis with slight adjustments over time Estimating Process Initial lower-fidelity baseline iteratively refined over time
Focused on lifecycle as dictated by predictive program plans Duration Focused on near-term roadmap to inform resourcing cycle
Milestone-Driven Update Timelines Regular updates as new information becomes available
SME involvement upfront; disconnected from execution Team Interactions Cost analysts tightly coupled with SMEs throughout program
Solution defined in detail upfront w/periodic updates Program Definition Near-term iterations defined with less fidelity for longer term objectives; regular updates
Large set of program data available; solid analogous programs to reference Cost Data Emerging set of program actuals; along with metrics used to inform future iterations
Focused on cost and schedule to meet fixed scope Uncertainty and Risk Analysis Focused on variable capability given cost and schedule
No benefits are realized until the end of development when the software is fielded Benefit Analysis Benefits are realized more often with each fielded iteration of software

Addressing Different Software Paths

Reference Source: USD(A&S) Guidance

The different paths on the Software Pathway can present different challenges.  An Application Path program is more likely to be independent of other systems or platforms, operating on a cloud-based infrastructure, supportive of a continuous development and integration pipeline and high deployment frequencies.  An Embedded Software Path program conversely is likely to have connections to another weapons system, have broader integration concerns, operate on infrastructure that emulates mission hardware, require more significant operational testing and have longer deployment frequencies.

 A cost estimator will have to account for these differences in the cost categories established and the risk calculations for the program. 

  1. Application Path: Provides for rapid development and deployment of national security system software running on commercial hardware, including modified hardware and cloud computing platforms.
  2. Embedded Software Path: Provides for rapid development, deployment, and insertion of upgrades and improvements to software embedded in weapon systems and other military-unique hardware systems.

Steps to Develop a SWP Cost Estimate

Reference Source: USD(A&S) Guidance

  1. Form the Team. It is important to identify cost estimators that have some familiarity with modern software development and are likely to have continuity on the program.  It is also important to identify the product management and software engineering SMEs that will be consulted for the initial estimate and throughout the program’s duration.
  2. Review the Program Information. SWP program managers and technical teams should have compiled some general program information to help inform the cost estimate.  This information should be provided in a tailored Cost Analysis Requirements Document (CARD) and supported by available documentation.  Even for a greenfield effort, the program should have decomposed requirements (preferably from a Capability Needs Statement) that form the initial product backlog and the near-term roadmap.  This information should serve to inform the initial cost baseline in terms of how many development teams will likely be required, the fixed infrastructure costs and the management overhead.
  3. Confirm the Work Breakdown Structure. CAPE has published different DD Form 2794 CSDR Standard Plans that are organized by commodity, including one for Information Systems-Defense Business Systems (IS-DBS).  However, there are other formats that have been developed by Service Cost Agencies (SCAs) that conform more closely to a software program leveraging modern software development methodologies. The cost estimator for the effort should review the available program information and determine which format will be most suitable.  For an embedded software path program, a modified version may be needed to account for unique costs such as specific certification events.
  4. Establish a Process. Each SWP program is likely to have unique aspects that will drive the processes to employ in conducting the cost estimate. For instance, some programs may have transitioned from another pathway and will have higher levels of data, more mature development teams, better understanding of fixed costs and deeper insight into the required content of future releases.  A greenfield program will be less mature and have much less insight.  Therefore, more advanced estimating techniques such as function points analysis might be used for a program that transitioned whereas capacity-based estimating may be the best approach for establishing an initial cost baseline for a new program.Estimate details
  5. Articulate the Assumptions. While cost estimating for hardware-centric efforts is often based on data from analogous efforts, the software domain can be more challenging in using this approach.  This challenge is even more amplified with DoD’s adoption of DevSecOps where the dataset is smaller for programs employing this new methodology.  Additionally, for a new software effort that is using the Software Pathway, the amount of available program information is limited, especially in the Planning Phase.  Therefore, it is important for cost estimators to document the assumptions made for the initial cost baseline.  Over future iterations, certain assumptions can be validated or abandoned.  As the GAO Agile Assessment Guide notes, “Well-supported assumptions include documentation of their sources along with a discussion of any weaknesses or risks.”
  6. Understand Potential Costs. Using the available program information and other insights gained for the program through discussions with the program management and technical teams, cost estimators should explore the different cost elements to gain an initial understanding of the potential costs.Software Cost Elements
  7. Craft the Initial Cost Estimate. Given the many variables mentioned, such as the likely immature state of the backlog prioritization and resulting roadmap, the estimating team will need to rely heavily on the development team’s expert opinion in crafting the initial cost baseline.  Estimators should assume a relatively constant pace of development, based on team steady state output and the number of teams employed.  This estimate should span a reasonable amount of time (5 years is a useful duration to inform the FYDP deliberations). The cost estimators should also consider various influencers in drafting the initial estimate and time-phasing it for near-term execution:
    •  Government’s Ability to Surge.  It is important to consider the government team’s ability to immediately surge a certain number of development teams and manage them effectively.  SWP guidance advises programs to start small and scale after demonstrating and delivering successful software releases. A greenfield software program that expects to immediately stand-up twenty functioning development teams in a matter of months may be challenged in doing so.  The cost estimating team should work with the program management team to ensure that the time phasing of resources is credible.
    • Operational Sponsor Expectations. While most acquisition programs attempt to posture themselves as critically important, there are often indications when the operational resourcing community places an effort in its top tier of priorities.  A software program that has senior leader advocacy is better placed to receive a budget allocation that maximizes the program’s abilities.  It also means that the operational command may be willing to accept greater risk in rapidly standing up a larger number of development teams despite the suboptimal productivity that is likely to result.
    • Code Reuse Considerations. When assessing the potential for software reuse, analysts should consider that code reused from other programs typically requires additional adaptation compared to code carried over from a previous release. Re-deploying unmodified software onto a new or upgraded platform can encounter integration challenges. Use of modern software methodologies can help mitigate some of these challenges but they deserve some consideration.

    “In summary, there is no doubt that focusing on the 20% of the features that give you 80% of the value will maximize the investment in software development and improve overall user satisfaction. After all, there is never enough time or money to do everything. The natural expectation is for executives and stakeholders to want it all and want it all now. Therefore, reducing scope and not doing 100% of the features and functions is not only a valid strategy, but a prudent one.” 

    – Standish Group

  8. Conduct Analysis. To help establish the foundation for future updates, the team should conduct sensitivity analysis to understand which cost drivers are most likely to affect the estimate.  Risk and uncertainty analysis should also be conducted to better understand the risk range around the assumptions which will impact the estimate as things change.   This is important to accomplish given the variations in estimating assumptions such as sizing metrics, velocity, number of iterations, and labor rates.
  9. Integrate the Team. Traditional programs often treat cost analysis as a separate activity, rather than as an integrated team endeavor, but cost estimation on an Agile program is a team-based activity.  Agile software development is a dynamic process and not all insights will be gained from data collection, which is why it is important that the cost estimating team be integrated into release planning activities.  Ideally, the cost estimator is tightly coupled with the systems engineers and development team as each Agile release is scoped, developed, and tested. The insights gained by participation in these discussions will help enable an integrated assessment of the operational and programmatic risks, team performance, cost drivers, and schedules to inform the next cost estimate update.

      Iteration is the Key.  GAO acknowledges that “it is proper and prudent to complete the estimate with the best available information at the time while also documenting the estimate’s shortcomings” so start with what you know and iterate on the cost estimate over time.  Use of modern software methodologies provide the opportunity for iterative feedback and provision of new data and regular updates to the cost estimate.

      Source: GAO Cost Estimating and Assessment Guide

      1. Iteratively Update. The cost estimating team should strive to maintain abreast of program changes through participation in release planning as well as in maintaining cognizance of updated SWP artifacts such as updated Capability Needs Statement, Product Roadmap, Performance Metrics and Value Assessments.  Estimates can be further informed by reviewing program burn-down charts and understanding the team’s historical velocity.  The cost estimate should continually be updated as near-term releases are completed and the next set of future releases become more defined.
      • Use Roadmaps. Intended to keep the team connected from the individual features (backlog, roadmap) to the higher-level objectives (CNS).  For estimators, roadmaps should assist in developing near-term estimates based on the goals of the program, should serve as the basis for engaging with the development team to garner SME input, and help identify when the number of teams required to meet roadmap is not consistent with available resources.
      • Use Performance Metrics. The minimum set of software pathway metrics may provide useful to cost estimators in understanding team productivity (deployment frequency metric), efficiency (lead and cycle time metric), quality (change failure rate metric), security posture (cyber responsiveness metric), and user perspective (value assessment summaries).  A downward trend in these areas should illuminate potential areas of risk in the program achieving its roadmap goals.  It could drive cost estimators to ask questions such as: Does the team need better tools?  Is there technical debt to burndown?
      • Use Value Assessments. This is a useful tool for estimators to determine if the program has appropriate near-term resourcing based on current projections. For instance, highly positive feedback would confirm that the team is operating effectively, delivering on an acceptable deployment frequency and providing the desired content.  Conversely, highly negative feedback may drive some pivots in how the team is organized or staffed, what the focus of their efforts should be and whether there is a need for additional resources.
      • Use Burn-Down Charts. These charts should help estimators track progress for each release aligned to the roadmap and show the amount of work on the project over time.  These charts can be used to inform estimate update cycles (as releases occur) and to help programs advocate for more resourcing if needed.
      • Monitor Velocity. Velocity is generally defined as the amount of work the team can deliver in an iteration measured as the sum of all the features completed in an iteration. Understanding this helps estimators gauge team productivity and assists with planning future work and assessing if the planned work can be realistically accomplished.
      • Integrating Processes. Unlike traditional hardware programs, software cost estimating becomes an integral part of the ongoing program that needs to both pull from and inform various SWP artifacts.

      Potential Cost Estimating Techniques for a SWP Program

      Reference Source: USD(A&S) Guidance

        Cost estimators should consider multiple factors (as discussed above) in selecting the best estimating approach (or combination) that will provide the best measure.  An approach used to develop the initial cost baseline can migrate to a more refined process over time as more is known about the program and the team’s performance.

        The general high-level approaches that can be employed are captured below.

        • Level of Effort Costing – Based on a specifically sized team working over a specific period or range of time.  Cost estimates based on level of effort address the question “What are the cost and duration estimated to deliver the desired outcomes with a fixed team size?” Cost is estimated based on the number of teams, the burn rate of the teams, and duration. This is a good approach when the budget is likely to stay steady and the requirements are incredibly dynamic.
        • Work-Based Costing – Calculated by the time and effort required to complete each work item. The work items can be organized as capabilities, features, etc.  Work-based costing places greater focus on the level of effort and cost associated with delivering each piece of work. The question addressed by this cost estimate is: “How much will it cost to deliver the desired work items (defined as capabilities, features or user stories)?” The cost estimates are organized around the time and effort required by the software team to deliver each feature. Cost estimates are based on the total of cost of all features implemented in each software release.  This approach can be useful for conducting near-term estimates and for informing the product roadmap resourcing.
        • Incremental Costing – This approach uses incremental delivery as the basis of estimate. Cost for the first increment of delivery is estimated and can then be used to inform longer term deliveries by comparing and extrapolating attributes of the first delivery to future deliveries. The first delivery could be standing up a software factory and/or developing the MVP. Estimating the costs of the first delivery are challenging as no execution data is available yet, but approaches such as level of effort, work-based, or analogy can be used. After the first delivery, information and data about team capacity can be collected and used to help refine future increment estimates.  This is a good approach to mature capacity-estimating techniques where productivity knowledge from initial MVPs better informs the future near-term releases.

        Some potential software sizing approaches that can be employed are captured below.  The SWP highly discourages the use of full function point analysis due to the overhead associated with using that approach and software lines of code sizing due to the challenges in using that with modern software development practices.

        Simplified Function Points.  The Department of Homeland Security Cost Analysis Division has made some advances in using this approach for software estimating.  The Simplified Function Point Analysis (SFPA) methodology combines functional software sizing (i.e., quantifying Function Points based on business function/transaction types, system interfaces, and requirements counts from high-level acquisition documentation) and functional software productivity (e.g., hours per function point) to determine Agile software development costs. The Simple Function Point Association, an international non-profit association formed in Italy to evolve and promote the method of Simple Function Points (SFPs), has published a SFP measurement manual, SFP counting templates, and examples of SFP counting.  The SFPA functional sizing methodology leverages the process of IFPUG’s ISO certified counting practices manual albeit in a more streamlined fashion.
        Reference and Additional Information

         Story Points.  Units of measure for expressing an estimate of the overall effort required to fully implement a product backlog item or any other piece of work. Teams assign story points relative to work complexity, the amount of work, and risk or uncertainty. Values are assigned to break down work into smaller pieces.  Over time, this helps teams understand how much they can achieve in a block of time and builds consensus and commitment to the solution.  It may sound counter-intuitive, but this abstraction is helpful because it pushes the team to make tougher decisions around the difficulty of work. Here are few reasons to use story points:

        • Each team will estimate work on a slightly different scale, which means their velocity (measured in points) will naturally be different.
        • Once there is agreement on the relative effort of each story point value, points can be assigned quickly.
        • Story points reward team members for solving problems based on difficulty, not time spent. This keeps team members focused on shipping value, not spending time.
        • Unfortunately, story points are often misused. Story points go wrong when they’re used to judge people, assign detailed timelines and resources, and when they’re mistaken for a measure of productivity. Instead, teams should use story points to understand the size of the work and the prioritization of the work.

        Reference and Additional Information

        Feature Estimation.  Many agile teams use the practice of relative estimation for features. Instead of estimating features across a spectrum of unit lengths, they select a few (three to five) relative estimation categories, or buckets, and estimate all features in terms of these categories. While the emphasis at this initial stage of planning is on speed and on the relative work per feature, at some point features must be broken down to their respective tasks and estimated more precisely. This happens during release planning and iteration planning. In general, feature estimates and task estimates serve different purposes:

        Reference and Additional Information

        Planning Poker: Planning Poker is an agile estimating and planning technique that is consensus based. To start a poker planning session, the product owner or customer reads an agile user story or describes a feature to the estimators.  Each estimator is holding a deck of Planning Poker cards with values like 0, 1, 2, 3, 5, 8, 13, 20, 40 and 100, which is the sequence we recommend. The values represent the number of story points, ideal days, or other units in which the team estimates. This technique reduces anchoring bias by asking teammates to use playing cards to submit their story points estimate.

        Reference and Additional Information

        T-Shirt Sizing: This is a unit of measurement for relative sizing techniques. Many teams use T-shirt sizes (S, M, L, XL) for each feature or story. With T-shirt measuring, the development team evaluates whether they think a story is extra-small, small, medium, large, extra-large, or double extra-large. By expelling the numerical score, the development team is allowed to think in a more dynamic manner about the exertion associated with a story. The sizes can, if necessary, be given numerical value after the estimation is finished.

        Reference and Additional Information

        SW Cost Analysis Requirements Description (CARD)

        Reference Source: USD(A&S) Guidance

          To help establish an initial cost baseline, SWP programs should provide the below information to the maximum extent possible to assist cost estimators.

          Program Description

          This section should outline the problem statement that drove the initiation of the program to provide important context to the cost estimator.  Was the program initiated to improve timeliness of decision-making using data analytics? Was it to improve the usability of the legacy system?  Was it to move capabilities to the cloud and reduce the hardware footprint?

          Any available details on the system’s key elements and strategies should also be included.  This includes the following information any of which can be provided separately in an excel spreadsheet (as applicable/needed):

          • Acquisition Strategy. Provide high-level details on the proposed strategy for the program.  How will the program be procuring the development talent for the program? Will a government-owned SW factory be used? Will a single vendor or multiple vendors be used for the development?  Will there be a lead system integrator?
          • Hardware/Hosting Infrastructure. Provide any details on the expected software development environment to help inform some of the expected fixed costs for the program.
          • Integration Lab Requirements. Detail any integration lab or mod/sim capabilities that will be needed to execute the program to adequately inform the additional costs that will be required to stand-up and/or maintain this infrastructure.
          • Software Licenses. Detail to the extent possible what licenses will be used on the program to help inform the costs associated with the development infrastructure. Will this be a more standard configuration using an existing enterprise services contracts or will this be comprised of a program-unique configuration?
          • Operational Environment. Provide any details about the operational environment that may drive costs for fielding capability.
          • Cybersecurity/Program Protection. Provide any details on expected cybersecurity activities outside of the DevSecOps pipeline and general cyber testing events that would drive program costs.
          • Reuse Strategy. Articulate if this is intended to primarily be a greenfield solution or is expected to reuse significant portions of existing code.
          • Expected Number of Users. Provide any details on the number of users expected to employ delivered capability by year at a minimum and by release if applicable.
          • Training Strategy. Provide any details on the planned training approach such as expected occurrence, length/type of events and what types of training materials will likely need to be developed and approved.
          • PMO Staffing. Provide any details on the expected staffing levels to inform the SE/PM costs.  Clarify if there will be any organic developers supporting the program.
          • Test & Evaluation. Articulate any high-level details on the testing approach, including operational acceptance, planned for the program to accurately capture expected costs.  The focus should be on events that will require external resources and costs outside of the normal suite of automated tools.

          Performance Characteristics

          This section should capture the key software capabilities needed to achieve the operational requirements. These should be high-level groupings of enduring needs which will be met over a series of software releases. If replacing a legacy system, provide any available details on expected additional functionality, any legacy retirement timelines, and alignment with other system(s), or support to upcoming operations).

          Example:  The XX program requires access to an integrated data environment with user-centered applications to improve readiness and reduce lifecycle costs. The system is required to provide capability 1, capability 2, capability 3, and capability 4. The system should minimize XX workload and improve the ability for operators to access courses of action to enable rapid decision-making.

          Interfaces

          This section should outline any major systems, services, and networks with which the software solution must maintain interoperability. Provide references to documents with any additional details of specific interfaces to help inform the cost estimator about the complexity of the system.

          Similar System

          This section should identify any existing systems the program office is aware of that would provide cost estimators with a point of reference for sizing and complexity.

          Metrics

          This section should describe the minimum set of high-level metrics planned for the program. Metrics should be able to address the frequency with which quality software is delivered into operation, user satisfaction with that software, and delivered quality, among other areas.  Metrics should measure key elements that would impose risks on the program to help the cost estimator understand what risk factors to monitor and potentially adjust in future updates.

          Program Roadmap

          This section should provide a summary of the vision and direction of expected product offerings over the next 18 months of the program.  It should describe the goals and features of each planned software iteration with the expectation that it will be dynamically updated as user needs change and priorities are adjusted.  While this artifact is not required until entry of the Execution Phase, any details that can be provided to the cost estimator will be helpful for them to understand the content and complexity of the program to develop the initial cost estimate.

          Template for SWP CARD

          Programs should use the DSO CSDR Template as a starting point but collaborate with their cost estimators to tailor out what is not applicable or infeasible to collect.

          Independent Cost Estimates (ICE)

          Reference Source: DODI 5000.73 Section 3.1.e

           

          CAPE will conduct an ICE for programs using the software acquisition pathway likely to exceed ACAT I or II thresholds before the program enters the execution phase (EP). CAPE may, in its discretion, delegate the authority for the conduct of the cost estimate to the SCA. At the discretion of DCAPE, the ICE may be updated during the EP. Estimates for software acquisition programs that do not exceed the ACAT II threshold must be conducted in accordance with the policies and procedures issued by the relevant SCA.

          SWP programs should contact their SCA at the earliest opportunity to request delegation for any higher-dollar value programs so that the program can begin collaboration with the appropriate cost estimating team (developing the Cost Analysis Requirements Document and establishing key assumptions).

          Preparation of ICE for Acquisition of Software

          Reference Source: DODI 5000.73 Section 3.4.h

           

          Figure 8 shows the typical timeline of events and deadlines to support the timely completion of an ICE for a software acquisition program. This timeline may be tailored as needed, depending upon the program and the information needed to best support the decision maker.

           

          • Concurrent with submission of an ADM documenting the decision to use the software acquisition pathway, the PMO will notify CA of an upcoming execution phase (EP) decision that requires either a DoD Component ICE or a CAPE ICE. If the start of the planning phase is less than 210 days before the EP decision, DCAPE will tailor the timeline to support the shorter time frame.
          • A kick-off meeting will be held no later than 180 days before the planned EP decision. Before the kick-off meeting, the SCA and CA will develop an agenda of information to discuss, to include requirements for the cost estimates, alternatives to consider, available data, and the assumptions on which the cost estimates will be based. A CA representative and SCA representative will co-chair the kick-off meeting. A PMO representative will brief a description of the program.
          • The PMO will prepare and deliver the draft CARD to CA and the SCA at or before the kick-off meeting. For joint programs, the CARD will include the common program agreed to by all participating DoD Components, as well as any unique program requirements of the participating DoD Components.
          • CA will make a decision whether to conduct a CAPE ICE or delegate the responsibility for the ICE to the SCA at least 165 days before the planned EP decision meeting. CA will issue a memorandum documenting its decision and upload a copy to the CADE. If CA decides to prepare the ICE, the program will follow the timeline in Figure 8 and procedures described in this section. If CA delegates the responsibility for the ICE to the SCA, the SCA will follow its policies in preparing the ICE and will deliver a copy of the final DoD Component ICE to CA within 7 days of the EP decision.
          • CA will provide feedback to the PMO on the draft CARD no later than 45 days after receipt of the draft CARD, usually at least 135 days before the planned EP decision.
          • No later than 45 days after receipt of the draft CARD, usually at least 135 days before a planned EP decision, if CA or the SCA determine that the CARD is insufficient, CA and the SCA will sign a memorandum to the PMO informing the PMO that the CARD is insufficiently developed to continue with preparation of the cost estimates. In this scenario, the planned EP decision may be delayed.
          • Following the kick-off meeting and continuing until the EP decision, the CA analyst and representatives from the SCA and PMO will conduct site visits and collect and review program data. During the same time, the CA analyst, SCA representative, and PMO representatives will have ongoing discussions concerning the cost estimating  strategies and methodologies used to develop all relevant cost estimates.
          • The PMO will deliver the draft final CARD to CA and the SCA at least 45 days before the EP decision. The draft final CARD should be in near complete form, with only minor changes occurring between its delivery and the delivery of the final signed CARD at least 21 days before the EP decision.
          • The PMO and SCA representatives will brief CA on the working level drafts of all relevant estimates available, at least 45 days before the EP decision. Following this briefing, the PMO and SCA representatives will provide CA any updates to the working level drafts of the estimates as appropriate or upon request.
          • The PMO must provide a final copy of the CARD, dated and signed by the program executive officer and program manager, to CA and the SCA at least 21 days before the scheduled EP decision and uploaded into CADE.
          • Representatives from CA, the PMO, and the SCA may meet approximately 7 days before the EP decision to compare and discuss the results of the draft cost estimates.
          • Before the EP decision, CA will issue its ICE report and upload a copy to CADE.
          • CA will brief the ICE to the decision authority either before or at the EP decision.
          • Following the EP decision, the decision authority will document his or her decision in an ADM, coordinated through the DoD Component offices responsible for financial management and requirements, that certifies the DoD Component will fully fund the program in the current FYDP or will commit to full funding during the preparation of the next FYDP.
          Timeline for Preparation of ICE for Software Acquisition

          Timeline for Preparation of ICE for Software Acquisition

          Programs should use the DSO CSDR Template as a starting point but collaborate with their cost estimators to tailor out what is not applicable or infeasible to collect. 

          Note: If the below video(s) show a “Website Blocked” banner, try accessing the video via a non-DoD network. No sensitive content is contained in this video. Current DoD network policies to conserve bandwidth may be impacting the ability to view this video.