Release: 2014 / US Department of Defense



The Department of Defense (DoD) must continue to improve product support, with a specific focus on increasing readiness and enabling better cost control. In 2008, the Office of the Assistant Secretary of Defense for Logistics and Materiel Readiness (ASD(L&MR)) established a group of senior government, industry, and academia representatives called the Product Support Assessment Team (PSAT) to drive this effort. In November 2009, Dr. Ashton Carter, Under Secretary of Defense for Acquisition, Technology, and Logistics (USD(AT&L)), approved and signed the Weapon Systems Acquisition Reform Product Support Assessment (WSAR-PSA) report and its eight integrated recommendations to improve life cycle product support. One of the eight recommendations included clarifying and codifying policies and procedures pertaining to the use of analytical tools, including business case analysis (BCA) in the life cycle product support decision making process.

In addition to the PSAT effort, this DoD Product Support BCA Guidebook supports Dr. Carter’s November 2010 memorandum on “Better Buying Power” by laying out a uniform methodology for accurate, consistent, and effective support of value-based decision making, while better aligning the acquisition and life cycle product support processes. The guidebook fulfills the need to standardize the DoD BCA process used to conduct analyses of costs, benefits, and risks.

A senior team of system engineers, logisticians, acquisition experts, and financial experts from the Services, Agencies, Industry, and Academia embedded their broad knowledge and experience into this guidebook to help BCA practitioners serve their primary customers, the Warfighter and the Taxpayer. This guidebook is a living document that will continue to be updated with new best practices and methodologies, and provides overall guidance for conducting a Product Support BCA. This guidebook should be used in conjunction with other analytical tools and guidance and can be further tailored for specific types of BCAs.

Alan F. Estevez

Principal Deputy Assistant Secretary of Defense
for Logistics and Materiel Readiness


The guidebook was updated in March 2014 deleting Appendix C and to reflect current law, DoD instructions, and Better Buying Power 2.0.

Table of Contents


1. Introduction and Purpose 6

1.1. Introduction 6

1.2. Guidebook Purpose 7

2. People 8

2.1 Audience 8

2.2 Sponsor 8

2.3 Owner 8

2.4 Functions, Roles, and Responsibilities 9

3. Data Management 11

3.1 Data Management Introduction 11

3.2 Recommended Authoritative Data Sources 11


4. Product Support BCA Outline 13

4.1 Executive Summary (Product Support BCA) 13

4.2 Introduction (Product Support BCA Main Body) 14

4.3 Desired Outcomes and Requirements 16

4.4 Assumptions and Methods 17

4.5 Alternatives 20

4.6 Mission and Business Impacts 24

4.7 Risk Analysis and Mitigation Plans 30

4.8 Sensitivity Analysis 33

4.9 Conclusion 33

4.10 Recommendations 34

5. Governance, Validation, and Approval 36

5.1 Governance 36

5.2 Validation and Approval 36

6. Documentation 37

6.1 Lessons Learned and Best Practices 37

6.2 Documentation 37

6.3 Revalidation Analysis of Product Support Strategy BCAs 37

Appendix A – Product Support BCA Checklist and Phases 38

A.1 Product Support BCA Checklist 38

A.2 Product Support BCA Process Flow 42

Appendix B – Guidelines for Capturing Cost 43

Appendix C – Product Support BCA Timeline and Life Cycle 45

Appendix D – Analytical Tools 48

Appendix E – Glossary of Terms 105

Appendix F – Acronyms 108

Appendix G – Product Support BCA Policies, Statutes, and References 111

1. Introduction and Purpose

1.1. Introduction

A Business Case Analysis (BCA) is a structured methodology and document that aids decision making by identifying and comparing alternatives by examining the mission and business impacts (both financial and non-financial), risks, and sensitivities. BCAs may be somewhat different from other decision support analyses through their emphasis of the enterprise wide perspective of stakeholders and decision makers and assessment of the holistic effects impacted by the decision. Other names for a BCA are Economic Analysis, Cost-Benefit Analysis, and Benefit-Cost Analysis. Broadly speaking, a BCA is any documented, objective, value analysis exploring costs, benefits, and risks.

Product Support Manager responsibilities relative to cost-benefit analyses are spelled out in 10 U.S.C. § 2337, DoDI 5000.02 and the Defense Acquisition Guide. Prior to each change in the Product Support Strategy or every five years, whichever occurs first, the program must revalidate any business-case analysis performed in support of the product support strategy.

A Product Support BCA should aid the decision maker (PM, PEO, SAE, or others as applicable) in making an informed the product support strategy decision. It should be tailored to inform the PM of costs, benefits and risk implications of the strategy alternatives being considered. It should reflect the appropriate level of analysis needed to provide a fair assessment of the proposed alternatives.

A BCA concludes with a recommendation and associated specific actions and an implementation plan to achieve stated organizational objectives and desired outcomes. One principle application of this guidebook is to assist the Product Support Manager (PSM) in identifying the product support strategy that achieves the optimal balance between Warfighter capabilities and affordability.

A BCA does not replace the judgment of a decision maker. Rather, it provides an analytic, standardized, and objective foundation upon which credible decisions can be made. A Product Support BCA should be a comprehensive, fair, and accurate comparison when evaluating multiple alternatives. It should take into account broad Department wide impacts and context throughout the analysis. The PSM prepares a Product Support BCA for major product support decisions, especially those that result in new or changed resource requirements. A Product Support BCA helps leadership with significant investment and strategic decisions across all applications of Product Support. For example, Product Support BCAs may support decisions on whether or not to transform the product support strategy or business operations, develop a web-based training curriculum, or retire an asset.

1.1.1. Product Support BCA Structure

A BCA has three major elements: the purpose, process components, and quality foundation (see Figure 1). The BCA purpose identifies the problem statement, objectives, and metrics. The items of this element should clearly annotate what issue the BCA is attempting to solve and how success will be measured. The BCA process components are those subsections of the BCA that directly execute and report on analytical actions. The third major BCA element contains the supporting foundation of the BCA that directly affects the quality and completeness of the analysis. Background research, due diligence, governance, and data management and control underlie and prop up the entire process. Governance represents the oversight and enterprise wide context that helps to steer the analysis throughout the process. The three elements work together to ensure the BCA targets the relevant subject matter, credibly analyzes and reports the results, and integrates into the organization’s mission and leadership’s vision.

Figure 1: BCA Elements

Figure 1: BCA Elements

1.2. Guidebook Purpose

The purpose of this guidebook is to provide a standardized process and methodology for writing, aiding decision making, and providing analytical decision support for a Product Support BCA. This guidebook is organized into two sections:

  • Introduction to the Product Support BCA; providing the background, people, roles and responsibilities, and data management involved in creating a Product Support BCA
  • The Product Support BCA Process; providing the method of preparing a Product Support BCA, including research, data analyses, and delivery of a Product Support BCA report

2. People

The People section provides guidance on assembling a Product Support BCA team. It addresses involving the right stakeholders at the kickoff meeting and assembling the Governance structure and board. A Product Support BCA is a team effort undertaken by experienced participants across a wide range of specialties (See Table 1). Many BCAs have an expert analyst as the team lead specific to the effort. This does not relieve the PSM of his/her statutory position. Each position identified in this section should be filled by highly competent and dedicated personnel who are given the resources, time, and money to fully and properly perform the tasks required. From the initial stages of accomplishing the background research and gathering the data, through the final stages of staffing a BCA for senior Department decision makers, it must be expected that conducting a BCA requires significant effort by all those involved.

2.1 Audience

This guide was designed for the Product Support Manager (PSM) as the primary user while also providing valuable insight to budget and business managers, senior decision makers, approval authorities, and stakeholders.

2.2 Sponsor

The sponsor is the primary decision maker. Depending on the size, scope, and sensitivity of the decision, it may be the Milestone Decision Authority (MDA), Program Executive Office (PEO), etc. The sponsor assigns the owner and uses BCA recommendations and findings to assist in decision making. The sponsor may help identify and agree to the uses of assumptions, constraints, and other metrics, most notably the weighting of factors’ importance.

2.3 Owner

The owner of the Product Support BCA is most often the program office. The program office employee responsible for any Product Support Strategy BCAs is the PSM. The Program Manager (PM) is the primary executer of the actions and recommendations derived out of the BCA. Within the program office, the PSM has the responsibility to plan, develop, implement, and execute the Product Support Strategy. Changes to the Product Support Strategy must be informed by a Product Support BCA.

The PSM estimates the cost of conducting and obtains resources necessary for accomplishing a Product Support BCA. To avoid a biased analysis to the maximum extent possible, the PSM should employ an objective, independent team to execute the analysis and provide the BCA recommendations. The PSM should ensure objective analysis through maximizing structured analysis in a transparent manner.

2.4 Functions, Roles, and Responsibilities

Team effort is required to ensure the accuracy of analyses and viability of resulting recommendations. It is imperative that all program management team members and stakeholders understand individual roles and team efforts related to executing Product Support BCAs effectively.

There is a critical due diligence period when the PSM assembles a team to plan the Product Support BCA. This effort includes the timeline, scope, assembly of the key stakeholders, etc. After this initial planning is complete, but before beginning the Product Support BCA, the team should meet with all the necessary stakeholders and SMEs. During this kickoff meeting, the team should establish the intended outcomes, constraints, and methodology for conducting the Product Support BCA. Assembling the right stakeholders from the beginning is critical to the success of the Product Support BCA process and final outcome.

Table 1 describes the functions or roles of the individuals that should or may be involved throughout the Product Support BCA process. The levels of involvement will vary according to the type of Product Support BCA being conducted, the stage of the Product Support BCA writing process, and the organization.


Responsibility Description


Impacts on the Warfighter are the primary considerations of the Product Support BCA. As the user of the weapon system, the Warfighter is typically the ultimate beneficiary of the Product Support BCA. The Warfighter provides the performance requirements for the weapon system which are ultimately taken into account for the support strategy. The Warfighter also provides feedback on the system and support strategy.

Program Manager (PM)/ Product Support Manager (PSM)

The PSM, working for the PM, is responsible for the Product Support BCA. This includes overseeing the team that is conducting and writing the sections of the Product Support BCA. These roles are also defined by statutes.[1]

Governance Body/ Approval Authorities

Approval authorities provide directional guidance and concurrence throughout the Product Support BCA process on such matters as the problem statement, assumptions, constraints, data sources, risk mitigation strategies, etc. The governance body has the responsibility to ensure that the Product Support BCA strategy integrates an enterprise wide perspective. Normally, the governance board is determined by the impacts of the decisions being made, as well as, the PM’s chain of command.

Business Analyst (Financial, Cost, and Budget analyst)

The business analyst has the analytical training and skills to conduct the majority of the Product Support BCA analysis. This includes the financial/cost analysis section, the analytical methodology for the Product Support BCA, and the conclusions and recommendations. The analyst conducts the funding analysis and budget plan with regards to the recommended Product Support BCA approach.

Logistician (Requirements, Logistics, and Supportability Manager)

The logistician is responsible for ensuring the sustainment strategy, requirements, and performance measures are addressed in the Product Support BCA. Additionally, this person is responsible for completing the mission impact section, including assisting with the non financial analysis of the Product Support BCA.

Systems Engineering and Engineering Disciplines

This person validates that the alternatives under consideration are technologically plausible and comprehensive in nature to support the BCA’s purpose.

Product Support Integrator (PSI)/Product Support Provider (PSP)

The PSI and PSP may provide subject matter expertise and consultation with regards to the attributes of the product support strategies and alternatives that are being explored in the Product Support BCA. The PSI is an entity performing as a formally bound agent (e.g., contract, Memorandum of Agreement, Memorandum of Understanding) charged with integrating all sources of support, public and private, defined within the scope of product support arrangements to achieve the documented outcomes.[2]

Data Manager

The data manager is responsible for maintaining and keeping historical records of past Product Support BCAs. These records include research, performance outcomes, cost estimates and methodology, sources of data, etc. as recommended in the GAO report GAO-10-717 on O&S costs. Historical records maintenance is critical to future analysis, variance analysis, and future iterations of the Product Support BCA.

Legal and Contracts

The legal and contracting officers and managers review the Product Support BCA as an advisor concerning compliance with laws and regulations.

Subject Matter Experts (SMEs)

SMEs are recognized experts in the specialized knowledge applicable to the analysis and preparation of the Product Support BCA components (e.g., cost estimation, system requirements, risk analysis, etc.) This includes other relevant stakeholders that provide inputs to and impacts on the Product Support BCA analysis.


This role is as required. The Sponsor or Owner makes the decision to bring this role into the Product Support BCA process.

Table 1: Roles and Responsibilities Table

3. Data Management

3.1 Data Management Introduction

3.1.1 Data Collection

Early in the BCA, the program office should discuss and plan for locating, collecting, verifying, and using data within decision support products. The data collection should include both benefit/non-monetary factors, as well as financial data. The PSM should work very closely with the product support business analysts, logisticians, and contracting officers to ensure that the proper data is contracted for and executed from the beginning of the life cycle of the program. Likewise, due diligence for data collection and availability must be ensured from appropriate government sources. Not collecting the correct functional and cost data can reduce the effectiveness of the BCA and hinder, delay, or inhibit later decision making efforts. As the data is collected, the program office should execute a cohesive plan for archiving and efficiently dispersing the data to applicable stakeholders.

3.1.2 Access to Data

The program office should understand and specifically dictate from the beginning how the data will be made available for the PSM to conduct the Product Support BCA. This should be discussed and agreed upon by all parties following the ground rules for managing intellectual property. For instance, will the data be provided via a web-access system, MS Excel, or verbally? Will it be provided in hard copy or electronically? If it is provided electronically, will it be in Excel or PDF? MS Excel is highly recommended not only for program office and analytical purposes, but also for higher level agency review and oversight.

3.2 Recommended Authoritative Data Sources

3.2.1 Authoritative Data Sources

The governance board should also approve the authoritative data sources from which the Product Support BCA team will conduct the financial and non-financial analysis. This is a critical component to the Product Support BCA and repeatedly cited as a weakness in existing Product Support BCAs by numerous GAO reports.[3] The criteria for the authoritative data source should be: accurate, comprehensive, consistent, timely, available, and accepted. This approval step may occur numerous times in the course of the BCA process as data sources are revealed.

Use the template below as an example for documenting data sources.

Data Element



Contact Info

Date Data Generated

Used for. .

Example 1

Database 1

Person 1/Office


Date data was created

Data element used to calculate. . .

Example 2

Database 2

Person 2/Office


Date data was created

Data element used to calculate. . .

Example 3

Database 3

Person 3/Office


Date data was created

Data element used to calculate. . .

Table 2: Data source table

3.2.2 Data Control and Configuration

In addition to collecting quality and relevant data, the PM should encourage open book style accounting for both the organic and contractor support. PSMs should seek out and use information technology tools to automate and reduce the level of effort required to collect and analyze programmatic data. This ensures that the BCA team is able to access relevant information and compare like data points.

As a general note, research and data management is the responsibility of all the appropriate roles involved in conducting the BCA. Each functional area lead is the expert for their particular requirements and sources of data to perform their respective analyses. As such, each functional representative should spearhead the solicitation and configuration control of Product Support BCA data in conjunction with the data manager and other members of the BCA team.

Make efforts to only use non-proprietary methods in a Product Support BCA and ensure that all data and processes will be available to the program office so that subsequent iterations of the BCA may be accomplished or updated by the government or a contractor other than the original creator of the BCA. The government will have the rights to fully use the data and processes contained in a Product Support BCA in any manner and for any purpose the government deems proper, including but not limited to executing BCA recommendations and/or follow-on analyses.


4. Product Support BCA Outline

The DoD Product Support BCA outline represents the standardized DoD Product Support BCA report. While a Product Support BCA is not executed in this linear format,[4] the report should follow this generic outline with tailoring for specific circumstances.

The outline of the DoD Product Support BCA is as follows:

1. Executive Summary

2. Introduction

i. Problem Statement

ii. Background

iii. Scope

3. Desired Outcomes and Requirements

i. Desired Outcomes

ii. Requirements

4. Assumptions and Methods

i. Ground Rules and Assumptions

ii. Analysis Methods, Tools, and Rationale

iii. Evaluation Criteria

5. Alternatives

i. Current Baseline/Anticipated Initial Support/Status Quo

ii. Alternatives

6. Mission and Business Impacts

i. Benefits and Non-Financial Analysis

ii. Cost and Financial Analysis

7. Risk Analysis and Mitigation Plans

i. Risk Analysis

ii. Mitigation Plans

8. Sensitivity Analysis

9. Conclusion

i. Comparison of Alternatives

ii. Summary of Results

10. Recommendations

i. Specific Actions Based on Business Objectives

ii. Implementation Plan

4.1 Executive Summary (Product Support BCA)

This section discusses drafting the Product Support BCA Executive Summary.

4.1.1 Product Support BCA Executive Summary

Decision makers often read and analyze the Executive Summary first, making it a critical part of the overall product support strategy documentation. The Executive Summary should be written last even though it is usually the first section read. The Executive Summary should be concise[5], identify the problem statement in question, and highlight key elements of the recommendation. It should summarize mission and business impacts, risk and sensitivity analyses results, as well as briefly address other important sections as required to help the reader quickly understand the BCA’s product support strategy recommendation.

The Executive Summary provides the recommended solution and why it is recommended over the competing alternatives. It should include a reference to each rejected alternative and how it compares to the recommended alternative in costs and benefits, pros and cons, and other relative merits established in the Product Support BCA. This comparison can be portrayed as a balancing of tradeoffs among alternatives for a more robust recommendation.

Items within the recommendation section should minimally include:

  • Key assumptions that drove the recommendation
  • Brief description of the alternatives
  • Description of the approach
  • Summary of objective criteria and conclusions
  • Description of the implementation plan at a level of detail necessary to support the recommendation

4.2 Introduction (Product Support BCA Main Body)

This section provides guidance on drafting the problem statement and background to begin the main body of the Product Support BCA. The introduction lays out much of the background and reasoning for conducting the Product Support BCA and helps to define the issue being addressed and supported by the analysis.

4.2.1 Problem Statement

The Problem Statement should provide an accurate and concise reason for conducting the Product Support BCA, as well as define the analysis framework for the current deficiencies, additional requirements, or opportunities for improvement. This statement should not assume a specific means of achieving the desired result. Rather, the Problem Statement contains an objective description of the desired end state or outcome (i.e., not biased toward any one alternative). Biases or unfounded assumptions in the problem statement undermine the analytical purpose of the Product Support BCA by jumping to conclusions.

Questions to consider as the team develops the Problem Statement include:

  • What is the desired end state?
  • What is the purpose of the analysis?
  • What is the scope of the analysis?
  • Who is the decision maker?
  • What are the potential impacts to the enterprise?

Having a clear and well-defined Problem Statement provides a reference point to go back to throughout the analysis. After reading this section, the decision maker should understand the purpose of the analysis and the framework of its conclusion. The approval authorities or governance board should review the draft Problem Statement for validation at the Product Support BCA kickoff meeting. Such clarification can avoid unnecessary rework and ensure the analysis covers the assigned subjects.

