U.S. flag

An official website of the United States government

Dot gov

Official websites use .gov
A .gov website belongs to an official government organization in the United States.

Https

Secure .gov websites use HTTPS
A lock () or https:// means you’ve safely connected to the .gov website. Share sensitive information only on official, secure websites.

Breadcrumb

  1. Home
  2. Product Support Analysis (PSA)

Product Support Analysis (PSA)

DAU GLOSSARY DEFINITION

Alternate Definition

The analysis required to create the package of support functions required to field and maintain the readiness and operational capability of major weapon systems, subsystems, and components, including all functions related to weapon system readiness. 

Alternate Definition Source

MIL-HDBK-502A, Product Support Analysis

General Information

Background

DoD Instruction (DoDI) 5000.91, Product Support Management for the Adaptive Acquistion Framework, states that "The PSM will establish a cross-functional team of subject matter experts (SMEs) to develop accurate assumptions, capture data, and perform data analysis to develop and refine the product support analysis, also referred to as the supportability analysis. This analysis will support DoD Component engineering and product support solutions. As a program progresses through development, the PSM will use the team of cross-functional SMEs to ensure product support analysis activities are executed to develop accurate logistics product data, reduce redundancy, and form a baseline for developing product support documentation (e.g., technical manuals, training manuals). The PSM will work with the cross-functional team to conduct a thorough analysis using analytical tools and modeling techniques to facilitate informed decisions on supply support, manpower, training, maintenance and maintenance planning, and other IPS [Integrated Product Support] Elements. Pursuant to DoDI 5000.88, supportability analyses will be included in the evolution of the digital authoritative source of truth which is managed and maintained throughout the life of the program." (Note: bold text added for clarity.)

MIL-HDBK-502A

MIL-HDBK-502A defines the PSA framework and activities as an integral part of the Systems Engineering (SE) process, and includes the selection and tailoring of those activities to meet DoD program supportability objectives. Sample contract language for acquiring PSA deliverables is also presented. The handbook is for guidance only and cannot be cited as a requirement. It offers guidance on DoD’s implementation of SAE International (SAE) Standard TA-STD-0017, Product Support Analysis, which was adopted for use by DoD on June 11, 2013. The Adoption Notice states, “This standard defines the analysis required to define the support system for new products, systems and end items. SAE TA-STD-0017 is a new and improved replacement for the cancelled MIL-STD-1388-1A. The application of SAE TA-STD-0017 is recommended for DoD Programs by tailoring the Statement of Work (SOW)..." (SAE TA-STD-0017 is a commercial standard and is available for purchase from SAE TA-STD-0017: Product Support Analysis - SAE International).

The PSA Process

MIL-HDBK-502A describes the PSA process as a wide range of analyses. Inputs and outputs for the system level PSA include system analysis/engineering at the hardware-operating-support trade level, and provide outputs to the interfacing activities in the form of boundary conditions or goals for both engineering performance and IPS Element concepts and plans. These outputs affect design and operational concepts; identify gross product support resource requirements of alternative concepts; and relate design, operational, and supportability characteristics to system readiness objectives and goals.

Figure 1, attached in the drop down section below, PSA Interfaces, Inputs, Tradeoffs and Outputs, identifies the multidisciplinary interfaces required. Table 1, included within the article text below, PSA Activities, defines the process steps and the details the activities required for the accomplishment of each step. Coordination of these interfaces and activities is a significant management task for all the disciplines involved.

Table 1. MIL-Handbook-502A PSA Activities

