Report of the Advisory Panel on Streamlining and Codifying Acquisition Regulations

Volume 1 of 3 | January 2018

Defense Business Systems: Acquisition of IT Systems Volume 1

Recommendation 16: Combine authority for requirements, resources, and 

acquisition in a single, empowered entity to govern DBS portfolios separate 

from the existing acquisition chain of command.

Problem 

Responsibility for acquisition of DBSs is diffused across DoD, with no single entity accountable for 

results. Consequently, DBS programs take too long and cost too much to implement. Extended 

implementation timelines prolong use of legacy systems at a substantial cost and delay migration to 

more modern business capabilities to support the warfighting mission.1 Second-order effects include 

managing a large, burdensome portfolio of aging systems and interfaces—reducing DoD’s ability to 

become financially auditable and increasing cyber risk. Billions of dollars have been spent to modernize 

DoD’s business operations with only limited success to date.2

Background 

Nearly 20 years ago, the challenge of modernizing DoD’s business systems and processes was formally 

recognized, and since then Congress and department leadership have established a progressively more 

complex set of acquisition rules and oversight bodies. Today, the cumulative effect is that DBS 

programs fail to operate with the speed and agility needed to keep pace with commercial technology

advances. 

The initial catalyst for a major DoD business modernization effort was the 2001 Quadrennial Defense 

Review (QDR), which stated, “While America’s business[es] have streamlined and adopted new 

business models to react to fast-moving changes in markets and technologies, the Defense Department 

has lagged behind without an overarching strategy to improve its business practices.”3 A key theme 

from the 2001 QDR was to “Modernize DoD business processes and infrastructure,” which led to the 

creation of the Financial Management Modernization Program (FMMP). Recognizing that financial 

management overhauls alone would not resolve broader business challenges, in May 2003 DoD 

expanded FMMP and renamed it the Business Management Modernization Program (BMMP). One of 

the key concepts that came from BMMP was the DoD BEA. BEA was intended “to provide a blueprint 

for the end state of successful business transformation—the ‘to-be’ environment for business systems.”4

It was in these early stages of BMMP that Congress enacted the first legislation specific to defense 

business modernization. The FY 2005 NDAA created a new section in Title 10—Defense Business 

Systems: Architecture, Accountability and Modernization. 5 This new legislation (10 U.S.C. § 2222) did 

the following:

 

1 GAO testimony before the House Committee on Oversight and Government Reform, May 25, 2016. The testimony stated: “The federal 

government spent more than 75 percent of the total amount budgeted for information technology (IT) for fiscal year 2015 on operations 

and maintenance (O&M) investments. Such spending has increased over the past 7 fiscal years, which has resulted in a $7.3 billion 

decline from fiscal years 2010 to 2017 in development, modernization, and enhancement activities.” 2 GAO, DOD Business Systems Modernization: Additional Action Needed to Achieve Intended Outcomes, GAO-15-627, accessed 

November 9, 2017, https://www.gao.gov/products/GAO-15-627. 3 DoD, Quadrennial Defense Review Report, September 30, 2001, 49, accessed November 9, 2017, 

https://www.documentcloud.org/documents/2695397-2001-Quadrennial-Defense-Review.html. 4 “History,” Deputy Chief Management Officer, accessed August 11, 2017, http://dcmo.defense.gov/About/History. 5 FY 2005 NDAA, Pub. L. No. 108–375, 118 Stat. 1851, Section 332 (2004).
Report of the Advisory Panel on Streamlining and Codifying Acquisition Regulations

Volume 1 of 3 | January 2018

Defense Business Systems: Acquisition of IT Systems Volume 1

§ Defined the term defense business system modernization.

§ Set forth conditions for certification and approval of funds for any DBS modernization with a 

cost exceeding $1 million.

§ Established the Defense Business Systems Management Committee (DBSMC)—chaired by the 

Deputy Secretary of Defense—as the entity responsible for certification and approval of funds 

for DBS investments, among other duties.

§ Required (a) development of an enterprise architecture to cover all DBSs and the functions and 

activities supported by DBSs and (b) development of a transition plan for implementing the 

enterprise architecture for DBSs.

§ Required DoD to establish an investment review process consistent with 40 U.S.C. § 11312, 

Capital Planning and Investment Control.

§ Required DoD to submit specific DBS budget information and reports to Congress.

As BMMP progressed, the program’s leadership was realigned from the USD(Comptroller) to the 

USD(AT&L) in March 2005. In October of the same year, the Deputy Secretary of Defense established

the DoD Business Transformation Agency (BTA) with the mission to reengineer and integrate the core 

business activities of the department. DoD submitted the first enterprise transition plan to Congress in 

September 2005. The plan provided an overview of business transformation at the DoD and component 

levels, and established a set of priorities for new systems and capabilities to guide further development 

of the enterprise architecture.6

BMMP eventually dissolved primarily due to a focus on building an enterprise architecture rather than 

delivering business capabilities.

7 The broader business system modernization effort continued under 

numerous separate DBS programs. Many, but not all, of these programs were under the purview of the 

Defense Business Systems Acquisition Executive (DBSAE), a newly created acquisition executive 

position within BTA. According to the DoD DCMO: 

In May 2007, the Secretary of Defense used his discretionary authority to designate the Deputy Secretary 

of Defense as the CMO of the Department of Defense. Subsequently, Congress codified the department’s 

action in the FY 2008 NDAA, formally acknowledging the deputy secretary of defense as DoD CMO, 

establishing a new Principal Staff Assistant position, the Deputy Chief Management Officer (DCMO), to 

assist the Deputy Secretary, and naming the Under Secretaries of the Military Departments as CMOs of 

their respective organizations.8

 

6 Defense Business Board, Report to the Secretary of Defense, Business Management Modernization Program Task Group, accessed 

November 9, 2017, http://dbb.defense.gov/Portals/35/Documents/Reports/2005/FY05-

2_Business_Management_Modernization_Program_2005-5.pdf. 7 Jacques S. Gansler and William Lucyshyn, Defense Business Transformation, 4, accessed November 9, 2017, 

http://www.cpppe.umd.edu/publications/defense-business-transformation. 8 “History,” Deputy Chief Management Officer, accessed August 11, 2017, http://dcmo.defense.gov/About/History.
Report of the Advisory Panel on Streamlining and Codifying Acquisition Regulations

Volume 1 of 3 | January 2018

Defense Business Systems: Acquisition of IT Systems Volume 1

In March 2009, BTA released BEA version 6.0 and DoD decided that updates to BEA would only be 

released on an annual basis (as opposed to semiannual). At the same time, BTA released its required 

Congressional Report on Defense Business Operationsand the department continued to invest in DBS 

modernization but demonstrated limited progress in modernizing DBS and business capabilities.9

Congress continued to monitor the department’s progress with DBS in particular, and with 

IT acquisition in general. Section 804 of the FY 2010 NDAA required the Secretary of Defense to 

develop and implement a new acquisition process for information technology systems...based on the 

recommendations in chapter 6 of the March 2009 report of the Defense Science Board Task Force on 

Department of Defense Policies and Procedures for the Acquisition of Information Technology...and 