4.2.2 Background

Provide necessary background on the organization, industry/market conditions, or other systems which create cost and performance drivers for the system being analyzed. Also include relevant background on historical precedents, previous BCA or product support strategy attempts, acquisition documentation such as AoAs, and stakeholders. Previous Product Support BCA Results

The Product Support BCA process should always build on itself to incorporate lessons learned and best practices from previous iterations of a Product Support BCA. For example:

  • If this is five years after a Product Support BCA or prior to a change in the strategy, document recommendations from the previous Product Support BCA
  • Document the recommendation implemented from the previous Product Support BCA as the current baseline and compare to the alternatives Research and Due Diligence

The Product Support BCA team members should conduct a large part of the research and due diligence prior to the Product Support BCA kickoff to help guide initial decision making, such as validating the problem statement, and throughout the process of conducting a Product Support BCA. In the beginning, the team members should gather data, interview SMEs, examine previous iterations of the Product Support BCA (if applicable), and collect other documentation according to the Product Support BCA outline and as needed throughout the analysis. This effort should include and emphasize the relationship between the product support decision and the capabilities, objectives, potential impacts, and possible fallout across the enterprise.

4.2.3 Scope

Scope is the range of coverage encompassed by the BCA along with several dimensions such as time and functional areas of sustainment. A few examples include software, integrated training products, depot repair, technical publications, obsolescence management, and supply chain. Boundaries define the scope precisely and provide rules for data, organizational influences, and personnel. Other areas of concern that influence the boundaries the BCA should include:

  • Time and schedule
  • Cost/Benefit
  • Organizations
  • Functions and positions
  • Geographical areas, sites, and locations
  • Technology
  • Peace vs. Wartime operating environment
  • Other categories that have a potential impact on the decision

4.3 Desired Outcomes and Requirements

This section provides guidance on gathering and documenting the desired outcomes and requirements. It also discusses the preparation that must go into conducting a Product Support BCA. Early understanding of the requirements and desired outcomes provides a target for which to pursue through the analysis process.

4.3.1 Desired Outcomes

Identify and document the Warfighters’ desired outcomes rather than just the documented requirements. Identifying both the desired outcomes and requirements ensures that the desired outcomes are not buried in the details of the requirements. The Product Support BCA team and its stakeholders must come to consensus on the desired outcomes and periodically refer to them to stay on track. The governance board should concur with the desired performance outcomes in any deliverables to the sponsor.

4.3.2 Requirements

After identifying the desired outcomes, state the Program requirements. Some possible sources of the requirements may be the Key Performance Parameters (KPP), Key System Attributes (KSA), Performance Metrics already identified by the Capability Development Document (CDD), Capabilities Production Document (CPD), etc. Identify the KPPs and KSAs, including the range of KPPs and KSAs. Performance Metrics must be addressed through the recommended approach and be consistent with appropriate policy documents.

The documented outcomes and requirements may take the form of a Product Support Arrangement (PSA). A PSA is a generic term representing the range of implementing agreements, such as contracts, Memorandums of Understanding (MOUs), Memorandums of Agreement (MOAs), Commercial Service Agreements (CSAs), Service Level Agreements (SLAs), and similar formal agreements to ensure performance expectations (on both sides) are clearly articulated.

4.4 Assumptions and Methods

This section provides guidance on documenting the ground rules, assumptions, and methodology of the Product Support BCA. Assumptions and methodology are two items to be explored early in the Product Support BCA process.

4.4.1 Ground Rules and Assumptions Ground Rules

The ground rules document the Product Support BCA’s known or dictated parameters and conditions. Prior to formulating assumptions, what is known with certainty should be stated under the ground rules: facts, laws, defined criteria, constraints, regulations, OSD, or Service guidance. Include any factor known to be true that may affect the current or future business conditions under consideration in the analysis.

Constraints are those factors known or discovered during the research and due diligence period, normally beyond the control of the PM or PSM, which bound the Product Support BCA analysis. The BCA team must understand these constraints before beginning the analysis. Constraints should be presented to the governance board and reader of the BCA. For example, funding constraints such as congressional mandates could qualify as a ground rule.

A non-exhaustive list of major Product Support BCA ground rules includes:

  • Source of funding streams
  • Legislation, regulations, and policy
  • Financial data in constant or current dollars
  • Directed inflation index
  • Quantity of fielded systems
  • Expected OPTEMPO and service life Assumptions

An assumption is an informed position about what is true of a current or future state of affairs for a situation where explicit factual knowledge is unobtainable (i.e., inflation rates). Assumptions define aspects that are beyond the control of the BCA team. They are explicit statements about the conditions on which the BCA team bases the analysis.

After stating factors in the ground rules section, list the assumptions about what is not known, or about future states affecting business conditions. It is crucial to identify all key assumptions and gain stakeholder concurrence used in the Product Support BCA and critical for the risk or sensitivity analysis. Any non-concurrence by a stakeholder should be documented. Describe why a particular item is an assumption.

In the sensitivity analysis section, evaluate each major assumption for its impact on the Product Support BCA recommendation if the assumption is significantly off target. Omitting, changing, or misusing of an assumption can directly influence which alternative is recommended. A non-exhaustive list of major Product Support BCA assumptions includes:

  • Financial metrics and inputs (inflation)
  • Physical environment
  • Operational tempo or contingency vs. non-contingency operations
  • Expected useful life of a weapon system

4.4.2 Analysis Methods, Tools, and Rationale

Document the types of financial and non-financial analysis methods used and why. The Product Support BCA team should use guidance from OMB Circular A-94: Guidelines and Discount Rates for Benefit-Cost Analysis of Federal Programs (OMB A-94) on cost benefit analysis at all relevant points. As a general rule, the Product Support BCA team should include the following financial analysis metrics, tools, and techniques unless there is a documented rationale not to use them: Net Present Value (NPV), Payback Period, Break Even Point, Return on Investment (ROI), Internal Rate of Return (IRR), Life Cycle Cost (LCC), Time Value of Money Considerations (current or constant dollars and discounted dollars), Operating and Support (O&S) cost.

4.4.3 Evaluation Criteria[6]

One of the most critical and difficult components of a BCA is analyzing benefits in addition to cost, and thus making a final recommendation based on a set of evaluation criteria that enables a best value assessment. Best value is often defined as the intersection of performance and cost, based on specific criteria. The Product Support BCA team will establish the evaluation criteria for both financial and non-financial factors early in the process after conducting background research and obtaining approval from the governance body. Quantitative and Qualitative Values

The Product Support BCA problem statement, requirements, and Warfighter desired outcomes should drive the evaluation criteria. All criteria should be numerical and may include both quantitative and qualitative criteria. Criteria may be inherently quantifiable, for example, financial benefits and cost per flight hour. Other criteria may require numerical transformation of a qualitative variable, for example, morale, maintainability, supportability, or customer satisfaction. The methods and rationalization for numerical transformation of subjective (qualitative) factors must be fully described. Evaluation criteria should be independent, relevant, discriminating, and clearly defined for the reader of the BCA.

Consider the following, non-exhaustive list of quantitative and qualitative benefits categories:

  • Availability
  • Reliability
  • Supportability
  • Operational tempo or contingency vs. non-contingency operations
  • Expected useful life of a weapon system
  • Manageability
  • Sustainability
  • Versatility
  • Affordability (note: this is normally considered a cost variable but may be explored here as well depending on the analytical team’s approach) Scoring and Weighting

After identifying the quantitative and qualitative criteria, the governance board prioritizes the values for the criteria by agreeing on a scoring and weighting methodology such as Value Focus Thinking (VFT) and Analytical Hierarchy Process (AHP).[7] Establishing the scoring and weighting criteria ensures traceability for the next iteration of a Product Support BCA or auditing capabilities during a variance analysis. The scoring and weighting criteria should correlate to the Warfighters’ and sponsor’s identified desired outcomes and requirements. Quantifying Qualitative Values

Financial costs are by their very nature quantifiable; however, benefits may be more qualitative in nature. Consider using SMEs to generate scores. When trying to quantify areas that are not easily quantified, always define the scores used. Always define and document the scoring system used and how the resultant the scores were applied in an evaluation. For example, morale could be rated as a 0 for “does not improve morale”, 1 for “maintains current morale”, or 2 for “improves current morale”. The larger the span of ratings, the greater the difficulty in explaining what improvements an alternative would need to move up a point in the ratings scale. Any number of potential scoring methodologies can be devised. However, avoid situations where one alternative is rated 18 out of 20 and another is rated 19 out of 20 without any accompanying definition to show what made one alternative one point above the other. Another concern to consider is that not all benefits may be equally important to the decision maker, and should be prioritized and weighted accordingly. Normalization

To compare benefits with different units of measure, score or poll them on a consistent scale (e.g., 1 through 10). Describe the scoring criteria for each benefit to identify how the benefit will be measured and how that measure will translate into a score. If there is uncertainty or disagreement on how to score any of the alternatives, address it in the sensitivity analysis to determine how it will impact the overall decision. Rank Ordering/Prioritization

Establishing the weighting and scoring criteria is also important in cases such as, “Is the benefit of morale improvement equal to safety improvement?” or “Is safety improvement equal to targeting accuracy?” Just as in determining a rating scale, deliberately define the weighting scale. For example, a 100% weight means the benefit is “critical importance,” a 75% weight indicates “above average importance,” 50% shows “average importance,” 25% shows “below average importance,” and 0% means the benefit does not impact the recommendation.

If using SMEs to generate the scores, define and document the specific methodology and parameters in the Product Support BCA. Also identify the justification for differences in scoring between alternatives based on specific factors or reasoning. Refer to the suggested methodology below:

  1. Vote. Have each individual spread 100 points over the value measures based on the measures’ importance and range.
  2. Discuss significant differences. Have the “outliers” discuss their rationales.
  3. Revote until the group agrees on the ordinal ranking of the value measures.
  4. Vote again requiring each person’s weights to follow the group’s ordinal ranking of the value measures.
  5. Average the weights (cardinal ranking of weights) and normalize so they sum to one.
  6. Discuss significant differences. Have the “outliers” discuss their rationales.
  7. Repeat these steps until the group agrees. Sensitivity Analysis of Subjective Analytical Methods

Once the scoring and weighting is complete, evaluate the results to ensure that the results are not skewed or unrealistic. For example, if the results show that Alternative A scored 100 times greater than Alternative B, take a moment to ensure that the results are not artificially inflated in any one direction as a result of the scoring and weighting criteria.

Once the comparison and analysis is complete, summarize the significance of what the numbers indicate to help the decision maker make a final decision with a focus on value.

If there is any concern on the impact of the weighting and scoring criteria including unusually high or low data that skews results, neutralize it through sensitivity analysis by conducting an analysis on extreme ends of the numerical spectrum. This will help discern when decisions begin to change and tip the decision in one direction or another.

4.5 Alternatives

This section discusses how to develop, describe and choose a list of alternatives; brainstorming and drafting alternatives must be conducted early in the process.

4.5.1 Overview of an Alternative

For programs that already have official status, Figure 2 Sustainment Chart below displays a top level overview of key management items of interest. It contains a brief description of the program’s plans, schedule, benefits, and costs. While this quad chart by itself does not provide enough information to conduct a BCA, it can provide a roadmap and starting point for deriving solutions to issues. It also provides a mechanism by which the Baseline alternative and other Alternatives (following section) can be described from a top level viewpoint. The quad chart easily organizes the alternatives as options with the trade space among these four sections. The supporting data backing up this chart is among the data used by the analytical team when performing the different phases of analysis.

Figure 2: Sustainment Chart

Figure 2: Sustainment Chart

4.5.2 Current Baseline/Anticipated Initial Support Status

Identify the performance and cost baseline of the program, organization, or system using the Life Cycle Sustainment Plan (LCSP) and other source documents or information that ultimately feeds the Sustainment Chart. Describe the status and relevant attributes of the current state of affairs. The current strategy, operations and tactics that are being followed should be fully explained and rationalized. If the results change the Product Support Strategy, the LCSP must be updated to reflect the new baseline.

4.5.3 Development of Alternatives Choosing Alternatives

Alternatives should include a wide range of all possible solutions from which feasible solutions for in depth analysis are selected. Possible alternatives could include:

  • Government provided depot maintenance
  • Contractor provided depot maintenance
  • Various feasible combinations of depot and contractor maintenance percentages, such as 50–50, 25–75, or 75–25
  • Various contract types
  • Management functions and execution strategies
  • Intellectual Property Strategies

Consider extreme alternatives that may be tailored to inspire innovative alternatives such as no or low maintenance scenarios that may trade O&S costs with procurement costs. Identify the decision points, “when do costs and benefits occur?” and “when do they change?” When identifying alternatives, keep in mind that “all organic” or “all contractor” supported systems are rare, and are generally limited to mission driven operational environment factors (all organic) or commercial or commercial-derivative systems (all contractor). In reality, neither the organic nor commercial industry base possesses the resources, infrastructure, or the skills base to accomplish all sustainment functions for most defense systems. The Product Support BCA should avoid narrowly defined “all organic” or “all contractor” alternatives. The real alternative analysis focuses on achieving, for each of the IPS Elements required for sustainment, the best blend of organic and industry capabilities to arrive at a best value solution.

The alternative must identify the full time period to address the cost of the decisions and should not be constrained by appropriation categories. Identify and describe in detail the feasible alternatives to the current support method, including changes to the current state and any assumptions specific to each alternative. Alternatives concerning the source of work should include organic, commercial, and partnership arrangements. Alternatives should also include partnerships tailored to IPS elements at the component, sub-assembly, or system/platform level. Final alternatives must be realistic and assume the possibility of selection. Validating Alternatives

An initial attempt at developing alternatives should be included in the kickoff agenda to obtain input from potential providers, improvements, and new or alternative approaches to satisfying the requirement. More alternatives may be added by the BCA team during or soon after the kickoff meeting. Document the filtering or pare down criteria to explain how the Product Support BCA team and the governance body chose which alternatives will be analyzed and considered throughout the Product Support BCA. Using the Decision Matrix for Product Support (DMPS)

Product Support BCA alternatives can vary depending on a range of pertinent factors. These factors include the point in the system life cycle in which the Product Support BCA is accomplished, the scope of product support for the objective system, and considerations reflecting statutory, policy, guidance, or financial requirements. Figure 3, The Decision Matrix for Product Support (DMPS)[8], defines the potential range of product support strategies as defined by two key strategic system characteristics:

  • Weapon system scope: the level at which readiness and sustainment outcomes are measured and managed at the platform, major subsystem, or component level
  • Integration approach: the desired or required industry, organic, or blended (partnership) industrial capabilities

Figure 3: Decision Matrix for Product Support (DMPS)

Figure 3: Decision Matrix for Product Support (DMPS)

While the DMPS portrays nine separate product support option blocks, a tailored best value product support strategy may be located at an infinite number of points within the 3×3 matrix framework. In that regard, the DMPS serves as an initial guide to the PSM outlining the boundaries of potential product support strategies. Alternatives at Various Stages of Life Cycle

Product Support Alternatives (PSAs) will, to some degree, be dictated by where the system is in the life cycle. Early in the life cycle (between Milestone B and Milestone C), the PSM’s focus is on sustainment planning. DoD policy does not require establishment of an organic depot maintenance capability until four years following IOC. During the early life cycle design and development of the system there is typically a minimal amount of performance or supportability data. The early life cycle Product Support BCAs serve to initiate the Product Support BCA process, institutionalizing the collection and analysis of available data, and evolving the analysis as the amount and accuracy of data matures.

When adequate data is sufficient to make a life cycle product support strategy decision, DoD regulations stress the importance of making the best possible use of DoD and industry resources at the system, subsystem, and component levels while maximizing the use of outcome based product support strategies. When a program’s support strategy is under further assessment, the intent of the Product Support BCA is to derive the best value sustainment strategy for the objective system based on available competencies, capabilities, and cost while complying with Title 10 requirements for workload sourcing.

4.6 Mission and Business Impacts

This section provides guidance on conducting the analysis for the Product Support BCA.

4.6.1 Benefits and Non-Financial Analysis

The benefit analysis should focus on the non-monetary factors influencing the decision. To determine which benefits to include, stakeholders should assess which factors are most important for the desired outcome. JCIDS requirements found in CJCSI 3170-01G, enclosure B, should be explored in the Benefits and Non-Financial Analysis section of the Product Support BCA. These are Materiel Availability and Materiel Reliability. Operations & Support Costs is a third JCIDS requirement, but should be assessed in the Cost and Financial Analysis section of the BCA. Additionally, those other KPP requirements and other metrics that the program office deems important should also be included in the analysis. These should be tied to program requirements and parameters, such as schedule, technical performance, mission completion, etc. Benefits are frequently qualitative in nature, which injects a degree of subjectivity into the assessment. While this subjectivity sometimes cannot be avoided, it is important to ensure that the scoring and outcomes are traceable and repeatable as described in the Section 4.4. Performance Data

Performance metrics are only as good as the supporting data. Data collected for the metrics needs to be timely, accurate, and meaningful. Metrics should conform to SMART: specific, measurable, attainable, relevant, and timely. The selected metrics should not be so complex that good data collection becomes too expensive and difficult to achieve. Existing data collections should be used whenever possible. Data collection methods should minimize burdens on the Warfighter and should not add significant costs to the logistics support providers. Benefits and Non-Financial Analysis Methodologies and Strategies

The costs and benefits should be weighted using the criteria established in Section 4.4 Evaluation Criteria, to account for their relative importance. For example, if availability and customer satisfaction are both benefits being evaluated, the program office would likely determine that availability of the objective system to the Warfighter is twice as important to the BCA decision as customer satisfaction, and weigh it accordingly. It is important to document the weighting approach in the Product Support BCA.

The application of outcome or performance based strategies makes consideration of qualitative factors crucial to the Product Support BCA decision process. Most cost estimating methodologies apply consistent ground rules and assumptions (GR&A) factors across all alternatives and price them out based on cost of labor, cost of infrastructure, and other applicable cost elements. While it is important to have established GR&A to ensure uniformity in estimation and analysis, the evaluation of process efficiencies should not be eliminated from consideration. This requires flexibility in the benefits analysis.

The consideration of process efficiencies may play an important role in the results of the Product Support BCA. The BCA should not assume assignment of similar efficiencies to all sourcing alternatives. Rather, it should document and substantiate all analytical decisions for generating efficiency figures. Specifically, if one alternative is given credit for a more efficient process (such as fewer workers) as compared to other alternatives, this efficiency should be discussed in the BCA report and documented with substantiating material. Also, it should be referenced directly to the supporting mathematical BCA documentation where this figure is applicable. Likewise, those key processes that are assumed or set in the analysis to be equal should be also be explained and documented.

4.6.2 Cost and Financial Analysis Cost Estimation

