Product Support Analysis (MIL-HDBK-502A)

Product Support Analysis (MIL-HDBK-502A) [Suggest Change]

Avg. Rating: 3 and 1 users rated this article   8,319 page views

Primary Functional Area : Life Cycle Logistics

Figure 1. Product Support Analysis Interfaces, Inputs, Tradeoffs and Outputs

 

Definition [Suggest Change]

MIL-HDBK-502A Product Support Analysis was issued by the Department of Defense in March 2013, and supersedes the outdated May 30, 1997 MIL-HDBK-502 Acquisition Logistics. MIL-HDBK-502A is approved for use by all Departments and Agencies of the Department of Defense. The Handbook defines the Product Support Analysis (PSA) framework and activities as an integral part of the Systems Engineering process, and includes the selection and tailoring of those activities to meet DoD program supportability objectives. Sample contract language for acquiring Product Support Analysis deliverables is also presented. The Handbook is for guidance only and cannot be cited as a requirement.

General Information/Narrative [Suggest Change]

Background


MIL-HDBK-502A offers guidance on DoD’s implementation of SAE Standard TASTD0017, Product Support Analysis, which was originally issued in November 2012 as TechAmerica Standard TA-STD-0017, Product Support Analysis.  SAE TASTD0017 is a commercial standard and is available for purchase from SAE at TASTD0017: Product Support Analysis - SAE International.


Subsequent to the issuance of MIL-HDBK-502A, TA-STD-0017 (now known as SAE TASTD0017) 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. TechAmerica TA-STD-0017 is a new and improved replacement for the cancelled MIL-STD-1388-1A. The application of TECHAMERICA-STD-0017 is recommended for DoD Programs by tailoring the Statement of Work (SOW) to reflect Section 813 (FY13 NDAA) and Better Buying Power 2.0 requirements and using MIL-HDBK-502A guidance for defining which activities are included in the Statement of Work (SOW).”


The Product Support Analysis (PSA) Process


The Handbook defines the Product Support Analysis (PSA) process as a wide range of analyses that are conducted within the Systems Engineering process. Inputs and outputs for the system level Product Support Analysis 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 Integrated Product Support (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, Product Support Analysis Interfaces, Inputs, Tradeoffs and Outputs, identifies the multidisciplinary interfaces required. Table 1, Product Support Analysis 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 Product Support Analysis 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.


The Handbook addresses the assessment and verification of the adequacy and effectiveness of the Product Support Analysis 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, three Appendices support the implementation of the Product Support Analysis process.


Appendix A, Example Contract Data Requirement List (CDRD) 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 Integrated Product Support (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 Product Support 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 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 for Fiscal Year 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 during the Operations and Support 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 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.

Defense Acquisition Guidebook, Policies, Directives, Regulations, Laws [Suggest Change]

Department Of Defense Instructions



Joint Chiefs Of Staff Instructions/Manuals



Department Of Defense Manuals



Department Of Defense Guidebooks



Defense Acquisition Guidebook (DAG)


Best Practices, Lessons Learned, Stories, Guides, Handbooks, Templates, Examples, Tools [Suggest Change]


Defense AT&L Magazine


Training Resources [Suggest Change]

DAU Classroom Courses


  • LOG 201 Product Support Strategy Development, Part B
  • LOG 211 Supportability Analysis
  • LOG 340 Life Cycle Product Support
  • LOG 350 Enterprise Life Cycle Logistics Management
  • LOG 465 Executive Product Support Manager's Course

DAU Distance Learning Courses


  • LOG 101 Acquisition Logistics Fundamentals
  • LOG 102 Fundamentals of System Sustainment Management
  • LOG 103 Reliability, Availability and Maintainability (RAM)
  • LOG 200 Product Support Strategy Development, Part A
  • LOG 204 Configuration Management
  • LOG 206 Intermediate Systems Sustainment Management
  • LOG 215 Technical Data Management
  • LOG 235 Performance-Based Logistics

DAU Continuous Learning Modules


  • CLL 001 Life Cycle Management & Sustainment Metrics
  • CLL 005 Developing a Life Cycle Sustainment Plan (LCSP)
  • CLL 008 Designing for Supportability in DoD Systems
  • CLL 012 Supportability Analysis
  • CLL 039 Product Support & Sustainment Requirements Identification
  • CLL 042 Supportability Analysis Techniques, Procedures & Tools

Communities [Suggest Change]

Data Management
Life Cycle Logistics
Naval Open Architecture
Performance Based Logistics
Production, Quality & Manufacturing
Program Management
Requirements Management
Systems Engineering
Test & Evaluation

Related Articles [Suggest Change]

Affordable System Operational Effectiveness (ASOE) Model
Analysis of Alternatives (AoA)
Capability Development Document (CDD)
Capability Production Document (CPD)
Depot Activation and Capability Establishment
Failure Modes & Effects Analysis (FMEA) and Failure Modes, Effects & Criticality Analysis (FMECA)
Integrated Product Support (IPS) Element - Design Interface
Integrated Product Support (IPS) Element - Sustaining Engineering
Level of Repair Analysis (LORA)
Life Cycle Management (LCM)
Life Cycle Sustainment Plan (LCSP)
Logistics Product Data
Maintenance Task Analysis (MTA)
Performance Based Logistics (PBL) Metrics - Overview
Post IOC Supportability
Product Life-Cycle Management (PLM) Integrated Data/Decision Environment (IDE)
Product Support Manager (PSM)
Product Support Package
Support Equipment
Supportability Analysis
Supportability Design Objectives
Sustainment Maturity Levels (SML)
Systems Engineering in Engineering and Manufacturing Development Phase
Systems Engineering in Materiel Solution Analysis
Systems Engineering in Technology Maturation and Risk Reduction
Technical Data Package (TDP)
Post Production Software Support (PPSS)
Provisioning
Integrated Product Support (IPS) Element - Product Support Management
Integrated Product Support (IPS) Element - Maintenance Planning and Management
Supportability Testing (Logistics Test & Evaluation)
Post-Deployment Review
Performance Based Logistics (PBL) Metrics – Techniques & Tools for Optimizing Operating & Support (O&S) Cost & System Readiness
Funding Product Support Strategies

Attachments [Suggest Change]

Page Information

Page Views 8,319
Created on 8/12/2013
Modified on 8/5/2016
Last Reviewed 7/28/2016