Selecting and Transitioning Pathways

PLAN AHEAD.  Start planning your transition early. Your acquisition strategy should anticipate the transition and describe the actions needed to ensure the transition proceeds smoothly. If the transition was not planned at the beginning of the program, the strategy may be revised to reflect the transition. Be sure to get the revised strategy approved by the decision authority. Keep in mind, multiple transition paths may be appropriate. When evaluating multiple transition paths, consider how your transition might occur in series, in parallel, or staggered. While the strategy may change during execution, you should have the overall acquisition capability objective in mind.

COLLABORATE.  Reach out to functional organizations / SMEs in advance, as you develop your transition plan and tailored acquisition strategy. Secure their involvement early, to avoid any last-minute objections, oversights, or surprises.

REUSE. To speed up development, review, and approvals, look for opportunities to reuse documents and approvals. Be sure the re-used documents focus on the appropriate scope of work, and update the re-used documents to account for the differences as necessary. Separate documents may be necessary for separate efforts, but using previously approved documents can help speed up the development, review, and approval process for any new documentation.

TAILOR IN. The acquisition strategy should tailor in the minimal set of processes, reviews, documents, adding only what is necessary for the program. Ensure each item is actually helpful for managing the program, and meet the pathway’s intent for that item. For example, UCA, MCA, MTA, and SW pathways all require an approved requirement, however, the formality and extensiveness of each pathway’s requirements documentation varies. Avoid including any “compliance-only” documents or reviews that exist only to check a box.

CREATE CLARITY. Explicitly identify unified decision authorities, tailored processes, and documents ahead of time if your program combines two or more pathways. Avoid situations where using multiple pathways creates multiple / conflicting chains of commands.

GET CREATIVE.  Recognize that you have a lot more acquisition options to consider than you have in the past. The different pathways are intended to provide flexibility and maximize effectiveness. Take an expansive view, consider all the potentialities and weight the benefits when deciding how to structure your program.  Consider how you might employ a portfolio approach with multiple programs using different pathways that  are sized to be manageable and meet the stated requirements as fast as possible. Do not feel constrained to follow what others have done or what you think might be easiest to get approved.

SCOPING. There needs to be a clear understanding of how the past acquisition efforts align with the planned acquisition efforts. Are they part of the same acquisition program or two distinct efforts (e.g. Increment 1 vs 2). If seeking to use multiple pathways in parallel, are they part of the same acquisition program or two related programs in a capability portfolio? This may drive acquisition categories (ACAT) and related thresholds across a number of statutory and regulatory requirements (documents, processes, and oversight).

REQUIREMENTS. If transitioning from one pathway (or legacy DODI 5000.02 models) to a new pathway, assess if the current requirements document(s) are current and scoped properly. As some of the new pathways have new requirements processes (e.g. MTA and SWP are exempt from JCIDS), it may warrant a new document to capture the current scope of work planned for the new pathway. If using two or more pathways in parallel, there needs to be a clear agreement on the structure of the requirements documents to ensure alignment across efforts. Timelines for requirements coordination and approval should be factored into transition strategies.

COST ESTIMATES. Based on the scope, the program will likely create or update cost estimates which may be a continuum of past acquisition efforts or a distinct scope. Per DODI 5000.73, programs over ACAT II thresholds require a CAPE independent cost estimate.

REPORTING AND OVERSIGHT. Based on how the acquisition efforts are scoped, each pathway has different documentation, reporting, and oversight requirements. Grouping past and future efforts together may exceed ACAT thresholds with increased oversight, whereas delineating future efforts may keep it at a lower level of oversight and reporting.

Icons from thenounproject.com. Credits:
Plan Ahead by Gregor Cresnar ; Collaborate by Kirby Wu TW; Reuse by Turkkub, TH; Tailor In by Tigers; Get Clarity by b farias; Get Creative by catyline_Icon, ID; Scoping by Eucalyp; Requirements by mynamepong, TH; Cost Estimates by Icon Island; Reporting and Oversight by Adrien Coquet, FR

Urgent Capability Acquisition that transitions into Middle Tier of Acquisition (Rapid Fielding)

A warfighting command identifies an operational shortfall and submits a requirement for initial capabilities to be delivered within 2 years. A program office uses the Urgent Capability Acquisition (UCA) pathway to develop and field a system to meet that specific need.

The new system is successful and a decision is made to quickly equip forces who are outside the scope of the validated urgent operational need. The program office transitions the UCA-developed system to the Middle Tier of Acquisition (MTA) Rapid Fielding pathway. This allows them to quickly ramp up production (within 6 months) of a larger quantity of systems based on the mature capability previously developed.

If the transition is planned as part of the UCA effort, then the contract vehicle used to meet the UCA requirement should be structured to anticipate additional quantities (contract options) exercised under the MTA Rapid Fielding path.

