Report of the Advisory Panel on Streamlining and Codifying Acquisition Regulations

Volume 3 of 3 | January 2019

Portfolio Management Framework Volume 3

Recommendation 39: Leverage a portfolio structure for requirements.

Problem

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. 

Software is a driving force for most weapon system advancements, yet the requirements structure 

inhibits adoption of leading software development practices (e.g., Agile and DevOps). While offering 

some flexibility for software, programs are expected to define requirements at the start and obtain 

approvals from senior leaders. Agile and related methodologies dispel the myth that software 

programs must define requirements upfront, when the program has the least knowledge about user 

needs and the target solution. Commercial organizations develop software iteratively, with dynamic 

scope and requirements based on user feedback, interim performance, and shifting priorities. 

Recent DoD reform efforts have focused on streamlining coordination timelines for JCIDS requirements 

documents. These reforms fail to address the bigger issue of breaking down large, stove-piped 

programs from the start. DoD needs many small and midsized capabilities to complement and connect 

the major systems. 

Background

JCIDS provides a critical and systematic process for incorporating CCMD inputs on capability gaps, 

operational requirements and funding priorities within constrained budgets. It has a portfolio structure 

based on functional capability areas, each with an FCB. JCS reviews ensure cross-Military Service 

issues are adequately addressed and limit duplicative requirements among the Military Services. JCS 

further validates requirements for critical areas to include communications, logistics, and cybersecurity. 

JCIDS also ensures nonmateriel aspects (e.g., doctrine, training, personnel) are aligned to maximize 

mission impact. 

As shown in Figure 2-10, DoD strategic guidance and CONOPSs for the operational mission area drive 

a capabilities-based assessment (CBA). CONOPs often reflect a culture that identifies traditional, 

Military Service-specific capabilities. When a CONOP outlines a to-be state, it often lacks sufficient 

evidence-based analysis. These issues can preordain a biased Military Service solution or a 

technologically infeasible solution. Initial analysis takes place during the CBA and leads to 

development of one or more ICDs. The ICD serves as a key entrance criterion to the acquisition process 

at the materiel development decision.
Report of the Advisory Panel on Streamlining and Codifying Acquisition Regulations

Volume 3 of 3 | January 2019

Portfolio Management Framework Volume 3

Figure 2-10. Interaction of JCIDS Documents and Early Acquisition Lifecycle

Programs conduct an analysis of alternatives (AoA) and related analyses during the Materiel Solution 

Analysis (MSA) Phase to prepare for Milestone A, which, as outlined in DoDI 5000.02, is an 

“investment decision to pursue specific product or design concepts.” Even at this early stage, programs 

will already have made some crucial decisions about the nature of the solution.1 Many of these 

decisions are very important for ensuring joint warfighting success, but some may be unnecessarily 

restrictive. A draft Capability Development Document (CDD), with several mandatory and programunique KPPs, is required for Milestone A approval.2 KPPs can help constrain program costs and limit 

requirements creep in later phases, yet they can also restrict the solution trade space. Milestone A 

authorizes the program to advance to the Technology Maturation and Risk Reduction (TMRR) Phase: 

the point at which the procuring agency can engage industry and contract for competitive prototyping 

to reduce risk in the selected materiel solution. Typically, the Request for Proposal (RFP) for technology 

maturation or risk reduction either suggests or clearly identifies the preferred solution with detailed 

specifications and technical requirements. Because programs perceive urgency to complete the CDD 

and enter the development phase, the insights gained from risk reduction prototypes often come too 

late to effectively shape the CDD. These early commitments to a solution may serve to overly constrain 

innovative options. 

The JROC or the Military Services’ requirements council must approve the final CDD before a program 

can release the RFP for system development. A 2015 GAO report indicated that completing a CDD 

takes, on average, 24 months—the longest timeframe of all the program documentation the GAO 

reviewed.3 Lengthy AoAs, conducted in parallel with the CDD development, contribute to these 

timelines. The CDD sets the scope of a major program for a decade or longer of development, testing, 

and production. During this timeframe, changes occur constantly across operations, threats, priorities,

