Printer Friendly

Reimagining: Defense business acquisition.

The Department of Defense (DoD) has spent billions of dollars annually to either modernize existing business systems or procure new business systems, yielding uneven results. The milestones, models and documentation driven through the traditional DoD acquisition process have not provided a flexible enough structure for managing business systems. And, in practice, tailoring for a business system has often taken more time and effort than the benefits it produced.


History has shown that:

* The requirements, acquisition and investment review functions necessary for a successful program operate as separate processes, and the key players in each area do not work closely enough.

* There is a tendency to jump to an information technology (IT) solution to the business problem without fully understanding the underlying capability need.


* Functional Sponsors and/or Process Owner(s) are not taking enough ownership, responsibility and accountability for the definition and validation of the capability need and/or do not perform a broad enough analysis of all Doctrine, Organization, Training, materiel, Leadership and Education, Personnel, Facilities, and Policy (DOTmLPF-P) solution options beyond just materiel (IT).

* The current acquisition culture, models, procedures, documentation requirements and oversight expectations do not align with commercial best practices for implementing commercial-off-the-shelf (COTS) products and are neither agile nor flexible.

Unfortunately, many of these challenges are not new. In 1995, the General Accounting Office (renamed in 2004 as the Government Accountability Office [GAO]) designated the DoD's multibillion-dollar business systems modernization program as high risk, and it has been on the GAO's high-risk list ever since. In 2015, GAO added to the list Improving the Management of IT Acquisitions and Operations, recognizing that "federal IT investments too frequently fail or incur cost overruns and schedule slippages while contributing little to mission-related outcomes."

Acquiring defense business systems (e.g., health care, finance, contracting, human resources, logistics, and training) are obviously quite different than acquiring weapon systems (e.g., Joint Strike Fighter aircraft, nuclear aircraft carrier, or a tank), as shown in Table 1. DoD Instruction (DoDI) 5000.02's milestones, models and documentation did not provide the proper structure for managing business systems. And, in practice, tailoring for a business system often took too much time and effort, making it hard to justify the benefits produced.

A New Development Approach

Recognizing these uneven results and the unique nature of Defense Business Systems, Congress in the Fiscal Year (FY) 2016 National Defense Authorization Act (NDAA) required the Under Secretary of Defense for Acquisition, Technology, and Logistics (USD[AT&L]), the Deputy Chief Management Officer (DCMO), and the DoD Chief Information Officer (CIO) to collaborate on a new requirements, acquisition and investment review process for business systems. The USD(AT&L), DCMO, and DoD CIO viewed the FY 2016 NDAA requirement as an opportunity to build a framework to resolve discrepancies and other challenges between acquisition policy in DoDI 5000.02 and DCMO guidance on business systems requirements and the investment review process. A team of subject-matter experts (SMEs) from across the DoD gathered and determined that a new business systems process must:

* Align to Commercial Best Practices: Enforce the mindset that "Industry is the Innovator" in the business systems product market and the need to customize COTS products should be minimized as much as possible.

* Provide Complete Solution Coverage: Cover IT business capabilities and business change across the DOTmLPF-P spectrum and must emphasize consideration of all other nonmateriel options before determining an IT (materiel) solution is needed.

* Maximize Process Efficiency: Reduce process overlaps, clarify oversight roles, and streamline documentation requirements to reduce total life-cycle time (and thus, cost)--from identifying a business capability need to delivery of a solution.

* Enforce Compliance: Address FY 2016 NDAA Section 883

* Provide Flexibility: While enforcing compliance, provide a more useful common ground for process tailoring and allow for multiple implementation approaches (i.e., Agile, incremental, etc.).

The team's work culminated in the business capability acquisition cycle (BCAC) process and supporting policy in the form of the DoDI 5000.75, approved for release on Feb. 2, 2017, by the USD(AT&L), DCMO, and the DoD's CIO. The purpose of the BCAC is to rapidly deploy business capabilities which address identified mission and capability needs within approved cost, schedule and performance parameters. The BCAC addresses in part past recommendations by the Defense Science Board and requirements of Section 804 of Public Law (P.L.) 111-84 to establish a new acquisition process for information technology.

BCAC Process Overview

