Many operational commands overly define system requirements for the acquisition community, who in turn overly define system specifications for industry. This results in many stovepiped solutions that are not responsive to changes in operations, threats, and technologies. Most DoD systems don’t operate as standalone stovepipes, but are part of a systems-of-systems or portfolio of capabilities. Instead of overly defining system requirements, operational commands can enable greater speed and flexibility by capturing operational requirements at a broader portfolio level. 

The Section 809 Panel recommended DoD develop a series of capstone requirements for each acquisition portfolio.

DoD’s requirements system is under-resourced and lacks the speed, agility, and innovative approaches needed to effectively exploit leading technologies for military advantage. DoD’s requirements processes, including implementation of JCIDS policies, contribute to lengthy development timelines, limited flexibility, and stove-piped systems. Although this process is important for CCMDs to provide joint warfighting priorities, the lengthy series of system-centric analyses, requirements documents, and reviews can limit innovation and interoperability by prematurely defining and constraining requirements.

 

The capstone documents would include:
Enduring Enterprise Requirements (EERs): Current and future operational requirements of the Military Services and CCMDs based on the relevant CONOPs. These would not be written at the system level or allocated to individual systems; ideally, they would be constrained to a few strategic themes to provide strategic direction.

Measures of Force Effectiveness (MOFEs): Specific measures of how a force mix (a system of systems consisting of elements such as sensors, weapons, and communications systems) performs against the EERs. MOFEs represent the culmination of the Measures of Effect and Measures of Performance currently captured in ICDs and CDDs. This would impel the PAE to iteratively deliver capabilities to maximize performance against MOFEs, focusing investment on the highest mission impact.

Mission Threads, Kill/Effects Chains: Representative vignettes that illustrate specific operational scenarios. The vignettes would expand upon the Mission Engineering work within OSD, JCS, and the Services to identify a series of effects chains and would focus investments to strengthen any weak links in the chain, holistic integration, and strategic outcomes.

Portfolio ICDs

“The purpose of an Initial Capabilities Document (ICD) is to document joint military capability requirements and associated capability gaps in cases where the Sponsor deems the operational risk of unmitigated capability gaps to be unacceptable. The ICD provides traceability to the operational context, threats, and other relevant factors that determine the joint military capability requirements. The ICD quantifies capability gaps associated with the requirements, operational risks across the joint force, and proposes materiel and/or non-materiel approaches to closing or mitigating some or all of the identified capability gaps.”

– JCIDS Manual, Aug 2018

ICDs are traditionally scoped for an acquisition program to address. DoD organizations should consider authoring Portfolio ICDs to cover a broad mission or capability area and align with the scope of a portfolio rather than that of a single program. They would be broad documents central to ensuring that the operational, acquisition, and intelligence communities align around common outcomes, priorities, and expectations. In coordination with stakeholder operational commands, operational sponsors could manage capstone requirements via portfolio ICDs as living documents. This could include periodic updates to reflect their current concept of operations, strategic guidance, priorities, threats, capability gaps, and desired effects.

“One ICD may lead to the creation of multiple CDDs and/or DCRs, each of which contribute to satisfying the capability requirements and  eliminating or mitigating identified capability gaps in the ICD.” – JCIDS Manual, Aug 2018   

A Portfolio ICD approach is shown in column (3) per this figure from the JCIDS Manual.

A Portfolio ICD would serve as an umbrella requirements document to allow future programs and rapid acquisition efforts to leverage and iteratively define capability gaps within that mission or capability area via capability development documents or IT Box alternatives. As operational commands develop and coordinate ICDs, they should consider structuring them to cover a broader capability or mission area vice a specific materiel solution to enable speed in future efforts. As new threats, operational demands, or technology opportunities arise, organizations will no longer have to develop and staff an ICD, but rather proceed to the analysis and subsequent requirements documentation activities. 

Actions You Can Take

• If related development efforts are spread across multiple, outdated ICDs and/or CDDs, setup a series of discussions with operational commands, Service headquarters staff, and Joint Staff to propose transitioning to a Portfolio ICD. 
• If establishing a new capability area, explore the opportunity to structure high level requirements via a new Portfolio ICD
• Existing operational and acquisition portfolio leadership could author a new Portfolio ICD to cover existing program-centric ICDs as well as emerging capability needs. A portfolio ICD could serve as the foundation to align with an acquisition portfolio structure focused on delivering an integrated suite of capabilities vice independent programs. 
• Independent from, or aligned with, a Portfolio ICD, Operational commands and Service headquarters staff could develop a capstone set of portfolio requirements to serve as the overarching direction for an acquisition portfolio. These may include enduring enterprise requirements, measures of force effectiveness, and mission threads/kill chains/effects chains. 

References 

• JCIDS Manual, Aug 2018
• CJCSI 5123.01H, Aug 2018
• ICD Template, Mar 2017
• Section 809 Panel, Volume III, Part 1, Recommendations 39, 40, Jan 2019
• Section 809 Panel, Volume II Report, Requirements Management section pp. 52-60, Jun 2018