Report to Congress...on the new acquisition process developed.

10

The department submitted the required report to Congress in November 2010, titled A New Approach 

for Delivering Information Technology Capabilities in the Department of Defense. Although the 2010 DoD 

report was consistent with the IT acquisition reforms from the Defense Science Board report, many of 

these concepts were never fully implemented (see details in Findings below).

Congress continued to update 10 U.S.C. § 2222 through NDAAs. For example, the FY 2010 NDAA 

requires DoD to ensure appropriate business process reengineering (BPR) occurs for each DBS 

investment, and the BPR must be certified as a condition of funds certification and approval.11

In August 2010 the Secretary of Defense announced elimination of BTA and the transfer of its functions 

to the DCMO and USD(AT&L), which occurred in October 2011.12 Since 2010, the department has 

continued its multibillion-dollar annual investment in DBSs, and after years of difficulties, some of the 

larger DBS programs are now fully deployed and operational. These programs include Defense 

Logistics Agency’s Enterprise Business System (EBS) and Defense Agencies Initiative (DAI), Navy ERP, 

and Army’s LMP and General Fund Enterprise Business System (GFEBS). Despite this progress, 

criticism from Congress and the GAO continue, making it clear that more needs to be done to realize 

the benefits of the department’s substantial investment in business transformation and DBSs.13

In February 2017, DoD published DoDI 5000.75, which established the business capability acquisition 

cycle (BCAC) for DBSs with the intent to streamline decision-making, allow for flexibility in the upfront 

requirements process, and use an information-centric instead of a document-centric approach for 

evaluating programs.14 DoDI 5000.75 superseded DoDI 5000.02 for DBSs. Although this new regulation 

for DBSs moves the process in the right direction, it is not as far-reaching as the recommendations from 

the 2010 Report to Congress, A New Approach for Delivering Information Technology Capabilities in the 

 

9 Jacques S. Gansler and William Lucyshyn, Defense Business Transformation, 33, accessed November 9, 2017, 

http://www.cpppe.umd.edu/publications/defense-business-transformation. Between 2004 and 2009 a total of 581 new DBSs were 

registered in the DoD Information Technology (IT) Portfolio Repository database. GAO, DOD Business Systems Modernization: Recent 

Slowdown in Institutionalizing Key Management Controls Needs to Be Addressed, GAO-09-586, accessed November 9, 2017, 

http://www.gao.gov/products/GAO-09-586. 10 FY 2010 NDAA, Pub. L. No. 111–84, 123 Stat. 2402, Section 804 (b) (2009). 11 FY 2010 NDAA, Pub. L. No. 111–84, 123 Stat. 2470, Section 1072 (a) (2009). 12 “History,” Deputy Chief Management Officer, accessed August 11, 2017, http://dcmo.defense.gov/About/History. 13 GAO, DoD Business Systems Modernization, GAO-15-627, accessed June 15, 2017, http://www.gao.gov/assets/680/671452.pdf 14 Business Systems Requirements and Acquisition, DoDI 5000.75 (2017).
Report of the Advisory Panel on Streamlining and Codifying Acquisition Regulations

Volume 1 of 3 | January 2018

Defense Business Systems: Acquisition of IT Systems Volume 1

Department of Defense.

15 The Section 809 Panel intends to revive and enhance some of the 2010 report’s 

more ambitious ideas that were never fully implemented.

Findings

In its research and analysis, the Section 809 Panel found the following, discussed in detail below:

§ Fragmented and overlapping oversight processes create a burdensome parallel acquisition 

system that hinders flexibility for the programs needing it most.

§ The defense acquisition system’s linear lifecycle inhibits use of modern commercial IT 

acquisition and implementation practices.16

§ Previous recommendations to substantially change the DoD IT acquisition process, including 

acquisition of DBSs, were not implemented.

Oversight Processes

Fragmented and overlapping oversight processes create a burdensome, parallel acquisition system that 

hinders flexibility for programs needing it most. DBS programs are implementing fast-changing 

technology solutions and changing business processes (i.e., the way people do their jobs) as a result. To 

be successful, such projects require maximum flexibility to adjust as new information or new 

technology solutions become available. The current system, however, saddles DBS programs with 

additional oversight beyond that of a traditional DoD acquisition program (see Figure 3-2 below).

 

15 DoD, A New Approach for Delivering Information Technology Capabilities in the Department of Defense: Report to Congress Pursuant to 

Section 804 of the National Defense Authorization Act for Fiscal Year 2010, accessed November 9, 2017, 

https://www.dau.mil/policy/PolicyDocuments/the849OSD13744-10-804ReportToCongress.pdf. 16 “What is DevOps?” Amazon Web Services, accessed June 6, 2017, https://aws.amazon.com/devops/what-is-devops.
Report of the Advisory Panel on Streamlining and Codifying Acquisition Regulations

Volume 1 of 3 | January 2018

Defense Business Systems: Acquisition of IT Systems Volume 1

Figure 3-2. Comparison of Compliance and Oversight Effort

In 2012, the DoD Director of Acquisition Resources and Analysis studied the average number of 

touchpoints (e.g., document reviews, preparation meetings, formal briefings) during the typical lifecycle 

of an MDAP. The average number of touchpoints between the materiel development decision (MDD) 

and Milestone C (initial production) was 893.17 This analysis was for non-IT programs. Referring back 

to Figure 3-2, it is evident the additional oversight prescribed in the Clinger–Cohen Act (CCA) and 

10 U.S.C. § 2222 add more touchpoints. Additional compliance and oversight requirements to which 

DBS programs are subject as reported by GAO in May 2014, beyond the standard defense acquisition 

system, include the following:

§ CCA compliance to the CIO based on a checklist of 11 major items

§ BEA compliance18

§ BPR certification

§ Funding certification (in addition to normal planning, programming, budgeting, and execution 

[PPBE] activities)

§ Authorization to Operate (Cyber Security/Risk Management Framework)

 

17 Nancy Spruill, Defense Acquisition Executive Summary (DAES) briefing, April 4, 2012.

18 Some DBS practitioners interviewed by the Section 809 Panel posit that BEA has become a rubber stamp that consumes substantial 

time and resources but does not have a noticeable effect on the outcome of the program. In extreme cases, the myriad BEA products 

produced do not represent the actual system being implemented. GAO, DoD Business Systems Modernization: Further Actions Needed to 

Address Challenges and Improve Accountability, GAO-13-557, accessed November 9, 2017, http://www.gao.gov/assets/660/654733.pdf. 

The report states: “even though DoD has spent more than 10 years and at least $379 million on its business enterprise architecture, its 

ability to use the architecture to guide and constrain investments has been limited.”
Report of the Advisory Panel on Streamlining and Codifying Acquisition Regulations

Volume 1 of 3 | January 2018

Defense Business Systems: Acquisition of IT Systems Volume 1

These requirements create additional touchpoints that impede speed and agility in adopting 

commercial technology and business capabilities.

The results these activities produce are not always commensurate with the effort they require. The 

current system places little value on time, yet in the technology world, as in warfighting and business, 