The objective of cost estimation is to compile and forecast the cost to perform the tasks associated with each IPS Element, for each alternative, during a specified time period of analysis. Cost considerations must be included in every decision relating to the allocation of resources. The appropriate cost estimating method depends on the program being evaluated and the availability of data.

BCA acceptance depends largely on the credibility of the cost estimates. Therefore, an analyst must document data sources, provide the derivation of all costs, and maintain a clear audit trail. There are multiple sources available to provide additional guidelines and details on conducting cost estimates.[9]

At a minimum, the following guidelines should be observed in developing Product Support BCA cost estimates:

  • Include all incremental, direct, and indirect costs to the taxpayer.
  • Support the comparative analysis process by fully documenting the status quo (existing system) and providing its cost estimate.
  • Include all relevant anticipated costs directly or indirectly associated with each feasible alternative over the life of the program. Show all resources required to achieve the stated objective. Estimate all future costs from the start of the earliest alternative (other than the status quo) through implementation, operation, and disposal for a program or project. In the disposal, include the cost of disposal, and/or residual value for the old unit.
  • Ensure that cost estimates are consistent with the assumptions, ground rules, and objectives of the product support strategy.
  • Estimate all relevant future costs from inception through implementation, operation, and disposal for the program or project; not that all cost elements necessarily deserve the same weighted importance. If a cost associated with a certain element is very small and not significant to the program, spend an appropriate amount of time estimating this element. Devote the appropriate time to the more significant cost driving elements. The cost of an alternative includes the cost of operating the status quo programs until the chosen alternative is fully implemented.
  • Do not include sunk costs as part of the evaluation, analysis, or recommendation.
  • Disclose confidence levels Example Cost Estimating Methods

The engineering, parametric, analogy, and expert opinion approaches are four examples of cost estimating methods. The use of a specific approach varies with the amount and reliability of data available. Each approach may have positive attributes and limitations for a particular application.

  • Engineering Approach. The engineering or bottom-up approach can be broadly defined as an examination of separate segments of work at a low level of detail and a synthesis of the many detailed estimates into a total. Estimating by the engineering method requires the analyst to have an extensive knowledge of the system characteristics such as the system design, the sustainment processes, and the sustainment organization. Break the system, activity, or item of hardware into its level components and make estimates of each component. An analyst may use different estimating methods in estimating the costs of some components. Combine the costs of the components and the costs of integrating the components to get the total system cost. The detailed knowledge required for an engineering analysis is not always available, making this approach the most difficult to apply.
  • Parametric Approach. In parametric cost estimating, the cost is based upon physical attributes or performance characteristics and their relationships to highly aggregated component costs. For example, the total estimated cost of an item will depend on such things as size, weight, and speed. The lack of a significant number of data points can limit or preclude the use of parametric cost estimating. The results of a parametric estimate depend upon the ability of the analyst to establish valid relationships between the attributes or elements that make up the alternative and its cost. Therefore, properly choose and describe the Cost Estimating Relationship (CER). When documenting results that have used a CER, present the statistical characteristics of the CER, the source database, and all assumptions surrounding the CER development.
  • Analogy Approach. The analogy approach is based on direct comparison with actual data, historical information of similar existing activities, systems, or components. The major disadvantage of this method is that it is a judgment process, requires considerable experience and expertise, and assumes that analogous systems are available. Use this method when the comparability of the analogous system and the product/process is well documented. The documentation should give a convincing argument that the product/process is similar enough to the source to make the analogy valid. A variation to this methodology is to make an adjustment to the source data to account for some variation in the estimate of the product/process. For example, if commercial vehicle data are used to estimate some aspect of a tactical vehicle, an adjustment could be made to the source data. Document the "adjustment technology" well so that there is no doubt about the methodology.
  • Expert Opinion Approach. The expert opinion approach uses the judgment of an experienced individual or group. This method requires just as much rationalization and explanations as any other method. While estimates developed by expert opinion are occasionally both useful and necessary, they are normally highly uncertain and have a low confidence rating. Do not use expert opinion when time permits the preparation of a more thorough analysis. Do not use expert opinion as a convenient substitute for more scientific methods when such methods are available for use. If expert opinion is used, the documentation should contain the sources and qualifications of the opinion and a list of the attributes of the sources. One of the expert opinion methods used is the Delphi questionnaire. This method involves the query of expert opinion from a group. Seek information and supporting rationale from each expert independently. Summarize the results and send a report to each expert. Gather a second opinion after each individual reviews the report, and then summarize the results. Continue this iteration process for several cycles until there is a consensus, or near-consensus.
  • Other Approaches. The Cost Assessment and Program Evaluation (CAPE) O&S Cost Estimating Guide references Actual Costs and Cost Factors as two additional approaches. Other cost modeling and analysis techniques also exist. The BCA report should have the proper description and documentation of all analytical techniques deployed to maintain the tenets of credibility, traceability and repeatability. Most often this intricate detail is contained in an appendix to the main body in written documentation and Excel/other mathematical tools. The main body of the BCA contains a top level description and review of the analytical techniques used. CAPE Guidance on Cost Estimation

Cost and Financial Analysis should be captured according to the IPS Elements[10] and the CAPE Cost Elements[11], and customized according to where the weapon system is in the life cycle. Every category and cost element should be examined to collect the entire cost. This level of analysis should be repeated for each alternative.

The O&S cost element structure is divided into six major categories. The basic scope and intent of the six major categories should be retained, even if changes are made to lower level entries. The six major categories are:

  • Unit-Level Manpower: Cost of operators, maintainers, and other support manpower assigned to operating units. May include military, civilian, and/or contractor manpower.
  • Unit Operations: Cost of unit operating material (e.g., fuel and training material), unit support services, and unit travel. Excludes all maintenance and repair material.
  • Maintenance: Cost of all maintenance other than maintenance manpower assigned to operating units. May include contractor maintenance.
  • Sustaining Support: Cost of support activities other than maintenance that can be attributed to a system and are provided by organizations other than operating units.
  • Continuing System Improvements: Cost of hardware and software modifications to keep the system operating and operationally current.
  • Indirect Support: Cost of support activities that provide general services that cannot be directly attributed to a system. Indirect support is generally provided by centrally managed activities that support a wide range of activities.

Using IPS and CAPE elements, two sets of costs should be identified: one for non-recurring or investment costs and another for recurring costs. Once both sets of costs are identified, add them together for each year under consideration to come to the total cost. The total costs can then be used for other financial analysis (such as net present value). All Relevant Comparative Costs: Life Cycle Cost

As discussed in the Defense Acquisition Guidebook, the LCC of a program consists of elements directly associated with the program plus other indirect costs that are “logically attributed to the program.” [12] Include any incremental cost to the taxpayer that can be traced to an alternative when executing the cost portion of the BCA, regardless of agency, appropriation, or timing.

The Department is taking several new steps towards more thorough and accurate projections of collective systems’ LCC for cost reduction efforts to be taken earlier within the Acquisition process. For example, LCC-focused estimates of cost for material alternatives during the Analysis of Alternatives (AoA) process will be conducted with the intent to strongly steer initial systems specification, development, and acquisition. LCC consideration and influence on the earliest system configuration, sourcing, and trade-off decisions should be made. LCC estimates and analyses that are built on AoA findings and continued as major decisions will play a major role in the evolution of design, development, and establishment of an effective life cycle sustainment program. For fielded and mature programs, comprehensive LCC measurement and analysis can help reduce costs and influence Product Support BCA factors for the performance capabilities of future upgrades and entire replacement of systems.

  • The Office of the Deputy Director, Cost Assessment (OSDDCA)) defines LCC categories in the Operating and Support Cost Estimating Guide. The major categories include Research and Development (R&D), Investment, Operations and Support, and Disposal. They are summarized as:
    • Research and Development: Consists of development costs incurred from the beginning of the materiel solutions analysis phase through the end of the engineering and manufacturing development phase, and potentially into low rate initial production. Typically includes costs of concept refinement, trade studies, advanced technology development, system design and integration, development, fabrication, assembly, and test of hardware and software for prototypes and/or engineering development models, system test and evaluation, system engineering and program management, peculiar and common support equipment, peculiar training equipment/initial training, technical publications/data, initial spares, and repair parts associated with prototypes and/or engineering development models.
    • Investment: Consists of production and deployment costs incurred from the beginning of low rate initial production through completion of deployment. Typically includes costs associated with producing and deploying the primary hardware; system engineering and program management; peculiar and common support equipment, peculiar training equipment/initial training, technical publications/data, and initial spares and repair parts associated with production assets; interim contractor support that is regarded as part of the system production and is included in the scope of the acquisition program baseline; and military construction and operations and maintenance associated with system site activation.
    • Operations and Support: Consists of operating and sustainment costs incurred from the initial system deployment through the end of system operations. It includes all costs of operating, maintaining, and supporting a fielded system. Specifically, this consists of the costs (organic and contractor) of personnel, equipment, supplies, software, and services associated with operating, modifying, maintaining, supplying, training, and supporting a system in the DoD inventory. These costs may include interim contractor support when it is outside the scope of the production program and the acquisition program baseline. O&S costs include costs directly and indirectly attributable to the system (i.e., costs that would not occur if the system did not exist), regardless of funding source or management control. Direct costs refer to the resources immediately associated with the system or its operating unit. Indirect costs refer to the resources that provide indirect support to the system’s manpower or facilities. For example, the pay and allowances (reflected in composite standard rates) for a unit level maintenance technician would be treated as a direct cost, but the (possibly allocated) cost of medical support for the same technician would be an indirect cost.
    • Disposal: Consists of costs associated with demilitarization and disposal of a military system at the end of its useful life. It is important to consider demilitarization and disposal early in the life cycle of a system because these costs can be significant, depending on the characteristics of the system. Costs associated with demilitarization and disposal may include disassembly, materials processing, decontamination, hardware, collection/storage/disposal of hazardous materials and/or waste, safety precautions, and transportation of the system to and from the disposal site. Remember that there may be residual value or positive credit for resource recovery and recycling. Appropriation Category Limitations

Initially, the Product Support BCA owner should not restrict or bind the requirements of the financial analysis according to the guidelines provided in the DoD Financial Management Regulation 7000.14-R, and should instead focus on capturing costs and benefits in accordance with OMB A-94 guidance. After conducting the analysis with the assumption of “colorless money,” splay the costs across budgetary appropriations. If the appropriation category is a known limitation from your sponsor or other stakeholders, it should be identified as such under the GR&As and mitigated in the Programmatic Risk (as a Funding Risk) section and the Implementation section of the BCA.

At the point of developing the recommendation, ensure the project plan includes steps for how the program office plans to fund and execute the decision. The PSM needs to ensure processes are in place to enable the PSM and PM to maintain an awareness of funding complexities such as when one category of funding goes up, another category of funding is forced down as a result. Although this may happen, there should always be a demonstrated savings that is mapped to the guidance provided by CAPE.

4.7 Risk Analysis and Mitigation Plans

This section provides guidance on conducting a risk analysis and associated mitigation plans.

4.7.1 Risk Analysis Risk Analysis in a BCA

Each risk should be separately reviewed and assessed by comparing and quantifying factors such as probability and impact of occurrence. Risk analysis is critical—the level of risk can be a factor in eliminating or reducing the value of an alternative that is otherwise highly evaluated. For example, a particular alternative PSP may evaluate highly due to attractive labor rates for a particular workload which requires highly skilled personnel. However, further data reflects that the PSP has insufficient manpower to accomplish the projected workload and must hire additional personnel to meet the requirement. The risk of hiring highly skilled personnel or training lower skilled personnel to accomplish the more complex workload is a significant organizational and technical risk, and could lead to concluding that an alternate PSP with higher labor rates but adequate in-place skilled personnel is the best value option. Risk Classification

Risk should be viewed as an undesirable implication of uncertainty. Risk can be estimated in terms of probability of occurrence and impact of occurrence. In certain situations, probabilities of various outcomes can be estimated and the impact quantified. Risk can be classified as Business or Programmatic, Operational, Suitability, Process, Technical, Schedule, Organizational, Sustainability, Safety, and Environmental.

  • Business or Programmatic Risk: Risk of undesirable consequences that affect the program’s viability, affordability, and budget. For example, the unknown problems associated with managing product support providers; the risk associated with not anticipating all requirements when developing a contract and paying a premium for those requirements at a later date. Other examples include poor performance on behalf of a product support provider, cost growth, and extended labor disputes.
  • Operational Risk: Risk to the Warfighters’ ability to perform the mission as planned. Included in operational risk is examining the readiness and equipment performance. Examples are: How would other alternatives affect the risk to the overall operations, how do the alternatives increase or decrease wartime effectiveness, and is there any potential degradation across the operational spectrum?
  • Suitability Risk: Risk to the availability and reliability of systems and support systems and the comparative impact to the combat or operation.
  • Process Risk: The potential for undesirable performance in a newly established process that could cause failure to meet the anticipated performance or standards. An example of a process risk is a depot maintenance facility being unable to meet the requirements of a new process.
  • Technical Risk: Risk associated with failing to develop or implement the technology necessary to institute process change or technologies that may render an alternative useless. Typically, technical risk increases with the use of immature technologies. Using systems engineering methodologies such as spiral development can mitigate some technical risks.
  • Schedule Risk: Risk associated with time allocated for performing the defined tasks. This factor includes the effects of programmatic schedule decisions, the inherent errors in schedule estimating, and external physical constraints.[13]
  • Organizational Risk: Risk associated with difficulties in implementing a change within an organization. Implementing an effective communication and change management strategy can mitigate organizational risks.
  • Sustainability Risk: Risk associated with addressing the needs of the present at the cost of the needs of the future. The PM must consider whether the project can balance economics (i.e., profit), efficiency, environment, safety, and social responsibility (i.e., impact on local community) in the long term.
  • Safety Risk: Risk associated with exposing personnel to hazardous work environments. Unsafe conditions endanger the human capital of the organization and create legal liabilities.
  • Environmental Risk: The chance of harmful effects to ecological systems resulting from exposure to physical, chemical, or biological stressors which may adversely affect specific natural resources or entire ecosystems. Damage to the local environment can drain organization resources for clean up, litigation, and bad public relations. Risk Prioritization

Risks are prioritized according to their potential implications for meeting the program’s objectives. A common approach to prioritizing risks is to use a Risk Probability and Impact Matrix (see Figure 4, Sample Risk Probability and Impact Matrix). The specific combinations of likelihood and impact that lead to a risk being rated as high, medium/moderate, or low overall effect on a risk scale between 1 and 5 are usually set by the organization. Also provide a definition of the thresholds for high, medium, and low for the reader. There should also be a description of the impact of the risk on the program or system (e.g., time delayed in days, loss of funds, etc). The risk score helps guide and prioritize risk responses.

Figure 4: Sample Risk Probability and Impact Matrix

Figure 4: Sample Risk Probability and Impact Matrix

4.7.2 Mitigation Plans

After identifying, ranking, and prioritizing the risks, develop a mitigation plan. Adopting less complex processes, conducting more tests, or choosing a more stable supplier are examples of mitigation actions. Taking early action to reduce the probability or impact of a risk occurring on the project is often more effective than trying to repair the damage after the risk has occurred. Mitigation plans may involve making tradeoffs in capabilities, cost, schedule, and performance. If budgets are cut, certain tradeoffs will be made (reduced capabilities, delayed schedule, lesser accepted performance, etc.). To make fully informed decisions on which course to take, leadership needs to understand the risks in all these areas. Important components of the risk mitigation plan include roles and responsibilities, risk analysis definitions, and risk thresholds for low, medium/moderate, and high risks.

Risk mitigation implies a reduction in the probability and/or impact of an adverse risk event to an acceptable threshold. However, the program manager should be aware that in some cases there are follow-on effects of risk mitigation. Mitigating risk in one area may have adverse effects in other areas of the program. Mitigation may require prototype development to reduce the risk of scaling up from a bench scale model of a process or product. Where it is not possible to reduce the risk probability, a mitigation response may lessen the impact by targeting linkages that determine the severity.

Risk and risk mitigation strategies should inform and influence the sensitivity analysis section.

4.8 Sensitivity Analysis

This section discusses the sensitivity analysis section of the Product Support BCA.

4.8.1 Sensitivity Analysis

Sensitivity analysis is a repetition of an analysis with different quantitative values for cost or highly variable ground rules and assumptions to determine their effects for comparison with the results of the basic analysis. It is a tool that can be used for assessing the extent to which costs and benefits are sensitive to changes in key factors. Sensitivity analyses conducted on major unknowns for each feasible alternative can provide a range of costs and benefits that may provide a better guide or indicator than a single estimate. It is not sufficient to present the decision maker with a set of alternatives whose costs and benefits are based on most likely factors and assumptions. The decision maker needs to be informed about how well the rankings hold up under reasonable changes to factors and assumptions. Describe how sensitive the costs and benefits are to changes.

Ensure sensitivity analyses are done as frequently as deemed necessary. It becomes more critical when a BCA does not favor any one alternative or there is significant uncertainty about a cost element, benefit, other parameter or assumption. Sensitivity analysis should explain what happens to costs and benefits if an underlying assumption changes or is wrong, or how certain changes in inputs have an impact on the output. Analyses should identify the “what if” scenarios or the confidence range for your analysis results. These can be performed using tools like Monte Carlo simulations, sampling of variables, and emulator methods. Assumptions and contributing factors can include length of system life, volume, mix and pattern of workload, future labor and overhead rates, etc. Sensitivity analysis can also be performed on subjective weighting and prioritizing aspects of the analysis, especially those components found in the Comparison of Alternatives section.

4.9 Conclusion

This section provides guidance on completing the analysis and comparing the results as input into the final recommendation for the Product Support BCA.

4.9.1 Comparison of Alternatives

Compare the baseline against the alternatives according to the selection criteria identified during the kickoff with the key stakeholders and approval from the governance body. Provide a value analysis that includes a narrative explaining the methodology and rationalization of comparison criteria. Finally, restate the methodologies and tools used to develop the conclusion. There may be a need for an incremental analysis approach for complex systems. The trade space among key analytical factors should be fully vetted and described to present a fully matured analysis and conclusions focused on providing the decision maker the richest understanding of the feasible choices and tradeoffs.

4.9.2 Summary of Results

Summarize all the results of all the different analyses conducted in the BCA, across all alternatives. This should be a list of all alternatives, along with pros, cons, risks, and additional findings/observations for each.

4.10 Recommendations

This section provides guidance on the final step of the Product Support BCA, completing the draft and making recommendation and its associated implementation plan. State the final recommendation on which strategy to choose and why that strategy should be chosen.

4.10.1 Specific Actions Based on Business Objectives

Recommendations provide closure to the Product Support BCA process and begin the transition to the selected product support strategy. Provide the rationale, justification, and supporting information for each recommendation. Other pertinent information to include is a roadmap and implementation plan that includes time for validation and approval of Product Support BCA, documenting or archiving the Product Support BCA, determining gaps, and documenting other lessons learned.

