The DoDI 5000.91 Product Support Strategy contains 12 elements in the Integrated Product Support (IPS) and 10 elements in the Lifecycle Sustainment Plan (LCSP). This documentation is required for all Major Defense Acquisition Programs and all Middle-Tier programs over $300M of RDT&E or $1.8B of procurement. There a slightly streamlined “tailored” LCSP for all programs that are not covered.
One thing that doesn’t make much sense is that for covered systems, the Product Support Strategy is required prior to Milestone A or equivalent, “pursuant to Section 2337 of Title 10, U.S.C.” That means DoD needs to lifecycle plan hundreds of pages of documents prior to a prototype, let alone full-scale development. The statute referred to by the instruction, however, only requires an LCSP prior to Milestone B or equivalent.
Waterfall Planning
True to form, this instruction requires a lot of “static” planning prior to any empirical information. One headscratcher here is that all programs need a fixed technical baseline and lifecycle cost estimate, regardless of size, in order to determine whether the program is considered “covered” or not. For one example, imagine doing the PSS for the Predator in the early days. Whatever the analysis led someone to conclude, the Predator turned out to be cheaper and more effective than the Air Force expected, as well as faster evolving. Change in a program then has impacts across the PSS, requiring updated analyses at every stage. For example, the Business Case Analysis:
The output of the PS BCA helps determine a best value solution for meeting the PSS. The PM uses recommendations from the PS BCA to support sustainment funding requirements in the programming, planning, budgeting, and execution process. The PM and PSM will revalidate the PS BCA based on changes (to systems, hardware or software, constraints, and operational environment) or every 5 years, whichever occurs first. The PS BCA provides O&S cost projections associated with the PSS, as reflected in the LCSP, which informs the PM’s program objective memorandum (POM) input, in time to allocate funds required for the PSPs and the PSIs to execute sustainment activities.
Nevermind that there’s a slight error there in the PPBE, they put “programming” before “planning.” But for the desired approach for fast moving programs, adaptive requirements, learning, etc., revalidating the BCA on every change would be prohibitively time consuming. Indeed, the bureaucratic challenges of keeping a PSS up-to-date with the program may cause officials to reject value-added changes to the system, leaving DoD with inferior equipment to what would otherwise have existed.
Software
This difficulty is perhaps best reflected in the Software pathway, which has three pages of dedicated instructions. Any update to the capability needs statement requires an update to the PSS. Hopefully the CNS will be a pretty high-level statement of outcomes. But there might be an issue there. Would a high-level CNS with iterative features on the product backlog support the PSS “solution”? For example, “The PSM will also ensure the product support solution plans for disposal costs at the software system’s retirement.”
This gets to a larger issue what they call the “Solution Analysis Phase”: “The PSM will conduct historical and operational data analysis to inform RAM costs, economic analysis, schedule, resource planning, initial acquisition strategy, capability implementation plan, and cybersecurity strategy.” Historical data isn’t exactly useful for innovative programs which seek to break the mold of the past, as economist Ronald Coase understood of accounting data in the 1930s:
Business decisions depend on estimates of the future. Accounting records cannot therefore be used as a guide for future action without considering how far the conditions which have existed in the past will continue in the future.
Before we get off software, I’d like to say I approve of the elements that get user involvement in feedback: “The PSM will collaborate with cross-functional teams via product owners to update the product support impacts as they become known and incorporate appropriate user feedback.” But again, it seems like too much emphasis is on planning, even “pre-planning” whatever that means: “the PSM will coordinate with the lead software developer to
identify and pre-plan for user participation in product support-related user assessments of the software technical manual, source codes, training materials, and supportability.”
Multiple Pathways
Another issue is that if a combination of pathways are used to prove out subsystems and move towards integration programs. This is inherently uncertain, so it’s not clear what the PSS will address. For the software pathway, it explicitly states that “When an acquisition program combines the software acquisition pathway with the MCA or the MTA pathway, the PSM will document the PSS for the software within the overarching LCSP.” But that again presumes that the total system-of-systems integration package is pre-determined ahead of program start! So what was the benefit of breaking it down into multiple pathways? It is certainly difficult to reconcile DoD’s functional guidance for lifecycle planning with optionality, portfolio management, and a “recombinatorial” approach to innovation.
Availability Metrics
There are two key availability metrics required, even for “tailored” LCSPs:
Am is a measure of the percentage of the total inventory of system operationally capable of performing an assigned mission at a given time… Ao is a measure of the degree to which a piece of equipment or weapon system can be expected to work properly when it is required.
I’ll just say that availability can’t really be a requirement ahead of program development. For hardware systems especially, availability depends on priority and funding in sustainment — perhaps many years in the future. Indeed, DoD should not want to high arbitrarily high availability rates. That will force complexity in the design process, which likely lowers true reliability, maintainability, etc. But strategically, if DoD wants a force structure that is scalable to meet high-intensity conflicts, then it should want a large number of unavailable systems. If DoD has 70-90% mission capability, then it won’t be able to afford that many systems, and therefore while it is ready to “fight tonight” it won’t be ready to “fight tomorrow night.”
Conclusion
As I predicted back in January 2020, the rise of the functionals would start to bog down the adaptive acquisition framework. I took some heat for saying that at the time, but since then there’s been the release of at least nine functional DoDIs with more to come — most of which double down on waterfall methods dominant from the industrial age.
Integrated Product Support elements for covered systems:
(1) Product support management; (2) Design interface; (3) Sustaining engineering; (4) Maintenance planning and management; (5) Supply support; (6) Support equipment; (7) Technical data; (8) Training and training support; (9) IT systems continuous support; (10) Facilities and infrastructure; (11) Packaging, handling, storage, and transportation; (12) Manpower and personnel.
Lifecycle Sustainment Plan elements for covered systems;:
(1) A comprehensive PSS; (2) Performance goals, including: (a) Sustainment key performance parameters (KPPs).
(b) Key system attributes; (c) Other appropriate metrics; (3) An approved life cycle cost estimate for the system;
(4) Results of the Product Support Business Case Analysis (PS BCA); (5) Affordability constraints and key cost factors that could affect the system’s O&S costs and proposed mitigation plans; (6) Sustainment risks, SCRM, and diminishing manufacturing sources and material shortage (DMSMS) risk management and proposed mitigation plans; (7) Engineering and design considerations, including DMSMS resilience, that support cost-effective sustainment for the system; (8) A technical data and intellectual property (IP) management plan for product support; (9) Major maintenance and overhaul requirements for the system’s life cycle; (10) A plan to leverage enterprise opportunities across programs and DoD Components.
Leave a Reply