ACTIVITY / TITLE /PARA. PURPOSE
1. Product Support Analysis Strategy (5.2.3) To develop a proposed PSA strategy for use early in the acquisition program; and identify the PSA activities which will provide the best return on investment and document the risks of accomplishing these objectives.
2. Product Support Analysis Planning (5.2.3) To develop a PSAP which will effectively implement the PSA program. It also documents the PSA management structure and authority; what PSA activities are to be accomplished; when each activity will be accomplished; what organizational units will be responsible for accomplishing each activity; how all activities are integrated; and how results of each activity will be used.
3. Program and Design Reviews
(5.2.4)
To provide for timely PSA program participation in the official review and control of design information; the scheduling of detailed PSA program reviews; and logistics risk assessments at program reviews. It also ensures that all pertinent aspects of the PSA program are addressed as an integral part of all formal program and design reviews.
4. Application Assessment (5.3.2) To identify support factors related to the system’s intended use. Also to document quantitative data results which should be considered when developing support alternatives.
5. Support System Standardization (5.3.3) To define support and support related design constraints based upon support standardization considerations. It also provides support related input to standardization efforts.
6. Comparative Analysis (5.3.4) To define a sound analytical foundation for making projections for new system/equipment parameters and identifying targets of improvement; identify the supportability, cost, and readiness drivers for the new system/equipment; identify risks involved in using comparative system data in subsequent analyses.
7. Technological Opportunities
(5.3.5)
To identify technological advancements and state-of-the-art design approaches
offering opportunities to achieve new system support improvements. Use of available technology is emphasized to improve projected safety, cost, support, and readiness values, which reduce a new system’s environmental impact,
and resolve qualitative support problems or constraints identified.
8. Supportability and Supportability Related Design Factors (5.3.6) To establish quantitative operations and support characteristics of alternative design and operational concepts; and support related design objectives, goals and thresholds, and constraints for inclusion in requirement, decision, and program documents and specifications.
9. Functional Requirements
(5.4.2)
To identify missions (e.g., shoot, move, communicate), maintenance, and support (transport, maintain, dispose) functions that should be performed for each system/equipment alternative in the intended environment. It also identifies requirements for operations, maintenance and support, and documenting task performance requirements in a task inventory.
10. Support System Alternative (5.4.3) To establish support system alternatives for evaluation, tradeoff analysis, develop a detailed support plan, and determination of the best system to be developed.
11. Evaluation of Alternatives and Tradeoff Analysis (5.4.4) To determine the preferred support system alternative(s) and their associated risks for each proposed system; and determine, through tradeoff analysis, the best approach to satisfying the need (the one that provides the best balance between risk, cost, environmental impact, schedule, performance, readiness, and support).
12. Task Analysis (5.5.2) To analyze required operations, maintenance, and support tasks to: identify resources required for each task; highlight resource requirements which are new or critical and any risks associated with those resource requirements, including hazardous materials/waste and their environmental impact; define transportability requirements; identify support requirements exceeding established goals/thresholds/ constraints; provide data supporting recommended design alternatives to improve data supporting recommended design alternatives to improve supportability/enhance readiness; and provide source data to develop required documents, e.g., Maintenance Plans, Maintenance Allocation Charts, Technical Manuals, and Provisioning Documentation.
13. Early Distribution Analysis (5.5.3) To assess new system impact on existing systems to include quantifying risk levels which surround system performance/ supportability; to identify sources of manpower/ personnel skills to meet new system requirements; to determine impact of failure to obtain necessary product support resource requirements.
14. DMSMS/Obsolescence Analysis (5.6.2) To analyze the loss or impending loss of manufacturers or suppliers of parts and material required to operate and sustain the system/ equipment and support development of a program to establish alternate sources of supply.
15. Field Feedback (5.6.3) To correct potential post production support problems prior to closing production lines and to develop a plan to ensure effective support of the system during its life cycle. Post production support plan should identify single/dual source items and those for which the government has no data rights. Plans should include available organic support assets, production line buy-out, or contractor logistics support agreements.
16. Disposal Activity (5.6.4) To identify the disposal/demilitarization procedures associated with a system/end item including facility equipment that focuses on those components, assemblies, sub-assemblies, parts and materials that contain hazardous materials, wastes and pollutant; identify those items that can be recycled, reused or salvaged.
17. Operational Suitability (5.7.2) To assess achievement of support parameters specified; identify reasons for deviations from projections; recommend changes to correct deficiencies and improve system readiness.

 

MIL-HDBK-502A addresses the assessment and verification of the adequacy and effectiveness of the PSA process. This critical aspect of product support is conducted throughout the system/equipment's life cycle to demonstrate, within stated confidence levels, the validity of the analysis and products developed from the analysis, and to adjust the analysis results and products as required. This part of the process starts with early planning for verification of support concepts and continues through development, acquisition, deployment, and operations to include assessment and verification of post-deployment support.