budgets, technologies, and related systems; however, unless the Military Service wants to use the 

update process, the requirements remain fixed. Updates are reviewed and approved by a configuration 

steering board (CSB) chaired by the SAE, with membership consisting of executives from the relevant 

 

1 “Failures of Imagination: The Military’s Biggest Acquisition Challenge,” Jarrett Lane and Michelle Johnson, War on the Rocks, April 3, 

2018, accessed December 30, 2018, https://warontherocks.com/2018/04/failures-of-imagination-the-militarys-biggest-acquisitionchallenge/. 2 “Key Performance Parameters(KPPs),” DAU Acquipedia, accessed December 30, 2018, 

https://www.dau.mil/acquipedia/pages/articledetails.aspx#!346. 3 GAO, Acquisition Reform: DOD Should Streamline Its Decision-Making Process for Weapon Systems to Reduce Inefficiencies, GAO-15-192, 

February 2015, accessed December 30, 2018, https://www.gao.gov/assets/670/668629.pdf. 
Report of the Advisory Panel on Streamlining and Codifying Acquisition Regulations

Volume 3 of 3 | January 2019

Portfolio Management Framework Volume 3

Military Service, OSD, and JCS. Often, the lack of knowledge about requirements processes hinders and 

lengthens each step’s completion. 

Realizing that subsequent increments or programs may follow many years later, operational sponsors 

are incentivized to include most known requirements in the current CDD. This practice compounds 

risk by expanding the program scope, the number of critical technologies to mature, and variances in 

estimates. These compounded risks drive longer timelines and higher costs to achieve the target 

system’s initial operational capability (IOC). JCIDS does have fast track lanes for urgent operational 

needs (UONs) that affect an ongoing contingency operation and Joint emergent operational needs 

(JEONs) that affect an anticipated contingency operation. The CCMDs, the CJCS, and the VCJCS 

identify joint UONs and JEONs, while the Military Services may also identify UONs. The JCIDS 

manual outlines staffing timelines of 15 days for UONs and 31 days for JEONs, whereas the traditional 

deliberate planning timeline is 97 days. DoDI 5000.02 states these capabilities must be fielded in less 

than 2 years. 

During development, PMs may discover that the program has experienced major operational and 

threat changes, technology maturity or performance issues, budget changes, or other disruptive factors. 

ACAT I and IA programs must convene a CSB at least annually to review all requirements changes, 

significant technical configuration changes, and descoping options to reduce costs or respond to 

emerging threats. The CSB reviews and may recommend changes to the requirements authority. 

As highlighted in Figure 2-11, the JCIDS process of coordinating the major capability requirements 

documents is just one part of the broader DoD requirements processes. Strategic guidance (e.g., NSS

and NDS) provides DoD an overarching framework of objectives and priorities to shape operations, 

requirements, and investments. The missions, planning, and operations function includes operational 

plans and CONOPS that articulate operational capabilities and how an organization plans to 

accomplish its missions. In force elements, the Military Services and Combat Support Agencies 

organize, train, and equip materiel and nonmateriel solutions to provide forces to the CCMDs. 

Although DoD’s requirements processes interface with the acquisition and budgeting processes, tighter 

alignment is critically needed for more efficient and effective solution deliveries. DoD needs to examine 

the requirements processes holistically, beyond JCIDS boards and documentation reviews (along with 

aligning with budget, acquisition, and sustainment) for greater speed, agility, and innovation for 

mission impact. 
Report of the Advisory Panel on Streamlining and Codifying Acquisition Regulations

Volume 3 of 3 | January 2019

Portfolio Management Framework Volume 3

Figure 2-11. Requirements Process Interactions4

Discussion

Problems with DoD’s Requirements Processes 

The lengthy analysis and documentation procedures involved in JCIDS are designed to set 

requirements for billion-dollar platforms that will operate for several decades. Three to 5 years may 

elapse from the time an operational commander initially identifies a capability need to when a CDD is 

approved. The only other pathway currently available is an express lane for meeting urgent or emerging 