time is a key factor that can affect outcomes. Satisfying the compliance-heavy, process-oriented 

requirements described above can add years to program schedules and comes at a substantial cost. This 

financial burden includes both the direct cost of labor to conduct the activities and opportunity cost of a 

solution that may be obsolete by the time it is deployed. When acquiring technology, DoD must take

reasonable risks, move quickly, and stop performing double and triple checks before it takes action.

To obtain results faster, DoD needs to empower decision-makers and simplify acquisition processes, 

not create committees, or worse yet, layers upon layers of committees.19 A recent study commissioned 

by the Deputy Assistant Secretary of Defense, Command, Control, and Communication (C3), Cyber, 

and Business Systems (DASD[C3CB]) acknowledged that the existence of a separate acquisition 

organization poses one of the major systemic challenges in DoD business transformation:

Business System modernizations tend to be more successful when led by a business leader and supported 

by IT. For instance, a human resource management system led by the head of HR and supported by the 

CIO organization. The business unit best understands the processes and requirements that the technology 

must support.20

Industry typically has a business (user) organization and an IT organization (CIO) and must decide 

which one will lead a project, whereas DoD has three different entities: a business organization, an 

IT organization, and an acquisition organization. Involving more entities is inefficient and precludes 

the common commercial industry practice of business-led projects.21 In the current DBS acquisition 

system, industry standard practice for project leadership and organization is not even an option.

This constraint is another symptom of applying concepts originally intended for weapon system 

programs to IT and business capabilities. One of the objectives of the Goldwater–Nichols Act was to 

separate the military-oriented requirements generation process from the acquisition process and put 

acquisition under separate, civilian leadership.22 There are arguments for and against this separation, 

but in the case of IT and business systems, it has clearly diminished DoD’s ability to operate in a 

manner resembling commercial industry. As stated above, to increase the likelihood of success for 

business systems projects, the business owner must lead the project, not a separate acquisition 

organization.

 

19 Navy PEO EIS, Enterprise IT Acquisition Efficiency Study. The study states: “Industry favors a decentralized core competence as opposed 

to centralized governance and oversight.” 20 DASD(C3CB) Study of Commercial Practices, Focus Area 5: Cost, Schedule and Performance, Acquisition Baselines, Variance Analysis, 

and IT Governance, September 23, 2016, 12.

21 Ibid, 15. The study states: “BPR and requirements development are more successful at the commercial organizations where the 

individuals that own the process are directly involved in the re-engineering and requirements development, since they should understand 

the process better than the IT organization.” 22 Goldwater–Nichols Department of Defense Reorganization Act of 1986, Pub. L. No. 99-433 (1986). Civilian Management of the Defense 

Acquisition System, 10 U.S.C., Subtitle A, Part IV, Chapter 149, § 2546.
Report of the Advisory Panel on Streamlining and Codifying Acquisition Regulations

Volume 1 of 3 | January 2018

Defense Business Systems: Acquisition of IT Systems Volume 1

In developing this concept, business leaders need to be responsible not only for individual projects but 

also for the entire portfolio of projects supporting their business areas (e.g., finance, logistics, HR). 

Empowered business owners or portfolio leaders would then be able to make the important trade-off 

decisions required when modernizing business practices. Use of portfolio leaders closely resembles

recommendations in previous studies on IT acquisition, and in current and proposed legislation.23 To 

be efficient and fully effective, DoD needs to formalize this approach with authority outside of the 

current acquisition chain of command.24 The 2010 DoD Report to Congress stated:

A major change in the new process will be moving from large multi-year programs to portfolios of shortduration projects. This requires a new approach to project oversight. This approach will place more 

accountability on timely coordination, quicker decision-making, and increased stakeholder involvement 

through more frequent performance-based in-process reviews. Oversight will be conducted by integrated 

and empowered governance bodies that have ownership of a capability roadmap.25

In the current system, portfolio governance is an interim step in a complex funds-certification process 

instead of being an empowered function to make critical trade-off decisions.

Modern Commercial IT Acquisition and Implementation

The defense acquisition system’s linear lifecycle inhibits use of modern commercial IT acquisition and 

implementation practices. The lifecycle models in the DoD 5000 Series are generally linear because they 

are based on the waterfall approach to systems development.26 Although appropriate in some 

situations, the waterfall approach has numerous limitations, especially when it comes to acquiring IT at 

the speed of commercial innovation.27 The Defense Acquisition Guidebook states that for large and 

complex projects using the waterfall approach, a single incomplete task can grind an entire project to a 

halt and often the “underlying technology is obsolete before delivery.”28 Current DoD policy includes 

some variations of the waterfall approach, such as spirals and increments; however, DoD’s acquisition 

system typically treats increments as separate programs that take years, not weeks or months, as one 

 

23 Senate Armed Services Committee, Report No. 115-125, FY 18 NDAA Mark, Section 884, Review and Realignment of Defense Business 

Systems to Emphasize Agile Methods.

24 Recent changes to Defense Business Systems: Business Process Reengineering; Enterprise Architecture; Management, 10 U.S.C. § 2222, 

that increased the threshold for covered DBS from $1 million to $50 million help reduce some of the bureaucracy associated with DBS 

acquisitions, but also make some investments invisible to a certain extent. An empowered portfolio leader would have visibility (and 

trade off authority) for all of the DBS investments in their portfolio. 25 DoD, A New Approach for Delivering Information Technology Capabilities in the Department of Defense: Report to Congress Pursuant to 

Section 804 of the National Defense Authorization Act for Fiscal Year 2010, 6, accessed November 9, 2017, 

https://www.dau.mil/policy/PolicyDocuments/the849OSD13744-10-804ReportToCongress.pdf. 26 According to the Defense Acquisition Guidebook Chapter 6-3.4.1, the waterfall software development method is defined as follows: 

The waterfall method is a classical software development method for which tasks are arranged to fall sequentially. One phase is 

completed before the next phase is started. Several software builds are completed before deployment. In its purest form, all 

requirements are known before IT is developed and the finished product is not delivered until all tasks are completed. 27 House Armed Services Committee Panel on Defense Acquisition Reform, DAR Interim Report, 17, accessed November 9, 2017, 

http://www.govexec.com/pdfs/031110rb1.pdf. The report states: “As a result, the Department is unable to keep pace with the rate of IT 

innovation in the commercial market place, cannot fully capitalize on IT-based opportunities, and seldom delivers IT-based capabilities 

rapidly. By way of example, the private sector is able to deliver capabilities and incrementally improve on those initial deliveries on a 

12 to 18 month cycle; defense IT systems typically take 48-60 months to deliver. In an environment where technology is obsolete after 

18 months, defense IT systems are typically two to three generations out of date by the time they are delivered.” 28 Defense Acquisition University, Defense Acquisition Guidebook, Chapter 6, Section 3.4.1., accessed November 9, 2017, 

https://www.dau.mil/tools/dag.
Report of the Advisory Panel on Streamlining and Codifying Acquisition Regulations

Volume 1 of 3 | January 2018

Defense Business Systems: Acquisition of IT Systems Volume 1