4.10.2 Implementation Plan Communications Plan

Without effective communication, key stakeholders in a project may miss out on vital information and may not understand the need for change. Customers might not be aware of the plans for a new way of doing business, and raise concerns about how the proposed alternative would meet their needs. The other military services, DFAS, or the Joint Staff may need to be informed of the Product Support BCA recommendation. Oversight groups such as OSD, OMB, Joint Staff, or Congressional staff may need to be informed or require approval of the Product Support BCA recommendation through the budget formulation process if not by any other means.

Provide a communications plan[14] for the proposed alternative. Focus on increasing integrated efforts, strategic messaging, and clear communication of desired actions. The best way to approach communication is to develop a clearly planned approach or strategy. Address the means, methods, and messages—including who will issue messages—along with a schedule for delivery. Explain the initiative to stakeholders and other parties impacted by the proposed new way of doing business.

Target Audience


Communication Tool

Responsible Party

Due Date


Identify the Target Audience by considering the following:

 Who will benefit from the project?

 Who are the key stakeholders?

 Who are the stakeholder groups and target audience within them?

What do you intend to communicate to the stakeholder groups?

What are the key points stakeholder groups need to understand and act upon?

What communication methods and tools are most appropriate for the stakeholder groups?

e.g., electronic, verbal, written

Who will be responsible for implementing each action?

When must the action be implemented?

What are the costs associated with each action?

Table 3: Communications Table Project Plan

Provide a project plan for the recommended alternative. With a well thought out, high level project plan, the PM or PSM will be able to communicate, coordinate the tasks, and manage the risks necessary for a successful transition throughout pilot, implementation and sustainment phases. The well thought out project plan may also help validate or uncover aspects of a recommendation that were not previously considered.

Implementation plans should have specific events tied to specific, achievable milestones that factor in technological, cost, and schedule risk. Ensure the plan includes steps for how the program office plans to fund the decision. Identify the type of approach to implementing the preferred alternative, for example one large project, a number of smaller projects or a combination of both. Brief the implementation or action plan with all stakeholders to verify that all necessary tasks are accounted for, are in their proper sequence, and are assigned to appropriate organizations or individuals. Product Support BCA preparers must make sure the implementation plan is consistent with scheduled costs and budgets elsewhere in the Product Support BCA. Budget Plan

Provide a budget proposal in line with the Services’ annual program and budget process in concert with the PPBE calendar based on the Product Support BCA analysis and recommendations. Identify the amount of funding required for each phase of the recommended alternative, identify the source for these funds, and the current funding status. Be sure to understand and account for any restrictions associated with these funding sources.

The budget plan should consider and address:

  • What is the amount of funding from existing or previously submitted budgets for the existing operation that could be used for the new proposed operation?
  • What is the amount of new funding, if any, needed to be requested by appropriation or major budget account?
  • What is the rationale for requesting funds from these sources?
  • What are the limitations on these funding sources?
  • Will proposed funding require other existing or planned efforts or programs to go unfunded or have budgeted amounts reduced?
  • What is the effect of funding impacts on organizations for the function or the organization proposing the new way of doing business?
  • What is the risk of availability of funding source(s)?

5. Governance, Validation, and Approval

This section provides guidance on establishing the governance structure and body, as well as the validating and approving the Product Support BCA.

5.1 Governance

Establish a governance body with the relevant approval authorities at the kick off meeting. The governance body is normally tied to the sponsor’s and PM’s chain of command. This body will continue to provide guidance throughout the process. Additionally, this governance body also helps ensure buy-in during each step and major milestone of completing a Product Support BCA. The governance body should meet periodically at an agreed upon timeline to discuss progress, issues, and next steps. A non-exhaustive list of steps include: the purpose, GR&A, evaluation criteria, and all other critical factors contained within the BCA. The Product Support BCA owner should have this governance body in mind when writing the Product Support BCA. The periodic meetings should ensure that no stakeholder or approval authority is surprised by the final Product Support BCA recommendation.

The validation and approval of a BCA is ultimately dependent upon the decision maker. This and the following sections provide the BCA team insight that many decision makers request a wide range of diverse perspectives prior to and in support of making major decisions. The people and organizations representing this diversity are essentially the foundation for governance, validation, and approval type bodies.

5.2 Validation and Approval

The Product Support BCA owner should consider adopting the GAO comment procedure that can be seen in the appendix of most GAO reports. This provides the organization an opportunity to comment on the study or recommendations to avoid the “accept or reject” process. This streamlines the approval process that is repeatedly cited as one of the lengthiest process segments in completing a Product Support BCA.

The Product Support BCA sponsor should conduct a final review of the Product Support BCA and look for a Product Support BCA recommendation that is comprehensive, consistent, accurate, timely, and unbiased. The sponsor or the ultimate decision maker should document the reason for agreeing or disagreeing with the Product Support BCA recommendation. This final decision documentation serves as an archive, and combined with the Product Support BCA, provides the baseline for the next iteration of the Product Support BCA.

6. Documentation

6.1 Lessons Learned and Best Practices

The Program Office should require a step in the Product Support BCA process to capture the lessons learned and share the best practices across the DoD. The program office should document the results of the variance analysis and research the “why” of the results to pull out some valuable lessons learned and best practices for the process.

6.2 Documentation

The data manager is responsible for maintaining and keeping historical records of Product Support BCAs to include the research, performance outcomes, cost estimates and methodology, sources of data, etc. This is a critical step to support subsequent iterations of the Product Support BCAs or a variance analysis as the program matures or requires additional analysis to support decisions as there is a change in the program strategy. Once a Product Support BCA for an ACAT 1 program has been approved the outcome, along with the implementing plan, risks, funding profile, assumptions and constraints must be reflected in the LCSP as the new baseline.

6.3 Revalidation Analysis of Product Support Strategy BCAs

Prior to each change in the Product Support Strategy or every five years, whichever occurs first, the program will revalidate any business-case analysis performed in support of the product support strategy. The revalidation analysis examines the actual results versus the planned or estimated results and includes four primary categories of information: operations, cost, performance, and funding.

Appendix A – Product Support BCA Checklist and Phases

This attachment provides a guide for those responsible for preparing or reviewing the Product Support BCA. This checklist and process steps is provided as an initial guide for those responsible for preparing or reviewing the Product Support BCA. It is designed to enhance consistency in Product Support BCA products, and is not all-inclusive. Tailoring to the specific program and alternatives being assessed should be done.

A.1 Product Support BCA Checklist

  1. Executive Summary:
    1. Does the executive summary adequately state the problem, study objective, and significant criteria, assumptions and constraints?
    2. Are the feasible alternatives clearly identified and differences explained?
    3. Is the recommended alternative adequately supported by referencing details of the analysis?
  2. Introduction, Outcomes, and Requirements:
    1. Is the outcome clear and specific?
    2. Is the outcome realistic?
    3. Are any feasible alternative solutions excluded due to a bias in the objective statement?
    4. Is the objective, as stated, unbiased as to the means of meeting the objective?
    5. Are the expected outputs/accomplishments defined in quantifiable, measurable terms?
    6. Are criteria specified for selection of a preferred course of action?
    7. Is the objective statement phrased so that the type and variety of potential alternatives are not unnecessarily limited?
    8. Is the statement of the objective/problem well documented?
    9. Have performance measures and outcomes been identified which are appropriate for monitoring the business performance under the proposed new business plan?
  3. Assumptions and Methods :
    1. Are all assumptions recognized and identified?
    2. Are the assumptions realistic, justified, and realistically supported?
    3. Are assumptions used only when actual facts are unavailable?
    4. Are assumptions unnecessarily restrictive, thereby preventing consideration of feasible alternatives?
    5. Do assumptions include economic life and future changes in operations requirements?
    6. Are key facts, ground rules, laws, DoD or Service policies, and other constraints stated?
    7. Are all assumptions pertinent to the analysis identified and rationale provided?
    8. Is a project time frame established?
    9. Are space, construction, furniture, and lab equipment needs included?
    10. Are necessary geographical constraints included?
    11. Are assumptions too restrictive or too broad?
    12. Are facts presented as assumptions? Can the facts be verified? Are uncertainties treated as facts?
    13. Are all assumptions/constraints well documented?
    14. Are methods, factors, evaluation criteria, and their approval process by the governance board clearly documented?
  4. Alternatives:
    1. Are all feasible alternatives considered?
    2. Were alternatives rejected before a full analysis was adequately documented?
    3. Are the alternatives significantly different as opposed to superficial restructuring of a single course of action?
    4. Was the status quo used as the baseline for alternative evaluation?
    5. Were other government agencies' capabilities to provide a product or service considered, where applicable?
    6. Were contracting alternatives considered (including public private competition under OMB Circular A-76 or termination and consolidation of existing contracts)?
    7. If appropriate, is lease versus buy evaluated as an alternative?
    8. Are options applicable to each alternative presented?
    9. If the project increases productive capacity, has a contracting alternative been examined?
    10. Are the alternatives well defined?
    11. Do alternatives overlap one another? Why?
  5. Benefits and Non-Financial Analysis:
    1. Have all project results, outputs, benefits, or yields been included?
    2. Do the benefits relate to the project objective?
    3. Are the benefits identified in measurable terms where possible?
    4. Are benefits measuring techniques properly defined and supported?
    5. Is benefit priority or ranking criteria clearly stated and used in the evaluation? Is any weighting scale consistently and reasonably applied?
    6. Are negative results or outputs identified and adequately evaluated?
    7. Is the list of benefits free of double counting?
    8. Are secondary benefits (not related to the objective) identified?
    9. Are all cost savings represented as a negative cost rather than as a benefit?
    10. Are the benefits suitably tabulated, graphed, etc.?
    11. Are the assumptions identified and rationale explained? Are they too restrictive or too broad?
    12. Are estimating techniques defined? Are they appropriate?
    13. Are information/estimation sources clearly identified?
    14. Are data collection methods valid and adequate?
    15. Are benefits estimating techniques valid?
    16. If savings have been claimed, will a budget actually be reduced? Have the identified savings been fully coordinated with the impacted activity?
    17. Have all advantages and disadvantages of the alternatives been identified?
    18. Is expert opinion used? Were these experts properly qualified?
  6. Cost and Financial Analysis:
    1. Are cost and savings schedules realistic?
    2. Have all incremental costs to the taxpayer, including common costs, been provided for each alternative?
    3. Have cost estimates been provided for the status quo? Are they reasonable? Can they be verified?
    4. Are all government direct and indirect costs included for each alternative?
    5. Do investment costs include CAPE guidance, IPS Elements, etc.?
    6. Are personnel costs all inclusive; that is, specific skill levels, fringe benefits, overtime and shift differentials, etc.? Are personnel costs broken out by rank/grade, number of employees in each category, etc.?
    7. Are future equipment replacement costs included as investments as opposed to operations costs?
    8. Are available asset values considered and are such values adequately documented?
    9. Are cost collection and aggregation methods correct?
    10. Are estimating relationships and procedures identified and properly supported?
    11. Are program or project costs expressed in constant dollars?
    12. Where inflation or cost escalation is used, have the factors been identified and validated?
    13. Are cash flows discounted at the proper discount rate using OMB Circular A-94 guidance?
    14. Are the sources of estimates identified? Are these sources accurate and appropriate?
    15. Are cost factors current and supportable?
    16. Is appropriate backup documentation, e.g., cost data sheets and variable explanation sheets, provided to support cost estimates?
    17. Are cost estimates consistent with assumptions and constraints?
    18. Has the life cycle cost estimate been provided for all feasible alternatives?
  7. Risk:
    1. Assuming that a risk analysis has been performed, how were the probability estimates derived?
    2. Has an uncertainty analysis been performed? What technique was used (for example, a fortiori or contingency analysis)?
    3. Were ranges of values used for unknown quantities?
    4. Were point values varied to illustrate impact?
    5. Have all relevant "what if" questions been answered?
  8. Sensitivity Analysis:
    1. Were the effects of possible changes to the objective requirements evaluated?
    2. Has a sensitivity analysis been performed to show the impact of changes in dominant cost elements? Examples are length of economic life; volume, mix or pattern of workload; requirements; organizational structure; equipment, hardware, or software configuration; or, impact on the length of time for project completion. If no sensitivity analysis has been performed, why not?
    3. What do the sensitivity analysis results imply about the relative ranking of alternatives?
    4. Would the recommendation stay the same if a given characteristic varied within a feasible range?
  9. Conclusion and Recommendation:
    1. Do the comparison and selection criteria agree with those in the project or mission objective statement?
    2. Does analysis data clearly support the recommendation?
    3. Were alternative selection criteria applied consistently?
    4. Were cost and benefit data suitably displayed to accurately depict relationships?
    5. Were the alternatives compared to a common baseline (minimum requirements level)?
    6. Were alternative comparison techniques suitable for the program project being evaluated; that is, present value, payback period, uniform annual cost, etc.?
    7. Was a specific course of action recommended?
    8. Does the analysis seem free of bias in favor of a particular alternative (for example, no benefits indicated for one or more of the alternatives, biased assumptions, etc.)?
    9. Are the recommendations logically derived from the material?
    10. Are the recommendations feasible in the real world of political or policy considerations?
    11. Are the recommendations based on significant differences between the alternatives?
    12. Do benefits exceed relevant costs for the preferred alternative?
    13. Have all significant differences between the recommended alternative and others been emphasized?
    14. Does the communication plan show a reasonable plan for spreading the word about the proposed business process to all affected parties?
    15. Is there a project plan that spells out in sufficient detail the actions different offices or organizations must take to implement the new way of doing business?
    16. Does the plan include reasonable steps that are sequenced in proper order to get from the “as-is” to the “to-be” state of business?
    17. Do steps in the action plan acknowledge any barriers to implementation and allow time and a reasonable plan of action to overcome implementation barriers?
  10. Documentation:
    1. Are the costs thoroughly documented in appendixes so an independent reviewer may replicate it?
    2. Is it possible to trace costs to their basic inputs, units of measure, sources derived from, and as of date for any special rates or factors?
    3. If costs, assumptions, or other input to the estimate is based upon expert opinion, does the supporting documentation include the individual's office symbol, email address, and phone number?
    4. Will the Product Support BCA "stand on its own?"
    5. Will an independent reviewer be able to reach the same conclusion?
  11. Coordination:
    1. Has coordination of all participating offices and organizations been obtained?
  12. Sustainability:
    1. Is the project economically viable?
    2. Is the project energy and resource efficient?
    3. What is the program’s potential environmental impact?
    4. What is the program’s plan and mitigation strategies for potential environmental impacts?
    5. Is the project safe for workers and end users?
    6. What is the impact to the local community?
    7. Does the project consider the 6Rs of closed loop material flow (Recover, Recycle, Redesign, Reduce, Remanufacture, and Reuse)?
    8. Does the project consider the 7 Elements of Sustainable Manufacturing (Cost, Resource Consumption, Environment, Health, Safety, Waste Management, and Local Community)?

A.2 Product Support BCA Process Flow

The following process flow provides a visual representation of the general steps necessary to complete a Product Support BCA. This is provided for illustrative purposes. Tailoring of the process must occur to meet the needs of the stakeholders and sponsor.

Figure 5: Product Support BCA Flow Process

Figure 5: Product Support BCA Flow Process

Appendix B – Guidelines for Capturing Cost

The guidelines for capturing cost should follow DoD DInstruction 7041.04, “Estimating and Comparing the Full Costs of Civilian and Military Manpower and Contract Support”.

The instruction establishes business rules for use in estimating and comparing the full costs of military and DoD civilian manpower and contract support. The full costs of manpower include current and deferred compensation costs paid in cash and in kind as well as non-compensation costs.

The instruction can be found at:

Appendix C – Product Support BCA Timeline and Life Cycle


Appendix C – Analytical Tools