Additionally, Appendices A, B and C support the implementation of the PSA process. Information included in each Appendix is included below.

Appendix A, Example Contract Data Requirement List (CDRL) and Data Item Descriptions (DID)

The section provides CDRL examples and DID suggestions. The CDRLs identify data and information that the contractor will be obligated to deliver under the contract. DIDs are used to define and describe the data required to be furnished by the contractor. After selecting the data and information to be delivered, the selections are documented in the SOW and CDRL line item entries. Each CDRL entry should reference the appropriate DID. Paragraph 5.8, Tailoring, and Paragraph 6, Contracting provide detailed discussion and guidance for the tailoring, and selection of analysis requirements for specific phases and types of programs.

CDRLs include the following deliverables in support of the Handbook activities:

  • Logistics Product Data, to include data such as the LSA-004, Maintenance Allocation Chart, LSA-056, Failure Modes, Effects and Criticality Analysis (FMECA) Report, LSA-080, Bill of Materials, and the LSA-151, Provisioning Parts List Index.
  • Logistics Product Data Summaries, to include the IPS Elements of Maintenance Planning, Support and Test Equipment, Manpower, Personnel, and Training, Facilities, Packaging, Handling, Storage, and Transportation and Post Production Support.
  • Product Drawings/Models and Associated Lists, and
  • Scientific and Technical Reports, to include documentation of PSA Activities such as Comparative Analysis, Supportability and Supportability Related Design Factors, Functional Requirements, Program and Design Reviews, Evaluation of Alternatives and Tradeoff Analysis, Task Analysis, Field Feedback, and Operational Suitability, Test, Evaluation, Verification and Validation.

Appendix B, Assessing a Program’s Intellectual Property (IP) Rights and Developing a Data Rights Strategy

DoD Instruction 5000.02, Enclosure 2, paragraph 6a(4) requires Program management to establish and maintain an IP Strategy to identify and manage the full spectrum of IP and related issues (e.g., technical data and computer software deliverables, patented technologies, and appropriate license rights) from the inception of a program and throughout the life cycle.

Appendix B addresses the requirements of DFARS 207.106, “Additional Requirements for Major Systems”, which directs the implementation Section 802(a) of the National Defense Authorization Act (NDAA) for Fiscal Year (FY) 2007 (Pub. L. 109-364) to (a) assess the long-term technical data and computer software needs of those systems and subsystems, and (b) establish acquisition strategies that provide for the technical data and computer software deliverables and associated license rights needed to sustain those systems and subsystems over their life cycle. Additional guidance is provided by referencing to the DoD Open Systems Architecture Contract Guidebook.

The IP Strategy will describe, at a minimum, how program management will assess program needs for, and acquire competitively whenever possible, the IP deliverables and associated license rights necessary for competitive and affordable acquisition and sustainment over the entire product life cycle, including by integrating, for all systems, the IP planning elements for major weapon systems and subsystems thereof.

The IP Strategy will be updated throughout the entire product life cycle, summarized in the Acquisition Strategy, and presented with the Life Cycle Sustainment Plan (LCSP) during the Operations and Support (O&S) Phase. Program management is also responsible for evaluating and implementing open systems architectures, where cost effective, and implementing a consistent IP Strategy. This approach integrates technical requirements with contracting mechanisms and legal considerations to support continuous availability of multiple competitive alternatives throughout the product life cycle.

Appendix C, Application Guidance for Implementation of Level of Repair Analysis (LORA) Program Requirements

The Appendix provides rationale and guidance for the selection and tailoring of LORA activities in SAE TASTD0017 to meet specific program objectives in a cost effective manner. General application guidance is provided for both economic and non-economic LORA programs. Discussion of the LORA program process, the development of LORA requirements, the impact of data availability, and the tailoring of the analysis by acquisition phase is presented. Specific guidance is provided on LORA activities in the areas of the LORA Program Plan, LORA Guidance Conference, Economic and Non-Economic evaluation, Sensitivity Analysis, the LORA Report and the use of the US Army Materiel Command Logistics Support Activity (LOGSA) LORA tool, COMPASS.