would expect.29 The current DoD lifecycle models are out of step with modern commercial IT practices, 

which heavily rely on Agile principles that are markedly different from the waterfall approach. 

The concept of Agile development stems from the Agile Manifesto, published in 2001 by software 

developers who wanted a more efficient and responsive way to address user needs. The Agile

Manifesto includes many guiding principles. Some of the well-known principles are listed in Table 3-1 

below along with the Section 809 Panel’s assessment of their adoption status within DoD.

Table 3-1. DoD Status of Adopting Selected Agile Principles

Agile Manifesto DoD Status

“Focus on customer satisfaction through 

continuous software delivery.”30

DoD does not continuously deliver software to customers under most 

existing programs, but rather engages in deployments once an 

acquisition process is completed. During these procurements and 

subsequent deployments, customer satisfaction is arguably not the 

principal metric with which DoD aligns performance incentives for 

requirements staff, program staff, contracting staff, testing staff, or 

vendors.

“Deliver working products on a rapidturnaround timeframe of a few weeks or 

months.” 31

DoD’s acquisition apparatus does not usually abide by this principle. 

Most business systems require several years to progress from

conceptualization to delivery of usable functionality.

“Accept that requirements will change, even 

late in the development process.”32

DoDI 5000.75 includes flexibility that may, in some cases, allow for 

adoption of this principle in DoD IT acquisition programs: “Functional 

requirements will include enough detail to inform definition of 

potential business system solutions and evaluation criteria, but 

without including too much detail that would overly constrain 

solution selection.”33

“The metric by which success is primarily 

measured should be whether software is 

built and works well.”34

The primary metrics by which DoD, the Military Services, and 

Congress measure success tend to be growth in cost and schedule, as 

well as compliance with predetermined technical requirements. 

These technical requirements may in some cases be obsolete by the 

time the software is built.

“Acquisition professionals and system 

architects should pursue simplicity in 

programs, or ‘the art of maximizing the 

amount of work not done’.”35

The current approach to DBS programs, with its myriad compliance 

and oversight requirements and layers of committees, is arguably the 

opposite of simple. A great amount of work occurs, and much of it to 

satisfy a process metric or regulation, not to produce an outcome or 

capability.

One particular problem area in the current linear acquisition model for DBSs is the requirements 

process. Agile principles are based on the assumption that requirements will not be complete upfront 

 

29 Operation of the Defense Acquisition System, DoDI 5000.02 (2017). 30 Adapted from “Principles behind the Agile Manifesto,” AgileManifesto.org, accessed November 9, 2017, 

http://agilemanifesto.org/principles.html. 31 Ibid.

32 Ibid.

33 See Business Systems Requirements and Acquisition, DoDI 5000.75, section 4.2(c)(3)(a), (2017 update). 34 Adapted from “Principles behind the Agile Manifesto,” AgileManifesto.org, accessed November 9, 2017, 

http://agilemanifesto.org/principles.html. 35 Ibid.
Report of the Advisory Panel on Streamlining and Codifying Acquisition Regulations

Volume 1 of 3 | January 2018

Defense Business Systems: Acquisition of IT Systems Volume 1

and will change over the course of a project. The current DoD requirements process for DBSs is the 

opposite; it entails an exhaustive analysis of requirements, BPR, and even a return on investment (ROI) 

analysis prior to approval of requirements. These activities typically rely on not just requirements, but

also on the selection of a specific solution (usually a COTS product in the case of DBSs). Attempting to 

complete BPR and ROI analysis prior to selection of a solution is not just difficult; some argue it is 

impossible.36 Reengineering of DoD’s business processes has not happened to the extent envisioned 

and needed. Consequently, the department contends with many customized systems that are costly to 

sustain and limit the ability to take advantage of innovations and new capabilities developed by 

software vendors.

The DBS requirements document, until recently referred to as a problem statement, has several parts 

addressing a wide range of topics and can take years to complete and approve, even for small 

projects.37 The Army Materiel Command’s (AMC’s) price-and-credit tool project described in Figure 3-3

below illustrates this challenge.38

The price-and-credit tool illustration shows how DoD’s current DBS requirements process is not only 

out of step with, but explicitly inhibits, use of modern commercial IT implementation practices such as 

Agile. It is impractical for users to define requirements up front, lock them down, and subsequently 

hand them off to an acquisition organization that takes years to deploy the capability. This approach 

ignores the reality that IT solutions change at a dizzying pace. To have anything resembling modern 

business capabilities, DoD must fundamentally change its expectations about the requirements process 

and lifecycle for DBS acquisitions.39 The budget cycle exacerbates the challenges of the requirements 

process by further limiting flexibility to quickly adopt new technologies and solutions—a problem 

resulting from the expectation that requirements will be known years in advance of when they are 

needed.40

 

36 DASD(C3CB) Study of Commercial Practices, Focus Area 1: Business Process Re-engineering and Requirements, September 23, 2016, 

p. 4 “Only so much BPR can be done prior to tool selection and implementation.” 37 The Problem Statement terminology was changed with the issuance of DoDI 5000.75 in February 2017. It is now split between 

Capability Requirements (former Problem Statement Part 1) and Business Processes / BPR Changes (some of which was in Problem 

Statement Part 2, some of which is new with the 5000.75).

38 Project Manager Army Enterprise Systems Integration Program (PM AESIP) personnel, information for AMC price-and-credit tool case 

study provided to the Section 809 Panel staff, from July 31 to August 7, 2017. 39 DASD(C3CB) Study of Commercial Practices, Focus Area 1: Business Process Re-engineering and Requirements, September 23, 2016. 40 One DoD official told the Section 809 Panel staff, “There is also the linear and lengthy budget cycle that makes it hard to get funds for 

IT following the process. It would take over a year to get funds...to just get started on getting the system procured.”
Report of the Advisory Panel on Streamlining and Codifying Acquisition Regulations

Volume 1 of 3 | January 2018

Defense Business Systems: Acquisition of IT Systems Volume 1

Figure 3-3. Requirements Process Example

Price-and-credit is a capability to consolidate the five 

budget formulation tools used by AMC to determine 

pricing on the material record. Initial estimates showed

the project would take about 2 years and cost $9 million. 

At first, the customer/user organization was unaware it 

would need to complete a formal problem statement 

because this small project was not an acquisition 

program, and it had the required funding available. 

Under the DBS policy, the customer was in fact required 

to complete the multipart problem statement, including 

a business case analysis, and obtain approval all the way 

up to the DoD IRB. Instead of beginning the contracting 

process based on the requirements the customer had 

already documented, in April 2015, the customer began 

developing Part 1 of the problem statement, which took 

about 3 months. Part 1 was approved more than a year 

later in September 2016, and Part 2 was approved in 

conjunction with required funds certification another 

8 months later, in May 2017. Altogether, it took more 

than 2 years to formalize and approve a requirement for 

what by DoD standards is a very small project intended 

to enhance a business capability and resolve longstanding shortcomings in the current legacy systems. 

The nine review and approval layers depicted at right are 

only the formal steps. Many briefs that are more 

informal and prebriefs typically occur during this 

process. One interviewee with knowledge of the process 