The following table of analytical tools was in response to the November 2009 Weapon System Acquisition Reform Product Support Assessment (WSAR-PSA) report requirements. The PSAT compiled this list from different software, analytical techniques, guidebooks, processes and best practices across a wide variety of sources all concerning the analysis of financial and logistics investment and strategic decisions. This appendix is intended to be used as a reference only. There is no endorsement by USD AT&L for or against any of these items presented in this appendix. This appendix should be viewed strictly as informative in nature. Any analytical tools used by analysts (including those located in the Product Support Analytical Tools website ( should still be vetted, reviewed, and approved through appropriate channels consistent with all other professional work performed.


Model Name

Product Tool (Output)

Purpose of Tool

Owner (DON Code)


Facilities Acquisition Management Program

Model is a spreadsheet based tool, developed and in use for past 12 years. Complexity level is moderate to low.

FAPM model forecasts NAVFAC’s annual costs to execute customer funded BOS, SRM, and ENV contract workload.



Base Operating Support (BOS) Model

BOS Performance/Pricing Model links resources (input) to performance (output) for 8 mission capability areas, 23 functions, and 107 sub-functions.

An accredited BOS model will provide more accurate, and more defendable BOS requirements. An independently accredited BOS model will enable decision makers to identify risks and opportunities while evaluating different levels of service.



OPOM (Ordnance Programs Optimization Model)

Ordnance OM,N requirements across FYDP in three major categories. WSS (Manpower), QE (Reliability), and Maintenance (Availability)

Assess Ordnance requirements against CNO War planning goals for sufficiency and War fighter goals for Effectiveness. Model correlates funding impacts on system readiness, outputs include budget exhibits and spend plans and various metric reports.



Airframe Depot Readiness Assessment Model

Ability to meet CNO Goals "C" Rating

Assess budget requirements



Engine Depot Readiness Assessment Model

Ability to meet CNO Goals "C" Rating

Assess budget requirements



Flying Hour Projection System

Budget Quality Output

Integrate the Hours with the Pricing to develop a requirement



Flying Hour Resource Model


Provide hours to Flying Hour Projection System



SEDRAM (Support Equipment Depot Readiness Assessment Model)

The model produces the total cost, cost per each subcategory and deferred maintenance.

Used to simulate the readiness impact of funding decisions: Readiness status of SE inventory and Cost of SE repairs




"What if" Analysis CNO Objectives/Metrics (Fleet Response Plan, TMDE Availability, Laboratory Readiness) wrt OMN Funding

Forecasting of NAVAIR 1C7C OMN calibration requirements



1B4B Ship Maintenance Summary

Ability to meet CNO Goals Ships Ready For Tasking

Assess programming and budget requirements and risk



Mission Funded Naval Shipyard Model

Requirement (Overhead Non-labor, Direct and Indirect Workforce FTE, Direct Non-labor) to execute assigned Workload

Calculate and Assess Maintenance requirements



Mission Funded Regional Maintenance Centers Model

Requirement (Overhead Non-labor, Direct and Indirect Workforce FTE, Direct Non-labor) to execute assigned Workload

Calculate and Assess Maintenance requirements



TYCOM Ship Maintenance Model

Requirement (CNO Availability, Continuous Maintenance, Emergent Maintenance, & Other Maintenance) to execute Ship Class Maintenance Plans

Calculate and Assess Maintenance requirements



V & H Ship Operations Model

Ship Operations Requirement to train and operate ships and submarines as required to support FRP Ao. Controls. Budget exhibits, SNaP Report.

Calculate Operations requirement, allocate fiscal controls, and create budget exhibits.



Aegis Optimization Model (AOM)

Shipboard Spares Allowance List

(1) Generate Readiness Based Sparing (RBS) List to optimize Operational Availability (Ao) at minimum cost (e.g., Shipboard Allowance, Installation and Checkout). This model can also optimize Ao for available storage space and/or weight limitations. (2) Assess potential system Ao for existing shipboard spares assets. (3) Determine probability of sustaining system operation for x (any set period) days with existing spares complement or other defined spares complements.

NAVSEA, PEO SHIPS FL [Model developed by Lockheed Martin. Navy has unrestricted government rights.]


Tiger-Availability Centered Inventory Model (Tiger-ACIM)

Shipboard Spares Allowance List

Generated Shipboard Readiness Based Sparing (RBS) List to optimize Operational Availability (Ao) at minimum cost.

NAVSUP, Mechanicsburg, PA


Multi-echelon Model

Wholesale Spares List

Generated wholesale level spares list that optimize Operational Availability (Ao) at minimum cost.

NAVSUP, Mechanicsburg, PA


Fleet Logistics Support Improvement Program (FLSIP) familyof models

Wholesale Spares List

Generated wholesale level spares list. This is a demand-based model.

NAVSUP, Mechanicsburg, PA



Life Cycle Spares Management and Life Cycle Sustainment Cost Projection Model. Following is a list of products: (1) Wholesale spares pipeline requirements/cost by year for total life cycle. (2) COTS/NDI life time support management tool, taking into account production window, repair support window, fielded systems lifetime support window, and asset re-use. (3) Diminishing Manufacturing Sources and Material Shortage (DMSMS) requirements and alternate solutions analysis. (4) Cost Of Ownership analysis. (5) Spares budget submissions and substantiation. (6) Return On Investment analysis. (7) Performance Based Logistics (PBL) contract spares level determination and spares quantities risk assessments. (8) PBL/Business Case Analysis (9) Alternate maintenance approach cost trade off analysis.

Technology Service Corporation, Fairfax, VA



MTBF and Sparing Analyses

Data to determine sparing levels



Relex Reliability Studio

Reliability Block Diagrams/LCC analysis, etc

Model the reliability of systems and determine/forecast LCC



Crystal Ball

Monte carlo simulations and outputs

Model the probability of outcomes for multiple variables




Decision support SW simulations

Simulations to support decisions



Microsoft® Excel

Model of system LCC, TOC, BCA, ROI, etc.

develop custom tool to determine LCC, TOC, BCA, ROI, etc.








LC2 from a Jim Jones Class (Logistics Management Associates)

Life Cycle Costing

Assist in predicting potential costs that may be incurred during ownership of an item or equipment



Horizon Solutions Suite

Diminishing Manufacturing Sources and Material Shortages (DMSMS)

The tool is used to monitor the life cycle status of parts (both Commercial-off-the-Shelf (COTS) and Mil-Spec), project system supply availability, assist with sustainment approaches, project cost of solutions alternatives, and manage DMSMS cases and metrics.




Maintenance Planning, provisioning, Reliability/Cost Tradeoffs

Logistics Support Analysis Modeling



Virtual Safety, Effectiveness, & Affordability Review (VSEAR)

Metrics for Safety, Effectiveness, Affordability

Review of Lifecycle issues impacting system safety, effectiveness, and affordability



Extend 7

Life Cycle Cost estimate

Life Cycle Cost




Life Cycle Cost estimate

Life Cycle Cost



Simulation Assisted Reliability Assessment

Reliability Estimates

Reliability Modeling

University of Maryland, Center for Advanced Life Cycle Engineering


MOSS Model

Life Cycle Cost estimate

Life Cycle Cost



Provisioning Estimate

Provision Depot Spares for SM



ILMF Resource Model

ILMF Resource Requirements

Determine Resources Needed



Logistics Model

GFM Requirements

Determine Resources Needed and Supply Chain Activity for Missile Assembly



Consolidated Obsolescence Management and Part Availability Support System (COMPASS)

Obsolescence "health" of STANDARD Missile (or other systems that may use this model)

Track and display the obsolescence "health" of the system down to the piece part level.



Future Obsolescence Cost Analysis System (FOCAS)

Future cost of NRE to resolve obsolescence issues

Project the cost of NRE to resolve obsolescence issues



Budget Line Item Stratification System (BLISS)

Stratification data for STANDARD Missile components

Stratify STANDARD Missile components for development of the program's spares budget



Computer Aided Spares Budget (CASB)

P18 forms for STANDARD Missile spares budget

Produce P18 spares budget forms for STANDARD Missile




The Joint Semi-Automated Forces (JSAF) system is an Air Force modeling-and-simulation application employed in various war games by the War Gaming Department at the Naval War College.

The Battlespace Applications Branch ( uses the Joint Semi-Automated Forces (JSAF) Model to provide positional and other Situational Awareness parameters to an integrated environment. These integrated environments are used to conduct Distributed Simulation Events in support of various Test & Evaluation customers. The War Gaming Department (WGD) conducts approximately 50 games a year. These events support internal College educational needs and externally-generated requests from Navy departments and operational commands, the Joint Services, foreign navies, and other sources. The business areas JSAF would best support are Command & Control and Training. JSAF is used in war games such as Urban Resolve 2015 and Northwest Pacific to provide simulated unit movement and tracking in a synthetic environment, and to provide that data to other applications such as GCCS and C2PC. These applications provide players with a common operational depiction of deployed forces for such purposes as force planning, force employment, and force laydown.


All war games are used to study some aspect of maritime and joint strategic and operational warfare. The games are sponsored by the college itself (education), by other naval commands, joint activities, and other defense agencies. The result in the war games is the ability for participants to understand and employ maritime operational strategy in a hostile environment, to examine strategic and operational issues, and to prepare for future naval preparedness.



System Reliability Prediction, Reliability Drivers System Maintainability Prediction

Provides for complete system reliability and maintainability analysis utilizing a reliability block diagram (RBD) or fault tree analysis (FTA) approach to obtain system results based on architecture and component data.




Measures component lifetime and reliability characteristics

Reliability and life data analysis (Weibull analysis)



RBS Suite

System Availability Prediction, Mission Spares Projection

Provides the capability for inventory allowance development to achieve specified weapon system Operational Availability (Ao) or Full Mission Capability (FMC) goals and minimize investment. It can also maximize readiness at a fixed cost. Optimizes ACIM .




System Reliability Prediction, Reliability Drivers System Maintainability Prediction

Monte Carlo type simulation tool which uses system reliability architecture and component reliability as an input to assess system reliability and identify readiness drivers




Reliability Block Diagrams, System Reliability Simulation model in TIGER format

Graphically create and edit Reliability Block Diagrams (RBD’s) and prepare initial input files to the TIGER simulation program




Mission Spares Projection

Computes spares using marginal analysis to optimize support for readiness drivers and to factor sparing cost



Obsolescence Management Information System (OMIS™)

Sustainability Assessment

Proactive monitoring to respond to system wide obsolescence incidents

NAVSEA, Keyport (N00253)



Generates simulated users of the website/portal

Simulates web site/portal users logged on/off or logging on/off

MARCORSYSCOM Product Group -10



Generates airflow/temperature data, gradients, hot/cold spots, and highlights deficient cooling/heating/ventilation areas

Heating, Ventilation, and Air Conditioning modeling/simulation

MARCORSYSCOM Product Group -10


Joint Communications Simulation System (JCSS) (formerly known as NETWARS)

Provides network speed, delays, latencies, and throttling/bottleneck areas in network pipes inside or outside the data center in question

Network modeling and simulation environment for the defense system networks

MARCORSYSCOM Product Group -10


System of Systems Analysis Toolset (SoSAT)

Support optimization decision support tool

Optimizes supply and sustainment support through modeling and simulation over a period of time of known and/or simulated RAM data and assists with validation of maintenance support concepts

PEO Land Systems PM JLTV


Total Life Cycle Management-Assessment Tool (TLCM-AT)

Run “what if” scenarios by manipulating the data inputs in order to see the long term effects to all elements of the life cycle

Model the myriad of industry accepted elements which directly affect the Operational Availability (Ao) of a system



Availability Centered Inventory Model (ACIM)


Computes maritime spares using marginal analysis to optimize support for readiness drivers at least cost




Readiness Assessment

Maritime simulation model (Monte Carlo-type) which uses Reliability Block Diagram information as an input to determine readiness drivers and project readiness



Aviation Readiness Requirements Oriented to Weapon Replaceable Assemblies (ARROWS)


Multi Echelon/Multi Indenture RBS sparing model for aviation weapon systems



Defense Sustainment Chain Operational Readiness Evaluator (D-SCORE)

Readiness Assessment

Simulates DoD’s entire sustainment value stream, from the operational level through intermediate level maintenance to wholesale supply and depot maintenance. It has a unique capability to evaluate alternative logistics process improvements in terms of results.



Computation and Research Evaluation System (CARES)

Wholesale Levels Analysis

Set of computer programs which emulate the performance of UICP (Uniform Inventory Control Point) to simulate wholesale stocking levels and project performance subject to budgetary constraints



Service Planning & Optimization (SPO)


Forecasts parts demand and determines optimal stocking lists and stocking levels at the lowest cost to achieve desired readiness goal



Simulation Package for Evaluation by Computer Techniques - Readiness, Utilization and Maintenance (SPECTRUM)

Series of Monte Carlo. Discrete Event simulation models that model all levels of Navy Maintenance (O, I and D). Also includes the suite of data processing and analysis programs that prepare AV-3M. Transaction History File (THF), and other data for input to the models and generate reports for validation and future analysis.

See Product Tool (Output)



Naval Aviation Maintenance and Supply Model (NAVSM)

Naval Aviation Maintenance and Supply Model (NAVSM) provides a modeling and simulation capability that will be used to assess and test sortie generation capabilities as well as associated manpower utilization. The effort includes representing processes and being able to accurately evaluate manning associated within AIMD, AIr Wing and Aviation Supply. The capability to analyze the impact of General Arrangement (ship design) and the resultant impact on Aviation Maintenance and Supply processes and manpower is also a key part of the overall effort. The end result of this work is the creation and evolution of a NAVSM that interfaces to other model components making up the CVN21 virtual Carrier in order to address the complex interdependencies of ship design, organizations and processes that must work together in order to support aviation operations to achieve sortie generation capabilities.

See Product Tool (Output)



Automated Cost Estimating Integrated Tool (ACEIT)

Cost Estimating

ACE is the estimating portion and heart of the ACEIT application suite. ACE is a model building tool consisting of a structured format for analysts to quickly structure their cost estimate and a calculation engine to quickly process the information.




Proactive cost, schedule and risk management

Insight is a business intelligence tool for analyzing, sharing, consolidating, and reporting earned value management data. Deltek provides integrated analytical and oversight tools for cost, schedule, and risk management.



Vmetric XL

Inventory Control Spare Parts End Items Costs Availability Defects (Materials)Repair

The Marine Corps is seeking to centralize the management of secondary repairables and is considering options that include centralizing responsibility and funding (while keeping the inventory model as it is) and changing the inventory model.



Reliasoft BlockSim

Reliability and Maintainability Analysis

BlockSim provides a comprehensive platform for complete system reliability and maintainability analysis utilizing a reliability block diagram (RBD) or fault tree analysis (FTA) approach to obtain system results based on component data.




Vulnerability/Lethality Analyses

An application toolset designed to help expedite vulnerability/lethality (V/L) analyses



Designer's Edge

Technology Based Training

Designer's Edge is a revolutionary set of integrated pre-authoring toolsets and wizards, built by instructional experts, to accelerate the analysis, design, and evaluation of effective technology based training.




Front end Analysis

Performs front end analysis and provides feedback on the life support costs and logistic performance of design alternatives to bring logistic concerns inside the systems engineering decision loop.



Integrated Computerized Deployment System (ICODES)

Ship stow planning

ICODES is the DOD cross service migration system for ship stow planning. It provides intelligent decision support to Army, Navy, and Marine Corps users during unit deployment operations. ICODES supports unknown vessels with a generic ship generating tool.




Network Modeling

Imprint is a dynamic, stochastic discrete event network modeling tool designed to help assess the interaction of soldier and system performance throughout the system life cycle from concept and design through field testing and system upgrades.




Vulnerability Assessments

Survivability Team Members use TREMOR to perform vulnerability assessments. This product is a visualizer of modeling inputs and is used to perform what/if scenarios required for Vulnerability Criticality Analysis tasks.




Quality Assurance, Corrective Action, and Nonconformance Reporting

TIP QA is an integrated suite of quality assurance applications designed to meet the unique quality assurance requirements in the manufacturing enterprise. PM AAA personnel use two (2) modules in TIP QA, the Corrective Action (CA) Module



Deltek Risk+™ for Project

Schedule and Risk Management

Deltek Risk+ is a comprehensive risk analysis tool that integrates seamlessly with Microsoft® Project to quantify the cost and schedule uncertainty associated with project plans.



@RISK for Project

Schedule and Risk Management

@RISK for Project uses Monte Carlo simulation to show you many possible outcomes in your project and tells you how likely these outcomes are to occur. You can determine which tasks are most important and then manage those risks appropriately.



@RISK for Excel

Cost, Schedule, and Risk Management

@RISK is a true add-in to Microsoft Excel, integrating completely with your spreadsheet. Browse, define, analyze while never leaving Excel.




The Evaluation of Mechanical Designs for Reliability

MechRel automates the use of the "Handbook of Reliability Prediction Procedures for Mechanical Equipment" and guides the user through the application of material properties, design parameters, and the intended operating environment to a conclusion




Statistical Analysis

Minitab Statistical Software gives you the tools you need to analyze your data and make informed decisions about how to improve your business. Minitab 15 gives you the statistical tools you need to analyze your data and improve quality in one easy-to-use




Metrics Management

A tool to support engineers and managers in the use and execution of the PSPSM and TSPSM; automates metrics collection and analysis. Personal Software Process, PSP, Team Software Process, and TSP are registered service marks of Carnegie Mellon University.



Total Life Cycle Management Assessment Tool (TLCM AT)

Decision Support

Decision support tool supporting development of budgets in support of weapon systems operations, as well as resource trade studies during acquisition logistics planning for future weapon system and throughout the life cycle to reduce life cycle cost



Model Name

Government POC (users)

Company/ Supplier

Functional Description

Programs and Purpose


Aircraft Total Life Cycle Assessment Software Tool (ATLASTTM)

PM Utility Helicopter for UH-60M, Lowell Bidwell 256-313-1616

Sean Connors, Clockwork Solutions 512-338-1945 x111

Tool to support Army aircraft overhaul and repair cost estimating using variables such as: flying hour programs by station location, component age and reliability, repair capacity and time, life limits, customer wait times, and spares acquisition schedules.

Program: UH-60M; Purpose: component reliability requirements, Availability



Members of ARDEC Reliability Mgmt Branch, POC is RMB Chief, Dr. Jason Cook,, 973-724-3930


Develop accelerated life testing plans and evaluates data to determine life estimates

Used to determine shelf and service life of ammo and weapon systems


AMSAA Reliability Growth Suite

Danielle Wayda, 586-574-6863,


This software is used to create reliability growth curves to project idealized growth. It also functions as a software tool to track reliability growth throughout testing.

This software will be used on the JLTV program in order to determine that the CDD reliability requirements are achievable. It will also be used to track vendor's growth throughout the various phases of the program.



PM Medium Altitude Endurance for Sky Warrior, Kirk McCollum, 256-313-5355

Rockwell Software

Ao Tool for analyzing complex, medium to large scale projects involving highly sensitive changes related to supply chain, manufacturing, processes, logistics, distribution, warehousing, and service systems.

Program: Sky Warrior UAS Purpose: Reliability, Availability performance requirements



Chris Bolton, PM-MEP 703-704-1995

Internal development

This model calculates the most efficient distribution of power sources and distribution equipment based on the physical layout of the using system, the power consuming equipment in use in that system, and the assumed duty cycles and mission profiles of that system. This produces a more accurate solution as opposed to taking nameplate power values or using peak power requirements.

We use this model on multiple generator fielding efforts to determine the most efficient allocation of generator and power distribution equipment. The Central Power concept for standardized Command Post organizations is a prime example. The number of generator sets is obviously a LCC driver for the user, but the average loading (and efficiency) of these sets drives fuel consumption, which is a much bigger element of total LCC.


Automated Cost Estimate – Integrated Tool (ACE-IT)

Used throughout the Army


A predictive cost modeling tool used to prepare Life Cycle Cost Estimates for Weapon Systems. The ACE-IT Model can respond to “what/if” excursions, estimating future costs based on a given scenario.

This model is required for all ACAT level I and II programs and is recommended for ACAT III programs.


Automated Cost Estimate – Integrated Tool (ACE-IT)

Maj Mike Mastria, USMC David Holm, Army 586-574-5680

Tecolote Research, Inc.

Tool for developing, sharing, analyzing, and reporting life cycle costs of the product of an acquisition program.

ACE-IT is being used on the JLTV program to evaluate the effect of program and design changes on life cycle cost.


Automated Cost Estimating Integrated Tools (ACE-IT)

Chris Waltsak 732-427-5936

Tecolote Research, Inc.

The Army’s Automated Cost Estimating Integrated Tools (ACE-IT) is an integrated tool suite designed to facilitate cost estimating. ACE-IT is an integrated tool suite of several software products specifically designed for the cost estimating community. Core features include a database to store technical and normalized cost data, a statistical package specifically tailored to facilitate cost estimating relationship (CER) development, and a uniquely designed spreadsheet that promotes structured, systematic model development and built-in government approved proven inflation, learning, time-phasing, documentation, sensitivity, what/if, risk, and other analysis capabilities. ACE-IT integrates all the necessary cost estimating functions but allows you to enter the process at any level.

We are using LCET as one of the tools to help us develop our Type II Business Case Analysis in pursuit of a Performance Based Logistic, Life Cycle Sustainment program for our target DCGS-A Mobile System


Automated Cost Estimating Integrated Tools (ACE-IT)

PM Unmanned Aircraft Systems; Kirk McCollum, 256-313-5355. PM Aviation Systems, PD Joint Cargo Aircraft; Mike Tesi, 256-313-3745

ASA(FMC) Army Cost and Economics

Tool for analyzing, developing, sharing, and reporting cost estimates, providing a framework to automate key analysis tasks and simplify/standardize the estimating process.

Program: Sky Warrior UAS, Joint Cargo Aircraft, Purpose: O&S cost estimation


Automatic Requirements Computation System Initial Provisioning (ARCSIP)

CECOM; Ken Steinberg, LEO-S-SM-P


The ARCSIP system is designed to automatically compute initial issue quantities (IIQ) consisting of order ship time, operating level, and safety level quantities for non-repairable items; and order ship time, operating level, safety level and turn around quantities for repairable items. Replenishment quantities are also computed. These are the gross quantities required to support an EI for up to 5 years for locally managed items, and for the first 12 months of deployment for non-locally managed items. In short, the system computes the support items required to support new EIs being fielded. Computation of the gross initial issue and replenishment quantities is accomplished by bringing together the PMR, the EIP file, the MMD file, the ARCSIP formulas based on DoD, DA, and Development and Readiness Command policies and regulations.



Members of ARDEC Reliability Mgmt Branch, POC is RMB Chief, Dr. Jason Cook,, 973-724-3930


Develop system reliability and availability models from component or failure mode level inputs for evaluation of system/platform or SoS level reliability and operational availability(Ao)

Determine compliance with requirements or assist in requirement validation and decomposition in areas of RAM. Also useful in testing sparing and repair strategies and optimizing CBM, applicable to any system type.


Computerized Optimization Model For Predicting and Analyzing Support Structure (COMPASS)

Bill Colon


The Computerized Optimization Model for Predicting and Analyzing Support Structures (COMPASS) is the Army standard Level of Repair analysis (LORA) model that optimizes maintenance concepts to achieve an end item Operational Availability (Ao) at the least total ownership cost. A LORA determines where each item is cost effectively repaired. SESAME algorithms are embedded in COMPASS to simultaneously optimize maintenance and supply support. COMPASS was designed to determine steady state, full deployment LORA and SORA decisions by comparing the net present value logistics cost estimates that vary by maintenance policy. COMPASS requires information about the line replaceable units (LRUs) used to restore the end item and higher failure rate shop replaceable units (SRUs) used to repair LRUs. It has the fidelity to permit a RAM analysis of the detailed design to show life cycle support cost impacts associated with each item modeled in the equipment. Support costs associated with design improvements can be compared to the baseline design to assess the improvement's potential to reduce life cycle support costs. This helps supportability analysis to become an integral part of systems engineering.

COMPASS enables supportability optimization prior to fielding. COMPASS can also be used as a source of repair analysis (SORA) model. A SORA model determines how each item is cost effectively repaired. COMPASS can be used to compare the total costs associated with government depot repair versus contractor depot maintenance in achieving the same Ao goal. A best value analysis would apply to non-core depot work.


Computerized Optimization Model For Predicting and Analyzing Support/ Structure (COMPASS)

Chris Waltsak 732-427-5936


The Computerized Optimization Model for Predicting and Analyzing Support Structures or COMPASS is an Army approved, PC-based computer model, sponsored by the U.S. Army Logistics Support Activity (LOGSA), and is designed to assist analysts in conducting a variety of system support studies. The objective of COMPASS is to simultaneously optimize both the maintenance concept and supply while achieving a given operational availability goal. The COMPASS mode provides quantitative analysis of the different hardware product support strategies.

We are using LCET as one of the tools to help us develop our Type II Business Case Analysis in pursuit of a Performance Based Logistic, Life Cycle Sustainment program for our target DCGS-A Mobile System.


Computerized Optimization Model For Predicting and Analyzing Support/ Structure (COMPASS)

Mark D. Patrizi 256-955-6310,


Level of Repair Analysis (LORA) model which provides the optimal, least cost maintenance policy for a weapon system. Utilizes system part specific information such as reliability, availability, and maintainability data to determine best repair locations and resources required (spares, repairmen, and support equipment).

COMPASS is utilized by many programs to determine optimal maintenance policies. Recently, the software was used to perform LORA on systems such as the AH-64A, CH-47D, CROWS, and Prophet. 2200 (CECOM, TACOM, AMCOM, AMSAA, AEC, KEM PO, MEADS PO, GMD Joint PO, JPM Lightweight Howitzer, Precision Fires PO, PEO CBD, Naval Aviation Weapons Center, PM Multi-Spectrum Sensors, PM Prophet, Others)


Computerized Optimization Model For Predicting and Analyzing Support/ Structure (COMPASS)

PM Utility Helicopter for UH-60M PM Cargo Helicopter for CH-47F. POC: Joe Ketron, 256-955-0238 PM Apache Attack Helicopter for AH-64D and Apache Block III 256-313-4988 PM Aviation Systems, PD Joint Cargo Aircraft Mike Tesi, 256-313-3745

LOGSA Logistics and Engineering Center

Analytical methodology used to determine the maintenance level where the removal and replacement, repair, or the discard of an item should be performed.

Program: UH-60M, CH-47F, AH-64D, Apache Block III, Sky Warrior, JCA Purpose: Availability, O&S Cost estimation


Computerized Optimization Model for Predicting and Analyzing Support Structures (COMPASS)

ATEC-AEC-ILSED Wayne Patterson 410-306-0357


Level of Repair Analysis (LORA) model that determines the optimal system level maintenance policy to meet a weapon system/end item operational performance target.

Used on numerous programs to conduct Level of Repair Analyses (LORA) and to evaluate system maintenance concepts.


Computerized Optimization Model for Predicting and Analyzing Support Structures (COMPASS)

Vincent DiNicola 732-532-4565 DSN 992-4565 Vincent,

US AMC –Logsa: Logistic Support Activity.

COMPASS is a model designed to assist the analyst in conducting a Level Of Repair Analysis (LORA) study and is the Army's approved system-level LORA model. The COMPASS program will identify the most cost effective maintenance concept.

LORA is an analytical methodology used to establish the maintenance level at which an item will be replaced, repaired or discarded. These decisions are based upon operational readiness requirements. LORA determines the most cost effective maintenance concept for a system.


Computerized Optimization Model For Predicting and Analyzing Support Structure (COMPASS) Level of Repair Analysis (LORA)

Terri Schwierling, 256-876-3561,

COMPASS is a PC based computer model designed to assist in conducting a Level of Repair Analysis (LORA). LORA is an analytical methodology used to determine the maintenance level where the removal and replacement, repair, and/or discard of an item should be performed. COMPASS is the Army approved system level LORA model.

Multiple Programs


Cost Analysis Strategy and Assessment Model (CASA)

Terri Schwierling, (256) 876-3561,

Life Cycle Cost (LCC)/Total Ownership Cost (TOC) decision support tool. CASA covers the entire life cycle of the system, from initial research cost to those associated with yearly maintenance, as well as spares, training cost and other expenses.

Multiple Programs


Cost Analysis Strategy Assessment (CASA)

Phil Paschel, 256-955-9922,


Life cycle cost model and systems engineering decision support tool that calculates total cost of ownership from initial design until disposal with a focus on the detailed cost elements over the operational life of a system. Extensive trade off and sensitivity analysis capabilities for "gaming" cost impacts of support concepts, spares provisioning, reliability growth, availability, production rates, etc.

CASA is used by many PMs throughout DoD and their support contractors to evaluate the life cycle cost impacts of different design and support alternatives and to identify cost drivers in accordance with sound systems engineering guidance. 1400 registered users from many different PMs and support organizations (e.g., CECOM, TACOM, AMCOM, PM FCS, PM Blackhawk, Joint GMD, Navy, Air Force, NASA)


Joint Integrated Analysis Tool

Daniel L. Schwartz (703)

Office of the Deputy Assistant Secretary of the Army –Cost and Economics ( HQDA – ASA(FM&C)

The Joint Integrated Analysis Tool (JIAT) concept is an architecture that allows models in the functional areas of cost estimating, engineering design, requirements, capability, and performance analysis to be linked together. JIAT provides a near realtime cost estimating capability to the acquisition, requirements modeling and simulation (M&S) and communities. JIAT provides the capabilities for cost and requirements analysts to develop cost estimates and perform cost performance trades at the system level with the limited amounts of data available early in a program’s lifecycle.

Users of JIAT will be able to perform life cycle cost analysis which can include early design concept data such as performance and capabilities based costing. JIAT incorporates various analytical models to perform trade-off analysis with optimization techniques. JIAT will also benefit requirements analysts and engineers in developing cost estimates.


Laser HELLFIRE Integrated Flight Simulation (IFS)

Jim Utterback 256-876-4618

Lockheed Martin & U.S. Army

Life cycle system analysis tool used to evaluate performance of the Laser HELLFIRE system throughout the system lifecycle from product improvements, operations and maintenance and end of the system.

Used on the Laser HELLFIRE Missile System to support product improvements, testing, system analysis, and assessment of system performance.


Logistics Analysis Model (LOGAM)

PM Utility Helicopter Lowell Bidwell 256-313-1616

SPARTA, Inc., endorsed by LOGSA

Forecast logistics support parameters and operating and sustainment costs associated with the system’s evolving design when supported by alternate envisioned maintenance concepts.

Program: UH-60M Purpose: O&S cost estimation


Logistics Cost Estimating Tool (LCET)

Bill Colon


LCET estimates logistics costs for a weapon system. The logistics costs are broken into 25 cost categories listed on their website. LCET can be used to establish a logistics cost baseline and to quantify cost savings resulting from improvements and changes to the weapon system and the way it is supported.

LCET uses operating hours and mean time between failures (MTBFs) to calculate some of the logistics costs. It can also be used to evaluate a weapon system's logistics costs associated with different proposals in a source selection.


Logistics Cost Estimating Tool (LCET)

Chris Waltsak 732-427-5936

Gov. Provided Software

The CECOM Logistics Cost Estimating Tool (LCET) is an estimating tool for weapon systems, was used in conjunction with COMPASS to assist in time phased analysis and display of data. The Logistics Cost Estimating Tool (LCET) estimates the logistics costs for a weapon system. The logistics costs are broken into 25 cost categories, which are shown below: 1. Military Operators 2. Energy (Batteries/Petroleum) 3. Field Support (Material Fielding & Logistics Assistance) 4. Organic Repair Labor * 5. Contractor Repair and Other Contractor Logistics Support * 6. Warranty Costs 7. Scheduled Maintenance and Overhaul 8. Initial Provisioning Spares * 9. Replenishment Spares * 10. Inventory Holding Costs * 11. Support Equipment * 12. Test Program Sets * 13. Training 14. Training Material 15. Post Deployment Software Support 16. Technical Documentation * 17. Transportation ** 18. Integrated Material Management ** 19. Post Production Project Management 20. System Hardware Changes 21. Facilities/Site Activation 22. System Specific Base Operation 23. Leases 24. Demilitarization and Disposal 25. Industrial Readiness LCET consists of two modules: Time Phased (TP) COMPASS and the Logistics Cost Spreadsheet. You may use the Logistics Cost Spreadsheet in conjunction with Time Phased COMPASS or as a stand-alone tool. Using it in conjunction with Time Phased COMPASS requires more detailed data but will provide a better cost estimate than using it as a stand-alone tool. The Army’s Automated Cost Estimating Integrated Tools (ACE-IT) is an integrated tool suite designed to facilitate cost estimating. ACE-IT is an integrated tool suite of several software products specifically designed for the cost estimating community. Core features include a database to store technical and (normalized) cost data, statistical package specifically tailored to facilitate cost estimating relationship (CER) development and a uniquely designed spreadsheet that promotes structured, systematic model development, and built in government approved proven inflation, learning, time phasing, documentation, sensitivity, what/if, risk and other analysis capabilities. ACE-IT integrates all the necessary cost estimating functions but allows you to enter the process at any level.

We are using LCET as one of the tools to help us develop our Type II Business Case Analysis in pursuit of a Performance Based Logistic, Life Cycle Sustainment program for our target DCGS-A Mobile System


Logistics Cost Estimating Tool (LCET)

Bill Colon


LCET estimates logistics costs for a weapon system. The logistics costs are broken into 25 cost categories listed on their website. LCET can be used to establish a logistics cost baseline and to quantify cost savings resulting from improvements and changes to the weapon system and the way it is supported.

LCET uses operating hours and mean time between failures (MTBFs) to calculate some of the logistics costs. It can also be used to evaluate a weapon system's logistics costs associated with different proposals in a source selection.


Logistics Cost Estimating Tool (LCET)

Chester Shadovitz 732-532-1222 DSN: 992-1222

LCMC-G3/5, Systems Analysis Division

LCET estimates the logistics costs for a weapon system. The logistics costs are broken into 25 cost categories.

LCET can be used to establish a logistics cost baseline and to quantify cost savings resulting from improvements and changes to the weapon system and the way it is supported. It can also be used to evaluate a weapon system's logistics costs associated with different proposals in a source selection.


Longbow HELLFIRE Simulation

Jim Utterback 256-876-4618

U.S. Army

Life cycle system analysis tool used to evaluate performance of the Longbow HELLFIRE system throughout the operations and maintenance and end of the system lifecycle phases.

Used on the Longbow HELLFIRE Missile System to support testing, system analysis, and assessment of system performance.



Members of ARDEC Reliability Mgmt Branch POC is RMB Chief, Dr. Jason Cook, 973-724-3930

Minitab, Inc.

Statistical SW package for DoE and other statistical analysis methods

Used for DoE, LSS, SPC, and similar. Not unique to any specific system type.


Multi-Attribute Decision Methodology (MADM)

Chuck Wong 732-532-5170 DSN: 992-5170

LCMC – G3/5 Systems Analysis Division

MADM is an analysis approach based on Decision Theory that evaluates multiple decision criteria including cost on the same scale.

Its objective is to evaluate the combined results of cost savings and other non-cost related evaluation criteria to determine the Best Value alternatives in support of decision making.


Operation & Support Management Information System (OSMIS)

Used throughout the Army


A tracking tool of operation and support needs and costs for various Army Weapon programs

Tool can be used by using actual data as a means to estimate future costs.


Optimum Stock Requirements Analysis program (OSRAP)

ATEC-AEC-ILSED Wayne Patterson 410-306-0357


Stock computation model that uses Readiness Based Sparing to provide a package of spare parts optimized on cost, weight or volume while targeting operational availability. Handles multiple systems, is less data intensive than SESAME, and supports wartime environment.

Used for virtually any set of end items to conduct footprint analysis, primarily for Class IX, but can be expanded to include other classes of supply.


Optimum Stock Requirements Analysis Program (OSRAP)

Charlotte Evering 410-278-4980


Stock computation model that uses Readiness Based Sparing to provide a package of spare parts optimized on cost, weight or volume while targeting operational availability. Handles multiple systems, is less data intensive than SESAME, and supports wartime environment.

Used for virtually any set of end items to conduct logistics footprint analysis, primarily for Class IX, but can be expanded to include other classes of supply. Model outputs include a recommended parts list, overall summary of the unit, cost drivers, weight and volume drivers, and additional “plus up” quantities needed for the unit to sustain the target readiness rate. Other analyses can be performed based on sensitivity to readiness, cost, weight, or volume. OSRAP is incorporated into the war reserve process (LMP) through its requirements determination module (RDM). OSRAP is used to calculate the Army Prepositioned Stocks, OPLAN sustainability analyses, Deployment Stock Packages (DSP) where the input parts file is tailored specifically to the unit’s past demands, Customer Support Requirements Lists (CSRL), and logistics footprint and concept exploration analyses in assessing Analysis of Alternatives (AoA) of conceptual systems against current unit force structures.


OV Parser

Pat Degroodt 732-532-8229

General Dynamics C4 Systems 400 John Quincy Adams Rd. Taunton, MA 02780-1069

The Government Furnished Software (GFS) OV parser outputs a spreadsheet containing utilization and throughput metrics based on tiers and resources. Information such as tier utilization (ground to ground), resource utilization, and average tier throughput (ground and space) are presented in the spreadsheet. Tier utilization is a percentage of how much of the ground tier is being utilized. Resource utilization is a percentage of how much each non CI resources are being used in the scenario. The average tier throughput indicates how many bps each tier is handling.

PM WIN-T uses the OV parser to provide information that is extremely valuable and helps to determine how to best optimize the network. If the ground tier is over utilized, the plan can be modified to relay traffic using other tiers (space) to help alleviate the ground network and vice versa.


Port Operational Performance Simulator (POPS)

Arthur Murray DSN 770-5191

Surface Deployment and Distribution Command Transportation Engineering Agency

POPS is an equation based calculator of the throughput capacity of an ocean terminal. POPS performs a weakest link analysis of port cargo movement in which each subsystem is analyzed separately and then compared to find aggregate seaport throughput.

POPS is used across the full spectrum of planning and programmatic mobility studies.


Port Simulation Model (PORTSIM)

Kaye Aldrich DSN 770-5206

MYMIC 200 High Street, Suite 308 Portsmouth, Virginia 23704-3721 USA

PORTSIM models the reception, staging, and ship loading of military equipment at seaports of embarkation (SPOE) and ship offloading, staging, and port clearance of military equipment at seaports of debarkation (SPOD).

PORTSIM can be used across the full spectrum of both planning and programmatic mobility studies.



Dave Leciston

 Future M&S Tool

Software life cycle modeling of the DCGS-A program



Bob Daniell 732-861-1487


Business Process development using the SCOR, DCOR and CCOR business process reference models to address PBL, Systems Engineering and the Industrial Base

We use this tool to build models addressing physical and logical mappings, functional decompositions, RASCI, disconnect analysis along the life cycle of a weapons system or commodity. Very helpful in establishing PBL configurations. It incorporates the SCOR, DCOR and CCOR models to provide standardized nomenclature, metrics, best practices across TLCSM



Mark Barboza, Jenna Romatowski, Chris DeVries, Roberto Flores, Allison Waltsak 732-532-9129


Designed to support and fast track business transformation projects, ProcessWizard complements project methodologies like Value Chain Excellence. ProcessWizard allows you to capture your analysis in a packaged, robust and reusable business improvement.

ProcessWizard is a process modeling and enterprise architecture tool containing de facto standard industry frameworks. ProcessWizard is particularly powerful for Supply Chain (SCM), Design Chain (PLM), Customer Chain (CRM) and Value Chain (VCM)



R. Giuntini Business Process development using the SCOR®, DCOR and CCOR business process reference models to address PBL, Systems Engineering and the Industrial Base


Uses Activity Based Costing (ABC), similar to Earned Value, in identifying all the cost drivers and their resources; this technique is viewed as best practice in commercial world. All findings and conclusions are validated in proprietary data base.

SCOR® is a registered trademark of the Supply Chain Council, Inc.

Has been used for Army Future Warrior, GD, LM, DynCorp, and others



R. Kaminski


RAPTOR is a Monte Carlo simulation program used to model reliability and availability of complex systems with extensive interdependencies.

RAPTOR is used to model system reliability and availability and conduct trade studies and predict reliability and availability performance.



R. Kaminski


RELEX is a multi-suite toolset for performing a wide variety of reliability, maintainability, and availability analyses.

RELEX is used to perform reliability prediction, FMECA, and maintainability analysis.



Members of ARDEC Reliability Mgmt Branch POC is RMB Chief, Dr. Jason Cook, 973-724-3930


Develop plans for and analyze data from reliability growth testing.

To determine reliability of system and determine test and management methods required to achieve reliability targets


Scenario Manager

Pat Degroodt 732-532-8229

General Dynamics C4 Systems 400 John Quincy Adams Rd. Taunton, MA 02780-1069

The Scenario Manager tool runs inside OPNET Modeler as a customized feature. Any topology variations can then be made directly to OPNET modeler. The tool reads the force structure file and outputs node information (positions, trajectories, etc.) and then it determines the links for the scenario based on user selectable link creation algorithms. Rain effects along with various blockage algorithms, as well as hardware policies based on the node’s mobility state can be used to affect the links.


Scenario Manager Path Trace Tool

Pat Degroodt 732-532-8229

Produces route information for each communicating pair of nodes in a scenario.

Generates inputs to WAN Path Reliability Tool.



DASA-CE Sean Vessey 703-601-4150 TACOM Cost & Systems Ron Dicesare

Galorath Incorporated

This software is an estimating tool used to create independent manufacturing cost estimates, sanity checks, and to analyze contractor estimates.

SEER is primarily used in support of FCS C4ISR manufacturing estimates, and sanity checks. It is being evaluated to see if we can use it to support JLTV depending on the software requirements for JLTV. Our office also needs SEER to communicate with other organizations like CECOM that use SEER as their primary estimating methodology.


SEER for Hardware, Electronics, & Systems (SEER HW)

Galorath Incorporated

SEER for Hardware, Electronics, & Systems (SEER HW) is a decision support tool that reliably and accurately estimates the total cost of ownership for new product development projects.


SEER for Manufacturing (SEER MFG)

Galorath Incorporated

SEER for Manufacturing (SEER MFG) focuses on manufacturing project and process options, and can be used to model virtually any manufacturing operation.



Galorath Incorporated 

SEER-RateMakerTM, a calculation tool used for generating labor and machine tool rates for individual and manufacturing processes across organizations continents. SEER-RateMaker is designed to generate labor and machine cost rates to assist the estimating process, helping to control costs and maintain both supplier and purchaser companies' profitability.


Selectable Essential Item Stock and Availability Method (SESAME)

PM Utility Helicopter for UH-60M : Lowell Bidwell, 256-313-1616 PM Cargo Helicopter for CH-47F: Joe Bogema 256-876-4625

AMSAA is the proponent. Contact:

Decision tools on budgeting and stocking to achieve a system Operational Availability (Ao) performance goal at the least cost, and identify the initial provisioning requirement for spares prior to production to determine what items should be placed at which support levels when fielding of the systems.

Program: UH-60M, CH-47F, AH-64D, Apache Block III, Sky Warrior, JCA

Purpose: see functional description


Selected Essential item Stockage for Availability Method (SESAME)

SESAME model minimizes the initial provisioning cost for spares to meet an Ao requirement or maximizes Ao to a budgeted cost. SESAME can also estimate an end item Ao based on proposed sparing; experienced, contracted or proposed logistics response times; and experienced or proposed reliability and maintainability. If item level data is attainable, the acquisition community can potentially use SESAME to evaluate the end item Ao proposed in source selections. The Test and Evaluation community can also evaluate Ao from experienced test results.


Selected Essential Item Stockage for Availability Methodology (SESAME)

Terri Schwierling, (256) 876-3561,

Multi-Echelon, Multi-Indenture Inventory Model that determines the Optimal Range & Depth of Spares/Repair parts at all locations in order to meet either a Weapon System/End Item Budget Constraint or Operational Performance Target. AR 700-18 Provisioning of US Army Equipment mandates use of SESAME for Initial Provisioning Requirement Determination.

Multiple Programs


Selected Essential Item Stockage To Availability Method (SESAME)

Julio Tejeda 732-532-8903 DSN: 992-8903

U.S. AMSAA Attn: AMSRD-AMS-LL 392 Hopkins Rd. APG, MD 21005; DSN: 298-9309 or 298-4359

SESAME is the Army’s approved tool for determining the initial spares needed to support a weapon system that is being fielded. SESAME determines the optimal (i.e., least cost) quantities of spares that will achieve desired operational availability (Ao) for the weapon system.

The output of SESAME tells you the optimal quantities and cost of retail spares at each maintenance shop to achieve your Ao. It also gives you quantities and cost of wholesale spares.


Selected Essential Stock for Availability Method (SESAME)

Charlotte Evering 410-278-4980


Multi-echelon, multi-indenture level inventory cost model that determines the optimal range and depth of spares and repair parts at all locations in order to meet either a weapon system/end item budget constraint or operational performance target.

Used on numerous programs to conduct provisioning analyses and to determine lists of initial provisioning for systems to be fielded. Can be used to answer provisioning issues, such as, "How much should I pay to reduce OST?", “How can I evaluate the added value of a warranty?", "Does commonality affect the level of spares required?", "What happens if OPTEMPO changes?", "What operational availability can I achieve with my limited budget?", "How does improved reliability affect my spares budget?", and "What support structure works best for me?" Mandated for use for initial provisioning in AR700-18 and AR700-127.


Selected Essential Stock for Availability Method (SESAME)

ATEC-AEC-ILSED Wayne Patterson 410-306-0357


Inventory model that determines the optimal range and depth of spares and repair parts at all locations in order to meet either a weapon system/end item budget constraint or operational performance target.

Used on numerous programs to conduct provisioning analyses and to determine lists of initial provisioning for systems to be fielded.


Selected Essential Stock for Availability Method (SESAME)

Bill Colon


The Selected Essential-item Stock for Availability Method (SESAME) model is the Army standard initial provisioning model that optimizes the mix and placement of spares to achieve an end item Ao requirement or the maximum Ao for a dollar goal input.

SESAME's readiness goal is achieved at a minimum cost or the maximum amount of readiness is bought for an initial provisioning budget. To use SESAME, the maintenance concept for each essential item must be known or proposed. SESAME can also be used in an evaluation mode to estimate the Ao being proposed or experienced. This Ao is based on the proposed sparing of items, their demand rate and logistics response times associated with their support concept. The Assistant Secretary of the Army for Acquisition, Logistics and Technology strongly encourages using SESAME to determine initial spares requirements.


Selected Essential Stock for Availability Method Life Cycle Cost Model (SESLCC)

Charlotte Evering 410-278-4980


Computer model that uses SESAME calculated initial stock lists, deployment schedules, and reliability and maintenance data to compute the expected initial issue spares and repair parts, replacement of consumed parts, repair of reparable items, transportation costs, and retrograde costs portion of the weapon system's life cycle costs throughout its useful life.

Computes the expected life cycle costs for the enterprise's supply and maintenance system (the service supply chain) that will be supporting a weapon system/end item throughout its useful life. Outputs can be used directly to evaluate alternative equipment, reliability improvement, and/or service supply chain decisions or as input to actionable Total Cost of Ownership analyses. Can aid in evaluating the tradeoff between spare and repair part reliability improvements and the associated reduction in the life cycle service supply chain costs. Can be used for virtually any end item or weapon system to all estimate significant O&S costs that are reliability driven.


Selected Essential Stock for Availability Methodology Life Cycle Cost Model (SESLCC)

ATEC-AEC-ILSED Wayne Patterson 410-306-0357


Computer model that uses SESAME calculated initial stock lists, deployment schedules, and reliability and maintenance data to compute the expected life cycle costs of a system's supply and maintenance that will be supporting a weapon system throughout its useful life.

Can be used for virtually any end item or weapon system to all estimate significant O&S costs that are reliability driven.



Natalie Palm 732-532-0425 DSN: 992-0425

CACI International Inc. 1100 North Glebe Rd. Arlington, VA 22201

SIMPROCESS is a hierarchical and integrated process simulation tool developed by CACI International Inc. It combines the simplicity of flowcharting with the power of simulation, statistical analysis, Activity Based Costing (ABC), and animation. It is designed to analyze varied scenarios and to mitigate the risk associated with dynamically changing environments. SIMPROCESS builds a model describing how a system works.

The software can be used for analysis of process reengineering changes, six sigma analyses, and also for the PBL Analyses of metrics.


Support Enterprise Model (SEM)

Peter Haniak 586-574-8671

Sandia National Laboratory

A logistics modeling, analysis, optimization, and decision support tool

PEO-GCS is assessing utility of the tool. Provides integrated modeling of supply chain and repair chain activities for a worldwide support system


System of System Availability Model (SoSAM)

John Conolly 410-278-5720


SoSAM is discrete event based model, developed using ARENA simulation software that produces operational availability, based on reliability failures, of ground and aerial assets in a future force scenario.

SoSAM simulates the mission profile and generates reliability failures for each asset. Through simulation, downed assets are recovered, required parts are obtained, repairs completed and the asset is returned to duty. Principle outputs of the model are the instantaneous and average availability over the scenario, instantaneous and average number of failures, and average mechanic utilization by system and/or class. Outputs can be used directly to evaluate system availability based on proposed reliability and perform "what/if" analyses based on reliability improvement programs. Can be used for virtually any end item(s) in various unit structures (FBCT, HBCT, IBCT) and scenarios.


System of Systems Analysis Tool Set (SoSAT)

Peter Haniak 586-574-8671

Sandia National Laboratory

SoSAT is a suite of software tools designed to provide a capability to analyze performance and interrelationships of a System of Systems and it’s various subsystems using State Object Models

Used by PEO-GCS fleet wide. Used for System of System Analysis of Brigade Combat Teams


System of Systems Analysis Tool Set (SoSAT)

ATEC-AEC-ILSED Wayne Patterson 410-306-0357 ATEC-AEC-RAM

Sandia National Labs

Dynamic, time step simulation tool designed to perform platform, family and system of system sustainability analysis for the Future Combat System (FCS).

Designed specifically to perform a wide range of sustainability analyses for the Future Combat System (FCS).


System of Systems Availability Model (SoSAM)

ATEC-AEC-ILSED Wayne Patterson 410-306-0357


Discrete event based flow diagram model, written in ARENA software, to estimate operational availability based on reliability of assets.

Model logic was written specifically for the FCS program, but can be modified to for other systems.


Transportability Analysis Reports Generator (TARGET)

Joyce Banovz DSN 770-5803

Argonne National Laboratory

TARGET is a group of models and programs that provide the capability to detail unit movement requirements at the individual item level of detail (level 6). The TARGET system merges force structure databases with equipment characteristics for either Army or Marine Corps units.

TARGET can be used across the full spectrum of both planning and programmatic mobility studies.


True Planning/PRICE Estimating Suite

DASA-CE Sean Vessey 703-601-4150 TACOM Cost & Systems Ron Dicesare

PRICE Systems

This software is an estimating tool used to create independent manufacturing cost estimates, sanity checks, and to analyze contractor estimates.

True Planning is used primarily in support of FCS MGV and C4ISR manufacturing estimates, and sanity checks. It is being evaluated to see if we can use it to support JLTV as another tool to sanity check our ACEIT cost estimate. Our office also needs PRICE to communicate with contractors that use PRICE as their primary estimating methodology.


UNIfied Probabilistic Assessment Software System (UNIPASS)

Members of ARDEC POC is RFFF APO and Rel. Egr. Competency Dean Mr. Bob Kuper 201-572-4085

PredictionProbe, Inc.

Perform system or component modeling. Quantify Risk, Reliability, Safety thru Uncertainty Quantification and Modeling. Provides Robust Design Analysis, Optimization, etc.. Easily integrates with any computational engine like Finite element, thermal analysis, Computational Fluid Dynamics (CFD), etc. Provides most likely outcomes (MPP), computes probabilities (CDF/PDF, inverse probability, Robust Design, quantitative Risk analysis, IDs key process drivers, etc. Contains libraries of 61 math functions, 15 probability distributions, Goodness of Fit tests; numerous methods for parameters estimation etc.

This model is used on many weapon and ammo life cycle programs inclusive of Tech base through development and production, Operational life, etc.


Visual Growth

Dr. David Mortin


Contains AMSAA reliability growth models for planning, tracking, and projection.

Used by multiple contractors and government organizations to develop reliability growth plans and assessments.


WAN Path Reliability Tool

Pat Degroodt 732-532-8229

General Dynamics C4 Systems 400 John Quincy Adams Rd. Taunton, MA 02780-1069

Includes three tool subsets which take information from various OPNET Simulation Outputs and uses this information to create the Wide Area Network (WAN) module and connectivity sampling events used in the Transmission Link Reliability Experiment.

Utilized as input to the HyPerformix File Generator Tool



Members of ARDEC Reliability Mgmt Branch POC is RMB Chief, Dr. Jason Cook,


Develop component or failure mode specific reliability estimates

Analyzing life data of any system type


WIN-T Inc 2/3 OPNET Models – OPNET Modeler Latest Released Versions:Inc2 CDR OPNET Modeler ver 11.5 Inc3 PDR OPNET Modeler ver 11.5 Potential migration to OPNET Modeler ver 14.5

Pat Degroodt 732-532-8229

OPNET Technologies, Inc. 7255 Woodmont Avenue Bethesda, MD 20814 Node models and Process models are custom tailored for PM WIN-T by General Dynamics C4 Sy

OPNET Modeler® accelerates network R&D, reduces time to market, and improves product quality. Using simulation, network designers reduce research costs and ensure optimal product quality. OPNET Modeler’s cutting edge technology provides an environment for designing protocols and technologies as well as testing and demonstrating designs in realistic scenarios prior to production. OPNET Modeler is used to enhance the design of network devices, technologies such as VoIP, TCP, OSPFv3, MPLS, IPv6, and much more.

PM WIN-T uses the OPNET simulation environment to model the WIN-T Inc 2 and Inc 3 networks. The following is a list of Node Models and Process Models that were developed in OPNET specifically for the WIN-T networks:

  • Node Models
  • WAN Router Model
  • Satellite Node
  • Network Topology File Based Interface (NTFBI)
  • WIN-T Config Node (Scenario Manager)
  • QED (QoS Edge Device) Node Traffic Generator Node Process Models
  • Highband Networking Waveform (HNW) Radio
  • Fixed Rate Radio (FRR) Network Centric Waveform (NCW) Radio
  • Multi-Link Radio Child (used within both HNW and NCW Radio models)
  • OPNET Router – LAN and WAN
  • Traffic Generator Model
  • IP (Internet Protocol) Model
  • Open Shortest Path First (OSPF) Protocol (OSPF_v2)
  • Network Blockage Infrastructure (formerly Physics)
  • WIN-T Position Updater
  • WIN-T Process Model
  • QED Sensor


WIN-T INC 2/3 System Network Reliability Models – Hyperformix Workbench Discrete Event Simulator Latest Released Versions: Inc3 PDR

Pat Degroodt 732-532-8229

HyPerformix, Inc. 4301 Westbank Drive Building A, Suite 300 Austin, TX 78746-6564 Office: 512.328.5544

Hyperformix Workbench is a discrete event simulation tool that is used to create the Network reliability model. As a founding simulation product of HyPerformix, SES/workbench is used worldwide to solve hardware, software and networking problems, particularly performance and resource allocation problems. It is the ultimate product for solving architectural and design problems involving all three elements: hardware, software, and network. Study is ongoing whether workbench can support simulation of force size comparable to Major Theater of Operations.

The PM WIN-T Network Reliability Model is used for all network reliability experiments, which are designed to support the architecture design and the development of sparing and maintenance strategies. The model is used to compute the WIN-T Network Reliability values for both on the move (OTM) and at-the-halt (ATH) configurations. The WIN-t NW Reliability Model is built around the Hyperformix Workbench tool.

Air Force

Model Name

Government POC (users/owners)

Programs and Purpose

Functional Description


Aging Aircraft Model


Scenarios to be predicted

A Rough Order of Magnitude (ROM) Model that can be used to explore the economic and capability conditions needed to justify a recapitalization decision. In house tool developed in Microsoft® Excel


Air Force Total Ownership Cost (AFTOC)


Transportation Supply Maintenance Readiness Munitions

Used to track consumption of assets for Cost Per Flying Hour (CPFH). Air Staff directed in support of SRRB process.


Airborne Laser On-Station Availability Model (ABL OSA)


Operational/Maintenance Readiness

ABL OSA is a simulation model developed at OAS to estimate the on station availability of the ABL. The model considers laser fuel support equipment availability, inventory levels, ABL deployment scenarious as well as ABL mission parameters.


AIRCAT Center Wing Box Management Tool



Used to predict C-130 equivalent baseline hour consumption based on ops tempo in order to forecast when the aircraft will reach its grounding point. Essential in managing flying hours so aircraft don't ground prior to scheduled center wing box replacement date.


Aircraft Sustainability Model



Computes optimized quantity requirements for deployable aircraft spares kits given a flying hour scenario. Also assesses readiness spares kits for Status of Resources and Training System (SORTS) in terms of predicted aircraft availability.


ASC Logistics Composite Model (LCOM)


Part of the Air Force Standard Analysis Toolkit (AFSAT), general logistics related questions at AF/A9

Sustainment simulation tool used to assess weapon system availability and effects of reliability, maintainability, and supportability including failure rates, repair times, spares and manpower levels, maintenance concepts, etc.


Base Support and Expeditionary (BaS&E) Planning Tool


Transportation Supply Maintenance Readiness Munitions

Employment driven, information technology planning tool suite supporting the AF Expeditionary Site Survey Planning (ESSP) Process; Identifies resources and combat support requirements at potential deployment locations; Operates on both unclassified and classified networks; Capability to assess an employment locationsв€™ ability to support operations based on available resources and projected operations tempo; Allows rapid capability and limiting factor (LIMFAC) identification and facilitates force tailoring decisions


COLT (Customer Oriented Leveling Techniques)



Algorithm to provide optimized supply levels for Defense Logistics Agency managed consumable spare parts. Contractor managed.


Combat Forces Assessment Model (CFAM)


An AF Toolkit model to determine the impact of budget, attrition, force structure, targeting decisions, and munitions inventories on war fighting capabilities in a theater scenario.

An AF Standard Analysis Toolkit model to determine the impact of budget, attrition, force structure, targeting decisions, and munitions inventories on war fighting capabilities in a theater scenario.


Crystal Ball


Risk Analysis tool

Monte Carlo Simulations



HQ AF/A9 EADSIM model manager (owner) is Jim Watkins,SMDC-FW-SM,Voice: (256) 955-1681 (DSN: 645).

EADSIM is used by AF/A9, ACC/A9, and others. See for additional users. EADSIM is part of AFSAT (Air Force Standard Analysis Toolkit).

The Extended Air Defense Simulation (EADSIM) is a many on many simulation of air, missile and space warfare. EADSIM is used for scenarios ranging from few on few to many on many. It represents all the missions on both sides. It is unique in the scope of modeling at such a level of detail, where each platform (such as a fighter aircraft) is individually modeled, as is the interaction among the platforms. It includes an extensive functional and statistical representation of perception feeding perception based C3. It models the Command and Control (C2) decision processes and the communications among the platforms on a message by message basis. Intelligence, surveillance, and reconnaissance is explicitly modeled to support offensive and defensive applications. EADSIM provides a robust reliability, availability, and maintainability (RAM) modeling, to include multiday scenarios. This RAM modeling allows specified components of a system to fail based on a mean time to failure statistical distribution. Each component has a mean time to repair, also specified by a statistical distribution, and a user specified inventory of spare components that can be drawn from as a remove and replace (R&R) process. R&R times are also specified as a statistical distribution. In all cases where distributions are used, the type of statistical representation is user selectable. Depot ordering with shipping delays for individual components is also captured in the RAM modeling.


Enhanced Trade Space Tool

AF/A8XP, Walters, Stephen Col AF/A8XP, 703-697-4202

Supports the AFCS with tradespace analysis

Life Cycle Costs (Procurement, RDTE, O&M, MILPERS) for various force structures. In house tool developed in Access and Microsoft Excel.


Enterprise Knowledge Management System (EKM)


Used to extract/capture monthly maintenance performance indicator data from the Integrated Maintenance Data System.


F100 Engine Production Models


Models developed for LEAN Cell manufacturing and production of F100 Engine Systems

One per cell – Est. 30+ models


Fuels Automated System (FAS) otherwise known as Purple Hub

DLA, multiple AF users

Transportation Supply Maintenance Readiness

Used to track and bill fuel consumption for CPFH program. Air Staff directed in support of CPFH program.





JOPES is used by Combatant Commanders as a planning and execution tool that catalogs Unit Personnel and Cargo movement information and as a programming function to ensure timely unit and personnel movement.


Global Ammunition Control Point/AMST



AMST has a complete round analyzer in it to a allow us to compile all assets to give us the complete round to complete a munitions item.




Used for multiple systems to estimate how much a given force structure will cost over its life cycle

Spreadsheet cost model. In house tool developed in Microsoft® Excel.




Simple to use. Low cost.

Process and shop flow modeling




Transportation Readiness

Transportation tool used for flow of supplies and transportation analysis


Joint Analysis System (JAS)


Theatre Logistics Constructive Modeling

JAS is a constructive, stochastic, C4ISR centric, joint (campaign level) model with integrated Strategic Mobility, Theater Logistics, and Joint Operations encompassing a broad range of military operations (ROMO).


Joint Semi Automated Forces (JSAF)


Constructive Modeling

Joint Semi Automated Forces (JSAF) is a computer generated forces constructive simulation.


JSF Spares Requirements Support


Logistics Spares Modeling

Provided spares requirements lists to the Program Office for an assessment of mission capability. Based on the results and description of the model, the JSF selected the Air Force Aircraft Sustainability Model for calculation of initial spares quantities


KC-X Organic FAA Posture


KC-X Tanker

Analysis of sustainment issues and processes: The KC-X will be an FAA procured and organically sustained weapon system program. The USAF does not currently have the requisite infrastructure in place for an organically supported and maintained FAA certified weapon system of this magnitude (179 aircraft), such as FAA certified repair facilities (i.e., ALC's), FAA-trained depot maintenance personnel, O level maintainers trained on commercial manuals, etc. The stand-up of these capabilities will be articulated, documented, and pursued during the SDD phase and implemented/transitioned during the ICS phase. The sustainment simulation would complement our planned SDD efforts to fully document and understand the complexities of planning and posturing for, and implementation of, an organically supported FAA certified and maintained weapon system over a 40 year life cycle.


Logistics, Installations, Mission Support-Enterprise View (LIMS-EV)


Expeditionary Combat Support System

Enables information exploitation to facilitate decision making, tracking of metrics and performs proactive activities across all A4/7 business areas.


Logistic Simulation (LOGSIM)


Logisitics simulation.

Airbase Logistic Operations constraining effects of aircraft maintenance on air operations


Logistics Sustainment Predictive Analysis (LSPA)


Maintenance and Logistics Sustainment Model

Our LSPA effort uses state of the art, Commercial Off The Shelf (COTS), industry standard technology. ReliaSoft’s BlockSimTM software application provides a comprehensive platform for complete system failure analysis utilizing RBDs for system definition and allows complex system analysis both analytically and through discrete event simulation. In addition to reliability information, the user can implement BlockSimTM to define the characteristics for simulating corrective maintenance, preventive maintenance, and/or inspections for each component.




Logistics Module (LOGMOD), used for deployment of Unit Type Codes (UTCs)

Logistics Module B (LOGMODB) provides Joint Command and Air Force Warfighters with unprecedented ability to plan, execute, accelerate, or redirect to a higher priority location the deployment of Air Force combat units for accomplishing realtime combat operations anywhere in the world. LOGMODB is an enterprise IT system that enables logisticians to rapidly and accurately execute deployment of preplanned or tailored combat capabilities packages, then sustain the tempo of combat operations by commensurately supporting the Air Force units equipment, manpower, and materiel. LOGMODB enables the Air Force to increase its combat sortie production capability while also decreasing its mobility footprint and cost of operations.




Mulit program cost estimation tool.

Software and hardware cost and schedule estimating tool


Proactive Demand Levelling algorithm


Supply, used by all ALCs

Allocate low demand parts across the CAF and prevent grounding MICAP incidents.


Process Sequence Model

Transportation Supply Maintenance Readiness Munitions

Process Sequence Models (PSM) are developed to depict key process flows and form the quantitative foundation for the Air Force Capability Review and Risk Assessment (CRRA). They are used to perform critical path analysis and determine likely points of failure based on Monte Carlo simulation (performed with Crystal Ball software). PSMs have been developed for the following mission areas that relate directly/indirectly to logistics: Open and Establish Operating Locations, Generate the Mission, Equip Forces, Sustain Operating Locations, Training, and Protect Forces.




Used across systems to predict net present value calculation in support of recapitalization efforts.

Spreadsheet cost model. In house tool developed in Microsoft® Excel


Propulsion Requirements System


Supply Maintenance Readiness

The PRS model computes the number of whole spare engines needed to support planned peace and wartime flying hour programs. Requirements are computed for bases, CRFs, and depots.




Multi system tool used to estimate the system's availability, reliability, support issues, etc.

Simulation uses reliability, maintenance, logistics, and operational characteristics of a system's parts to determine the system's availability, reliability, support issues, etc.


Readiness Based Leveling (RBL)


Supply Readiness

RBL is used to allocate levels of reparable spare parts among AF bases worldwide. A new computation is run semiannually to relevel among AF bases, as well as on other occasions, to see what standing up a base at a new location will do to the rest of the world, or how much it would degrade support to the rest of the AF to send extra spares to a given base.


Reliability Maturity Index (RMI) Balanced Score Card


Microsoft® Excel spreadsheet questionnaire to evaluate the maturity and completeness of a system/component's Reliability Program

User rates elements of the reliability program on a scale of 1 to 4 or Yes/No. The model assigns value and weighting to determine overall rating for the status.


ReliaSoft Block Sim 7 and Wiebull ++

Maintenance Other

Used to identify potential reliability/supportability issues lead time away to support planning and decision making to implement corrective actions as necessary. Also used to support resource decisions to ensure resources are applied/timed to maximize effectiveness of when they are applied. Funding and other resources are limited and the tool helps to quantify the most effective time to invest in a particular system or program. Data is also used to direct maintenance and repair improvements to address declining reliability where possible.


RMLS Maintenance and Ground Ops (Arena)


Simulation for rocket based launch systems.

Arena based simulation for determining fleet size, turn time, manpower requirements, and maintenance for rocket based launch systems.


Scalable Integration Model for Objective Resource Capability Evaluations (SIMFORCE)


Desktop Decision Support Tool

SIMFORCE is a desktop decision support tool that predicts resource utilization using simulation/modeling technology. It calculates probable maintenance resource (people, equipment, facilities, and parts) needs based on Air Force Wing operational taskings.


Scenario Space Model


Measures how the addition of one more platform of a given type will affect the outcome of a campaign in a specified scenario. Information can be used to develop ratios of per platform capability contribution for new (e.g., F-35) versus legacy (F-16) platforms

One can add one more asset (e.g., F-16) at the beginning of a campaign and measure how much it effects the outcome. One can also add one more asset on each day of the campaign and see how the outcome of the campaign is affected if the asset arrived on the second day, the third day, etc. And you can do this for different types of assets (e.g., F-16s and F-35s). In house tool developed in Access and Microsoft Excel.




Used by multiple programs to aid in the estimation of hardware development, production, operations & support, and system level cost analysis.

Software and hardware cost and schedule estimating tool


Spares Requirement Review Board (SRRB) tool


Supply Maintenance Readiness

Used to determine sustainment requirements for the Depot Level Reparables (DLR). Air Staff directed for use in developing DLR rates.


Standard Utilization Model


Excel spreadsheet used to predict a unit's maximum sortie/flying hour capability based on the limiting factors of aircraft and personnel availability. Used at the AMU level during the initial first look phase of annual flying hour program planning.


System Effectiveness Data System (SEDS)


R&M Model

SEDS is the Reliability and Maintainability (R&M) modeling system used at the Air Force Flight Test Center, Edwards AFB, CA.





Two SBSS test gangs which allow us to process complete mission changes, and actually see the influence of the data before the actual load. We also use the databases to test new software before it is loaded in the production environment. The test databases also allow for scenarios to be processed over and over again, which highly assist in training.

Appendix D – Glossary of Terms

Analysis of Alternatives (AoA): The AoA assesses potential materiel solutions to satisfy the capability need documented in the approved Initial Capabilities Document (ICD). It focuses on identification and analysis of alternatives, measures of effectiveness, cost, schedule, concepts of operations, and overall risk, including the sensitivity of each alternative to possible changes in key assumptions or variables. The AoA also assesses Critical Technology Elements (CTEs) associated with each proposed materiel solution, including technology maturity, integration risk, manufacturing feasibility, and, where necessary, technology maturation and demonstration needs.

Business Case Analyses (BCA): The evaluation of alternative solutions for obtaining best value while achieving operational requirements balancing cost, schedule, performance, and risk.

Capabilities Development Document (CDD): A document that provides the operational performance attributes, including KPPs, necessary for the acquisition community to design a proposed system and establish a program baseline, normally using an evolutionary acquisition strategy. The CDD outlines an affordable increment of militarily useful, logistically supportable and technically mature capability that can be effectively developed, produced or acquired, or deployed and sustained. The CDD supports the Milestone B acquisition decision.

Capabilities Production Document (CPD): A document that addresses the information necessary to support production, testing and deployment of a specific affordable and supportable increment of an acquisition program. The refinement of performance attributes and KPPs is the most significant difference between the CDD and CPD. The CPD must be validated and approved before the Milestone C decision review.

Cost Assessment & Program Evaluation (CAPE): Organization established to conduct independent cost estimates for MDAPs and to serve as the principal advisor to the appropriate Milestone Decision Authority on matters of program life cycle cost.

Integrated Product Support Elements (IPS Elements): the package of support functions required to deploy and maintain the readiness and operational capability of major weapon systems, subsystems, and components, including all functions related to weapon systems readiness.

Cost Estimating Relationship (CER): A mathematical relationship that defines cost as a function of one or more parameters such as performance, operating characteristics, physical characteristics, etc.

Key Performance Parameters (KPP): Those minimum attributes or characteristics considered most essential for an effective military capability. They characterize the major drivers of operational suitability, interoperability, supportability, schedule, technical progress, and cost.

Key System Attributes (KSA): System attributes considered most critical or essential for an effective military capability but not selected as Key Performance Parameters (KPPs). KSAs provide decision makers with an additional level of capability prioritization below the KPP but with senior sponsor leadership control (generally four star, Defense agency commander, or Principal Staff Assistant).

Life Cycle Cost (LCC): The total cost to the government of acquisition and ownership of that system over its useful life. It includes the cost of development, acquisition, operations, and support (to include manpower), and where applicable, disposal.

Life Cycle Sustainment Plan (LCSP): A life cycle plan that describes the planning to effectively and affordably sustain the system being developed. It documents the program’s sustainment metrics and product support strategy influence on the system’s design and support, through acquisition into sustainment and disposal. It facilitates cross-functional integration, most critically with systems engineering and product support stakeholders, and highlights sustainment contract development and performance incentives. After IOC, it is updated to reflect sustainment performance data, O&S cost management, and the system’s periodic Independent Logistics Assessment.

Memorandum of Agreement (MOA): In contract administration, an agreement between a Program Manager (PM) and a Contract Administration Office (CAO), establishing the scope of responsibility of the CAO with respect to the Earned Value Management System (EVMS) criteria surveillance functions and objectives, and/or other contract administration functions on a specific contract or program.

Memorandum of Understanding (MOU): De facto agreement that is generally recognized by all partners as binding even if no legal claim could be based on the rights and obligations delineated therein.

Milestone B (MS B): The point at which a recommendation is made and approval sought regarding starting or continuing an acquisition program, i.e., proceeding to the next phase. MS B approval allows entry into the Engineering and Manufacturing Development (EMD) phase. SDD has two major efforts: System Integration and System Demonstration. The entrance point is MS B, which is also the initiation of an acquisition program.

Milestone C (MS C): The point at which a recommendation is made and approval sought regarding continuing an acquisition program, i.e., proceeding to the next phase. MS C approval allows entry into the Production and Deployment phase. MS C authorizes entry into Low Rate Initial Production (LRIP) (for MDAPs and major systems), into production or procurement (for non-major systems that do not require LRIP) or into limited deployment in support of operational testing for Major Automated Information System programs or software intensive systems with no production components.

Milestone Decision Authority (MDA): Designated individual with overall responsibility for a program. The MDA shall have the authority to approve entry of an acquisition program into the next phase of the acquisition process and shall be accountable for cost, schedule, and performance reporting to higher authority, including congressional reporting. (DoDD 5000.01)

Performance Based Logistics (PBL): PBL is an agreement, usually long term, in which the provider (organic, commercial, and/or public/private partnership) is incentivized and empowered to meet overarching customer oriented performance requirements (reliability, availability, etc.) to improve product support effectiveness while reducing TOC.

Product Support Arrangement (PSA): PSA is a contract, task order, or any type of other contractual arrangement, or any type of agreement or non-contractual arrangement within the Federal Government, for the performance of sustainment or logistics support required for major weapon systems, subsystems, or components.

Program Executive Office (PEO): A military or civilian official who has responsibility for directing several MDAPs and for assigned major system and non-major system acquisition programs. A PEO normally has no other command or staff responsibilities within the Component, and only reports to and receives guidance and direction from the DoD Component Acquisition Executive (CAE).

Program Manager (PM): Designated individual with responsibility for and authority to accomplish program objectives for development, production, and sustainment to meet the user's operational needs. The PM shall be accountable for credible cost, schedule, and performance reporting to the Milestone Decision Authority (MDA). (DoDD 5000.1)

Research & Development (R&D) Costs: Those program costs primarily associated with R&D efforts including the development of a new or improved capability to the point where it is appropriate for operational use. These costs are funded under the Research, Development, Test and Evaluation (RDT&E) appropriation.

Total Ownership Cost (TOC): Includes all costs associated with the research, development, procurement, operation, logistics support, and disposal of an individual weapon system, including the total supporting infrastructure that plans, manages, and executes that weapon system program over its full life.

Appendix E – Acronyms


ACAT Acquisition Category

AoA Analysis of Alternatives

ASN RDA Department of Navy Research, Development and Acquisition


BCA Business Case Analyses


CAPE Cost Assessment and Program Evaluation

CDD Capability Development Document

CER Cost Estimating Relationship

CPD Capability Production Document

CSA Commercial Services Agreement


DFAS Defense Finance and Accounting Service

DMPS Decision Matrix for Product Support

DoD Department of Defense

DRRS Defense Readiness Reporting System

DTM Directive Type Memorandum


EMD Engineering and Manufacturing Development


FOC Full Operational Capability


GAO Government Accountability Office

GR&A Ground Rules and Assumptions



ILA Independent Logistics Assessment

IPS Elements Integrated Product Support Elements

IRR Internal Rate of Return


JSCA Joint Supply Chain Architecture


KPP Key Performance Parameters

KSA Key System Attributes


LCC Life Cycle Cost

LCSP Life Cycle Sustainment Plan


MDA Milestone Decision Authority

MOA Memorandum of Agreement

MOU Memorandum of Understanding


NPV Net Present Value


O&S Operations and Support

OEM Original Equipment Manufacturer

OMB Office of Management and Budget

OSD Office of the Secretary of Defense


PBA Performance Based Agreement

PBL Performance Based Logistics

PEO Program Executive Office

PM Program Manager

POA&M Plan of Action and Milestone

POC Point of Contact

PSA Product Support Arrangement

PSI Product Support Integrator

PSM Product Support Manager

PSP Product Support Provider



R&D Research and Development

ROI Return on Investment


SME Subject Matter Expert

SRL Service Level Agreement


TOC Total Ownership Cost


USD AT&L Under Secretary of Defense Acquisition Technology and Logistics


VCNO Vice Chief of Naval Operations

VVA Verified, Validated and Accredited


WSARA Weapon System Acquisition Reform Act




Appendix F – Product Support BCA References

  • Product Support Manager (PSM) Guidebook,
  • GAO 09-41: Improved Analysis and Cost Data Needed to Evaluate the Cost effectiveness of Performance Based Logistics, December 2008.
  • CJCSI 3170.01G Joint Capabilities Integration and Development Systems
  • OMB Circular A-94,
  • Army Logistics Management College (ALMC), Operations Research/Systems Analysis (ORSA) Familiarization Course;
  • Defense Acquisition Guidebook- GAO-09-3SP Cost Estimating and Assessment Guide: Best Practices for Developing and Managing Capital Program Costs, March 2009.

Analysis References

Document Management References

  1. Reference Section 2 of the PSM Guidebook, PSBM, Roles and Responsibilities, Product Support Arrangements, and Product Support Strategy and Implementation for further description on these roles

  2. Please see the Product Support Manager Guidebook for more information

  3. GAO 09-41: Improved Analysis and Cost Data Needed to Evaluate the Cost-effectiveness of Performance Based Logistics, December 2008

  4. Reference Appendix A, 2.0, for a Product Support BCA execution and process flow and Appendix F for related reference material.

  5. Recommend this not exceed more than two pages in length

  6. For more information on decision-focused thinking for the evaluation criteria, please refer to materials and classes offered by the Army Logistics Management College (ALMC)

  7. For more information on VFT and AHP, please refer to materials and classes offered by the ALMC

  8. Refer to the Product Support Manager Guidebook, for additional information on using the DMPS.

  9. GAO-09-3SP Cost Estimating and Assessment Guide: Best Practices for Developing and Managing Capital Program Costs, March 2009

  10. Please refer to Appendix A, the Product Support Manager Guidebook for more information on IPS Elements.

  11. Refer to the O&S Cost-Estimating Guide is available at Also see Appendix B for more information on how to accurately capture costs

  12. Refer to, Chapter 3: Affordability and Life Cycle Resource Estimates


  14. Reach out to appropriate offices to assist with developing the communications plan (i.e., Public Affairs Office, Legislative Liaison Office, etc.)