As shown in Figure 1, the BCAC has five phases and is intended to be cyclical and flexible with steps repeating as necessary to drive more rapid achievement of intended outcome(s). The BCAC implements a governance and management structure; assigns responsibilities of the functional and acquisition communities; provides direction for the identification of business needs, development of capability requirements and supporting IT; and introduces continuous improvement as part of ongoing business capability support.



The linear version of the BCAC is shown in Figure 2 and reflects phases with associated decision points. The process steps, decision points, and roles and responsibilities affiliated with each BCAC step and decision are detailed in DoDI 5000.75.

Finally, Figure 3 summarizes key activities in each of the cycle's phases.

The BCAC unifies existing processes for business systems into one policy as directed by DoDI 5000.75. The BCAC enables users to more quickly implement capabilities by emphasizing the importance of results rather than static documentation.

The defense business systems investment review process implements Title 10 United States Code (U.S.C.) Section 2222 and involves an approval of funds certification. This process is intended to enable the management of a well-defined IT investment portfolio for the DoD Business Mission Area (BM A) by enforcing the business enterprise architecture (BEA), business process reengineering (BPR), and portfolio management. The investment review process is integrated into the BCAC with appropriate decision makers (depending on the level of the program) participating throughout. The first certification to allow the obligation of funds will occur at the Acquisition Authority to Proceed (ATP).

The Clinger-Cohen Act (CCA), or Subtitle III of Title 40, U.S.C, applies to all IT investments, including National Security Systems (NSS). One BCAC benefit is its streamlining of traditionally duplicative CCA confirmation processes. The intent is that any requirement for CCA confirmation is validated during existing BCAC processes, eliminating the need for a separate CCA review.

Guiding BCAC Principles

In the BCAC, success and readiness to move to the next phase will be measured on a "team" basis by acquisition, functional and IT professionals to streamline decision making and allow a quicker transition between phase activities. The BCAC focuses on the following core Guiding Principles to enable success:

* Work as a team: Key constituencies work together as one team with functional, acquisition and IT members involved throughout the life cycle.

* Plan to evolve: The life cycle is continual. Sustainment requires criteria and triggers that define on-ramps back into business need analysis to restart the cycle.

* Adopt best practices: Don't reinvent the wheel. Be willing to prioritize requirements, deploy the 80 percent solution, change processes to minimize customization, and stop the effort if it will not achieve the desired outcome.


* Show the money: Increase transparency by allocating and tracking funding for all activities across the DOTmLPF-P spectrum, including the cost of requirements development and sustainment.

* Do work once: Avoid bottlenecks and eliminate competing processes. Work products are for the use of the process operators--eliminate extraneous documentation for documentation's sake.

* Deliver value: This would be a capability that addresses the entire DOTmLPF spectrum--not just a system. Increase value by reducing the time required to deliver capability.

What's So Different?

The biggest differences from the previous state of practice for business systems operating under the DoDI 5000.02 and supporting guidance and now operating under the BCAC are that it:

* Utilizes ATP decisions in lieu of traditional acquisition milestone decisions for maximum flexibility. ATPs are tailored as necessary, and the decision authority may vary depending on the type of activity being authorized (e.g., acquisition activity would be authorized by a Milestone Decision Authority [MDA] whereas requirements activities would be authorized by a Functional Sponsor). DoDI 5000.75 defines the decision authority at each ATP.

* Emphasizes change management throughout the process--from beginning to "end"--recognizing that there is no true "end" to IT programs and/or their underlying processes.

* Focuses on a thorough analysis of capability needs vs. wants or "nice to haves." Performing this analysis upfront allows for identification of potential non-IT paths that may prove less costly and more effective in addressing an organization's requirements.

* Dictates early examination of existing solutions in use around the DoD in order to avoid creating new solutions where sufficient ones may already exist. These reuse considerations apply not only to minimizing the customizing of commercial software to accomplish functional objectives but also to leveraging existing IT solutions, hosting and infrastructure.

* Takes a dynamic, information-centric approach to evaluating programs rather than focusing on static documentation.

* Provides great encouragement to tailoring both process and documents. Artifacts are intended to be virtual in nature (i.e., not traditional "paper documents") and will be used to support program execution. Programs may choose to develop any other artifacts or documents that they wish in order to execute their programs.