told the Section 809 Panel there are actually 77 separate 

steps to get a problem statement approved.41

Nine Layers in the DBS requirements 

approval process for a $9M project

> 2 years to approve requirements

Another aspect of the current lifecycle model that suboptimizes defense business capabilities is the 

concept of system sustainment (formally referred to as capability support in DoDI 5000.75).42 The linear 

lifecycle model is based on a program executing predetermined phases and milestones, and eventually 

declaring a full deployment (FD) milestone, which signifies the capability is in sustainment. At 

sustainment, DoD cannot add new, related capabilities or enhancements to the baseline quickly. 

Instead, any changes must go through the time-consuming problem statement process as described 

 

41 Data collection interviews, conducted by Section 809 Panel Team 6: IT Acquisition, from March to July 2017. 42 Business Systems Requirements and Acquisition, DoDI 5000.75, 18 (2017).

Army Business Council 

(2 Star)

Office of Business 

Transformation

Army Business Council 

(3 Star)

Army DCMO

Precertification 

Authority

Domain

Governance Review

Customer/User 

Organization

DoD DCMO

DoD IRB
Report of the Advisory Panel on Streamlining and Codifying Acquisition Regulations

Volume 1 of 3 | January 2018

Defense Business Systems: Acquisition of IT Systems Volume 1

above and are essentially treated as a separate program (often referred to as an increment). Even in the 

best circumstances, these subsequent increments can take years to fully implement.

43 This model is 

starkly different than the one used by most commercial organizations. In common commercial 

approaches, IT projects do not have a defined point at which they transition to sustainment. Instead, 

commercial entities recognize that business capabilities and their supporting technology require 

ongoing enhancements and cannot wait for a lengthy requirements approval process to feed a waterfall 

development approach. Delayed implementation of capabilities, which are often outdated by the time 

they are deployed, is simply unacceptable to commercial companies, as it should be to DoD.

Serial test events in the current lifecycle process constitute yet another inhibitor to the speed and agility 

needed in modern DBS implementations. A 2010 House Armed Services Committee Panel on Defense 

Acquisition Reform report indicated,

Testing is integrated too late and serially in current IT systems acquisition practices, with testing in 

realistic operational environments deferred until the mandated operational test. The acquisition 

community has been reluctant to embrace virtualized testing or is overtly precluded from reusing or 

accessing operationally-relevant test data and environments.44

DoD struggles to use Agile concepts under the rigid rules of its current acquisition system, yet many 

commercial entities are moving beyond Agile to Development Operations (DevOps). DevOps breaks 

down the traditional barriers and hand-offs between IT development and operations with the goal of 

getting functionality into production more quickly and more frequently. When using DevOps, 

technical staff may work at each phase of the process; little distinction may exist between developers, 

testers, and sustainment staff who work on the same product over the course of its lifecycle.45 This 

model integrates capabilities more quickly and seamlessly.

The flexibility inherent in Agile and DevOps cannot be achieved with the existing DBS acquisition 

process. Advocates of the current DoD process argue that every requirement must be reviewed in the 

context of the DoD BEA to ensure there is no duplication of effort. Advocates also contend layers of 

governance committees are needed to ensure proper oversight and stewardship of taxpayer dollars. 

Although there is a need for enterprisewide oversight, the reality is that the current process cannot 

deliver the kind of agility and results desired. The system requires change to provide more flexibility 

and autonomy, along with requisite accountability.

Congress and DoD acquisition leadership have clearly expressed a desire to inject more flexibility and 

agility into IT acquisition.46 For this transition to happen, the current system must be radically changed 

 

43 The Logistics Modernization Program Increment 2 is considered a successful example of a subsequent increment of a DBS, but still took 

nearly 4 years from initiation through full deployment. 44 House Armed Services Committee Panel on Defense Acquisition Reform, DAR Interim Report, 17, accessed November 9, 2017, 

http://www.govexec.com/pdfs/031110rb1.pdf. 45 “What is DevOps?” Amazon Web Services, accessed June 6, 2017, https://aws.amazon.com/devops/what-is-devops. 46 James MacStravic, acting in the capacity of USD(AT&L), noted, “Right now, to make a Milestone B decision on a major acquisition 

program, I have to sign up to 20 waivers in order to not conform to a statutory requirement that may or may not be relevant to the actual 

problem I was facing. A best practice on a hardware system has migrated into a statutory requirement on every system. I need those 

relieved, and the more I can pull those down so we can make contextually appropriate decisions that relate to the technical and 

operational changes we’re actually facing, the more we’ll see acquisition agility.” “DoD’s acting acquisition chief looks to purge ‘the 
Report of the Advisory Panel on Streamlining and Codifying Acquisition Regulations

Volume 1 of 3 | January 2018

Defense Business Systems: Acquisition of IT Systems Volume 1

from a serial, process-oriented model to a dynamic, outcome-oriented one in which individuals are 

empowered to make decisions and obtain results without layers of committees expecting analysis of 

every possible scenario before rendering a decision.47 Agile methods change the frame of reference 

from measuring processes to measuring the outcomes, usually by observing the working software 

(e.g., does this transaction work the way the user expected? by how many days does it reduce cycle 

time?). Continuous feedback from business users is one of the hallmarks of Agile, and in conjunction 

with frequent releases, it allows for adjusting the project more quickly and ultimately solving the 

business problem better and faster.

A recurring theme in the Section 809 Panel’s interviews in particular, and in IT research in general, is 

that smaller projects are more likely to succeed. The Standish Group’s 2015 CHAOS Report, based on 

surveying more than 10,000 software projects, concluded that small projects using Agile had a 

58 percent success rate compared to 44 percent when the project used the waterfall process. Large 

projects experience an even more pronounced gap, with the success rate for Agile 18 percent and a 

mere 3 percent for waterfall. 48 A case study by the software development estimation company 

Quantitative Software Management (QSM) showed that although Agile was less efficient when first 

adopted, by the second year, software deliveries were 34 percent faster and used 27 percent less effort 

than waterfall methods.

49 The takeaway is clear: DBS projects should be kept small and use Agile 

methods as much as possible.

A comparison of DoD and commercial industry enterprise resource planning (ERP) systems supports 

the argument that projects should remain small. ERPs are major COTS business systems that run 

functions such as finance and human resources. A 2009 study by the DoD BTA, cited in a report by the 

Center for Public Policy and Private Enterprise, revealed that several Fortune 100 companies have more 

ERP systems than DoD, even though DoD is a much larger organization. For example, General Electric, 

with an annual revenue of approximately $150 billion, had 15 ERP systems, yet DoD had more than 

three times that budget/revenue and only nine ERP systems.50 The implication is that commercial 

industry determined that breaking up its business systems based on product line, geography, or other 

factors was the optimal strategy, and DoD has tried to implement massive systems with a much higher 

likelihood of failure.51 Numerous GAO reports from 2012 to 2017 document these results.

52

 

stupid’ from IT procurement,” by Jared Serbu, Federal News Radio, June 6, 2017, https://federalnewsradio.com/dod-reporters-notebookjared-serbu/2017/06/dods-acting-acquisition-chief-looks-to-purge-the-stupid-from-it-procurement/. 47 House Armed Services Committee hearing on the initial findings of the Section 809 Panel, May 17, 2017, Representative Duncan 