operational needs. Military Services’ implementation of Middle Tier Acquisition outlined in Section 804 

of the 2016 NDAA includes the Service Chief approving requirements, which appears excessive for a 

rapid prototyping project. DoD needs many intermediate pathways to provide just enough analysis and 

requirements documentation for midsized systems, with lifespans under a decade, that can be 

iteratively upgraded by subsequent releases. This situation calls for a set of processes that can exploit 

mature, leading technologies for military capabilities today by establishing an architecture that can 

integrate emerging technologies tomorrow. For example, a fifth-generation fighter requires different 

rigor in documentation than a small, command-and-control IT solution. F-35 software upgrades (and 

fixes to critical safety or operational issues) require a different approach than the initial CDD for the 

program. A program that relies heavily on COTS solution requires a different approach than a new 

development program with maturing technologies. Acquiring IT as a service is different from tailoring 

a COTS solution or developing new software development. 

The Requirements System Inhibits Contemporary Software Development Practices 

As shown in Figure 2-12, the IT Box model in the JCIDS manual was designed to enable flexibility in 

requirements for software development costing more than $15 million. The four sides of the IT Box 

 

4 Source: Joint Capabilities Integration and Development System (JCIDS) Manual of Operations. 

Strategic Guidance

Threats/Conditions

Missions/Planning/Operations Capability Requirements

Force Elements (Readiness) DOTmLPF-P Acquisition (Materiel)

(Non-Materiel)

Resources/Investment

DAS Process

(including rapid acquisition)

JCIDS Process - urgent/emergent/deliberate

Portfolio Management

(includes capability and capacity)

Organize, Train, and Equip

PPBE Process

Authorization/Appropriations

Global Force Management

Exercises/Wargaming

Readiness Reporting

NSS/NDS/NMS, QDR, DPG, GEF, Etc.

OPLANs/CONPLANs/Scenarios

Concepts/CONOPs

JOPES/APEX Process
Report of the Advisory Panel on Streamlining and Codifying Acquisition Regulations

Volume 3 of 3 | January 2019

Portfolio Management Framework Volume 3

represent a flag-level oversight requirements board, validated capabilities and initial measures of 

effectiveness, estimated software development and integration costs and estimated sustainment costs. 

JROC approves an information system variant of the ICD or CDD that defines these boundaries. 

Provided the program stays within the box, it does not require subsequent JROC approval or JCIDS 

documents. The program can iteratively define smaller requirements documents for approval by its 

flag-level requirements board. 

Although the IT Box originally required programs to generate a high-level IS-ICD for the JROC to 

approve, the JROC has since designated the IS-CDD as the guiding document. Per discussions with 

JCS/J8, IS-CDDs can average 40 pages and require 2.5 months of staffing by the JCS (in addition to 

Military Service-level staffing) to receive JROC approval. The JCS envisions that programs will 

generate IS-CDDs for each major incremental development, not for an entire major system.

Figure 2-12. IT Box Primer 

Source: Adapted from DAU graphic.

This approach is based on the fallacy that programs can effectively define the scope and requirements 

for a major software development effort upfront and bound the program by the estimated development 

and sustainment costs. By contrast, as noted previously, in leading software development practices—

such as Agile and DevOps—users, acquirers, developers, and other stakeholders iteratively define, 

prioritize, and change program scope and requirements. They begin with a hypothesis of the desired 

functionality and iteratively build, test, and demonstrate capabilities in close coordination with users. 

Users and engineers provide feedback on interim developments to shape future iterations. A growing 

number of DoD software programs are embracing this model, with some notable successes achieved by 
Report of the Advisory Panel on Streamlining and Codifying Acquisition Regulations

Volume 3 of 3 | January 2019

Portfolio Management Framework Volume 3

programs such as the Air Force’s Air Operations Center Pathfinder program, which delivers higherquality, lower-risk, secure software on a weekly release schedule to warfighters.5

Leading commercial corporations and start-ups apply Agile practices to manage software requirements 

via dynamic, prioritized backlogs of user stories. User stories capture the functionality the end users 