Keys to Implementation Success

The following section provides keys to success that are leveraged from industry research and support the BCAC guiding principles, further enhancing the driving factors that enable BCAC users to successfully execute the process.

Continuous process improvement is a way of life. Therefore, actively manage business processes throughout the life cycle to ensure they can be adapted and optimized. And remember that continuous process and systems improvements also occur after the go-live stage.

Try before you buy. Conduct use case demonstrations, pilots and prototypes prior to acquisition. Use market research, analysis and ratings to narrow viable options in advance. Leverage domain expertise and know the Art of the Possible.

Manage the change. Know your customer--the organization, culture and people. Involve end users throughout the project. Tailor development and deployment strategies to fit the culture and the product. Understand that commonly used methods--such as agile development and cloud--are gaining traction.

Embrace the COTS/Government OTS mindset. Minimize customization and ensure vigorous change control governance. Only customize if there is an advantage or efficiency to be gained. Focus COTS testing on integration points and enhancements.


As the DoD transitions to this new approach for business systems requirements and acquisition, lessons will be learned, best practices adopted and a body of knowledge and experience will emerge. Under the sponsorship of the DCMO, DoD CIO, and USD(AT&L), a community of practice has been established to serve the workforce as its authoritative source for guidance, advice and information regarding the successful acquisition of a business system or capability and application of the BCAC. See

Dewey DuHodway * Howard Harris * Melissa Naroski Merker * Scott Smith

DuHadway is a member of the staff of the Office of the Department of Defense (DoD) Deputy Chief Management Officer. Harris is a professor of Acquisition Program Management at the San Diego Campus of the Defense Acquisition University's West Region. Merker and Smith are staff members of the Deputy Assistant Secretary of Defense for Command, Control, Communications, Cyber and Business Systems.

The authors can be contacted at;; and
Table 1. Weapon System vs. Defense Business System

Category              Weapon System

Requirements          JCIDS process; KPPs; KSAs; ICD, CDD and CPD
Engineering Efforts   Competitive prototypes; technology readiness
                      levels; detailed design; and technical reviews
Testing               Detailed DT and OT
                      Full-up LFT&E as required
                      Demanding IOT&E with warfighters operating the
                      system and in realistic operating environment
Production            Start new production facilities; train the new
                      workforce; ramp up production and material in
                      LRIP after Milestone C; full rate production
Sustainment           Field environment; expensive O&S costs; all
                      Integrated Product Support elements considered

Category             Defense Business System

Requirements         Does not follow JCIDS process unless it is a
                     special interest to JROC
Engineering Efforts  Limited development effort, COTS/GOTS software;
                     software available in the commercial market place
Testing              Full-up LFT&E not required; very limited
                     environmental testing; operational testing in
                     office setting
Production           No production; No Milestone C. Emphases on
                     COTS/GOTS integration coding
Sustainment          Office environment; updating/batches/additional
                     increments of software; priority on training

Key to abbreviations: CDD=Capability Development Document;
COTS/GOTS=commercial off-the-shelf/government off-the-shelf;
CPD=Capability Production Document; DT=Developmental Testing;
ICD=lnitial Capabilities Document; IOT&E=initial operating test and
evaluation; JCIDS=Joint Capabilities Integration Development System;
JROC=Joint Requirements Oversight Council; KPP=key performance
parameter; KSA=key system attribute; LFT&E=Live Fire Test and
Evaluation; O&S=Operations and Support; OT=operational test.

Source: The authors
COPYRIGHT 2017 Defense Acquisition University Press
No portion of this article can be reproduced without the express written permission from the copyright holder.
Copyright 2017 Gale, Cengage Learning. All rights reserved.

Article Details
Printer friendly Cite/link Email Feedback
Author:DuHodway, Dewey; Harris, Howard; Merker, Melissa Naroski; Smith, Scott
Publication:Defense AT & L
Date:Sep 1, 2017
Previous Article:Letter to the editor.
Next Article:Making DoD an employer of choice.

Terms of use | Privacy policy | Copyright © 2019 Farlex, Inc. | Feedback | For webmasters