To print a PDF copy of this article, click here.
In late 2011, the principal deputy under secretary of Defense for acquisition technology and logistics furnished direction on the information content and format for the life cycle sustainment plan (LCSP). Although LCSPs have been in use for some time under a variety of names, this direction was intended to improve the document’s utility for all stakeholders in life cycle product support. Several major defense acquisition programs have now been through a variety of milestone decisions using the new LCSP outline. So this is a good time take stock of where we’ve been and where we’re going with the refinement of the LCSP as a stand-alone decision support document and useful tool for programs in product support planning.
The PDUSD(AT&L) chartered an Acquisition Document Streamlining Task Force in 2010, with the following goal:
“Eliminating non-value added content [from acquisition documents] while simultaneously increasing their value to the preparing organizations and senior decision makers…all of our required documents should be of utility to those directly responsible for planning, managing, and conducting our programs…If the various plans and reports we require adequately serve this purpose, then they should be sufficient for [milestone] reviews.”
It is worth clearing up any misconceptions about the term “streamlining.” The word may connote shorter or easier, but in the context of the task force’s goal, it has more to do with improving the relevance of documentary information. For acquisition documents, information must be relevant in servicing at least two critical needs: those of program manager and those of the milestone decision authority in making the right business decision. Although these needs evolve throughout the acquisition process, they must complement one another for the acquisition process to work. The impetus behind the Streamlining Task Force was to reverse a trend in which programs expended significant effort preparing acquisition documents solely for the purpose of a milestone decision review, only to have those documents fail to support the information needs of the decision maker. So if there are instances in which neither the program nor the decision maker derives value from the production of acquisition documents, that would seem to be an opportunity for improvement.
The word ‘streamlining’ may connote shorter or easier, but in the context of the Task Force’s goal it has more to do with improving the relevance of acquisition documents.
The task force’s approach was to build an initial set of outlines for four critical acquisition documents (the technology development strategy/acquisition strategy, the systems engineering plan, the program protection plan, and the life cycle sustainment plan), that provide specificity in the minimum information required to serve both the needs of program and the decision maker. Additionally, the outlines provide guidance on a format for presenting the information so that it is easily captured and easily consumed. Format is important, because one of the key dynamics with the non-value-added documents was the extensive use of narrative and descriptions, which increased page counts but not necessarily clarity. This is why you’ll see in the outlines extensive use of tables, graphs, and lists, with the intent of making the information more easily produced, maintained, and consumed, at the program and decision-maker levels.
The LCSP was among this first group of outlines the Streamlining Task Force produced. While the streamlining effort was focused on efficiency in the acquisition process, a theme emphasized in the USD(AT&L) Better Buying Power initiatives, the LCSP has assumed a much larger purpose in the past 2 years, as the emphasis on affordability has grown. In the current and projected budget environment, an acquisition program’s survival depends on its demonstrating, unambiguously, that its plan for sustainment satisfies the warfighter requirements and is affordable for the taxpayer. The LCSP therefore focuses on aligning three dynamics: 1) the needs of the warfighter, 2) what the Service(s) can afford in the context of the portfolio of capability, and 3) the program’s strategy and plan for satisfying (1) and (2).
The first area addressed in the outline is the warfighter’s requirements, with specific emphasis on sustainment metrics and elaboration on these metrics. This helps the program factor supportability into the system design and the design of the product support package. Product support strategy comes next. This is where the program delineates, at a high level, how it will allocate sustainment functions among organic and commercial providers. Strategy is then refined into plans through the definition of product support arrangements among commercial contracts.
The LCSP outline then addresses the individual product support elements, but only at a review and assessment summary level. What about the detailed implementation plans, you might ask? The task force deliberately constrained this section for a couple of reasons. First, implementation plans could be voluminous, introducing a level of detail that at this point in the document would detract from the goal of the aligning the three dynamics discussed above.
Second, detailed implementation plans entail a degree of Service specificity, and the task force did not believe that driving a standardized approach supported the two main objectives: providing a program tool first and milestone decision support second. This is not to say that implementation plans don’t have a place in the LCSP.
The annex section at the end of the outline was included to provide a place for greater detail needed by the specific program or Service.
The outline provides a place to document the statutory and regulatory requirements that impact sustainment planning, but the key here is the alignment among these requirements and the performance requirements of the program. Next in the LCSP is the integrated schedule, which is specifically focused on product support activities and deliverables, and must align with the program’s integrated master schedule.
Funding is covered next in the outline. This section is critical in addressing the affordability dimension of the three dynamics. Here is where the program details its sustainment specific funding requirements and assesses any gaps. It goes without saying that the current economic situation will likely turn any discussions of closing gaps with more funding into spirited dialogs, to say the least.
The LCSP outline then shifts to the program’s management approach, drilling down to the structure, roles and responsibilities of the program’s product support organization. This section describes the membership and objectives of the Sustainment IPT. Ideally, the LCSP is not just a product of the Sustainment IPT, but the central management tool used by this team and its leader, the product support manager. Key to the management approach is the program’s method for managing sustainment risks, in the context of the overall program risk management process. The final section of the outline addresses supportability analysis from three aspects: design interface, product support package determination, and sustaining engineering.
As mentioned earlier, the content of the LCSP outline was intended to furnish the minimum essential information. Accordingly, the outline provides a section at the end for planning factors and annexes which the PM may need to ensure the tactical utility of the document.
In many cases the task force provided notional information to stimulate the writer’s thinking as pen meets paper on a program’s initial LCSP. More to the point, the actual data in the document must be relevant and specific to the unique program, if it is to be useful to the program; the notional charts and data in the outline are thus representational, illustrative only.
The LCSP is intended to serve as the nexus of critical thinking among stakeholders, united in the goal of delivering affordable product support. Those stakeholders exist within the program: think in terms of systems engineering, contracting, and financial management. External stakeholders might include such product support providers as depots, DLA, the Service’s retail supply system, or industry partners.
Commercial providers may be internal or external depending on where the program is in the contracting process. When a program begins to formulate the RFP for commercial product support services, the LCSP becomes an even more critical tool. The type of contract is guided by the stability of the product design and the maturity of the product support package, which is documented in the LCSP. The performance work statement is guided by the product support strategy, and incentives must support the performance metrics. Again, all captured in the LCSP.
A robust LCSP is, in other words, the key tool in documenting and translating product support and sustainment requirements into effective contracts.
Beyond being a good reference that informs RFP development, there are sections from the LCSP that might be good background to include directly in the solicitation, such as the sustainment requirements, the product support strategy or portions of the schedule, although other sections, such as funding data, might not be appropriate. Some portions of the LCSP might be developed by the prime, such as the detailed plan for supportability analysis, or specific product support implementation plans, but always in the context of the overall Life Cycle Sustainment Plan, the development of which is unequivocally a governmental function.
The real measure of success for the deployment of the LCSP is its comprehensive use as a management tool within the program and among the program and its key stakeholders. To be useful in this context, the plan must align requirements, strategy, costs, and affordability. The “win-win” is that this same information is needed for sound acquisition decisions and ultimately the delivery of optimized sustainment outcomes.