expect the software to deliver, often with a clear definition of done that serves as the acceptance criterion. 

A product owner collaborates with the stakeholders to prioritize the user stories on the product 

backlogs—the set of features for which software must be developed (see Figure 2-13). The highest 

priority features determine the scope of the next time-boxed release backlog. The development team 

commits to design, develop, integrate, test, and demonstrate working software for each sprint backlog 

to users and testers. Based on software performance and user feedback, product owners may make 

changes to the release and program backlogs to shape user stories and priorities. 

Figure 2-13. Example of Agile Backlogs

Conclusions

Develop a Capstone Set of Requirements for Each Portfolio

Instead of producing a large set of system-centric requirements documents, the Military Services and 

Defense Agencies should develop a set of capstone requirements and related materials for each 

execution portfolio. These items would guide the iterative delivery of an integrated suite of capabilities 

to maximize operational impact. 

The Military Service headquarters leadership, in collaboration with their respective Military Service 

Chiefs, operational commands, and JCS, should work to provide each execution portfolio with an 

integrated, capstone set of requirements and threat assessments (from the intelligence community). 

This approach would focus the JCS and Military Service Chiefs on the strategic operational 

 

5 “AOC Pathfinder is Saving USAF Big Money, and It Wants More of It,” Air Force Magazine, February 22, 2018, accessed December 30, 

2018, http://www.airforcemag.com/Features/Pages/2018/February%202018/AOC-Pathfinder-is-Saving-USAF-Big-Money-And-It-WantsMore-of-It.aspx. 
Report of the Advisory Panel on Streamlining and Codifying Acquisition Regulations

Volume 3 of 3 | January 2019

Portfolio Management Framework Volume 3

requirements, while enabling portfolios to manage speed and agility of capability requirements for 

specific systems/programs at lower levels. 

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. 

The capstone requirements provide the PAE direction for shaping prototypes and experiments, the 

trade space for program requirements, and resources to maximize mission impact. Ideally, capability 

requirement documents for programs would be iteratively developed and approved at lower levels 

(within the Military Services’ corporate structure) to focus on more detailed, specific needs. KPPs for 

MDAPs would still be validated by Military Service Chiefs and/or Service Headquarters Staff, and (if 

the program is of JCS interest), by the JROC. 

Empower PAEs with Flexibility to Shape and Shift Program Scope and Requirements

Replicating the success of the Air Force Rapid Capabilities Office, the PAE should be empowered to 

shape program requirements below a KPP. The PAE would be responsible for iteratively delivering 

capabilities based on their capstone portfolio requirements, technological maturity, cost/budget, 

schedule, system performance, risks, threats, and other such considerations. PAEs would allocate 

capability requirements to different elements of the portfolio based on analytics to maximize MOFEs 

and mission impact. As programs progress, operations, threats, and priorities change. PAEs would 

shift requirements across programs/projects to maximize the effect of each investment in close 

coordination with operational commanders, empowered operational representatives within the 

portfolio, and other key stakeholders. This approach would not require CSBs with senior DoD officials 

or extensive documentation coordination across DoD. Instead, it would potentially enable programs to 

provide capabilities to operational commands years sooner at lower costs than if they waited to mature 

all technologies and develop and test all functionality to meet 100 percent of the requirements defined a 

decade earlier. 
Report of the Advisory Panel on Streamlining and Codifying Acquisition Regulations

Volume 3 of 3 | January 2019

Portfolio Management Framework Volume 3

Assign Empowered Operational Representatives to Each Portfolio

Tighter integration of the operational and acquisition communities is critical to delivering mission 

impactful capabilities. Requirements organizations and operational commands currently invest time in 

authoring system requirements documents and collaborate with program offices with varying levels of 

success. A better approach would be to embed empowered operational representatives within each 

portfolio.

The empowered operational representatives would help shape the vision for key capability areas 

within the portfolio. They could provide insights on current operations and threats to help acquisition 

professionals and contractors shape capability developments. These representatives could provide 

rapid feedback on interim developments and connect programs with operational commanders and end 