UCA programs have wide discretion to exclude formal milestone events and documents, so when planning for this transition, considerable deliberation should be given to the activities and documentation that may be required under the MTA Rapid Fielding pathway. Current MTA guidance requires submission of an approved requirements document (in accordance with Service/Component instructions), a formal cost estimate, and an approved Lifecycle Sustainment Plan. There may be other required documents as well. It is important that this be considered during UCA program execution and captured in the required UCA Disposition Analysis to ensure a smooth transition.

This blended pathway strategy provides greater flexibility in terms of quantities and can extend delivery for an additional five years. It also provides a mechanism for some minor additional development work, as needed.

Urgent Capability Acquisition followed by Major Capability Acquisition

A warfighting command identifies an operational shortfall and submits a requirement for initial capabilities to be delivered within 2 years. A program office begins development using the Urgent Capability Acquisition (UCA) pathway.

As an immediate follow-on activity, the program office can also use the Major Capability Acquisition (MCA) pathway to develop a more robust, enduring capability based on the original UCA product. Because of the common scope, requirements, and designs between the UCA and MCA efforts, the program should be able to tailor the early phases of the Major Capability Acquisition pathway to leverage activities performed under the UCA. This should allow the program office to transition the system to development sooner and expedite the path to full rate production.

The entry point into the MCA pathway will depend on the maturity and fitness for use of the UCA-developed system. NOTE: The program should tailor its testing strategy to exploit the lessons learned and successes of the operationally deployed system.

This blended pathway strategy provides Warfighters with capabilities rapidly, while simultaneously addressing the scope, requirements, and designs needed for an enduring solution. It also enables a significant degree of tailoring to the MCA pathway, taking advantage of the validated designs and documents from the UCA effort. Note that even a tailored MCA pathway will still require some documents that the UCA pathway does not require, so the program office should plan to address additional statutory requirements. Considerable deliberation should be given to milestone and documentation planning that may be required in the transition to the MCA path.

Middle Tier of Acquisition (Rapid Prototyping) and Major Capability Acquisition

A Component may initiate an effort using the Middle Tier of Acquisition (MTA) Rapid Prototyping pathway to rapidly develop a prototype, demonstrate its performance in an operational environment, and field a capability within 5 years. This might involve using an Other Transaction agreement or a FAR-based contract.

Simultaneously, the program office may also launch a parallel effort using the Major Capability Acquisition (MCA) pathway to produce a more robust, enduring version of the prototype capability built under the MTA pathway. Starting the MCA effort while the MTA is still underway ensures that the program office is fully ready to receive the prototype as soon as it is delivered (after Milestone B) and is not scrambling to catch up. This approach is a sound strategy when the level of uncertainty around the MTA prototype is low.

This combination of pathways provides the Warfighters with capabilities quickly (MTA), while shaping the scope, requirements, and designs for a longer-term solution (MCA). Commonality of scope, requirements, and designs between the rapid prototype and longer-term solution should allow the program to significantly tailor the early phases of the Major Capability Acquisition to transition to development sooner than using MCA alone.

Middle Tier of Acquisition (Rapid Prototyping) followed by Major Capability Acquisition

A Component may initiate an effort using the Middle Tier of Acquisition (MTA) Rapid Prototyping pathway to rapidly develop a prototype, demonstrate its performance in an operational environment, and field a capability within 5 years. This might involve using an Other Transaction agreement or a FAR-based contract.

As a follow-on activity, the program office may then initiate a new program using the Major Capability Acquisition (MCA) pathway to produce a more robust, enduring version of the prototype capability built under the MTA pathway. Starting the MCA effort after the MTA has delivered and demonstrated a prototype is a sound strategy when the level of uncertainty around the MTA prototype is high.

This combination of pathways provides the Warfighters with capabilities quickly (MTA), while shaping the scope, requirements, and designs for a longer-term solution (MCA). Depending on the commonality of scope, requirements, and designs between the rapid prototype and longer-term solution, the program should be able to significantly tailor the early phases of the Major Capability Acquisition to transition to development sooner than if they used MCA alone.

Middle Tier of Acquisition (Rapid Prototyping) followed by Software Acquisition

The program initially demonstrated and fielded a prototype capability in an operational environment to provide users an initial capability (either as a Minimum Viable Product or Initial Operational Capability) via the Middle Tier of Acquisition (MTA) Rapid Prototyping Pathway.

At some later point, beyond the MTA 5-year timeframe, the system requires additional iterative software development to scale the capability for Service-wide use. This may include adding additional features, strengthening cybersecurity, or improving interoperability with other systems. Having provided the operational user an initial capability that met or exceeded expectations, the sponsor wishes to continue enhancing and refining capabilities so that the capability can be deployed Service-wide. This program would then transition to the Software Acquisition Pathway for further development. An MTA program may also reach the end of its statutory period and decide to transition to the Software Acquisition Pathway given its software-centric requirements. An MTA program may also decide to transition earlier to utilize a pathway geared towards continuous and iterative software delivery.

