SD-22 DMSMS Guidebook Cover

SD-22 – Diminishing Manufacturing Sources
and Material Shortages (DMSMS)

A Guidebook of Best Practices for Implementing a Robust DMSMS Management Program

Defense Standardization Program Office

8725 John J. Kingman Road, Stop 5100

Fort Belvoir, VA 22060-6220

703-767-6888

https://www.dsp.dla.mil

Message from the Director

Because Department of Defense (DoD) system life cycles are longer than technology life cycles, Diminishing Manufacturing Sources and Material Shortages (DMSMS) issues are inevitable. DoD cannot afford to be reactive in this area—reactivity may lead to a combination of schedule delays, readiness degradations, and higher cost.

Leadership attention must be brought to bear on this problem and adequate resources must be provided to minimize its impact. The return on investment from these resources can be substantial because resources devoted to proactivity lengthen the window of opportunity to take corrective action. There will be a larger number of low-cost options available when the window to address the issue is longer. Therefore, cost-effectiveness improves. This is the primary theme of the better buying power initiatives—better value for the warfighter.

This guidebook—SD-22, Diminishing Manufacturing Sources and Material Shortages: A Guidebook of Best Practices for Implementing a Robust DMSMS Management Program—provides best practices for robust and proactive DMSMS management. It explains things to do and why those things are important. Examples include the following:

  • Fully fund DMSMS management activities and resolutions and ensure that the right people are trained and involved.
  • Get the contract language right. This is critical to proactive DMSMS management.
  • It’s never too early to begin. Starting early in design, proactively monitor critical, highly vulnerable items, software, assemblies, and materials to identify potential problems before negative impacts occur.
  • Link DMSMS health assessments with the program’s product roadmaps to mitigate issues before they materialize.
  • Ensure that resolutions minimize life-cycle costs; solutions that are inexpensive upfront may have significant future cost.
  • Obtain comments from the DMSMS community on designs and redesigns to avoid the inclusion of obsolete items.

This guidebook, while designed primarily for the DMSMS practitioner, should also be useful for program managers, engineers, and life-cycle logisticians. It is updated periodically. This version of the SD-22 replaces the version published in February 2015. Recommended changes to this document should be addressed to the Defense Standardization Program Office, 8725 John J. Kingman Road, Stop 5100, Fort Belvoir, VA 22060-6220, or e-mail at DSPO@dla.mil.

Director Signature

, Defense Standardization Program Office

Contents

1. Introduction 1

1.1. Scope and Objective 1

1.2. DMSMS Mechanisms 2

1.3. The Importance of a DMSMS Management Program 6

1.4. Overview of the DMSMS Management Process 8

1.5. Organization of This Document 9

2. DMSMS Management Links to the Defense Acquisition System 12

2.1. DMSMS Policy 12

2.2. DMSMS Guidance for the Program Manager 14

2.3. Design Effectiveness and DMSMS 17

2.3.1. DMSMS as a Consideration in Design 17

2.3.2. DMSMS Considerations in Systems Engineering Technical Reviews 22

2.4. Process Efficiency and DMSMS 24

2.4.1. Acquisition Strategy 25

2.4.2. Product Support Strategy 25

2.4.3. Life-Cycle Sustainment Plan 26

2.4.4. DMSMS Considerations in Logistics Assessments 27

2.5. Technology and Supply Chain Management 28

3. Prepare: DMSMS Management Program Infrastructure 32

3.1. Establish the Strategic Underpinnings for DMSMS Management 32

3.2. Develop a DMSMS Management Plan 35

3.2.1. Planning Considerations 35

3.2.2. Outline of DMP Contents 38

3.3. Form a DMSMS Management Team 40

3.3.1. Roles and Responsibilities of DMT Members 40

3.3.2. DMT Training Needs 45

3.4. Establish DMSMS Operational Processes 47

3.4.1. Secure Resources for DMT Operations 50

3.4.2. Manage Cases 53

3.4.3. Evaluate Program 55

3.4.4. Ensure Quality 56

4. Identify: DMSMS Monitoring and Surveillance 57

4.1. Prioritize Systems 58

4.2. Identify and Procure Monitoring and Surveillance Tools 60

4.3. Collect and Prepare Item Data 62

4.3.1. Item Data Collection 62

4.3.2. Item Data Preparation 66

4.4. Analyze Item Availability 74

4.4.1. Predictive Tools 74

4.4.2. Vendor Surveys 75

4.4.3. Critical Materials Analysis 77

4.4.4. Product Discontinuation Notices 85

4.4.5. Special Considerations for Software 87

4.5. Collect and Update Programmatic and Logistics Data 90

4.6. Develop Health Assessments 91

5. Assess: DMSMS Impact Assessment 94

5.1. Identify Data Needs 95

5.1.1. Programmatic Data 95

5.1.2. Availability Data 96

5.1.3. Criticality Data 96

5.1.4. Logistics Data 96

5.2. Assess Impact of a DMSMS Issue 97

5.2.1. Should a Resolution to the Problem Be Pursued? 99

5.2.2. Which Problem Should Be Addressed First? 101

5.2.3. At What Level Should a Resolution Be Applied? 103

6. Analyze: DMSMS Resolution Determination 105

6.1. Identify Resolution Cost Elements 105

6.2. Identify and Define DMSMS Resolution Options 107

6.3. Determine the Preferred DMSMS Resolution 112

7. Implement: Implementation of DMSMS Resolutions 120

7.1. Secure DMSMS Resolution Funding 120

7.2. Implement DMSMS Resolution 128

Appendix A. Obsolescence and Its Relationship to DMSMS 130

Appendix B. Developing DMSMS Workforce Competencies 132

Appendix C. Contracting 135

C.1. Determining Whether to Contract for DMSMS Management 135

C.1.1. General Factors to Consider 135

C.1.2. Considerations by Function 138

C.1.3. Exit Clauses 139

C.2. DMSMS Management Activities in Contracts by Life-Cycle Phase 140

C.3. Examples of DMSMS Management Contract Language 142

Appendix D. DMSMS Management Questions for Systems Engineering Technical Reviews 156

Appendix E. DMSMS-Related Questions for Logistics Assessments 169

Appendix F. Counterfeit Items and DMSMS 174

F.1. Background 174

F.1.1. How Counterfeit Items Are Made 175

F.1.2. Risks of Using Counterfeit Parts 176

F.1.3. Types of Items Being Counterfeited 176

F.2. Summary of DoD Counterfeit Policy and Key Definitions 178

F.3. The Impact of Counterfeit Items on DMSMS Management 180

Appendix G. Accessing Organic Services and Capabilities to Mitigate DMSMS Issues 184

Appendix H. DMSMS Knowledge Sharing Portal 185

Appendix I. DMSMS Quality Assurance Process 186

I.1. Quality Plan 186

I.2. Metrics 187

I.3. Process Analysis 189

Appendix J. DMSMS Program Capability Levels 192

Appendix K. Lead-Free Electronics and DMSMS Resolutions 197

Appendix L. Complete Department of Commerce Cost Survey Results 199

Appendix M. Abbreviations 203

Figures

Figure 1. Mechanisms for Hardware and Software Obsolescence 3

Figure 2. Steps in the DMSMS Management Process 9

Figure 3. Interrelationships among the DMSMS Processes and the Document’s Components 11

Figure 4. Acquisition Life Cycle 14

Figure 5. Framework for Ensuring Affordable System Operational Effectiveness 16

Figure 6. Relationship between a Program’s Expended Life-Cycle Cost and Locked-In Cost….18

Figure 7. Timing of Systems Engineering Technical Reviews 23

Figure 8. DMSMS Management Processes 49

Figure 9. DMSMS Monitoring and Surveillance Processes 58

Figure 10. Hierarchy of System Items 62

Figure 11. Comparison of Flat and Indentured BOMs 63

Figure 12. Risk Cube for Determining Where Proactive Monitoring of Previously “Uncategorized” Items Is Important 71

Figure 13. Summary Illustration of Risk-Based Approach for Determining Which Items
and Materials on the BOM to Monitor 72

Figure 14. Select the Critical Materials of Concern for the Program 81

Figure 15. Engagement to Identify Potential DMSMS Issues Associated with Critical
Materials 84

Figure 16. Initiation of the Assessment Step 95

Figure 17. DMSMS Resolution Determination Process 114

Figure 18. Notional Relationship between DMSMS and Obsolescence 131

Figure 19. Breakdown of Counterfeit Electronic Parts 177

Figure 20. Assessment of Counterfeit Risk for DLA-Managed FSGs 178


Tables

Table 1. Summary of Principal Systems Engineering Technical Reviews 23

Table 2. Summary of Logistics Assessments 28

Table 3. Notional ARCI Chart 43

Table 4. Recommended DMT Training 45

Table 5. Comparison of Start-Up and Steady-State Effort 51

Table 6. Framework for Determining the Applicability of Proactive Software
Obsolescence Management 73

Table 7. Sample Template for a Quick-Look Analysis of Designs for Obsolescence Risk 92

Table 8. Example Template for a Detailed Health Assessment Report of a System 98

Table 9. DMSMS Resolution Options, Definitions, and Examples 107

Table 10. Cost Elements as Applied to DMSMS Resolution Options 111

Table 11. Distribution of DMSMS Resolutions by Part Commodity 115

Table 12. Average Cost Associated with Implementing Each DMSMS Resolution Option 118

Table 13. Description of DMSMS Resolution Cost Estimation Approaches 121

Table 14. Courses beyond DAU Certifications Needed to Achieve DMSMS Competency 134

Table 15. DMSMS Management Questions for Systems Engineering Technical Reviews: Prepare (Section 3) 156

Table 16. DMSMS Management Questions for Systems Engineering Technical Reviews: Identify (Section 4) 161

Table 17. DMSMS Management Questions for Systems Engineering Technical Reviews:
Assess (Section 5) 164

Table 18. DMSMS Management Questions for Systems Engineering Technical Reviews: Analyze (Section 6) 165

Table 19. DMSMS Management Questions for Systems Engineering Technical Reviews: Implement (Section 7) 166

Table 20. DMSMS Management Questions for Systems Engineering Technical Reviews:
Other 167

Table 21. DMSMS Management Questions for Logistics Assessments: Prepare (Section 3) 169

Table 22. DMSMS Management Questions for Logistics Assessments: Identify (Section 4) 171

Table 23. DMSMS Management Questions for Logistics Assessments: Assess (Section 5) 172

Table 24. DMSMS Management Questions for Logistics Assessments: Analyze
(Section 6) 172

Table 25. DMSMS Management Questions for Logistics Assessments: Implement
(Section 7) 173

Table 26. DMSMS Management Questions for Logistics Assessments: Other 173

Table 27. DMSMS Program Capability Levels 193

Table 28. Number of DMSMS Resolutions Reported and Average Cost by Type,
Commodity, and Environment 200

1. Introduction

1.1. Scope and Objective

A Diminishing Manufacturing Sources and Material Shortages (DMSMS) issue is the loss, or impending loss, of manufacturers or suppliers of items, raw materials, or software.[1] The Department of Defense (DoD) loses a manufacturer or supplier when that manufacturer or supplier discontinues production and/or support of needed items, raw materials, or software or when the supply of raw material is no longer available. While traditionally thought of as applying to electronic items, it is important to be cognizant that a DMSMS issue can arise regarding any item within a system, including software and non-electronic components—materials and structural, mechanical, and electrical (MaSME) items.

DMSMS issues can be caused by many factors—such as low-volume market demand, new or evolving science or technology, changes to detection limits, toxicity values, and regulations related to chemicals and materials—that significantly affect the DoD supply chain and industrial base. Another aspect of DMSMS is when an item, although still available commercially, no longer functions as intended because of hardware[2]–electronic and MaSME items, software, and/or requirements changes to the system. This is often referred to as functional obsolescence.[3] Any of these situations may endanger an ongoing production capability and/or the life-cycle support of a weapon system or any training, support, or test equipment already in the field.[4] Ultimately, DMSMS issues affect materiel readiness and operational availability, which, in turn, affect both combat operations and safety.

No system or program is immune from DMSMS issues; they are inevitable. They affect short- and long-lived systems; repairables and consumables; space-based, air-based, ground-based, and sea-based equipment (including support and test equipment); and so on. DMSMS issues are not confined to piece parts or devices; obsolescence may occur at the part, module, component, equipment, or system level. DMSMS issues are also not limited to defense-unique items; commercial off-the-shelf (COTS) items represent a significant obsolescence problem, because such items are most susceptible to market forces.

Consequently, robust DMSMS management is needed. DMSMS management is a multidisciplinary process to identify issues resulting from obsolescence, loss of manufacturing sources, or material shortages; to assess the potential for negative impacts on schedule and/or readiness; to analyze potential mitigation strategies; and then to implement the most cost-effective strategy. DMSMS management has been most closely associated with electronics. However, DMSMS management also should be concerned with materials, mechanical items, and software.[5] This standardization document, which replaces the February 2015 version of SD-22, is intended primarily for the DMSMS practitioner community. It is a guidebook of best practices for implementing an effective DMSMS management program throughout the system life cycle. Because DMSMS considerations affect how a system is designed and sustained, program managers (PMs), engineers, and life-cycle logisticians (including supply chain managers, inventory managers, and maintainers) are also affected. Consequently, as beneficiaries of DMSMS management best practices, these communities and their associated policymakers are also part of the intended audience.

The purpose of this document is fivefold:

  • Create awareness of the extent and impact of DMSMS issues on DoD systems.
  • Define a robust DMSMS management process that a PM can use to build an effective DMSMS management program.
  • Define DMSMS support metrics to measure the effectiveness of a robust DMSMS management program.
  • Promote affordable and efficient program support through rapid and cost-effective DMSMS management best practices and resolutions that take into account equipment life cycles, technology changes, and planned obsolescence.
  • Promote the exercise of DMSMS management best practices throughout the acquisition life cycle.

1.2. DMSMS Mechanisms

Whether dealing with hardware–electronic and MaSME items or software, obsolescence is ultimately driven by one of a number of DMSMS mechanisms, influenced by the short life cycle of technology as compared to the long life cycle of defense systems. Figure 1 illustrates the symmetrical nature of both first-order and lower-order obsolescence mechanisms for hardware and software. Although the figure may give an impression of a sequential progression of events, that is not the case. Hardware and software obsolescence may occur simultaneously. To help drive home the point that both hardware and software are part of the same process, the figure shows “hardware and software monitoring” and “DMSMS resolution identification” as single boxes, rather than hardware- and software-specific boxes. Both hardware and software may also become functionally obsolete, as a secondary impact of some other change to the system.

There are two broad obsolescence mechanisms: first-order obsolescence and lower-order, or derived, obsolescence. First-order obsolescence is directly driven by market factors and regulation changes that affect DoD’s ability to buy, license, obtain support for, or use hardware and software. Lower-order obsolescence is functional obsolescence caused by hardware or software changes made to address first-order obsolescence, perform a proactive upgrade, or respond to a requirements change. Hardware and software monitoring identifies instances of first-order obsolescence. This monitoring also identifies functional obsolescence, resulting from proactive upgrades to hardware and software, in addition to, at least in part, driving the need to make proactive upgrades.

Figure 1 Mechanisms for Hardware and Software Obsolescence

Mechanisms for Hardware and Software Obsolescence

First-order obsolescence situations should be identifiable from hardware and software monitoring of the effects of market forces. When first-order obsolescence does occur, though, some of the root causes are as follows:

  • Hardware–electronic items. Sales and support may be terminated because of some combination of low demand, demand for new technologies and capabilities, lack of profitability, vulnerabilities, loss of production capability because of modernization or disposal of manufacturing equipment or mergers/acquisitions, unavailability of items, unavailability of materials, loss of repair support expertise, and so forth. For example, manufacturing tooling may be disposed of after production is completed.
  • Software. Competitive market forces can also lead to diminished capability. Companies generally do not find it sufficiently profitable to apply resources to support old versions of software; they prefer that customers upgrade to the most recent products. Mergers and acquisitions may lead to a similar situation. A program’s ability to use software is inextricably linked to obtaining a license or being able to purchase the software from a reliable source. Consequently, diminished ability to use software may occur when newer versions of the software are available or there is no longer an ability to read the digital media on which the software is delivered. In addition, there is a diminished ability to use software when its support terminates. Software support includes product enhancements to increase capability or to decrease vulnerability to malicious attacks, error correction, and general support for its application in particular environments. If support is no longer obtainable, updated security patches will not be available, bugs cannot be fixed, routine maintenance cannot occur, and modifications can no longer be made. For example, current software may not satisfy an emerging information assurance policy requirement or a cybersecurity protection requirement. Software support also terminates when the software development tools for building, testing, and integrating the software are no longer available, for example, compilers, databases, regression testing capability,[6] and configuration management (CM) software. Regardless of the market force that leads to diminished software capability, programs should be aware of associated security concerns and evaluate potential information assurance implications.
  • Hardware–MaSME items. Market forces also lead to DMSMS issues for hardware–MaSME items, but not quite in the same way as for electronic items and software. Unlike electronic items, MaSME items are typically on the market for long periods of time and, depending on the situation or support posture, are often repairable. Manufacturing processes for structural, mechanical, and electrical items have also remained relatively stable over time. Principal factors for DMSMS issues pertaining to materials (including critical materials resident within the supply chain) and structural, mechanical, and electrical items include the following:
    • Hazardous materials are being used. Regulations on hazardous materials may become stricter (e.g., Restriction of Hazardous Substances). Such materials may be banned completely or become difficult and/or prohibitively expensive to use or obtain (e.g., Freon or lead).
    • The supplier goes out of business or through a merger and acquisition in which the existing product line no longer fits in the new product portfolio. This is more likely with small and/or financially vulnerable suppliers that supply items to larger companies that use the items to assemble their product. Item lines that are sold from original companies to other businesses are vulnerable to being discontinued.
    • The supplier’s business case is no longer viable. This may occur with low-demand products potentially containing exotic materials that are difficult to manufacture or involve major disruptions to more profitable business activities. This may also occur as a result of regulation changes (e.g., tungsten rhenium wire was affected because of energy-related regulations on the disuse of incandescent light bulbs; Freon).
    • Supply-constrained materials are used. There may be U.S. or foreign regulations or supplier policies that affect availability. For example, a foreign source may limit its exports or not be willing to sell its product for a DoD application. The United States Code, Title 10, §2533b imposes restrictions on some specialty metals, for example, steel (specific mixes); metal alloys containing nickel, iron-nickel, and cobalt base alloys; titanium and titanium alloys; and zirconium and zirconium base alloys.[7]
    • The tooling is no longer available. Depending on the specific situation, resolving this issue may involve substantial time and cost.

Technology change may also be a factor, but this is often associated with COTS items for which the market situation is variable. Some COTS items (e.g., photographic equipment or network controllers) behave similarly to electronic items and software. Other COTS items (e.g., motors and pumps) behave more like MaSME items.

When a program takes an action to resolve first-order obsolescence or to proactively upgrade, the first-order changes implemented have the potential to cause lower-order or derived obsolescence. Below are descriptions of the different factors that influence the need for hardware or software changes and how such changes can cause lower-order obsolescence:

  • First-order hardware changes can result from one of three factors. First, robust DMSMS management seeks to refresh items before they become obsolete. Proactive technology refresh results in a hardware change. Second, hardware changes may be driven by implementing engineering resolutions to address DMSMS issues caused by the termination of sales or support of existing hardware. The resulting engineering resolutions range from the use of a simple substitute that relies on an existing replacement item to the redesign of the item to redesign at a higher level of assembly. Finally, a new performance requirement may necessitate a hardware change. Regardless of the factors influencing first-order hardware changes, lower-order hardware or software obsolescence may result because the existing hardware or software no longer functions as intended. For example, legacy software may not work, or may not work correctly, on new hardware configurations for a variety of reasons, such as data transmittal, storage, access, processing, display, interface issues, operating system capability issues, or timing concerns. Similarly, legacy hardware may suffer from physical incompatibility.
  • First-order software changes can result from factors that are analogous to the three factors that cause first-order hardware changes. Software upgrades or technology refreshments are not always compatible with other software applications that have been tested on or with earlier versions. For example, an upgrade to a COTS operating system may no longer support the assumptions made by the existing firmware; consequently, the firmware may become functionally obsolete. DMSMS resolutions implemented because of the inability to use software also lead to a first-order software change. Finally, first-order software obsolescence may be driven by changes to performance requirements that necessitate a software change. For example, scalability may be an issue if the transaction volume changes significantly. Greater processing power and memory size may also be required. The above rationale for first-order hardware changes leading to lower-order software or hardware obsolescence is directly applicable to first-order software changes leading to lower-order software or hardware obsolescence.

1.3. The Importance of a DMSMS Management Program

Ultimately, DMSMS management is important for a simple reason: it protects programs. Robust DMSMS management of inevitable obsolescence is the most cost-effective and efficient way to

  • minimize the scope of DMSMS-related out-of-cycle redesigns when they cannot be eliminated or avoided,
  • eliminate DMSMS-caused production schedule impacts, and
  • eliminate readiness degradations caused by DMSMS issues.

These three objectives of DMSMS management minimize the impact on the cost, schedule, and performance of a program, three primary concerns of a PM.

Because DMSMS management has a significant effect on many aspects of a program, it is not a standalone function, nor does it benefit a single stakeholder. DMSMS management is inherently linked with reliability, maintainability, supportability, and availability. Within this context, it is important to plan for, minimize, and manage the risks associated with DMSMS issues, due to their detrimental impact on materiel readiness, operational mission capability, safety of personnel, and affordability.

Materiel readiness is an immediate and urgent concern for the warfighter. Missions are affected if equipment cannot be supported; either the equipment is not available for the mission, or it cannot be sustained throughout the mission. DMSMS issues can negatively affect supportability if the items needed to repair a system are not available or are in scarce supply. It is unacceptable for a system to be non-mission-capable due to a DMSMS issue. To allow a DMSMS situation to progress to the point of affecting a mission (because items are not available) is contrary to DoD policy and is an indication of ineffective DMSMS management. In addition, ineffective DMSMS management can cause the costs for items to rapidly escalate.

A robust DMSMS management program is the most effective and efficient way to minimize readiness risks due to DMSMS issues, deliver better buying power, and improve overall life-cycle management. DMSMS resolutions are based on the most cost-effective approach to managing the problem before operations are affected. The cost avoidance by being proactive can be substantial, as discussed below:

  • The B-1 program office was informed by the original equipment manufacturer (OEM) that a radar system was experiencing obsolescence and the recommended system upgrade needed to resolve the problems would cost $350 million. DMSMS monitoring and surveillance indicated only minimal obsolescence existed, and the analysis team identified readily available alternate parts to replace the ones identified as obsolete. The bottom line was that obsolescence and supportability issues were easily overcome, allowing adequate cost-effective system support through continued organic depot repair with an estimated 10-year cost avoidance of $316 million.
  • The Apache obsolescence working group shares power equally between the government and contractor. Issues and details are discussed and resolved within this small team with an expansion of participation as needed from other functional disciplines. An empowered Apache program office champion drives recommendations to reality. This model has resulted in early discovery and intervention of obsolescence risks in an environment of agreed-to mitigation plans. The benefit has been no part shortages or schedule delays, identification of funding to mitigate obsolescence that does not require “robbing Peter to pay Paul,” and required redesign blended into planned design updates. The success of this model and this program is best represented by the cost avoidance by being proactive—over $200 million—realized by this working group across all configurations and life-cycle phases of this system.
  • The Virginia-class submarine program integrated DMSMS management into the construction program early in the design/build process. To ensure consistency and repeatability of results, the program office established a technology refreshment integrated product team (IPT), formalized a standard operating procedure, developed a memorandum of agreement with the Naval Supply Systems Command for the advanced procurement of spares, and established a budget. As a result, the program resolved more than 1,260 obsolescence issues and reaped more than $159 million of documented cost avoidance by being proactive since inception.
  • A foreign military sales (FMS) DMSMS team was asked to look into an obsolete part (a digital display indicator) needed for critical support equipment used by FMS customers. The OEM was unable to fulfill a request for the support equipment due to the obsolete part and quoted $2.6 million for redesign. The FMS DMSMS team examined an available drawing, identified the original component manufacturer part number, researched the supply system, located the original component manufacturer, and was able to obtain 50 of the parts needed (more than the required quantity) for $327,000, resulting in a $2.3 million cost avoidance by being proactive. The extra parts were transferred to the inventory of another platform using the same equipment.

The examples demonstrate how DMSMS management can result in better value for the taxpayer and the warfighter. However, benefits extend well beyond these examples. Since 2010, the Under Secretary of Defense for Acquisition, Technology and Logistics has signed and issued several memorandums, one building on the other, providing specific guidance for improving the way DoD does business. The 2014 “Better Buying Power 3.0” white paper augmented and modified the 2012 “Better Buying Power 2.0” memorandum, establishing the following focus areas:[8]

  1. Achieve affordable programs.
  2. Achieve dominant capabilities while controlling life-cycle costs.
  3. Incentivize productivity in industry and government.
  4. Incentivize innovation in industry and government.
  5. Eliminate unproductive processes and bureaucracy.
  6. Promote effective competition.
  7. Improve tradecraft in the acquisition of services.
  8. Improve the professionalism of the total acquisition workforce.

Robust DMSMS risk management is a contributor especially important to focus areas 1, 2, 3, 4, 6, and 7. DMSMS management helps target affordability and control cost growth (focus areas 1 and 2) in several ways. By accounting for DMSMS issues during design (trades), future operating and support (O&S) costs will be controlled and possibly reduced. For example, the use of standardized parts and the latest technologies can reduce the impact of DMSMS issues during sustainment by enhancing the interchangeability, reliability, and availability of items. Robust DMSMS management may enable programs to control cost by achieving “should cost” estimates.

To incentivize productivity and innovation in industry (focus areas 3 and 4), robust DMSMS management will cultivate long-term relationships with suppliers using performance-based logistics precepts and other means. Given such relationships, suppliers should be less likely to discontinue an item, and if they decide to discontinue the item for business reasons, the government is more likely to have advanced warning, placing it in a better position to plan an alternative course of action. This planning could be done in coordination with industry. A new initiative in “Better Buying Power 3.0” is to emphasize technology insertion and refresh in program planning. DMSMS management results should be a key driver of technology refresh plans. The ultimate goal is to replace items before they become obsolete.

Promoting effective competition (focus area 6) by developing alternate sources of items with DMSMS issues is also a key element of robust DMSMS management. Both open systems architecture and data rights in designs enable competition by providing a framework for decomposing a system into items and obtaining the necessary technical information for them. Modular open systems architecture is not only a driver of innovation, it is also an important DMSMS-related design consideration, because substitution of alternative items becomes easier. Robust DMSMS management will secure data rights and bills of materials (BOMs) for items highly likely to face DMSMS issues.

Service contracts (focus area 7) are often used for system support. Clauses in these contracts may require a contractor to manage DMSMS issues. Those clauses must have the right incentives for robust DMSMS management, including effective metrics and notification of issues to the government as soon as they are discovered. For example, if the contractor is concerned only with availability, then costs may get out of control. The proper incentives must be in place for the contractor to manage DMSMS issues, considering both industry and government perspectives. This is where the initiative to improve tradecraft in the acquisition of services comes into play.

1.4. Overview of the DMSMS Management Process

The DMSMS management process is straightforward. As illustrated in Figure 2, it has five steps:

  • Prepare. Develop the DMSMS strategic underpinnings (e.g., vision and focus) and a DMSMS management plan (DMP) to implement the strategic underpinnings for the program. Form a DMSMS management team (DMT) representing all stakeholders. Establish, document, and resource DMSMS management processes for the DMT to execute the DMP.
  • Identify. Secure access to logistics, programmatic, and item data and to monitoring and surveillance tools. Identify items with immediate or near-term obsolescence issues.
  • Assess. Considering the population of problem items, identify and prioritize the items and assemblies most at risk for current and future readiness or availability impacts.
  • Analyze. Examine the problem items with near-term readiness or availability impacts first. Develop a set of potential DMSMS resolutions for the items and their higher-level assemblies. Determine the most cost-effective resolution.
  • Implement. Budget, fund, contract or arrange for, schedule, and execute the selected resolutions for the high-priority items.

Figure 2 Steps in the DMSMS Management Process

Steps in the DMSMS Management Process

Each of these steps applies throughout the life cycle, from early technology development through sustainment. Although it is best to begin these activities early in the life cycle, they may be initiated at any point in the process. Robust DMSMS management is a dynamic process that never ends. Once a program solves one issue, it should move on to the next. When a program has gone through its list of issues, it should start again; something will have changed. A program should repeat this process until its system retires. Ultimately, the DMSMS management process constitutes DMSMS risk management.

1.5. Organization of This Document

The five steps of the DMSMS management process constitute the core organizing principle for this document:

  • Section 1 provides an overview of DMSMS as both a concept and a multidisciplinary process. Specifically, it describes the DMSMS scope and objective, the mechanisms that drive obsolescence, the importance of establishing a DMSMS management program, and an overview of the DMSMS management process steps.
  • Section 2 discusses the link between DMSMS management and the defense acquisition system, with particular focus on systems engineering (SE) and life-cycle product support. This section provides important input to and context for the rest of the document.
  • Section 3 addresses the Prepare step of DMSMS management. Specifically, it describes best practices for establishing a strong infrastructure—data, people, processes, management reports, and financial resources—for successful DMSMS management.
  • Section 4 focuses on the Identify step, which encompasses DMSMS monitoring and surveillance throughout the life cycle and includes best practices for determining where to focus DMSMS management efforts.
  • Section 5 discusses the Assess step of DMSMS management. It begins with a discussion of the monitoring and surveillance data collected; it also describes how to measure the operational impacts of the risks and how to prioritize them.
  • Section 6 focuses on the Analyze step, which deals with analyzing alternative approaches for resolving DMSMS issues and identifying the preferred alternative. This section lists DMSMS resolution options and provides a basis for estimating their cost. It also identifies risk factors associated with these options.
  • Section 7 addresses the Implement step, which covers the implementation of the preferred resolution option. It discusses potential sources of implementation funding, the roles of the DMT during implementation, and some considerations associated with common implementation issues.

Appendixes A through L contain supporting detail about DMSMS activities, such as questions that need to be addressed for SE technical reviews and logistics assessments (LAs), examples of contract language related to DMSMS management, DMSMS workforce competencies and the capabilities of a robust DMSMS management program, DMSMS implications of counterfeit parts and lead-free electronics, best practices for the quality assurance (QA) of DMSMS processes, and ways to access additional DMSMS knowledge and organic services and capabilities. Appendix M defines abbreviations used throughout this document.

Figure 3 shows the high-level interrelationships of the five DMSMS steps, the corresponding sections of this document, and the supporting appendixes. The figure does not show Appendix H, which contains reference information about all DMSMS activities.

Figure 3. Interrelationships among the DMSMS Processes and the Document’s Components

Interrelationships among the DMSMS Processes and the Document’s Components

2. DMSMS Management Links to the Defense Acquisition System

This section addresses the relationship of defense acquisition system policy and guidance to DMSMS management policy and guidance. Considering overarching DoD policy and guidance, the DoD Components have created their own policies, which can be found in the DMSMS Knowledge Sharing Portal (DKSP) described in Appendix H. The DKSP also contains DoD Component guidance documents.

2.1. DMSMS Policy

DoD Instruction (DoDI) 5000.02, “Operation of the Defense Acquisition System,”[9] has established DMSMS policy in its Enclosure 6 on life-cycle sustainment as follows: “Ensure identification of obsolete parts in specifications and develop plans for suitable replacements in accordance with P.L. 113-66, Section 803.”[10] The public law requires the Secretary of Defense to “implement a process for the expedited identification and replacement of obsolete electronic parts included in acquisition programs of the Department of Defense.” The following, taken verbatim from the public law, are characteristics of that process:

  1. include a mechanism pursuant to which contractors, or other sources of supply, may provide to appropriate Department of Defense officials information that identifies—
    1. obsolete electronic parts that are included in the specifications for an acquisition program of the Department of Defense; and
    2. suitable replacements for such electronic parts;
  2. specify timelines for the expedited review and validation of information submitted by contractors, or other sources of supply, pursuant to paragraph (1);
  3. specify procedures and timelines for the rapid submission and approval of engineering change proposals needed to accomplish the substitution of replacement parts that have been validated pursuant to paragraph (2);
  4. provide for any incentives for contractor participation in the expedited process that the Secretary may determine to be appropriate; and
  5. provide that, in addition to the responsibilities under section 2337 of title 10, United States Code, a product support manager for a major weapon system shall work to identify obsolete electronic parts that are included in the specifications for an acquisition program of the Department of Defense and approve suitable replacements for such electronic parts.”

That policy has been amplified in DoDI 4140.01, “DoD Supply Chain Materiel Management Policy,” which states the following:[11]

  • “DoD materiel management shall operate as a high-performing and agile supply chain responsive to customer requirements during peacetime and war while balancing risk and total cost. The DoD supply chain shall provide best-value materiel and services in support of rapid power projection and operational sustainment of U.S. forces as required by the National Military Strategy. Potential disruptions within and outside the DoD supply chain shall be identified, monitored, and assessed in order to mitigate risk to supply chain operations. Life-cycle management controls shall be applied to guard against counterfeit materiel in the DoD supply chain. Energy efficient products or services shall have preference in all procurements, except those products or services procured for combat or combat-related missions.”
  • “Resourcing for all elements of the DoD supply chain shall be optimized through collaboration between support providers and customers. DoD investment shall be sufficient throughout the life cycle of new or existing weapons systems, equipment, and major end items to respond to warfighter needs. Performance and cost evaluations of supply chain operations and inventory shall be conducted periodically with the objective of ensuring that assets are available for use or reuse in the DoD supply chain to satisfy customer requirements.”

DoD Manual (DoDM) 4140.01, “DoD Supply Chain Materiel Management Procedures: Materiel Sourcing,” implements that policy for DMSMS as follows:[12]

  • “The Military Departments and [Defense Logistics Agency] (DLA) will: (1) Proactively take timely and effective actions to identify and minimize the DMSMS impact on DoD acquisition and logistics support efforts. (2) Develop and fund a standard DoD strategy and program to resolve problems created by DMSMS and to resolve those problems in a way that reduces or eliminates any negative impacts. (3) Proactively consider DMSMS through a system’s life cycle by anticipating potential DMSMS occurrences and taking appropriate logistics, acquisition, and budgeting steps to prevent DMSMS from adversely affecting readiness or total ownership cost.”
  • “The Military Departments and DLA will designate a focal point to plan and coordinate actions to minimize the impact of DMSMS.”
  • “When items are difficult to obtain because they are obsolete, out-of-production, or for other reasons, weapon system program managers and materiel managers will take measures to prevent potential counterfeit materiel or unauthorized product substitution items from entering the supply system.”
  • “Commanders of activities with responsibility for design control, acquisition, and management of any centrally managed item used within weapon systems or equipment will implement the DMSMS program by establishing internal procedures.”
  • “When an item is identified as DMSMS, the managing Military Department or DLA [will implement] the most cost effective solution consistent with mission requirements.”
  • “The Military Departments and DLA will send to the cognizant materiel manager the information that was originally obtained from industrial sources about an actual or prospective announcement of a manufacturer’s intent to stop production. … The cognizant materiel manager will notify the [Government-Industry Data Exchange Program] to establish a DMSMS case.”
  • “The Military Departments and DLA will ensure that the [Inventory Control Point] maintains post-action surveillance throughout the life of DMSMS items in the DoD supply system.”
  • “DLA or the managing Military Department as well as security assistance customers who use the specific items will respond to requests for requirements information needed to decide the best course of action for ensuring continued supply of DMSMS items.”

2.2. DMSMS Guidance for the Program Manager

DoD Directive (DoDD) 5000.01, “The Defense Acquisition System,” contains principles, policies, and procedures for managing all acquisition programs. One such policy establishes the importance of cost and affordability over the life cycle of a DoD system:

All participants in the acquisition system shall recognize the reality of fiscal constraints. They shall view cost as an independent variable, and the DoD Components shall plan programs based on realistic projections of the dollars and manpower likely to be available in future years. To the greatest extent possible, the MDAs [Milestone Decision Authorities] shall identify the total costs of ownership, and at a minimum, the major drivers of total ownership costs. The user shall address affordability in establishing capability needs.[13]

Figure 4 depicts the acquisition life cycle.

Figure 4. Acquisition Life Cycle

Acquisition Life Cycle

Adapted from DoDI 5000.02, January 7, 2015, p. 5.

SE is the technical management approach used to ensure the consideration of affordability throughout the life cycle. According to DoDD 5000.01,

acquisition programs shall be managed through the application of a systems engineering approach that optimizes total system performance and minimizes total ownership costs. A modular, open-systems approach shall be employed, where feasible.[14]

DoDD 5000.01 also provides the PM with the responsibility and authority to ensure that cost and affordability are considered throughout the life cycle. This is termed total life-cycle systems management:

The PM shall be the single point of accountability for accomplishing program objectives for total life-cycle systems management, including sustainment. The PM shall apply human systems integration to optimize total system performance (hardware, software, and human), operational effectiveness, and suitability, survivability, safety, and affordability. PMs shall consider supportability, life-cycle costs, performance, and schedule comparable in making program decisions. Planning for Operation and Support and the estimation of total ownership costs shall begin as early as possible. Supportability, a key component of performance, shall be considered throughout the system life cycle.[15]

The role of the PM changes over the life cycle of a system. DMSMS management assists the PM in fulfilling his or her responsibilities in each phase of the defense acquisition system. Before the establishment of initial operational capability (IOC), the PM is responsible for the design, development, and production of the system, with two primary goals: meet performance requirements and minimize life-cycle costs. Once the system is fielded, the PM is responsible for affordably supporting the system as it is used for both training and operations.

Robust DMSMS management is important to these PM responsibilities, because it accomplishes the following:

  • Establishes criteria for evaluating design alternatives from a DMSMS management perspective
  • Helps ensure the availability of all items and material required to design, produce, or repair the system or equipment
  • Controls and possibly reduces total ownership cost
  • Provides for risk mitigation as it applies to DMSMS issues
  • Identifies potential DMSMS issues early enough to allow all applicable resolution options to be considered
  • Evaluates all of the applicable approaches to resolve DMSMS issues
  • Collects metrics to monitor program effectiveness.

The importance of DMSMS management to the PM for ensuring cost and affordability throughout the system life cycle has also been highlighted by the Defense Acquisition University (DAU): “Obsolescence and DMSMS will eat your lunch (along with breakfast and dinner if you’re not careful).”[16]

The PM should establish an aggressive set of DMSMS management strategic underpinnings and develop and adopt a plan to execute those strategic underpinnings. This will help ensure that design, product support, modifications, and service life extensions will be effective from a supportability perspective.

Continuous modernization and technology insertion/refreshment are important enablers. In fact, DMSMS management should guide the program’s broader plans. DMSMS health assessments—which integrate estimated obsolescence dates, usage rates, items due and stocks on hand, to highlight when an item or assembly will no longer be supportable—should guide the program’s overall technology management strategy, plan, and roadmaps to synchronize efforts to address technology trends and requirement-driven product upgrades.

The Defense Acquisition Guidebook (DAG) establishes a framework for the PM to carry out cost- and affordability-related functions, as shown in Figure 5.[17]

Figure 5. Framework for Ensuring Affordable System Operational Effectiveness

Framework for Ensuring Affordable System Operational Effectiveness

Source: Defense Acquisition Guidebook.

According to the DAG, affordable system operational effectiveness is achieved by designing for the optimal balance between performance (technical and supportability), total ownership cost, schedule, and process efficiency that enables production, operation, and sustainment. The concept of affordable system operational effectiveness is important, because it is what the warfighter sees in terms of how well the system performs its missions over a sustained period, as well as how well it supports a surge, given the operating budget. In this concept, the emphasis is not only on the system’s ability to execute its mission or its reliability and maintainability, but also on the cost-effective responsiveness of the supply chain.

The framework should not be viewed as static. Initially, the design is a driver of the product support strategy. However, one of the tenets of evolutionary acquisition is incremental block development. Future increments of design are influenced by new technical performance requirements, the current degree of supportability, the current product support concept, and affordability. Consequently, life-cycle cost and process efficiency affect supportability in future increments of the system.

The following two subsections expand upon the framework’s two major elements: design effectiveness and process efficiency.

2.3. Design Effectiveness and DMSMS

The DAG describes how design effectiveness reflects the key design features of technical performance and supportability.[18] These characteristics should be designed into the system and with full knowledge of the expected system missions within the context of the proposed system operational, maintenance, and support concepts. To be effective, technical performance and supportability objectives should be defined in explicit, quantitative, and testable terms. This is important to facilitate tradeoffs, as well as to support the selection and assessment of the product and process technologies needed to achieve those objectives.

2.3.1. DMSMS as a Consideration in Design

Design effectiveness is an overarching outcome of SE. This is where the product support manager (PSM) provides advice about design tradeoffs. Section 4.3.18 of the DAG, “Systems Engineering Design Considerations,” discusses how design is a complex task that must balance a large number of performance, support, safety, environmental, security, regulatory, and other requirements and constraints. Because a feasible solution can rarely satisfy all of these things in a cost-effective way, the SE process guides design tradeoffs, including the consideration of DMSMS-related interests and concerns, to develop a balanced solution for all stakeholders. This section provides guidelines regarding the DMSMS trade space for initial design and subsequent redesign phases resulting from DMSMS considerations.

DMSMS is one among many product support design considerations in the DAG. Design decisions made early in a program—for example, during the materiel solution analysis, technology maturation and risk reduction, and engineering and manufacturing development phases—have a substantial impact on operations and support costs later in the program. As shown in Figure 6, a high percentage of the life-cycle costs of a program are locked in based on early design decisions.

Figure 6. Relationship between a Program’s Expended Life-Cycle Cost and Locked-In Cost

Relationship between a Program’s Expended Life-Cycle Cost and Locked-In Cost

Source: W.J. Larson and L.K. Pranke, Human Spaceflight: Mission Analysis and Design (McGraw-Hill, 1999).

During the initial design process, performance, supportability, logistics, cost, and other considerations all have to be balanced and trades made to produce the optimal design. For a redesign effort, specifications and interfaces already exist, which may constrain the ability to determine an optimal design. DMSMS is one of the many considerations informing design and redesign decisions.

A DMSMS review of system or product designs provides the opportunity to design out items that are high risk for various reasons. For example, if they are near their end of life (EOL), replacing them would be difficult or complex, and requalifying the system after replacing the items would be costly. As a best practice, program leadership should actively set the tone for the importance of DMSMS even as early as the Preliminary Design Review (PDR) by setting design goals that consider availability, supportability, producibility, reliability, and maintainability over the fielded lifetime of the product or system. These considerations should be built into the checklist for discussions with the chief engineer and program manager leading up to each review milestone. For example, the program might challenge its design engineers to develop a design that will endure until year X, where “X” is the year in which either the next production block or technology insertion is scheduled. Considering DMSMS during design not only will help to avoid the incorporation of obsolete or soon-to-be obsolete items, but will also enable a program to more easily implement or integrate resolutions to and mitigate the impact of any DMSMS issues that do emerge during each phase of a program. DMSMS can have such a substantial cost impact to program execution that failure to track and address these issues can have serious impact to cost, schedule, and even program viability.

Below are several design concepts that designers and systems engineers should consider to minimize DMSMS risk throughout the life cycle of a system or product:

  • Technology and item selection. New technologies do not capture 100 percent of the market all at once; there is a period of time when both the new technology and the one it replaces are in use. However, the design should not include anything that is near the end of its functional life. A technology roadmap that anticipates the life spans of technologies and synchronizes both technology refreshment and insertion is useful when designing systems, especially electronic systems. There are, however, tradeoffs associated with selecting new technologies. New technologies can be profoundly more effective at some important defense performance parameter, and thereby enable major changes in defense capability. So it is desirable to be able to insert such new technologies. However, there is often a learning phase associated with a new technology in which issues are discovered.[19] Consequently, choosing the appropriate technology insertion timing where leading capability exists but where early phase problems have been corrected is essential. When feasible to do so, it is also a best practice to avoid the selection of sole-source items.
  • Parts management. Parts management is a design strategy for standardization and reuse that can enhance the reliability of the system and mitigate obsolescence due to DMSMS.[20] An up-front assessment of the risk of obsolescence should influence parts selection during the design process. Parts selection encompasses both the selection of new parts and the reuse of parts from previous designs. The selection of new parts might seek to standardize the use of parts to the greatest extent possible and minimize the use of custom parts through the recommendation of alternatives. For example, field-programmable gate arrays instead of application-specific integrated circuits (ASICs) may provide the advantage of being able to purchase much larger quantities of a part type, and thereby enjoy volume discounts, and improved factory support, and reduced development cycle time and cost. This is a tradeoff, however, with lower power and higher performance for an ASIC designed specifically for a task where the volume or performance justifies the ASIC development. If unique, highly specialized parts are used to meet performance requirements, DMSMS issues during operations and support will be more prevalent. The risk assessment should also consider material selections, economic and regulatory trends, unique manufacturing processes, packaging schemes, and so on. Before including a part on a preferred parts list, the identified risks should be assessed and managed in order to make the BOM stable and sustainable.[21] As the design stabilizes, it should minimize the number of OEM or original component manufacturer (OCM) parts necessary for production. When nonpreferred parts are used, their designs should be captured in the proper transportable computer-aided design models.[22] A somewhat higher level of parts management is standardized module development. For example, a common design can be reused over and over for many purposes, perhaps with minor variation in software or minor variation in connected sensors and actuators to enable use in many different applications. Similarly, this same platform can be repackaged in a different shape but otherwise the same design. The net result of standardized module design is, as above, higher volume of product, better factory support from suppliers, and more rapid increase of product reliability and producibility. In the context of DMSMS, the higher-volume consumption of components enables a closer connectivity with suppliers to work DMSMS sourceability issues.
  • Open systems architecture–hardware. An open systems architecture employs technology-independent modular design tenets, uses widely supported and consensus-based standards for its key interfaces, and is subject to validation and verification, including test and evaluation (T&E), to ensure that key interfaces meet open standards. An open systems architecture thereby takes equipment roadmaps and technology insertion plans into account. Also, compared with design-specific approaches, it enables readily available alternative items to be used more easily in place of obsolete items, as long as the substitutes have the same form/fit/function (F3) and interface as the ones they replace. Test interfaces must also be considered. An open systems architecture reduces DMSMS costs, because it avoids expensive redesign by facilitating the insertion of advanced technologies.[23] Often, it also enables multi-vendor competition, which will minimize the likelihood of future DMSMS issues.
  • Open systems architecture–software. An open and modular design enables the development of “plug-and-play” hardware and software that are interchangeable through industry-standard interface modules. To minimize DMSMS impacts, the software architecture of a system should be designed to take growth, evolving standards, and interfaces into consideration.[24] This provides for change while minimizing the impact on existing system functions. In addition, the design should allow for partitioning of the software into appropriate units that can be tested in isolation and should avoid making software dependent on the hardware through the appropriate isolation of drivers. Plug-and-play interfaces are desirable when appropriate. Low coupling (interdependent relationships) within a system allows a system to rely on information sharing to control, manage, and execute functions. When designing custom software and selecting COTS software, a program will also want to carefully select interface standards and protocols that are the most stable and have the broadest support, as these will have greater staying power within industry. A program should also seek to minimize the number of different interface standards and protocols applied across the weapons system, because this will simplify the design configuration and configuration management issues. The focus of software design can then be to meet the driver interfaces, rather than different, specific hardware items. Transportability of models that capture critical elements of the design is a consideration. The modules of an open system should be discrete, scalable, and reusable with low connectivity to the relationship between internal elements of different modules, simplifying and decreasing the number of interfaces required. Having high cohesion among module functions also enables multitasking and use of identical modules throughout the system. Significant complexities may be associated with using open systems architecture principles for a new software design being incorporated into an existing asynchronous system. One approach to software design is object-oriented design, which can increase portability and reusability of software. Finally, DMSMS issues will often require an update of standards-based protocols (such as Internet protocols). Because standards-based protocols are revised relatively often due to cyber defense issues, it is essential to recognize that the operating system and protocol stack are likely to be revised frequently and therefore any system should provide the required mechanisms for assured updates.
  • Use of COTS assemblies. COTS assemblies offer opportunities for reduced development time, faster insertion of new technology, lower procurement costs, and potentially, lower life-cycle costs, due to a more robust industrial base. Consequently, DoD systems increasingly comprise COTS assemblies and software. Unfortunately, the use of COTS assemblies also presents some challenges. The DoD community has little influence over the far shorter life cycle of commercial products. Consequently, information on the future availability of COTS assemblies is hard to obtain or track. Changes during the system life cycle may not be documented, increasing the likelihood of CM and DMSMS issues. In addition, depending upon the system and program management practices, requalification costs associated with replacing COTS assemblies may be significant. For that reason, the initial cost savings from the use of COTS assemblies may be offset by increased costs later in the life cycle when those assemblies have become obsolete or are replaced by a later-generation design. In short, it may or may not be appropriate to include COTS assemblies in critical paths or functions of a system. Before including a COTS assembly in a design, the designer or PM should assess the risk and suitability (which should include developing a technology roadmap and refreshment strategy).[25] A program should avoid modification of COTS assemblies or software without careful consideration of the implications and alternatives. For example, modification could make the assembly or software nonstandard and incompatible with any standard updates to correct for deficiencies or errata, to add a feature, or to otherwise optimize performance. A PM would then be faced with choosing between the immediate costs of further revising the nonstandard assembly or software (to incorporate the update) or future high support costs and the inevitable obsolescence.

In addition to design concepts, the design tools themselves can impact future DMSMS issues. Modern defense systems are designed, built, and manufactured with extremely capable
computer-aided design tools. These tools enable exhaustive checking of a design at each design phase. Whether electrical design, software design, firmware design, mechanical design, system design, system validation, production, or life-cycle support, modern tools will be valuable in reducing the cycle time and eliminating many common types of errors. Some of these tools interface with DMSMS resources to provide alerts regarding the latest issues with components or subsystems or with current practices. Some are also able to check rules and checklists for best practices and identify alternate items that may be in an earlier stage of their life cycle. All are able to provide appropriate design documentation.

DMSMS is one of numerous priorities and requirements competing for the attention of the PM. Part of the DMSMS community’s role is to educate PMs on the importance of identifying and addressing obsolescence issues as early in a program as possible, often by addressing downstream implications. The DMSMS community should not be thought of as a single-issue community on its own. Instead, DMSMS should be approached as an integral part of reliability, maintainability, availability, and supportability. Indeed, the DMSMS community might be able to build momentum and weight behind its recommendations by leveraging the interaction that other communities have with the PMs and chief engineers. Ultimately, the bottom line is that even if the DMT is unable to influence the design in a manner that eliminates “designing in” an item that is or has the potential to soon be obsolete, it will have at least identified DMSMS risks to continue to monitor for potential future mitigating actions.

The establishment and conduct of a DMT can serve as another point of leverage for the ongoing identification and mitigation of DMSMS issues throughout a program. Such a team would include relevant stakeholders, representing both government and contractors, and ensure regular, scheduled communication to discuss and resolve obsolescence as it pertains to the design of the system for the program in question.

2.3.2. DMSMS Considerations in Systems Engineering Technical Reviews

  • Given the long life cycles of defense systems, the exclusion of obsolete items from the designs of those systems is an obvious best practice. Program leadership should ensure that a DMT has the opportunity, throughout the program life cycle, to review all designs and redesigns for obsolescence. Even in the early stage of a program and before BOMs are available, the DMT can examine a preliminary parts list to identify whether any important parts being considered are obsolete or near obsolete. Doing so offers a program the opportunity to lower the cost of redesigns, identify items that should be designed out prior to causing a detrimental impact, and also provide guidance to the program on what may need to be preserved, in terms of technical data, tooling, and insurance spares in order to hedge against future obsolescence. Even when the use of obsolete items cannot be prevented, having properly vetted a system’s design can enable a program to prepare a mitigation strategy to address the known obsolescence at a lower cost. A program should incorporate the necessary language into contracts to ensure that the program is able to review all designs and redesigns in relation to SE technical reviews, which are used throughout the life cycle as a means for the program office to assess how to technically proceed with the program. Figure 7 illustrates how some of the technical reviews relate to the life cycle.

Figure 7. Timing of Systems Engineering Technical Reviews

Timing of Systems Engineering Technical Reviews

Source: Adapted from the Defense Acquisition Guidebook.

Notes: ASR = Alternative Systems Review, CDR = Critical Design Review, PDR = Preliminary Design Review, PRR =
Production Readiness Review, SFR = System Functional Review, and SRR = Systems Requirements Review.

Table 1 summarizes specific issues that may be of interest from a DMSMS management perspective at the time of each technical review.

Table 1. Summary of Principal Systems Engineering Technical Reviews

Phase

Review type

Specific issues of interest
from DMSMS perspective

Materiel Solution Analysis

ASR

DMSMS management planning has been initiated and is focused on the most likely preferred systems concepts. DMSMS impacts may be a consideration when performing an analysis of alternatives (AoA) to ensure that the preferred system is cost-effective, affordable, operationally effective, and suitable and can be developed to provide a timely solution to a need at an acceptable level of risk.

Technology
Maturation and Risk Reduction

SRR

The program has begun to develop its DMSMS management strategy and plan, which begins to identify the roles and responsibilities of the government, prime/subcontractor, and third-party vendors. Some members of the DMT and contracting strategies have been identified. Technology development contracts require the delivery of data necessary for DMSMS management and define the contractor roles and responsibilities.

SFR

The DMP has been developed and a partial DMT has been formed. The development of DMSMS processes and metrics is underway.

PDR

The DMP, including the documentation of all operational processes, has been formally approved by program leadership. Monitoring and surveillance for DMSMS issues, using predictive tools and market surveys, is being conducted for notional or preliminary parts lists/BOMs. Impact assessment (using estimated reliability data), resolution determination, and resolution implementation have begun. Technology roadmaps and refreshment strategies are being factored into DMSMS management processes.

Engineering and Manufacturing Development

CDR

Monitoring and surveillance for DMSMS issues, using predictive tools and market surveys, are being conducted for the build baseline/final design, indentured BOM. Impact assessment (using estimated reliability data), resolution determination, and resolution implementation are taking place. Technology roadmaps and refreshment strategies are being factored into DMSMS processes. Case management and the capture of metrics are taking place. Engineering and manufacturing development contracts require the delivery of data necessary for DMSMS management and define the contractor roles and responsibilities.

PRR

Monitoring and surveillance for DMSMS issues, using predictive tools and market surveys, are being conducted. Impact assessment (using estimated reliability data), resolution determination, and resolution implementation are taking place. Technology roadmaps and refreshment strategies are being factored into DMSMS processes. Case management and the capture of metrics are taking place.

The SE community has developed checklists for each of the technical reviews. These checklists should be used during the reviews as the primary guide for assessing risk. DMSMS management-related issues also are suitable issues to be considered during all technical reviews.

Appendix D identifies a number of specific DMSMS management-related questions for use in support of technical reviews. The DMSMS management-related questions offered in that appendix have been designed for use by the DMSMS community to inform DMSMS-related discussions before the technical reviews and to highlight DMSMS issues to be addressed during the reviews. DMSMS management-related questions are already incorporated into the SE checklists for technical reviews; however, an effort has been made to expand upon them systematically for DMSMS practitioners.

The program should review and oversee the DMSMS management efforts of its prime contractor and ensure that all obsolescence issues are reviewed and resolved prior to the decision to proceed to the next phase in the life cycle, particularly before moving into production.

2.4. Process Efficiency and DMSMS

The DAG defines process efficiency as an indicator of how well the system can be produced, operated, serviced (including fueling), and maintained. It also indicates the degree to which the logistics processes (including the supply chain), infrastructure, and footprint have been balanced to provide an agile, deployable, and operationally effective system. Achieving process efficiency requires early and continuing emphasis on the various logistics support processes, along with other design considerations. An emphasis on process efficiency is important, because processes present opportunities for improving operational effectiveness—via Lean Six Sigma, supply chain optimization, and other continuous process improvement techniques—even after the design-in window has passed. Optimization and continuous process improvement techniques can be applied through, for example, supply chain management, resource demand forecasting, training, maintenance procedures, calibration procedures, packaging, handling, and transportation and warehousing processes.

The product support package and some of its key functions, as derived from the product support strategy, contribute to process efficiency. The product support package is formulated to provide supportability during the O&S phase of the acquisition life cycle. These are key areas for the PSM to contribute to supportability.[26]

2.4.1. Acquisition Strategy

The technology maturation and risk reduction phase of acquisition is focused on reducing technology risk associated with the set of technologies to be integrated into a full system. Activities in this phase are guided by a Technology Development Strategy (TDS). The TDS is a precursor to the Acquisition Strategy (AS) in that it provides overall cost, schedule, and performance goals for the program. At program initiation, the AS replaces the TDS.

According to the DAG, program strategies include the TDS and the AS. They optimize the time and cost required to satisfy approved capability needs and should be updated for all major decision points. Consequently, the combination of the TDS and the AS is the overarching program management plan. DMSMS management concepts are included in these documents in the section dealing with industrial capability and manufacturing readiness. The DMSMS management discussion should address technology obsolescence, replacement of limited-life items, and regeneration options for unique manufacturing processes.[27]

2.4.2. Product Support Strategy

The product support strategy translates warfighter requirements into performance outcomes. It is defined and implemented through a 12-step process, [28] which must be updated regularly throughout the life cycle. Three of these steps, those with expanded explanations in the following list, have been linked with DMSMS management:

  • Integrate warfighter requirements and support.
  • Form the product support management IPT.
  • Baseline the system. This step includes collecting data needed to assess and analyze support decisions. Strategically planning for technology refreshment is an important contributor to the design for support, and DMSMS management is recognized as one of several drivers of technology refreshment. The product support strategy itself affects the implementation of DMSMS management both within the program office and with contractors.
  • Identify or refine performance outcomes.
  • Conduct a business case analysis (BCA). This step involves using a structured method to identify and compare alternative product support solutions. Obsolescence management is part of the BCA scope. A DoD guidebook recommends the use of DMSMS analytical tools.[29]
  • Analyze the product support value. This step consists of assessing the results of the BCA to identify the optimal best-value product support solution. DMSMS management should be considered as part of best-value analysis to optimize life-cycle cost.
  • Determine support methods.
  • Designate product support integrators.
  • Identify product support providers.
  • Identify or refine financial enablers.
  • Establish or refine product support agreements.
  • Implement and assess.

2.4.3. Life-Cycle Sustainment Plan

The Life-Cycle Sustainment Plan (LCSP) provides for the execution of the product support package.[30] DMSMS management is identified as a notional entry in an LCSP table of regulatory/statutory requirements that influence sustainment performance. In addition, the LCSP is required to include a detailed, integrated life-cycle system schedule that contains major logistics sustainment events including dependencies on key sustainment planning documents. The DMP is identified as one of the key sustainment planning documents.

LCSP product support functions are derived primarily from the last five product support strategy steps listed above. Twelve integrated product support elements embody the tasks associated with the product support functions. The 12 elements, listed below, include 6 (those with expanded descriptions) that are linked with DMSMS management:[31]

  • Product support management. This element deals with planning and managing cost and performance across the product support value chain. The product support strategy is not static. It evolves as the system ages, in part because DMSMS issues affect the PSM’s ability to provide support, including the cost of that support. Therefore, the product support strategy needs to be reassessed periodically. The changes resulting from this reassessment are reflected in changes to the post-production support plan and the resources required for plan execution.
  • Design interface. This element deals with participation in the SE process to ensure the design facilitates supportability. DMSMS issues, technology refreshment, and modifications and upgrades are called out as long-term considerations affecting design. DMSMS management presents an important opportunity to influence design.
  • Sustaining engineering. This element deals with the continued operation and maintenance of a system with managed risk. It recognizes that DMSMS problems are a root cause of in-service problems and that modernization should anticipate DMSMS issues. Cautions are raised with the use of COTS assemblies and the risk of underestimating the number of or potential for DMSMS problems. The guidance also links to DMSMS management-related reference material, including this document.
  • Supply support. This element deals with the identification, planning for, resourcing, and implementation of all management actions to acquire repair items, spares, and all classes of supply to ensure that equipment is ready when needed. Over time, any product support strategy based on the production supply chain will need to shift to a sustainment supply chain. Furthermore, sustainment supply chains will have to be adjusted if DMSMS concerns exist.
  • Maintenance planning and management.
  • Packaging, handling, storage, and transportation.
  • Technical data. This element deals with the identification, planning, resourcing, and implementation of management actions to develop and acquire information to operate and maintain the system. The guidance for this element recognizes that because of DMSMS management and other concerns, the government may need detailed technical data for remanufacturing, reprocurement, or sustaining engineering. The requirement for such technical data should be established during the technology maturation and risk reduction phase of acquisition. Ultimately, any technical data requirement should be clearly expressed in the appropriate contracts as early as possible and flowed down the supply chain.
  • Support equipment. This element deals with the identification, planning, resourcing, and implementation of management actions to acquire and support the equipment required to sustain the operation and maintenance of the system. DMSMS management is identified as a consideration in the sustainment of support equipment.
  • Training and training support.
  • Manpower and personnel.
  • Facilities and infrastructure.
  • Computer resources.

2.4.4. DMSMS Considerations in Logistics Assessments

The implementation of independent LAs during weapon system development, production, and post-IOC acquisition phases was recommended by the DoD Weapon Systems Acquisition Reform Product Support Assessment to improve the effectiveness of product support.[32] An LA is an analysis of a program’s supportability planning, which serves as an effective and valid assessment of the program office’s product support strategy, as well as an assessment of how this strategy leads to successfully operating a system at an affordable cost…. Conducting the LA early in the program phase where the design can be influenced, and reassessing the planning at each milestone and periodically thereafter as the design matures, is critical to fielding a sustainable system.[33]

The LAs focus on the product support strategy and how that strategy leads to successful and affordable system operations. Because DMSMS issues have a bearing on the sustainment of a system, DMSMS should be considered within LAs. Table 2 summarizes the focus of the pre- and post-IOC LAs.

Table 2. Summary of Logistics Assessments

Assessment type

Specific issues of interest from DMSMS perspective

Pre-IOC (at
Milestone B,
Milestone C, and prior to full-rate
production decision)

Monitoring and surveillance for DMSMS issues, using predictive tools and market surveys, are being conducted to identify immediate and near-term obsolescence issues associated with the system BOM. Impact assessment, resolution determination, and resolution implementation are taking place. Technology roadmaps and refreshment strategies are being factored into DMSMS processes. Case management and the capture of metrics are taking place.

Post-IOC (at least every 5 years)

Monitoring and surveillance for DMSMS issues, using predictive tools and market surveys, are being conducted to identify immediate and near-term obsolescence issues associated with the system BOM. Impact assessment (using actual reliability data and inventory dispositions), resolution determination, and resolution implementation are taking place. Technology roadmaps and refreshment strategies are being factored into DMSMS processes and reviewed for potential updates and adjustments. Case management and the capture of metrics are taking place.

Appendix E identifies a number of specific DMSMS management-related questions for use in support of LAs. As was the case for SE technical reviews, the DMSMS management-related questions offered in the appendix have been designed for use by the DMSMS community to inform DMSMS discussion before the LAs and to highlight DMSMS issues to be addressed during the LAs. DMSMS management-related questions are already incorporated into the checklists for assessments; however, an effort has been made to systematically expand upon them.

2.5. Technology and Supply Chain Management

Technology and supply chain management are important elements of the defense acquisition system. A strategic understanding of the supplier base enables an assessment of planned technology development on competitiveness and the viability of essential industrial and technological capabilities. Such an understanding provides a picture of the health of the industrial base and its ability to develop, produce, maintain, and support the system and, thereby, may serve as an early warning of potential DMSMS issues.

From a DMSMS perspective, technology management is one of the most important aspects of supply chain management throughout the life cycle. Beyond the technology maturation and risk reduction phase, this approach is also referred to as modernization through spares, continuous modernization, or technology insertion or refreshment. Effective technology management enables a design AS and life-cycle sustainment strategy that minimizes the cost of resolving future obsolescence issues while incorporating state-of-the-art technologies to increase reliability, lower sustainment requirement costs, and increase warfighting capability to meet evolving requirements throughout an indefinite service life.

Robust DMSMS management by itself will lower the costs associated with obsolescence issues. However, even in the best of programs, DMSMS resolutions are often suboptimal. Life-of-need procurements are problematic because of limited contractual horizons and uncertainties in estimating the total requirement over the remainder of the life cycle. Finding or qualifying alternative items may work for a time, but such approaches rarely take advantage of new technologies and capabilities. Unplanned redesigns are costly. Therefore, incorporating a technology management strategy, influenced by DMSMS health assessments, into design, acquisition, and sustainment activities is a best practice to further reduce DMSMS cost and readiness impacts throughout the life cycle. Potential seamless upgrade paths for technologies and items should provide a timetable for replacing items even if they are not obsolete.

Determining when to upgrade requires the consideration of cost tradeoffs. From a single item perspective, the cost of the upgrade at a specified time can be compared to the cost of the upgrade at a later time plus the cost of mitigating the DMSMS issues until that later upgrade date. Such cost comparisons become increasingly complicated when multiple items are involved. Changes in capability will also affect the decision regarding whether to upgrade at a given point in time.

Effective technology management begins with a strategic understanding of the market and its trends. Market research entails collecting information about existing and emerging technologies, products, manufacturers, and suppliers. It has two components:

  • Market surveillance—a continuous canvassing of the commercial market to identify existing and future technologies, vendors’ products, and market trends that can potentially meet existing and emergent requirements from a strategic perspective. Market surveillance methods include searching the Internet, attending trade shows, reading technology publications, hiring consultants, issuing requests for information from prospective manufacturers and suppliers, visiting manufacturer/supplier facilities, and viewing product demonstrations.
  • Market investigation—a focused process of identifying and determining if specific technology products can meet particular functional requirements. Market investigation also includes system obsolescence profiling to plan for the continued support or replacement of soon-to-be obsolete products. This product-level information and the associated budget requirements form the basis for sustaining the operation or functionality of a system. Market investigation methods can include beta testing; prototyping; testing for compliance, conformance, and compatibility; and querying of manufacturers and suppliers about product obsolescence status.

Market research occurs in all of a system’s life-cycle phases, allowing the acquiring activity to do the following:

  • Anticipate obsolescence situations due to rapid and asynchronous product changes.
  • Plan and budget using a broader range of product obsolescence management options.
  • Maintain insight into technology trends, as well as internal product changes by the manufacturer, and test the effects of those changes on the system.
  • Assess the quality of a manufacturer and the impact on a system of a product’s change, including its suitability for the user, information security characteristics, and supportability.
  • Determine the manufacturer’s support period and inventories for a particular product.

Ignoring market research increases the likelihood of poor product and technology selections, as well as an inability to effectively predict and mitigate obsolescence impacts, leading to out-of-cycle redesigns. This can negatively impact program performance, schedule, and cost.

The combination of the results of market research and an understanding of current and future mission needs enables a program to develop a technology roadmap. Technology roadmaps identify alternative technology paths for meeting performance targets.[34] The DMSMS community of stakeholders is not responsible for developing and maintaining a program’s technology roadmaps. However, technology roadmaps that account for forecasted obsolescence have the potential to reduce DMSMS costs. For this reason, the DMT should inform its program’s technology road-mapping efforts based on the results of monitoring activities.

A program’s technology roadmap provides a basis for managing one or both of the following types of technology-related change:

  • Technology refreshment. Technology refreshment has been characterized by “the periodic replacement of COTS items … to assure continued supportability of that system through an indefinite service life. Technology Refreshes can be strategically applied to prevent the occurrence of DMSMS issues preemptively or to minimize them significantly.”[35] Within DoD, the limitation to apply technology refreshment only to COTS items is not applicable. It can apply to custom electronics as well. The DMSMS community is not responsible for managing the content and schedule for a program’s technology refreshments. These technology refreshments, however, should be informed by DMSMS management’s analysis of product discontinuance notices (PDNs), OEM surveys, the results generated by predictive tool algorithms, and knowledge of typical commercial technology life cycles. These data at the item level can be integrated to examine higher-level assemblies in what is often referred to as a health assessment (or “tombstone chart”). Given this understanding of when and what within the system will be affected by obsolescence, the DMT can recommend DMSMS resolutions—life-of-need procurement to provide the inventory necessary to support demand for that item, substitutes or other sources of supply, changing repair processes, and so forth—to extend the technology refreshment point. The optimal technology refreshment date will be that point in time when the sum of the cost of individual resolutions is greater than the cost to redesign.
  • Technology insertion. Technology insertion integrates mature technologies with requirements and logistics planning in order to expand system capability as well as increase readiness, reduce life-cycle costs, and reduce the logistics footprint. A program can avoid significant costs by determining optimum technology insertion dates. For example, a redesign to upgrade a product should simultaneously seek to eliminate obsolete or near obsolete parts (as identified via a health assessment), because it is more cost-effective to resolve a DMSMS issue simultaneously, rather than as a standalone, out-of-cycle redesign.

A program’s technology roadmaps also contribute to DMSMS management. They can improve predictions of the EOL and provide information that influences how resolutions are implemented.

Effective technology management implies that resolutions are planned before the effects of obsolescence or other technology-related change occur. This is perhaps the most robust form of DMSMS management.

3. Prepare: DMSMS Management Program Infrastructure

This section describes the Prepare step of the DMSMS management program. It encompasses establishing the strategic underpinnings for robust DMSMS management, developing a DMP, forming a properly trained DMT to carry out all DMSMS activities, and establishing DMSMS operational processes—securing operational funding, case management, program evaluation, and QA. As the first step, Prepare lays the groundwork for the other four DMSMS management process steps.

3.1. Establish the Strategic Underpinnings for DMSMS Management

The PM should establish the strategic underpinnings for DMSMS management of the program. These strategic underpinnings set the priorities for the DMSMS management approach to be pursued by the program’s DMT and documented in its DMP.

Program leadership may be tempted to delegate the establishment of the strategic direction to the DMT. However, doing so could result in a program whose scope of effort documented in the DMP does not match the funding obtained and available to support DMSMS management or program management’s expectations. Therefore, program leadership should engage early (before the DMP is finalized) to define the objectives for DMSMS management, the roles and responsibilities of DMT members, and DMT operating guidelines.

To establish the specific DMSMS management objectives for its program, program leadership should refine and elaborate upon the three overarching objectives identified in Section 1.3. For example, a PM might establish objectives such as the following: (1) exclude the introduction of obsolete or soon-to-be obsolete items from the system design, (2) eliminate or minimize the scope of DMSMS-related out-of-cycle redesigns throughout the life cycle, (3) eliminate DMSMS-related production schedule impacts while in design or production, and (4) eliminate DMSMS-related degradations to readiness during sustainment.

Program leadership should also provide expectations regarding the procedures for and frequency of DMT meetings. The procedures and frequency of DMT meetings will be a function of the number and criticality of DMSMS issues encountered and the maturity of DMSMS management for the program (e.g., a new program with a new DMT may require more frequent meetings than are required for a program with a more established DMT).

Program leadership should also define the role of and relative relationships among DMT members (including getting the right DMSMS management-related requirements on contract to support these roles and responsibilities and effective DMSMS management overall), both inside and outside the context of DMT meetings, and the program’s processes for monitoring DMSMS issues, creating DMSMS cases, assessing their impact, analyzing what to do about them, and obtaining program decisions regarding resolutions. These roles and responsibilities not only clarify what is expected of individual DMT members, but also how each individual’s performance will be rated from a program leadership perspective. Section 3.3 contains more detailed information regarding the composition and duties of the DMT.

Program leadership should establish risk-based operating guidelines. For many programs, operating guidelines will consist of similar, relatively generic statements such as the following:

  • Maintain case management data on all DMSMS issues.
  • Monitor items and assemblies to identify obsolescence issues.
  • Assess the impact of obsolescence issues.
  • Analyze ways to resolve the obsolescence issues cost-effectively.
  • Oversee the implementation of the resolutions.
  • These generic operating guidelines should be refined by program leadership to account for risk. To do so, program leadership should address the following questions:
  • Which subsystems should have priority for monitoring? Prioritization should be based on such considerations as mission criticality, safety, or known problem areas.
  • What items within those subsystems should be monitored? The answer to this question is a function of the risks that program management is willing to accept. These risks are manifested when a strategic determination is made of which items to proactively monitor (and by default, which items should be managed reactively) for a system or subsystem of interest.
  • There are, in fact, three separate strategic determinations to be made:
    • The first two determinations apply to those items that are found on a system’s bill of materials. Examples of such items listed on a BOM could include anything from microprocessors and application-specific integrated circuits to diesel engines and pumps to adhesives and insulating materials.
      • Determination 1. Determine the heuristic algorithms based on item life cycles to use in order to identify the items to definitely monitor and those not to monitor.
      • Determination 2. Determine whether further analysis will be performed on uncategorized items, those items for which the heuristics did not provide a definitive answer with regard to whether to monitor or not monitor.
    • The third determination applies to critical materials (e.g., hazardous, exotic, and supply-constrained materials) that appear in lower tiers of the items listed on BOMs.
      • Determination 3. Determine whether to investigate how critical materials in the supply chain may alter the status of items being proactively monitored. Knowing whether there are critical materials present in or used in the manufacturing process of an item on a BOM will improve the analysis of availability of that item.
  • The approach for the analysis behind these determinations is described in Chapter 4 as part of the Identify step of robust DMSMS management. DMSMS subject matter experts can provide advice to program management concerning these determinations. They can suggest the best heuristics, based on item life cycles, to use. They can explain and carry out the analysis needed to clarify what to monitor where the need for proactive monitoring is not determined by applying the selected heuristics. They can describe a low-cost method of finding information about critical materials in the supply chain. Ultimately, program management must decide whether resources should be applied to DMSMS management to reduce risk to an acceptable level.
  • When should DMSMS management begin? As a best practice, proactive DMSMS management should begin early in the life cycle, preferably at the time of a preliminary design review. Pursuing proactive DMSMS management for electronic items early is important, because there have been numerous examples of obsolete electronic items being incorporated into designs, virtually assuring sustainment issues if they are not discovered. Because the market forces driving DMSMS issues for MaSME items operate much more slowly than the competitive commercial electronics market, one might question whether to begin DMSMS management for these items later in the life cycle. It remains a best practice, however, to begin proactive DMSMS management for MaSME items at the same time as electronic items, for several reasons. First, the earlier that monitoring begins, the larger the window of opportunity to address an issue, the larger the selection of less expensive resolutions, and the smaller the likelihood of experiencing schedule and readiness impacts. Second, since a program will only be monitoring high-risk MaSME items, proactive monitoring of such items should begin early. Third, MaSME item monitoring can be integrated with electronic item monitoring. Finally, beginning to monitor early will enable designs containing high-risk MaSME items to be revised before it is much more costly to do so later.
  • How important is DMSMS management for software? If a system is heavily dependent on COTS software, the management of software obsolescence should be assigned a relatively high priority. Software obsolescence management for older systems primarily using custom software for mission-critical applications and COTS software only for user interfaces should be assigned a lower priority as long as no changes are anticipated. If changes are anticipated, the priority assigned to software obsolescence management is dependent on access to the critical human skills needed.
  • A risk-based perspective to monitoring is important because robust, proactive DMSMS management everywhere is not cost-effective and will be unnecessarily time-consuming. A risk-based approach takes into consideration the differing sizes (and associated number of parts) of the systems and thus the workload required for monitoring DMSMS. At one end of the spectrum, everything could be proactively monitored to predict obsolescence before the item is no longer available. However, for many items, the impact of obsolescence is small because alternatives are readily available. A risk-based approach to DMSMS management strikes a balance among high-risk items that should always be proactively monitored, items that are broadly available over a long period of time, and everything in between. Additional information regarding levels of risk-based prioritization can be found in Sections 4.1 and 4.3.2.
  • With regard to DMT deliverables, program leadership should identify those artifacts and data necessary to manage DMSMS activities for the program. Examples of useful deliverables are the documentation of all DMSMS cases in the program’s case management system, the capture of metrics associated with DMT operations and results, and the periodic assessment of the health of the system.
  • Because it may not participate in the day-to-day activities of DMSMS management, program leadership should establish ground rules regarding when it and other key stakeholders should be briefed and the PM’s role in decision making. At a minimum, the timing of briefings to program leadership should correspond to the timing of the completion of DMT meetings and major DMT deliverables. It should be established whether the PM maintains decision authority for all resolutions or just certain classes of resolutions. In support of this decision authority role, the PM must commit to being accessible to the DMT in order to prevent delays and assist in removing barriers to decisions.

3.2. Develop a DMSMS Management Plan

3.2.1. Planning Considerations

A program cannot have effective DMSMS management without an adequate plan. The DMP is the key planning document that describes how the regulatory requirement for DMSMS management will be implemented within the LCSP for the program. Formulation of the DMP should begin early in the life cycle—preferably, immediately after Milestone A—because the DMP provides a robust DMSMS management framework for a program.

The DMP describes the tailored DMSMS management processes to be pursued by a program. Tailoring of DMSMS management processes will be a function of the extensiveness of a program’s infrastructure, resources, priorities, and constraints (e.g., the number of people, the amount of funding, access to BOMs/parts lists, and the ability to survey) and the strategic underpinnings for DMSMS management established by the program leadership.

While the PM establishes the strategic underpinnings for DMSMS management for his or her program and is ultimately responsible for final approval of the DMP, the DMT develops the DMP. When developing the DMP, the DMT should address several interrelated questions whose answers affect the near-term objectives of the DMP and the DMT. The questions are as follows:

  • What is the AS and what life-cycle phase should be emphasized for the planning effort? As the system moves through the life cycle, the DMT’s focus may shift from providing government oversight of contractor DMSMS processes and delivery of management products to the government for acceptance, to conducting organic DMSMS assessments and sustainment planning. In the technology maturation and risk reduction phase and the engineering and manufacturing development phase, for example, the government should ensure that the contractor is minimizing obsolescence throughout the contract period of performance by selecting products that avoid or resolve hardware, material, and software obsolescence issues. During the production and deployment phase, the government should ensure that the contractor is able to meet production requirements as well as ensure that the government will be able to sustain the product over the long term. During the O&S phase, the government may want contractor support for DMSMS management and ensure that the system can be sustained until the next upgrade or replacement system.
  • What is the long-term sustainment strategy of the program? The answer to this question affects the DMP objectives as well as the composition of the DMT and the availability of technical data. The party ultimately responsible for long-term sustainment must participate in the DMT to ensure that the appropriate groundwork is laid to meet the long-term objectives of the DMP. No assumptions should be made regarding long-term sustainment responsibilities. For example, if the DMP assumes that a contractor will provide sustainment support for the life of the system, and a later decision is made to use an organic depot, the government may not have the appropriate DMSMS data to meet the system sustainment requirements. In such a situation, the DMP must include exit strategies established by contract exit clauses to ensure both a smooth transition of responsibilities and the availability of technical data throughout the program’s life cycle, not just until the end of the contract. Furthermore, government and industry often have different perspectives on long-term sustainment. The contractor usually focuses on the end of its contract.
  • What is the program’s approach to maintaining a life-cycle perspective on DMSMS? For many programs, a prime contractor will have responsibility for performing day-to-day DMSMS management. Since the prime contractor’s work is based on contracts of limited time duration, their period of responsibility corresponds only to the period of performance for the contract. The DMT needs to develop a provision through its DMP (reinforced via contracts, as necessary) that enables the government to manage DMSMS issues and their resolution across breaks in contracts (e.g., between production contracts, between a production contract and a sustainment contract, and between sustainment contracts). The ability to manage across contracts will require the ability to estimate the true life of need (e.g., when the system retires and when the next technology insertion is scheduled). The ability to procure and maintain the stocks of an item or assembly to satisfy through the life of need is crucial. This could require the inclusion, in contract language, of a requirement for true life-of-need (not life-of-contract) buys or provisions for handling life-of-need stocks as government-furnished material.
  • Who are the stakeholders for the robust management of DMSMS issues for the program (including other DMSMS management programs that interact with the DMSMS management program for the system in question)? The answer to this question determines the composition of the DMT, as well as its members’ roles and responsibilities, and takes into account the contracts in place or expected to be in place. The DMT should keep in mind that roles and responsibilities of various stakeholders—for example, government organizations, OEMs, and independent subject matter experts (SMEs)—and oversight relationships can evolve and change depending upon the phase of the life cycle. The answer also affects the communication flows needed to implement the DMSMS management processes that the DMT develops. One important flow for communication that should be documented in the DMP is the process for how DMT action items (i.e., assigned responsibilities and suspense dates) will be documented and monitored. In addition, the DMT will determine a desired frequency for monitoring and surveillance activities. Finally, the answer helps define the management products that the DMT delivers to its members as a function of the data needed to effectively carry out their roles and responsibilities.
  • What are the near-term and long-term DMP objectives? At the most basic level, the DMP’s objective is to reduce DMSMS cost, schedule, readiness, and availability risks to an acceptable level. The specific definition of “acceptable” is a function of the size, complexity, and cost of the system, as well as the current life-cycle stage, the AS, the LCSP, and the technology refreshment or technology insertion strategy. The near-term objectives, however, will drive the composition of the DMT, the roles and responsibilities of the DMT members, the processes and communication flows that the DMT needs to define and develop the necessary data inputs into those processes, and the management products that will be outputs of those processes.
  • What DMSMS management activities are being performed by the prime contractor? The DMT should not try to duplicate prime contractor activities; the DMP should be aligned with what the contractor is doing based on its own internal DMP. If the prime contractor is effectively managing DMSMS risk and similar requirements are being flowed down the supply chain, the DMT’s role should be focused on oversight. The DMT should not make assumptions about what the prime contractor is or is not doing. The facts can be obtained only from a careful examination of contract language and actual contractor processes. Regardless of the relative roles of the government and the prime contractor in DMSMS management, the government is ultimately the responsible party.
  • What types of processes should be developed and what products are needed to successfully manage DMSMS issues? Although many general DMSMS management processes and products are transferrable from program to program at a high level, the DMT must ensure that processes and products are tailored to meet the program’s specific needs at the working level. The DMP should consider the unique needs of the program, the unique needs of each stakeholder, and the unique flow of communication required among the stakeholders to ensure that the process enables fulfillment of the DMP objectives. In addition, the DMP must consider the data sources necessary to implement the DMSMS management processes and produce the DMSMS management products.
  • Where should the program be reactive and where should the program be proactive? Nearly everything will become obsolete or unavailable over time. However, not all situations need to be handled proactively. In some circumstances, the risk of impact is low if a program waits until an item cannot be purchased before dealing with the situation. For example, there may be commercially available alternatives to certain parts categories, such as electrical and mechanical COTS assemblies and standard industrial parts. Active monitoring may be more important for custom electronic and COTS assemblies.[36] While proactive monitoring may not be necessary for one-time manufactured items, the program should be properly prepared (i.e., with technical data) to reproduce those items if required.
  • What resources are available to fund DMT operations? Initial planning should not be resource constrained but rather should seek to address the strategic underpinnings for DMSMS management laid down by the program leadership. However, those initial DMP objectives, DMSMS management processes and products, and, to some extent, the DMT composition itself may need to be constrained if the program’s leadership cannot obtain sufficient funding to support the realization of that initial plan. In such an instance, program leadership should explicitly acknowledge that it is accepting greater risk and appropriately revise the initial set of strategic underpinnings for DMSMS management, prior to the final approval of the DMP.

The DMT is the program entity that has management authority to put the approved DMT into action. Programs sometimes use DMSMS intensity levels to identify the current state of their DMSMS management practices and to determine a desired future state for those practices. A higher intensity level indicates a more robust approach to DMSMS management, which implies that a high-performing DMT is actively engaged in doing the following:

  • Monitoring critical items in the system using predictive DMSMS management systems, vendor surveys, and other research techniques
  • Overseeing contractor DMSMS management efforts in a comprehensive way
  • Assessing readiness, availability, cost, and schedule risks to the program, because of item or materials obsolescence
  • Conducting analyses to determine the most cost-effective resolution, including actions at higher levels of assembly
  • Overseeing implementation of resolutions to ensure that all stakeholders carry out their assigned roles and responsibilities.

A robust DMSMS management approach does not imply being proactive everywhere. Program leadership should weigh in on its expectations regarding the scope of proactive DMSMS management. Proactive DMSMS management means being proactive when it is important, for example, when

  • the readiness or availability impact of a shortage is acute,
  • resolution implementation takes a long period of time,
  • the cost of delaying resolution is potentially high, or
  • a production schedule is likely to be affected.

In some situations (especially for common mechanical items), a reactive DMSMS management approach is robust, because many alternatives can be used. Although a robust DMP will be more expensive to implement, the resulting cost savings and cost avoidance by being proactive throughout the life cycle will be greater and DMSMS impacts on readiness, availability, and schedule will be lower.

Appendix J contains information to help guide a decision on the appropriate target DMSMS intensity level for a program. The DMP should then be designed to achieve that target.

Finally, DMPs are not static; they should be living plans. DMSMS management contracts change. The tools and processes employed change. Even more minor changes—such as modifying the roles and responsibilities of DMT members, a life-cycle extension, changes in procurement plans, or significant changes in operating tempo—will occur. All changes may drive revisions to the DMP.

3.2.2. Outline of DMP Contents

The DMP should be signed and approved by senior program leaders to demonstrate their agreement and support for the actions prescribed in the plan. This is especially important when competing for resources.

The outline and format for the DMP are not prescribed. However, the DMP should not be a tutorial on DMSMS management. Instead, it should include only what the program intends to accomplish. As a best practice, the DMP should include the following:

  • Introductory context considerations
    • Relevant system-specific information
    • Program milestones
    • Near-term DMSMS program objectives
    • Long-term DMSMS program objectives
    • Scope of DMSMS management effort
  • Management considerations
    • DMSMS management approach (including prioritization approaches)
    • DMSMS management tools, databases, and systems
    • DMSMS contractual language, including requirements flow-down to subcontractors
    • Contract exit strategies
    • DMSMS budgeting and funding
    • Relevant stakeholders
    • DMT structure and membership
    • Roles and responsibilities of the DMT and each member of the DMT
    • DMSMS training
  • Process considerations
    • Design techniques for mitigating DMSMS impacts
    • Access to up-to-date item information suitable for DMSMS management
    • System architecture/CM
    • DMSMS case management process
    • Synchronization with funded technology refreshment plans and product roadmaps
    • References to lead-free and counterfeit parts control plans
    • Quality assurance
    • DMSMS mitigation strategy
    • Metrics collection and analysis
    • DMSMS management products.

The Department of the Army’s multi-service expert system—Systems Planning and Requirements Software, or SYSPARS—is available to assist PMs and PSMs with the preparation of product support, supportability planning, and other acquisition and program management documentation, including the DMP.[37]

3.3. Form a DMSMS Management Team

The PM or PSM should charter the DMT and clearly identify and authorize its activities as well as the roles and responsibilities of its members inside and outside the context of the DMT. The DMT should represent both internal and external organizations that provide routine and recurring support to the DMSMS management program. In some cases, it may be appropriate for representatives of other system DMTs to participate if their DMPs and processes interact. In other cases, multiple layers of DMTs may exist (e.g., at the program level and for some subsystems); in these instances, subsystem level DMTs should participate in and leverage the program office DMT, as appropriate.

3.3.1. Roles and Responsibilities of DMT Members

The roles and responsibilities of the program office, the prime contractor, the OEMs, and independent SMEs are among those established by program leadership in the DMSMS management strategic underpinnings. The DMP further expands upon the roles and responsibilities of the DMT as well as its composition in overseeing and managing obsolescence, including software, to the extent that it is a strategic priority. For example, the DMP may include information on technology refreshment plans. Such plans may also include software upgrades. Also, they may include requirements for hardware and software vendor surveys or for tracking the extent to which the software satisfies information assurance requirements. Finally, appropriate contract language should be developed to carry out the prime contractor and/or OEM responsibilities.

The roles and responsibilities of the DMT are similar for every program, but the level of effort required of the team will depend on the complexity of the program and the severity of the DMSMS issues. In general, the activities of the DMT are to gather the necessary data, develop and implement the DMSMS management processes that require those data, produce the management products that result, report metrics that measure the effectiveness of the DMSMS management program when compared to the defined objectives, and apply continuous improvement processes to DMT operations. The roles should be tailored to meet specific program needs.

The composition of the team will depend on the complexity of the program as well as on other considerations. For example, some program team members may have multiple duties, which may affect the amount of time they can devote to DMT activities, or they may be assigned multiple roles on the DMT. As another example, if the responsibility for the system will be transferred to another agency or activity midway through the life cycle, the stakeholder who will ultimately bear responsibility for sustainment should participate in the DMT during all phases of the life cycle. The DMT composition may evolve over time. Early in the life cycle, before the Critical Design Review (CDR), a partial team may be sufficient.

Ideally, a DMT should consist of the following roles:

  • DMT lead. The DMT lead is the spokesperson for the DMT and oversees and has the authority to control DMSMS management operations. The DMT lead is also the champion of DMSMS for the program and, as a best practice, should be a full-time position; both conditions signal the importance placed upon DMSMS management by program leadership. The DMT lead is responsible for coordinating DMT meetings and managing corresponding action items, identifying potential sources of funding and funding availability, requesting funding and other resources to support the program, overseeing the DMSMS management support contracts and agreements, interfacing with the configuration control board (CCB), and reporting on DMSMS risks at technical, logistics, and programmatic reviews. This role should be filled from logistics, engineering, or program management organizations by an individual who possesses sufficient knowledge of DMSMS issues to be able to communicate to decision makers on the importance of actions regarding DMSMS cases. This role may sometimes be filled by the DMSMS SME.
  • Program office representative. The program office representative represents the views of the PM on the DMT. Normally, this person would be the DMT lead and champion of DMSMS for the program.
  • DMSMS SME. The SME coordinates the execution of DMT management processes and the development of DMT management products. This includes, for example, assessing obsolescence forecasts, processing BCAs, preparing budget forecasts, and presenting solution options to the DMT for discussion and concurrence. In addition, the SME assists with establishing the DMT and with developing and maintaining the program’s DMP as a living document. Furthermore, the SME monitors the effectiveness of the DMSMS management program and recommends ways to continually improve it by capturing and assessing metrics that accurately measure the success or failure of meeting the defined DMSMS management program objectives.
  • Engineering activity representative. The DMT member representing the engineering function (including industrial, mechanical, electrical, and general engineering expertise, as well as a systems integrator perspective) is responsible for managing the incorporation of DMSMS-related technical data into government drawings, technical publications, and documentation. The engineering activity representative provides information to the DMT regarding resource requirements, systems integration engineering, and reliability and maintainability analyses on items selected for use on the system. The engineering activity representative also assesses the suitability and feasibility of proposed technical solutions. Early in the life cycle, the engineering activity representative may also include the prime contractor representative, if that is the source of greatest expertise. The engineering activity representative should also be the DMT’s interface to the technology road-mapping community.
  • Software SME. The DMT should include a software SME, but all DMT members should possess a certain set of software obsolescence competencies. Even for those programs that do not place a high priority on software obsolescence, software expertise is valuable because hardware resolutions have the potential to affect software. Robust DMSMS management requires effective communication among all stakeholders. They must be made aware of hardware and software interdependencies and the potential impact of alternative resolutions, including the status quo. Having software expertise on the DMT facilitates the communications necessary to ensure that all resolutions are properly implemented.
  • Supply support activity representative. The supply support activity representative is an ad-hoc team member who provides his or her organization’s viewpoint on DMSMS issues. The team may have several supply support activity representatives, for example, item managers from DLA. DLA involvement, in particular, can augment a DMT’s efforts with research on DLA-managed items, additional but limited DMSMS management expertise and product knowledge, and a cross-system perspective that can highlight impending, otherwise unforeseen problems and potential resolutions.
  • Value engineering (VE) SME. A VE representative is an ad-hoc team member who can offer advice regarding the best-value resolutions to pursue to address DMSMS issues, as well as how those resolutions are synchronized with program roadmaps to integrate new technologies and current and future mission requirements.
  • Contracting office representative. The DMT member representing the contracting office is an ad-hoc team member who provides guidance and administrative requirements for support contracts and agreements. This person also helps the DMT ensure that there is no ambiguity in the contractor’s DMSMS management requirements.
  • Prime/subcontractor representative. Depending upon the terms of the contract, the prime/subcontractor representative ensures that the OEM fulfills its roles and responsibilities with respect to DMSMS management as outlined in the contract. In addition, the prime contractor representative may serve as the DMSMS management lead for subcontractors and present DMSMS issues and risks to the DMT.
  • FMS representative. The FMS representative helps optimize DMSMS resolutions by providing information that enables all users to be considered. Mitigating DMSMS issues in a program should account for both U.S.-owned and foreign-owned platforms (obtained through FMS or direct commercial sales), because all of these assets create demands that affect item availability. In addition, cost-related benefits that exist for one user may be able to be leveraged in the resolutions being developed by another user. Although U.S. and foreign DMSMS management processes are similar, there are additional considerations in an international situation (technology security, information assurance, International Traffic in Arms Regulations, etc.). The DMSMS SME must interface with the FMS representative and the appropriate international point of contact before taking any actions.

Below are examples of other roles that the DMT could include, depending on the program’s DMSMS management infrastructure and objectives:

  • Budget office representative
  • Maintenance repair activity representative
  • Software license management group representative[38]
  • Environmental and materials engineering representative
  • CCB representative.

Some roles may be combined, while some of the responsibilities may be deleted or new ones added over time. The most effective DMT organization allows for open communication among the team members, whether they are representing the government, the prime contractor, or subcontractors. Such open communication is critical for robust DMSMS management.

Ultimately, the PM is responsible for DMSMS management for the program. An Accountable/Responsible/Consulted/Informed (ARCI) chart is a good way to depict the relative roles and responsibilities required of each DMT member in order to implement DMSMS management in line with the program leadership’s established strategic underpinnings for DMSMS management. Different types of responsibility are defined as follows:

  • Accountable (A). Identifies the individual who is ultimately accountable for the completion of the activity and who has the ability to say “Yes” or “No.” There may be one and only one “A” for a decision or activity at each organizational level.
  • Responsible (R). Identifies the individual or individuals who are responsible at each level of the organization to execute a specific assignment for an activity. The degree of responsibility is determined by the person accountable. There can be multiple “R”s for one activity at each organizational level.
  • Consulted (C). Identifies the individual who must be consulted before a decision or activity is finalized. This represents two-way communication. There can be multiple “C”s for one activity at each organizational level.
  • Informed (I). Identifies the individual who must be notified about the completion or output of the decision or activity. This represents one-way communication. There can be multiple “I”s for one activity at each organizational level.
  • Not Informed (N). Identifies individuals who do not need to be notified about the completion or output of the decision or activity. There can be multiple “N”s for one activity at each organizational level.

Table 3 is a notional example (rows and columns are not complete, and entries are hypothetical) of such an ARCI chart, which shows the types of responsibility required relative to a set of roles and DMSMS management activities.

Table 3. Notional ARCI Chart

Role

Activity

DMT lead

Program office representative

DMSMS SME

Engineering
activity
representative

CCB
representative

Supply support representative

Contracting
office
representative

Prime contractor representative

Meeting coordination

A

I

C

I

I

I

I

I

Funding requirements

R

A

C

C

N

N

I

C

Future budget projections

R

A

C

C

N

N

C

C

DMSMS monitoring

A

I

R

I

N

I

N

C

DMSMS solution implementation

C

A

C

R, C

R

C, I

I

R, C

Contracting

C

R

I

I

N

I

A

C

Supply support

I

I

C

C

I

A, R

I

C, I

Responsibilities may change significantly, depending on how the prime contractor is being used to support DMSMS activities (see Appendix C). In many instances, the prime contractor is responsible for most of these activities.

As a best practice, program leadership should strive to use its personnel as efficiently as possible to implement DMSMS management. For example, in-house engineering personnel should not be diverted to perform routine, day-to-day DMSMS management activities. Individuals with more specialized expertise and experience are located within the prime contractor or the OEM, as well as independent SMEs. These existing resources and resident expertise should be leveraged by programs to the greatest extent possible. The prime contractor has the most in-depth knowledge of the system and, therefore, should also be involved throughout the system life cycle.

It is likewise a best practice for a program to employ independent SMEs, even if the prime contractor is already intimately involved in DMSMS management for the program. Independent SMEs can (1) assist the government with overseeing the prime contractor, particularly in terms of ensuring consideration of a life-cycle perspective; (2) give an independent perspective on issues and resolutions; (3) provide access to specialized tools, processes, data, and unique supplier relationships that may not be available to the prime contractor; (4) advise a program on formulating contract language, securing BOMs, developing a statement of work (SOW) for DMSMS activities for a prime contractor, and other responsive, tailored support to specific needs; (5) serve as a central linkage to DMSMS activities and best practices in other programs; and (6) provide a conduit to improved access to supplier data in a competitive situation. Independent SMEs may also prove helpful during sustainment, if the government is entirely responsible for sustainment support and the prime contractor has little or no role.

Although each DMT should have a DMSMS SME, it is not always necessary to find that expertise within the program. Centralized DMSMS SME teams reside within various organizations across DoD. These teams have in-house DMSMS management expertise and well-established processes that any program can easily leverage to implement a DMSMS program. In addition to having an established knowledge base and documented processes that enable robust DMSMS management, some of these teams own DMSMS management systems that experienced DMSMS practitioners use to integrate, analyze, and report on DMSMS-related data collected using predictive tools, vendor surveys, and PDNs received directly from manufacturers. The DKSP has a list of centralized DMSMS SME teams.

3.3.2. DMT Training Needs

All members of the DMT should be trained on their role in supporting DMSMS management for the program. Not all members of the DMT are expected to be DMSMS SMEs or reach a targeted competency level; however, the DMT lead should identify minimum training requirements for DMT members on the basis of the DMSMS management approach, available resources, and the roles and responsibilities of each DMT member.[39]

The recommended minimum DAU DMSMS-specific courses are as follows:

  • CLL 200, DMSMS: What Program Management Needs to Do and Why (forthcoming)[40]
  • CLL 201, DMSMS Fundamentals
  • CLL 202, DMSMS Fundamentals: Executive Summary (forthcoming)
  • CLL 203, DLA DMSMS Essentials
  • CLL 204, DMSMS Case Studies
  • CLL 205, DMSMS for the Technical Professional.

Table 4 outlines training recommended for the different DMT roles. The DMT lead may use this as a guide but tailor it as necessary to meet the specific needs and constraints of the program. The important thing is that DMT members have the appropriate knowledge and skill base to carry out their responsibilities effectively.

Table 4. Recommended DMT Training

Role

CL 200

CLL 201

CLL 202

CLL 203

CLL 204

CLL 205

DMT lead

X

X

X

X

X

X

Program office representative

X

X

X

X

X

DMSMS SME

X

X

X

X

X

X

Engineering activity representative

X

X

X

X

Software SME

X

X

X

Supply support activity representative

X

X

X

X

VE SME

X

X

X

X

Contracting officer representative

X

X

X

Prime/subcontractor representative

X

X

X

X

X

FMS representative

X

X

Budget office representative

X

X

Maintenance repair activity representative

X

X

Software license management group
representative

X

X

CCB representative

X

X

X

DMSMS SMEs should have a majority of the following knowledge, skills, and abilities:

  • Knowledge
    • Background in logistics management and SE, as well as a thorough understanding of DoD policies and procedures as applied to DMSMS management, design interface, maintenance planning, and the acquisition and sustainment of a system
    • Technical understanding of all logistics elements and SE principles and their impacts upon each other
    • Mastery of DMSMS management concepts and policies sufficient to provide guidance and direction to logistics and engineering personnel on issues related to or affected by DMSMS issues and concerns
    • In-depth knowledge of developing DMSMS management requirements and projecting funding requirements for an effective DMT
    • In-depth knowledge of a DMSMS case-tracking system and DMSMS metrics
    • Knowledge of the BCA process in the DMSMS decision process
    • Knowledge of military and contractor supply chains, especially for commodities of focus
    • Knowledge of the concepts, theories, and principles of system design, operations, and support
    • Functional knowledge of the relationship between design interface, maintenance planning, engineering design, and DMSMS considerations necessary to create and establish innovative and effective program policies and procedures for systems as required by DoD activities and authorized FMS organizations
    • Functional knowledge of DMSMS management for the development of agency policy, procedures, and processes for mitigating DMSMS issues
  • Skills
    • Skilled in interacting with senior government and industry executives, as well as with other logisticians, engineers, and PMs, both individually and in groups
    • Skilled in resolving conflict and negotiating solutions to complex technical issues
    • Skilled in developing and evolving collaboration among commands and agencies to maximize the attainment of efficiencies to determine best practices and leverage existing processes
    • Skilled in communicating with others to interpret contractual requirements for performance-based logistics (PBL) for DMSMS management support packages
    • Skilled in communicating with others about the prevention of obsolescence of critical items
    • Skilled in communicating clearly and concisely, both orally and in writing
    • Skilled in perceiving relationships and effects between the subject under discussion and related areas of importance and bringing those relationships to the attention of all concerned
  • Abilities
    • Ability to provide recommendations to program offices and field support teams to assist with planning and developing the DMP, statements of work, contract language, and LAs
    • Ability to provide focused management and coordination across multiple stakeholders in support of DMSMS management
    • Ability to chair and facilitate a DMT by developing annual goals and agendas and to direct the personnel and programs to meet the established goals
    • Ability to identify, prioritize, and recommend solutions to the barriers that prevent a PM from establishing a robust DMSMS management program
    • Ability to apply advanced concepts and theories to DMSMS issues and tasks so they may be resolved effectively and efficiently
    • Ability to develop and establish DMSMS management processes and guidelines for all personnel to follow.

Appendix B contains a comprehensive outline of DMSMS competency levels. The six DMSMS-specific courses identified at the beginning of this section as recommended minimum requirements for DMT members are also required courses, corresponding with the achievement of a DMSMS entry-level competency. Because the DMSMS competency does not exist in a vacuum and must be obtained in conjunction with DAU Defense Acquisition Workforce Improvement Act (DAWIA) certifications, additional courses are required to obtain the entry-level, technician-level, and leadership-level competencies and experience associated with the roles and responsibilities of DMSMS practitioners.

3.4. Establish DMSMS Operational Processes

A process is any activity or set of activities that uses resources to transform inputs into outputs. Processes have objectives, inputs, outputs, activities, constraints, and resources. Three foundational DMSMS processes have already been discussed in this section: (1) establish the strategic underpinnings for DMSMS management, (2) develop the DMP, and (3) form the DMT. As the DMT develops the DMSMS operational processes, the team must define the basic jobs needed to support the program office or other customers. The team must then define and understand the inputs, outputs, activities, resources, constraints, and schedule. In fact, once the operational processes have been developed, key DMSMS management events should be included in not only the DMP, but also the program’s integrated master plan (IMP) and integrated master schedule (IMS).

Tools are involved throughout all DMSMS operations. The DMT should employ tools to collect, aggregate, store, and report data, as needed, to produce DMSMS management products. The DMT should use research tools, predictive tools, logistics tools, BOM analysis tools, BOM manager tools, and CM tools. The DMT will need to determine the appropriate tool mix for enabling the intended DMSMS management approach.[41] Some of these tools are mentioned later in this section as part of the case management process. A more extensive discussion of tools can be found in Section 4.

It is not necessary for the program to develop or purchase its own tools. Existing DMSMS management systems support many of the defined elements of DMSMS operations. These systems integrate DMSMS best practices, processes, an in-house knowledge base, and many of the aforementioned tool types into a single management system that enables robust DMSMS management. These systems include management databases that trained DMSMS practitioners use to integrate, analyze, forecast, and report on data collected from predictive tools, logistics tools, vendor surveys, PDNs received from manufacturers, and an in-house knowledge base. In addition, these DMSMS management systems facilitate high-level processes for surveying vendors, processing alert notifications, analyzing BOMs, analyzing data, researching items, forecasting, budgeting, reporting, managing DMSMS cases, and ensuring quality. These processes are, for the most part, transferrable. Programs can leverage these DMSMS management systems and their associated service offerings to implement a new DMSMS management program. The DKSP contains a complete list of DMSMS tools, management systems, and resources.

DMSMS management processes can be categorized in many ways. Figure 8 shows the scheme used in this document. The DMT establishes and carries out all of the operational processes shown in the figure, but each process is associated primarily with one of the major DMSMS management process steps.

Figure 8. DMSMS Management Processes DMSMS Management Processes

The following subsections describe only those operational processes associated with the “Prepare: DMSMS management program infrastructure” step of the DMSMS management process, while the remaining operational processes are addressed in the remaining four sections of the main body of this document.

3.4.1. Secure Resources for DMT Operations

  • Operations funding is the funding required to support the day-to-day functioning of DMSMS management for a program, separate from the funding that may be required for specific resolutions for identified DMSMS issues. Operations funding should take into account what will be paid to the OEM, as negotiated via contract, to perform DMSMS management. In addition, operations funding should consider what is necessary to support (1) DMT meeting attendance and logistics and (2) the government’s role in the oversight of or active involvement in monitoring and surveillance, assessment, and analysis of DMSMS resolutions, as well as developing, reviewing, and approving resolutions to DMSMS issues. The program leadership and DMT, particularly for a system heavily dependent on COTS software, should also consider the importance of monitoring software obsolescence in determining the amount of funding needed for DMSMS operations. Finally, internal program office resources should be allocated to DMSMS management. Beyond a minimum level of internal support needed, tradeoffs between in-house people and external funding can be made.

The budget and funding for DMSMS management processes generally consist of three elements:[42]

Support for DMSMS planning and management. This element includes the following tasks:

    • Attending meetings, including travel and other logistics, as needed
    • Developing the DMP
    • Agreeing upon, creating, documenting, implementing, and executing processes
    • Agreeing upon the required management products, articulating the required formats, and producing the products
    • Defining and reviewing metrics
    • Ensuring quality.

Data management, research, and forecasting. This element includes the following tasks:

    • Obtaining parts lists/BOMs
    • Obtaining DMSMS analysis tools and management systems
    • Formatting, ensuring the quality of, and loading parts lists/BOMs
    • Analyzing BOMs
    • Researching items
    • Surveying vendors
    • Processing PDNs
    • Monitoring processes
    • Managing data.

Data analysis and reporting. The following are illustrative activities:

    • Assessing operational impact
    • Reporting (both formal and informal)
    • Analyzing resolutions
    • Managing cases
    • Overseeing implementation.

As a best practice, program leadership should budget and program for the funding of DMSMS operations using a risk-based approach and in consultation with the DMT. Independent SMEs can help a program estimate both DMSMS operations and resolutions costs, based upon a program’s selected acceptance of risk. Below are some drivers of operations funding:

Start-up versus steady-state effort. Beyond the spike of initial start-up, the funding requirements for DMSMS management operations should be relatively stable. This reflects the fact that DMSMS management requires a set of both nonrecurring and recurring tasks. Startup DMSMS management tasks are predominantly nonrecurring and may require substantially more effort than that during steady state, which translates into differences in the funding needed to support DMSMS management under these two different conditions. Examples of start-up tasks are developing a DMP; obtaining, formatting, and loading parts lists/BOMs; carrying out any additional research and analysis required to ensure the quality of the data; and putting in place a case management database and tracking system. The scope of a DMSMS management start-up effort is also broader, addressing the entire parts list/BOM, all vendors, and all parts, rather than only changes to or periodic updates to a subset of these. Because of those factors, the funding required for start-up can be up to four times greater than that to maintain a steady-state DMSMS management effort. Table 5 compares the start-up and steady-state efforts required for data cleanup, vendor surveys, and item research.

Table 5. Comparison of Start-Up and Steady-State Effort

DMSMS monitoring and surveillance activity

Start-up

Steady state

Data cleanup

Entire BOM

Only changes to the BOM

Vendor surveys

All vendors

Only on a time-phased, periodic schedule

Item research

All items

Only when certain conditions are met (e.g., item status changes, item has not been researched in a certain period of time, changes in the sources of an alternate item, packaging changes, revisit of a previous “no action required” item)

  • Monitoring and surveillance scope and level of effort. Monitoring and surveillance are recurring tasks for the DMSMS management of any program. If the program has adopted a risk-based approach to monitoring and surveillance, then decisions will have been made regarding which subsystems to monitor and which of their items and assemblies to monitor proactively. A program might also wish to consider the quality of the data available in the BOMs as a factor in determining the level of effort required to enable monitoring and surveillance, particularly in the beginning phases of a program. The scope and level of effort might fluctuate based upon the maturity of the DMSMS management program. More information on these monitoring and surveillance activities is provided in Section 4.
  • Assessment and analysis level of effort. Assessment and analysis are recurring tasks for the DMSMS management of any program. The magnitude of the requirement is contingent upon the DMP and the number of items that the team chooses to assess. Also relevant is the level of detail required for periodic health assessments of the system from a DMSMS perspective (see Section 4.6).

With the above information, programs can estimate the funding required to support DMSMS management operations in order to inform the program’s overall programming and budgeting. Below are data elements that a program might consider for estimating operations funding:

  • Number of parts lists/BOMs to be addressed by the DMSMS management effort (dividing these into critical, mission essential, and non–mission critical may provide a program with the opportunity to phase in the assessment and analysis [and corresponding costs] of less critical ones over time, rather than all at once)
  • Whether critical materials within the supply chain will be monitored (if so, then budget estimates for this workload are not likely to be sensitive to the results of the one-time identify processes)
  • Number of man-hours required to perform the nonrecurring start-up tasks for each BOM
  • Number of man-hours required to perform recurring steady-state tasks to monitor each parts list/BOM
  • Number of man-hours required to perform recurring steady-state tasks to assess and analyze each parts list/BOM
  • Hourly man-hour cost for participating stakeholders
  • Number and cost of predictive tools to be used for monitoring
  • Scope of involvement required for meetings, travel, health assessments, and generation of other reports.

The responsible office (often the program office) must program and budget for the resources for these activities or, alternatively, formally acknowledge risk and revise expectations regarding the focus and scope of the program’s DMSMS management effort. Leadership support and agreement are critical to the success of this effort. DMT operations funding will not be precisely known until the results of the one-time identify processes are available, as they select the items to be monitored with predictive tools and vendor surveys. If these selections are significantly different from the estimates used to formulate the budgets, budget adjustments will be required. If the budgets cannot be adjusted, changes to the strategic underpinnings and the DMP should be made to explicitly recognize the risks being taken. The bottom line is that planned DMT operations should be based on the actual funding allocated to DMSMS management operations.

The most effective rationale for obtaining DMSMS operations funding is to make the justification meaningful to the decision maker. The best way to approach this is to demonstrate the repercussions of inadequate funding on total ownership cost, the cost avoidance by being proactive, and/or mission capability and the return on investment (ROI) from DMSMS management activities. Because DMSMS management is not a standalone activity, including DMSMS-related resource requirements in the budgets of other activities, such as parts management, reliability and maintainability, or supportability activities, is often a successful tactic. Maintaining convincing metrics about accomplishments and cost avoidance by being proactive also helps justify DMSMS operations-related budget requests.

3.4.2. Manage Cases

The purpose of case management is to track and manage DMSMS issues from initial identification to implementation of a resolution and to provide a record of past issues and their respective approved resolutions. A program will need to document its approach (i.e., any criteria to be applied) regarding when to open an obsolescence case. Should it be for every item for which an EOL notice has been issued? Just for those items for which an EOL notice has been issued and current stocks will not support the system through end of need? Only for those items that will require a DMSMS resolution? Ideally, a program might want to open a case on every item for which there is an EOL notice, even if a resolution is not necessary, because it will provide more complete documentation and inform future DMSMS management efforts for the program.

To facilitate DMSMS case management, the DMT should consider the use of a tracking tool or database built upon a case sheet, consisting of basic and status data, for each DMSMS issue. Depending on how software intensive a system is, a program’s case management database may include some additional data elements associated with software. The development of a case sheet would therefore mark the beginning of the case management process. One prime contractor undertook the development of a case management database to standardize and facilitate what had previously been a time-consuming manual process that required months to complete a basic status update for a case. Having a standard case management database enabled the program to expedite the resolution of issues as well as to ensure configuration control in the presentation of DMSMS issue case information across the program.

The tracking tool or database should support functions such as the following:

  • Tracking by case number for future reference (including an ability to link to a previous, related case).
  • Tracking of all appropriate part information and nomenclature (configuration and vendor parts) for manufacturer data, including last sale date and demand.
  • Documentation of information on item higher assemblies and the criticality of impact.
  • Documentation of the results of research and other engineering notes.
  • Selection or identification of a particular DMSMS resolution or set of resolutions for each case.
  • Determination of DMSMS resolution costs, cost avoidance by being proactive, and ROI.
  • Assignment of action items to particular individuals or organizations related to a case, for example, who is responsible for working what aspects of the case.
  • Tracking of the length of time to identify and resolve DMSMS issues, for example, the timing for the next case management action and the alignment of such actions with key dates, such as the dates by which a bridge buy will need to be made.
  • Determination of the status of a DMSMS case, such as the following:
    • “Open”—cases that are actively being worked. Below are potential variants to “open” cases that a program might want to consider tracking further:
      • “Open: Under Investigation”—cases that are open and one or more DMT members are actively investigating the identified DMSMS issue. Such an investigation will first seek to validate the existence of a DMSMS issue that has the potential to impact the program and then to identify a recommended resolution.
      • “Open: Decision Pending”—cases that are open and for which the recommended resolution has been determined and is awaiting final program decision to proceed and/or funding. Information on opened cases requiring no action should be captured and fed back into the identify phase of the DMSMS management process, so that the case will not have to be investigated again, unless some new information comes to light.
      • “Open: Implementation Pending”—cases that are open and for which the decision to proceed and funding have been obtained, but implementation of the approved resolution has yet to begin.
      • “Open: Under Implementation”—cases that are open and for which the approved resolution is being actively implemented.
    • “Closed”—cases for which the approved resolution has been fully implemented and fielded.
    • “Watch List”—cases that are closed, but upon which the program has chosen to place further scrutiny to monitor if assumptions regarding obsolescence and resolutions remain consistent with new realities as a program progresses. For example, it is important to know if demand for an item is greater than the assumptions used to calculate the size of a life-of-need buy until the next technology refreshment/insertion. This would also apply to cases whose implementation is taking longer than expected.
  • Facilitation of communication with the DMT regarding the status of a DMSMS case.

Some programs may track a resolution until it is completely implemented and fielded. Other programs may stop tracking a resolution once it has been funded, rather than tracking it through fielding, due to the length of time for implementation. Also, depending on the level of detail needed, programs may combine open and pending resolutions. The decision about the level of detail to be tracked should be made when the program establishes its case management process.

A DMSMS case management report contains the relevant information—CAGE, part number, NSN, item type, next-higher assembly (NHA), and so forth—on DMSMS cases that are open (including all individual variants determined useful by the program), closed, and composing the watch list. Those reports include a synopsis of assigned priority, potential resolutions, selected resolutions, relevant points of contact, relevant case management metrics as defined by the DMT, and DMT action items relevant to each case. These case management reports are important, because they can be used for publicizing DMSMS successes and sharing data among other DoD platforms. Robust case management provides the basis for meaningful DMSMS program metrics. Effective outreach could help obtain funding both for DMT operations and for implementing resolutions to DMSMS issues.

3.4.3. Evaluate Program

The DMT should continually evaluate the effectiveness of the DMSMS management program measured against the defined DMT objectives. Recording and periodically analyzing performance metrics are important elements of this evaluation. Although metrics do not provide an answer to programs in and of themselves, many different metrics can and should be captured for a DMSMS program. Metrics indicate where a program should investigate further.

The DMT should determine what metrics to use as a basis for evaluation, how to collect those metrics (contractual requirements may be necessary), and how frequently to report those metrics. In addition, a feedback loop is needed so that the DMT can continually improve the DMSMS processes, process inputs, and process outputs. Below are some examples of DMSMS program evaluation metrics:

  • Trends in health assessments
  • Percentage of items forecasted to make it to end of need
  • Percentage of BOMs and software monitored
  • Number of DMSMS notifications or cases created or opened
  • Number of proactive cases vs. reactive cases (only those reactive cases for which the program should have been proactive)
  • Number of cases closed
  • Number of cases pending decision
  • Number of cases awaiting implementation
  • Average time to case closure
  • Average time to case resolution decision
  • Average time to resolution implementation
  • Estimated or actual cost avoidance by being proactive (depending on data available)
  • Percentage of the program robustly managed, based on unit-level BOMs and assemblies in the system (e.g., percentage of BOMs and assemblies of the system to be monitored out of the total number of items of the system)
  • ROI[43]
  • Operational availability deficiencies due to obsolescence that were avoided (e.g., when the resolution is put in place, quantify the operational deficiencies that would have taken place if that resolution was not implemented).

Data for the cost avoidance by being proactive are often also used by programs to evaluate and showcase the effectiveness of its DMSMS management. The cost avoidance by being proactive is the difference in cost between resolving an identified obsolescence issue now or later. This is why it is important to always view cost avoidance in terms of being modified by being proactive. While no cost avoidance results from being reactive, in some cases, little or no cost avoidance results from being proactive. Estimates for the cost avoidance by being proactive have traditionally been calculated in one of two ways: (1) the difference between the cost of the selected resolution and the next viable resolution or (2) the difference between the lowest-cost viable resolution and that of a redesign.

These estimation approaches are not without problems. For example, the first estimation approach assumes that if a program was reactive, then (1) the proactive resolution would not be feasible when the problem actually was identified and (2) the next viable proactive resolution from the past would still be feasible when the problem was identified. The second estimation approach implies that if a program was reactive, redesign is the only remaining option at the time the problem is identified. Both of these approaches overstate cost avoidance (the second method overstates more than the first). The true cost avoidance by being proactive can be determined
only in hindsight on an item-by-item basis in programs that were entirely reactive. And, of course, no program should be entirely reactive.

To the greatest extent possible, metrics should be focused on leadership concerns. In that way, leaders can be more readily convinced of the benefits of DMSMS management and, consequently, will be more likely to support the DMSMS management program.

3.4.4. Ensure Quality

DMSMS management support consists of complex processes using inputs from diverse sources and producing outputs supplied to customers with varying expectations and needs. Attention to the quality of these processes ensures the consistency and high quality of program support. Therefore, the DMT should operate within a well-defined and functioning quality management system (QMS). The DMT should ensure that a quality plan is established, with attention to process documentation, quality controls, meaningful metrics, and timely feedback loops in the areas of quality and process effectiveness. See Appendix I for more information on the QA process.

4. Identify: DMSMS Monitoring and Surveillance

Monitoring and surveillance constitute the Identify step of the DMSMS management processes. This second step requires a program to monitor and survey its items and materials for EOL notices or other indicators of potential discontinuance. DMSMS monitoring and surveillance should begin as early as possible during the design phase and continue throughout the entire life cycle of the system. This section describes the monitoring and surveillance processes:

  • System prioritization. This process entails the determination of the scope and focus (e.g., which subsystems of the system are of most interest, due to criticality, operational safety, or associated DMSMS-related costs) for the DMSMS management effort.
  • Identification and procurement of monitoring and surveillance tools. This process entails identifying and procuring the DMSMS predictive forecasting and associated data collection and management tools to support the DMSMS management program.
  • Collection and preparation of item data. This process encompasses the collection of BOMs and item data and the prioritization of items to eliminate those that can be easily replaced (such as fasteners) from items availability analysis. In addition, the BOM/parts list is prepared and loaded into a predictive tool for analyzing item availability.
  • Analysis of item availability. This process includes the combination of market research and the use of predictive tools to determine initial, and subsequent, item availability baselines for immediate and near-term obsolescence issues for the program.
  • Collection and update of programmatic and logistics data. This process entails the identification, collection, and update of programmatic and logistics data necessary to analyze item availability and, ultimately, to assess the DMSMS impact and determine a resolution.

Figure 9 identifies the one-time processes and the recurring processes associated with DMSMS monitoring and surveillance. For the most part, system prioritization, identification and procurement of monitoring and surveillance tools, and collection and preparation of item data are one-time processes. However, depending on when the prioritization was done, new data on DMSMS issues may lead to additional systems being given a high priority. The major data cleanup effort during DMSMS management start-up for the program will also require upkeep to maintain consistency with configuration changes once DMSMS management has reached a steady state. The other two processes—analysis of item availability and collection and update of programmatic and logistics data—recur when either the program receives a new EOL notice directly or the output of the program’s predictive tools or market research surveys has been updated.

Figure 9. DMSMS Monitoring and Surveillance Processes

DMSMS Monitoring and Surveillance Processes

4.1. Prioritize Systems

Robust DMSMS management may require monitoring and surveillance of thousands of items simultaneously. It could take months or even years, depending on the size of the system, the availability and format of data, and the program’s manpower, to load all of the program’s BOMs into a predictive tool. Prioritizing the scope and focus for the DMSMS management program, using a risk-based approach, is crucial for a complex platform, which typically has many subsystems, each with multiple units with multiple assemblies, which in turn include many items and software. Prioritization in this process is not a ranking of subsystems to monitor; rather, it is a “yes” or “no” DMT determination of what portions of the system to actively monitor, when, and at what frequency.

Initial prioritization of the portions of the system on which to focus the DMSMS management effort can be based upon the following:

  • Safety. A top priority for the scope and focus of a DMSMS management program is any subsystem containing a critical characteristic whose failure, malfunction, or absence could cause a catastrophic failure, loss, or serious damage resulting in an unsafe condition. Special attention should be paid to aircraft, missiles, rockets, and airborne systems, as well as to other systems that involve command, steerage, and propulsion of ships or land vehicles. Similar safety concerns on other systems should be identified by the program offices.
  • Mission criticality. Another top priority for the scope and focus of a DMSMS management program is any system—whether a primary mission system or an auxiliary or supporting system—whose operational effectiveness and operational suitability are essential to successful completion of the mission or to aggregate residual combat capability. Such systems are critical, because if the system fails, the mission likely will not be completed, especially if there is a known single point of failure or a significant impact on NHAs.
  • DMSMS-related costs. Any subsystem experiencing or expected to experience frequent or expensive DMSMS-related issues should be monitored. Considerations for identifying subsystems under this criterion, before actual data are available, include unique fit or materials, closed architecture, modified COTS assemblies, high electronics content, high redesign costs, single source, low reliability, or hard-to-support software.
  • Existing problems/historically troublesome. If DMSMS management is already underway, program management may already have a sense of those subsystems that cause the most headaches. If a program is just starting, program management might still be able to look to predecessor platforms to identify subsystems that have consistently proven to be trouble spots. Data to review in these instances include the reliability (e.g., low mean-time-between-failure rates or high mean-time-to-repair rates) of the assemblies, software, and other items in the subsystem. Another set of subsystems of interest are those that are common across platforms and, therefore, could have a potentially large impact if they fail.
  • Life-cycle phase. The system prioritization process may vary as a function of life-cycle phase:
    • For systems in design and production, actual data may not be available to understand where high costs or frequent DMSMS issues are occurring. There may be only some near-term indications of such areas based upon ongoing monitoring and surveillance. These areas are expanded as the system matures. It is especially important to identify DMSMS issues during design or production, because decisions made during those phases can significantly affect the system’s life cycle. Furthermore, when obsolete items are not eliminated from product designs, higher-risk distributors are more likely to be used to obtain items that are no longer in production. This adds to the risk of finding counterfeit parts in the DoD supply chain and, more important, in DoD weapon systems used by the warfighter.
    • Over time, the sustainment strategy may evolve; consequently, the mix of organic and contractor roles may change.
    • Once a subsystem has been fielded, there is a greater potential that an obsolescence impact on that subsystem could be felt directly by the warfighter in terms of readiness. This may be less of an issue if a program knows that it has sufficient spares availability.
  • Sustainment strategy. A system’s sustainment strategy reflects the maintenance or support concept of operations for that system. Such strategies consider impacts on system capability requirements, responsiveness of the integrated supply chains across government and industry, maintenance of long-term competitive pressures on government and industry providers, and effective integration of system support that is transparent to the warfighter and provides total combat logistics capability. The DMT should be particularly concerned with these issues if the government is providing sustainment support. If a contractor is required to resolve DMSMS issues, then the DMT’s primary role is to oversee the contractor’s efforts.
  • Availability of technical data. Although a program may prefer to implement robust DMSMS management over all priority subsystems, the reality is that not all of the BOM/parts list data may be available to do so, particularly at the start-up of DMSMS management for a program. In such instances, programs will not be able to scrutinize priority subsystems until sufficient data become available. However, a program should not postpone or avoid pursuing the necessary data for known, more complex and troublesome subsystems.

Each program will need to determine the factors of most importance to prioritize its subsystems for DMSMS monitoring and surveillance. Among the factors of interest to a program, not all will be of equal importance. To address this, a program might wish to develop a weighting scheme to help sort the system priorities for its monitoring and surveillance effort. A program that already is well underway, and for which historical data are available, could consider establishing a method that considers the likelihood and consequence of a particular subsystem being degraded due to obsolescence.

4.2. Identify and Procure Monitoring and Surveillance Tools

The DMSMS management program should identify and procure predictive obsolescence tools and associated data management tools needed to support DMSMS monitoring and surveillance. Predictive tools may be particularly useful for analyzing certain types of items, such as electronics; however, these tools have limited capability for other types of items, such as mechanical hardware or COTS assemblies. Most DMSMS predictive tools perform the same core functions of monitoring the availability of electronic items in the BOM and forecasting their obsolescence. Each tool has a set of loading criteria and formats, output report formats, and other information that can be ascertained from the loaded BOM.

Most programs will not be in a situation in which they independently evaluate and purchase a license for using a predictive tool. More typically, either a parent organization will have bought a centralized subscription to one or more tools, or the program will choose a DMSMS management provider (e.g., its prime contractor or independent SME) that has its own set of tools. Tools, however, may be a selection factor for independent SME organizations and the program may need to obtain a license for its prime contractor or OEMs.

In determining which predictive tools to use, a program should consider the following desirable attributes:

  • Manage accurate configurations.
  • Enable real-time assessments of availability for items qualified for the system.
  • Identify obsolescence issues and specific quantities per affected assembly.
  • Identify after-market sources of supply.
  • Create or generate timely alerts on production change notifications and PDNs.
  • Enable real-time views of current item availability analysis.
  • Provide highly accurate data.
  • Provide flexible data input and query options.
  • Allow comprehensive reporting options.
  • Contain a large number of key items for the system (or be able to add them).
  • Contain information about counterfeits and information assurance requirements.
  • Rapidly develop obsolescence case sheets, providing streamlined and complete status of obsolete item issues when integrated with a DMSMS management system.
  • Provide engineers with the data needed to evaluate and implement resolutions.
  • Share notes and resolutions across all managed platforms and systems.
  • Enhance productivity by minimizing the impact on engineering staffs, while rapidly providing critical data needed for decision making.
  • Provide excellent customer service.
  • Have a low cost.

If a program decides to have its prime contractor or OEMs perform monitoring and surveillance using DMSMS tools, the government must have access to the data reported by those tools for two key reasons: (1) to allow the government sufficient visibility for effective oversight and (2) to enable it to readily assume DMSMS management responsibilities if DMSMS management roles change.

A specific tool, alone, will not recognize all items in a BOM. A recent informal study of two predictive tools found that one of them successfully recognized only 71 percent of the items being researched by the team,[44] and the other recognized only 72 percent of the items being researched. When comparing the availability reported by the two predictive tools, the study found that the tools disagreed regarding the obsolescence status of 4 percent of the items being researched. There are legitimate reasons for these statistics. In particular, different tools use different algorithms and philosophies in identifying and reporting obsolescence. Also, the electronics industry changes rapidly, and new items are added daily. Furthermore, update schedules for the predictive tools vary, sometimes resulting in discrepancies in item availability status between tools. Therefore, if funding allows, and if practicable, the program should use more than one predictive tool and, for items not tracked by predictive tools and for items that are particularly critical, should conduct manual research. Regardless of the tools used, engineering analysis and judgment remain key factors in identifying DMSMS issues.

Beyond predictive obsolescence tools, BOM data management tools, configuration tools, logistics data collection tools, data storage and retrieval tools, and report generation tools are all needed for monitoring and surveillance. Selection criteria include reliability, user friendliness, cost, and usability by multiple programs. As discussed in Section 3, DMSMS management systems exist that include both proactive functions and data collection and management functions.

Many tools can assist a program with monitoring and surveillance, as well as with other data management tasks. A list of tools to assist with monitoring and surveillance can be found in the DKSP.

4.3. Collect and Prepare Item Data

Once the focus and scope of the DMSMS management program have been determined by the prioritization of subsystems based upon mission criticality, operational safety, and so on, the data necessary to support item availability analysis and, ultimately, DMSMS impact assessment should be identified and collected. Indeed, program leadership should ensure that the data to support DMSMS management are obtained. Item data, including parts and software lists/BOMs and additional information obtained from market surveys, are used to analyze item availability, resulting in a list of system items that have immediate, or anticipated, near-term obsolescence issues.

4.3.1. Item Data Collection

4.3.1.1. Hierarchy of System Items

To adequately and cost-effectively address obsolescence for a program, the DMT may have to monitor, assess, and resolve DMSMS issues at different and multiple levels within a system. Figure 10 illustrates the hierarchy of system items. As one moves from left to right across the figure, the system is decomposed into increasingly smaller items, from unit to assembly to component. For each of the items of the system, additional related terms are also provided. So, for example, when a program is referencing the component level, other terms often used to refer to this level of item are piece parts and device.

Figure 10. Hierarchy of System Items

Hierarchy of System Items

Notes: LRU = line replaceable unit, SRA = shop replaceable assembly, SRU = shop replaceable unit, and WRA = weapon replaceable assembly.

4.3.1.2. Different Types of Item Data

Different types of items are likely to be incorporated into the design of any system. Therefore, the DMT needs to be aware of how different types of data may need to be collected or even suggest different means of collecting and managing the data. The following subsections contain such information for both COTS and hardware–electronic and MaSME items and for software.

4.3.1.2.1. Hardware–Electronic and MaSME Items

For hardware–electronic and MaSME items–data, a parts list or BOM is an indispensable data resource for robust DMSMS management. Without a parts list or BOM, item availability analysis, impact assessment, and the continuous prediction of discontinuance by a DMSMS management program are impossible.[45]

A BOM identifies the materials, components, and assemblies used in making a unit. The list may be in a flat format or an indentured format. A flat BOM is a simple list of items, while an indentured BOM shows the relationships (generally in a top-down breakout format) of components to assemblies to units to the system. Figure 11 depicts the two formats.

Figure 11. Comparison of Flat and Indentured BOMs

Comparison of Flat and Indentured BOMs

Because it provides a bigger picture for identifying and weighing resolution options for an identified DMSMS issue, an indentured BOM format is preferred over a flat format. For example, when analyzing item availability, a flat BOM enables the identification of only the number of obsolete items within the unit; it would not provide any indication of whether some of the items are on the same assembly. Not knowing the effect of the identified, immediate, and predicted obsolescence issues on the system’s item hierarchy limits resolution options. In some cases, it may be more cost-effective to perform a minor redesign of an assembly, rather than undertaking life-of-need buys of multiple components within that assembly. An indentured BOM enables the program to more readily visualize the relationships of identified obsolescence issues within the system and to use this information to inform the identification and determination of potential resolution options.

In addition to the configuration (indenture) information conveyed through an indentured parts list or BOM, useful item data pertaining to the components, assemblies, and units of the program’s system include the following:

  • OEM-approved alternatives
  • OEM technical manuals
  • OEM DMSMS mitigation efforts underway
  • OCM part number
  • Sources of active manufacturing
  • Actual or projected EOL
  • Function (active versus passive, complexity)
  • Type (custom, hybrid, proprietary)
  • Restriction of Hazardous Substances (RoHS)/lead-free (Pb-free) information
  • F3 details.

For MaSME items, listed on a BOM, the items of interest may be reduced after production is completed by using a Provisioning Master Record (PMR), which includes only those items that are purchased by the DoD supply system. PMRs also provide additional information that can be used to further reduce the number of items to monitor, as described under “4.3.2. Item Data Preparation.”

One of the DMT’s first tasks is to obtain the BOMs (probably from the prime contractor via flow-down arrangements through the supply chain) for the system. The best situation is one in which the government has established a contractual requirement for the BOMs (and for notional BOMs or parts lists during design).[46] Contractual language, including data rights issues, is important to establish up front between the program office and prime contractor. Prime contractors often have to negotiate with OEMs for access to their BOMs, so it is not valid to assume that a prime contractor will automatically be able to make these available to the program office. When a contractual requirement is not in place, OEMs are often reluctant to release BOMs, due to competition or proprietary issues. However, an OEM initially unwilling to provide a BOM does not mean that one cannot be obtained. Experience has proven that a DMSMS management program may be able to convince the OEM to share BOM data. Below are some examples of ways to pursue access to the BOM:

  • The OEM may automatically assume that the program expects delivery of the entire technical data package (TDP). That is not correct. The program needs to make sure that it clearly explains what is being requested; data item description (DID) DI-PSSS-81656A[47] outlines data fields that a program requests (see the DKSP). Ideally, the BOM should be in an editable electronic open-standards-based format. An OEM may not have an issue with delivering this information.
  • If an OEM is still reluctant to share the BOM, the program may wish to determine if the OEM is more willing to share this information directly with the government. In some cases, subcontractors are wary of sharing their BOMs with the prime contractor but will more readily deliver them directly to the government or a government representative (with a nondisclosure agreement).
  • In both of the above cases, the program should illustrate advantages to the OEM from sharing the requested data. Because BOM data enable the program to continually monitor for obsolescence issues, the program will share DMSMS discontinuation notices with the OEM and can assist with researching resolution options, so that both parties (government and OEM) benefit.
  • If the program is still not able to convince the OEM to share the required data, then the program has several options to consider. It may be able to develop a BOM from available data such as drawings or technical documentation. With a limited BOM, the DMT can load a predictive tool, identify the status of items, and perform basic item availability analysis. As it gets better at managing DMSMS problems, the DMT will realize that any redesign or new system acquisition should include the BOM as a contract deliverable, along with the new components, assemblies, units, or systems. It may be prudent for a program to require the procurement of some types of BOM data on any new system acquisition. As an alternative to creating a BOM from available data, a program could also perform a physical control audit.
  • If the OEM requires a program to pay for the BOMs needed for robust DMSMS management, then the program should first determine whether the required data have not already been paid for and received through some other avenue (CM, production, provisioning, etc.). In some cases, the program may discover that the OEM is already proactively monitoring the BOM for DMSMS issues. In light of this information and due to funding constraints, a program may choose to leave DMSMS management to the OEM, rather than acquiring and loading the BOMs into its own predictive tool. However, if a program does decide to do this, it must maintain sufficient oversight of the OEM’s DMSMS management efforts. This might entail the program requiring the regular delivery of item availability analysis for the system or of immediate alerts when a DMSMS issue is identified. Because no DMSMS predictive tool is 100 percent accurate, a program may still wish to acquire its own tools and load its own BOMs to minimize the risk of missing a DMSMS issue that could significantly affect the system.
  • The DMT can manage the units within the system like a COTS item. Using COTS items within a system design has several benefits, including reducing or eliminating the risks typical of custom-developed systems. However, COTS items present a unique set of challenges for the management of DMSMS issues.[48] These challenges are due, at least in part, to the fact that these items are produced for the commercial market. For example, the rapid turnover of COTS items creates unique obsolescence-induced supportability issues for military systems, because OEMs are likely to replace or stop producing COTS items long before the life cycle of a system is complete.
  • DMSMS management concerns about the incorporation of COTS items in a system design are inevitable. Avoiding DMSMS issues due to the introduction of COTS items in a system design calls for effective relationships among all program participants: the COTS supplier, the system developer and integrator, the DMT, and the buyer (for example, the item manager). The DMT must remember that all COTS items are subject to DMSMS issues, but some are prone to specific problems. For example, software, central processing units, memory chips, and disks change frequently. These specific COTS classes aside, a degree of obsolescence is always in place in the form of planned minor upgrades or refreshes, typically at the 2- and 4-year marks. Beyond that, a major upgrade—a next generation—should be expected at some time in the future.
  • Automated DMSMS predictive tools typically do not comprehensively monitor COTS and mechanical items for obsolescence. Further, BOMs for COTS items are not usually readily available[49] and may not be cost-effective to obtain if available. However, for a COTS-intensive system, a program may want to investigate whether BOMs are readily available and, if so, develop the cooperative arrangements necessary to ensure delivery of those COTS BOMs, if cost-effective.
4.3.1.2.2. Software

Software items within a system may not always be automatically included in an indentured BOM. For this reason, a program may need to request (and then document via contract) that a list of software items be obtainable as part of a BOM. CM documents are another potential source for identifying the software in a system. For a third source, software is often a part of the software verification document. A fourth source is a data rights disclosure letter if it is a requirement on the contract. This letter lists all areas for which the government does not have full data rights, including commercial software applications and contractor proprietary software. A final source is a software licensing management group, if one exists. The software version document is a fifth possibility.

Just as an indentured BOM shows hierarchical interrelationships among items, software interdependencies should also be captured. For each listed software element, the software and hardware that depend on it and the software and hardware upon which it is dependent should both be identified. Software interdependencies may not be hierarchical; there can be cross-system relationships. An understanding of these relationships will not be found in a BOM; it is best achieved through discussions with systems engineers and/or software developers or may be identified in interface control documents. Consideration should be given to modifying the DMSMS DID or creating a new one for software.

4.3.2. Item Data Preparation

By this point, the program has identified and collected all relevant item data as well as selected and procured the appropriate DMSMS predictive tools. Before loading the parts lists/BOMs into the tools, the program should take several final steps to prepare the item data for recurring analysis of item availability. First, the parts lists/BOMs should be reviewed to identify the items on which the program’s DMSMS monitoring and surveillance activity will focus. This is a second prioritization filter—the first being the prioritization of subsystems on which to focus the DMSMS management effort (see Section 4.1)—that considers the criticality and safety as well as the vulnerability of particular items within the system design.

  • Because of rapid technology changes, robust DMSMS management and proactive monitoring for electronic items has generally been the primary focus of DoD’s DMSMS management guidance and effort. Being the center of attention, however, does not necessarily equate to adequate funding. Programs often struggle to obtain and maintain budgets for proactive DMSMS management in this area.
  • Narrowly targeting the items to monitor can have a large impact on the cost of a program’s DMSMS management effort, thereby focusing attention on the higher-risk items. For a program dealing with a larger number of items, applying this second prioritization filter could eliminate large portions of the BOM from the monitoring requirement. Culling out lower-vulnerability items from a program’s DMSMS monitoring effort may be less critical if the program is not dealing with a large number of items.
4.3.2.1. Hardware–Electronic and MaSME Items

Parts lists and BOMs may contain any number of items (such as fasteners) that do not need to be analyzed with a predictive tool because of the availability of so many alternatives. As described in the strategic underpinnings section (Section 3.1), to make more effective use of limited resources, programs should adopt a risk-based approach to proactive monitoring. For items that are listed on parts lists and BOMs, this section contains more details on the application of the first two strategic determinations—applying heuristics based on life-cycle estimates and further analysis of uncategorized items—associated with determining which items to monitor.

The first determination involves applying heuristics based on life-cycle estimates. In some instances, a supply system health analysis is performed to offer up a broad-based supportability picture and identify low-, medium-, and high-risk candidates from a support perspective. The results of applying the first determination to hardware–electronic and MaSME items listed on parts lists/BOMs are the following three categories of items:

  • Items to definitely monitor. These items include certain item classes known to have a high propensity for obsolescence issues. These item types include electronic COTS assemblies (e.g., networking gear, computers), active components, radiofrequency components, programmables, memory, microprocessors, ASICs, hybrids, and custom electronic assemblies. Assemblies[50] that contain sole-source items that are in low demand also should be proactively monitored. Custom passive items are also prime candidates for monitoring. In addition, if a design contains materials with chemical properties that are a function of the design, are sole source, and/or are otherwise potentially threatening to the environment, these materials should be monitored. All electromechanical items should also be included in a program’s monitoring efforts. This subset of item types generally introduces high risk to a program if the program chooses not to monitor them.
  • Items not to monitor. There are two types of items not to monitor:
    • Items where no further action is required. This subset of item types includes standard/common industrial items, such as mechanical components, connectors, cabling, and consumables, that typically do not present a significant risk, because most of these items are easily and quickly replaced when they become obsolete. Generally, these items can be eliminated from monitoring. Some circumstances, however, warrant a DMT’s monitoring of these types of items. For example, some items may have something unique about their operating environment, may be identified by the DMT as important, or may require extensive requalification. The DMSMS SME and engineering activity representative should understand the associated risk before choosing not to monitor such items and should revalidate that decision periodically.
    • Items where preparations should be taken. Custom-fabricated items (such as fenders or castings) that will no longer be produced after final delivery also should not be monitored for DMSMS issues; however, logistics managers and PMs should ensure that enough of these items are acquired for system sustainment through system disposition. As a safeguard, the program should obtain sufficient documentation to enable the reacquisition of custom-fabricated items in case of future need, through new acquisition contracts.
  • Items for which not enough is known to determine the need for monitoring. The final category of items is uncategorized items, because not enough information is known to determine whether the program should monitor these items.
  • With regard to this final group of uncategorized items, electronic and MaSME items, a program has three options from which to choose:
  • Monitor all of these items. This is a low risk for being caught off guard with an obsolescence issue, high-monitoring cost approach.
  • Do not monitor any of these items. This is a high risk for being caught off guard with an obsolescence issue, low-monitoring cost approach.
  • Conduct further analyses to determine which items to monitor. This approach optimizes the risk associated with being caught off guard with an obsolescence issue and monitoring cost.
  • From a risk-based and resource-constrained perspective, the latter option should only lead to monitoring those uncategorized items where the negative effects of a reactive approach are both most likely and most severe. The decision to pursue a reactive approach to DMSMS monitoring implies that the program will experience no severe ill effects from waiting until an item cannot be obtained before seeking a resolution. A reactive approach should be sufficient unless significant risks are present.
  • In applying the second determination, a program performs additional analysis to determine which of the items from the “uncategorized” list to proactively monitor. Three risk categories should be used to determine where a proactive approach should be taken for a particular material or item. These risk categories are as follows:
  • Item criticality. This risk category addresses the degree to which an item (whether or not it is an assembly or a component used to repair an assembly) is critical to the functionality of the system and ultimately the operational readiness of the unit employing that system. Quantitative and qualitative considerations for this risk category include the following:
    • Critical safety item
    • Mission criticality[51]
    • Item essentiality code
    • High demand (perhaps in top 10%)
    • High cost.
  • The first three considerations are direct indicators of criticality. Obviously items that are mission-critical or critical safety items meet the high criticality criterion. While critical safety items may be clearly identified, mission-criticality items are sometimes more ambiguous. The item essentiality code is an attempt to assist in classifying these items, but these data are not always accurate. There also should be a high correlation between high-cost and/or high-demand items and criticality. These considerations, depending on the system, can therefore serve as factors in their own right or in combination as a reasonable proxy for mission criticality when no other data are available.
  • Supply chain vulnerability. This risk category represents a key difference between electronic items and MaSME items. In the former case, the item often becomes obsolete because of technology changes. For the latter, obsolescence is usually related to a source going out of business or changing its product line. Quantitative and qualitative considerations for this risk category include the following:
    • Source related (e.g., no identified source, sole source, or only foreign sources)
    • Financial health of the supplier (e.g., as measured by Dunn and Bradstreet)
    • Persistent backorders (perhaps as indicated by an increasing number of backorders for at least 8 consecutive months)
    • Long customer wait times (perhaps top 10%)
    • Recent substantial price increase
    • Time since last order (perhaps if more than 3 years)
    • Low demand
    • Life cycle of the items.
  • The first three considerations examine the supply chain directly. A supply chain is potentially vulnerable if there is no source, just one source, or only foreign sources identified. Even if there are multiple sources, all unhealthy suppliers are a situation of concern. In some high risk situations, it may be useful to conduct a specific financial analysis on a particular supplier, since sources such as Dunn and Bradstreet are not always current. Similarly, long customer wait times, especially when there are persistent backorders are indicators of a potential problem.
  • The fourth and fifth considerations not only exacerbate the risk further, but also indicate other less obvious supply chain vulnerabilities and scarcities. Long wait times may be indicative of more serious problems. Similarly, a sudden price increase may imply something is changing in the supply chain that will have an effect on availability. Either of these factors may represent an early warning of future problems.
  • If a long time has passed since the last order, there may be substantial uncertainty about supply chain vulnerability. A source may make a financial decision that it is not profitable to keep producing an item, if the demand signal for that item is low. Finally, if the item has a short technological life cycle, its supply chain is more vulnerable.
  • Time to implement a resolution. The risk category addresses how long it will take to implement a resolution to a DMSMS issue for an item or material in comparison to the stocks that the program has on hand. If there is more than enough stock on hand and the time to implement is short, then the risk to the program would be viewed as lower; however, if there is a long lead time to implement a resolution and the stocks on hand are not sufficient, then this indicates high risk. Quantitative and qualitative considerations for this risk category include the following:
    • TDP availability for structural, mechanical, and electrical items or electronic items (e.g., not available or limited data) or availability of the material specification for an engineered material[52] (knowledge of material composition will shorten cycle time)
    • Source controlled
    • Manufacturing difficulty
    • Long lead time to requalify
    • Manufacturing cycle time
    • Availability of tooling and test equipment
    • Cost to implement a resolution
    • Defense unique.
  • If technical data are not available, reverse engineering will be required. This takes a long time and adds significantly to the risk. Reverse engineering of a material or a structural, mechanical, and electrical item or electronic item is almost always feasible. Many items can be reverse engineered in 3 to 6 months, but some take much longer. Also, source-controlled items (e.g., items where the allowable or qualified sources are listed on the drawing) typically involve a longer time to implement a resolution.
  • Measuring manufacturing difficulty is subjective. Factors such as the need for specialized skill and high capital equipment costs are indicators of potential manufacturing difficulties for all items. Sometimes this is a reason for a source-controlled designation. For structural, mechanical, and electrical items and electronic items, manufacturing difficulty may be associated with unique manufacturing processes and/or demanding requirements, such as extreme tolerances. For materials manufacturing, difficulties may be associated with the presence of hazardous materials or processes, which require special handling; the use of other exotic materials that are not commercially available and with little demand outside this application; demanding requirements (e.g., long shelf life, compatibility with other materials, replacement materials must be the same material, performance outside of normal operating environment); and material that cannot be reliably recycled for use in another form.
  • Other measures of the time to implement axis include a long lead time for requalification, manufacturing cycle time, and/or the lack of tooling or test equipment. For example, shipboard testing may be proposed, which requires scheduling ship availability. The cost to implement a resolution can be an indicator of the time required. Finally, resolutions for defense unique items are likely to require more time to implement.
  • Figure 12 depicts a risk cube illustrating where proactive monitoring of uncategorized items is important. Using this risk cube, if an item is not mission or safety critical, then there will be little operational impact from a DMSMS issue. Resolutions for such items can be developed and implemented without time sensitivity. If the item is critical, but the supply chain is robust, the likelihood of a DMSMS issue is also small, because other suppliers should be able to satisfy demands. Even if the supply chain is not healthy for a critical item, proactive monitoring is only needed when the time to implement a resolution exceeds the length of time covered by the on-hand inventory for that item. A best practice is that a program should only expend resources to proactively monitor those previously uncategorized items that are high risk across all three risk categories (in other words, red/red/red).

Figure 12. Risk Cube for Determining Where Proactive Monitoring of Previously “Uncategorized” Items Is Important

Risk Cube for Determining Where Proactive Monitoring of Previously “Uncategorized” Items Is Important

  • Once a program has determined which of the above considerations within the three risk categories to use, a best practice is to categorize the items that were previously uncategorized based on the application of heuristic algorithms. These items should be evaluated based upon those considerations suitable for evaluation through automated databases. Each consideration should also be assigned a weight. For all items being evaluated, the weights of all considerations should be summed and the items above a predetermined cut-off point should be monitored, while those below that cut-off point should not. Both the weights assigned to the considerations and the cut-off point should be determined by the program, based on its unique needs.
  • Regardless of what level of risk analysis is conducted, a subject matter expert could adjust the classifications, including the “do not monitor” items. This evaluation will take into account risk cube considerations that could not be adequately measured by automated databases, if applicable. There may also be some known vulnerabilities. For example, the technical members of the DMT may be aware of items that are known to be a problem and items with pending environmental or safety regulations that may limit their availability and use in any area of the world where the system operates. As a bottom line, the DMSMS SME and engineering activity representative should understand the associated risk before choosing not to monitor any such items and should revalidate that decision periodically.
  • The entire process described in this section is summarized in Figure 13.

Figure 13. Summary Illustration of Risk-Based Approach for Determining Which Items
and Materials on the BOM to Monitor

Summary Illustration of Risk-Based Approach for Determining Which Items and Materials on the BOM to Monitor

  • The DMT should have an obsolescence management strategy for every item. The program should carry forward the “definitely monitor” and “uncategorized” items that have been determined to be high risk across all three risk categories for availability analysis. The strategy for the “not to monitor” items is to find an alternative when they become obsolete, because ample replacements are available commercially, or to make the necessary preparations should a resolution be required down the road.
  • Once a program has categorized and prioritized the items on its BOMs, the data for these items can be loaded into the program’s predictive tools where appropriate.
4.3.2.2. Software

As part of this second layer of prioritization, a program should also use a risk-based approach to determining where proactive monitoring for software obsolescence makes sense. Table 6 combines the most common types of program-specific software encountered (rows)[53] and the software obsolescence mechanisms (columns) identified in Figure 2. Taking a risk-based approach on what to monitor, however, extends beyond merely what is captured in Table 6. For example, similar to parts, higher priority should be given to software that has a critical impact on the ability of the system to perform its missions. Other risk-based monitoring considerations for software include effect on safety, information assurance, the complexity of interdependence with hardware and other software, and the frequency of updates. A primary driver of obsolescence is the customization of defense system software for specific COTS operating system, middleware, and application software.

Table 6. Framework for Determining the Applicability
of Proactive Software Obsolescence Management

Type of software affected

Software obsolescence mechanisms

Lower order

First order

Hardware changes

Software
requirements changes

Proactive
software
upgrades

Diminished
ability to use software

COTS operating system, middleware, and application softwarea

Not necessary

Not necessary

Not necessary

Applicable

Custom operating system, middleware, and application softwarea

Not necessary

Not necessary

Not necessary

Applicable

Open source operating system,
middleware, and application software

Not necessary

Not necessary

Not necessary

Applicable

Government off-the-shelf operating
system, middleware, and application software

Not necessary

Not necessary

Not necessary

Applicable

COTS firmware

Not necessary

Not necessary

Not necessary

Applicable

Custom firmware

Not necessary

Not necessary

Not necessary

Not necessary

a COTS and custom application software also include interface software that moves, translates, or displays data, for example, custom drivers for printers or middleware interfacing COTS and custom applications.

As the table shows, proactive monitoring in several specific instances is not necessary. Hardware changes are driven by refreshing hardware technology, a hardware resolution, or a hardware requirements change. Software obsolescence is a second-order effect as implementation of hardware resolution/refreshment/requirement changes must take any derivative software changes into account,[54] leaving no additional implications for proactive software obsolescence management. The same argument can be used to eliminate the second and third columns. Implementation of a change in software requirements or technology refreshment would naturally include the consideration and resolution of any resulting software functional obsolescence. Again, there are no implications for proactive software obsolescence management.

  • Software configurations are controlled by freezing content at a version/revision level of detail after adequate testing has been conducted. Particularly with regard to software, once a decision is made on what to monitor, there should be a risk-based determination of which versions or revisions to track, because further refinements (lower-level revisions) may fix only minor errors and not affect functionality or major vulnerabilities.

4.4. Analyze Item Availability

When all of the items are analyzed for obsolescence (as determined via either predictive tool usage or vendor surveys), the magnitude of the program’s immediate and near-term DMSMS issues will begin to surface. These items’ availability status results represent a snapshot in time and, therefore, must be repeated throughout the life of the system, in response to the identification of new obsolescence notices, a vendor survey, or a regularly scheduled update to the predictive tools. If possible, a program should receive daily DMSMS notifications that pertain to the electronics in the program’s systems. Quarterly or annual alerts or vendor surveys may suffice for COTS items but may be too late for electronic items, especially if a program has only 30 days to make a life-of-need buy. Update frequency may also differ for different commodity types, based on the availability of information, the rapidity of the technology’s evolution, and the risk that the item or material poses to the system and mission.

Analyzing item availability should focus on identifying the items in each of the following three categories for further assessment:

  • Items that are no longer available and for which no alternatives are available[55]
  • Items for which discontinuation notices have been issued, but some are still available
  • Items projected to be out of production in the near future (where the time horizon is specified by the program).

The following three sections describe the three methods—predictive tools, vendor surveys, and PDNs—that prompt a refresh of a program’s item availability status for hardware–electronic and MaSME items. The section after that discusses some special considerations for software.

4.4.1. Predictive Tools

Some items (especially electronic parts) are more readily analyzed using predictive tools. In contrast, most predictive tools do not cover MaSME items. Those items covered by predictive tools should, if at all possible, be examined by two predictive tools. If the tools disagree regarding the obsolescence status of an item, then additional manual research is needed to confirm whether or not the item has an immediate or near-term obsolescence issue. If the item does not present an immediate or near-term obsolescence issue, it does not need to be assessed for DMSMS impacts. Even if the predictive tools agree that an obsolescence issue exists with respect to a particular item, a manual check should be done to confirm that finding.

Predictive tools may not provide an industry obsolescence status for some items. This may be due to an incorrect item number, a lack of identifying information, or the way the tool provider collects data. Also, the item may be from a manufacturer that the tool does not query. Some items may not be included in a tool’s database. Items with unknown availability must not lead to a false sense of security. Additional work is needed to determine their availability. It may be that data errors can simply be corrected to enable the predictive tools to forecast item availability. In other cases, manual research may be necessary. For example, the OCM, if known, should be contacted. Otherwise, inquiries should be made down the supply chain until the OCM can be identified and source control drawings can be accessed. If the item number is correct, another predictive tool may be used. Tool providers allow users to submit requests for items to be added to their library of monitored parts. Certain restrictions apply, but providers usually will add catalog item numbers at a subscriber’s request. Subscribers of these tools should take full advantage of this to reduce the amount of research required for future BOM monitoring and receipt of EOL notifications.

During start-up, a program may face a substantial manual research effort to perform an initial cleanup of the data and to confirm the obsolescence-related findings generated by predictive tools. Scoping the types of items to be monitored based upon the application of a second prioritization filter (as described in Section 4.3.2) can assist a program in reducing the level of effort it will need to employ to clean up and manually research such unknowns and verify statuses. Later, once a program’s DMSMS management has entered a steady state, research will need to be conducted only when certain predetermined conditions occur (e.g., item status changes, an item has not been researched in a certain amount of time, changes in sources of alternate items, packaging changes, and periodic revisit of previous “no action required” items).

Predictive tools should be used throughout the life cycle. Early in design, they should be used on notional BOMs or preferred parts lists; both are good sources of items that are likely to be used in production. Early design for new systems is usually based on existing designs being developed by the OEM. The starting point is rarely a predominately blank technical drawing.

4.4.2. Vendor Surveys

Predictive tools may not be able to forecast the availability of some items (such as COTS assemblies and MaSME items). This will also be the case for materials such as alloys, epoxies, glues, tapes, cooling fluids, and adhesives. In these instances, the best way to analyze availability is through vendor surveys, phone calls, e-mails, and vendor websites.

It is helpful to develop a vendor survey questionnaire to manually interact with COTS and hardware–electronic and MaSME items manufacturers and knowledgeable material specialists, establish a database to capture and track the survey information, and determine the frequency to make contact for updates (again, prioritized based on criticality). Contacts for these surveys can be made through phone calls or e-mail communication. A program should be mindful to conduct these surveys in the least burdensome manner possible in order to increase the likelihood of responses. Developing relationships with vendors often improves response time and willingness to participate. Some data can also be collected by reviewing manufacturers’ websites and other web research. This activity is particularly relevant to COTS items; manufacturers will often provide the status for the current item’s planned life cycle, especially when a next-generation version is intended.

The following list provides some examples of vendor survey information and questions that a program can include in its vendor survey questionnaires for electronic items.[56], [57], [58] The types of vendor survey questions suggested here for electronic items are generally applicable to MaSME items, as well; however, additional questions can be added to determine if someone other than the OEM is a likely candidate for providing future support for those items.

  • Product name.
  • Company name.
  • Commercial and government entity code.
  • Part number.
  • Contact information.
  • Is this item currently in production? If no, when did production end? If this product is no longer in production, can the government still purchase it? If yes, how many? When is the last date that the product can be purchased? If currently in production, when do you anticipate end of production?
  • If you are not currently planning an end of production date for this product, please provide an estimate, based on similar products, past history, technology/item obsolescence, and so forth. (Keep in mind that this date is used for supply planning purposes only.)
  • How long after the end of production will the government be able to have this product repaired? What’s the typical cost to repair this item?
  • Once production has been discontinued on the product, how much stock (in time) is typically available for sale? Are there considerations regarding shelf life (may be of particular interest for materials) of which the government should be aware?
  • When this product is discontinued by your company, will you enter into an agreement with an after-market vendor so that customers can still buy the product? If yes (for this product or for other similar ones), please indicate the name of the vendor and give a point of contact.
  • Is there a replacement or a planned upgrade to the product? Is the new item equivalent in terms of form, fit, and function? If so, what is the new product’s part number and cost?
  • What are your technology update plans? What additional capability will the new technologies provide?
  • What warranty does the product have? What is the warranty length and can the length or start time be adjusted to allow for integration and deployment? What extended warrantees are available, and at what cost?
  • What is the list price of the product and its lead-time?

A key step in developing an obsolescence management strategy for MaSME- and COTS-based systems is to compile a list of equipment and items in the system and group them by OCM (for mechanical items) and by OEM (for COTS items). With such a list, the DMT can make one phone call to each OCM and OEM to obtain obsolescence information about numerous items. Another helpful hint for a contractor that has been tasked by the government to survey vendors is to obtain a letter of permission to seek this information from the government and share it with the vendor. With this letter, vendors will likely be more cooperative in sharing information. The program (regardless of whether in-house or contracted out) should decide how often to contact the OCMs and OEMs; the appropriate frequency will depend on the criticality of each system, general life-cycle expectations, and other DMT-determined factors.

It is a best practice to conduct vendor surveys twice per year for electronic items and software, due to the rapid pace of change characterized by the market. For MaSME items, market changes occur much slower. While this might support the argument that vendor surveys could be conducted less frequently for MaSME items, there are several arguments against such an approach. First, conducting different vendor surveys (potentially for the same vendor) at different frequencies could lead to extra work and unnecessary complications for a program’s DMSMS management effort. Second, the marginal cost of conducting more frequent vendor surveys would likely be small, assuming that there are not a very large number of contacts to be made. Finally, material obsolescence caused by changes to environmental regulations or geo-political disruptions in supply can happen very quickly. For this reason, it could be beneficial to be monitoring MaSME items on a more frequent basis. Ultimately, a program should make its own determination on the frequency of vendor surveys for non-electronic items, based on obsolescence risk, resources, and the criticality/safety associated with those items.

4.4.3. Critical Materials Analysis

It is important to be aware that under some circumstances, the above described vendor survey and research approach may not be sufficient. This could be the case if and when the suppliers of the items listed on the BOM are unaware of issues associated with materials within their items’ supply chains. It is because of these instances that the importance of the program’s third strategic decision from the strategic underpinnings section (Section 3.1) is highlighted. This third determination reflects the program’s determination of whether to investigate critical materials in the supply chain (those not identified in a BOM) or in a manufacturing process.

A critical material could be hazardous, exotic, or otherwise be supply constrained. Such a material can either be embedded within an item that is listed on a BOM or required as part of the manufacturing of an item on a BOM. The incorporation of critical materials into a system will usually be done at a low level in the supply chain—a level that is below an item being surveyed or statused by a predictive tool and from a company that may not even know that its product is destined for a DoD system. Potential changes and disruptions at the lower-tier material level may not be immediately apparent and understood when an item is statused (especially for low-demand items) and, consequently, potential DMSMS concerns may not be identified early enough to resolve in a timely or cost-effective manner. For example, a buyout of a key critical material producer may lead to a major impact if there are plans to consolidate production lines. Given examples such as this, knowing whether there are critical materials present in or used in the manufacturing process of a MaSME item in the BOM will improve the analysis of availability of that item or material. The same is true for electronic items analyzed through predictive tools or other vendor surveys.

Programs often do not know which critical materials are in their supply chains. Only minimal information can be learned about imbedded critical materials from TDPs, material safety data sheets, and an item’s technical characteristics. Even if the critical materials in one’s supply chain were known, in nearly all cases, issues with these critical materials will affect multiple programs and systems. It would therefore be inefficient if every program independently conducted research to identify obsolescence concerns for critical materials in its own supply chain and then determined how to mitigate any issues that may be discovered from its own perspective. Such efforts are best accomplished on a centralized basis in coordination with all other stakeholders.

Programs should devote resources to identify material issues in lower-tier suppliers based on their perceived risk. First, a program can identify the set of lower-tier critical materials with which it is concerned; these would be the critical materials that are anticipated to have the greatest potential impact, if there should be an issue obtaining or being able to use a given material. Second, a program can strive to better understand the extent to which issues associated with the lower-tier critical materials in the supply chain may impact monitored item availability.

With regard to identifying the lower-tier critical materials with which to be concerned, a program has two options: (1) create a master list of all critical materials or (2) create a targeted list of critical materials for which the availability of that material can be anticipated to be uncertain because of pending regulatory change or other potential supply disruption. In selecting an approach, a program should keep in mind that hazardous materials (which often represent a large fraction of all critical materials) may fall into one of three categories: (1) their use is prohibited, (2) their use is restricted, or (3) their use is otherwise tracked.

Regardless of which hazardous material category applies, a predictive tool or a vendor survey will accurately capture the obsolescence risk status of an item on a BOM that uses a hazardous material, as long as there have been no recent changes in the categorization of that hazardous material within that item. For example, if the material is prohibited and has been for a period of time, the impact of that material on the items that it is in will already likely be known and those items will most likely be obsolete. In other words, the status of the item will already reflect its hazardous material’s known categorization. If the material is also known to be restricted or tracked, supply chain availability will be understood; there may or may not be DMSMS concerns. Only when the material’s category has recently changed or there is a strong likelihood of a change in the near future would there be a need to conduct further research to ensure that the end item status accurately accounts for these risks.

Consequently, it is sufficient for most programs to create a list of hazardous materials where the availability of that material can be anticipated to be uncertain, where uncertainty does not imply that the material should not be used. A targeted list of hazardous materials should be based on an understanding of and remaining up-to-date on the latest regarding the following:

  • Uncertainties associated with environmental restrictions pertaining to materials. The Chemical and Material Risk Management Program led by DoD’s Environment, Safety, and Occupational Health office scans a variety of sources to identify emerging contaminants—chemicals or materials that either lack human health standards or have an evolving science and regulatory status. When a potential emerging contaminant is first discovered, a risk alert is issued and a screening report is developed to inform a decision on whether that contaminant should be placed on a watch list where a more detailed (phase I) qualitative assessment will be conducted. Based on a phase I assessment, the contaminant is place on an actions list, if it is determined that significant DoD impacts are probable. Inclusion on the actions list signals that an even more detailed (phase II) quantitative assessment will be conducted on the contaminant in order to identify enterprise-wide risk management actions. The materials identified on these action and watch lists can be found at the following link: https://www.usarmy.mil/suite/page/618395.[59]
  • Material vulnerability uncertainties associated with the department’s office defense planning scenarios. DLA’s Strategic Materials Office maintains a Strategic and Critical Materials (SCM) list, which contains such material vulnerabilities. The SCM list is compiled from nominations by DoD components, other parts of the executive branch, Congress, subject matter experts, and other interested parties. Criteria for nomination include evidence of “weak links” in important material supply chains for defense and/or critical civilian applications. The SCM list is used as the basis for studies to recommend possible materials for purchase by the National Defense Stockpile. The Strategic Materials Office produces a report on these studies every 2 years. The studies show that not every entry on the SCM list is a potential shortfall. A shortfall does not imply a peacetime shortage—it only implies a possible shortage associated with DoD reconstituting its losses of that material due to the execution of a planning scenario. Therefore, from a DMSMS perspective, materials of interest could be limited to new additions to DLA’s identified shortfalls. It is, however, possible that there has been a change associated with a material that has already been on the shortfall list. A careful reading should provide some insight into the consistencies and divergence between consecutive years’ reports. It may, however, be imprudent to include all shortfalls. Information on the SCM list and shortfalls is maintained on the DMSMS Knowledge Sharing Portal.[60]

While it will likely be sufficient for most programs to create a targeted list, based on the sources described above, some programs may still judge that all critical materials are of concern. In this case, there are several sources of data that can be used to support this effort:

  • The 2013 National Aerospace Standard (NAS) 411-1, Hazardous Material Target List (HMTL). The HMTL has been developed to support and enhance the management of risks associated with the use of hazardous materials in products and services consistent with NAS 411, Hazardous Materials Management Program, and MIL-STD 882E, Department of Defense Standard Practice: System Safety, in which a Hazardous Materials Management Plan is described as a management task. The HMTL includes prohibited and restricted materials. A consolidated, tracked materials list is under development. NAS 411-1 may be purchased online from the Aerospace Industry Association.
  • DLA’s Strategic and Critical Materials (SCM) List. As described above, DLA’s Strategic Materials Office maintains an SCM list. This office’s website (http://www.strategicmaterials. dla.mil/Materials/Pages/default.aspx) lists materials; however, the latest Strategic and Critical Materials Report on Stockpile Requirements contains a list of materials that DLA’s Strategic and Critical Materials Office has recently studied. Of note, the Strategic and Critical Materials 2015 Report on Stockpile Requirements covers the study of 92 materials.[61]
  • Aerospace Defense Declarable Substance List (ADDSL). The International Aerospace Environmental Group (IAEG), which was formed to address the complexity and variability of environmental requirements in terms of their impact on the aerospace industry, is conducting a material declaration pilot to standardize reporting of chemical substances of interest. The ADDSL has been developed as part of the effort and addresses three types of substances:
    • Substances that are either prohibited from use or have restricted uses in aerospace and defense products based upon “in-force” regulations
    • Substances where the disclosure of their presence in aerospace and defense products is required by “in-force” regulations
    • Substances that are regulated and have the potential to be banned or restricted or to require disclosure.
  • This list can be found at the IAEG Supplier Portal’s “IAEG Aerospace and Defence Declarable Substances List (AD-DSL)” page (www.iaeg.com/workgroups/wg1/addsl/). This web page includes further links to the AD-DSL in both PDF and Excel formats.
  • Registration, Evaluation, Authorisation, and Restriction of Chemicals (REACH). The European Union’s REACH regulation controls uses and imposes reporting requirements for certain hazardous substances in Europe. Regulated substances can be found at the following link: http://ec.europa.eu/growth/sectors/chemicals/reach/index_en.htm.
  • Restriction of Hazardous Substances. European and various other countries have issued RoHS regulations that limit the material content of electronic and electrical equipment. Regulated substances can be found at the following link: http://www.rohsguide.com/.

Regardless of which approach is taken to compile a list of lower-tier critical materials of concern, DMSMS stakeholders should have an opportunity to contribute. Anyone on the DMT, including material and environmental engineers in the program office, may become aware of a potential material-related supply chain issue. Other potential sources include component organizations with material SMEs and/or organizations that conduct industrial base analyses.

A program’s list of critical materials of concern may be shortened over time as a function of what the DMT learns about whether these critical materials are on the program’s system or not. Consequently, there will typically be three classes of materials on a program’s list of critical materials of concern:

  • Those materials that are known to be on the system
  • Those suspected to be on the system
  • Those where their presence on the system remains unknown (this is likely to be the most prevalent class, particularly at the beginning of a program’s DMSMS management effort).

Figure 14 illustrates the first step of a proactive approach for issue identification for critical materials in the lower tier of the supply chain. This first step focuses on selecting those materials that will serve as the critical materials of concern for the program.

Figure 14. Select the Critical Materials of Concern for the Program

Select the Critical Materials of Concern for the Program


For items in the BOM, robust DMSMS management seeks to be proactive in problem identification to discover potential issues well before they materialize. This maximizes the time available to implement a resolution and thereby both increases the likelihood of finding an inexpensive resolution and minimizes any ill effects on schedule and readiness. From this perspective, once a program has identified the critical materials of interest, the next set of activities should follow a risk-based, proactive problem identification path to highlight “the unknown unknowns” of critical materials’ impact on item availability.

A typical proactive approach using predictive tools and vendor surveys and research would not normally be used to better understand the extent to which critical materials issues in the supply chain may impact monitored item availability. Such an approach to problem identification is very labor intensive and the data do not indicate that the DMSMS risks and potential impacts are severe enough to justify the investment needed to be proactive in that way.[62] Even if the government DMT were able to identify and contact lower-tier vendors, these contacts may not generate a complete response as the government will be seeking proprietary information that the company is unlikely to share unless it is in the company’s best interest to do so (e.g., the company wants government help to solve the problem).

In the absence of any exacerbating circumstances indicating high risk, the most cost-effective DMT approach for risk-based, proactive problem identification for lower-tier critical materials (and materials used in manufacturing processes) is to encourage and engage in communications among key critical material stakeholders to share tacit knowledge on the subject.[63] Considerations regarding how these types of communications can be fostered include the following:

  • Establishing an agenda item for critical material supply chain issues for every DMT meeting. This will engage the prime contractor and any OEMs on the DMT. These DMT members may be aware of some critical materials in the supply chain, as well as potential issues with these materials because of any chemical profiling they are performing on their products. Such chemical profiling may be due to regulations or because it has been determined important for them to do this from a business perspective (e.g., sales may otherwise be affected). Furthermore, primes and OEMs have the most detailed engineering understanding of the items on the system. Therefore, they will play an important role in determining a resolution, should that be necessary. A DMT agenda item will also engage the organic depots involved in sustainment. Although the depots may not normally have a representative on the DMT (Section 3.3.1 lists them as ad-hoc members), someone on the DMT will be in the position to communicate with them. This is an important avenue of communication because there is a supply chain associated with depot activities and, consequently, the depots may be aware of the presence of critical materials in the system and critical materials issues analogous to those known by the primes and OEMs. Depots may even be in a position to query their supply chains about issues.
  • Engaging with other stakeholders in preparation for a DMT discussion. Other stakeholders to engage include the following:
    • DLA’s Strategic and Critical Materials Office. This office can be contacted through its website (https://www.strategicmaterials.dla.mil/Pages/default.aspx).
    • The Office of the Secretary of Defense’s Manufacturing and Industrial Base Policy Office. This office has three functions that are applicable to materials. First, its manufacturing technology (ManTech) program anticipates and closes gaps in manufacturing capabilities for affordable, timely, and low risk development, production, and sustainment of defense systems. Second, its Title III office ensures that industrial base capabilities meet current and future national security needs. Finally, its assessments office gathers industrial base data, maps supplier relationships, and evaluates capabilities to deliver systems and services. There is a material sector lead position in the office that supports these functions. This office can be contacted by phone or by e-mail at osd.pentagon.ousd-atl.mbx.mipb@mail.mil.
    • Chemical and Material Risk Management Program. This program produces environmental risk alerts, which are maintained by the DoD Environment, Safety, and Occupational Health Network and Information Exchange (https://www.denix.osd. mil/cmrmd). A newsletter on emerging environmental issues can be subscribed to at the following link: https://www.ecportalinfo.org/distlist_new.aspx. Quarterly webinars are held to communicate emerging issues. A request to be on the distribution list for these webinars or to communicate on issues of concern can be made through the following e-mail address: osd.pentagon.ousd-atl.mbx.cmrmp@ mail.mil.
    • Major OEMs in the supply chain. This would apply particularly in the case of those OEMs who are not already represented on the DMT but who may be profiling chemicals on their own products.
    • Material engineers in the program office.
    • Environmental engineers in the program office. As part of the program office’s programmatic environment, safety, and occupation health evaluation (PESHE) requirements, hazardous materials, waste, and pollutants on the system must be identified.[64] Environmental engineers may also be briefed periodically on regulatory changes that might affect the program.
    • Organizations that conduct materials research or perform industrial base sector analysis, and/or cross-cutting materials subject matter experts for the components.

Figure 15 illustrates the second step of the proactive approach for issue identification for critical materials in the lower tier of the supply chain, as described above. This step focuses on assembling the materials-related stakeholder knowledge and experience as part of DMT meetings in order to be able to raise materials-related red flags, as necessary, to help mitigate against being caught off guard.

Figure 15. Engagement to Identify Potential DMSMS Issues
Associated with Critical Materials

Engagement to Identify Potential DMSMS Issues Associated with Critical Materials

The rationale for these engagements focused on critical materials includes the following:

  • Encourage all stakeholders to keep their ears open—primes and OEMs may be encouraged to more proactively monitor their supply chains
  • Learn the potential issues others are aware of and what they are concerned about
  • Learn what is being done
  • Learn what conversations are taking place
  • Actively share all information among the stakeholders
  • Ultimately put the stakeholders in a position to anticipate changes in regulations and other market-driven disruptions to the critical materials supply chain.

Once a potential problem is discovered, these engagements will force a conversation on what to do about the problem. A resolution that develops a drop-in replacement that is compliant and meets performance specifications is highly desirable. One of the stakeholders may be willing to take the lead in researching the issue and recommending a course of action. There may be circumstances where the prime and an OEM agree to resolve the problem because there is a clear business case for that to happen—this is most likely to occur when the material is included via a company-owned specification or drawing.

By engaging high-level organizations, a DoD-wide initiative may be established. Some DMT research may be warranted, but in most cases this would not occur until other options have been pursued. Regardless of who does the research, some potential data sources are as follows:

  • Industry associations.
  • Organizations that track both recent and pending domestic and international regulation changes. In addition to the aforementioned Office of the Secretary of Defense (OSD) Materials of Evolving Regulatory Interest Team, the National Aeronautics and Space Administration has established a Center for Regulatory Risk Analysis and Communication, which issues a regulatory training summary twice per month.[65]
  • REACH, RoHS, and conflict minerals data associated with items.
  • Other technical data, for example, annotations on drawings may lead to educated guesses about tracking or identifying critical material suppliers.
  • Full material disclosures published on company websites.
  • OEM contractual deliverables indicating potential DMSMS issues and supply issues.

Just as proactive DMSMS monitoring should begin by the time of the program’s PDR, so should these engagements and chemical profiling activities. They may lead to a design change if substances are included where there is a concern about anticipated regulation. Also, they help establish a baseline of understanding critical material content and issues during sustainment.

4.4.4. Product Discontinuation Notices

The DMSMS management program should receive automated industry obsolescence notices and DMSMS alerts from the selected predictive tools, the Government-Industry Data Exchange Program (GIDEP), and DLA. Although overlaps will occur, all three sources should be used to maximize completeness and timeliness and any PDNs received should be validated before any action is taken. In addition, the DMT should query manufacturers’ websites, build relationships with OCMs (similar to the vendor survey relationships), and access other federal supply sources and free government tools to identify data and notifications on item availability (see the DKSP for more information). The remainder of this subsection focuses on alerts and external triggers for item availability analysis updates from GIDEP and DLA.

4.4.4.1. GIDEP

A DMSMS management program should become a GIDEP member early in its life cycle and a member of the DMT should become trained in its usage. GIDEP is a cooperative activity between government and industry participants seeking to reduce or eliminate expenditures of resources by sharing essential technical information during the research, design, development, production, and operational phases of the life cycle of systems, facilities, and equipment. For complete requirements, and to become a member, see the GIDEP website (www.gidep.org).

GIDEP is a useful tool to support monitoring and surveillance, because it has developed a part batch search routine that permits GIDEP participants to send and compare part lists to the part identifiers in the GIDEP database. Part lists are protected so that only GIDEP operations center personnel have access. Batch processing is available only to registered GIDEP participants.

Also, as a GIDEP member, a program can get “push mail,” which is generated, as a convenience, to provide GIDEP participants with an overview of information without having to access the database. If a part or title in the list is of interest, the corresponding document can be retrieved through direct database access. All GIDEP representatives are automatically eligible to receive push mail. Users may also be granted access with their representative’s approval. Representatives can either access the push mail registration online to update their profile or to assign distribution to their users. Once users have been granted access to push mail, they can update and change their own distribution or e-mail online. As part of push mail, members can receive weekly summaries that list documents committed to the database during the week cited. The list includes the document number, date, designator, title, and abstract.

Members can also request parts lists that represent all part identifiers (manufacturer, government, specification, drawing, model, base, and national stock numbers) either contained within or cross-referenced to all documents entered into the GIDEP database during the week cited. This allows a program to check its parts against the GIDEP-generated weekly parts list without having to create reports itself. A program may then enter the database to retrieve only those documents of interest to the program.

GIDEP can also provide support when developing resolution options for a DMSMS issue. The GIDEP Urgent Data Request (UDR) is a service available to any authorized GIDEP user as well as the public. The service enables the user to enter two types of queries—a source of supply and a request for information.

  • A source of supply request is a mechanism for locating hard to find or obsolete items that are no longer available through traditional sources. The item may be an entire assembly or a material used in its manufacture. If multiple sources of supply are found, the user can select the most cost-effective supplier. Significant time savings to resolve an issue are achievable if any source of supply is found. If no source of supply can be found, the query may lead to potential new production sources.
  • A request for information may help an activity with resolutions to an obsolescence problem by finding technical or experiential data or other information that apply to the issue. For example, the request for information may ask for test, calibration, design, maintenance, or failure data. Having such data may help determine the viability of a substitute part.

In summary, GIDEP does not have the ability to predict which parts will become obsolete, but it can provide a program with a no-cost means to find out which parts of interest already have discontinuation notices against them. Programs can also use GIDEP’s batch processing as a way to ensure that the program will receive discontinuance notices that match system parts and also may provide the ability to assist with identifying unmatched parts.

4.4.4.2. Defense Logistics Agency

DLA (www.dla.mil) also provides PDN alerts to subscribers—including military services, government agencies, FMS customers, and industry (with .mil e-mail accounts and common access card capability)—through its shared data warehouse.[66], [67] These DLA-generated alerts contain information not available through GIDEP, such as DLA usage and weapon system coding. For DLA-managed items, additional analyses are done to determine resolution options ranging from requesting users to determine quantities for life-of-need buys to examining options to emulate microcircuits using its Generalized Emulation of Microcircuits (GEM) and Advanced Microcircuit Emulation (AME) programs.[68]

Access to DLA’s websites allows a program to search the following:

  • Qualified Manufacturers Lists (QMLs)/Qualified Products Lists (QPLs). The data provided in this search are updated as changes occur and may contain information not reflected in the hard-copy version. A program’s search will always return the latest information available at that time. QMLs/QPLs are also available in the ASSIST Qualified Products Database. DLA updates the lists as necessary and is charged with requalifying vendors every 2 years.
  • Standard microcircuit cross-reference. This search provides a cross-reference of microcircuits covered by standard microcircuit drawings, MIL-M-38510 specifications, and vendor item drawings. If a program prefers to use the cross-reference data on a local computer, a standard microcircuit lookup table can be downloaded.
  • Military specifications (MilSpecs) and drawings. This website provides courtesy copies of documents managed at DLA. If a program cannot find a document here, it may not be managed at DLA. For a complete list of all DoD MilSpecs, refer to DLA’s document automation and production service.
  • Standard microcircuit drawings. A list of standard microcircuit drawings is available to download.

4.4.5. Special Considerations for Software

The following discusses proactive software obsolescence management considerations associated with a diminished ability to use software for each of the rows of Table 6. Proactive management should be done as a function of the specific program’s strategic priorities and software risks (including the health of the software vendor).

4.4.5.1. COTS Operating System, Middleware, and Application System

The use of COTS software is increasing. It is often less expensive and quicker to integrate a COTS software product than to develop a custom product. COTS software may be monitored primarily by keeping track of licenses and support agreements,[69] analyzing technology and product roadmaps and projected new release information, participating in user groups,[70] tracking new interface standards, and conducting vendor surveys of the rapidly changing market to evaluate competitive products as a future replacement option.[71] Just as qualified sources for hardware items should be identified, so should qualified sources of support for each element of software. Potential software vendor survey questions are as follows:

  • What is the basis for changing version/revision levels? Are they updated regularly, and when?
  • How are patches and updates announced? How are they distributed?
  • What is the current version/revision of the software?
  • When was this product first available for sale?
  • Has {your version/revision} been discontinued?
  • How long will license agreements for {your version/revision} be obtainable?
  • Will license downgrades be available? For how long?
  • How long will you support {your version/revision}?
  • Will third-party support be available after that? For how long?
  • What is the planned product EOL?
  • Is there a planned replacement product?
  • Is the planned replacement backward-compatible?
  • What are the different technical characteristics between the old and new version?
  • What operating systems are compatible with the software?
  • What are the minimum hardware requirements (if any), for example, processor speed, communications interfaces, or memory?
  • Another aspect of proactive obsolescence management for COTS software is information assurance. DoD security bulletins may also be monitored.
4.4.5.2. Custom Operating System, Middleware, and Application Software

Because licenses do not usually apply to custom applications, the key information that can be tracked is viable continuation of support when there are both contractual and in-house elements. Surveys may not be the best mechanisms to obtain information. Program office sustainment personnel may be in a good position to identify potential software obsolescence risks. Key questions for consideration are as follows:

  • What is the current version/revision of the software?
  • Do you still have the ability to modify the software?
  • Is the source code repository maintained?
  • Are the development tools maintained?
  • Are there any third-party items?
  • Are you able to compile those third-party items?
  • What is the planned product EOL?
  • What is the planned product end of support?
  • Will third-party support be available after that? For how long?
  • Is there a replacement product?
  • Is the planned replacement backward-compatible?
  • What development and testing hardware and software infrastructure are needed to maintain the software?
4.4.5.3. Open Source Operating System, Middleware, and Application Software

If open source software is used, the government and/or OEM should assume configuration control for the source code. An analogy can be made to custom software, but there are differences. The expertise for making changes is likely to be found in the open source community, not with the OEM. Consequently, proactive software obsolescence management may consider monitoring changes made to the open source version (often found in the website), because using the newer version of the software may be necessary to support changes to the older code being used by the government. Licensing may not be an issue but the terms and conditions for using the open source software should be reviewed by a legal team because, for example, there may be a requirement to provide any modifications to the entire open source community.

4.4.5.4. GOTS Operating System, Middleware, and Application Software

Government off-the-shelf (GOTS) software is a subset of COTS software; therefore, the same considerations may apply. Licensing is unlikely to be an issue. The vendor survey would be conducted with the appropriate government entity.

4.4.5.5. COTS Firmware

Product changes that only upgrade COTS firmware may impact the system. When buying items, the program may not realize that firmware changes have been made and that those changes may not be fully compatible with the rest of the system even though there is no issue with the hardware in which it is embedded. In this situation, the item is a functional group—a combination of hardware and software. The item becomes obsolete when either the hardware or the firmware becomes obsolete in a way that affects the system.

COTS firmware changes may be tracked by monitoring the item itself as a functional group. If the hardware item is tracked through vendor surveys, a question about the firmware version or revision should be included. If the hardware item is monitored with a predictive tool, depending on the risk to the system, it may be important to include that hardware item in a vendor survey. Potential questions include the following:

  • What is the current version of the firmware?
  • Is it still in production?
  • When was it last updated? What was the reason for the update?
  • When is the next scheduled update? What is the reason for the update?
  • What is the estimated remaining market life?
  • How are updates announced and how are they distributed?
  • How many years of maintenance will be offered for the older version?

The need to use specific firmware to avoid a critical impact to the system should be documented; for example, the requirement may be identified in an engineering drawing.

4.4.5.6. Custom Firmware

There are no obvious considerations for proactive software obsolescence management because the program should be aware of changes to the firmware it controls. Therefore, there is no need to monitor such firmware.

4.5. Collect and Update Programmatic and Logistics Data

Programmatic and logistics data, along with the results of the items availability analysis, support the DMSMS impact assessment process and, ultimately, resolution determination. The data should be refreshed regularly (as changes are made to the systems being monitored) to ensure that the most up-to-date data are used for DMSMS impact assessments and program decision making. In some cases, the data may be updated with the receipt of EOL notices for an item or set of system items or with the update of predictive tools or vendor surveys.

The data collection process differs slightly as a function of acquisition phase. Early in the design phase, item data may be notional and based on a preferred parts list. Programmatic data may have less certainty early in a program. Predicted reliability data should be used until better data can be derived from operational use. Actual logistics data will be available only during sustainment.

Logistics and programmatic data may be acquired from the program office, logistics databases, item managers, OEMs, and depots (contractor and organic). Of note, the services and DLA can obtain this type of information from their own logistics tools and databases. Those data enable the DMSMS management program to consider thorough DMSMS impact assessment, whether or not the obsolescence issues discovered affect the system and program negatively, when that impact may occur, and which mitigation resolution is most feasible and cost-effective.

The following are among the types of programmatic data a DMSMS management program may consider collecting (applies to hardware and software):

  • Life-cycle phase
  • Planned technology insertions/refreshments
  • Planned end of system life
  • Planned number of systems
  • Planned operating hours per system.

Actual logistics data may be available only if a system has already entered the sustainment phase. Logistics data, however, should be considered a factor in DMSMS impact assessment from earlier phases in the life cycle, based upon predicted reliability data. Below are some examples of the types of logistics data a DMSMS management program should seek to collect (applies to hardware):

  • Average demand
  • On hand
  • Due in/due out
  • Procurement lead-time
  • Repair philosophy
  • Cost
  • Back-orders and how long items have been back-ordered
  • Unserviceable
  • Measure of reliability.

The existence of logistics data for the system should enable the program to identify those items, assemblies, and units of the system that present potential sustainment issues and those that do not. Those data can then be compared to the items’ availability analysis results during impact assessment to determine the risk presented by a particular obsolescence issue.

4.6. Develop Health Assessments

Early in a program, particularly during design, a “quick-look” health assessment should be generated based upon a review of a preliminary parts list to identify potential obsolescence issues; however, as the BOMs for the system design mature, more detailed health assessments should be generated. A quick-look health assessment enables a program to obtain a high-level snapshot regarding the obsolescence health of its system design. This less-detailed assessment might be of particular use during early phases of the life cycle and/or during the early stages of DMSMS management, when the system design may still be in flux and a complete parts list or BOM data are not yet available. However, a quick-look assessment might also be useful at other times during the system life cycle, serving as an executive summary to a more detailed health assessment.

Ideally, the quick-look health assessments should be aligned to coincide with the major technical design reviews or design changes. Their delivery should be made prior to such design reviews in order to identify ahead of time and, ideally, help to prevent the incorporation of an obsolete or near-obsolete item into a design. This could be either an obsolete item itself (e.g., a die) or its packaging. “Quick-look” assessments should not, however, be restricted to supporting the design reviews. They should be conducted whenever new parts lists are received.

Table 7 is a sample template for organizing information for a quick-look health assessment. Each program should tailor the information and format of such an assessment to best suit its needs. The key is for the assessment to highlight risk in terms of its impact on cost, schedule, and performance, as well as to ensure that mitigation actions are being planned and implemented.

The first two rows of Table 7 are especially important early in the life cycle. They give an indication of the status of two key enablers of robust DMSMS management. The next two rows measure the scope of the DMSMS effort underway relative to where it should be from a risk-based perspective. Finally, the last three rows portray a high-level view of the extent of obsolescence in the system.

Table 7. Sample Template for a Quick-Look Analysis of Designs for Obsolescence Risk

Risk area

Value

Impact (high, medium, low)

Red/yellow/
green

Cost

Schedule

Performance

Early preparation

DMP adequate and appropriately funded (as judged by
logistics and reliability) throughout the supply chain

Not
applicable

Technology roadmap in place and integrated into DMSMS management process, and vice versa

Not
applicable

Ability to monitor

Percentage of critical BOMs/parts lists available (i.e., a risk-informed decision has been made to monitor)

Percentage of available
critical BOMs/parts lists
being monitored

Item obsolescence

Percentage/number of items obsolete (or with EOL notice)

Percentage/number of items at high risk (custom items, ASICs, hybrids, sole source, etc.)

Number of obsolescence cases open, closed, and pending (i.e., no assessment has occurred to determine whether to open a case)

“Detailed” health assessments (sometimes referred to as “tombstone” charts or sustainability analysis) should begin when the design becomes mature. They should be conducted regularly (at the culmination of each iteration of the recurring processes of the identify step) through the remainder of system development, production, and sustainment. Detailed health assessments document the estimated obsolescence dates, usage rates, and stocks on hand or items due in to identify when an item or assembly will no longer be supportable. These assessments should also show the projected time frames for potential software obsolescence risk (including license and maintenance) for all of the monitored software. They provide key information needed to assess whether to open a DMSMS case. Detailed assessments are discussed in Section 5.

For a program to ensure that health assessments are provided periodically for review, it might need to include this requirement in its requests for proposals (RFPs). The requirement should likewise be applied throughout the supply chain. For the PDR and CDR, the program could require a contractor to identify and address any current and forecasted obsolescence risk pertaining to critical items within the design. This would include an analysis of any planned reuse of an existing design. After CDR, the program should regularly update and report on the risk assessment and obsolescence forecast for the design.

5. Assess: DMSMS Impact Assessment

An old logistician’s proverb—which begins with “for want of a nail the (horse) shoe was lost” and ends with the kingdom being lost, “all for want of a nail”—illustrates that the lowest-level item in a system’s hierarchy can affect the entire system. Consequently, the Assess step of the DMSMS management program examines the potential effects that a DMSMS issue, at any level of a system, may have on cost, schedule, availability, and readiness. Most DMSMS issues result in a combination of these effects and, ultimately, all if left unaddressed:

  • Cost impacts may be experienced in any stage of the life cycle. The impact is measured as (1) the additional cost that must be paid to resolve the issue, (2) the change in support costs (it will cost the program less if reliability is improved), and (3) the difference in the cost of items before and after resolution. This third element of cost may be positive or negative, depending on the resolution pursued. If a more expensive alternative item is used, then the cost will be higher.
  • Schedule impacts are usually associated with the design or production elements of the life cycle, because obsolescence may delay design or production activities.
  • Availability and readiness impacts normally occur during sustainment. DMSMS issues may affect the mission capability of a system, or they may prevent the system from being used altogether.

The purpose of the impact assessment is to answer three questions:

  • Should a resolution to the problem be pursued? Or, should a case be opened?
  • Which problem should be addressed first?
  • At what level should a resolution be applied?

Figure 16 summarizes the DMSMS management activities leading up to the Assess step. As the figure shows, an impact assessment may be initiated for the following reasons:

  • The results of predictive tools or vendor surveys indicate a problem.
  • The program receives a PDN.
  • A change occurs in a health assessment because of an increase in demand for obsolete items in inventory.

At this point in the DMSMS management process, data have been collected to help provide answers to the above three questions. The remainder of this section describes the specifics of the data and analysis needed to determine the impact of the shortages. As a best practice, as much data as possible should be gathered to increase the rigor of the analysis. However, in many cases, some of the data may not be available. The DMT should do the best job possible with the data it has. When the DMT uses assumptions to compensate for missing data, the results of the analysis will be subject to greater uncertainty.

Figure 16. Initiation of the Assessment Step

Initiation of the Assessment Step

5.1. Identify Data Needs

Every program is unique, and the criteria established for assessing DMSMS risk are specific to the program’s priorities. Regardless of the approach to the overall assessment, four types of data are needed: programmatic, availability, criticality, and logistics.

5.1.1. Programmatic Data

Below are the different types of programmatic data needed for an impact assessment:

  • Life-cycle phase. If the program is in the design or production phase, the overall life-cycle risk is significant, and emphasis on obsolescence issues at this point will have a significant impact on the total ownership cost of the program. However, an obsolescence issue discovered in the sustainment phase may not be as significant if the program is scheduled for disposal or if the replacement system is ready to be fielded. Industry tends to be interested in collaborating with DoD to solve an obsolescence issue during the design and production phases of acquisition; however, such collaboration can be difficult once the production line has gone cold.
  • Planned technology insertions or refreshments for the subject item/assembly/software element and the next higher unit. This information is important for an obsolescence issue at any point in the life cycle, because it presents an opportunity to eliminate the requirement for the problem item. It is important to understand whether the planned technology insertion or refreshment is funded. If no resources are programmed, then technology insertion or refreshment is unlikely to occur. It is also important to understand that DMSMS management is not the driver of technology insertion or refreshment. DMSMS management simply leverages this information to determine risk and, where appropriate, to recommend a resolution option. However, DMSMS issues can affect the technology refreshment’s scope and schedule, both positively and negatively, after they are initially established.
  • Planned end of system life. EOL data are used for inventory-related calculations. If the system is in design or production, the system EOL may not be known. Even during sustainment, the EOL may be uncertain, because of unplanned service life extensions, which in turn affect inventory requirements and may have potential DMSMS impacts. If the service life is extended, DMSMS situations with no operational impact before the extension may have a significant operational impact because of the extension. Nevertheless, the only approach is to base DMSMS impact assessments on official plans.
  • Number of systems in use over time through the end of system life. This number is used for inventory-related calculations. If the system is in design or production, only near-term numbers may be available.
  • Planned average operating hours per system. This number is used to help calculate demand for the item. If the system is in design or production, future average operating hours may not be available. In that case, it may be possible to make estimates based upon historical data of similar systems. The duty cycle must also be taken into account.

5.1.2. Availability Data

Availability data are needed at the item, assembly, and unit levels. For software elements, the program should track licenses, end-of-support dates, and frequency of updates. Availability should be identified at the lowest level possible, with an assessment of the impact at the next higher levels to better understand the risk and to help identify the most efficient cost resolution option. The DMT should differentiate between items that are currently unavailable and items forecasted to be obsolete in the near term (within 2 or 3 years). If authorized substitutes are available, there is no current obsolescence risk.

5.1.3. Criticality Data

Like availability data, criticality data are needed at the item, assembly, and unit levels. The first process in the Identify step (Section 4) is to prioritize systems according to their mission criticality and safety-related features. Those same criticality factors apply in impact assessments. Furthermore, item (hardware and software) criticality is often determined by the criticality of its function. Examples of items with critical functions are microprocessors, microcontrollers, memory, ASICs, and field-programmable gate arrays. Finally, the cost of the item is a criticality factor.

5.1.4. Logistics Data

Programs managed and repaired organically can have access to logistics data, assuming the data are captured and archived. Each military service has a logistics management system and item managers who have access to and understand logistics data. The contractor will have the data for programs that employ contractor logistics support; the government should arrange to have access to this information via contract requirements and deliverables. The following are examples of logistics data:

  • Demand for the items, assemblies, and units with DMSMS issues. This applies primarily to items in sustainment, unless the same items are used in the same way on other systems in the inventory.
  • Reliability of the items, assemblies, and units with DMSMS issues. This should be the same as the demand data for items in sustainment. When in design or production, when no demand data have been collected, the manufacturer’s stated reliability may be used, but it introduces more uncertainty into the impact assessment.
  • Inventory for the items, assemblies, and units with DMSMS issues. Inventory may be found in the service depot (either contractor or organic), production facility, and DLA facilities. The portion of the inventories should be identified for the system in question versus that for other platforms. Data on inventory due in, backlogged orders, and the length of time on back-order are also relevant. If the system is in design or production, inventory is most likely available from contractors.
  • Maintenance philosophy for the items, assemblies, and units with DMSMS issues. Some items may be repairable, while other items may be disposed of when they fail. The availability of or the development of a source of repair can reduce the risk that all of these elements must be investigated.
  • Repair history. It may prove useful to know how often the item is repaired: rarely or frequently.
  • Survival rates. This represents the fraction of time repair is economically feasible.

5.2. Assess Impact of a DMSMS Issue

Understanding the overall risk of an obsolescence issue depends on understanding when the issue will affect the system. This can be accomplished only through an understanding of the logistics position of the items within the system. An analysis of the logistics and programmatic data provides a snapshot in time of current inventory levels and usage rates in order to identify the time frame available (sometimes referred to as days of supply) to identify and implement a resolution. The ability to develop a resolution—within the time frame of availability levels and while a replacement item is available—is directly related to the risk of experiencing some negative impact as a result of a DMSMS issue.

To determine the potential for a future shortage of a particular item, the DMT must estimate the future demand for the item and determine whether the existing stocks (including items due in and items on back-order) will meet that demand. Mathematical methods, accepted by the logistics community, are available for calculating future demand.[72] These models may need to be applied to the NHA. If the subject item will be removed from the system by a planned technology insertion, then the period of requirement ends when the item is replaced.

Once the demand is established for the period required, the DMT can simply subtract the demand from the available stock to determine if and when the shortage will affect the system. Estimating the future demand for items is risky, due primarily to two key assumptions that must be made: projected future operational hours and reliability. The relative risk varies from decision to decision, but it is real and should be expressed to higher level decision makers when proposing resolutions. The risk introduced by assumptions is always higher before a system is deployed, because no reliability data based on actual operations are available.

The detailed health assessments introduced in Section 4 display obsolescence data to support assessing the impact of DMSMS issues. They offer a program a more comprehensive accounting of its specific obsolescence issues, both existing issues and issues anticipated to appear within a specific period of time. These assessments are usually organized by individual subsystem.

A detailed health assessment breaks out individual items, documenting, by year, the starting quantity balance, predicted/actual usage, and ending quantity balance of that item over a certain time frame, say 10 years. This information enables a program to identify when to address a given DMSMS issue. Being able to look across items may also suggest ideal timing for addressing a set of DMSMS issues within a particular subsystem. A program can consider how mission capability and readiness would be affected if the identified DMSMS issues pertaining to a particular item or set of items across a subsystem or COTS assembly are not resolved before a certain date. For example, the assessment could be used to determine a cost-effective time to consider DMSMS resolutions at a higher level of assembly than the obsolete item.

Table 8 is a simplified example of the type of format that could be used for reporting the results of a detailed health assessment. Programs should tailor the content and format of their detailed health assessments to best meet their specific needs. Below are some potential enhancements:

  • Include rows for both obsolete and obsolescent items.
  • Include due-ins from prior orders.
  • Include planned procurements of items that are not yet obsolete.

Table 8. Example Template for a Detailed Health Assessment Report of a System

Item no.

Item
type

Sub-system

Status characteristics

FYx

FYx
+1

FYx
+2

FYx
+3

FYx
+4

FYx
+5

FYx
+6

FYx
+7

FYx
+8

FYx
+9

123

Micro-processor

1

Starting balance

4

3

2

0

−1

−2

−3

−5

−6

−7

Predicted/actual usage

1

1

2

1

1

1

2

1

1

1

Ending balance

3

2

0

−1

−2

−3

−5

−6

−7

−8

456

Amplifier

1

Starting balance

135

122

108

92

75

55

33

8

−18

−44

Predicted/actual usage

13

14

16

17

20

22

25

26

26

26

Ending balance

122

108

92

75

55

33

8

−18

−44

−70

789

Touch screen

2

Starting balance

16

15

14

13

11

10

9

8

7

5

Predicted/actual usage

1

1

1

2

1

1

1

1

2

1

Ending balance

15

14

13

11

10

9

8

7

5

4

211

Motherboard

2

Starting balance

12

10

7

4

2

−1

−4

−7

−9

−12

Predicted/actual usage

2

3

3

2

3

3

3

2

3

3

Ending balance

10

7

4

2

−1

−4

−7

−9

−12

−15

222

Graphics CCA

2

Starting balance

11

11

11

11

11

10

10

10

10

10

Predicted/actual usage

0

0

0

0

1

0

0

0

0

0

Ending balance

11

11

11

11

10

10

10

10

10

10

233

Ethernet interface

2

Starting balance

18

14

11

7

3

−1

−5

−9

−13

−17

Predicted/actual usage

4

3

4

4

4

4

4

4

4

4

Ending balance

14

11

7

3

−1

−5

−9

−13

−17

−21

244

Serial I/O CCA

2

Starting balance

2

−38

−83

−128

−173

−218

−263

−308

−353

−398

Predicted/actual usage

40

45

45

45

45

45

45

45

45

45

Ending balance

−38

−83

−128

−173

−218

−263

−308

−353

−398

−443

255

Notebook computer

2

Starting balance

11

10

9

7

6

5

4

2

1

0

Predicted/actual usage

1

1

1

1

1

1

2

1

1

1

Ending balance

10

9

7

6

5

4

2

1

0

−1

Legend:

Sufficient assets to support more than 5 years

Sufficient assets to support next 5 years

Zero quantity reached within 4 years

Zero quantity reached within 3 years

Insufficient assets (0 or negative)

As described above, detailed health assessments identify current and future DMSMS issues. This information should be provided to the appropriate technology road-mapping community to develop or update technology refreshment/insertion plans. After the plans are established and decisions are made concerning their implementation, they should be a consideration in the Assess step. Detailed health assessments and technology refreshment/insertion plans provide key information for answering the three impact assessment questions. These questions apply only to first-order software obsolescence under the assumption that derivative obsolescence will be resolved as part of the changes implemented from hardware changes, requirements changes, and technology upgrades.

5.2.1. Should a Resolution to the Problem Be Pursued?

Just because a predictive tool indicates that a particular item is obsolete, or anticipated to be obsolete by a particular date, does not automatically translate into a DMSMS issue for which a program should pursue a resolution. A program will want to first validate the risk by examining when the item will no longer be available, the stocks on hand for the item, and the expected time to implement a resolution. The factoring in of the time to implement a resolution may be of particular importance when addressing a MaSME item. For example, there may be instances where an item, perhaps particularly a MaSME item, is not yet obsolete, but the time to realize a resolution would be very long. Depending on the exact facts of the situation, it may be worthwhile for the program to either increase its on-hand inventory or take an action that would reduce the time to resolve the issue should it arise.

One way to answer this question is to identify when a resolution should not be pursued. Clearly, no resolution is needed if enough items are on hand to meet all future demands. However, because the level of “all future demands” is never certain, the level of risk should be considered, as illustrated in these situations:

  • Situation 1. If the system is in sustainment and there have never been demands for the item facing a DMSMS issue, then there is a low risk for not pursuing a resolution.
  • Situation 2. If the system is in sustainment and calculations show that enough inventory of the item is on hand to last until the system is retired or until a technology refreshment replaces the item, then the risk of not pursuing a resolution is low, but it should be evaluated further. For instance, a program should also keep in mind that the item inventory available may not be held for a particular program; therefore, inventory levels should be monitored periodically. Reliability data are an extremely useful input in the assessment of risk at any level in the configuration: the higher the reliability, the greater the availability of the item and, therefore, the lower the risk of an obsolescence impact. For example, if a circuit card assembly seldom has to be replaced or repaired (highly reliable), obsolescence issues at the item level will not be as high risk as an obsolescence issue on a card that is continually being repaired or replaced. This information, if available, should be used in the overall assessment. If the EOL date for the item is uncertain and the item is in high demand, a best practice is to keep it on the list of problems to be addressed, but with low priority. Conversely, for items with a known EOL date and low-demand items, the risk of not pursuing a resolution is relatively low.
  • Situation 3. The risk of not pursuing a resolution could be considered low if there are reclamation opportunities to recover a sufficient quantity of the item to satisfy the projected demand for that item.
  • Situation 4. While a system is in the design or production phase, a constant supply of items is usually required. The rare exception is when there is a high degree of confidence that all items needed for production and sustainment have already been procured. The uncertainty of such an analysis would be enormous.
  • As illustrated through the situations above, when hardware–electronic and MaSME items become obsolete, there may be stockpiles that last for a while. A resolution may not be needed at all, depending on the days of supply on hand. Loss of a software license will usually have a more immediate impact. Assuming the software is mission or safety critical, a resolution should be pursued. Similarly, an information assurance issue with the software has an immediate impact as the software can no longer be used without a waiver.
  • Loss of software support is more complex. If obsolete software has never been changed and no errors have been uncovered or no changes are anticipated, then it also may be safe not to pursue a resolution for some period of time. The software may continue to operate correctly until the end of system life as long as the underlying layers can be sustained. Consequently, the cost of changing the software becomes a consideration. Requalification of systems after a software change can be more extensive than after a hardware change due in part to the complex nature of the required testing.
  • In the case of firmware changes, there is a question of whether there will be an effect if a new functional group is introduced into the system. A resolution should be pursued on the basis of the risk in making changes in the functional group application.
  • When an issue of environmental compliance is identified with regard to a material, the program will need to evaluate how long the item in which that material is resident will remain available.

5.2.2. Which Problem Should Be Addressed First?

A step-by-step process can be used to prioritize problems on the basis of their impact on the program. Several ways exist to develop such a prioritized list. The example here is based on knowledge of piece-part electronics, circuit card assemblies, and the black boxes the circuit cards populate. A similar approach for assessing risk of mechanical assemblies, materials, and COTS assemblies can be derived from these steps. There is one situation, however, that may make prioritization of the problem unnecessary—an external organization will resolve the issue. This may be the case for a common item that is shared among many platforms. The DMT may become aware of such a situation through its interfaces with DMSMS activities in other programs. This may also be the case for subtier materials where a higher-level organization is pursuing a DoD-wide resolution. In either situation, the DMT should evaluate whether that external resolution will meet both its schedule and its technical requirements.

The steps below are based on assessing the impact of circuit card obsolescence issues given knowledge of the devices (piece parts) on the card. These steps include general statements, such as rank by “x” or adjust the rankings as a function of “y.” There is no set formula for these rankings and adjustments. They are based on the experience of the person making the assessment:

  • The first step considers both an analysis of piece-part availability and the results of the calculation of the time frame until impact using the logistics data and the programmatic data. The order in which availability and logistics analyses are evaluated is determined by the risk assessor. Initially, the cards could be ranked by some combination of the total number of obsolete parts per card, the number of obsolete mission- or safety-critical parts per card, and the number and distribution of unique parts. The rankings could then be adjusted by the days of supply and the average monthly demand for both the parts and the card if the system is in sustainment. If the system is in design or production, reliability data, if available, could be used for the average monthly demand. Inventory levels would be the contractor’s stock level.
  • The second step is to adjust the rankings based on the near-term obsolescence risk for the parts and the card and on the number of sources or alternatives available for the parts on the card. These data could be generated using predictive tools.
  • A third step is to adjust the rankings based on the maintenance philosophy for the parts and the card. If the circuit card is repairable and the obsolete parts are highly reliable, then the risk of the part causing the card to be unavailable is not as great as if the card is a throw-away and no more cards can be produced, due to an obsolete part (even if it is reliable). For example, a repairable circuit card with critical obsolete items may not rank as high risk if the inventory levels of the circuit card are high and the usage rate is low, whereas a card not considered highly complex may be a greater risk based on low inventory levels and high demand rates. The bottom line is that no matter how simple the card, if a spare is not available, then the unit is out of commission. On the basis of this additional logistics information, the risk priority of the cards in a given unit may change. In design or production, this step might not affect the rankings very much, but the factors addressed are a consideration.
  • A final step is to examine programmatic data concerning product improvement plans or other mitigation efforts already underway. If a modernization plan calls for the replacement of the unit or if a refreshment of any of the circuit cards is planned, the risk priority may change yet again. For example, if a circuit card assembly is identified as high risk with low inventory levels, but a replacement unit is scheduled to be fielded, the risk may not be as great. The time frame for fielding and the ability to support the card through other means until that time may reduce the risk and therefore the priority of the card. These factors would probably not have much effect for a system in design or production.

If information is available about the electronic piece parts that populate a unit, but no structure is available to understand the breakdown from the unit to the card level, then the above four steps are completely analogous to Situation 1. Only the risk at the part level and this translation to the unit level can be evaluated. The number of obsolete items, the complexity of the function of any obsolete items, and the near-term obsolescence risks, along with logistics information at the unit level and the programmatic data, will identify the risk. For example, assume the list of parts contains 100 unique items. The availability analysis identifies no current obsolescence issues; however, several critical part functions are predicted to be obsolete in less than 2 years. The unit was just fielded, with production to continue for 2 more years and no near-term plan to replace it. In this situation, the near-term obsolescence elevates the risk of the unit, but the DMT has some time to plan the resolution options. Evaluating the availability of alternates for the high-risk items and working with the program and the prime contractor to develop a path ahead will reduce the DMSMS risk of this unit.

The same four steps could be used for assessing a COTS or a mechanical assembly for which part data are unlikely to be available. However, the analysis would be much less granular. Instead of using predictive tools, the DMT would need to derive availability data from vendor surveys. For step 1, the availability data would simply be that the assembly is obsolete and the logistics data would be similar to the above. Step 2 would consider just the near-term obsolescence risk for the assembly, and steps 3 and 4 would be analogous to the above. For example, assume the supplier survey indicates that the box will be available for another year and that a replacement is planned for when the box is discontinued. However, this replacement is not backward compatible; therefore, some nonrecurring engineering is required and, possibly, some testing to evaluate the use of the new unit in the system. From the logistics input, the DMT determines that the demand rate is low, with enough inventory to support the item for another 18 months as long as the demand rate does not increase. The risk may be assessed as low, given the availability of a replacement and the current inventory levels.

In another case, only one manufacturer supplies ball bearings for aviation platforms. The Industrial Capability Assessment (ICA) of the manufacturer indicates both financial and work-force well-being. However, the ICA also indicates that the manufacturer has limited capacity to surge and that all aviation platforms across the military services use this one source of ball bearings. If current inventory levels indicate a 6-month supply at the current operating tempo, and if DoD plans to increase the operating tempo, the ball bearings could be a high-risk item for availability (material shortage) even though not obsolete. The supplier might have problems meeting delivery schedules if multiple systems also experience an increase in operating tempo. If an additional source for these bearings is being developed, but qualification of the new supplier is still 2 years out, this manufacturer and this item would be considered medium risk and monitored. Evaluation of the increase in flying hours, along with reliability of the bearings, can identify possible future shortages.

Even though software can function for a long period of time with no support and without any adverse impact if underlying layers are stable, the loss of a software license should be addressed immediately. The same holds true for software no longer meeting information assurance requirements or a firmware change that affects system operation. When determining the priority under a loss-of-support situation, consideration should be given to the number and frequency of updates, the number of different versions currently being used on the system, or the age of the versions in use.[73]

5.2.3. At What Level Should a Resolution Be Applied?

If a system will be affected by a DMSMS issue, the DMT should determine where in the item’s hierarchy to apply the resolution. For example, the subject item may be one of many items within its hierarchy that have DMSMS issues. In such cases, it may be expeditious to replace or redesign the assembly rather than resolve the problems with each individual item. The same factors should be considered in this analysis:

  • Number and difficulty of DMSMS problems in the hierarchy
  • Reliability of items in the hierarchy
  • Expense of repair within the hierarchy compared with redesign or replacement
  • Life cycle of other items in the hierarchy
  • Potential for enhancing mission capabilities by redesigning or replacing items.

Most of these factors can be analyzed by the DMT if sufficient data exist. The importance of integrating item availability data with logistics and life-cycle data cannot be overemphasized when analyzing the impact of a DMSMS issue. The first factor is largely a numbers game. If the cost to implement numerous DMSMS resolutions exceeds the cost to redesign the NHA, then the redesign should be considered.[74] The second and third factors are similar, in that one must compare the cost of continued operation of the existing item to that of implementing and maintaining a new item. This calculation is more involved, but in the end, it is a simple evaluation of which resolution provides the most bang for the buck.

The fourth factor requires a more subjective judgment, because item life cycles are not a strictly objective measure and because educated guesses are required to predict DMSMS problems. One must look at various sources of information and determine if the risk of future obsolescence and its accompanying costs exceed the benefits of resolving known problems now. This analysis is often the basis for planning technology refreshes and may result in a decision to resolve the DMSMS problem for a limited time (life-of-need buy).

The last factor will require the input of other program, and potentially higher-level, personnel. If future mission demands require new equipment or different capabilities, it may be expeditious to implement those features now rather than to wait.

For software, an impact assessment is more complicated. Hardware impact assessment is relatively linear in that item obsolescence will have an effect on its NHAs. There often are non-linear, secondary and tertiary effects of software obsolescence. Consequently, software dependencies—those elements of the system potentially affected by changes to software—are usually more complex and far reaching than those of hardware. Understanding software (and hardware, for that matter) dependencies is crucial for determining the most cost-effective level
of resolution.[75] Because of this, the answer to this question should be determined on a case-by-case basis.

6. Analyze: DMSMS Resolution Determination

This section discusses the Analyze step; specifically, it explains how to find the best resolution option. The resolution determination process is iterative; the analysis is updated as new issues are identified and prioritized. Typically, new issues to be resolved are added at every DMT meeting. The following subsections address identifying the cost elements associated with estimating implementation costs, identifying and defining resolution options, and determining the preferred resolution option. The resolution determination process is the same whether the DMSMS issue is related to hardware–electronic and MaSME items or software.

6.1. Identify Resolution Cost Elements

To determine the best resolution, a program must first understand that resolution’s total implementation cost. That cost is the sum of all applicable cost elements associated with that resolution. For example, a resolution may require anything from simple drawing and technical manual updates to full development and testing of new designs to be implemented in a system. If the actual costs for particular cost elements are known, those costs should be used to develop a more accurate account of the costs required to implement a resolution or series of resolutions. Actual costs give a program the most accurate account of the funding required to mitigate obsolescence and is an important metric.[76] Although using actual costs for resolutions is preferred, actual costs may not be readily available, and obtaining actual costs may be cost-prohibitive. Therefore, each program should develop average costs for each applicable cost element.[77]

The following cost elements should be considered when determining the total cost for resolving a DMSMS issue:

  • Engineering and engineering data revision—cost of modifying drawings and other data to reflect the new configuration
  • Purchase of engineering, design, or technical data—cost of purchasing technical data required for support
  • Qualification of new items—research and evaluation cost generated in choosing a new item
  • Revision of test procedures—cost of updating test procedures to accommodate any new testing requirements of the selected solution
  • Software changes—cost of updating software because of the selected solution and including software updates to test equipment
  • Start-up costs—nonrecurring engineering costs to develop production or repair capabilities
  • Testing—cost of testing requirements for the selected resolution to ensure system
    compatibility
  • Tooling, equipment, test equipment, or software—cost of repairing and maintaining equipment
  • Computer programs and documentation—costs of new software and documentation to support the new item
  • Interim support—contractor cost to maintain a product until a permanent resolution can be implemented
  • Item cost—cost to procure the item for the entire life cycle
  • Manpower—cost of maintenance personnel needed to support the resolution for the life cycle
  • Spares—cost to procure spares for sustainment
  • Supply and provisioning data—cost to update logistics data to ensure support of selected resolution
  • Support and test equipment—cost to provide the repair center with any required support or test equipment
  • Technical manuals—cost to provide any manuals and documentation to repair centers
  • Training and trainers—cost to develop and maintain training for the new equipment
  • Any other costs as required.

The prevalence of counterfeit parts and the use of lead-free (Pb-free) solder in the electronics industry also affect the costs and risks to resolve a DMSMS issue. When a DMSMS resolution option involves purchasing an electronic item from sources other than authorized suppliers (i.e., OCM, OEM, authorized or franchised distributer, or authorized or approved after-market manufacturers), additional testing must be done to ensure that counterfeit parts do not enter DoD’s supply chain. Therefore, the average testing cost must be included. (See Appendix F on counterfeit parts and DMSMS management.)

The impact of Pb-free solder is more complex. It is not easy to know whether an alternative item uses Pb-free solder. However, certain critical DoD applications require that tin-lead (SnPb) solder be used. This adds a technical constraint on the acceptability of certain resolutions. Furthermore, if Pb-free is a requirement, then additional costs may be incurred to detect, test, and mitigate any use of Pb-free products. Such additional costs should be factored into the cost element averages. (See Appendix K on Pb-free electronics and DMSMS management.)

When determining the most accurate average cost for each element, a program should use various factors, such as the following:

  • Historical testing and qualification cost data of previously implemented resolutions for like equipment
  • Historical testing and qualification cost data of similar programs with like equipment
  • Historical development and redesign costs of like equipment within or outside the program.

In addition, averages are affected by the type of item, commodity, population, and operating environment. The type of item may be raw material, components, or assemblies. The commodity could be electronics, mechanical, electrical, or computer. The population, or number of items, can have a large effect on costs, due to economies of scale. Finally, the operating environment will make a large difference in testing and certification requirements for approving and qualifying new items into a system. Operating environments may be aviation, shipboard, space, or ground.

6.2. Identify and Define DMSMS Resolution Options

Many different types of resolutions exist for resolving an obsolescence issue. These resolutions fall into three broad categories: existing material (logistics), substitutes (engineering), and redesign (engineering). These broad categories indicate the level and amount of research required to implement a resolution. As a program progresses through the various resolution categories, the amount of research and number of cost elements required to implement a resolution increase. Resolutions under the existing material (logistics) category require actions to secure availability of existing supply. Substitute (engineering) resolutions require engineering involvement to qualify or implement. Redesign resolutions usually require all aspects of engineering and qualification to implement new or highly modified equipment. Table 9 contains the standard definitions and examples of each type of resolution, in order of complexity.

Table 9. DMSMS Resolution Options, Definitions, and Examples

Resolution

Definition

Examples

No solution
required

No solution is required, because existing stock contained in government or contractor-maintained inventories will satisfy future demands for the product or because the existing software may be used indefinitely without any anticipated repercussions. This is often the result of planned technology refreshment, redesign, or system retirement.

It is determined that sufficient stock of an item exists in current government or contractor-maintained inventories to support the system until its next technology refreshment.

It is determined that firmware embedded in obsolete hardware will remain functional until the hardware is replaced and existing hardware stocks are sufficient to meet system requirements through the end of service date.

A UDR query identified a vendor that had new items with a government acceptance stamp on them that had previously been sold as excess.

Approved item

The obsolescence issue is resolved by the use of items already approved on the drawing and still in production.

Research indicates that the drawing includes a reference to another approved item that is still available. Supply is directed to procure the other approved item.

The media used to store the software is no longer readable (e.g., floppy disks). The software is digitally ported to a CD.

Life-of-need buy

A sufficient quantity of the item is purchased to sustain the product until its next technology refreshment or the discontinuance of the host assembly. The quantity purchased should consider demands from all users. Because this resolution uses an approved item, no testing or drawing changes are required. The source of supply can be residual stock from the original manufacturer, shelf stock from distributers, sponsor-owned material, etc. Costs for packaging, storage, and transportation should be considered in the BCA for selecting resolutions. This is sometimes referred to as a life-of-type buy, bridge buy, or lifetime buy.

For software, sufficient licensing and/or support is obtained for the life of need, assuming the life of need is short enough to ensure that the vendor will remain in business.

On the basis of historical usage rates, it is determined that 165 diodes are required to sustain the system until it is decommissioned. Sufficient inventory of the discontinued item is then purchased from an approved distributor and stored for use as needed.

A life-of-need buy can also be made during design or production. Production material and associated spares can be procured when an obsolescence issue occurs early in the life cycle.

A license downgrade is negotiated with the software vendor, which enables the users to expand or extend authorized use of an older product by purchasing additional licenses of the latest version and applying those licenses to the older product until it is retired.

A particular adhesive used in production of circuit cards went obsolete. A sufficient quantity of adhesive was purchased to meet demand until a new adhesive could be qualified.

Repair,
refurbishment, or reclamation

The obsolescence issue is resolved by doing one of the following:

Instituting a repair or refurbishment program for the existing item or assembly, whether through a depot repair, a repair contract with the original manufacturer, or support from a third party.

Instituting a reclamation program to reclaim items from marginal, out-of-service, or surplus materiel. Costs for restoring reclaimed materiel as a result of electrostatic discharge damage, handling damage, and heat damage from unsoldering should be considered.

Obtaining access to the software source code, development tools, and the human resource skills necessary to change it to ensure continued support.

A program has sufficient items or assemblies to support the system, if they are refurbished. A private company is identified that has this capability, and a contract is awarded to repair these assets for the system’s remaining service life.

Hybrids are salvaged from an earlier configuration of the NHA, repaired, and used for future repairs on higher assemblies.

Because of scrap steel shortage, it was difficult to maintain a source for high explosive munitions bodies. A process was developed to decontaminate and mill surplus munitions projectiles.

The original vendor allows the customer to purchase the source code and the development tools to maintain it and will provide software engineering support for a fee.

Extension of
production or
support

The supplier is incentivized to continue providing the obsolete items. This may involve long-term agreements to procure specific quantities of items. One-time costs may be associated with setting up this resolution. Those costs should be included in any cost and cost avoidance by being proactive calculations.

For software, long-term licensing and/or support agreements are
obtained.

The DMT works with the manufacturer to resolve any obsolescence problems with a COTS assembly’s piece-parts or raw materials, so the original COTS assembly can still be manufactured. The government obtains the COTS assembly BOM from the OEM, resolves piece-part obsolescence, and then provides the needed parts to the OEM as government-furnished material to facilitate continued manufacture and repair.

The DMT works with the manufacturer or software vendor to extend the warranty or support period, thus extending the useful life of the product.

A third party is contracted to continue support on a software application.

A vendor creates a custom item number that freezes hardware and firmware at a specific version/revision level to ensure that future supply meets the original requirements.

Simple
substitute

The item is replaced with an existing item that meets all requirements without modification to either the item or its NHA and requires only minimal qualification. Typically, this implies use of a commercial item or non-developmental item that is a fit/form/
function substitute. Associated costs are largely administrative. This is sometimes referred to as an alternate.

The original item number from a company is purchased from a source not identified in control drawings; in other words, the item was purchased from a different vendor. The original oil specified in the drawings is no longer available. Another company makes oil with similar characteristics and was approved as a substitute with minimal evaluation.

The TDP of an intrinsically suitable, but different, item (e.g., a more reliable version or an existing item) is evaluated.

A rebadged COTS product is discontinued by its vendor, but the source item is still available from its OEM under a different part number.

The deployed version of an operating system is no longer supported. The support version is installed as an upgrade and meets all of the current requirements.

A previously emulated device (e.g., from DLA’s GEM program) is substituted for the original item.

Currently, software is rehosted to operate correctly with new application hardware or software.

Complex
substitute

A replacement item that has different specifications but requires no modification of the source product or the NHA, is researched and validated. The substitute may be the result of a redefined military requirement.

An optical coupler approved in the source control drawing is no longer made. An engineering search finds four couplers with similar characteristics. After qualification, two are approved for the application. The suggested sources table in the source control drawing is changed to authorize the new items.

The current operating system is obsolete. The replacement operating system does not meet all the specifications of the current version and must be thoroughly tested.

A military requirement was restated or revised to allow for the use of a substitute item from a commercial source.

Another software product is used to replace the obsolete software.

A magnetic tape with an obsolete fire-resistant coating was replaced with a tape with a similar fire-resistant coating that had to be fully tested and qualified before use.

Development of a new item or source

A replacement product is developed that meets the requirements of the original product without affecting the NHA. Nonrecurring engineering or other development-related activities will likely be required. The new product may be developed by emulating, reverse engineering, designing a replacement based on the original manufacturing designs and processes, or designing a different product based on the original or new requirements. The manufacturing source for the new item may be the original manufacturer or a new source.

A VME card is discontinued by its original manufacturer. Another manufacturer is contracted to purchase drawing packages, manufacturing equipment, and production rights to continue production of the card.

A manufacturer is approached to purchase specifications and production rights to resume production of a mechanical item (e.g., a diesel engine) that was discontinued by the original manufacturer.

The firmware for a circuit card is no longer available and must be rewritten using different tools.

DLA’s GEM program creates a device that emulates the original device.

The software application is redeveloped because of an obsolete compiler or obsolete modeling tools.

A special fabrication project in an organic facility is initiated to develop and produce an item.

Redesign–NHA

The affected item’s NHA must be modified. Only the NHA is affected, and the new design will not affect anything at a higher level in the
system.

An obsolete component for which a viable F3 replacement cannot be found requires a redesign of the circuit card on which the component is found.

The operating system of a single board computer is obsolete and no longer supported by the manufacturer. Policy dictates that it can no longer be used on DoD systems. The new version of the software will not run on the existing hardware. A replacement board that runs the new version of the operating system is available and will not require changes to other equipment. Some of the associated software must be modified to accommodate the new operating system.

A refrigeration system that used a banned Freon refrigerant had to be redesigned to use an approved refrigerant.

Redesign–complex/system replacement

A major assembly redesign affects assemblies beyond the obsolete item’s NHA and may require that higher level assemblies, software, and interfaces be changed.

Aircraft radar was replaced to use a different operating frequency. Many obsolescence issues were eliminated in the new design.

The operating system of a server must be replaced due to policy changes. The new operating system will require hardware changes to multiple hardware and software configurations.

A vehicle’s diesel engine became obsolete, requiring the replacement of the entire drive train for the vehicle, because the old transmission was not compatible with the new engine.

Table 10 identifies the cost elements that apply to each resolution; “X” indicates a cost element that is likely to be part of the listed resolution and may need to be considered when evaluating costs. There may be some differences in the applicability of the DMSMS cost elements to the resolution options when software is an issue. Because the cost element terminology is very broad, the differences are small. However, no data exist to support whether an average cost estimate for a software resolution will be the same or different than the cost of a hardware resolution.

Table 10. Cost Elements as Applied to DMSMS Resolution Options

Existing material (logistics)

Substitute
(engineering)

Redesign (engineering)

Cost element

Approved item

Life-of-need buy

Repair, refurbish-ment, reclamation

Extension of pro-duction or support

Simple substitute

Complex substitute

Development of a new item or source

Redesign–complex/ system replacement

Redesign–NHA

Engineering, engineering data revision

X

X

X

X

X

Purchase of engineering,
design, or technical data

X

X

X

X

X

Qualification of new items

X

X

X

X

X

Revision of test procedures

X

X

X

X

X

Software changes

X

X

X

X

Start-up costs (after-market, etc.)

X

X

X

X

X

Testing

X

X

X

X

X

X

Tooling, equipment, test
equipment, or software

X

X

X

X

X

Computer programs/
documentation

X

X

X

X

X

X

Interim support

X

X

X

Supply/provisioning data

X

X

X

X

X

Support/test equipment

X

X

X

X

X

Technical manuals

X

X

X

X

X

X

Training/trainers

X

X

X

X

X

Item cost (optional)

X

X

X

X

X

Manpower (optional)

X

Spares (optional)

X

X

X

X

Other (as required)

X

X

X

X

X

X

6.3. Determine the Preferred DMSMS Resolution

DMSMS management processes do not stand alone. They operate in the context of normal program office business processes. Therefore, determining which resolution to implement has two components. The first component is guided by the program office’s organizational structure, hierarchy, and chain of command; for example, all DMSMS management may be under the cognizance of a reliability and maintainability organization. The second component, which is the subject of this subsection, is methodological; its processes determine which DMSMS resolution options to recommend.

The resolution determination process uses various outputs from monitoring and surveillance and impact assessments that determine if and when an issue will affect the operational availability of the system. Figure 17 illustrates the major activities and tasks of the resolution determination process. One important, initial activity in this process is to determine whether there is an external organization that is pursuing a resolution to a DMSMS issue in a manner that meets the program’s schedule and technical requirements. As long as the external resolution process meets all of the program’s requirements, then the program only needs to monitor that the resolution process is on track. Otherwise, the program should continue with the other major activities of the resolution process.

The resolution process should also consider the requirements to transition from one program life-cycle phase or contract to another. For example, resolutions in the design phase may include short-term actions until a longer-term option can be implemented in the production phase. This complicates the process because the analysis may need to be conducted over multiple time increments (e.g., between now and the end of production and between the end of production and a planned technology insertion).

Figure 17. DMSMS Resolution Determination Process

DMSMS Resolution Determination Process

If the impact assessment indicates that a resolution is needed, one or more of the resolutions listed in Table 9 can be applied regardless of whether the DMSMS problem is mechanical, material, software, or electronic in nature.[78] While all of these resolution types apply to different item types, the frequency of use of a particular DMSMS resolution may differ depending on commodity type. Table 11 illustrates the distribution of resolution types by part commodity—electrical, electronics, and mechanical—as reflected in data collected through a 2014 Department of Commerce DMSMS Cost Survey. Although implementation[79] may vary drastically for different types of issues, the overall resolution determination process is the same. Not all resolutions can be applied to a given DMSMS problem. Only those that can be applied are considered viable.[80] For instance, most of the resolution options are not viable for a forged impeller body that has become obsolete; the only viable resolutions may be the identification of a new source or redesign. However, the process to determine the viable resolutions (often the most cost-effective) is the same, whether the problem is a circuit card assembly or a specific chemical used in the manufacturing process that has become obsolete because of environmental restrictions.

Table 11. Distribution of DMSMS Resolutions by Part Commodity[81]

DMSMS Resolution

Electrical

Electronics

Mechanical

Total

Approved items

987

316

236

1,539

Life-of-need buy

27

633

6

666

Simple substitute

190

1.233

77

1,500

Complex substitute

34

331

45

410

Extension of production or support

27

68

3

98

Repair, refurbishment, or reclamation

1

38

1

40

Development of a new item or source

14

103

10

127

Redesign–NHA

2

132

4

138

Redesign–complex/system
replacement

12

31

1

44

Total

1,294

2,885

383

4,562

Percentage of Share

28.4%

63.2%

8.4%

100%

As resolutions become more complex, their implementation becomes more costly.[82] The list of viable resolutions is built by going through Table 9 from top to bottom and determining the feasibility of each option. Many of the factors (e.g., near-term cost, total life cycle cost, level in the system, mission factors, planned technology refreshes or upgrades, results of impact assessments, and terms and conditions of contract) used to analyze the operational impact should be used to help determine which resolutions are viable. The overall resolution determination process should consider all viable resolutions at the lowest level of indenture possible and, if the impact assessment indicates that a resolution at a higher level of assembly may be preferable, at higher-level assemblies. In some cases, a resolution at a higher level will have a higher ROI, because it may resolve numerous issues at once or improve reliability significantly.

Section 2.3.1 discussed DMSMS design considerations from the perspective of design concepts that tend to reduce future DMSMS costs. There also are design considerations that impact the feasibility of resolutions. For example:

  • Real-time software. Many times, defense products use software that performs a real-time function. Often this is software for signal processing or signal analysis that has a specific time available to accomplish a specific task. This means that the failure to complete the signal processing in the available time means that information is lost, or worse, the system will crash. DMSMS issues can often have a profound impact on the portability of real-time software. Even when the real-time properties of various software modules are well documented, and latencies of interrupted service requirements are documented, the need to use a new and different processor or components with different memory speed due to obsolescence of an earlier or different processor component can result in considerable impact to real-time performance. Furthermore, real-time performance validation can be extremely difficult, particularly when real-time failures only occur under rare combinations of interrupt conditions. Whether a new processor performs slower or faster, the interaction with external interfaces is certain to be different, and it is occasionally difficult for drivers to fully compensate for speed changes. It is essential that the design, development, and maintenance of software systems that have real-time components maintain very accurate analysis and models of system timing so that as processors and technology evolve, the real-time performance can be easily validated, and software can be ported. There are also important implications with respect to maintaining an understanding of execution time statistics of each software module, and the corresponding understanding of selected compiler optimizations and coding style, in order to maintain real-time performance when DMSMS issues cause design updates.

Validation and production testing. Product testing advances today include many sophisticated capabilities to assess analog and digital subsystem performance. When a DMSMS issue occurs, the resolution may impact the means for testing. Today’s digital subsystems are tested with Joint Test Action Group and other interface validation. If a design or redesign causes interface changes, or timing changes, there are likely to be impacts to both validation tests and production line tests. It is essential to assure that testability of validation and production line tests remain resilient to these changes. This is especially important so that counterfeit components and marginal designs are quickly detected, identified, and corrected as part of a DMSMS redesign. To assure this, the testing process must retain documentation of traceability between what functions are being tested and how the tests relate to requirements, so that system behavior changes after a DMSMS redesign can be properly understood and validated. When the test equipment itself is affected by a DMSMS issue, validation considerations go beyond testing the function of the equipment. To deal with the potential for malware being introduced into the test equipment, validation should ensure that the equipment is performing all of the tests in the way that they should be performed. This is beyond the scope of typical validation testing.

Before any analysis of resolutions to identify the most cost-effective approach, the engineering representative on the DMT must ensure that those resolutions satisfy all technical requirements.

All viable options (including the status quo) are then analyzed further using either an AoA or a BCA to determine which resolution or set of resolutions gains the best ROI.[83] A BCA is a formal, structured approach for examining the costs, benefits, and risks of different alternatives. It requires background research and data collection and management. It also requires a thorough understanding of the quality and completeness of the data and of any assumptions made.

The standard criterion for comparing alternatives on an economic basis is net present value (NPV), the discounted monetized value of expected net benefits (benefits minus costs). NPV is computed by assigning monetary values to benefits and costs, discounting future benefits and costs using an appropriate discount rate, and subtracting the sum total of discounted costs from the sum total of discounted benefits. For DMSMS resolution alternatives, the one with the highest NPV (e.g., lowest life-cycle cost) is preferred, because the benefit of mitigating the DMSMS condition—that is, avoiding negative impacts on system operational readiness—is the same for each alternative.

An AoA is a simplified version of a BCA. An AoA does not require the amount of detailed analysis of a BCA to determine the most viable resolution. Typically, an AoA is used in place of a BCA when a low cost and risk of the resolution can be estimated accurately up front without an in-depth analysis.

A program must be able to calculate resolution costs at an acceptable level of fidelity to perform an AoA or BCA. To make a decision on which resolution to pursue, the cost calculations do not necessarily need to be exact; they just have to be consistent enough to establish an ordinal ranking. To ensure that the funding is sufficient to support the implementation of the selected resolution, a program will need better fidelity. Table 12 shows average costs associated with implementing each of the DMSMS resolution options. These data were compiled from submissions to a 2014 Department of Commerce survey of government and commercial DMSMS programs.[84] While it is preferable for a program to estimate specific costs for resolutions, the costs cited in the table can be used to make preliminary cost estimates when a program is gathering more detailed information.

Table 12. Average Cost Associated with Implementing Each DMSMS Resolution Option

Resolution option

Average[85]

Approved item

$1,047

Life-of-need buy

$5,328

Simple substitute

$12,805

Complex substitute

$25,867

Extension of production or support

$25,930

Repair, refurbishment, or reclamation

$66,185[86]

Development of a new item or source

$667,209

Redesign–NHA

$1,112,528

Redesign–complex/system replacement

$10,473,148

Appendix L can be used, with caution, to modify these averages based on more specific circumstances. The appendix is a three-part table that contains the complete results from the Department of Commerce survey. The rows of the table show the above resolution options subdivided by environment (aviation, ground, shipboard, space, and undersea). The columns show the commodity type (electrical, mechanical and electronics) subdivided by item type (assembly, component, raw material, and software). Entries in the table are average cost and sample size. Little confidence should be placed in entries with a low sample size.

Both an AoA and a BCA should account for life-cycle costs for each applicable time increment.[87] When possible, multiple resolutions sequenced over time for implementation through the end of need should be considered. This allows a program time to implement the resolution with the best ROI if barriers exist at the time of notification. For example, if a circuit card assembly with an ASIC is obsolete, and the impact on operational availability is projected to occur within 6 months (based on stock, demand, and reliability information), the DMT may determine that the resolution with the best ROI is to develop a new source of supply. However, if developing a new source will take at least 1 year after qualification, the DMT will need another resolution to cover the development time; for example, if stock is still available, then a life-of-need buy could be implemented.

The cost avoidance by being proactive is also a factor in both an AoA and a BCA. The cost avoidance by being proactive as it relates to DMSMS resolutions is usually defined as the difference between the cost of the selected resolution and the next viable resolution. For example, if the only two viable resolutions are a complex substitute or a redesign, then the cost avoidance by being proactive would be the difference between the estimated redesign costs and the complex substitute costs. However, as another example, if a complex substitute, the development of a new source, and a redesign were all viable resolutions, then the cost avoidance by being proactive would be the difference between developing a new source and using a complex substitute. As mentioned in Section 3.4.3, this approach to estimating the cost avoidance by being proactive is not without complications.

Once the program has identified the implementation cost for the viable resolutions, the program can calculate the breakeven points and ROI to determine which resolution is the most cost-effective. That resolution, however, may not be the best option when risk is taken into account. All identified risks associated with the resolutions should be captured and a proper weighting factor should be associated with each risk. Some risks will require a higher weighting factor than others. The following are among the risks to consider:

  • Technical—risk associated with the ability to develop or implement a resolution while still maintaining performance within the specification
  • Supply chain—risk associated with the financial viability of the resolution provider that will be maintaining the capability
  • Financial—risk associated with the availability of funding required to implement a resolution within a specified time period
  • Schedule—risk associated with implementing a resolution before operational availability is affected.

Application of these risks in the decision-making process is subjective. In some instances, a high-cost resolution with low risk is preferable to a low-cost resolution with high risk. For example, testing and qualifying an alternate item that uses technology similar to that in the obsolete item may not be the best choice, because there may soon be a shortage of that alternate. Instead, it may be better to develop a substitute item using more current technology.

When the DMT has determined the best resolution, the PM must decide whether it is acceptable and determine whether the funds and resources are available for implementing that resolution (Section 7.1 addresses estimating resolution costs to inform program budgeting programming). In some cases, feedback from the PM may require the DMT to repeat the resolution determination process. For example, the PM may impose new resource or time constraints or may even bring up the possibility of a new product improvement effort.

7. Implement: Implementation of DMSMS Resolutions

The DMT’s role does not end when a PM decides which resolution option to pursue. The final step of the DMSMS management process is implementation. In the Implement step, the DMT should be involved in two final processes: securing a source of funding for implementing the preferred resolution and ensuring that the actions required to implement the preferred resolution are taken.

In some cases, contracts with the prime contractor (during design and production) or a logistics provider (during sustainment) may include a requirement for the contractor to fund DMSMS resolutions. (Appendix C contains more information on contracting.) This situation is complex:

  • The definition of “end-of-life” can differ depending on one’s perspective. If the contract requires the contractor to buy additional items to resolve a DMSMS issue, the contractor will normally be concerned only with demands up to the end of the contract period of performance, whereas the government will likely be interested in addressing an issue through the “end-of-need.” Unless the government specifically defines this, it can remain open to interpretation. Depending on its relationship with the government, the contractor may be willing to support the program “on risk” to provide resolutions beyond the contract period of performance. The government should not assume that this will always be the case, nor should it expect the contractor to buy enough items to last until the end of need without additional funding.
  • If the contract requires the contractor to resolve DMSMS issues, the contractor may not fund the most cost-effective resolution from the program’s perspective. The contractor will determine the resolution based on its own business case calculations. However, depending on its relationship with the government, the contractor may factor the government’s long-term needs into the calculation, assuming the contractor is made aware of those needs. If the program included, in its RFP, a requirement for the contractor to fund the most cost-effective resolution from a program office perspective, the contractor would be forced to bid a much higher price to compensate for risk. Consequently, the program should be prepared to negotiate with the contractor on which resolution option to implement and should be prepared to provide additional funding if warranted. These negotiations are enabled by a strong government-industry relationship and full government awareness of the DMSMS services provided by the contractor.

As discussed in Section 2, effective technology management will help minimize the cost and readiness impacts of DMSMS issues.

7.1. Secure DMSMS Resolution Funding

The best way to secure DMSMS resolution funding is to plan and budget in advance. Although the program is responsible for comprehensive planning for DMSMS resources and securing implementation funding, the DMT is often asked to assist. A program may not know the specific DMSMS problems that will occur in a given year, but experience has proven that DMSMS issues are inevitable and thus a program will face multiple DMSMS problems annually. Furthermore, experience has proven that failure to mitigate those problems will lead to unacceptable performance, degradation of system reliability and availability, and increased costs.

Knowing that it will face any number of DMSMS issues in a given year, a program needs to be in the position to pay for resolutions as they arise. To do so, the DMT can assist program leadership in developing its budget and program submissions to be able to fund DMSMS resolutions as well as to ensure that obsolescence is incorporated in the program’s technology roadmap funding.

In addition to developing an estimate of the costs to address obsolescence, a program may also need to gather additional information to support the importance of having funding for robust DMSMS management and to implement resolutions as required. ROI and cost avoidance by being proactive metrics can be used to gain support for the budgets necessary to resolve expected problems. These metrics may be used to project future cost avoidance due to the implementation of the resolutions. If decision makers can be persuaded to accept the estimate of both future cost and future cost avoidance by being proactive, the estimates can be used to offset (to some extent) the cost of implementing the resolutions.[88] Consequently, future budgets may not need to be as high as originally estimated. Because the cost avoidance by being proactive will occur sometime in the future, near-term budgets will not be able to take credit for any offsets.

While there may be some uncertainty about the exact numbers and types of resolutions a program will face in a given year, a number of approaches can be used to assist in estimating resolution costs and, therefore, inform the program on what is required to support resolution funding. Table 13 summarizes different approaches that could be pursued to estimate resolution funding. These approaches are listed by the extent of analytical rigor in deriving the estimate (with the most rigorous at the top). Each program will have to make its own assessment regarding the level of effort, and degree of difficulty, it is willing to pursue to estimate DMSMS costs to inform program budgeting and programming. A key consideration is the amount of rigor necessary to successfully defend the funds.

Table 13. Description of DMSMS Resolution Cost Estimation Approaches

Approach

Description

Estimate by individual item

Analyze specific items to estimate discontinuation time

Estimate by technology segment

Analyze technology segments and what is known of their lifespans to
determine when and where obsolescence is predicted to impact a design

Estimate by prior trends

Calculate and use the historical numbers and trends for each resolution type

Estimate by annualized averages

Calculate the average of what has been spent annually on resolutions

Estimate by expert opinion

Use subject matter expertise to estimate the numbers and types of
resolutions to be encountered

The first two approaches generate estimates of the number of resolutions required. Additional analysis is required to determine what type of resolutions they will be and then to apply a cost to them.

Estimating by individual item requires a detailed understanding of the items constituting a system design, the requirements of a program’s production and sustainment plans, and forecasts of when specific items can be expected to become obsolete. Because of the data intensity required to support analysis at the item level, this DMSMS resolution cost estimation approach has the greatest degree of difficulty of the approaches summarized in Table 13. It is also the most analytically rigorous.

A slightly less data- and labor-intensive approach is the implementation of a technology segment analysis. This analysis looks at broader technology segments to identify what is known of the lifespans of the types of technology segments incorporated into a particular design. With the lifespan information for the technology segments, a program can forecast when and where obsolescence could be expected to affect the design and, therefore, can plan and program for dealing with that anticipated obsolescence. This approach may be sufficient to support a program’s estimates to inform budgeting and programming, but it may not be sufficient to support technology road-mapping.

A third option for estimating DMSMS resolution costs uses trend data. This approach could be particularly useful for a well-established program or a new program for a system similar to that developed by other programs. This cost estimation approach uses data on the historical number of and associated trends in obsolescence issues encountered by a program and the number and types of resolutions required to address obsolescence issues on a year-to-year basis. A program in sustainment can use historical data to develop an expected scenario for annual DMSMS problems to be resolved. To develop a scenario for DMSMS issues expected during design or production, the program should consider the contractor’s next-generation roadmaps, information from manufacturers, the age of the technology in active electronic items, and relevant experience with similar systems.

The annualized average uses historical data (from either the program or a similar program) to calculate an average of what has been spent on DMSMS resolutions annually.

Finally, a program could adopt a DMSMS resolution cost estimation approach that relies entirely on subject matter expertise to forecast the number and types of resolutions to be encountered. Assuming that the program has access to such SMEs, this would be the cost estimation approach with the least degree of difficulty to implement and the lowest degree of analytical rigor.

Despite diligent efforts to apply an appropriate cost estimation method for the program, stakeholders understand that funding requirements for DMSMS resolutions and corresponding budget requests, which are based on the best available data, will almost always be either too high or too low. Because DMSMS management is not a standalone process, there will be opportunities to use extra funding for other reliability, maintainability, or supportability issues. If program resources are not sufficient to implement a preferred resolution, other alternatives are possible. The remainder of this section summarizes a number of resources that a program could pursue to assist in funding a required DMSMS resolution when there is no planned or funded budget.

One such alternative is DoD’s VE program. VE is an organized, systematic approach that analyzes the functions of systems, equipment, facilities, services, and supplies to ensure they achieve their essential functions at the lowest life-cycle cost, consistent with required performance, reliability, quality, and safety.[89] Typically, the implementation of the VE process increases performance, reliability, quality, safety, durability, effectiveness, or other desirable characteristics. VE has been used to mitigate DMSMS issues from two perspectives: funding and methodological.[90]

From a funding perspective, a VE incentive (VEI) clause is included in most supply/service contracts when the contract price exceeds $150,000. A VE change proposal (VECP) is a proposal submitted to the government by the contractor in accordance with the VEI clause. A VECP proposes a change to the contract that, if accepted and implemented, provides an eventual, overall cost savings to the government with a substantial share of that savings contributing to the contractor’s profit. It provides a vehicle to reduce acquisition and operating costs, while increasing the contractor’s rate of return. Typically, the contractor pays the nonrecurring costs associated with the VECP and is reimbursed from the savings. To ensure that savings can be shared, the VECP must meet two primary requirements:

  • It must require a change to the current contract under which it is submitted.
  • It must provide an overall cost savings to the government after being accepted and implemented. (A VECP could result in increased unit cost but reduced O&S cost. Thus, there would be an overall savings to DoD.)

The key takeaway associated with the funding perspective is that the contractor has a profit-based incentive to resolve obsolescence issues earlier. Without this incentive, proactive issue identification may not occur and, consequently, resolutions may be more expensive. These concepts could be applied to a life-of-need buy if the contractor would use its own resources to buy items and then sell them back to the government when needed. This could be especially valuable if the government were not able to obtain the necessary resources in a timely manner.[91]

From a methodological perspective, the VE process can augment the Analyze step in DMSMS risk management, as illustrated in the following example:

Obsolescence issues emerged for the Theater High Altitude Air Defense missile. The issues involved multiple subcontractors and various components. The major and minor redesign efforts recommended to address the obsolescence problems would have resulted in high costs and negative schedule impacts for the program office. The DMT used VE to evaluate each redesign proposal and determine if other mitigation efforts could be employed to overcome the obsolescence issues. A VECP was implemented to mitigate the obsolescence and minimize redesign cost without adverse schedule impacts. The total 3year cost avoidance by being proactive was calculated to be $21.2 million.

Several external funding programs, at both the DoD and service levels, represent other potential resource options for DMSMS resolutions.[92],[93] Most of these funding sources have a periodic project solicitation, but some do not. Projects may or may not be accepted off cycle. In some cases, the solicitation is directed at government program offices; in other cases, the solicitation is directed at industry. The focus areas for the project solicitations are defined by the funding programs themselves, on the basis of their understanding of DoD needs. Although a program with DMSMS issues can communicate its needs to the funding programs, to obtain funding, the proposed DMSMS resolution must be aligned with the mission, requirements, restrictions, and goals of the funding programs. Key external funding programs are as follows:

  • DoD and service manufacturing technology (ManTech) program. The ManTech program is codified in Title 10 §2521 of the United States Code (U.S.C.) as a requirement for each military service and component.[94] This is DoD’s primary program for investing in next-generation manufacturing processes, materials, or technologies, but it also has the mission of “development and application of advanced manufacturing technologies and processes that will reduce the acquisition and supportability costs of defense systems and reduce manufacturing and repair cycle times across the life cycles of such systems.” Thus, DMSMS resolutions that require producibility improvements or a new manufacturing capability can seek funding through ManTech, particularly if repair cycle time and support costs can be reduced. The DoD ManTech program is a joint service research and development (R&D) program with appropriations in OSD, Army, Navy, Air Force, and DLA. Each service or agency programs its investments separately but plans jointly through the Joint Defense Manufacturing Technology Panel. Annual solicitations from OSD and each service or agency are released, and all proposals must contain clear transition paths and have service support from the transition target PM.
  • Defense Production Act Title III program. This program’s mission is to “create assured, affordable, and commercially viable production capabilities and capacities for items essential for national defense.”[95] Production capabilities that would otherwise be inadequate are transformed to support the material requirements of defense programs in a timely and affordable manner. Title III focuses on materials and items that could be used across a broad spectrum of defense systems. The capabilities of defense systems depend upon the availability of materials and technologies.

The program can respond to material shortages using unique authorities to accomplish four objectives:

  • Create, maintain, expand, protect, restore, or modernize the production capabilities of domestic suppliers whose technologies and products are critical to the nation’s security.
  • Increase the supply, improve the quality, and reduce the cost of advanced materials and technologies.
  • Reduce U.S. dependency on foreign sources of supply for vital materials and technologies.
  • Strengthen the economic and technological competitiveness of the U.S. defense industrial base.

Title III provides a set of broad economic authorities, found nowhere else in law, to incentivize the creation, expansion, or preservation of domestic manufacturing capabilities for technologies, items, and materials needed to meet national security requirements. The goal is not the production of materials or items themselves, but the creation or expansion of the industrial capacity to produce these items and materials. Title III mechanisms can include

purchases and purchase commitments (not commonly used),

installation of production equipment,

development of substitutes (most commonly used via R&D contracts), or

loans and loan guarantees (not used since 1992 by memorandum of understanding with the DoD General Counsel).

Industrial Base Analysis and Sustainment Fund (IBASF) projects. The IBASF is part of DoD’s efforts to fortify the industrial base, particularly with regard to DoD’s supply chain. To that end, the focus of the IBASF is to “preserve or improve the [industrial base’s] capability to sustain readiness by mitigating risks and issues which diminish industrial capabilities.”[96] IBASF projects are intended to support “last resort” efforts when it would prove costly, difficult, or perhaps even impossible to restore the capability, skill, or manufacturing process to produce a required defense system or item within a defense system. Criteria used to support IBASF project selection are as follows:

    • Fragility and criticality of the capability[97]
    • Existence of a plan to preserve, transform, or innovate an existing capability that has a strong likelihood of being required within the next 5 years
    • Likelihood that the capability will be lost if the project is not funded
    • Overall cost of undertaking a project to preserve the capability in comparison to the cost of having to reestablish the capability that has been lost
    • Number of projects supported by the capability; those supporting numerous programs or services take precedence over those supporting a single program.[98]
    • Guidance for the submission of proposals for consideration for FY15 projects indicated that total funding for a proposed project should not exceed $2 million.[99]

Foreign Comparative Testing (FCT) program. The FCT program’s mission is to test items and technologies from foreign allies with a high-technology readiness level to determine whether the items could satisfy U.S. military requirements or address mission-area shortcomings and could do so more quickly and economically than would otherwise be possible.[100] The program has reaped substantial savings by avoiding R&D costs, lowering procurement costs, reducing risk for major acquisition programs, and accelerating the fielding of equipment critical to the readiness and safety of U.S. operating forces. Although the aim of the FCT program is to improve the U.S. Armed Forces’ operational performance, this leveraging of foreign R&D has benefited the U.S. taxpayer. In addition, the FCT program has served as a catalyst for industry teaming arrangements, which have been productive for both U.S. and foreign industries in an increasingly competitive global market, helping to build a robust U.S. defense industrial base. Foreign items are nominated for inclusion in the FCT program by a sponsoring organization within DoD. The OSD Comparative Technology Office funds testing and evaluation; the military services fund all procurements that result from a successful test. DMSMS resolutions that have foreign involvement can use this program to qualify technology or items for procurement.

Defense Acquisition Challenge (DAC) program. The DAC program, initiated by the 2003 Defense Authorization Act, provides opportunities for introducing innovative and cost-saving commercial technologies or products into DoD acquisition programs.[101] Furthermore, the DAC program is especially designed to give small and medium-sized companies the opportunity to introduce new technologies and inject innovation into DoD programs. To do so, the DAC program provides any person or activity, within or outside DoD, the opportunity to propose alternatives, known as “challenge proposals,” to existing DoD programs that could improve performance, affordability, manufacturability, or operational capability of the systems acquired by that program. The program can fund the selection, testing, and insertion of the production-ready technologies into DoD systems, but must prove cost savings and readiness improvements, which would include many DMSMS efforts. The DAC program is focused on reducing life-cycle or procurement costs, enhancing standardization and interoperability, promoting competition by qualifying alternative sources, and improving the U.S. military industrial base. The program uses annual solicitations to request challenge proposals, which usually require a government and industry partner to ensure successful transition. The DAC program requires a commitment from the program of record to procure the technology if the proposed challenge alternative is successfully developed and tested. The DAC is currently finishing up projects under contract; it is unfunded for new projects.

DLA sustaining engineering program. DLA Land and Maritime’s sustaining engineering program is a means to secure funding for proposed efforts to upgrade items of supply; address obsolescence, item-level reliability, and maintainability issues; or develop new or improved items to replace existing inventory.[102] Sustaining engineering proposals are judged on the basis of the extent to which they do the following:

    • Involve an item managed by DLA Land and Maritime
    • Have demonstrated potential for ROI of at least 10:1 over the anticipated life cycle of the system
    • Make a positive impact on operational readiness
    • Make a positive impact on administrative or procurement lead-time
    • Make a positive impact on item demand
    • Make a positive impact on unit price
    • Make a positive impact on overall cost of ownership of the supported end item or life
      cycle
    • Reduce field or depot maintenance actions
    • Improve competitive position and sourcing issues.

Army, Navy, and Air Force working capital funds (WCFs). WCFs are revolving funds used to operate each service’s supply system. The funds generate adequate revenue to cover the full costs of their operations and to finance their continuing operations. WCF logistical operations projects may be used to resolve supportability deficiencies that result in increased cost or mission degradation. Examples of the beneficial results of such projects are mitigation of obsolescence; improvement of reliability, maintainability, and supportability; and reduction of the life-cycle costs of secondary items. Each service has different mechanisms for obtaining WCF resources:

    • The Air Force has no Air Force-wide programs.[103]
    • The Navy has a logistics engineering change proposal (LECP) program. Projects must be related to reliability or maintainability and designed to reduce support costs while maintaining or improving safety and performance. The project must break even in 7 years. If the project is selected, the LECP program will cover the costs of the engineering change proposal (ECP).[104]
    • The Army has four different types of WCF projects, each with different criteria:[105]
      • The Operating and Support Cost Reduction (OSCR) program is designed to “save the field money” by reducing secondary item acquisition costs, extending the life of the item, and reducing the number of events (removals or repairs) and the cost per event. OSCR promotes life-cycle cost savings and avoidance in the field by redesigning, prototyping, and testing spare parts for fielded systems. OSCR projects involve an individual item or assembly of items, prototype, or test. The program will not fund production or implementation of kits, nor will it fund studies. Eligibility for the program requires a validated economic analysis.
      • The Reliability Improvement program is a continuous process to look for opportunities to decrease demand, improve operations, and improve reliability. Projects must provide immediate help to the soldier and must show an ROI. This program will not fund production and studies.
      • The Obsolescence program is designed to mitigate obsolescence; improve reliability, maintainability, and supportability; or reduce the life-cycle cost of secondary items. Projects must provide an ROI. This program will not fund production, implementation of kits, and studies.
      • The Product Improvement Pilot program provides funding for product improvements such as improving reliability and maintainability, extending useful life, enhancing safety, and lowering maintenance costs. This program cannot be used to significantly change the performance envelope of an end item, and individual item costs may not exceed $1 million.

Aviation Component Improvement Program (AvCIP). AvCIP applies to the Navy and Air Force. Within the Naval Air Systems Command (NAVAIR), AvCIP deals with common and unique avionics on in-production and fielded systems. It can fund nonrecurring engineering activities such as redesign or modification, prototype development, T&E, integration, and technical documentation in partnership with the Naval Supply Systems Command for repairable items and with DLA for consumable items. To qualify for funding, a project must address a critical near-term issue concerning reliability, maintainability, or DMSMS; must result in cost avoidance by being proactive; and must achieve significant gains in warfighting capability or readiness.[106] (No evidence exists to indicate that AvCIP will be used by the Air Force for a DMSMS issue.)

7.2. Implement DMSMS Resolution

Upon acceptance and funding, the case enters the implementation phase. This phase should follow the program’s standard process for updating configurations and engineering modifications. Some changes may be largely clerical and not require a specified process for updates, while other changes will require a formal change process. For instance, most updates that affect major configuration changes or engineering modifications flow through the appropriate level of the ECP process. The standard ECP process ensures that all changes and qualifications satisfy the program’s requirements.

It is usually a mistake for the DMT to assume that the program’s standard processes will be problem free. As a best practice, the DMT should be involved in the following ways during implementation:

Ensure that all stakeholders understand their roles and responsibilities for implementation. These roles and responsibilities should have been established when the DMT was formed.

Ensure that the implementation steps are defined.

Verify that appropriate technical actions (e.g., qualification of the new item or procurement of the item) were successfully carried out.

Monitor the process.

Obtain feedback on the project status to ensure maintenance of full operational availability during implementation. If the project is behind schedule, the DMT may be required to determine supplemental mitigation actions.

Update BOMs being monitored to reflect the configuration changes once the project is completed.

In some cases, the DMT may have difficulty performing these functions. A champion in the program office is critical to implementation success. The champion should be at a high enough level to demand attention and be knowledgeable about the importance of an obsolescence program to take ownership of it and justify it to program leaders. The champion is often the catalyst that brings all the functional disciplines together toward the common goal of managing the availability of the program and is the person to resolve difficulties faced by the DMT in carrying out its DMSMS management responsibilities.

In some cases, the DMT is asked for advice on procedures to deal with issues that arise during implementation. Below are examples of some issues, along with some considerations about ways to resolve them:

Improving the priority of DMSMS management with the contracting officer. The DMT should invite the contracting officer to its meetings and explain his or her roles and responsibilities. The DMT should ensure that the contracting officer understands what is needed and the associated urgency.

Buying in advance of need. According to 31 U.S.C §1502 (a), the balance of an appropriation or fund, limited for obligation to a definite period, is available only for payment of expenses properly incurred during the period of availability or to complete contracts properly made within that period of availability and obligated consistent with §1501 of this title. The appropriation of funds is not available for expenditure for a period beyond the period otherwise authorized by law. A “bona fide need” statement must be documented for the General Counsel’s office. That statement should explain the DMSMS situation and describe how and why the resolution option was determined. Limitation on the acquisition of excess supplies, 10 U.S.C. §2213, may also be an issue. That section of public law also provides the basis for exceptions to the limitation.

Procuring sufficient stock to end of need. This is a straightforward calculation involving the use of the Poisson distribution with the appropriate confidence limits, operating tempo, number of units in service, and failure rates (either actual or predicted). At issue is the uncertainty in the input.

Determining the appropriate contract vehicle. A contract must be in place with the organization that will implement the resolution (e.g., the organization performing the nonrecurring engineering or the organization that will sell the items). Restrictions exist on the use of all appropriations. In some cases, additional procurement funds are necessary; in others, research, development, test, and evaluation funding is required for redesign, material substitution, or qualification of a new source. The contracting office can provide advice on this subject.

Managing inventory. Some issues are associated with receiving, inspecting, and storing items. The program should plan to follow the official rules on this subject. If these problems cannot be solved, the resolution option may not be viable. Options for storage locations include suppliers, prime contractors, and DoD component storage facilities.[107]

Appendix A. Obsolescence and Its Relationship to DMSMS

Obsolescence is not synonymous with DMSMS. Instead, it is less definitive and is situationally dependent in that an item can be obsolete from one perspective, but not from another. In the context of DMSMS management, an item is obsolete if it is out-of-date and superseded by something new. Below are key underlying causes of an item being out-of-date:

Technology. A technology is obsolete when the use of a newer technology becomes broadly preferred over the old, even if the old technology still functions and can be produced and purchased for certain unique situations. For example, videocassette recorders and players became technologically obsolete, when DVD recorders and players superseded them.

Function. An item is obsolete functionally if it no longer functions as intended because of hardware, software, or requirements changes to the item. Such an item may still be available commercially. For example, a videocassette tape (especially one in beta format) could be considered to be obsolete functionally, because players are no longer available for purchase to extract the tape’s content.

Regulation. Regulations that ban the use of items or substances lead to their obsolescence. For example, Freon use has been banned because of its ozone-depleting characteristics. Similarly, the purchase of rare-earth elements such as neodymium or ytterbium from China has been banned.

Supportability. An item may be obsolete if it is no longer supportable. An example is commercial software, which continually needs product support to correct errors, to defend against vulnerabilities, and, in some cases, to maintain licenses. Unsupportable software is obsolete. Beyond software, if the necessary item test capability is no longer available, then the item may no longer function properly and, therefore, could be considered obsolete.

Market demand. A product becomes obsolete when there is no longer a demand for it, because, for example, it is no longer desirable even though it may still be available for purchase. Leisure suits are an example. Another example is a product that is no longer profitable to produce because of low demand.

Obsolescence may be planned or unplanned. An example is a relatively new home computer printer that is technologically equivalent to the latest ones on the market but requires proprietary ink cartridges that are different from the ones used in the most recent model of the printer. The manufacturer may deliberately stop manufacturing those cartridges (thereby making the printer functionally obsolete) to force people to purchase the most recent printer model.

A high degree of overlap exists between obsolete items and DMSMS. Figure 18 notionally depicts their relationship.

Figure 18. Notional Relationship between DMSMS and Obsolescence

Notional Relationship between DMSMS and Obsolescence

An item may be obsolete, but if it is still in production, there is no DMSMS issue as long as the production capability or capacity can meet the demand. For example, hand pumps for water are still made for places where power is not available for an electric pump. Another example is a situation of an obsolete computer that is out of production, but it is not a DMSMS issue because there is sufficient stock in inventory to meet all future demands. In the first example, no DMSMS case would be opened because the item is still in production. In the second example, a DMSMS case would be opened, but no resolution would be needed. Changing the circumstances of the second example can create a situation in which a DMSMS problem will evolve over time. If there were not sufficient inventory to meet future demands, DoD might be able to repair the computer instead of replacing it. If that were the case, there would be no DMSMS problem. However, a DMSMS issue would occur if the repair parts were also obsolete, if the know-how (e.g., skills) to make the repair was lacking, or if the ability to test the system (e.g., the test equipment) after the repair was unavailable.

Finally, a non-obsolete item may have a DMSMS issue. For example, market factors may drive a supplier out of a particular line of business, a supplier may declare bankruptcy, a natural disaster may affect production, or a buyout of a sole-source provider may lead to temporary or permanent termination of production of a particular product. Some temporary DMSMS issues may be due to allocation of a scarce item. In this situation, some systems may be faced with a DMSMS issue, while others may not.

Not all obsolescence results in DMSMS issues, and not all DMSMS issues result from obsolescence. However, most DMSMS issues result from some form of obsolescence.

Appendix B. Developing DMSMS Workforce Competencies

This appendix outlines the recommended training required to achieve entry-level, technician-level, and leadership-level competencies and experience associated with the roles and responsibilities of DMSMS practitioners.

Entry-level training provides an individual with basic knowledge of the processes and procedures required to establish and maintain a robust DMSMS management program. An individual with entry-level competency is not expected to be proficient in analyzing DMSMS issues or in leading a DMSMS management program. An individual with entry-level competency should perform DMSMS analysis only in conjunction with an individual possessing technician-level or leadership-level competency. An individual with leadership-level competency should review all data before they are submitted for approval. An individual with entry-level competency should assist with DMSMS management functions under the supervision of an individual with leadership-level competency.

An individual with technician-level competency is capable of leading, conducting, explaining, and defending the results of any analyses that he or she has led. DMSMS analysts with technician-level competency should submit analyses to a person with a DMSMS leadership-level competency for approval. A DMSMS analyst with a technician-level competency should be capable of establishing and maintaining a robust DMSMS management program with minimal oversight.

An individual with leadership-level competency is well versed, trained, and experienced in DMSMS analyses, applications, and management practices. This is the desired level for DMT leaders. A leadership-level analyst will have developed and led numerous DMSMS efforts and must be conversant in all aspects of DMSMS processes and policy. The leadership-level analyst is ultimately responsible for planning the overall DMSMS effort for a program.

DMSMS competency is not developed in a vacuum. It must be obtained in conjunction with DAU DAWIA certifications for government employees and a company analog for industry.[108]

To achieve DMSMS entry-level competency, an individual should have the following DAU training beyond DAWIA level 1 certification:

DMSMS: What Program Management Needs to Do and Why (CLL 200; forthcoming)

DMSMS Fundamentals (CLL 201)

DMSMS Fundamentals: Executive Summary (CLL 202; forthcoming)

DLA DMSMS Essentials (CLL 203)

DMSMS Case Studies (CLL 204)

DMSMS for the Technical Professional (CLL 205)

Defense Logistics Agency Support to the PM (CLL 002)

Market Research (CLC 004)

Market Research for Technical Personnel (CLE 028)

COTS Acquisition for Program Managers (CLM 025)

Preventing Counterfeit Parts from Entering the DoD Supply System (CLL 032)

Counterfeit Prevention Awareness (CLL 062)

Introduction to Reducing Total Ownership Costs (CLM 021)

Fundamentals of Systems Engineering (SYS 101).

To achieve DMSMS technician-level competency, an individual should have the following DAU training beyond DAWIA level 2 certification:

All entry-level competency requirements

Business Case Analysis (CLL 015)

Technology Refresh Planning (CLL 019)

Independent Logistics Assessments (CLL 020)

Reliability and Maintainability (CLE 301)

Contracting for the Rest of Us (CLC 011)

Introduction to Parts Management (CLL 206)

Improved Statement of Work (CLM 031)

Technical Reviews (CLE 003)

Modular Open Systems Approach to DoD Acquisition (CLE 013)

Risk Management (CLM 017)

Acquisition Fundamentals (ACQ 101)

Performance Based Logistics (LOG 235)

Lead-free Electronics Impact on DoD Programs (CLL 007).

To achieve DMSMS leadership-level competency, an individual should have the following DAU training beyond DAWIA level 3 certification:

All technician-level competency requirements

Configuration Management (LOG 204)

Reliability Centered Maintenance (CLL 030)

Intermediate Systems Planning, Research, Development and Engineering (SYS 202).

Some of the above courses are core requirements for DAWIA certifications. Table 14 lists the courses, beyond DAU certifications, needed to achieve DMSMS competency. Specifically, the table identifies DMSMS competency courses in life-cycle logistics (LCL); systems planning, research, development, and engineering (SPRDE)–science and technology management (STM); SPRDE–SE; production, quality, and manufacturing (PQM); program management (PM); and T&E. All of the courses identified are self-paced, computer-based training and accessible via the DAU Virtual Campus link (https://learn.dau.mil).

Table 14. Courses beyond DAU Certifications Needed to Achieve DMSMS Competency

Course

LCL

STM

ENG

PQM

PM

T&E

DMSMS Entry Level

CLC

004

X

X

X

X

X

X

CLE

028

X

X

X

X

X

X

CLL

200

X

X

X

X

X

X

CLL

201

X

X

X

X

X

X

CLL

202

X

X

X

X

X

X

CLL

203

X

X

X

X

X

X

CLL

204

X

X

X

X

X

X

CLL

205

X

X

X

X

X

X

CLL

002

X

X

X

X

X

X

CLL

032

X

X

X

X

X

X

CLL

062

X

X

X

X

X

X

CLM

025

X

X

X

X

X

X

CLM

021

X

X

X

X

X

X

ENG

101

Lvl 1 Core

Lvl 1 Core

Lvl 1 Core

X

Lvl 1 Core

Lvl 1 Core

DMSMS Technician Level

ACQ

101

Lvl 1 Core

Lvl 1 Core

Lvl 1 Core

Lvl 1 Core

Lvl 1 Core

Lvl 1 Core

CLC

011

Lvl 2 Core

X

X

X

X

X

CLE

301

X

X

X

X

X

Lvl 2 Core

CLE

003

X

X

Lvl 2 Core

Lvl 1 Core

X

Lvl 2 Core

CLE

013

X

X

X

X

X

X

CLL

015

Lvl 3 Core

X

X

X

X

Lvl 3 Core

CLL

019

X

X

X

X

X

X

CLL

020

Lvl 3 Core

X

X

X

X

X

CLL

206

X

X

X

X

X

X

CLL

007

X

X

X

X

X

X

CLM

031

X

X

X

X

X

Lvl 3 Core

CLM

017

X

X

Lvl 1 Core

Lvl 1 Core

X

X

LOG

235

Lvl 2 Core

X

X

X

X

X

DMSMS Leadership Level

LOG

204

Lvl 2 Core

X

X

X

X

X

CLL

030

X

X

X

X

X

X

SYS

202

X

X

Lvl 2 Core

X

Lvl 3 Core

Lvl 2 Core

Appendix C. Contracting

DMSMS management can be performed (1) by a program using government personnel (and SE technical assistance support), (2) by the prime contractor and its subcontractors,[109] or (3) by independent contractors.[110] The entity managing DMSMS issues for a program has no bearing on the robustness of that effort.

Regardless of who performs DMSMS management, the government remains responsible for ensuring that DMSMS risk is effectively managed. This is accomplished through the DMP, which emphasizes how a robust DMSMS management effort will reduce future obsolescence-related costs and minimize detrimental impacts on materiel readiness, operational mission capability, and safety of personnel. The DMP identifies all of the program’s DMSMS planning objectives, the approach to be pursued, and the entities that will perform the functions necessary to pursue the approach (Section 3). If contractors perform the work, the DMP should describe the nature and extent of government oversight.

When a program decides to use a prime contractor (and its subcontractors) or an independent contractor for DMSMS management, contracts containing DMSMS-related requirements (including government access to sufficient DMSMS-related information), combined with government oversight, provide the basis for ensuring that DMSMS management is effective. This appendix focuses on factors and examples a program should consider incorporating into contracts with a prime contractor (and its subcontractors) or an independent contractor provider of DMSMS management.

C.1. Determining Whether to Contract for DMSMS Management

C.1.1. General Factors to Consider

Early in a program’s life cycle, a decision should be made regarding who will have primary responsibility to perform DMSMS management in support of the program. This subsection includes a number of factors a program should consider in determining whether to keep DMSMS management solely within the government or to contract with a prime contractor (and its subcontractors) or an independent contractor.

C.1.1.1. Availability of Resources

Using a contractor (whether a prime contractor and its subcontractors or an independent contractor) for DMSMS management requires funding. In some instances, the program office may already have funding available associated with a design, production, or sustainment contract. In those cases, such contracts and funding could be used to support a prime contractor and its subcontractors as the DMSMS management provider for the program. Using an independent contractor for DMSMS management normally requires a vehicle that is not with the prime contractor. There may or may not be an existing contract that can be leveraged for this purpose. If funding available for such contracts is limited, internal government resources can usually be obtained to perform DMSMS management internal to the program.

C.1.1.2. A Contractor’s DMSMS Management Capability

If a program is considering the use of a prime contractor (and its subcontractors) to provide DMSMS management, a key initial consideration is the DMSMS management capability of that contractor. If the contractor has a robust DMSMS management program in place, then the program might want to leverage that existing capability, rather than establish an entirely duplicative government-run DMSMS management program. In this case, the government might want the prime contractor to manage and mitigate DMSMS issues for the program, while the program establishes a way for the government to oversee the prime contractor’s DMSMS management efforts. However, if a prime contractor’s internal DMSMS management program does not appear to be sufficiently effective, then the government may need to establish its own more robust DMSMS management program.

If a program is considering the use of an independent contractor, it should consider the additional capabilities such an independent contractor might offer, as compared to other DMSMS management providers. Below are some questions that a program should consider:

Is the independent contractor offering DMSMS management capability that is not available through the prime contractor or the government?

What kind of capability and access does the independent contractor have regarding the receipt of PDNs or the ability to manually research items?

Is an independent contractor needed if the prime contractor and its subcontractors have an existing, robust DMSMS management capability?

Have other programs used this independent contractor? How have these other programs evaluated the independent contractor’s performance?

C.1.1.3. Acquisition Phase

During the design and production phases, the program already has a prime contractor under contract to develop and manufacture the system. DMSMS management and mitigation should inherently be a part of those efforts; therefore, the prime contractor and its subcontractors are in a natural position to perform these activities. In such a case, the government should ensure that a contractual requirement exists for the prime contractor to develop a DMP establishing the DMSMS management objectives and approach for the program. There is, however, the potential for conflicting forces to be at work, if DMSMS management responsibility is assigned to the prime contractor. The business objectives of any for-profit company include lowering costs and increasing revenue, whereas implementing DMSMS management practices requires expending time and resources. The contractor’s leaders must believe that DMSMS management is a good business practice, because it makes products more attractive to buyers through the reduction of total ownership cost. Consequently, the contractor’s products will have a competitive advantage.

Effective DMSMS management in the design phase is critical. If obsolescence is “designed in,” then the program will face large costs to mitigate these problems later in the life cycle. The prime contractor and its subcontractors are in a good position to manage DMSMS issues during design, because of their familiarity with the current configuration of the design (including the potential for rapidly changing items). The government must remain in a position to carefully oversee what the prime contractor and its subcontractors do with regard to DMSMS management, including the identification and resolution of current and near-term obsolescence issues. Simply receiving an item obsolescence report at a design review is not sufficient oversight; the government should have a thorough understanding of and maintain visibility into the DMSMS management processes being used by the prime contractor and its subcontractors.

Although the system’s parts lists and BOMs should be stable by the time the program has entered the production phase, the government will still have limited experience with the system. Consequently, the prime contractor may continue to play a key role in DMSMS management. One of the areas that the government should include in its oversight is laying the appropriate groundwork to transition DMSMS management to the entity most appropriate to perform that role during sustainment.

Typically, the government uses a combination of three different sustainment strategies:

In-house support through a service depot or supply system or through DLA

Non-PBL contractor support services

PBL contracts.

In the first case, the government will typically not use the prime contractor and its subcontractors for DMSMS management. The government will either use its own in-house capability or combine its in-house capability with an independent third-party contractor. The use of non-PBL contract support depends on the scope of work. For example, a contractor operating a repair depot on either a cost-reimbursable or fixed-price basis could be asked to perform DMSMS management. If the work is more limited (e.g., interim or emergency support), then DMSMS management could be out of scope for that contract.

PBL is a sustainment strategy that places primary emphasis on optimizing system support to meet the needs of the warfighter. PBL specifies outcome performance goals of systems, ensures that responsibilities are assigned, provides incentives for attaining those goals, and facilitates the overall life-cycle management of system reliability, supportability, and total ownership costs. It is an integrated acquisition and logistics process for buying system capability. Generally, PBL contracts are long term (5–10 years) and require that the provider manage many aspects of product support throughout the life cycle. A properly structured PBL contract contains DMSMS management requirements.

In a theoretical sense, PBL incentivizes the provider to maintain a proactive DMSMS management program to achieve the required performance outcomes. This is not always true in practice. The contractor will take the most cost-effective approach to meeting its performance requirements within the terms and conditions of its contract. This approach may not be the most cost-effective for the government when the contract is completed.

C.1.1.4. Conflicts of Interest

Whenever the government contracts for services, it must determine whether any potential conflicts of interest exist and then manage those situations effectively. For example, there could be a situation in which a nongovernment DMSMS management provider has a business interest (e.g., potential additional revenue) regarding a specific resolution option, as compared to other options. This situation does not necessarily preclude the use of that DMSMS management provider; however, it does place an additional burden on the government to appropriately oversee and understand the potential repercussions of decisions and to factor them into the program’s decision-making process.

C.1.2. Considerations by Function

Below are some contracting considerations for selected activities associated with the DMSMS management steps:

Prepare—DMSMS management program infrastructure.

    • Define obsolescence. The government should determine what constitutes obsolescence for the program, and any contractor responsible for DMSMS management activities should agree to this definition. For example, for the purposes of a contract, hardware, software, and firmware could be considered obsolete when the item can no longer be procured from the prime contractor, as identified in the current TDP or product specification.
    • Determine whether the program is concerned with critical materials in its supply chains. If programs have a reason to be concerned about critical materials in their supply chains, they should consider adding a contract clause to identify the extent to which such materials are in the supply chains for the subsystems of interest. This is often done today to be compliant with REACH and RoHS reporting certification and to meet PESHE requirements. This effort, however, does not normally identify the suppliers of the critical materials nor does it identify the specific critical material content. Typically engineering estimates are made to estimate the total amount of material included. If a more extensive understanding of the supply chain were considered necessary, the program office should limit the list of materials to be tracked in this way.
    • Develop a DMSMS management plan. Every organization (government and contractor) conducting DMSMS management should have its own DMP. Contractors should be required to use SAE International Standard, SAE-STD-0016, “Standard for Preparing a DMSMS Management Plan.”
    • Continually track and manage DMSMS cases. This process may be performed by any combination of the three categories of providers: the government, the prime contractor and its subcontractors, or an independent contractor. Regardless of the DMSMS management provider, the government should ensure that it maintains complete records.
    • Report performance and track cost metrics. This may be performed by any combination of the three categories of providers: the government, the prime contractor and its subcontractors, or an independent contractor. The government should define the format to be used. Regardless of the DMSMS management provider, the government should ensure that it maintains complete records.
    • Manage subcontractor’s DMSMS management programs. This is a required DMSMS management function for the prime contractor. Overseeing the prime contractor’s management of its subcontractors’ DMSMS management programs is also a government responsibility. This applies whenever DMSMS management is conducted by the prime contractor and its subcontractors. Therefore, it is important to include language for the prime contractor that requires flowing appropriate DMSMS management language down the supply chain. In addition, supplier selection should consider the vendor’s past DMSMS-related performance. Government oversight should also include such supplier-selection activities.

Identify—DMSMS monitoring and surveillance.

    • Deliver item data. The prime contractor and subcontractors should develop, maintain, and deliver item data to enable the identification, forecasting, and management of obsolescence issues and mitigation. Item data include both indentured and flat BOMs or preferred parts lists for all specified subsystems down to the assembly level, depending on what is available given the current stage in the life cycle. The program must receive this data in order for a robust DMSMS management program to be successful.
    • Continually monitor BOMs. This process may be done by any combination of the three categories of providers: the government, the prime contractor and its subcontractors, or an independent contractor. Regardless of the DMSMS management provider, the government should ensure that it maintains complete records and that there is regular feedback and visibility to the program office. When this process is performed by the prime contractor and its subcontractors, there should be a process to identify and notify the government of pending and emergent obsolescence issues, supplier recall notices, and emergent vendor-implemented changes associated with the system baseline. The prime contractor should include a process for similarly notifying subcontractors.

Assess—DMSMS impact assessment. The key activity in this step is to continually assess DMSMS impacts. This may be done by any combination of the three categories of providers: the government, the prime contractor and its subcontractors, or an independent contractor. This applies both at the item level and at higher levels of assembly. Regardless of the DMSMS management provider, the government should ensure that it maintains complete records. Government contributions concerning programmatic and logistics factors are necessary.

Analyze and implement—DMSMS resolution determination and implementation of DMSMS resolutions. The key activity in this step is to identify cost-effective solutions. This may be done by any combination of the three categories of providers: the government, the prime contractor and its subcontractors, or an independent contractor. Regardless of the DMSMS management provider, the government should ensure that it maintains complete records. Government contributions concerning programmatic and logistics data, cost factors, and technology roadmaps are necessary.

C.1.3. Exit Clauses

Exit clauses for DMSMS management are a critical element in any contract, including PBL contracts. The primary purpose of this type of clause is to mitigate the risk of DMSMS issues at the end of the contract period of performance. The exit clause requires the contractor to ensure all known and forecasted DMSMS issues have been identified and have mitigation plans, so that the program office is not left with a system that is not supportable or sustainable due to DMSMS issues. It ensures that the information needed to manage DMSMS issues is provided to the program office. Exit clauses establish procedures and time frames to ensure the orderly and efficient transfer of performance responsibility upon completion or termination of the contract. The exit clauses should require delivery of those items, identified in the SOW or statement of objectives (SOO), within the negotiated contract price.

Exit clauses are necessary but not sufficient to guarantee the transition of DMSMS management responsibilities from one provider to another. As part of its contractor oversight, DoD should develop an understanding of all DMSMS management activities being performed by the contractor. In that way, DoD will be in the best position to ensure that effective DMSMS management continues throughout a transition.

C.2. DMSMS Management Activities in Contracts by Life-Cycle Phase

When contracting for DMSMS management, a program should develop a contract that clearly conveys DMSMS management requirements. (The program also should state, in its RFP and other communications, that DMSMS-related criteria will be used in source selection.) This ensures that the contractor knows its specific responsibilities for DMSMS and that the government has access to the information it needs for adequate oversight. The following is a list of representative DMSMS management activities, by acquisition phase, that a program should consider when developing contracts to cover DMSMS management:

Design

    • The prime contractor and its subcontractors should minimize obsolescence throughout the contract period of performance by selecting products that will avoid or resolve hardware, software, and firmware obsolescence issues. This may be pursued through various DMSMS design considerations, such as selecting technologies or items that are not near their EOL, parts management, open systems design, and so on, as described in Section 2.
    • The prime contractor and its subcontractors should determine the most cost-effective resolution to obsolescence issues. For the purposes of the contract, hardware, software, and firmware should be considered obsolete when the item can no longer be procured from the OCM as identified in the current TDP.
    • The prime contractor and its subcontractors should flow down DMSMS management requirements to their suppliers, who should flow down requirements in a similar manner.
    • The prime contractor should deliver a parts list and indentured BOM (or notional versions, if that is all that is available at the time), in accordance with DI-SESS-81656A, to the program office at agreed-upon points in the technical schedule.
    • The prime contractor and its subcontractors (and possibly an independent third-party contractor if one is to be used) should monitor the availability of items (with agreed-upon frequency of update) and provide the results to the program office. The government should be notified of pending and emergent obsolescence issues, supplier recall notices, and emergent vendor-implemented changes.
    • The prime contractor and its subcontractors should resolve and document any DMSMS issues prior to the delivery of design. (Supplemental funding for the contractor may be necessary.)
    • The prime contractor should deliver a production roadmap for low rate initial production.
    • The prime contractor should deliver a supportability roadmap (with agreed-upon frequency of updates).
    • The prime contractor should deliver a description of how the system is envisioned to be supported after fielding, including the process for assigning the source of repair.
    • The prime contractor and its subcontractors (and possibly an independent third-party contractor if one is to be used) should participate in the government-contractor obsolescence working group (with frequency of face-to-face and telephone communications specified).

Production

    • The prime contractor and its subcontractors should minimize obsolescence throughout the contract period of performance by selecting suppliers that will avoid or resolve hardware, software, and firmware obsolescence issues.
    • The prime contractor and its subcontractors should determine the most cost-effective resolution to obsolescence issues. For the purposes of the contract, hardware, software, and firmware should be considered obsolete when the item can no longer be procured from the OCM as identified in the current TDP.
    • The prime contractor and its subcontractors should flow down DMSMS management requirements to their suppliers, who should flow down requirements in a similar manner.
    • The prime contractor should deliver a parts list and indentured BOM, in accordance with DI-SESS-81656A, to the program office if it has not already been delivered.
    • The prime contractor and its subcontractors (and possibly an independent third-party contractor if one is to be used) should monitor the availability of items (with agreed-upon frequency of update) and provide the results to the program office. The government should be notified of pending and emergent obsolescence issues, supplier recall notices, and emergent vendor-implemented changes.
    • The prime contractor and its subcontractors should solve and document any DMSMS issues prior to delivery of the system for fielding.
    • The prime contractor and its subcontractors (and possibly an independent third-party contractor if one is to be used) should participate in the government-contractor obsolescence working group (with frequency of face-to-face and telephone communications specified).
    • The prime contractor and its subcontractors should develop and execute a plan to transition DMSMS management to the sustainment provider.

Sustainment

    • The sustainment provider should minimize obsolescence throughout the contract period of performance by selecting suppliers that will avoid or resolve hardware, software, and firmware obsolescence issues.
    • The sustainment provider, especially in the PBL case, should determine the most cost-effective resolution to obsolescence issues. For the purposes of the contract, hardware, software, and firmware should be considered obsolete when the item can no longer be procured from the OCM as identified in the current TDP.
    • The sustainment provider, especially in the PBL case, should flow down DMSMS management requirements to suppliers, who should flow down requirements in a similar
      fashion.
    • The sustainment provider (and possibly an independent third-party contractor if one is to be used) should monitor the availability of items (with agreed-upon frequency of update) and provide the results to the program office. The government should be notified of pending and emergent obsolescence issues, supplier recall notices, and emergent vendor-implemented changes.
    • The sustainment provider (and possibly an independent third-party contractor if one is to be used) should participate in the government-contractor obsolescence working group (with frequency of face-to-face and telephone communication specified).
    • The sustainment provider should recommend DMSMS resolutions.

C.3. Examples of DMSMS Management Contract Language

This section contains several examples of how DMSMS management responsibilities have been documented in contract language:

Example 1 contains contract language about the DMP.

Example 2 contains DMSMS resolution-related contract language.

Example 3 contains SOW/SOO language on BOM, CM, and DMSMS issue forecasting and notifications-related requirements.

Example 4 contains language detailing intent to use DMSMS management factors in review of approaches.

Example 5 contains contract language related to the assignment of DMSMS management responsibilities support for design and production.

Example 6 contains language pertaining to the assignment of DMSMS management responsibilities support for production.

Examples 7–11 contain contract language detailing the assignment, to a contractor, of either generic responsibility for obsolescence management or the responsibility for multiple DMSMS-related activities.

Examples 12 and 13 contain contract language detailing the assignment, to a contractor, of responsibility for obsolescence management during production.

Example 14 shows language that a prime contractor or a subcontractor could use to flow down DMSMS requirements to a supplier.

Examples 15 and 16 contain contract language pertaining to deliverable and mitigation information for chemicals and other critical materials.

Example 2 includes a statement about monitoring, identifying, and planning resolutions. Generic examples 17, 18, 19, and 20 are for contract language to implement specific resolutions:

Example 17 contains contract language for life-of-need buys with a maximum funding liability.

Example 18 contains contract language for a redesign.

Example 19 contains contract language for a redesign in association with a life-of-need buy.

Example 20 contains contract language for reverse engineering.

The DMSMS management program should ensure that the chosen contract language clearly specifies the DMSMS management responsibilities being assigned to the contractor and enables the government access to the information it needs to maintain effective DMSMS management oversight. The examples should be tailored to the specific situation. In addition to the examples here, the Navy has developed example Contract Data Requirements Lists (CDRLs) for an AoA, BOM, DMP, and report. They are designed to assist programs with developing their own deliverables. These CDRLs can be found on the DKSP.

Example 1. DMSMS Management Plan

The Contractor shall develop and submit as part of its proposal (with an advance copy supplied to the Government at time of cost estimate submission), an Obsolescence and DMSMS Management Plan for managing the loss, or impending loss, of manufacturers or suppliers of parts and/or material required for performance of this contract.

At a minimum, the plan shall address the following:

  • Means and approach for providing the Government with information regarding obsolescence and DMSMS issues
  • Planned resolution of current obsolescence and DMSMS issues
  • Parts list screening
  • Parts list monitoring
  • Receiving, processing and disseminating Government-Industry Data Exchange Program (GIDEP) DMSMS Notices
  • Receiving, processing and disseminating Defense Logistics Agency (DLA) DMSMS Alerts
  • Communication with and availability of information to the Government
  • Means and approach for establishing obsolescence and DMSMS solutions
  • Plan for conducting DMSMS predictions.

Example 2. DMSMS Resolution-Related Contract Language

Company X is responsible to provide support for all valid requirements including those instances where DMS/MS and obsolete piece part issues impact, delay, or prohibit the acquisition of necessary piece parts except as discussed below. Where DMS/MS solutions have been funded under Program Office funding and separate contract, Company X is responsible to monitor, identify and plan the resolution of DMS/MS and parts obsolescence issues and should plan far enough in advance to alleviate DMS/MS and parts obsolescence occurrences. Company X may propose and submit DMS/MS resolution plans to the … Program Office and [Service inventory control point program manager] which include Life-of-Type buys and Bridge buys, proposed to meet the requirements of each delivery order and what is suggested for any post-contractual period. Although Company X is authorized to use existing Government DMS/MS resolution efforts, Company X nonetheless retains full responsibility for resolving DMS/MS issues. …

Company X shall inform the Government of known or suspected DMS/MS issues for resolution upon discovery. Company X shall include all known information related to the DMS/MS issues at the time of Government notification. DMS/MS does not excuse Company X from the performance of metrics identified in Section H. In the event the program office… funding for DMS/MS effort is not adequate or not provided in a timely manner, the [Service inventory control point] Contracting Officer may, in his or her discretion, provide relief from Company X’s responsibility for fulfillment of performance metrics for resolutions. Company X shall submit all DMS/MS resolution recommendations to the Contracting Officer and Program Office or designated agent for final disposition. Upon a final DMS/MS resolution decision by the Government, Company X shall provide support for Life of Type, or Bridge Buy storage as required to implement the DMS/MS resolution.

Example 3. SOW/SOO Example of BOM, Configuration Management,
and DMSMS Issue Forecasting and Notifications-Related Requirements

1.0 Bill of Materials (BOM)

1.1 Periodic delivery of updated BOMs to the program office in an indentured format (in accordance with DID DI-PSSS-81656A)

1.2 Mitigation process of obtaining source data to forecast DMSMS if prime vendor or supplier will not provide a BOM

1.3 The contractor shall identify, as applicable, the parts planned to be used, as well as those used in the product at all indentured levels. The data may be obtained progressively during any program life cycle phase using sources such as the preferred parts list, build-of-materials, vendor surveys, inspections, etc. The information documented at the part level shall be updated as the design progresses or changes and be sufficient to enable forecasting and management of any associated DMSMS issues.

2.0 Configuration Management/Control

2.1 Validation of the system’s technical data to ensure all configuration changes are incorporated into the Configuration Management (CM) data base and drawings to ensure the system’s most current configuration is documented

2.2 CM of DMSMS addressed in the CM program plan

3.0 DMSMS Forecasting and Notifications

3.1 Use of predictive tools/methods to proactively forecast and monitor parts for DMSMS and provide results to the program office, access/insight into tools, DMSMS status at all reviews.

Example 4. Language Detailing Intent to Use DMSMS Management Factors
in Review of Approaches

Proposals will be evaluated on the management approach and the adequacy of planning for mitigating DMSMS risks. Proposals including management plans defining a proactive approach to manage DMSMS will receive more favorable ratings than those without such an approach. A proactive approach will include predictive forecasting strategies, parts list screening to the piece part level, parts list monitoring, matching of parts to the weapons systems’ environment across the vendor chain, methodologies for tracking, reporting, and mitigating DMSMS cases to avoid costly solutions, and a process to manage sub tier suppliers’ DMSMS efforts.

Example 5. Assignment of DMSMS Management Responsibilities Support
for Design/Production

Diminishing Manufacturing Sources and Material Shortages (DMSMS)

When addressing DMSMS and obsolescence in the XXX Parts Management Plan, the contractor shall include the following:

  • Means and approach for providing the Government with information regarding obsolescence and DMSMS issues
  • Planned resolution of current obsolescence and DMSMS issues
  • Parts list screening
  • Parts list monitoring
  • Receiving, processing and disseminating GIDEP DMSMS Notices
  • Receiving, processing and disseminating DLA DMSMS Alerts
  • Communication with and availability of information to the Government
  • Means and approach for establishing obsolescence and DMSMS solutions
  • Plan for conducting DMSMS predictions.

Example 6. Assignment of DMSMS Management Responsibilities
Support for Production

The Contractor/sub-contractor shall be an integral part and maintain full participation with the Program Office Obsolescence DMSMS IPT as follows:

Formal notification to alerts (Government Industry Data Exchange Program (GIDEP), Predictive Tool, as utilized by the Contractor) shall be submitted quarterly via the XXXX when they affect the YYY Program through this effort. The Contractor shall notify the XXX DMSMS IPT upon discovery of immediate or imminent DMSMS issues impacting the ability to manufacture articles under this SOW. The Contractor shall participate in quarterly DMSMS working groups to assist XXX in determining the best course of action to address these DMSMS issues. The Contractor shall notify XXX immediately should it be unable to maintain the capability to manufacture, repair and yield rates for articles under this SOW. The Contractor shall update and supply an indentured Bill of Materials (BOM) list quarterly via the CITIS. The Contractor shall analyze the YYY configurations and identify those items that are critical to supporting the YYY system. Potential DMSMS problems include, but are not limited to:

  1. Remanufacture issues, either performed organically by XXX or another Contractor’s facility.
  2. Closing of production lines due to Contractor downsizing, streamlining, contract termination or production line closeout
  3. Identification of impact assessment of diminishing sources of supply, including parts obsolescence issues.
  4. Expected/unexpected discontinuances of business (terminal closure) by the Contractor.
  5. Re-procurement/repair of Commercial Off the Shelf (COTS) items.

The Contractor shall determine if any of these potential problems can or will exist during the production contract and make recommendations for resolving them.

Example 7. Assignment of Obsolescence Management Responsibility
to the Contractor

The Contractor is responsible for managing obsolescence over the entire period of the contract, and notwithstanding any obsolescence issues or problems, the Contractor remains responsible for meeting all performance and other requirements of this contract. This obsolescence management responsibility includes an ongoing review and identification of actual and potential obsolescence issues, including but not limited to obsolescence of items, assemblies, sub-assemblies, piece parts, and material (hereafter referred to for purposes of this section only as “parts and/or material”). The Contractor is responsible for all costs associated with obtaining a replacement if and when any parts and/or material become obsolete. The costs for which the Contractor is responsible include, but are not limited to, the costs of investigating part availability, interchangeability and substitutability, locating part replacement, vendor interface, engineering efforts, testing requirements, internal drawing changes, etc. The Contractor shall prevent any additional costs from being incurred by the Government due to obsolescence. Any configuration changes due to obsolescence shall be approved in accordance with the Configuration Management requirements of this SOW. The Contractor shall provide the Government with obsolescence status briefs, as part of the periodic program reviews provided for under the contract.

Example 8. Assignment of Obsolescence Management Responsibility
to the Contractor

The Contractor is responsible for managing obsolescence over the entire period of the contract to ensure compliance with all performance and contract requirements. Responsibility includes all costs associated with locating part replacement, vendor interface, and engineering efforts. The Contractor shall develop a plan for managing the loss, or impending loss, of manufacturers or suppliers of components, assemblies, or materials used in the system. Changes considered necessary by the Contractor to ensure the continued manufacture and/or repair of the equipment shall be made in accordance with the Configuration Management requirements of this SOW. The Contractor’s Obsolescence Management Plan shall include language identifying their participation in the Government-Industry Data Exchange Program (GIDEP). The Contractor will not be responsible for redesign cost for obsolescence initiatives producing Class I changes. System/sub-System/Component redesign efforts will be pursued only after the Contractor has researched and eliminated all other potential mitigation options.

Example 9. Assignment of Obsolescence Management Responsibility
to the Contractor

The Contractor’s obsolescence management program shall prevent the impact to contract performance metrics and shall prevent additional costs being incurred by the Government due to obsolescence. The Contractor is 100% responsible for all obsolescence issues/problems with regard to the items in the contract, including: managing the loss or impending loss of manufacturers or suppliers for the spare and repairable items covered under the XXXX PBL Program. The Contractor shall manage obsolescence issues/problems in order to prevent the impact to contract performance metrics. Costs related to obsolescence issues/problems will be borne by the Contractor during the life of the contract. Changes considered necessary by the Contractor to ensure the continued manufacture and/or repair of the items will be made in accordance with XXXX requirements and/or Configuration Management requirements.

Example 10. Assignment of Obsolescence Management Responsibility
to the Contractor

The Contractor, on a continuous basis during contract performance, shall review and identify obsolescence issues related to piece parts for the items listed in Attachment “X.” The Contractor shall be responsible for piece part acquisition of replacement items to avoid obsolescence or repair turnaround issues. Should obsolescence or DMSMS issues occur that preclude the Contractor from obtaining spares of the current design for any vendor repairable item, as identified in Attachment “X,” any redesign, qualification and production efforts will be considered “over and above” this statement of work. Such issue shall relieve the Contractor from availability for that item. The Contractor will perform an engineering analysis of these items and provide recommended solutions. If in the course of an engineering review of the items in Attachment “X,” the Contractor identifies other obsolescence issues concerning the end item test sets, the Contractor may notify the Government of these issues and possible remedies.

Example 11. Assignment of Obsolescence Management Responsibility
to the Contractor

The Contractor is responsible for managing obsolescence over the entire period of the contract to ensure compliance with all performance and contract requirements. Responsibility includes all costs associated with locating part replacement, vendor interface, and engineering efforts. The Contractor shall develop a plan for managing the loss, or impending loss, of manufacturers or suppliers of components, assemblies, or materials used in the system. Changes considered necessary by the Contractor to ensure the continued manufacture and/or repair of the equipment shall be made in accordance with the Configuration Management requirements of this SOW. The Contractor’s Obsolescence Plan shall include participation in GIDEP.

The Contractor will not be responsible for redesign cost for obsolescence initiatives producing Class I changes. Redesign effort to proceed only after the Contractor has exhausted all options to accomplish engineering efforts for drop in replacement.

The Contractor’s obsolescence program shall prevent impact to contract performance metrics and shall prevent additional costs being incurred by the Government due to obsolescence.

The Contractor is 100% responsible for all obsolescence issues/problems with regard to the items in the contract, including: managing the loss or impending loss of manufacturers or suppliers for the spare and repairable items covered under the XXX PBL Program. The Contractor must manage obsolescence issues/problems in order to prevent impact to contract performance metrics. Cost related to obsolescence issues/problems will be borne by the Contractor during the life of the contract. Changes considered necessary by the Contractor to ensure the continued manufacture and/or repair of the items will be made in accordance with … requirements and/or Configuration Management requirements.

The Contractor, on a continuous basis during contract performance, shall review and identify obsolescence issues related to piece parts for the items listed in Attachment “X.” The Contractor shall be responsible for piece part acquisition of replacement items to avoid obsolescence or repair turnaround issues. Should obsolescence or DMSMS issues occur that preclude the contractor from obtaining spares of the current design for any vendor repairable item, as identified in Attachment “X,” any re-design, qualification and production efforts will be considered “over and above” this statement of work. Such issue shall relieve the contractor from availability for that item. The Contractor will perform an engineering analysis of these items and provide recommended solutions. If in the course of an engineering review of the items in Attachment “X,” the Contractor identifies other obsolescence issues concerning the end item test sets, the contractor may notify the Government of these issues and possible remedies.

Example 12. Assignment of Obsolescence Management Responsibility
to the Contractor during Production

Diminishing Manufacturing Sources and Material Shortages (DMSMS)

DMS Management

XXXX shall perform integrated DMS and Technology Refreshment Planning in accordance with the [XXXX DMSMS Management Plan and the XXXX Technology Refreshment Management Plan]. XXXX shall proactively manage DMS to ensure viable ongoing production and analyze impacts affecting future availability or logistics support of deliverable equipment. XXXX shall perform technology refreshment planning based on DMS drivers and supply trends, to define recommended system refreshment timelines based on lowest total program cost. Technology refreshment planning shall be coordinated with any capability upgrade roadmap activities accomplished by the Follow-on Development competency, to allow for an integrated program capability/tech-refreshment roadmap

XXXX shall flow down DMS requirements to suppliers and sub-contractors to the extent necessary to fulfill requirements under this statement of work. XXXX shall ensure that each supplier has established and utilized an effective DMS management program that identifies DMS status for all parts, materials, assemblies, subassemblies, and software items used in the current and prior configurations of deliverable equipment.

The XXXX DMS Management activity shall include:

        1. A process for identification, resolution and implementation for all DMS/obsolescence issues associated with components, materials, assemblies, subassemblies, and software items used in deliverable hardware, logistics support system, and support and training equipment under this contract. The contractor shall generate DMS case reports and recommendations based on trade study results. The reports shall be in accordance with CDRL XXXX.
        2. A semi-annual obsolescence status report to inform the Government and International Partners of current year’s DMS/obsolescence status including near-term risks, pending DMS cases, DMS parts and materials inventory assessment, as well as upcoming redesign activities, in accordance with CDRL XXXX.
        3. A semi-annual, contractor-led Obsolescence Working Group (OWG) during the life of the contract. These meetings shall occur within 45 days after the submittal of the semi-annual obsolescence report. Participation planning and specific meeting objectives will be decided and agreed upon by the Government and the Contractor no later than 14 days prior to each meeting date. In general, current and predicted DMS issues that have significant impacts to production and sustainment, DMS stock positions that have become excess for disposition (e.g. the result of profile changes or redesign activities), and coordination of Follow-on Development activities will be included. The Contractor shall maintain minutes and action item assignments and resolutions from each meeting.
        4. An annual 10-year rolling electronic systems DMS redesign and tech refreshment plan including both hardware and software air system elements in accordance with CDRL XXXX. This plan will define the optimally recommended refreshment point for air system components based on lowest total program cost, and will be provided for integration with any future upgrade roadmaps.
        5. A semi-annual 5-year rolling DMS activity and cost forecast to assist in program and budget planning in accordance with CDRL XXXX. This forecast will inherently contain and be based on the integrated technology refreshment plan, and will cover known and anticipated DMS events for the 5-year period.
        6. DMS modeling capability to assist in the development of cost forecasts and in ongoing DMS/tech refreshment upgrade trade studies and program decisions. This modeling shall provide the capability to evaluate the impact of non-optimal tech refreshment timelines and include allowances for the high variability inherent in DMS forecasting.

DMS Redesigns

XXXX shall perform redesign, as authorized in this contract, to resolve Diminishing Manufacturing Sources (DMS) in accordance with XXXX.

Example 13. Assignment of Obsolescence Management Responsibility
to the Contractor during Production

The Contractor shall review sources of information such as the Government Industry Data Exchange Program (GIDEP) Diminishing Manufacturing Source (DMS) notices and supplier notifications for applicability of the hardware being delivered. The Contractor shall support the Government in micro-electronic management and obsolescence avoidance by participating in engineering technology assessments [the system’s] hardware during the period of performance of this SOW. The result of the assessments will provide an understanding of the current microelectronic status of the systems, the scope of any immediate non-availability, obsolescence problems, and magnitude of future problems and possibilities for alleviating the impact to the program.

The Contractor shall support the DMSMS activity by assisting the identification of alternate sources, replacement parts, or optional part numbers for parts and materials that become or will become obsolete. If a direct replacement is not identified, the Contractor shall notify the Government in writing through the contracting officer. The Contractor shall document any identified obsolescence or DMS issues for all microelectronic parts and associated materials used to produce and support the [system during the period of performance] in a System Problem Report (CDRL XXXX). The report shall include all obsolescence issues identified by the Contractor and its subcontractors. The report shall identify which production lot is impacted, identify proposed solutions/substitution for the obsolescence parts and estimate the lead time for the proposed solutions/substitution. Any nonrecurring effort associated with developing and/or qualifying replacement components and subsystems shall be separately contracted.

Example 14. Contractor Flow Down of DMSMS Requirements to a Supplier

Subcontractors/suppliers shall monitor parts obsolescence over the period of performance. Obsolescence monitoring includes an ongoing review and identification of actual and potential obsolescence issues, including but not limited to obsolescence of components, assemblies, subassemblies, piece parts, and material. The subcontractor/supplier is responsible for identifying the obsolete components and whether or not a simple replacement of the component is required or a redesign (that will drive a change in specification, ATP, and/or form/fit/function of the delivered item. Obsolescence issues that are identified during the period shall be documented and provided to (Name of Prime) via report on a (frequency specified). In addition, the subcontractor/supplier is responsible for identifying the potential cost (NTE ROM) of addressing the obsolescence issue, as well as the time required to implement the change. The NTE ROM shall include the costs for full investigating part availability, interchangeability and substitutability; locating part replacement; vendor interface; engineering efforts; testing requirements; internal drawing changes; etc. Any changes in configuration being driven by obsolescence must be approved by (Name of Prime) IAW contract requirements.

Example 15. Requirement for Chemical Content Reporting
at the Line Replaceable Unit Level

Hazardous materials include but are not limited to…

Information delivered shall include:

  1. Identification of the hazardous materials on the [insert system name] system and generated during operations and maintenance by specific data elements/ part number on the [insert system name] system and quantities (those used during manufacturing do not apply).
  2. Description of the reasonably anticipated hazardous waste(s) generated during normal operations and maintenance and emergency situations.

Example 16. Requirement for Mitigation Information Pertaining to
Specific Critical Materials

If [insert critical material] is planned to be used or will be required for maintenance operations, provide the following information for each application and alternative:

  1. Cost effectiveness of alternative materials or processes over the [insert system name] system life cycle.
  2. Technical feasibility of alternative materials

Example 17. Life-of-Need Buys with a Maximum Funding Liability

  1. (INSERT CONTRACTOR NAME) agrees that no additional funding will be required from the (INSERT SERVICE) for life-of-need buys (up to $1 million per buy going through DMSRB) in support of obsolescence for the (INSERT SYSTEM TYPE) requirements under this contract. This specifically excludes any life-of-need buys related to retrofit, spares or FMS requirements. As the contractor identifies parts impacted by obsolescence, the contractor shall initiate processes identified in Attachment XXX. If it is determined that a life-of-need buy is required, (INSERT CONTRACTOR NAME) will secure those parts to cover up to a total of (INSERT NUMBER and SYSTEM TYPE).
  2. Should the government determine that a redesign/requalification of an obsolete part is required, the government may authorize (except as described in the paragraph below) and fund all costs associated with redesign of the replacement part and any delta recurring costs via the procedures of the “Changes” clause of this contract and/or another contract vehicle.
  3. In the event that the government elects not to fund the cost associated with a redesign of the replacement part of the existing part, appropriate authorization (e.g., deviation, waiver, (INSERT APPROPRIATE AUTHORITY) approval) will be granted to allow for acceptance of the supplies and completion of deliveries under this contract.

Example 18. Redesign Implementation

1. Purpose

The purpose of this effort is for (INSERT CONTRACTOR NAME) to redesign the existing (INSERT ITEM NAME), eliminating existing Diminishing Manufacturing Source (DMS) components and mitigating any other known DMS issues.

(INSERT ITEM NAME, NSN, P/N)

2. Contractor Tasks and Responsibilities

The contractor shall redesign the existing (INSERT ITEM NAME, P/N), eliminating and mitigating all known DMS issues to ensure production capability for at least NNNN years after completion of this Delivery Order.

  • The new (INSERT ITEM NAME) design shall be a form, fit, function, and interface replacement for the current (INSERT ITEM NAME) configuration.
    • The contactor shall perform all necessary testing of the new design to approve it as the preferred spare for all USAF configurations of the (INSERT NEXT HIGHER ASSEMBLY).
    • The contractor shall test new design on contractor test (INSERT TYPE OF ASSET).
  • The contractor shall provide MMMM prototypes for Government test.
  • The contractor shall create and/or revise all applicable engineering drawings required to identify the new design as the preferred spare.
  • The contractor shall host design reviews (PDR/CDR) and notify government participants 30 days prior to each review.

Example 19. Redesign Implementation with a Life-of-Need Buy

1. Purpose

This Statement of Work (SOW) defines the support effort to be performed by (INSERT CONTRACTOR’S NAME) as the contractor, relating to the following unit in the (DESCRIBE WHERE THE UNIT FITS IN THE SYSTEM): (INSERT NAME OF ITEM).

The support effort is to redesign the (INSERT NAME OF ITEM), using a Life Time buy of XXXX’s for a fixed life solution; and to begin a process of evaluating an extended time solution of replacing the XXXX’s. The fixed life solution will result in NNNN tested, deliverable, and production representative articles with documentation. The XXXX replacement process will result in an evaluation of success in replacing an XXXX with a new design and will be based on test results.

2. Contractor Tasks and Responsibilities

The contractor shall accomplish the following:

1. Redesign the (INSERT NAME OF ITEM)

2. Manufacture NNNN pre-production articles per (INSERT NAME OF ITEM) with MMMM being deliverable.

3. Complete testing of (INSERT NAME OF ITEM) to include:

a. Environmental stress screening test per xxxxx

b. Next higher assembly and system bench testing

c. Support as necessary of integration testing of delivered articles

4. Provide documentation and reports:

a. Engineering drawings including:

Develop and update existing documents

      • Level III engineering drawings (Complete procurement technical data package)
      • Acceptance test specification
      • System test specification
      • UUT schematics

Generate new documents with updated end-item part number for new assembly

      • Statement D
      • Revision notice
      • Engineering change proposal
      • Required JEDMICS metadata
      • Formatted and delivered for JEDMICS upload

b. PDR/CDR

c. Status reports and final test reports in accordance with CDRL ZZZZ

d. Qualification by similarity statement to verify form, fit, function and interface.

e. Environmental qualification analysis based on similarity to include: (reference Prime Item Development Specification, PIDS, xxxxxxx, dd mmm yyyy paragraph xxx Temperature, (b) Vibration, (c) Shock, (d) Explosion, (e) Power, (f) EMC/EMI

f. Provide Safety of Flight (SOF) certificate before flight test

5. Address the heat that the (INSERT NAME OF ITEM) produces in the next higher assembly and ensure the redesign ameliorates the heat issues.

6. Ensure the redesign of the (INSERT NAME OF ITEM) works properly with the next higher assembly.

7. Provide a report describing the results of evaluating the redesign approach and define the next step if test results are successful.

Example 20. Reverse Engineering Implementation

1.1 Purpose

1.1.1 Reverse engineer the (INSERT ITEM NAME, NSN, P/N) for the (INSERT NAME OF SYSTEM)

1.1.2 Develop and deliver a full and complete manufacturing technical data package (TDP) for the (INSERT ITEM NAME).

1.1.3 Develop, test, and deliver one prototype asset.

1.2 Scope

1.2.1 The contractor shall complete the following tasks for this effort. Unless otherwise specified, all time spans given are in calendar days. The contractor shall deliver a program management plan, DI-MGMT-81797 (CDRL XXXX) within 30 days of contract award, which shall define the project schedule and risk management plan.

1.2.2 The contractor shall analyze and reverse engineer the (INSERT ITEM NAME) based on available technical data, documents, and physical access to the (INSERT ITEM NAME). The contractor shall analyze the current (INSERT ITEM NAME), and its detail/subassembly items, for parts obsolescence and include logistically supportable replacement parts where obsolescence is found and/or where reliability, maintainability, and supportability can be improved. Contractor shall analyze the current material used in the window of the (INSERT ITEM NAME) and provide options for more reliable materials to be used in the prototype. Any changes to the existing configuration shall be presented to the Government for evaluation prior to implementation into the proposed design. The new reverse engineered design shall maintain Form, Fit, and Function (FFF) with the current (INSERT ITEM NAME). No changes to the (INSERT ITEM NAME) shall be incorporated that will require new or additional field installation and depot test procedures, unless approved by Government Engineering. The contractor shall request a meeting with Government Engineering, through the cognizant contracting officer, to obtain clarifications on an as-needed basis.

1.2.3 The contractor shall develop and deliver a prototype asset to the Government for FFF test/verification/validation in the Next Higher Assembly or end system. The Contractor will perform material UV testing on a sample of the material to be used as the new window for the (INSERT ITEM NAME) to duplicate 20 years’ worth of exposure to sunlight. The Government will perform Prototype Testing on Next Higher Assembly (NHA) using current technical Orders in conjunction with contractor’s test plan. Contractor shall resolve all issues that arise during testing until all technical parameters/requirements are met IAW Technical Orders and scope of the project. Contractor will be allowed to witness the Prototype Testing at a Government facility unless a portion of the testing must be performed in a security restricted environment.

1.2.4 The contractor shall develop and deliver a Level 3 engineering TDP, Final TDP (CDRL XXXX) to the Government for use on future procurement/manufacturing purposes for the (INSERT ITEM NAME) IAW … with full/unlimited data rights to the Government. The contractor shall provide a draft procurement TDP to the Government no later than 30 days after Critical Design Review (CDR) (CDRL XXXX). The U.S Government will have 30 days to review the draft TDP and provide comments to the contractor. The contractor will then have 110 days to deliver the final TDP. The TDP shall be delivered in two separate deliverables (on two CDs), a draft package and a final package. All forms of technical data submitted as part of the final TDP or created under this contract must be submitted with full/unlimited data rights to the Government.

The contractor shall conduct a Preliminary Design Review (PDR) and a CDR to include Government participation. The contractor shall receive Government’s approval of the PDR and CDR before proceeding to the next phase of the project. The Government will have 15 days after PDR and CDR to respond to the contractor. Monthly status reports shall be submitted per ZZZZ and all other meeting reports/minutes shall be submitted per AAAA, Contractor’s Progress, Status, and Management Report (CDRL XXXX and YYYY). The contractor shall develop and deliver a test plan/procedure for the (INSERT ITEM NAME) IAW any available depot test or OEM procedures and demonstrating Form, Fit, and Function operational capability within the Next Higher Assembly (NHA). Test plan shall be submitted per …, Test and Evaluation Program Plan (CDRL XXXX). Test Reports shall be submitted per …, Test/Inspection Report (CDRL XXXX).

Appendix D. DMSMS Management Questions for Systems Engineering Technical Reviews

This appendix contains DMSMS management questions intended for use by DMSMS practitioners to prepare for six of the SE technical reviews of primary importance:

  • Alternative Systems Review (ASR)
  • Systems Requirements Review (SRR)
  • System Functional Review (SFR)
  • Preliminary Design Review (PDR)
  • Critical Design Review (CDR)
  • Production Readiness Review (PRR).

The questions are designed for the program office, but many also apply to prime contractors and subcontractors. The questions are presented in six tables. Tables 15–19, respectively, contain questions pertinent to the five DMSMS management steps: Prepare, Identify, Assess, Analyze, and Implement. They are further broken down by process. Table 20 contains questions that apply to SE technical reviews but do not relate directly to a particular DMSMS step or process.

Table 15. DMSMS Management Questions
for Systems Engineering Technical Reviews: Prepare (Section 3)

Process

ASR

SRR

SFR

PDR

CDR

PRR

Establish strategic under-pinnings

Has program leadership identified expectations for DMSMS management operations and deliverables?

Has program leadership updated expectations for DMSMS management operations and deliverables?

Has program leadership updated expectations for DMSMS management operations and deliverables?

Has program leadership updated expectations for DMSMS management operations and deliverables?

Has program leadership updated expectations for DMSMS management operations and deliverables?

Has program leadership defined the roles and relative relationships among DMT members?

Has program leadership updated the roles and relative relationships among DMT members?

Has program leadership updated the roles and relative relationships among DMT members?

Has program leadership updated the roles and relative relationships among DMT members?

Has program leadership updated the roles and relative relationships among DMT members?

Establish strategic under-pinnings (cont’d)

Has program leadership determined a risk-based perspective to DMSMS management by identifying criteria for which systems to monitor and which items to monitor within those systems?

Has program leadership updated the risk-based perspective to DMSMS management by updating criteria for which systems to monitor and which items to monitor within those systems?

Has program leadership updated the risk-based perspective to DMSMS management by updating criteria for which systems to monitor and which items to monitor within those systems?

Has program leadership updated the risk-based perspective to DMSMS management by updating criteria for which systems to monitor and which items to monitor within those systems?

Has program leadership updated the risk-based perspective to DMSMS management by updating criteria for which systems to monitor and which items to monitor within those systems?

Develop a DMP

Has the program started to develop its strategy and plan for addressing and managing the impact of DMSMS issues?

Has the program established a robust DMSMS management strategy and program that identifies obsolescence due to DMSMS issues before critical items are unavailable?

Has a government DMP been formally approved by program leadership?

Is the DMSMS management program being executed per the formal approved DMP?

Is the DMSMS management program being executed per the formal approved DMP?

Are DMSMS impacts a consideration when analyzing alternative systems to help ensure that the preferred system is cost-effective, affordable, operationally effective, and suitable and can be developed to provide a timely solution to a need at an acceptable level of risk?

Is language developed and included in the SOO/SOW/RFP documentation requiring the prime contractor to provide its strategy and plan to address the impact of DMSMS issues and obsolescence?

Is this reflected in a draft government DMP?

Is the government DMP being updated, as necessary?

Is the government DMP being updated, as necessary?

Develop a DMP
(cont’d)

Does the draft DMP identify the roles and responsibilities of the prime/
subcontractor and third-party vendors?

Does the draft government DMP identify the roles and responsibilities of the prime/
subcontractor and third-party vendors?

Does the approved government DMP identify the roles and responsibilities of the prime/sub-contractor and third-party vendors?

Have the roles and responsibilities of the government, prime/sub-contractor, and third-party vendors been established as contractual requirements?

Have the roles and responsibilities of the government, prime/sub-contractor, and third-party vendors been established as contractual requirements?

Have the roles and responsibilities of the government, prime/sub-contractor, and third-party vendors been established as contractual requirements?

Are the roles and responsibilities of the government, prime/sub-contractor and third-party vendors being executed?

Are the roles and responsibilities of the government, prime/sub-contractor and third-party vendors being executed?

Are prime contractors flowing down DMSMS management requirements to their subcontractors and are those subcontractors flowing down requirements to their supply chains in a similar way?

Are prime contractors flowing down DMSMS management requirements to their subcontractors and are those subcontractors flowing down requirements to their supply chains in a similar way?

Are prime contractors flowing down DMSMS management requirements to their subcontractors and are those subcontractors flowing down requirements to their supply chains in a similar way?

Is a CDRL included for the delivery of the prime contractor’s DMP?

Are prime contractors flowing down DMSMS management requirements to their subcontractors and are those subcontractors flowing down requirements to their supply chains in a similar way?

Are prime contractors flowing down DMSMS management requirements to their subcontractors and are those subcontractors flowing down requirements to their supply chains in a similar way?

Develop a DMP
(cont’d)

Are there exit strategies in the contracts that require all sustainment providers to ensure no item end-of-life issues are unresolved at the completion of the period of performance?

Are there exit strategies in the contracts that require all sustainment providers to ensure no item end-of-life issues are unresolved at the completion of the period of performance?

Are there exit strategies in the contracts that require all sustainment providers to ensure no item end-of-life issues are unresolved at the completion of the period of performance?

Are there exit strategies in the contracts that require all sustainment providers to ensure no item end-of-life issues are unresolved at the completion of the period of performance?

Are there exit strategies in the contracts that require all sustainment providers to ensure no item end-of-life issues are unresolved at the completion of the period of performance?

Is the government conducting sufficient oversight when contractors are responsible for executing DMSMS
operational
processes?

Is the government conducting sufficient oversight when contractors are responsible for executing DMSMS
operational
processes?

Is the government conducting sufficient oversight when contractors are responsible for executing DMSMS
operational
processes?

Is the government conducting sufficient oversight when contractors are responsible for executing DMSMS
operational
processes?

Is the government conducting sufficient oversight when contractors are responsible for executing DMSMS
operational
processes?

Form a DMT

Has a partial DMT been formed?

Has a partial DMT been formed?

Has the full DMT been formed?

Has the full DMT been formed?

Do all identified DMT members understand their roles and responsibilities and have adequate training to fulfill their roles and responsibilities?

Do all identified DMT members understand their roles and responsibilities and have adequate training to fulfill their roles and responsibilities?

Do all identified DMT members understand their roles and responsibilities and have adequate training to fulfill their roles and responsibilities?

Do all identified DMT members understand their roles and responsibilities and have adequate training to fulfill their roles and responsibilities?

Secure DMT operations funding

Have current and outyear DMSMS operating budgets been estimated and identified?

Have current and outyear DMSMS operating budgets been established, approved, and funded?

Have current and outyear DMSMS operating budgets been established, approved, and funded?

Have current and outyear DMSMS operating budgets been established, approved, and funded?

Establish DMSMS opera-tional
processes

Is the process of defining and documenting all DMSMS operational processes in the government DMP
underway?

Have all DMSMS operational processes been defined and documented in the government DMP?

Manage case

Has the program defined DMSMS metrics that will be captured and tracked for DMSMS cases, trends, and associated resolutions and costs?

Has the program defined DMSMS metrics that will be captured and tracked for DMSMS cases, trends, and associated resolutions and costs?

Is the program using DMSMS metrics to track DMSMS cases, trends, and associated resolutions and costs?

Is the program using DMSMS metrics to track DMSMS cases, trends, and associated resolutions and costs?

Has the program identified how it will capture and track DMSMS metrics?

Has the program developed or identified a DMSMS case tracking database?

Evaluate program

Has planning begun for reporting DMSMS case management metrics (life-cycle costs and cost avoidance by being proactive associated with DMSMS resolutions)?

Has a plan to report DMSMS case management metrics (life-cycle costs and cost avoidance by being proactive associated with DMSMS resolutions) been established?

Has a plan to report DMSMS case management metrics (life-cycle costs and cost avoidance by being proactive associated with DMSMS resolutions) been updated?

Has a plan to report DMSMS case management metrics (life-cycle costs and cost avoidance by being proactive associated with DMSMS resolutions) been updated?

Evaluate program (cont’d)

Are DMSMS case management metrics (life-cycle costs and cost avoidance by being proactive associated with DMSMS resolutions) being reported to program management?

Are DMSMS case management metrics (life-cycle costs and cost avoidance by being proactive associated with DMSMS resolutions) being reported to program management?

Ensure quality

Has the process of establishing metrics to measure the efficiency of DMSMS operational processes begun?

Have metrics been established to measure the efficiency of DMSMS operational processes and to drive continuous
process improvement?

Are process efficiency metrics being used to drive continuous process improvement of the DMSMS operational processes?

Are process efficiency metrics being used to drive continuous process improvement of the DMSMS operational processes?

Table 16. DMSMS Management Questions
for Systems Engineering Technical Reviews: Identify (Section 4)

Process

ASR

SRR

SFR

PDR

CDR

PRR

Prioritize
systems

Are mission criticality, operational safety, and DMSMS-related costs being considered to identify and prioritize the systems and subsystems to be monitored?

Are mission criticality, operational safety, and DMSMS-related costs being used to identify and prioritize the systems and subsystems to be monitored?

Are mission criticality, operational safety, and DMSMS-related costs being used to identify and prioritize the systems and subsystems to be monitored?

Are mission criticality, operational safety, and DMSMS-related cost being used to identify and prioritize the systems and subsystems to be monitored?

Identify and
procure
monitoring and
surveillance tools

Have DMSMS forecasting and associated data collection and management tools or service
providers been
researched?

Have DMSMS forecasting and associated data collection and management tools or service
providers been
researched and
selected?

Have DMSMS forecasting and associated data collection and management tools been reviewed to determine their continued suitability for sustainment?

Have DMSMS forecasting and associated data collection and management tools been reviewed to determine their continued suitability for sustainment?

Identify and procure monitoring and surveillance tools (cont’d)

Have tool selections been made to supplement, as necessary?

Have tool selections been made to supplement, as necessary?

Collect and
prepare item data

Have the items associated with critical system functions been identified?

Is a CDRL included for the delivery of the system BOM?

Have the items associated with critical system functions been updated?

Have the items associated with critical system functions been updated?

Have notional BOMs for the system been acquired in accordance with
DI-SESS-81656A?

Have indentured BOMs for the system been acquired in accordance with
DI-SESS-81656A?

Have indentured BOMs for the system been acquired in accordance with
DI-SESS-81656A?

Are critical materials of concern within the supply chain being considered?

Are critical materials of concern within the supply chain being considered?

Are critical materials of concern within the supply chain being considered?

Does the program have a strategy for obtaining the following:

Design disclosed items, including subtier hardware indenture levels

F3/proprietary design items, including subtier hardware indenture levels

Items that are single source and those for which the government cannot obtain data rights and the associated corrective action plans are identified?

Has the program obtained the following:

Design disclosed items, including subtier hardware indenture levels

F3/proprietary design items, including subtier hardware indenture levels

Items that are single source and those for which the government cannot obtain data rights and the associated corrective action plans are identified?

Has the program obtained the following:

Design disclosed items, including subtier hardware indenture levels

F3/proprietary design items, including subtier hardware indenture levels

Items that are single source and those for which the government cannot obtain data rights and the associated corrective action plans are identified?

Collect and
prepare item data (cont’d)

Has the notional BOM been loaded into the selected forecasting/
management tool in order to perform an initial DMSMS items availability assessment?

Has the build baseline/final design BOM been loaded into the selected forecasting/
management tool in order to perform a DMSMS items availability assessment?

Has the BOM been regularly updated and reloaded into a DMSMS forecasting/management tool and/or service in order to perform periodic DMSMS items availability assessments?

Have preliminary lists of items, software, and materials to monitor been prepared?

Have lists of items, software, and materials to monitor been updated?

Have lists of items, software, and materials to monitor been updated?

Analyze item availability

Are the selected forecasting/
management tool or the results of manual research being used to identify immediate and near-term obsolescence issues associated with the notional BOM? For any DMSMS issues identified, are they addressed and mitigated prior to establishment of the build baseline/final design BOM?

Have the selected forecasting/
management tool or the results of manual research been used to identify immediate and near-term obsolescence issues associated with the build baseline/final design BOM? For any DMSMS issues identified, are they addressed and mitigated prior to
acceptance and approval of the build baseline/final design BOM?

Are the selected forecasting/
management tool or the results of manual research being used to identify immediate and near-term obsolescence issues associated with the BOM?

Is the program
receiving obsolescence forecasts on a scheduled basis?

Is the program
receiving obsolescence forecasts on a scheduled basis?

Are product discontinuation notices being received regularly?

Are product discontinuation notices being received regularly?

Are vendor surveys being conducted on a regular basis?

Are vendor surveys being conducted on a regular basis?

Are vendor surveys being conducted on a regular basis?

Collect and update
programmatic and logistics data

Have programmatic and predicted reliability data needs for impact assessment been identified?

Have programmatic and predicted reliability data needs for impact assessment been updated?

Have programmatic and predicted reliability data needs for impact assessment been updated and collected?

Have programmatic and predicted reliability data needs for impact assessment been updated and collected?

Table 17. DMSMS Management Questions
for Systems Engineering Technical Reviews: Assess (Section 5)

Process

ASR

SRR

SFR

PDR

CDR

PRR

Assess
impact of DMSMS issue

Is a formal technology roadmap and insertion/ refreshment strategy being developed for all, or portions of, the program/system?

Has a formal technology roadmap and approved insertion/
refreshment strategy been developed?

Has a formal technology roadmap and approved insertion/
refreshment strategy been developed and funded?

Has a formal technology roadmap and approved insertion/
refreshment strategy been reviewed for potential updates and adjustments?

Does the technology roadmap and insertion/
refreshment strategy focus on and address the identification of critical items, materials, and technologies, as well as emerging technologies?

Does the roadmap and insertion/
refreshment strategy identify critical items, materials, and technologies, as well as emerging technologies?

Does the technology roadmap and insertion/
refreshment strategy identify critical items, materials, and technologies, as well as emerging technologies?

Does the technology insertion/
refreshment plan identify critical items, materials, and technologies, as well as emerging technologies?

Is the technology insertion/
refreshment plan being used to determine the time frame for potential DMSMS operational impacts?

Is the technology insertion/
refreshment plan being used to determine the time frame for potential DMSMS operational impacts?

Is the technology insertion/
refreshment plan being used to determine the time frame for potential DMSMS operational impacts?

Is the technology insertion/
refreshment plan being used to determine the time frame for potential DMSMS operational impacts?

Are DMSMS issues being considered as a basis for adjusting the scope or schedule of the technology insertion/
refreshment?

Are DMSMS issues being considered as a basis for adjusting the scope or schedule of the technology insertion/
refreshment?

Are DMSMS issues being considered as a basis for adjusting the scope or schedule of the technology insertion/
refreshment?

Are DMSMS issues being considered as a basis for adjusting the scope or schedule of the technology insertion/
refreshment?

Assess
impact of DMSMS issue (cont’d)

Are DMSMS operational risks being identified and prioritized?

Are DMSMS operational risks being identified and
resolved?

Are DMSMS operational risks being identified and
resolved?

Are DMSMS operational risks being identified and
resolved?

Is the monitoring of usage of and anticipated demand for items and materials being considered in DMSMS impact
assessment?

Is the monitoring of usage of and anticipated demand for items and materials being considered in DMSMS impact
assessment?

Is the monitoring of usage of and anticipated demand for items and materials being considered in DMSMS impact
assessment?

Is the monitoring of usage of and anticipated demand for items and materials being considered in DMSMS impact
assessment?

Table 18. DMSMS Management Questions
for Systems Engineering Technical Reviews: Analyze (Section 6)

Process

ASR

SRR

SFR

PDR

CDR

PRR

Determine DMSMS
resolution

Are DMSMS impacts being identified and addressed during the initial item availability analysis prior to acceptance and approval of the notional BOM?

Are resolutions to DMSMS impacts being identified and addressed during the item availability analysis prior to acceptance and approval of the build baseline/final design BOM?

Are resolutions to DMSMS impacts being identified?

Is a BCA or AoA being performed (including ROI calculations) as part of resolution determination?

Is a BCA or AoA being performed (including ROI calculations) as part of resolution determination?

Is a BCA or AoA being performed (including ROI calculations) as part of resolution determination?

Have all costs associated with a resolution been considered?

Have all costs associated with a resolution been considered?

Have all costs associated with a resolution been considered?

Do mitigation strategies clearly address the entire system life cycle (not just the contract period)?

Do mitigation strategies clearly address the entire system life cycle (not just the contract period)?

Do mitigation strategies clearly address the entire system life cycle (not just the contract period)?

Has resolution determination taken into account that the most cost-effective resolution may be found at a higher level of assembly?

Has resolution determination taken into account that the most cost-effective resolution may be found at a higher level of assembly?

Has resolution determination taken into account that the most cost-effective resolution may be found at a higher level of assembly?

Table 19. DMSMS Management Questions
for Systems Engineering Technical Reviews: Implement (Section 7)

Process

ASR

SRR

SFR

PDR

CDR

PRR

Secure DMSMS
resolution funding

Have any DMSMS case management metrics (life-cycle costs and cost avoidance by being proactive associated with DMSMS resolutions) been identified for use in supporting funding requests?

Are DMSMS case management metrics (life-cycle costs and cost avoidance by being proactive associated with DMSMS resolutions) being used to support funding requests?

Are DMSMS case management metrics (life-cycle costs and cost avoidance by being proactive associated with DMSMS resolutions) being used to support funding requests?

Are DMSMS case management metrics (life-cycle costs and cost avoidance by being proactive associated with DMSMS resolutions) being used to support funding requests?

Are projected current and outyear DMSMS resolution budgets being developed using a sound analytical basis that is persuasive enough to obtain necessary funding?

Have projected current and outyear DMSMS resolution budgets been established using a sound analytical basis that is persuasive enough to obtain necessary funding?

Have projected current and outyear DMSMS resolution budgets been established using a sound analytical basis that is persuasive enough to obtain necessary funding?

Have projected current and outyear DMSMS resolution budgets been established using a sound analytical basis that is persuasive enough to obtain necessary funding?

Have the projected resolution budgets been included in the program’s Logistics Requirements and Funding Summary (LRFS)?

Have the projected resolution budgets been approved and included in the program’s LRFS documentation?

Have the projected resolution budgets been approved and included in the program’s LRFS documentation?

Have the projected resolution budgets been approved and included in the program’s LRFS documentation?

Is funding being sought on the basis of projected resolution budgets?

Have the resolution budgets been approved and funded?

Have the resolution budgets been approved and funded?

Have the resolution budgets been approved and funded?

Implement DMSMS
resolution

Are the DMSMS impacts on the notional BOM, identified during the item availability analysis, resolved?

Are the DMSMS impacts on the build-baseline/final design BOM, identified during the item availability analysis, resolved?

Are funded DMSMS resolutions being implemented on a timely basis?

Table 20. DMSMS Management Questions
for Systems Engineering Technical Reviews: Other

Process

ASR

SRR

SFR

PDR

CDR

PRR

Not readily
relatable to
specific
organizational principles,
chapters, or
processes

Is DMSMS management a consideration when the system design approach is being determined in order to minimize the impact on supportability and sustainability?

Is DMSMS management a consideration when the system design approach is being determined in order to minimize the impact on supportability and sustainability?

Is DMSMS a management consideration when the system design approach is being determined in order to minimize the impact on supportability and sustainability?

Are the following addressed:

Open system architecture

Order of precedence for parts selection (use of QML parts, particularly for applications requiring extended temperature ranges)

Selection of parts relatively new in their life cycle

Minimized use of custom parts

Requirement for a preferred parts list and parts control prior to detailed design to minimize obsolescence issues

Identification of shelf and
operating life
requirements

Identification of technology life expectancies

Are the following addressed:

Open system architecture

Order of precedence for parts selection (use of QML parts, particularly for applications requiring extended temperature ranges)

Selection of parts relatively new in their life cycle

Minimized use of custom parts

Requirement for a preferred parts list and parts control prior to detailed design to minimize obsolescence issues

Identification of shelf and
operating life
requirements

Identification of technology life expectancies

Are the following addressed:

Open system architecture

Order of precedence for parts selection (use of QML parts, particularly for applications requiring extended temperature ranges)

Selection of parts relatively new in their life cycle

Minimized use of custom parts

Requirement for a preferred parts list and parts control prior to detailed design to minimize obsolescence issues

Identification of shelf and
operating life
requirements

Identification of technology life expectancies

Not readily
relatable to
specific
organizational principles,
chapters, or
processes
(cont’d)

Are DMSMS considerations incorporated into pertinent program documentation, e.g., IMP/IMS, LCSP, LRFS, TDS, Product Support Plan (PSP), and AS?

Are DMSMS considerations incorporated into pertinent program documentation, e.g., IMP/IMS, LCSP, LRFS, TDS, PSP, and AS?

Are DMSMS considerations incorporated into pertinent program documentation, e.g., IMP/IMS, LCSP, LRFS, TDS, PSP, and AS?

Are DMSMS considerations incorporated into pertinent program documentation, e.g., IMP/IMS, LCSP, LRFS, TDS, PSP, and AS?

Appendix E. DMSMS-Related Questions for Logistics Assessments

This appendix contains DMSMS-related questions intended for use by DMSMS practitioners to prepare for pre-IOC and post-IOC LAs. The questions are presented in six tables. Tables 21–25, respectively, contain questions pertinent to the five DMSMS management steps: Prepare, Identify, Assess, Analyze, and Implement. Table 26 contains questions that apply to LAs but do not relate directly to a particular DMSMS step or process.

Table 21. DMSMS Management Questions for Logistics Assessments: Prepare (Section 3)

Process

Pre-IOC

Post-IOC

Establish strategic underpinnings

Has program leadership identified required operations and deliverables, defined DMT member roles and responsibilities, and developed a risk-based approach to DMSMS management?

Has program leadership updated required operations and deliverables, defined DMT member roles and responsibilities, and developed a risk-based approach to DMSMS management?

Develop a DMP

Has the program established a robust DMSMS management strategy and program that identifies obsolescence due to DMSMS before items are unavailable?

Is the DMSMS management program being executed per the formal approved DMP?

Is this reflected in a formal DMP that has been approved and signed by leadership?

Is the government DMP being updated, as necessary?

Does the government DMP identify the roles and responsibilities of the prime/
subcontractor and third-party vendors?

Has the government DMP been updated to identify the roles and responsibilities of the prime/subcontractors and third-party vendors as necessary?

Have these roles and responsibilities for the prime/subcontractor and third-party vendors been established as contractual requirements where applicable?

Have these roles and responsibilities for the prime/subcontractor and third-party vendors been established as contractual requirements where applicable?

Is a CDRL included for the delivery of the prime contractor’s DMP?

Where applicable, are there exit strategies in the contracts that require all sustainment providers to ensure no item end-of-life issues are unresolved at the completion of the period of performance?

Where applicable, are there exit strategies in the contracts that require all sustainment providers to ensure no item end-of-life issues are unresolved at the completion of the period of performance?

Is the government conducting sufficient oversight when contractors are performing DMSMS operational processes?

Is the government conducting sufficient oversight when contractors are performing DMSMS operational processes?

Form a DMT

Has the DMT been formed?

Has the DMT been formed?

Secure DMT
operations funding

Are DMSMS case management metrics (life-cycle costs and cost avoidance by being proactive associated with DMSMS resolutions) being used to support funding requests?

Are DMSMS case management metrics (life-cycle costs and cost avoidance by being proactive associated with DMSMS resolutions) being used to support funding requests?

Have current and outyear DMSMS operating budgets been established, approved, and funded?

Have current and outyear DMSMS operating budgets been established, approved, and funded?

Establish DMSMS operational
processes

Have all DMSMS operational processes been defined and documented in the
government DMP?

Have all DMSMS operational processes been defined and documented in the
government DMP?

Manage case

Has the program defined DMSMS metrics that will be captured and tracked for DMSMS cases, trends, and associated resolutions and costs?

Has the program defined DMSMS metrics that will be captured and tracked for DMSMS cases, trends, and associated resolutions and costs?

Has the program identified how it will capture and track DMSMS metrics?

Has the program identified how it will capture and track DMSMS metrics?

Has the program developed or identified a DMSMS case tracking database?

Has the program developed or identified a DMSMS case tracking database?

Is the program using DMSMS metrics to track DMSMS cases, trends, and associated resolutions and costs?

Is the program using DMSMS metrics to track DMSMS cases, trends, and associated resolutions and costs?

Evaluate program

Has a plan to report DMSMS case management metrics (life-cycle costs and cost avoidance by being proactive associated with DMSMS resolutions) been established?

Has a plan to report DMSMS case management metrics (life-cycle costs and cost avoidance by being proactive associated with DMSMS resolutions) been established?

Are DMSMS case management metrics (life-cycle costs and cost avoidance by being proactive associated with DMSMS resolutions) being reported to program management?

Are DMSMS case management metrics (life-cycle costs and cost avoidance by being proactive associated with DMSMS resolutions) being reported to program management?

Ensure quality

Have metrics been established to measure the efficiency of DMSMS operational processes and to drive continuous process improvement?

Are process efficiency metrics being used to drive continuous process improvement?

Table 22. DMSMS Management Questions for Logistics Assessments: Identify (Section 4)

Process

Pre-IOC

Post-IOC

Prioritize systems

Are mission criticality, operational safety, and DMSMS-related costs being used to identify and prioritize the systems and subsystems to be monitored?

Are mission criticality, operational safety, and DMSMS-related costs being used to identify and prioritize the systems and subsystems to be monitored?

Identify and procure monitoring and
surveillance tools

Have DMSMS forecasting and associated data collection and management tools or service providers been researched and selected?

Have DMSMS forecasting and associated data collection and management tools been reviewed to determine their continued suitability for sustainment?

Have tool selections been made to supplement, as necessary?

Collect and prepare item data

Have the items associated with critical functions been identified?

Have the items associated with critical functions been updated?

Is a CDRL included for the delivery of the system BOM?

Have indentured BOMs for the systems been acquired in accordance with
DI-SESS-81656A?

Has the program obtained the following:

Design disclosed items, including subtier hardware indenture levels

F3/proprietary design items, including subtier hardware indenture levels

Items that are single source and those for which the government cannot obtain data rights and the associated corrective action plans are identified?

Has each indentured BOM been loaded into the DMSMS forecasting/management tool?

Has the BOM been regularly updated and reloaded into a DMSMS forecasting/
management tool or service?

Have items, materials, and software been identified for monitoring?

Have items, materials, and software been identified for monitoring?

Analyze item
availability

Are the selected forecasting/management tool or the results of manual research being used to identify immediate and near-term obsolescence issues associated with the BOM?

Are the selected forecasting/management tool or the results of manual research being used to identify immediate and near-term obsolescence issues associated with the BOM?

Is the program receiving obsolescence forecasts on a scheduled basis?

Is the program receiving obsolescence forecasts on a scheduled basis?

Are vendor surveys being conducted?

Are vendor surveys being conducted?

Are product discontinuation notices being received regularly?

Are product discontinuation notices being received regularly?

Collect and update programmatic and logistics data

Have programmatic and predicted reliability data needs for impact assessment been identified or updated and collected?

Have programmatic and actual reliability and inventory data for impact assessment been updated and collected?

Table 23. DMSMS Management Questions for Logistics Assessments: Assess (Section 5)

Process

Pre-IOC

Post-IOC

Assess impact of DMSMS issue

Has a formal technology roadmap and approved insertion/refreshment plan been developed and funded?

Has a formal technology roadmap and approved insertion/refreshment strategy been reviewed for potential updates and adjustments?

Does the technology roadmap and insertion/refreshment strategy focus on and address the identification of critical items, materials, and technologies, as well as emerging technologies?

Does the technology roadmap and insertion/refreshment strategy identify critical items, materials, and technologies, as well as emerging technologies?

Is the technology insertion/refreshment plan being used to determine the time frame for potential DMSMS operational impacts?

Is the technology insertion/refreshment plan being used to determine the time frame for potential DMSMS operational impacts?

Are DMSMS issues being considered as a basis for adjusting the scope or schedule of the technology refreshment?

Are DMSMS issues being considered as a basis for adjusting the scope or schedule of the technology refreshment?

Are DMSMS operational risks being identified and prioritized?

Are DMSMS operational risks being identified and prioritized?

Table 24. DMSMS Management Questions for Logistics Assessments: Analyze (Section 6)

Process

Pre-IOC

Post-IOC

Determine DMSMS resolution

Are resolutions to DMSMS impacts being identified?

Are resolutions to DMSMS impacts being identified?

Is a BCA or AoA being performed (including ROI calculations) as part of the resolution determination?

Is a BCA or AoA being performed (including ROI calculations) as part of the resolution determination?

Have all costs associated with a resolution been considered?

Have all costs associated with a resolution been considered?

Do mitigation strategies clearly address the entire system life cycle (not just the contract period)?

Do mitigation strategies clearly address the entire system life cycle (not just the contract period)?

Has resolution determination taken into account that the most cost-effective resolution may be found at a higher level of assembly?

Has resolution determination taken into account that the most cost-effective resolution may be found at a higher level of assembly?

Table 25. DMSMS Management Questions for Logistics Assessments: Implement (Section 7)

Process

Pre-IOC

Post-IOC

Secure DMSMS resolution funding

Is funding to mitigate DMSMS risk being identified and obtained?

Is funding to mitigate DMSMS risk being identified and obtained?

Have projected current and outyear DMSMS resolution budgets been established using a sound analytical basis that is persuasive enough to obtain necessary funding?

Have projected current and outyear DMSMS resolution budgets been established using a sound analytical basis that is persuasive enough to obtain necessary funding?

Have these projected resolution budgets been approved and included in the program’s LRFS documentation?

Have these projected resolution budgets been approved and included in the program’s LRFS documentation?

Have these resolution budgets been approved and funded?

Have these resolution budgets been approved and funded?

Implement DMSMS resolution

Are funded DMSMS resolutions being implemented on a timely basis?

Are funded DMSMS resolutions being implemented on a timely basis?

Table 26. DMSMS Management Questions for Logistics Assessments: Other

Process

Pre-IOC

Post-IOC

Not readily relatable to specific organizational principles, chapters, or processes

Is DMSMS a consideration when the system design approach is being determined in order to minimize the impact on supportability and sustainability?

Is DMSMS a consideration when the system modification approach is being determined in order to minimize the impact on supportability and sustainability?

Are the following addressed:

Open system architecture

Order of precedence for parts selection (use of QML parts, particularly for applications requiring extended temperature ranges)

Selection of parts relatively new in their life cycle

Minimized use of custom parts

Requirement for a preferred parts list and parts control prior to detailed design to minimize obsolescence issues

Identification of shelf and operating life requirements

Identification of technology life expectancies.

Are the following addressed:

Open system architecture

Order of precedence for parts selection (use of QML parts, particularly for applications requiring extended temperature ranges)

Selection of parts relatively new in their life cycle

Minimized use of custom parts

Requirement for a preferred parts list and parts control prior to detailed design to minimize obsolescence issues

Identification of shelf and operating life requirements

Identification of technology life expectancies.

Are DMSMS considerations incorporated into pertinent program documentation, e.g., LCSP, LRFS, and PSP?

Are DMSMS considerations incorporated into updates of pertinent program documentation, e.g., LCSP, LRFS, and PSP?

Appendix F. Counterfeit Items and DMSMS

Counterfeit items are a DMSMS management concern, because the items purchased to mitigate a DMSMS issue may be counterfeit.[111] This may happen with alternative or substitute items, or even with the original items, if they are purchased from an unauthorized supplier.[112] Consequently, DMSMS resolution options using unauthorized sources have both additional technical risk and costs due to the extra screening and testing necessary to ensure that the items are not counterfeit. This appendix begins with general background information on the proliferation of counterfeit items, including how they are made and what risks are associated with them.[113] It then expands on the impact of the counterfeit problem on DMSMS management.

F.1. Background

The number of counterfeit electronic items is proliferating in the open market, due to a number of factors. Below are the two primary factors:

  • Electronic scrap assemblies, also known as e-waste (electronic waste), are being shipped from all over the world to developing countries. The United States alone produces an estimated 3 million tons of electronic waste yearly, and the annual world production of ewaste has been estimated to be as high as 50 million tons. The developing countries where the counterfeiting is most prevalent produce enough of their own e-waste to have an indefinite supply. Entities ranging from small business operators to organized crime syndicates have seized upon this material as an opportunity to remove and refurbish items, with the intent to resell them with the misrepresentation that the product is new. There is no threshold on the dollar value of the items being counterfeited, from half-penny capacitors to thousand-dollar-plus complex microprocessors. These items might also be falsely represented as higher-grade product (higher speed, larger memory capacity, better operating temperature range, or subjected to military screening), which further increases the profit potential for the counterfeiter.
  • The growth of Internet sales has yielded unprecedented opportunities for profiteers to find a market for counterfeit products. A buyer or business owner in the United States has the capability to use various Internet search engines to locate an enormous number of advertised items from all over the world. A 2012 Government Accountability Office (GAO) report highlighted concerns about these search engines, because an undercover team procured multiple suspect counterfeit items and bogus items.[114]

F.1.1. How Counterfeit Items Are Made

Electronic items can be counterfeited in several different ways, including the following:

  • Cloning, that is, making a new product “from scratch” and misrepresenting it as the original brand
  • Stealing authentic product (bare die or packaged parts) from the manufacturer’s facility before completion of all processes
  • Re-marking new product to misrepresent the item’s function or pedigree (part number, date code or lot, country of origin, plating type, etc.)
  • Re-marking used or scrap product to misrepresent the item’s function or pedigree (part number, date code or lot, country of origin, plating type, etc.).

There is no accurate breakdown of the percentage of counterfeiting that can be attributed to each example above. However, it is generally accepted that the refurbishment of e-waste is a significant contributor to the counterfeit industry.

When electronic items are salvaged from electronic waste for resale, the processes for salvaging and refurbishing the items occur most often in countries where manual labor is cheap and regulatory actions are limited or nonexistent. This allows the counterfeiter to maximize profit and evade criminal prosecution. Items are removed from the scrap assemblies by melting the solder through uncontrolled heating processes. Items are cleaned up.[115] Leads are straightened and perhaps chemically treated and retinned to disguise signs of previous use. In some cases, cut leads are lengthened by attaching pieces of metal to the ends. If necessary, the actual part number and traceability information (lot code, date code, manufacturing facility, and country of origin) may be sanded off and a new coating applied to the item. For plastic or ceramic devices, this process is commonly referred to as “blacktopping.” A new part number and traceability information are then applied to the blacktopping, either by ink or through laser etching. Counterfeiters are constantly improving their methods. They have been known to “flat lap” items where the item markings are polished off of items and to “microblast” items, which involves media-blasting with various materials (such as glass beads, walnut shells, finely ground plastic particles, or dry ice) to remove old markings and clean the devices. The newly marked part number may or may not match the actual part number. Below are the most common reasons for re-marking a salvaged component:

  • To make the used item appear to be new.
  • To make a group of items from varied production lots appear to be from one homogeneous lot.
  • To make an item appear to be a better, more expensive, or less available version of the actual item.
  • To make an item appear to be a better, more expensive, or less available version of the same item type (not the same item).
  • To make an item appear to be any type of “in-demand” item (regardless of whether the item is a functional equivalent).

Only the last example represents an instance in which a user might expect a failure during item or system-level testing. In all other cases, the counterfeit product might pass all initial testing, only to fail in the application environment much sooner than anticipated, perhaps catastrophically for the user.

F.1.2. Risks of Using Counterfeit Parts

Significant risks are associated with the use of counterfeit items. The salvage or refurbishment process for used authentic items, as described above, is usually accomplished with little regard for the item’s internal integrity. Many plastic-encapsulated electronic items absorb moisture over time. If excess heat is applied before the moisture can be baked out, the items are easily damaged by the expanding gas as it exits the device. The damage takes the form of microcracks and internal voids that, if they do not cause immediate failure, can allow contaminants to seep in (e.g., during a cleaning process that exposes the item to unfiltered water) and dramatically reduce the item’s life. Of lesser risk, but still important, is the potential for component microcracks caused by mechanical flexure stress imparted onto the soldered items when the populated printed circuit board is bent, twisted, or flexed during the salvage operation. As with thermally induced micro-cracks, the component’s life may be reduced.

The storage and shipping of refurbished items[116] may also be suboptimal, introducing risk into the reliability of the item. Handling of the items in a non–electrostatic discharge (ESD) safe environment raises the distinct possibility of electrical damage to the part by applying static charges of thousands of volts to the component pins. Static-charge buildup is particularly possible during operations that generate repetitive friction, such as sanding a part number off. This type of damage is often latent, reducing the reliability of the device.

Even if new items are simply being recoated, retinned, resold from process rejects, or made entirely from scratch, there are reliability risks beyond those associated with authentic items. The testing that a program performs may be inadequate to eliminate break-in failures or to ensure operation to the specified environment. In addition, issues resulting from the handling, shipping, and storage of the product by parties unacquainted with (or unwilling to undertake the expense to counter) the moisture and ESD susceptibility of electronic items also apply to this product.

Finally, there is heightened concern for MilSpec components that have rigorous specifications and testing requirements from the OCM. MilSpec devices are not only opportunities for counterfeiters making a profit, but they introduce an opportunity for more nefarious “state-controlled” counterfeiters that may be interested in tampering with, infiltrating, or controlling a device or system.

F.1.3. Types of Items Being Counterfeited

The most commonly counterfeited electronic items are integrated circuits. However, there is still a risk of obtaining counterfeit items of other types. In fact, virtually every type of electrical or electronic item has been counterfeited. This includes electrical assemblies such as circuit breakers, and entire COTS assemblies such as Internet switches, as well as small passive parts such as ceramic capacitors. Figure 19 shows the distribution of the types of electronic parts commonly counterfeited. The figure is based on data generated by ERAI from 2,000 reports from 2012 to 2014.[117] As the figure shows, nearly 85 percent of counterfeit items are integrated circuits, and another 8 percent of the counterfeits are discrete semiconductors such as transistors and diodes. The remaining 7 percent are non-semiconductor types of the items, such as capacitors and inductors. When a profit is to be made, counterfeiters will make the attempt.

Figure 19. Breakdown of Counterfeit Electronic Parts

Breakdown of Counterfeit Electronic Parts

Source: ERAI.

A 2012 DLA briefing, “Counterfeit Items Detection and Prevention,” includes an assessment of counterfeiting activity discovered within DLA’s supply chain. This assessment could be used to set the foundation for risk-based and application-focused approaches to counterfeit avoidance. While industry market analyses tend to report counterfeiting risks associated with a subset of products falling within one federal supply group (FSG)—59–Electrical and Electronic Equipment Components—the DLA assessment covered 69 FSGs managed by DLA. The end result is DLA’s assessment of low, moderate, and high counterfeiting risk across all of those FSGs (and the 505 federal supply classes falling within them), as illustrated in Figure 20. The FSGs identified as having a high risk for counterfeiting (indicated in red) are those associated with incidents discovered by DLA through testing or reported by DLA customers. The “Top 5” high-risk FSGs (those with the highest number of incidents) are as follows:

  • FSG 59–Electrical and Electronic Equipment Components
  • FSG 29–Engine Accessories
  • FSG 47–Pipe, Tubing, Hose, and Fittings
  • FSG 53–Hardware and Abrasives
  • FSG 25–Vehicular Equipment Components.

FSGs identified as having a moderate risk (indicated in yellow) are those associated with incidents reported by other DoD organizations, GIDEP, or industry organizations or those associated with notorious markets. FSGs identified as having a low or “base-level” risk are indicated in green.

Figure 20. Assessment of Counterfeit Risk for DLA-Managed FSGs

Assessment of Counterfeit Risk for DLA-Managed FSGs

It is suspected that many instances of counterfeiting are unreported. The reasons for this non-reporting or underreporting are numerous. First, failures are often attributed simply to quality and reliability issues. Because few companies analyze failure mode effects when a system or assembly fails, it is not known how large the problem truly is. There may also be some uncertainty regarding the legal responsibility for reporting counterfeit items and any legal repercussions for possessing counterfeit material. The admission of counterfeit items having been detected in a product may also affect the perception of the product with customers and the market in general. Finally, there may be a motivation by some to be reimbursed for the items, if they can be returned to their source.

F.2. Summary of DoD Counterfeit Policy and Key Definitions

DoD’s primary interest with regard to counterfeit parts pertains to preventing the introduction of counterfeit items into DoD’s supply chain and, ultimately, into weapons systems, where they have the potential to adversely affect the safety and performance of the warfighter. DoDI 4140.67, “DoD Counterfeit Prevention Policy,” does the following:

  • “Establishes policy and assigns responsibilities necessary to prevent the introduction of counterfeit material at any level of the DoD supply chain”
  • “Provides direction for anti-counterfeit measures for DoD weapon information systems acquisition and sustainment to prevent the introduction of counterfeit materiel”
  • “Assigns responsibilities for prevention, detection, remediation, investigation, and reinstitution to defend the DoD against counterfeit materiel that poses a threat to personnel safety and mission assurance.”[118]

First and foremost, the policy mandates that DoD will “not knowingly procure counterfeit materiel.” However, under the assumption that counterfeit material may find its way into the DoD supply chain, the policy requires DoD to “employ a risk-based approach to reduce the frequency and impact of counterfeit materiel within DoD acquisition systems and DoD life-cycle sustainment processes.”[119]

Below are three key terms as they are defined in DoD policy:

  • Nonconforming product: “A product or the component of a product that has not been manufactured, assembled, tested, or inspected in accordance with the terms of the contract, its specifications, or drawings, including military specifications.”[120]
  • Suspect counterfeit: “Materiel, items, or products in which there is an indication by visual inspection, testing, or other information that it may meet the definition of counterfeit materiel.”[121]
  • Counterfeit material: “An item that is an unauthorized copy or substitute that has been identified, marked, or altered by a source other than the item’s legally authorized source and has been misrepresented to be an authorized item of the legally authorized source.”[122]

Of note, the Defense Federal Acquisition Regulation Supplement (DFARS), as amended in 2014, added specific requirements for defense contractors with respect to the avoidance, detection, containment, and reporting of counterfeit electronic items in response to anti-counterfeit sections in the National Defense Authorization Acts since 2012.[123] A critical element is the requirement for contractors to establish a counterfeit electronic item detection and avoidance system. The system should encompass (1) training; (2) inspection and test of items based on accepted techniques; (3) use of original manufacturers or authorized suppliers to obtain items; (4) reporting (and quarantining) of counterfeit and suspect counterfeit items to DoD and GIDEP; (5) flow down of counterfeit-related detection and avoidance requirements to subcontractors throughout the supply chain; (6) screening of GIDEP and other sources for information on counterfeiting; and (7) minimized use of obsolete electronic parts in order to maximize the availability and use of authentic, originally designed, and qualified electronic parts throughout the product’s life cycle.

F.3. The Impact of Counterfeit Items on DMSMS Management

DMSMS issues directly impact the marketability and profitability of counterfeit components (creating an incentive for counterfeiters to make and offer such items), because obsolete items are almost always more difficult to find than items that are still in production. Over 50 percent of counterfeit electronic items identified have been obsolete part numbers, indicating that counterfeiters have made obvious efforts to tap the highly profitable DMSMS market. In addition to these items being more likely to command a high price, obsolete items are usually available only from the gray market where counterfeiters sell their product alongside legitimate unauthorized suppliers.[124]

Defense and aerospace products are particularly vulnerable to counterfeit items due to item obsolescence. Microelectronics, in particular, have life cycles far shorter than those of the defense and aerospace products that use them. Robust DMSMS management helps avoid the introduction of counterfeit items, because the program will be more likely to deal with authorized suppliers.[125] Authorized suppliers include the OCM, OCM-authorized sales representative or distributor, a trusted foundry,[126] or an aftermarket manufacturer that owns the intellectual property rights for the item. Whenever possible, DMSMS resolutions should use items from authorized suppliers. The liability of providing counterfeit items to a valued customer can be sufficient to bankrupt a supplier, and the associated stigma will inevitably damage the brand of the organization if the concern is enough to drive the customer base away. Information on approved vendors can be obtained from ERAI, GIDEP, vendor assessment checklists, or on-site audits.

For that reason, the most reputable suppliers are extremely sensitive to the risk of counterfeit items. Such companies seek to buy only authentic products and expend significant effort in identifying reputable sources. They accomplish this by aggressively monitoring part databases, industry blogs, and internal purchasing quality history; participating in industry forums (e.g., the SAE G-19 Committee focused on preventing the proliferation of counterfeit electronic parts); standardizing practices (e.g., certification to SAE Standard AS 6081, Fraudulent/Counterfeit Electronic Parts: Avoidance, Detection, Mitigation, and Disposition – Distributers Counterfeit Electronic Parts; Avoidance Protocol, Distributers; accreditation to SAE Standard AS6496, Fraudulent/Counterfeit Electronic Parts: Avoidance, Detection, Mitigation, and Disposition – Distributers Counterfeit Electronic Parts; Avoidance Protocol, Distributers – Authorized/
Franchised Distribution
; and to DLA’s Qualified Testing Supplier List); and word of mouth. In addition, those companies maintain lists of sources that are not trusted, to ensure they do not purchase items from those sources.

The program may sometimes decide to purchase from unauthorized suppliers because of the expense or timeliness of other, less risky solutions. For example, it may not be possible to buy from any qualified source, and redesign may be too expensive.[127] However, the risk of purchasing a counterfeit item from the gray market is high. For integrated circuits, the risk may be nearly 100 percent (the only remaining items are refurbished product represented as new items).

A check, in 2012, of a popular Internet parts search engine found a glut of counterfeits of an integrated circuit (randomly selected from an obsolete item listing) that had been discontinued in 1998. In fact, more sources were listed on this site for items date coded 2001 or later than during the item’s production range of 1998 or earlier. Although certain MilSpecs (for example, MIL-PRF-38535 and MIL-PRF-19500) have clauses that require the identification of all known supply chain intermediaries back to the OCM, that requirement cannot often be met with material acquired from the open market. The GAO also revealed that suspect counterfeit and bogus (the part numbers are not associated with any authentic items) military-grade electronic items can be found on Internet purchasing platforms.[128]

When the selected DMSMS resolution calls for items to be purchased from an unauthorized supplier, programs must recognize that costs for minimum inspections and tests should be incurred to ensure that counterfeit items do not enter the supply system. In some cases, the cost of these tests may be quite substantial and may take a significant amount of time.

SAE Standard AS 6171, Test Methods Standard: General Requirements, Suspect/Counterfeit Electrical, Electronic Parts, contains a number of test methods for determining an appropriate approach to employ. The costs should be factored into the determination of the most appropriate resolution option.[129] No single test method can detect all the various methods of counterfeiting; counterfeiters keep improving the process to evade detection. Recommended inspections and tests are listed below:

  • Visual inspection (IDEA-STD-1010), to look for signs of re-marking, refurbishment, repackaging, and so forth.
  • Testing of marking permanency (IDEA-STD-1010), to attempt to remove subpar ink markings or surface coatings.
  • Testing of surface finish permanency (IDEA-STD-1010), to attempt to remove surface coatings. This should ideally include newer aggressive solvents proven to be more capable (than acetone) at removing newer, more robust coatings.
  • X-ray fluorescence of item leads, to determine if the item has the correct plating composition.
  • Radiological examination, to look for inconsistencies in the internal construction of the item.
  • Scanning acoustic microscopy, to determine if there is internal delamination, which may indicate exposure to excess thermal stress associated with uncontrolled removal from an assembly.
  • Decapsulation and die examination, to determine whether the die markings are consistent and as expected for the purchased item.
  • Curve trace or direct current electrical test of the device (for microcircuits) or a value measurement (for passive devices).
  • Full electrical testing or dynamic characterization of selected parameters to search for unexpected waveforms or excessive variation.

Conversely, items may fail some of the tests and still be authentic. The only way to truly maximize the confidence in items bought from unauthorized suppliers is to contact the OCM for the items and to have that organization review the analysis and weigh in on the authenticity of the product. Unfortunately, OCMs are under no contractual obligation to assist with these analyses if the items have been purchased from the gray market. In addition, the OCM may not be able to determine, from the test paperwork alone, if the items are authentic.

If the OCM agrees to review the analysis, then the requestor should provide as much detail as possible about the product, such as the following:

  • A 10X photograph of all external item markings, including bottom-side markings
  • Photos of packaging and documentation for the items
  • Description of which inspections and tests the items failed and how they failed
  1. High-magnification photos of the die markings.

OCMs state that an item can often be identified as counterfeit strictly by comparing the manufacturing logo, fonts, or lot and date code information against their internal data. However, counterfeiters often are expert at copying legitimate manufacturer markings and have access to legitimate die due to the e-waste issue.

If analysis confirms that the items are likely counterfeit or fraudulent, the items must be contained. Return of the items for refund or for any other reason is not acceptable, because those items may simply be reinserted into the gray market for future resale.

Counterfeit and fraudulent items must be reported to the appropriate authorities and organizations. DoD components are to report all occurrences of suspect and confirmed counterfeit materiel:

  1. To appropriate authorities, deficiency reporting systems, and GIDEP [www.gidep.org] within 60 calendar days.
  2. To DoD criminal investigative organizations and other DoD law enforcement authorities at the earliest opportunity.[130]

The requirement for defense contractors to report counterfeit electronic items is cited in DFARS, as amended in 2014.[131]

There are two additional risks that a program faces when dealing with high-risk suppliers:

  • The inspections and tests above can provide a degree of confidence as to whether a high-risk purchase contains authentic or counterfeit items. However, items may pass some or all of the tests and still be counterfeit. Additional testing may be required based on the application risk, the risk of the component in the application, and the risk of the supplier. The cognizant engineer should provide input on the appropriate level of testing, considering the total risk associated with the situation. All testing should be performed by a test laboratory that is qualified to perform the work.
  • If the items turn out to be counterfeit, the program still faces a perhaps more significant DMSMS issue. The problem must be resolved before it impacts schedule or readiness and a great deal of time would have been consumed for testing an infeasible resolution approach.

Appendix G. Accessing Organic Services and Capabilities to Mitigate DMSMS Issues

Today’s PMs, PSMs, and technical personnel are finding increasingly significant challenges in locating and securing supply solutions for legacy DoD systems. These challenges can only increase as the service life of DoD systems is extended. A number of unique engineering, manufacturing, and sustainment capabilities exist within the government’s industrial base and can be leveraged to help meet DMSMS challenges.

The government’s industrial base encompasses all of the manufacturing and sustainment providers that are owned and operated by the government. This includes the DoD locations termed arsenals and depots, as well as a portion of the National Laboratory system within the Department of Energy.

A list of all government industrial base locations is maintained to foster DMSMS community awareness of their capabilities and to expedite communications. Locations on this list have some manufacturing capabilities on-site and can support DoD organizations. The location list is periodically updated with information such as key contacts and addresses. Each key contact has agreed to be an initial point of contact for DoD personnel who are soliciting help on DMSMS issues. In addition, a more specific capabilities matrix has been created for participating government industrial base locations to specify their areas of manufacturing expertise, as well as to describe their mechanical, electronic, materials, and T&E capabilities.

The location list and capabilities matrix are designed to be complementary when used in tandem. For example, a DMSMS practitioner who has unfulfilled requirements for integrated circuit manufacturing can review the capabilities matrix to identify which government locations have those capabilities. Then the location list can be used to contact the respective locations to pursue particular DMSMS resolutions for that issue.

The most recent update of the government industrial base location list and capabilities matrix can be accessed within the DKSP.

Appendix H. DMSMS Knowledge Sharing Portal

The DKSP contains DMSMS-related information, resources, and material. Use of the DKSP will enable the DMSMS community, both organic and contractor, to implement best practices for robust DMSMS management. The DKSP is supported by the Defense Standardization Program Office (https://www.dsp.dla.mil) and is currently located within the DAU Acquisition Community Connection (ACC) website (https://acc.dau.mil). The DKSP is just one of a number of communities of practice (CoPs) hosted by the ACC, whose purpose is to connect people and acquisition know-how across DoD and industry. CoPs enable interaction and sharing of resources and experiences to support job performance, avoid duplication of effort, and advance the connection of people and ideas.

Participation in the ACC is free and completely voluntary, and much of its content is open to the public, requiring no login to access the extensive knowledge base. Although much of the information is publicly available, individuals who qualify can request ACC membership access. Becoming an ACC member provides additional capabilities that guests do not have. Those capabilities include accessing other members’ contact information, initiating and participating in discussions, contributing and sharing knowledge, creating bookmarks, subscribing to updates, and accessing restricted community knowledge. The DKSP can be accessed through the following link: https://acc.dau.mil/dmsms.

The DKSP content is organized by topic, shown on the left of the page, in a user-friendly format for easy navigation. The topics are as follows:

  • Conferences and Events. The content is broken down into (1) DMSMS conferences and (2) other DMSMS-related events (workshops, clinics, forums, symposiums, etc.).
  • DMSMS Training Courses. The content lists available DMSMS and other related training.
  • Organizations and Groups. The content is broken down by organization: DoD, DLA, Other Government, Army, Navy, Air Force, Marine Corps, and Industry.
  • Tools and Management Aids. The content is broken down by organization: DoD, DLA, Other Government, Army, Navy, Air Force, Marine Corps, and Industry.
  • Policy and Guidance. The content is organized by policy, guidance, and manuals/handbooks for DoD, DLA, Other Government, Army, Navy, Air Force, and Marine Corps and by standards for industry.
  • DMSMS Library. The content is broken down by organization: DoD, DLA, Other Government, Army, Navy, Air Force, Marine Corps, and Industry.

Appendix I. DMSMS Quality Assurance Process

A quality management system is the basis for QA. A QMS is an overarching framework that defines the organizational structure, responsibilities, methods, data management, processes, resources, customer satisfaction, and continuous improvement. The mitigation of DMSMS issues must be controlled in a QMS to receive optimal benefit and ensure consistency over time. A well-defined QMS can also ensure that the same high level of quality service and products can be produced regardless of personnel changes. This appendix focuses on control of DMSMS management processes.

I.1. Quality Plan

The QMS should call for a quality plan (as part of the DMP) that defines the checks of the system or product necessary to ensure quality, that is, to ensure that processes and product are in control and meet defined requirements. An excellent means of controlling processes is to document the responsibilities and methods associated with the processes in a series of procedures or work instructions and to establish quality checks at optimal points within the process to ensure that the work product meets defined quality standards. Quality checks are verifications to demonstrate whether the process is operating as defined. The quality plan should include the identification, collection, and monitoring of meaningful metrics to ensure that the process is successful. Metrics provide information as to whether the process must be adjusted to meet the intended outcome.

Different entities may use specific nomenclature to name the written process definitions, such as standard operating procedures, or work instructions. The nomenclature chosen for this documentation does not matter. This appendix suggests a naming scheme to provide clarity on the concept being presented.

A written procedure outlines how to perform a process. This level of documentation typically applies to the processes common across a function, such as DMSMS support. Because DMSMS support can vary significantly from one platform to the next, a second tier of process definition should be developed. This second level, often known as work instructions, is used at a work-group level to define how to perform a task. Each platform support team should develop its unique DMSMS support work instruction tailored to the support of its specific platform.

As an example of how this system may function, consider the processes to collect and disseminate PDNs and obsolescence event data, often referred to as “Alerts.” PDNs are published by part manufacturers to inform the industry that a part is targeted for discontinuance. A procedure could be written for how to find, confirm, and document this obsolescence event data. The platform support teams may take different actions in response to an alert; each team could write work instructions to describe its own specific process.

The general workflow in support of DMSMS management consists of data collection from many diverse sources, data compilation and analysis, risk assessment, and report or briefing development. Because data collection, manipulation, and analysis are at the heart of DMSMS team activities, data standards should be clearly defined. Data standards define such aspects of data management as content accuracy, data content, and data entry standards.

To establish quality checks, the DMT should review all of the process inputs and outputs. For each data stream, whether input or output, the DMT must decide the characteristics of a good record. The DMT should document these characteristics and make them available to the DMT members who may create or process that type of record.

The DMT determines the method to identify records that do not meet the defined standards. Quality checks can range from automated comparison of records to defined standards to simply having an experienced team member review the work of a less-experienced DMT member.

The DMT should review the process flow and determine where to insert quality checks. These locations are the points at which errors can be identified and corrected before additional work is applied and before the customer is affected. The quality plan should include the inspection points, the inspection method, and the error correction mechanism.

To demonstrate a quality check of data content accuracy, consider the record of availability status of a highly complex electronic part. In general, the obsolescence of such a part, in contrast to a part that is of low complexity, has a greater impact on the mission of the platform, and the mitigation of such a part can be much more difficult. Therefore, the accuracy of the data concerning this type of part is critical. In such a situation, the DMT may decide that verifying the content accuracy of the availability status of this type of part may require manufacturer contact or no less than two predictive tool providers to report the availability status for the part. The quality check to ensure content accuracy for this type of record could be to check that the availability record was verified by contact with the manufacturer or by the use of more than one predictive tool. For example, the DMT may decide that the part description in a part availability record must exactly match the approved list of part descriptions. The quality check would then determine whether, in fact, the entry for a part description matches the entry on the table of approved parts.

This same principle can be applied in other data streams, such as the recording of mitigation efforts, often called case data. The DMT may decide that the implementation date for the mitigation of an obsolete part should be recorded. In this situation, a quality check would verify the presence of an implementation date associated with all records tagged as “implemented.”

I.2. Metrics

Metrics measure the status of processes and activities within a quality plan. Keep in mind that metrics discussed in this appendix are measuring the DMSMS management processes operated by the DMT. This discussion does not include metrics focused on mission impact, such as cost avoidance by being proactive. Among the reasons that a process fails are budgeting of too little time or too little money, inadequate planning, constantly changing goals, lack of process knowledge, and ineffective communication. Often when a process is in danger of failing, management is unaware of the problems.

One of the best tools for avoiding process failures is to track key indicators of process health. The data should be presented in a meaningful way to help process managers make the proper decisions, take corrective steps on processes, or both. It is also important to define the right measurable periods that can cover possible gaps in the control of the measuring indicators, as well as allow control of the situation upfront if a failure occurs within the measurable intervals.

Process-specific metrics generally must have another figure—such as an industry benchmark or regulatory guidelines—against which they can be compared. However, sometimes metrics apply only to a particular organization, so no industry benchmarks would be available.

Five general criteria are typically used when defining metrics for a process:

  • Time
  • Cost
  • Resources (e.g., person-hours)
  • Quality
  • Actions.

When metrics are first applied to a process, it is often difficult to separate the categories of time, cost, and resources. Tracking metrics that provide information on combinations of two or more of these concepts is a viable approach. As the QMS matures and the situation necessitates, metrics can be redefined to provide more focused data. Below are two examples:

  • Electronic part availability research is necessary for programs that have parts lists or BOMs. This research can be time-consuming. Establishing the availability of these parts is also a product supplied by the predictive tool suppliers. In general, it could be more cost-effective and timely to the DMSMS professional to obtain part status data from at least one predictive tool supplier. One measure of resource usage would be to track the percentage of parts that the predictive tool companies recognize. By working with the predictive tool suppliers to increase the recognition rate of parts, the team is effectively moving part research from an internal process to a subscription deliverable and, thus, is using resources more effectively.
  • Data management in support of DMSMS management contains several distinct processes. A metric to provide feedback on adherence to schedule could be obtained by tracking the time to perform the intermediary processes, such as the time from receipt of a parts list or BOM to identification of the components to be monitored for availability. The time to perform the intermediary processes is then compared to a standard time established for this process. Metrics values consistently over the standard indicate that a problem exists in the process. Metrics consistently under the standard indicate a need to adjust the standard because the process has been improved.

The quality metric focuses on whether appropriate actions are taken in response to finding a process defect, not the existence of defects. The metric chosen should provide insight as to whether defects are tolerated or, even worse, ignored. In data management, a defect is a situation in which a defined standard is not met. Below are some examples:

  • The DMT may require, in the quality plan, measurement of the conformance of configuration records to defined standards. The associated metric would be to track the number of defective configuration records periodically and then to show the trend for this value. If the number of errors is higher than the acceptable quality level or increases over time, a problem exists with the quality of the CM process.
  • The DMT may choose to open a mitigation record for each monitored part that has an obsolescence issue. The DMT could then track the number of parts with obsolescence issues that do not have an associated mitigation record. In this situation, the quality of the program support process is being measured.

The actions metric focuses attention on identifying outstanding action items as a means of determining possible barriers to the process success. To use this type of metric, the DMT should maintain an action item summary in support of the process steps. This action item summary should then be reviewed to develop metrics:

  • Any differences between the action completion date and the projected completion date may indicate that a problem existed for that task. The difference between the action completion date and the projected completion date should be compared to a calculated standard established for support of that platform. This metric is most meaningful for DMT members accustomed to setting reasonable projected completion dates.
  • A quick metric to calculate is the number of open items. This metric measures multiple program aspects. This metric may measure the skill of the PM in capturing the steps necessary to support the program. This metric also may indicate that a project is experiencing difficulties in completing tasks.

Beyond these general metric categories are some more intangible signs that a project may be in trouble. These signs include a general lack of interest in the project, poor communication among team members, a fear of talking about project problems, and a generalized lack of project advancement.

To be successful, metrics must be well thought out and consistently applied. The DMT must be very clear as to the meaning of the metric values. Finally, the DMT must act upon the process health conclusions provided by the metrics in a timely manner to correct or improve the process, metric, or both.

I.3. Process Analysis

A detailed analysis of the processes used in DMSMS management can be valuable both in eliminating defects in the process and in improving efficiency. One type of business process analysis that has been used successfully to improve a DMSMS process is Lean Six Sigma (LSS), a methodology that employs a collaborative team effort to improve performance by systematically identifying and removing “waste.” In the LSS context, “waste” means any nonproductive, obstructive, or error-causing parts of a business process. These components of waste are called “defects.” The purpose of an LSS analysis is to identify the defects in the process and to devise approaches to eliminating or mitigating them. The DMAIC approach is one that is commonly used for an LSS analysis: DMAIC means “Define, Measure, Analyze, Improve, Control,” and it comprises the steps in the overarching process used by the analysis team. The final step is to put in place controls that ensure that defects are minimized and thus maintain the overall quality of the process.

Such an approach could be applied, for example, to the DMSMS management of COTS assemblies for which status is determined through vendor surveys.

In a DMSMS COTS process, the functions that must be performed are to monitor items for potential obsolescence, identify parts impacted, evaluate need for opening a DMSMS case, and implement a case when required. The process to accomplish these functions could be composed of four basic subprocesses:

  • Market surveillance—use vendor surveys, vendor contacts, website analysis, and forecasting tools to discover potential parts obsolescence issues.
  • Verify item identity, stocks on hand, and demand trends for the item at issue.
  • Determine if the obsolescence issue will impact the program via analysis of demand and stockage levels, from which “health charts” may be constructed.
  • Open and evaluate cases, determine preferred resolutions, and track resolutions.

COTS obsolescence management is characterized historically as a largely manual effort with extensive human reactions that are subject to error, not to mention inefficiencies. Variability and non-value-added steps result in additional labor, schedule delays, and increased costs. Such defects can then be effectively identified and addressed via LSS methodologies. Developing an automated database is a first step toward a faster, more efficient, and less error-prone process.

One DMSMS management team that conducted an LSS analysis of its DMSMS process for COTS items identified 131 defects occurring in an approximate 1-year period in market surveillance of COTS parts. The LSS analysis team defined a “reactive defect” to be one wherein an identified obsolescence date occurred in the past and “updates within 4 months defects” were instances in which the date occurred within 4 months of the current date (thus limiting the time available for case analysis and determination of resolution, if required). Process changes identified to address these defects resulted in substantial reductions in defects (25 percent or more) and attendant improvements in process efficiency on the order of 25–30 percent or more (depending on the subprocess).

To implement an LSS project for DMSMS, an LSS team is formed, headed if possible by an LSS “black belt.”[132] Team membership should comprise representatives knowledgeable in the various aspects of the process under scrutiny.

Assuming the DMAIC procedure will be followed, in the Define phase of the project, the team focuses on the overall process and identifies the overarching “problem” causing inefficiencies and errors. The team comprehensively examines the process and narrows down the areas of deficiency. An initial process map is created, and the metrics and data identified that can quantify the problem. It is particularly useful to document the value stream map (VSM) that describes the value-added workflow steps that produce required products. The VSM facilitates identifying non-value-added steps within the process for potential elimination or at least modification to create value. This phase ends with the drafting of a charter for the project containing a broad statement of the problem and the overall goals of the project. In addition, anticipated roadblocks are identified and a plan to overcome them formulated.

The Measure phase includes the development of a data collection method to capture pertinent aspects of the current processes and their outputs, the collection of data, and the establishment of a baseline for measuring improvements. For example, the time to accomplish a process segment might be a meaningful measure to examine. Another would be the trend in defect rate over time.

The Analyze phase determines the most critical root causes of defects from as many perspectives as possible. Team “brainstorming” sessions generate ideas to bring about process improvement. This process should be wide open, with the objective of identifying as many ideas as possible. The team then filters, sorts, combines, evaluates, and distills the improvement ideas into a feasible, most promising set.

In the Improve step, an implementation plan is formulated and initiated. If the list of desired improvements is lengthy, it will likely be necessary to time-phase implementation due to budgetary, operational, or other constraints, such as equipment or software availability.

Lastly, the Control step ensures that the improvements are being realized. A process of continuous improvement will seek to identify further improvements.

Appendix J. DMSMS Program Capability Levels

The DMP should include plans for achieving the target DMSMS capability level. This appendix contains information to help guide a decision on the appropriate level for a program.

Table 27 identifies the program capability levels for each DMSMS management step and process. The levels are defined as follows:

  • Level 1 represents minimal DMSMS management capability. Practices are largely reactive.
  • Level 2 represents a DMSMS management capability greater than Level 1. Practices are somewhat proactive in situations where proactive practices are needed.
  • Level 3 represents a DMSMS management capability greater than Level 2. Proactive practices are used when needed.
  • Level 4 represents robust DMSMS management capability. Comprehensive efforts are being applied whenever required.

A program should use the table as the basis for determining the current state of its DMSMS management practices. This is done by examining each row of the table and identifying what is being done. If the program does not have a DMP, then it is effectively below capability Level 1. The DMP should provide a basis for systematically progressing through the capability levels to achieve its target. Several factors should be considered when determining the appropriate target capability level for a program:

  • A lower capability level could be sufficient near the end of a system’s life cycle.
  • A higher capability level might be needed for more complex systems, because such programs are more likely to encounter DMSMS issues. However, smaller programs may be seriously affected, depending on the technologies used.
  • A higher capability level cannot be achieved without significant DMSMS subject matter expertise and DMSMS training for the entire DMT.
  • Not every DMSMS management process must be at the same capability level.
  • A program cannot immediately move from a low capability level to a high capability level; the transition should be gradual.
  • Resource constraints may exist, either for a single program or for a group of programs.

Table 27. DMSMS Program Capability Levels

Step

Process

Level 1

Level 2

Level 3

Level 4

Prepare

Establish strategic under-pinnings

Strategic underpinnings not established

Program leadership sets strategic underpinnings for DMSMS management

Program leadership sets strategic underpinnings for DMSMS management

Program leadership sets strategic underpinnings for DMSMS management

Develop a DMP

DMP developed

DMP approved and signed by program leadership

DMP approved and signed by program leadership and updated periodically

DMP approved and signed by program leadership and updated periodically

DMP calls for no or minimal government oversight of contractor activities

DMP calls for limited government oversight of contractor activities

DMP calls for extensive government oversight of contractor activities

DMP calls for extensive government oversight of contractor activities

Marginal contract requirements covering some aspects of DMSMS management

Contract requirements established for all significant and applicable aspects of DMSMS management

Contract requirements, to include exit clauses, established for all significant and applicable aspects of DMSMS management

Contract requirements, to include exit clauses and incentives, established for all significant and applicable aspects of DMSMS management

Form a DMT

DMSMS point of contact established (but retains other duties)

DMSMS point of contact established (but retains other duties)

Full DMT formed including all stakeholders with an understanding of their roles and responsibilities

Full DMT formed including all stakeholders with an understanding of their roles and responsibilities

No independent DMSMS SME

Limited funding for the use of an independent DMSMS SME

Independent DMSMS SME funded to assist the government with overseeing the prime contractor, give an independent perspective on issues and resolutions, and provide general DMSMS management advice

Independent DMSMS SME funded to assist the government with overseeing the prime contractor, give an independent perspective on issues and resolutions, and provide general DMSMS management advice

DMSMS point of contact has limited training

DMSMS point of contact trained

DMT trained

DMT members have advanced DMSMS training

Secure DMT
operations funding

No DMSMS-earmarked funding

Funded to operate at Level 2

Funded to operate at Level 3

Funding shortfall and impact identified and reported to decision makers

Funded to operate at Level 4

Prepare (cont’d)

Establish DMSMS operational processes

DMSMS operational processes entirely ad hoc and reactive

DMSMS operational processes defined, but not documented

DMSMS operational processes defined and documented, and processes are proactive when needed

DMSMS operational processes defined and documented, and processes are proactive when needed

Manage cases

No record keeping or metrics

Ad-hoc record
keeping and some metrics

Record keeping formalized and
metrics collected

Record keeping formalized and
metrics collected

Evaluate program

No metrics collected

Limited metrics collected, limited attempt to evaluate program

Metrics aggregated and analyzed to improve program performance; metrics used to justify operational budgets

Metrics widely accepted and used by program management

Ensure quality

No QA metrics collected

Limited QA metrics collected, limited attempt to improve process

QA metrics established and used for corrective action and continuous process improvement

QA metrics established and used for corrective action and continuous process improvement

Identify

Prioritize systems

No prioritization of subsystems

Subsystems and items prioritized for DMSMS
management
execution

Materials and software explicitly
considered

Materials and software explicitly
considered

No prioritization of items

Items evaluated to the lowest level to determine a risk-based approach to DMSMS management activity

Materials and software explicitly considered

Materials and software explicitly considered

Identify and procure monitoring and surveillance tools

Predictive tools and data management tools only partially in place

Predictive tools and data management tools in place

Comprehensive DMSMS management systems in place

Comprehensive DMSMS management systems in place

Collect and prepare item data

Only miscellaneous item data collected; everything driven by PDNs or the inability to procure the item

BOM data collected, but may not be indentured

Indentured BOM data collected (including software and materials); vendors surveyed for assemblies, mechanical parts, software, and materials

Indentured BOM data collected (including software interface specifications and materials); vendors surveyed for assemblies, mechanical parts, software, and materials

Identify (cont’d)

BOM data errors not fully corrected

BOM data errors corrected

Items and materials prioritized and determination made regarding what to exclude from proactive monitoring

All items and materials prioritized and determination made regarding what to exclude from proactive monitoring

Analyze item
availability

Predictive tools used occasionally

Results of predictive analyses for electronic items examined continually

Results of at least two predictive tools examined continually for electronic items

Vendors surveyed periodically for MaSME items and software

Results of at least two predictive tools examined continually for electronic items

Vendors surveyed periodically for MaSME items and software

Collect and update programmatic and logistics data

No logistics and programmatic data collected

Limited logistics and programmatic data collected

Some logistics and programmatic data collected for impact assessment

Comprehensive logistics and programmatic data
collected for impact assessment

Assess

Assess
impact of DMSMS issue

Ad hoc; only when PDN received

Only parts
availability
considered

Some logistics and programmatic data and vendor surveys being used to determine when an operational impact will occur

Extensive logistics and programmatic data and vendor surveys (including software and materials) being used to determine when an operational impact will occur

No priorities

No priorities

Rough priorities being assigned

Specific priorities being assigned; next higher levels of assembly being examined for operational impact

No technology roadmaps

Technology roadmaps
not used to determine impact

Technology roadmaps being used to determine impact

Technology roadmaps being used to determine impact

Analyze

Determine DMSMS resolution

Ad hoc; limited cost data used

AoA conducted
using unrefined cost factors

BCA conducted using refined cost factors, tailored to the specific
problem

Resolution options determined at item level and for higher levels of assembly

BCA used where necessary

Implement

Secure DMSMS
resolution funding

No resolution budgets; funding sought on case-by-case basis

No resolution budgets; funding sought on case-by-case basis

Resolution budgets funded based on projections of issues; outyear budgets unfunded

Active engagement in obtaining other sources of funding; outyear budgets programmed

Implement DMSMS resolution

No follow-up

Minimal oversight of execution

Comprehensive oversight of
execution

Comprehensive oversight of
execution

Appendix K. Lead-Free Electronics and DMSMS Resolutions

For more than 50 years, the electronics industry has relied on tin-lead (SnPb) solder as the primary means of interconnection between electronic devices.[133] The European Union’s RoHS directive, issued in January 2003, and other international and domestic mandates to eliminate materials deemed hazardous to health have forced the electronics industry to adopt solders and termination finishes free of lead (Pb). Although aerospace and defense electronics are excluded from these Pb-free mandates, many of their component suppliers are consumer electronics companies, driven by the needs of high-volume customers that demand RoHS compliance to enter or preserve European markets. Suppliers sometimes provide products in two forms, but usually only temporarily, before converting to a single Pb-free (RoHS-compliant) version. New products are being introduced almost exclusively in Pb-free form.

Nearly all parts and material suppliers and most board assemblers represent the lowest tiers of the global electronics supply chain. Avionics OEMs and logistics, maintenance, and repair providers draw upon this global supply chain, along with a few captive aerospace suppliers, to provide electronic subsystems to platform integrators and operators. As a result, highly demanding aerospace and defense applications are being forced to use components targeted for high-volume commercial markets with far less demanding requirements. Manufacturing in the global electronics supply chain cannot be controlled by the low-volume aerospace and military electronics customers.

Avionics, defense electronics, and other high-reliability electronic applications differ in significant ways from the vast majority of commercial and consumer electronic applications. Field environments often include extreme temperature and humidity, high altitude, high levels of shock and vibration, underwater exposure, or the extremes of space. Product lifetimes are often measured in decades, rather than in years. Contrary to most commercial practices, maintenance and repair activities are routinely performed down to the replacement of individual components on circuit cards. These maintenance and repair activities often occur many years after initial manufacture, at varied and distant locations, and under the control of agencies not always under the direction of the OEM. Finally, failure of the equipment to perform may have dire consequences.

The reliability of SnPb interconnections is well known and meets the requirements of these more demanding applications. In contrast, the scientific information indicates increased reliability risks in using Pb-free solder in high-performance electronics. These risks include the spontaneous formation of tin whiskers from Pb-free tin-based finishes, reduced Pb-free solder joint integrity, reduced reliability by cross-contamination between the different alloys, and the potential component and board damage from the higher Pb-free processing temperatures.

The first consideration in DMSMS management of Pb-free electronics is the risks of using them in the program. The program must therefore determine where Pb-free solder is acceptable and where it must not be used. For example, a program may determine that Pb-free components are viable options, but that the leads need to be applied with a SnPb finish prior to installation. Or, as another example, a program may determine that Pb-free components can be used for all non-mission-critical systems, but not for any mission-critical components, which should continue to use only leaded parts.

Pb-free components affect DMSMS risk management in several ways:

  • The RoHS directive has undoubtedly exacerbated the problem of obtaining traditional SnPb parts and components due to market changes. As the commercial market transitions to Pb-free construction and finishes on parts and components, the availability of the originally selected parts in SnPb becomes smaller. Also, new technology alternates are unlikely to have configurations with SnPb construction and finishes.
  • The obsolescence status of an item may be in error. In some cases, component manufacturers that stop using SnPb finishes entirely have kept the same part number. Even if the component manufacturer elects to continue to produce a SnPb version of their item, there is no established protocol on whether to keep the original part number or to assign a new part number to the SnPb item.
  • The technical viability of certain resolution options is affected. Alternative items that do not use SnPb solder are not necessarily usable.
  • It may be necessary to take mitigation steps when buying items. For example, x-ray crystallography may be needed to determine whether or not SnPb solder was used and to prevent Pb-free components from entering the supply system. Another option could be the use of conformal coatings to discourage the growth of tin whiskers.

The Government Electronics and Information Technology Association (GEIA) originally developed the following handbooks and standards to help manage the effects of Pb-free electronics. GEIA no longer exists. In 2013, SAE International assumed responsibility for these documents and is in the process of updating them.

  • GEIA-HB-0005-1, “Program Management/Systems Engineering Guidelines for Managing the Transition to Lead-Free Electronics”
  • GEIA-HB-0005-2, “Technical Guidelines for Aerospace and High Performance Electronic Systems Containing Lead-free Solder and Finishes”
  • GEIA-HB-0005-3, “Rework/Repair Handbook to Address the Implications of Lead-Free Electronics and Mixed Assemblies in Aerospace and High Performance Electronic Systems”
  • GEIA-STD-0005-1A, “Performance Standard for Aerospace and High Performance Electronic Systems Containing Lead-Free Solder”
  • GEIA-STD-0005-2A, “Standard for Mitigating the Effects of Tin Whiskers in Aerospace and High Performance Electronic Systems”
  • GEIA-STD-0005-3A, “Performance Testing for Aerospace and High Performance Electronic Interconnects Containing Pb-Free Solder and Finishes”
  • GEIA-STD-0006, “Requirements for Using Solder Dip to Replace the Finish on Electronic Piece Parts.”

Appendix L. Complete Department of Commerce Cost Survey Results

This appendix can be used, with caution, to modify the averages based on more specific circumstances. The appendix is a three-part table (Table 28) that contains the complete results from the Department of Commerce survey. The rows of the table show the above resolution options subdivided by environment (aviation, ground, shipboard, space, and undersea). The columns show the commodity type (electrical, mechanical, and electronics) subdivided by item type (assembly, component, raw material, and software). Entries in the table are average cost and sample size. Little confidence should be placed in entries with a low sample size.


Table 28. Number of DMSMS Resolutions Reported and Average Cost by Type,
Commodity, and Environment (Part 1)

Electrical

Assembly

Component

Electrical Total

No.

Average

No.

Average

No.

Average

Approved Parts

86

$2,764

901

$199

987

$422

Aviation

10

$1,500

191

$937

201

$965

Ground

76

$2,930

0

76

$2,930

Shipboard

0

0

0

Space

0

710

710

Life of Need Buy

3

$5,772

24

$12,467

27

$11,723

Aviation

0

1

$57,000

1

$57,000

Ground

3

$5,772

3

$14,066

6

$9,919

Shipboard

0

0

0

Space

0

20

$10,000

20

$10,000

Simple Substitute

0

190

$3,315

190

$3,315

Aviation

0

89

$4,960

89

$4,960

Ground

0

4

$21,125

4

$21,125

Shipboard

0

0

0

Space

0

97

$1,072

97

$1,072

Undersea

0

0

0

Complex Substitute

1

$129,000

33

$15,565

34

$18,902

Aviation

0

0

0

Ground

1

$129,000

29

$14,441

30

$18,260

Shipboard

0

4

$23,713

4

$23,713

Undersea

0

0

0

Extension of Production or Support

27

$27,000

0

27

$27,000

Aviation

27

$27,000

0

27

$27,000

Ground

0

0

0

Shipboard

0

0

0

Repair, Refurbishment or Reclamation

1

$7,500

0

1

$7,500

Aviation

0

0

0

Ground

1

$7,500

0

1

$7,500

Shipboard

0

0

0

Undersea

0

0

0

Development of a New Item or Source

11

$222,370

3

$1,179,368

14

$427,441

Aviation

0

3

$1,179,368

3

$1,179,368

Ground

11

$222,370

0

11

$222,370

Shipboard

0

0

0

Redesign–NHA

1

$321,617

1

$20,000

2

$170,809

Aviation

1

$321,617

1

$20,000

2

$170,809

Ground

0

0

0

Shipboard

0

0

0

Redesign Complex/System Replacement

12

$21,115,333

0

12

$21,115,333

Aviation

12

$21,115,333

0

12

$21,115,333

Ground

0

0

0

Shipboard

0

0

0

All for Part Type

142

$1,811,776

1152

$4,496

1294

$202,822

Table 28. Number of DMSMS Resolutions Reported and Average Cost by Type,
Commodity, and Environment (Part 2)

Electronics

Assembly

Component

Raw Material

Software

Electrical Total

No.

Average

No.

Average

No.

Average

No.

Average

No.

Average

Approved Parts

47

$2,335

269

$789

0

0

316

$1,019

Aviation

31

$62

207

$298

0

0

238

$267

Ground

1

$4,543

45

$749

0

0

46

$832

Shipboard

15

$6,886

17

$6,686

0

0

32

$6,886

Space

0

0

0

0

0

Life of Need Buy

86

$3,586

547

$5,163

0

0

633

$4,949

Aviation

44

$4,384

392

$5,292

0

0

436

$5,200

Ground

10

75

$1,778

0

0

85

$1,569

Shipboard

32

$3,610

68

$1,805

0

0

100

$2,383

Space

0

12

$41,133

0

0

12

$41,133

Simple Substitute

91

$3,339

1141

$15,232

1

$20,000

0

1233

$14,358

Aviation

80

$2,412

989

$16,310

1

$20,000

0

1070

$15,274

Ground

0

105

$7,379

0

0

105

$7,379

Shipboard

11

$10,080

47

$10,080

0

0

58

$10,080

Space

0

0

0

0

0

Undersea

0

0

0

0

0

Complex Substitute

63

$20,107

268

$28,113

0

0

331

$26,590

Aviation

40

$4,090

265

$28,346

0

0

305

$25,165

Ground

4

$252,043

3

$7,600

0

0

7

$147,282

Shipboard

19

$5,000

0

0

0

19

$5,000

Undersea

0

0

0

0

0

Extension of Production or Support

9

$13,750

54

$11,149

5

$195,600

0

68

$25,055

Aviation

9

$13,750

51

$11,706

5

$195,600

0

65

$26,135

Ground

0

3

$1,667

0

0

3

$1,667

Shipboard

0

0

0

0

0

Repair, Refurbishment or Reclamation

12

$89,254

26

$58,442

0

0

38

$68,172

Aviation

0

4

$175,672

0

0

4

$175,672

Ground

1

$38,400

1

$741,000

0

0

2

$389,700

Shipboard

5

$126,650

21

$3,610

0

0

26

$27,272

Undersea

6

$66,567

0

0

0

6

$66,567

Development of a New Item or Source

24

$1,459,651

79

$449,964

0

0

103

$685,231

Aviation

15

$1,142,949

71

$399,946

0

0

86

$529,539

Ground

7

$2,212,485

7

$985,861

0

0

14

$1,599,173

Shipboard

2

$1,200,000

1

$250,000

0

0

3

$883,333

Redesign - NHA

56

$1,661,963

72

$654,588

0

4

$2,250,484

132

$1,130,320

Aviation

16

$1,613,126

25

$1,439,633

0

1

$1,354,200

42

$1,503,691

Ground

33

$1,979,628

5

$164,560

0

3

$2,549,245

41

$1,799,958

Shipboard

7

$276,023

42

$245,637

0

0

49

$249,978

Redesign Complex/System Replacement

22

$5,748,030

9

$7,964,419

0

0

31

$6,391,498

Aviation

11

$5,360,447

7

$9,879,786

0

0

18

$7,117,968

Ground

3

$1,454,808

2

$1,260,634

0

0

5

$1,377,138

Shipboard

8

$7,890,915

0

0

0

8

$7,890,915

All for Part Type

410

$628,638

2465

$74,819

6

$166,333

4

$2,250,484

2885

$156,732

Table 28. Number of DMSMS Resolutions Reported and Average Cost by Type,
Commodity, and Environment (Part 3)

Mechanical

All Res. Types/

Assembly

Component

Raw Material

Mechanical Total

Environment

No.

Average

No.

Average

No.

Average

No.

Average

No.

Average

Approved Parts

0

228

$3,375

8

$9,295

236

$3,576

1539

$1,028

Aviation

0

0

3

$6,667

3

$6,667

442

$628

Ground

0

226

$3,344

1

$4,484

227

$3,349

349

$2,926

Shipboard

0

2

$6,925

4

$12,468

6

$10,620

38

$7,476

Space

0

0

0

0

710

Life of Need Buy

1

$11,500

5

$5,072

0

6

$6,143

666

$5,234

Aviation

1

$11,500

0

0

1

$11,500

438

$5,333

Ground

0

5

$5,072

0

5

$5,072

96

$2,273

Shipboard

0

0

0

0

100

$2,383

Space

0

0

0

0

32

$21,675

Simple Substitute

3

$6,249

72

$6,109

2

$38,500

77

$6,956

1500

$12,579

Aviation

0

0

1

$2,000

1

$2,000

1160

$14,472

Ground

3

$6,249

72

$6,109

0

75

$6,115

184

$7,162

Shipboard

0

0

0

0

58

$10,080

Space

0

0

0

0

97

$1,072

Undersea

0

0

1

$75,000

1

$75,000

1

$75,000

Complex Substitute

5

$26,835

19

$20,080

21

$21,835

45

$21,649

410

$25,410

Aviation

0

1

$26,000

4

$29,750

5

$29,000

310

$25,227

Ground

0

0

1

$32,604

1

$32,604

38

$42,405

Shipboard

5

$26,835

18

$19,751

15

$13,795

38

$18,332

61

$14,532

Undersea

0

0

1

$100,000

1

$100,000

1

$100,000

Extension of Production or Support

0

2

$21,740

1

$20,000

3

$21,160

98

$25,472

Aviation

0

0

1

$20,000

1

$20,000

93

$26,320

Ground

0

0

0

0

3

$1,667

Shipboard

0

2

$21,740

0

2

$21,740

2

$21,740

Repair, Refurbishment or Reclamation

1

$2,534

0

0

1

$2,534

40

$65,015

Aviation

0

0

0

0

4

$175,672

Ground

1

$2,534

0

0

1

$2,534

4

$197,359

Shipboard

0

0

0

0

26

$27,272

Undersea

0

0

0

0

6

$66,567

Development of a New Item or Source

3

$1,951,415

6

$132,500

1

$25,000

10

$667,425

127

$655,411

Aviation

2

$2,750,00

5

$115,000

1

$25,000

8

$762,500

97

$568,851

Ground

1

$354,246

1

$220,000

0

2

$287,123

27

$941,064

Shipboard

0

0

0

0

3

$883,333

Redesign - NHA

2

$133,000

2

$502,180

0

4

$317,590

138

$1,092,856

Aviation

1

$140,000

1

$862,500

0

2

$501,250

46

$1,402,156

Ground

0

0

0

0

41

$1,799,958

Shipboard

1

$126,000

1

$141,860

0

2

$133,930

51

$245,427

Redesign Complex/System Replacement

1

$1,150,000

0

0

1

$1,150,000

44

$10,287,964

Aviation

0

0

0

0

30

$12,716,914

Ground

1

$1,50,000

0

0

1

$1,150,000

6

$1,339,282

Shipboard

0

0

0

0

8

$7,890,915

All for Part Type

16

$464,825

334

$10,357

33

$19,845

383

$30,160

4562

$159,179

Appendix M. Abbreviations

ACC

Acquisition Community Connection

AME

Advanced Microcircuit Emulation (program)

AoA

analysis of alternatives

ARCI

Accountable/Responsible/Consulted/Informed

AS

Acquisition Strategy

ASIC

application-specific integrated circuit

ASR

Alternative Systems Review

AvCIP

Aviation Component Improvement Program

BCA

business case analysis

BOM

bill of materials

CAGE

CCB

configuration control board

CDR

Critical Design Review

CDRL

Contract Data Requirements List

CM

configuration management

CoP

community of practice

COTS

commercial off-the-shelf

DAC

Defense Acquisition Challenge

DAG

Defense Acquisition Guidebook

DAU

Defense Acquisition University

DAWIA

Defense Acquisition Workforce Improvement Act

DFARS

Defense Federal Acquisition Regulation Supplement

DID

data item description

DKSP

DMSMS Knowledge Sharing Portal

DLA

Defense Logistics Agency

DMP

DMSMS management plan

DMS

Diminishing Manufacturing Sources

DMSMS

Diminishing Manufacturing Sources and Material Shortages

DMT

DMSMS management team

DoD

Department of Defense

DoDD

DoD Directive

DoDI

DoD Instruction

DoDM

DoD Manual

ECP

engineering change proposal

EOL

end of life

ESD

electrostatic discharge

F3

form/fit/function

FCT

Foreign Comparative Testing (program)

FMS

foreign military sales

FSG

Federal Supply Group

GAO

Government Accountability Office

GEIA

Government Electronics and Information Technology Association

GEM

Generalized Emulation of Microcircuits (program)

GIDEP

Government-Industry Data Exchange Program

GOTS

government off-the-shelf

HDL

Hardware Description Language

IBASF

Industrial Base Analysis and Sustainment Fund

ICA

Industrial Capability Assessment

IDEA

Independent Distributors of Electronics Association

IMP

integrated master plan

IMS

integrated master schedule

IOC

Initial Operational Capability

IPS

Integrated Product Support

IPT

Integrated Product Team

LA

logistics assessment

LCL

life-cycle logistics

LCSP

Life-Cycle Sustainment Plan

LECP

logistics engineering change proposal

LRFS

Logistics Requirements and Funding Summary

LRU

line replaceable unit

ManTech

manufacturing technology (program)

MDA

Milestone Decision Authority

MDD

materiel development decision

MilSpec

military specification

NAVAIR

Naval Air Systems Command

NHA

next higher assembly

NPV

net present value

NSN

national stock number

NTE

not to exceed

O&S

operating and support

OCM

original component manufacturer

OEM

original equipment manufacturer

OSCR

Operating and Support Cost Reduction (program)

OSD

Office of the Secretary of Defense

OWG

Obsolescence Working Group

Pb

lead

PBL

performance-based logistics

PDN

product discontinuance notice

PDR

Preliminary Design Review

PM

program manager or program management

PQM

production, quality, and manufacturing

PRR

Production Readiness Review

PSM

product support manager

PSP

Product Support Plan

QA

quality assurance

QML

Qualified Manufacturers List

QMS

quality management system

QPL

Qualified Products List

R&D

research and development

RFP

request for proposals

RoHS

Restriction of Hazardous Substances

ROI

return on investment

ROM

rough order of magnitude

SE

systems engineering

SFR

System Functional Review

SME

subject matter expert

Sn

tin

SOO

statement of objectives

SOW

statement of work

SPRDE

systems planning, research, development, and engineering

SRA

shop replaceable assembly

SRR

Systems Requirements Review

SRU

shop replaceable unit

STM

science and technology management

SYSPARS

Systems Planning and Requirements Software

T&E

test and evaluation

TDP

technical data package

TDS

Technology Development Strategy

U.S.C.

United States Code

VE

value engineering

VECP

value engineering change proposal

VEI

value engineering incentive

VHSIC

very high speed integrated circuit

WCF

working capital fund

WRA

weapon replaceable assembly

SD-22 DMSMS Cover Image

  1. The term “software” encompasses COTS, custom, or any combination thereof of firmware, middleware, wrappers, gateways, firewalls, application programs, and operating systems.

  2. Hereafter, except if otherwise specified, if “hardware” is used alone, it refers to both electronic and MaSME items.

  3. The term “obsolescence” is similar, yet different, from DMSMS. The differences are small—DMSMS encompasses (1) items that are not obsolete but where there are shortages and (2) obsolete items that are out of production and there is demand. Both terms are used interchangeably throughout this document with a distinction being made where needed for clarity. For more information on the relationship between obsolescence and DMSMS, please see Appendix A, “Obsolescence and Its Relationship to DMSMS.”

  4. The word “system,” as used in this document, encompasses weapon systems and training, support, and test equipment.

  5. Generally, the use of the word “item” in this document is intended to be all-inclusive of parts, assemblies, software, and material.

  6. Regression testing seeks to ensure that software changes have not introduced new faults.

  7. 10 U.S. Code §2533b, “Requirement to buy strategic materials critical to national security from American sources; exceptions,” Cornell University Law School, Legal Information Institute website, www.law.cornell. edu/uscode/text/10/2533b, accessed July 31, 2015.

  8. Under Secretary of Defense for Acquisition, Technology and Logistics, memorandum, “Better Buying Power 2.0: Continuing the Pursuit of Greater Efficiency and Productivity in Defense Spending,” November 13, 2012.
    Under Secretary of Defense for Acquisition, Technology and Logistics, memorandum, “Implementation Directive for Better Buying Power 2.0—Achieving Greater Efficiency and Productivity in Defense Spending,” April 24,
    2013. Under Secretary of Defense for Acquisition, Technology and Logistics, “Better Buying Power 3.0,”
    September 19, 2014.

  9. DoD, “Operation of the Defense Acquisition System,” DoDI 5000.02, January 7, 2015, p. 113.

  10. Public Law 113-66, “National Defense Authorization Act for Fiscal Year 2014,” December 26, 2013.

  11. DoD, “DoD Supply Chain Materiel Management Policy,” DoDI 4140.01, December 14, 2011.

  12. DoD, “DoD Supply Chain Materiel Management Procedures: Materiel Sourcing,” DoDM 4140.01, Vol. 3, February 10, 2014, pp. 24–47.

  13. DoD, “The Defense Acquisition System,” DoDD 5000.01, May 2003 (certified current as of November 2007), p. 5.

  14. Ibid., p. 9.

  15. Ibid., p. 10.

  16. Bill Kobren, “10 Things Great Program Managers Know About Product Support,” Defense AT&L, November–December 2011.

  17. See https://dag.dau.mil/Pages/Default.aspx, accessed February 11, 2014.

  18. Supportability encompasses the extent to which design characteristics and logistics resources enable the attainment of availability goals.

  19. For example: In electronic components these issues are often called errata. In specialized manufacturing, there can be issues with a manufacturing process that must be resolved before the product is sufficiently reliable for a specific application.

  20. Defense Acquisition Guidebook, Section 4.3.18.21, “Standardization,” https://dag.dau.mil/Pages/Default.aspx, accessed February 11, 2014. For more information on parts management, see Defense Standardization Program Office, SD-19, Parts Management, September 2009, and MIL-STD-3018, “Department of Defense Standard Practice: Parts Management,” October 27, 2011.

  21. A bill of materials is a list of the OEM-assigned part numbers.

  22. A very useful method of describing many firmware or logic hardware design is through a VHSIC Hardware Description Language (VHDL). A VHDL (assuming a satisfactory level of specificity) is easily ported from one generation to the next generation of technology. Life-cycle costs may be reduced significantly through the proper use of VHDL design representation. When dealing with microcircuits, the most common HDL is VHDL.

  23. The ability to use an open systems architecture design approach for a legacy system is limited if not anticipated in the initial design.

  24. Software is the primary focus of integration for the development of open, scalable, and adaptable systems.

  25. Electronic Industries Alliance, “Standard for Preparing a COTS Assembly Management Plan,” EIA-933, 2011. This standard was originally issued by the Electronics Industries Alliance, which dissolved in February 2011 and no longer exists. The standard now belongs to SAE International, which is in the process of updating this
    document.

  26. In addition to the product support references cited in this section, see the following: 10 U.S.C. § 2337, “Life Cycle Management and Product Support”; DAU Life Cycle Logistics Community of Practice, https://acc.dau.mil/log; DAU Performance Based Logistics Community of Practice, https://acc.dau.mil/pbl; DAU Product Support Key References, https://acc.dau.mil/productsupport; and DoD, PBL Guidebook: A Guide to Developing Performance-Based Arrangements, 2014.

  27. Sample TDS and AS outlines are in “Document Streamlining—Program Strategies and Systems Engineering Plan” (April 2011 memorandum from the Principal Deputy Under Secretary of Defense).

  28. DoD, Product Support Manager Guidebook, 2011.

  29. DoD, Product Support Business Case Analysis Guidebook, 2011.

  30. See Life-Cycle Sustainment Plan Sample Outline, Version 1.0, August 10, 2010, promulgated by the Principal Deputy Under Secretary of Defense, Memorandum, “Document Streamlining—Life-Cycle Sustainment Plan (LCSP),” September 2011.

  31. DoD, Integrated Product Support (IPS) Element Guidebook, 2011, and DoD, Product Support Manager Guidebook, 2011.

  32. DoD, Logistics Assessment Guidebook, July 2011, p. 2.

  33. Ibid., p. 6.

  34. Marie L. Garcia and Olin H. Bry, Fundamentals of Technology Roadmapping, SAND97-0665 (Albuquerque, NM: Sandia National Laboratories, April 1997).

  35. Pete Pizzutillo, “Technology Refreshment—A Management/Acquisition Perspective,” July 2001.

  36. Custom electronic and COTS assemblies are mission-specific equipment designed by the prime contractor or a subcontractor specifically for the program.

  37. See https://www.logsa.army.mil/lec/syspars/.

  38. Unlike hardware, software often requires a license or agreement. Although maintaining software licenses and maintenance agreements are not normally a DMT responsibility, the DMT may want to take responsibility if software presents a critical obsolescence issue for the program. If a license management group is doing this work, the DMT should maintain an open line of communication with that group to remain cognizant of the status of licenses.

  39. If the DMT membership changes, the new members should receive training on DMSMS and on their roles and responsibilities within the DMT.

  40. The DoD DMSMS program has revised the course content for the current “DMSMS for Executives” course. The new version of this course, “DMSMS: What Program Management Needs to Do and Why” (CLL 200), covers two principal overarching learning objectives. The first makes the case to program management for why robust DMSMS management is important through a description of the ill effects of poor or reactive DMSMS management. The second highlights several strategic actions that program management should take to avoid or minimize the ill effects of poor or reactive DMSMS management. CLL 202 will be replaced next year.

  41. When determining the appropriate tool mix, the DMT should consider the tools already being used by the contractors.

  42. Section 7 discusses funding for implementing DMSMS resolutions.

  43. ROI is a metric for evaluating that compares the magnitude and timing of investment gains with the magnitude and timing of costs. A high ROI means that gains compare favorably to costs.

  44. The study reviewed all of the systems (ranging from missiles to aviation and in all phases) monitored by the U.S. Army Aviation and Missile Research Development and Engineering Center. On the basis of that review, the study calculated recognition rates for the two predictive tools used by the center.

  45. This does not imply that the government must have a BOM. DMSMS can be managed by the prime contractor. See Appendix C.

  46. To understand the data rights, see the original procurement contract and any follow-on contracts. The contracts usually contain specific detail on the data rights for items delivered as contained in DD250 forms. Using product data for government purposes, such as monitoring integrated BOM part numbers for end-of-life warnings, and using product data for competitive reprocurement are significantly different. DoD should attain technical data rights commensurate with the sustainment strategies of the systems used in its global defense missions so that it can ensure they remain affordable and sustainable. For more information about data rights, refer to “Myths of Data Rights” in the Army Guide for the Preparation of a Program Product Data Management Strategy, August 2010.

  47. This DID will be found at http://www.assistdocs.com/search/search_basic.cfm.

  48. SAE EIA-933, “Standard for Preparing a COTS Assembly Management Plan,” includes requirements for obsolescence management.

  49. In contrast, BOMs may be available for nondevelopmental items designed for the government.

  50. Obsolescence of complex assemblies is often caused by obsolescence of their critical items.

  51. For the Army, the Rand Corporation has developed a readiness indicator that could contribute to this factor. The Rand Readiness Indicator uses an Army deadline report that shows the number of times a part has appeared in that report and the total number of days that the part was in the report. Eric Peltz, et al., “Diagnosing the Army’s Equipment Readiness: The Equipment Downtime Analyzer,” Santa Monica, CA: Rand, Arroyo Center, 2002,
    46–48.

  52. An engineered material is designed to perform a specific function and is composed of multiple raw materials.

  53. The software used enterprise-wide affects or is affected by the program-specific obsolescence situation. Therefore, there are no proactive DMT implications beyond communication of second-order DMSMS issues to all stakeholders.

  54. The DMT interface with engineering is the most common way to understand the impact.

  55. The fact that a predictive tool indicates the existence of an alternative item does not guarantee that the item will work successfully in legacy systems. The conversion of original hard-copy drawings to digital drawings for legacy systems may make it difficult to know why a particular source’s item was chosen over another source’s item that appears to be similar or the same. The hard-copy drawings may have indicated a difference that was not captured digitally. Therefore, the DMT should check with the engineering authority before concluding that an impact assessment is not needed.

  56. Although more questions can be asked, the response rate is likely to be higher if the vendor survey is brief. Additional questions specific to different types of software are provided in Section 4.4.4.

  57. The answers to these questions and any follow-up questions should be provided to the appropriate technology road-mapping community in the program office.

  58. ANSI/VITA 53.0-2010, Commercial Technology Market Surveillance, is a reference to consider for additional questions to pose to a manufacturer (production start/end dates, end-of-support dates, failure, warranty, distributers, design changes, etc.).

  59. This is an Army Knowledge Online (AKO) site, which requires an AKO account to access.

  60. The DKSP is supported by the Defense Standardization Program Office (https://www. dsp.dla.mil) and is currently located within the DAU Acquisition Community Connection website (https://acc.dau.mil). More information on the DKSP may also be found in “Appendix H. DMSMS Knowledge Sharing Portal” of this document.

  61. These materials are listed on pages 2–4 of Appendix 2 of this report. The report is available by request through DLA’s Strategic and Critical Materials Office. A copy may also be found via the Homeland Security Digital Library at the following link: https://www.hsdl.org/?view&did=764766.

  62. This may change in the future if a greater number of substances become subject to environmental restrictions.

  63. A more proactive approach is to include a provision in contracts to collect data on any material of interest in the supply chain. This is a more costly approach and could be integrated with potential PESHE-related efforts. See Appendix C.

  64. Defense Acquisition Guidebook, “4.3.18.9. Environment, Safety, and Occupational Health,” May 15, 2013, 182–187.

  65. See http://www.nasa.gov/offices/rrac/home/.

  66. The e-mail address to become a subscriber is dmsms@dla.mil.

  67. DLA’s Obsolescence Data Repository is a centralized repository for resolution data and information.

  68. See http://www.gemes.com.

  69. To achieve economies of scale, organizations should consider having a higher-level organization obtain licenses and support. This is not a DMSMS issue.

  70. User groups are also a source of information on error and vulnerabilities.

  71. There is a question of whether this function should be done at the program level or enterprise level for COTS software, because the same software may be used by multiple programs. In addition, the need for software vendor surveys may not be as great compared to hardware because much more software update information is available on the web.

  72. Many articles are related to this topic; one good source is http://src.alionscience.com/pdf/POIS_APP.pdf.

  73. Software can degrade through configuration incompatibilities. While all the individual software elements may be fine, over time, the combination of these elements can be incompatible and lead to system failure.

  74. A single item may be a constituent component in multiple higher-level assemblies. This may change the cost calculation, because multiple higher-level assemblies may need to be redesigned. The most cost-effective option could be a combination of resolutions at the item level and at higher levels of assembly.

  75. That is why identification of the interdependencies was included in the Identify phase of robust DMSMS management.

  76. Over time, this metric can be referenced for projecting budget requirements for implementing solutions. See Section 7.

  77. A future version of SD-22 will contain information on average costs using this cost element approach. Previous versions of SD-22 provided average costs for different resolution types. These averages did not consider all of the applicable cost elements. Consequently, budgets based on these averages usually underfunded resolution implementation.

  78. The National Defense Stockpile should be a consideration for a DMSMS issue relating to raw materials. The raw materials may already be stockpiled, or they may be added to the stockpile in the future. For more information, see the Strategic and Critical Materials Stockpiling Act (50 U.S.C. §98 et seq.) and Strategic and Critical Materials 2011 Report on Stockpile Requirements, issued by the Under Secretary of Defense for Acquisition, Technology and Logistics, January 2011.

  79. Technology roadmaps can provide information that influences options for implementing different resolutions.

  80. All requirements (performance, safety, security, etc.) must be met for a resolution to be viable. A viable resolution must also address all second-order derivative effects.

  81. Defense Standardization Program Office, Diminishing Manufacturing Sources and Material Shortages: Cost Metrics, February 2015, p. 12.

  82. A life-of-need buy may appear to be the least costly and simplest option to implement. However, before this resolution may be used, a number of obstacles must be addressed. Per 10 U.S.C. § 2213, a waiver process must be used to procure goods that will result in more than 2 years of operating stock. Also, contractors cannot typically be obligated to procure stock beyond the life of their contract, so the government would need to procure and maintain a stock of the needed item. Also, because reliability and end of system life are estimates, accurately determining the quantity of an item to buy is nearly impossible. These obstacles may result in the determination that a life-of-need buy is not an option unless it would be used as an interim resolution until another alternative is implemented.

  83. A future version of this document will include average values for DMSMS cost elements to calculate ROI.

  84. Defense Standardization Program Office, Diminishing Manufacturing Sources and Material Shortages: Cost Metrics, February 2015.

  85. Resolution costs adjusted for inflation using a suggestive factor of 1.8 percent per “National Defense Budget Estimates for FY 2016—Office of the Under Secretary for Defense (Comptroller),” Table 5-2: Pay and Inflation Rate Assumptions—Outlays, p. 54.

  86. In addition to an inflation adjustment, this figure corrects a typographical error that was included in the February 2015 version of the SD-22.

  87. For a life-of-need buy, the DMT should consider whether it must purchase a minimum quantity. If that quantity is greater than the expected need, the program should try to identify other potential users as partners.

  88. This is more difficult when different sources of money are involved.

  89. Office of Management and Budget, Value Engineering, Circular A-131, January 2013 (available at http://www.whitehouse.gov/omb/circulars_a131).

  90. See SD-24, Value Engineering: A Guidebook of Best Practices and Tools, June 2011 (available at http://www.acq.osd.mil/se/docs/SD-24-VE-Guidebook.pdf), Chapter 8.

  91. When a PDN is anticipated but has not been released, it may be possible to adapt this approach to critical items that are expensive to redesign and test. Specific arrangements to do this would have to be negotiated in advance with the program office, the contracting officer, and industry.

  92. Programs that apply to only a single service are not included.

  93. DMSMS practitioners should also be aware of congressionally established programs that are not included in the DoD Presidential budget, for example, the Industrial Base Innovation Fund, the Rapid Innovation Fund, and the Defense Rapid Innovation Program. Such congressional programs are not discussed in this document.

  94. For more information, see https://www.dodmantech.com/.

  95. For more information, see http://dpatitle3.com/dpa_db/.

  96. Acting Deputy Assistant Secretary of Defense for Manufacturing and Industrial Base Policy, memorandum, “Call for FY15 Industrial Base Analysis and Sustainment Fund (IBASF) Projects,” January 24, 2013, p. 1.

  97. The fragility and criticality criteria are used by DoD’s Manufacturing and Industrial Base Policy Office to prioritize the capabilities and sectors of the industrial base on which to focus its efforts. The criticality portion of the assessment considers factors such as (1) the degree to which there is a commercial market for the capability; (2) the extent to which any specialized skills, equipment, or facilities are required or related to the capability; (3) the existence or necessity of defense-specific requirements; (4) the impact given the time it would take to restore the capability once lost; and (5) consideration of any alternatives. The fragility portion of the assessment looks at (1) the financial stability of the current source for the capability, (2) DoD business versus business from other customers for the current source for the capability, (3) other sources that exist within the market sector, and (4) the existence of a dependency on a foreign source for the capability.

  98. Enclosure 1—Project Proposal Submission Guidance.

  99. Ibid.

  100. For more information, see https://cto.acqcenter.com/.

  101. Ibid.

  102. For more information, contact dla.land.and.maritime.value.engineering@dla.mil.

  103. For more information, an organization should contact its own Air Force WCF manager.

  104. For more information, an organization should contact its Naval Supply Systems Command LECP manager.

  105. For more information, an organization should contact its manager for each of the programs.

  106. For more information, contact the NAVAIR AvCIP program manager.

  107. White Sands Missile Range in New Mexico has established a facility and processes for storage.

  108. DAWIA was initially enacted as Public Law 101-510 in November 1990. Most of the act is codified in 10 U.S.C. § 1701–1764.

  109. The OEM should be responsible for flowing down DMSMS-related contractual requirements to its suppliers and to require those suppliers to flow down DMSMS-related requirements through their supply chains in a similar way. This appendix assumes that is the case whenever the OEM is discussed as a potential provider of DMSMS management functions.

  110. An independent contractor could be part of a government DMSMS SME team, as discussed in Section 3.

  111. The discussions in this appendix are oriented predominately to counterfeit electronic items. The generic title of the appendix reflects the intent that the DMSMS implications of counterfeit items apply across the board.

  112. Of note is the existence of a small risk that a counterfeit item could be obtained through an authorized supplier that has accepted returns from customers of items that were counterfeit; those counterfeit items become mixed into the inventory of the authorized supplier and resold. However, the risk of receiving a counterfeit item is much smaller when purchasing from authorized suppliers, as opposed to unauthorized suppliers.

  113. For more information about generic requirements for managing counterfeit electronic items for any organization that procures such items, see SAE AS5553, “Fraudulent/Counterfeit Electronic Parts; Avoidance, Detection, Mitigation, and Disposition.”

  114. Government Accountability Office, DoD Supply Chain: Suspect Counterfeit Electronic Parts Can Be Found on Internet Purchasing Platforms, GAO-12-375, February 2012.

  115. As an example, items can sometimes be cleaned by dipping them in unfiltered river water. This type of cleaning procedure can allow moisture and contaminates to infiltrate items that are either not hermitically sealed or for which the hermitic seal has failed.

  116. Another risk associated with refurbished items pertains to the fact that the items have been previously used. If the item has a set life, it may be unknown how much of that life was consumed by its original application. This could result in an item needing to be replaced within a shorter period of time than anticipated.

  117. ERAI is a privately held global information services organization that monitors, investigates, and reports issues affecting the global supply chain of electronics. Since 1995, ERAI has been the industry’s primary reporting and investigation service, providing information and risk mitigation solutions to electronics professionals worldwide. See http://www.erai.com/Index.aspx.

  118. DoD, “DoD Counterfeit Prevention Policy,” DoDI 4140.67, April 26, 2013, p. 1.

  119. Ibid., p. 2.

  120. DoD, “Coordination of Remedies for Fraud and Corruption Related to Procurement Activities,” DoDI 7050.05, May 12, 2014, p. 20.

  121. DoD, “DoD Counterfeit Prevention Policy,” DoDI 4140.67, April 26, 2013, p. 13.

  122. Ibid., p. 12.

  123. See National Defense Authorization Act for 2012, Section 818, and DFARS Case 2012-D055.

  124. A legitimate unauthorized supplier is a broker or independent distributor that does not knowingly sell counterfeit items. Some independent distributors have robust processes and procedures in place to ensure quality.

  125. See Under Secretary of Defense for Acquisition, Technology and Logistics, memorandum, “Overarching DoD Counterfeit Prevention Guidance,” March 2012.

  126. Trusted foundries can support DMSMS resolutions outside the context of counterfeit items. They provide greater protection with respect to information and hardware assurance when replacing items used in critical or sensitive applications. Furthermore, they may have the equipment to manufacture obsolete items of a less sensitive nature and there is assurance that the work performed there will be well done. Finally, they ensure that there will not be any reasonable threats to the disruption of the supply chain. There are additional costs associated with these benefits. Procuring an item using trusted services from a given supplier is substantially more expensive than procuring the same item through that supplier’s normal commercial processes.

  127. Major supply chain disruptions such as floods, fires, and earthquakes may also lead to the selection of riskier item sources and thus increase the frequency of counterfeit issues.

  128. Government Accountability Office, DoD Supply Chain: Suspect Counterfeit Electronic Parts Can Be Found on Internet Purchasing Platforms, GAO-12-375, February 2012.

  129. DoD has made changes to the Defense Federal Acquisition Regulation Supplement to comply with Section 818 of the Fiscal Year 2012 National Defense Authorization Act, “Detection and Avoidance of Counterfeit Electronics” (Public Law 112-81, December 31, 2011). Even with those changes, unauthorized suppliers carry greater risk; consequently, conducting additional inspections and tests remains a best practice.

  130. DoD, “DoD Counterfeit Prevention Policy,” DoDI 4140.67, April 26, 2013, p. 9.

  131. See National Defense Authorization Act for 2012, Section 818, and DFARS Case 2012-D055.

  132. If not available in house, a consultant should be engaged to advise the team.

  133. The material in this appendix was taken from Pb-Free Electronics Risk Management (PERM) Consortium White Paper, December 2009 (http://www.aia-aerospace.org/assets/2009-12-22_PERM_White_Paper_FINAL.pdf).

+Notes
+Bookmarks