users; assist in establishing portfolio priorities; and define, shape, and prioritize lower-level capability 

requirements. Requirements would be constrained by available portfolio budget and strategic 

direction. The operational representatives could also advise the PAE on shaping lower-level program 

requirements and senior leaders on strategic, long-term priorities, capability needs, and investments. 

These operational representatives would serve as key linchpins to shape a portfolio/mission area; 

therefore, portfolios should competitively staff these billets with experienced operators who have 

strengths in strategic planning, collaboration, and systems engineering. While the operational 

community faces resource constraints, embedding the right representatives to shape a portfolio’s 

acquisitions is a critical investment to ensure timely delivery of capabilities that maximize mission 

impact. 

As Congress has authorized new acquisition pathways and greater flexibilities, DoD has a prime 

opportunity to develop a tighter collaborative relationship between technologists and warfighters to 

iterate and identify innovative new means and ways to shape the environment. It is important not to 

constrict the opportunity space by biasing capability development through the lens of yesterday’s and 

today’s operations. In some cases, where an operational community is fixed on a known means and 

ways, there will be value to let the CONOPS drive requirements and solutions. In other cases, however, 

CONOPS should result from a deeper, objective understanding of technologies and their military 

applications, which would enable innovation achievement in the means and ways.

Maximize Use of Prototyping, Experimentation, and Minimum Viable Products 

Execution portfolios should maximize use of prototyping, experimentation, demonstrations, and 

minimum viable products (MVPs) independent of specific programs as well as in the early stages of a 

given program’s acquisition lifecycle. Congress and DoD, over the last few years, established a series of 

initiatives, funds, organizations, and pathways to increase use of these practices. DoD has begun 

implementing middle-tier acquisition via rapid acquisition and rapid fielding pathways per Section 804 

of the FY 2016 NDAA. These pathways can prototype innovative technologies, demonstrate them in an 

operational environment, and produce mature capabilities without having to go through JCIDS and 

DoDD 5000 acquisition processes. A prototype or MVP in the hands of operators and engineers would 

accelerate learning and design of solutions beyond a team conducting a CBA or AoA. Portfolios should 

use the multiple prototyping pathways to the maximum extent before establishing a formal program or 

follow-on increment to shape scope and requirements. Iterative prototypes and MVPs would improve 

opportunities to exploit leading technologies and the chances of delivering high-value capabilities to 
Report of the Advisory Panel on Streamlining and Codifying Acquisition Regulations

Volume 3 of 3 | January 2019

Portfolio Management Framework Volume 3

warfighters. Prototypes provide valuable inputs to mission engineering efforts by demonstrating how 

strengthening individual elements of a mission thread generate holistic impact. 

As highlighted in Figure 2-14, each portfolio should collaborate with a robust R&D network, including

the Defense Advanced Research Projects Agency, government laboratories, federally funded research 

and development centers, university affiliated research centers, and industry. Industry R&D can come 

from a variety of sources that include the Small Business Innovation Research program, Other 

Transaction Authority Consortia, and DoD-industry liaison programs such as DIU, SOFWERX, 

AFWERX, partnership intermediary agreements, technology investment agreements, grants, and 

cooperative agreements. Each portfolio’s network could collaborate and compete on research to exploit 

leading technologies for military advantage. This network should focus on ensuring a robust pipeline 

of innovative solutions to shape the scope of new programs and modernize existing systems. Each 

portfolio could establish an S&T/R&D director to coordinate research activities and investments with 

the portfolio’s network, Military Service leadership, and the USD(R&E). The directors would develop 

an S&T/R&D strategy and roadmap to align research with portfolio priority needs and opportunities. 

They could shape R&D investments as a diverse portfolio of many seedling efforts with stage funding 

from multiple DoD sources, technology agreements, and industry R&D funds. The S&T/R&D strategy 

should include technology push opportunities to apply leading technologies to military needs. The 

portfolio S&T/R&D director would be responsible for ensuring the most promising S&T/R&D projects 

cross the valley of death to be integrated into programs of record and fielded. This effort would include 

use of transition confidence levels to proactively connect, shape, plan, and fund the technology 