This blended strategy enables rapid delivery of an initial prototype, followed by iterative updates and upgrades in response to emerging needs and advances in technology. For software-heavy systems with a predictable need for regular updates, this approach should be part of the original acquisition strategy.

Middle Tier of Acquisition (Rapid Fielding) followed by Major Capability Acquisition

A Component may initiate an effort using the Middle Tier of Acquisition (MTA) Rapid Fielding pathway to rapidly test, produce and field a capability within 5 years. This might involve using an Other Transaction agreement or a FAR-based contract.

As a follow-on activity, the program office may then initiate a new program using the Major Capability Acquisition (MCA) pathway and entering at Milestone C to produce a higher quantity of the production articles delivered under the MTA Rapid Fielding pathway.

This is a good transition for programs that are exploiting commercial or Non-Developmental Item (NDI) technology that can be quickly fielded with minimal testing. initiating the larger program with the MTA Rapid Fielding pathway enables faster delivery of an initial production set while work is underway to stand up the more enduring program of record.  The MCA program should be able to significantly tailor the entry at Milestone C utilizing the lessons learned and documentation created for the preceding MTA program. However, program office should not wait until the MTA Rapid Fielding activity is complete to begin planning for the development of any statutory and necessary regulatory documentation. Start early to ensure the transition is seamless.

Major Capability Acquisition and Software Acquisition

A major weapon system development can simultaneously use the Major Capability Acquisition (MCA) pathway and the Software Acquisition pathway on the same program, such as when designing a new aircraft or other system with a significant amount of software.

The acquisition strategy should document the details of this approach, showing how the program office will use a tailored version of the MCA Pathway to develop the system’s hardware and overall architecture and a tailored version of the Software Pathway to develop the software-based components. Worth noting: the software development must align to or integrate with the weapon system architecture, designs, and cyber standards. Open system architecture practices and principles apply here.

This program would likely use a modular contracting strategy, in accordance with FAR 39.103. The program may decide to contract with/through the weapon system prime contractor and/or new contractor(s) with the prime as the integrator, based on current contract agreements, openness of architecture, and planned contract strategies.

There are some open issues being worked out on how to effectively scope, baseline, and report on the program. The goal is to enable the speed and flexibility of the Software Acquisition Pathway, while conforming to the overarching structure of MCA, often with MDAP constraints. PMs and DAs can tailor the MCA program with some SWP strategies and processes for the software elements. Breaking up into two distinct programs, each following their own pathway offers benefits of navigating each pathway but adds integration risk.

Major Capability Acquisition followed by Software Acquisition

A major weapon system developed and produced capabilities via the Major Capability Acquisition (MCA) pathway and achieved Initial Operational Capability (IOC) or possibly even Full Operational Capability (FOC). At some point subsequent to IOC or FOC, the system requires major software upgrades to its sensors, avionics, and/or mission support systems. This software development can be done independently, yet in coordination with other planned weapon system improvements, using the Software Acquisition pathway.

In this scenario, the program would follow the Software Pathway to guide the software development efforts. The sponsor and end user will generate a Capability Needs Statement (CNS) to capture the scope of the software requirements and that will be approved via the Components requirements approval processes. The software development must align to or integrate with the weapon system architecture, designs, and cyber standards.

The program office should not wait until after IOC or FOC to begin working on the Software pathway. Instead, they should be able to anticipate the transition from MCA to the Software Acquisition pathway and begin work in a timely manner. The program may decide to contract with/through the weapon system prime contractor and/or new contractor(s) with the prime as the integrator, based on current contract agreements, openness of architecture, and planned contract strategies.

Major Capability Acquisition plus Middle Tier of Acquisition

A program using the Major Capability Acquisition (MCA) pathway to deliver a large, enduring capability may decide to add a Middle Tier of Acquisition (MTA) activity to their acquisition strategy. One reason to take this blended approach is to address changes that emerge in the threat environment, the technology environment, or both while the program is underway but before the design is finalized.

When faced with such changes, the program could initiate a course of rapid prototyping using the Middle Tier of Acquisition pathway. The purpose of these prototypes is to explore new alternatives and to develop new ideas for addressing emerging needs, threats, or capabilities. These prototypes developed under an MTA framework would then be injected back in to the primary MCA program.

Programs with a long development timeline may be able to anticipate and predict the need for rapid prototyping.  They might therefore include an MTA effort in the original acquisition plan. Alternatively, a program may encounter unexpected changes and may thus choose to add some rapid prototyping work using the MTA pathway despite it not being part of their original plan.

This program would likely use a modular contracting structure, in accordance with FAR 39.103. The program may decide to contract with/through the weapon system prime contractor to develop the prototypes, and/or establish vehicles with new contractor(s) and have the prime serve as the integrator.