Hunter, “Because people screw up...we’re going to take...the personal responsibility element out of acquisition and create so many steps 

and milestones that no one has to take responsibility for anything...Talk about putting just somebody in charge, because that’s—in the 

past 50 years that’s one way that we’ve done a lot of our great stuff is by putting one person in charge and saying, ‘You—you just do it.’

And you can fail and try again and fail and try again, but we're going to put it on—on you to get it right.” 48 Standish Group, CHAOS Report, accessed November 9, 2017, https://www.projectsmart.co.uk/white-papers/chaos-report.pdf. 49 Taylor Putnam, Quantitative Software Management, A Case Study in Implementing Agile, accessed August 11, 2017, 

file:///D:/User/My%20Documents/Downloads/A_Case_Study_in_Implementing_Agile.pdf. 50 Jacques S. Gansler and William Lucyshyn, Implementing the U.S. Army’s Logistics Modernization Program, 28–29, accessed 

November 9, 2017, http://www.cpppe.umd.edu/publications/implementing-us-army%E2%80%99s-logistics-modernization-program. 51 U.S. Senate Permanent Subcommittee on Investigations, The Air Force’s Expeditionary Combat Support System (ECSS): A Cautionary 

Tale on the Need for Business Process Reengineering and Complying with Acquisition Best Practices, accessed November 9, 2017, 

file:///D:/User/My%20Documents/Downloads/PSI%20REPORT%20-%20The%20Air%20Force's%20ECSS%20(July%207%202014).pdf. 52 GAO, DoD Business Systems Modernization, GAO-15-627, accessed June 15, 2017, http://www.gao.gov/assets/680/671452.pdf.
Report of the Advisory Panel on Streamlining and Codifying Acquisition Regulations

Volume 1 of 3 | January 2018

Defense Business Systems: Acquisition of IT Systems Volume 1

IT Recommendations Not Implemented

Previous recommendations for substantial change to the DoD IT acquisition process, including 

acquisition of DBSs, were not implemented. The FY 2010 NDAA required the Secretary of Defense to 

“develop and implement a new acquisition process for information technology systems...and Report to 

Congress...on the new acquisition process developed.”53 The department submitted the required report 

to Congress in November 2010 titled A New Approach for Delivering Information Technology Capabilities in 

the Department of Defense; however, many of the reforms described in the report were not fully 

implemented or not implemented at all. Data from a 2016 GAO report and information collected 

through Section 809 Panel interviews suggest one of the main reasons for failure to implement these 

reforms was frequent turnover of senior leaders whose strong and consistent sponsorship would have 

been necessary to bring sweeping changes to fruition.54 Prominent examples of specific reforms not 

fully implemented are listed in Table 3-2 below.

Table 3-2. Implementation Status of Selected Section 804 IT Acquisition Recommendations

Section 804 Recommendation Implementation Status

Eliminate service and department-level oversight 

redundancy.55

The majority of DBS programs’ milestone decision authority 

(MDA) was delegated to the Military Service level, which was 

positive. Other parts of the process, especially requirements 

approval, are still redundant. Reviews by interim bodies without 

decision-making authority remain a challenge. BCL was an 

attempt to address some of these issues, but was rescinded 

before it could be institutionalized. DBS programs have a unique 

and ongoing challenge in terms of oversight redundancy among 

the acquisition, CMO/DCMO, and CIO roles.

Realign traditional DoD 5000 milestone reviews 

for major program phases to frequent decision 

points more appropriate for the dynamics of IT 

acquisition.56

The latest model for DBS in DoDI 5000.75 appears similar to 

traditional DoD 5000 milestone reviews, although tailoring is 

encouraged. Substantial tailoring is not yet common, and likely 

more of a cultural challenge than a policy issue.

Change institutional processes with separate 

acquisition and sustainment phases to a model 

that allows for continuous IT capability 

development.57

A separate sustainment phase remains in all DoD 5000 lifecycle 

models, including the model in the DoDI 5000.75 designed 

specifically for DBSs. Continuous IT development is difficult to 

achieve under the current models.

Shorten the lengthy project initiation timeline to 

be responsive to the dynamic IT environment.58

No progress has occurred on this recommendation. By some 

accounts, initiating a project takes longer than it ever has (see 

case study in Figure 3-3).

 

53 FY 2010 NDAA, Pub. L. No. 111–84, 123 Stat. 2402, Section 804 (b) (2009). 54 Between 2009 and 2017, five different individuals held or acted in the position of DoD CIO (four of the five in only an acting capacity). 

This represents an average tenure of approximately 1.5 years per individual, and acting officials rarely make major policy changes. The 