transitions.6

Figure 2-14. Interplay of Portfolio R&D, Requirements, and Analysis

 

6 Anthony Davis and Tom Ballenger, “Bridging the ‘Valley of Death’,” Defense AT&L Magazine, January–February 2017, 13-17, accessed 

December 30, 2018, https://www.dau.mil/library/defense-atl/DATLFiles/Jan-Feb2017/Davis_Ballenger2.pdf. 
Report of the Advisory Panel on Streamlining and Codifying Acquisition Regulations

Volume 3 of 3 | January 2019

Portfolio Management Framework Volume 3

Develop Portfolio Analysis Engines and Model-Based Enterprise Architectures

Portfolios could also develop analysis engines for continual integrated analysis of capabilities, 

requirements, threats, cost, schedule, performance, risks, and other factors. Instead of a linear, serial, 

program-centric model of CBAs and AoAs, a portfolio team (with staff augmentation from operational, 

acquisition, and sustainment commands) could expand that analysis across a suite of capabilities. 

As captured in Recommendation 36 of this report, each portfolio should have an enterprise architecture 

lead/group that uses model-based engineering. These enterprise models, with related portfolio 

analysis, would help shape portfolio priorities, capability scope, and requirements, which would help 

ensure capabilities are designed and developed to maximize interoperability within and across 

portfolios. Enterprise architects would work with their peers in other execution portfolios, Military 

Service headquarters, and ECPs.

Tight integration with cost analysts, systems engineers, users, and financial managers helps to assess 

the cost-performance trade space to scope affordable solutions. Prior to the 1996 DoDI 5000.2-R 

establishing AoAs, DoD conducted cost and operational effectiveness analyses (COEAs).

7 The COEAs 

emphasized quantitative cost analysis in program formulation. Although the current policies dictate 

program affordability targets and caps, and cost is part of AoAs, more comprehensive cost analysis 

could be used to shape program scope and requirements. Adopting more portfolio management 

practices as outlined in this report, along with revisiting some of the COEA practices, would help 

ensure programs are bounded by realistic affordability constraints, based on available portfolio 

budgets. 

Manage IT Requirements Using Dynamic Portfolio Backlogs

A software requirements model should be timely, iterative, dynamic, and user-centric. Execution 

portfolios should manage their capability requirements via a series of dynamic backlogs rather than 

large static documents. As mentioned earlier, a dynamic backlog is a prioritized list of required 

functions written from an operational user’s perspective but can also include technical requirements 

such as cybersecurity. The highest priority items on the backlog drive the next capability development 

or research (if greater technology maturity is needed). The requirements to shape a new capability 

development could be iteratively captured and approved via a tailored document, depending on the 

size, scope, cost, and risk. Managing requirements via backlogs is easier for software and IT given their 

dynamic and severable traits, but portfolios could also employ this approach beyond IT programs with 

smaller, iterative developments. 

The portfolio’s operational representative should be empowered to dynamically reprioritize, add or 

delete, and shape capability requirements based on operational needs, threats, technical performance, 

systems engineering, security, feedback from earlier releases, and other factors. These representatives 

would actively collaborate with operational commanders, end users, organizations providing threat 

assessments, and enterprise architects to curate the portfolio backlog. During portfolio reviews with 

Military Service leadership and operational commands, PAEs and their operational representatives 

 

7 Defense Acquisition Management Documentation and Reports, DOD 5000.2-M, February 1991, Part 8: Cost and Operational 

Effectiveness Analysis, accessed December 30, 2018, http://www.whs.mil/library/mildoc/DOD%205000.2-

M,%20February%201991%20Part%201.pdf. 
Report of the Advisory Panel on Streamlining and Codifying Acquisition Regulations

Volume 3 of 3 | January 2019

Portfolio Management Framework Volume 3

could present the requirements backlog to ensure alignment with Military Service and CCMD 

operational priorities and outcomes.

Each program or increment could also manage its requirements via dynamic backlogs. As interim 

developments are demonstrated or fielded, user feedback and system performance might generate new 