DoD CMO and DCMO positions were each held by four different individuals between 2010 and 2016 (GAO, Defense Business 

Transformation: DoD Should Improve Its Planning with and Performance Monitoring of the Military Departments, GAO-17-9, accessed 

November 9, 2017, https://www.gao.gov/products/GAO-17-9.) 55 Adapted from DoD, A New Approach for Delivering Information Technology Capabilities in the Department of Defense: Report to 

Congress Pursuant to Section 804 of the National Defense Authorization Act for Fiscal Year 2010, accessed November 9, 2017, 

https://www.dau.mil/policy/PolicyDocuments/the849OSD13744-10-804ReportToCongress.pdf. 56 Ibid.

57 Ibid.

58 Ibid.
Report of the Advisory Panel on Streamlining and Codifying Acquisition Regulations

Volume 1 of 3 | January 2018

Defense Business Systems: Acquisition of IT Systems Volume 1

Section 804 Recommendation Implementation Status

Move from large multiyear programs to 

portfolios of short-duration projects governed by 

empowered bodies that can make trade-offs 

across a portfolio to deliver valued mission 

capabilities.59

Portfolio governance bodies are but one step in the current DBS 

Investment Management process, and they are simply an interim 

review as opposed to being the final decision makers (i.e., not 

empowered).60 Additionally, trade-off decisions are slow to be 

implemented due to the cumbersome governance and budgeting 

processes.

Change the Planning, Programming, Budgeting, 

and Execution (PPBE) system to more accurately 

reflect the nature of IT capability investment 

(e.g., a single appropriation type for IT projects, 

establishing an IT revolving fund, defining a new 

funding element).61

No substantial progress has been made on this recommendation, 

although as of the writing of this report DASD(C3CB) has a study 

in progress with the intent of making more specific 

recommendations related to funding flexibility for IT acquisitions.

Incorporate continuous user engagement into 

the process of delivering IT.62

Progress varies by functional customer, but typically the process 

includes hand-off of a requirement from a user (capability 

developer in DoD acquisition speak) to a project manager as 

opposed to continuous user engagement. Intensity of user 

engagement needs to be increased to ensure the right users with 

appropriate knowledge and skills are participating in delivery of 

new IT solutions.

Acknowledge the requirements uncertainty 

associated with the dynamic IT environment and 

incorporate the flexibility to responsively 

manage changing needs.63

No substantial progress has been made on this recommendation. 

Based on current DBS guidance, the expectation is that 

requirements are exhaustively defined upfront and approved at 

the Office of the Secretary of Defense (OSD) level, even for a 

Service-specific program/system. Changing requirements once a 

program has commenced is extremely difficult and not timely.

Supplant the deliberate and time-consuming 

waterfall process.64

Limited progress has occurred on this recommendation. Waterfall 

is still the dominant and default lifecycle methodology.

Conclusions

Some progress has been made in terms of deployed DBSs, but it was achieved through the brute force

approach of expending vast amounts of financial and personnel resources. These successes occurred 

despite the acquisition process and culture, rather than because of them, often resulting in slipped 

schedules and cost overruns.65 DoD has not adopted the majority of the reforms identified in the 

2010 Section 804 report, yet those recommendations remain relevant today, and more needed than ever 

as the rate of IT change continues to outpace DoD’s ability to adopt technology and improve its 

 

59 Ibid.

60 DCMO, Defense Business Systems Investment Management Guidance, Version 4.0, accessed August 11, 2017,

http://dcmo.defense.gov/Portals/47/Documents/Governance/DBS%20Investment%20Management%20Guidance%20Version%204.0%20

-%20April%202017.pdf?ver=2017-05-30-110052-673. 61 Adapted from Department of Defense, A New Approach for Delivering Information Technology Capabilities in the Department of 

Defense: Report to Congress Pursuant to Section 804 of the National Defense Authorization Act for Fiscal Year 2010, accessed 

November 9, 2017, https://www.dau.mil/policy/PolicyDocuments/the849OSD13744-10-804ReportToCongress.pdf. 62 Ibid.

63 Ibid. 64 Ibid.

65 GAO, DOD Financial Management: Reported Status of Department of Defense's Enterprise Resource Planning Systems, GAO-12-565R, 

accessed November 9, 2017, https://www.gao.gov/products/GAO-17-9.
Report of the Advisory Panel on Streamlining and Codifying Acquisition Regulations

Volume 1 of 3 | January 2018

Defense Business Systems: Acquisition of IT Systems Volume 1

business operations.66 Recommendations from the 2010 Section 804 report also closely align to the 

conclusions of more recent studies by Navy PEO EIS and DASD (C3CB).67

The greatest shortcomings in the current DBS acquisition process include the following:

§ Requirements are still expected to be fully known and locked down at the outset of a project 

using the lengthy and onerous problem statement process, compromising DoD’s ability to keep 

up with the technology innovation cycle.68

§ It is too difficult to change policies and regulations to conform to commercially available, 

innovative functionality or business processes provided by COTS solutions. Customization 

persists because DoD acquisition professionals perceive it as less difficult than changing policies 

and regulations.69

§ The linear program lifecycle and associated milestones/authority to proceed (ATP) that inhibit 

flexibility and agility persist in DoD regulations, including lengthy separate test events.70

Continuous IT development is not a viable option. Tailoring is officially encouraged, but in 

practice is widely discouraged in the current system. The level of tailoring required to truly use 

Agile concepts breaks most of the paradigms in the current lifecycle, representing too much of a 

perceived risk for most decision-makers.

§ The overlapping compliance and oversight processes of the CCA and 10 U.S.C. § 2222 layered 

on the defense acquisition system represent an additional burden on programs most needing 

the flexibility.

§ Lack of funding flexibility limits the ability of DBS programs to quickly adopt the latest 

technologies and take advantage of opportunities for business operations improvement.71

In preparing this report, the Section 809 Panel reviewed Section 901 of the FY 2017 NDAA and DoD’s 

report to Congress in response to Section 901. The Section 809 Panel also interviewed several 

individuals involved in producing the Section 901 report, with a specific focus on “Part 2: Restructuring 

 

66 House Armed Services Committee Panel on Defense Acquisition Reform, Findings and Recommendations, March 23, 2010, 17.

67 Enterprise IT Acquisition Efficiency Study, Navy PEO EIS, July 2016. DASD(C3CB) Study on Commercial Practices, September 2016. 68 DASD(C3CB) Study on Commercial Practices, Acquisition of Technology, July 7, 2017, 25. As stated in the study, in the current DoD IT 

acquisition process “3.5 Year Period Between Identifying User Needs and Executing the Contract” while “6+ Technology Innovation Cycles 

passed between identifying the user need and executing the contract.” The “Problem Statement” terminology was changed with the 

issuance of DoDI 5000.75 in February 2017. It is now split between “Capability Requirements” (former Problem Statement Part 1) and 

“Business Processes / BPR Changes” (some of which was in Problem Statement Part 2, some of which is new with the 5000.75). 69 Logistics Modernization Program System Procure-to-Pay Process Did Not Correct Material Weaknesses, DoD Inspector General Report 

No. DODIG-2012-087, 19, May 29, 2012. The report states, “Army managers did not perform sufficient business process reengineering to 

implement the BEA’s P2P business process within LMP successfully. Instead, the Army recreated most of the legacy business processes 

within LMP, which did not correct the long-standing material weaknesses within the P2P business process.” 70 “DoD’s acting acquisition chief looks to purge ‘the stupid’ from IT procurement,” by Jared Serbu, Federal News Radio, June 6, 2017, 

https://federalnewsradio.com/dod-reporters-notebook-jared-serbu/2017/06/dods-acting-acquisition-chief-looks-to-purge-the-stupidfrom-it-procurement/. Quoted in the piece, Acting USD(AT&L) James MacStravic states, “By using modern software development and 

automation tools, it’s possible to build in and validate the functionality and information assurance as you’re doing the software, and our 

whole procurement model didn’t reflect that.”

71 See Recommendation 18 on funding flexibility.
Report of the Advisory Panel on Streamlining and Codifying Acquisition Regulations

Volume 1 of 3 | January 2018

Defense Business Systems: Acquisition of IT Systems Volume 1

the Chief Management Officer Organization.” Although the scope of the Section 901 report is broader

than the Section 809 Panel’s acquisition reform mandate, many of the CMO themes in the Section 901 

report are consistent with the Section 809 Panel’s DBS recommendations.72 The general structure of the 

CMO organization is consistent, with some variations in terminology (e.g., the reform leader role in the 

Section 901 report is the enterprise business process owner in the Section 809 Panel’s recommendations). 

The Section 901 report identifies a new PEO for IT Business Systems within the CMO organization and 

states this PEO “will plan and execute the transformation of all business systems affecting support 

areas within the Department.”73 The Section 809 Panel agrees with the concept of the CMO planning 

and executing transformation of business systems; however, acquisition authority for the CMO is not 

explicitly stated in the Section 901 report. The CMO must have authority sufficient to accomplish this 

responsibility; therefore, the CMO should have consolidated authority for requirements, resources, and 

acquisition. 

The other notable difference between the CMO structure in the Section 901 report and the Section 809

Panel’s DBS recommendations is the Military Services supporting the enterprise business process owners. 

The Section 901 report is silent on the Military Services’ role; the Section 809 Panel’s recommendations 

specify empowered portfolio leads with responsibility for all DBS projects/programs within the Military 

Services’ business process (e.g., financial management, supply chain, and logistics). The need exists to 

transition to enterprise services, and the Military Services must be empowered to transform their own 

DBS portfolios while supporting the larger departmentwide transition to enterprise services. 

Implementation

Legislative Branch

§ Provide consolidated acquisition authority to the CMO, including requirements, resources, and 

acquisition (see Figure 3-4 and the corresponding explanation below the figure for proposed 

governance structure).74

 

72 DoD’s Section 901 report Part 2 addresses DoD’s business operations as a whole; the Section 809 Panel recommendations are specific 

to acquisition of DBSs enabling those business operations. 73 DoD, Report to Congress, Restructuring the Department of Defense Acquisition, Technology and Logistics Organization and Chief 

Management Officer Organization In Response to Section 901 of the National Defense Authorization Act for Fiscal Year 2017 (Public Law 

114-328), 18, accessed November 9, 2017, https://www.defense.gov/Portals/1/Documents/pubs/Section-901-FY-2017-NDAA-Report.pdf. 74 Follow a similar approach to the one that provided acquisition authority to U.S. Special Operations Command. See Unified Combatant 

Command for Special Operations Forces, 10 U.S.C. §167(e)(4).
Report of the Advisory Panel on Streamlining and Codifying Acquisition Regulations

Volume 1 of 3 | January 2018

Defense Business Systems: Acquisition of IT Systems Volume 1

Figure 3-4. Recommended DBS Governance Structure

Roles and responsibilities of entities depicted in Figure 3-4:

DoD Chief Management Officer (CMO)

- As stated in the FY 2018 NDAA, becomes the third most senior official in the 

department by precedence and is responsible for all enterprise business operations 

including the CIO functions for DBSs.

- Maintain a simplified DoD BEA described in 10 U.S.C. § 2222 (e) as “a blueprint to guide 

the development of integrated business processes within the Department of Defense.”

- Change policies and regulations that prevent the use of commercial software solutions, 

and advocate for changes to statute when necessary.

- Approve budget requests for business system portfolios as part of the PPBE/POM 

process.

Defense Business Council (DBC)

- As currently specified in 10 U.S.C. § 2222 (f) except now chaired by the DoD CMO 

instead of being cochaired by the Under Secretary of Defense for Business Management 

and Information and the DoD CIO. 

Enterprise Business Process Owners

- Recommend approval of budget requests for business system portfolios.

- Identify and advocate for enterprise (cross-Service) DBS solutions.

- Provide oversight of, and adjudicate issues among, the Service DBS portfolios.

DoD CMO

Finance Logistics HR Acquisition/

Contracting

Installation & 

Environment

Training & 

Readiness

Enterprise Business Process Owners

Army

Finance

Portfolio Lead

Navy

Finance

Portfolio Lead

Air Force

Finance

Portfolio Lead

This structure

replicated for

each business 

process portfolio

Portfolios of 

Agile Projects led by 

Project Managers

DBC

«

«

«

«

«

«

«

«

«

Contracting Office(s)

Matrix Support to Portfolios:

• User

• Systems Engineering

• Test

• RMF and Cyber

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

Volume 1 of 3 | January 2018

Defense Business Systems: Acquisition of IT Systems Volume 1

Service Portfolio Leads

- Provide business process leadership and expertise to projects and project managers 

within the portfolio.

- Identify, select, prioritize, and resource projects within the portfolio based on desired 

business outcome measures and support to the mission via the Portfolio Execution Plan 

(a replacement for the current Organizational Execution Plan [OEP]) which according to 

current DBS Investment Management Guidance (p. 8) “articulates an organization’s 

approach to align with the Functional Strategies and produce business results.”

- Ensure appropriate matrix support from necessary disciplines to enable successful 

project execution.

- Advocate for changes to laws, regulations, and policies (LRPs) when such changes will 

enable more efficient business processes or better outcome measures.

- Assume the responsibilities previously fulfilled by the Service Chief Management 

Officer/Pre-Certification Authority (CMO/PCA): “the senior accountable official that is 

responsible for ensuring compliance with investment review policies...including BPR 

and BEA assertions.”

§ Amend 10 U.S.C. § 2222 to be the sole statute applicable to acquisition of DBSs and do the 

following:

- Eliminate the separate funding certification process (see Recommendation 17).

- Define a new empowered role (portfolio lead) to lead business capability portfolios with 

accountability for business metrics and outcomes, and authority sufficient to affect those 

outcomes.

- Change basis of oversight from covered defense business systems to portfolios of business 

processes. Remove priority defense business systems.

- Remove responsibility of milestone decision authority paragraph to provide authority for project 

decisions to the new empowered portfolio lead.

- Remove the requirement for the CIO’s information technology enterprise architecture to 

address “each of the major business processes conducted by the Department of Defense.” 

Empower the CMO to address business processes.

Executive Branch

§ Revise DoD’s DBS Investment Management Guidance to reflect the following:

- The new empowered and accountable role of portfolio lead.

- A simplified governance process that includes only the CMO, enterprise business process 

owners, and portfolio leads in the chain of command, with the DBC continuing in its current 

capacity as an advisory body.

- Elimination of the separate funding certification process that is now integrated into the 

PPBE process (see Recommendation 17).

- New funding structure based on portfolios of projects instead of individual programs. 
Report of the Advisory Panel on Streamlining and Codifying Acquisition Regulations

Volume 1 of 3 | January 2018

Defense Business Systems: Acquisition of IT Systems Volume 1

§ Rescind the DoD requirements validation and IT business case analysis template for business systems

and empower portfolio leads to determine the optimal requirements definition process for their 

business areas with concurrence of the CMO. 

§ Revise DoDI 5000.75 to reflect the following:

- A simplified and iterative requirements-identification and documentation process that 

acknowledges exhaustive requirements and BPR cannot be completed prior to initiation of a 

project and selection of a specific vendor or technology solution.

- Replacement of the single linear lifecycle and milestone (ATP) decision points with multiple 

lifecycle models, including both Agile and waterfall. Portfolio leads should establish 

lifecycles and decision points based on the attributes of the specific project, and not be 

bound by a set of predetermined decision points. Projects should not be required to have a 

defined point at which they transition to sustainment. Business capabilities and their 

supporting technology will require ongoing development and enhancements.

- New structure of portfolios reflecting a preference for smaller, shorter projects instead of 

large, individual programs; elimination of business system categories and thresholds.

- Responsibility of empowered portfolio leads to change policies and regulations whenever 

possible to enable BPR and adopt commercial processes and technology instead of 

customizing COTS products/solutions. 

- Elimination of the hand-off of requirements from a functional sponsor to a project manager 

in favor of continuous partnership with end users. 

- Prioritization of working software (business capabilities) and improvement of business 

outcome metrics as the definition of success.

- Inclusion of a reference table summarizing all statutory and regulatory information 

requirements applicable to DBSs. 

§ Instruct CMO to publish new BEA guidance reducing the burden on programs to the minimum 

necessary as required by 10 U.S.C. § 2222(e).

Implications for Other Agencies

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