capability requirements or shift priorities for the backlog. The goal should be to ensure that each 

successive iteration addresses the users’ highest priority needs and strengthens force effectiveness.

Consider Breaking Large Programs Down into Smaller Efforts to Iteratively Deliver Capabilities

As DoD establishes execution portfolios or adopts related practices within the portfolios, PAEs should 

consider opportunities to decompose large programs currently in the planning and development 

phases into multiple smaller efforts. Each program would need to balance the pros and cons of 

restructuring to include timing and system-of-systems integration, which may require revisiting the 

CDD and acquisition strategy structure of programs in development. The VCJCS should update the 

JCIDS manual to enable a more iterative structure in CDDs in future programs by adopting the 

proposed CDD annex approach in the new JCIDS manual and effectively implementing it. 

This approach would enable PAEs to comply with the direction for rapid, iterative development in the 

NDS, DoDD 5000.01, and FAR Part 39. For example, instead of spending a decade to deliver all the 

functionality required in a CDD, the program could be structured to deliver functionality years sooner 

and iteratively deliver capabilities and new technologies via future releases, manage common 

subsystems (e.g., communications or sensors) via a single group within the portfolio, and integrate 

across platforms. If a technology or performance parameter proves more difficult to implement than 

planned, the functionality could be deferred to a subsequent release to allow mature capabilities to be 

fielded near-term.

Implementation

Legislative Branch

§ Include language in the next NDAA authorizing Military Services and Defense Agencies to 

pilot a portfolio requirements approach within one or more of their current PEOs or via the 

proposed execution portfolio structure. 

Executive Branch

§ Charter teams to develop a set of capstone requirements for each execution portfolio. These 

capstone requirements should include EERs, MOFEs, and mission threads/effect chains/mission 

engineering. They should provide an umbrella set of requirements to shape capability research, 

planning, and developments. 

§ Update the JCIDS manual, CJCS Instruction (CJCSI) 5123.01, and DoDI 5000.02 to empower 

PAEs to shape and defer lower-level requirements, below a KPP, for programs in development. 

§ Determine a reasonable level of delegated authority based on the size of the program, changes, 

risks, and other factors. The PAE should be empowered to make changes to approve 

requirements on ACAT II–IV programs and lower-level requirements for ACAT I programs, in 
Report of the Advisory Panel on Streamlining and Codifying Acquisition Regulations

Volume 3 of 3 | January 2019

Portfolio Management Framework Volume 3

collaboration with key stakeholders. Major changes (e.g., KPPs for ACAT I programs) will 

require senior approval via the CSBs and/or related processes as defined in current acquisition 

and requirements policies.

§ Assign one or more operational representatives to each execution portfolio. These 

representatives would report directly to the PAE and may have dual reporting to an operational 

command or headquarters staff. 

§ Update DoDI 5000.02 to prioritize prototyping, experimentation, and delivery of MVPs before 

the start of a program and in the early phases of the acquisition lifecycle. PAEs should be 

empowered to work with the R&D community to rapidly fund prototyping efforts to shape the 

scope and requirements of new programs, upgrades to existing programs, projects to improve 

interoperability between systems, or initiatives to improve the readiness of fielded systems. 

§ Charter a team to iterate on the IT Box model or develop a new approach for meeting software 

requirements. The team lead and team members must have experience with or a deep 

understanding of Agile development practices. The chosen approach should enable adoption of 

software development practices to include Agile and DevOps through use of dynamic, 

prioritized backlogs managed by product owners rather than large, static documents. Authorize 

iterative release approvals at the lowest level commensurate with program scope, cost, and risk. 

§ Outline multiple requirements pathways for DoD to follow. The pathways may include Middle 

Tier Acquisition rapid prototyping and rapid fielding; technology insertion and iterative 

upgrades to existing systems; software intensive systems; business systems; commercial 

solutions with little to no development; formalizing a government R&D program; IT services, 

cyber acquisition, and limited lifespan capabilities with little to no sustainment needs. 

Implications for Other Agencies

§ There are no cross-agency implications for this recommendation.