DOD INSTRUCTION 5000.75
B
USINESS SYSTEMS REQUIREMENTS AND ACQUISITION
Originating Component: Office of the Under Secretary of Defense for Acquisition and Sustainment
Effective: February 2, 2017
Change 2 Effective: January 24, 2020
Releasability: Cleared for public release. Available on the Directives Division Website
at https://www.esd.whs.mil/DD/.
Incorporates and Cancels: Enclosure 12 of DoD Instruction 5000.02, “Operation of the Defense
Acquisition System,” January 7, 2015, as amended February 2, 2017
Cancels: DoD Chief Information Officer (DoD CIO) Memorandum, “Use of
Enterprise Information Technology Standard Business Case Analysis,”
October 23, 2014, for business systems
Approved by: Frank Kendall, Under Secretary of Defense for Acquisition Technology,
and Logistics
Terry Halvorsen, Department of Defense Chief Information Officer
David Tillotson III, Assistant Deputy Chief Management Officer
Change 2 Approved by: Ellen M. Lord, Under Secretary of Defense for Acquisition and
Sustainment
Dana S. Deasy, Department of Defense Chief Information Officer
Lisa W. Hershman, Chief Management Officer
Purpose: In accordance with the authority in DoD Directives 5134.01, 5144.02, 5105.82, 5105.53, and
5000.01 and the July 11, 2014 and July 13, 2018 Deputy Secretary of Defense Memorandums, this
issuance:
• Implements the statutory requirements of Section 2222(c) “Issuance of Guidance” of Title 10 United
States Code (U.S.C.) and Section 883(e) “Guidance on Acquisition of Business Systems” of Public Law
114-92.
• Establishes policy for the use of the business capability acquisition cycle (BCAC) for business
systems requirements and acquisition.
DoDI 5000.75, February 2, 2017
Change 2, January 24, 2020
• Implements the statutory requirements of Subtitle III of Title 40, United States Code (U.S.C.)
and Section 811 of Public Law 106-398 (referred to in this issuance as the Clinger-Cohen Act
(CCA)).
• Supersedes all processes, procedures, and definitions in DoD Instruction (DoDI) 5000.02T
for all business system acquisition programs, including the definition of Major Automated
Information System in DoDI 5000.02T’s Table 2, which does not apply to business systems.
DoDI 5000.75, February 2, 2017
Change 2, January 24, 2020
TABLE OF CONTENTS 3
TABLE OF CONTENTS
SECTION 1: GENERAL ISSUANCE INFORMATION .............................................................................. 5
1.1. Applicability. .................................................................................................................... 5
1.2. Policy. ............................................................................................................................... 5
1.3. Summary of Change 2. ..................................................................................................... 6
SECTION 2: RESPONSIBILITIES ......................................................................................................... 7
2.1. Under Secretary of Defense for Acquisition and Sustainment (USD(A&S))................... 7
2.2. Chief Management Officer of the Department of Defense (DoD CMO). ........................ 7
2.3. DoD Chief Information Officer (DoD CIO). .................................................................... 7
2.4. Director, Cost Assessment and Program Evaluation. ....................................................... 8
2.5. OSD and DOD Component Heads. .................................................................................. 8
SECTION 3: ROLES ........................................................................................................................... 9
3.1. General. ............................................................................................................................. 9
3.2. Roles in Business Systems Requirements and Acquisition. ........................................... 10
a. Functional Sponsor....................................................................................................... 10
b. CMO. ........................................................................................................................... 10
c. Milestone Decision Authority (MDA). ........................................................................ 11
d. Chief Information Officer (CIO). ................................................................................ 11
e. Functional Lead. ........................................................................................................... 11
f. Program Manager. ........................................................................................................ 12
3.3. Program Manager Relationship. ..................................................................................... 12
SECTION 4: PROCEDURES .............................................................................................................. 13
4.1. Overview. ........................................................................................................................ 13
a. Tailoring. ...................................................................................................................... 13
b. ATP Decision Points. ................................................................................................... 13
c. Governance. ................................................................................................................. 14
d. Change Management. .................................................................................................. 14
e. Budgeting by Functional Capability and IT Portfolio. ................................................ 14
f. Continuous Process Improvement. ............................................................................... 14
g. Industry Analysis and Market Research. ..................................................................... 14
h. Prototyping and Demonstrations.................................................................................. 14
i. Delivery of Capability. ................................................................................................. 15
j. Integrated Testing. ........................................................................................................ 15
k. Delegation. ................................................................................................................... 15
l. Documentation and Deliverables. ................................................................................. 16
4.2. BCAC Phase Activities and Decision Points. ................................................................. 16
a. Capability Need Identification. .................................................................................... 16
b. Solution Analysis. ........................................................................................................ 17
c. Functional Requirements and Acquisition Planning. ................................................... 18
d. Acquisition, Testing, and Deployment. ....................................................................... 19
e. Capability Support. ...................................................................................................... 20
APPENDIX 4A: SUPPORTING INFORMATION ................................................................................... 22
APPENDIX 4B: CAPABILITY IMPLEMENTATION PLAN .................................................................... 26
4B.1. Definition. .................................................................................................................... 26
DoDI 5000.75, February 2, 2017
Change 2, January 24, 2020
TABLE OF CONTENTS 4
4B.2. Content. ........................................................................................................................ 26
4B.3. Progression of Capability Implementation Plan Content. ............................................ 29
APPENDIX 4C: CMO CERTIFICATION ............................................................................................ 32
4C.1. Responsibilities. ........................................................................................................... 32
a. DoD CMO. ................................................................................................................... 32
b. MILDEP CMOs. .......................................................................................................... 32
c. Program Manager. ........................................................................................................ 32
4C.2. CMO Certification........................................................................................................ 32
APPENDIX 4D: BUSINESS SYSTEM SOLUTION DOCUMENTATION .................................................. 34
4D.1. Functional Requirements. ............................................................................................ 34
4D.2. Potential Business System Solution Selection. ............................................................ 34
4D.3. Business System Design Specifications. ...................................................................... 34
4D.4. Content of Business System Design Specifications. .................................................... 35
GLOSSARY ..................................................................................................................................... 36
G.1. Acronyms. ...................................................................................................................... 36
G.2. Definitions. ..................................................................................................................... 36
REFERENCES .................................................................................................................................. 39
TABLES
Table 1. DoD Business System Categories.................................................................................... 9
Table 2. Functional Lead and Program Manager Interaction ...................................................... 12
Table 3. Decision Authorities ...................................................................................................... 22
Table 4. Statutory Requirements.................................................................................................. 22
Table 5. Considerations for Decision Criteria ............................................................................. 23
Table 6. Progression of Capability Implementation Plan Content through BCAC Phases and
Decision Points ............................................................................................................................. 30
FIGURES
Figure 1. Business Capability Acquisition Cycle .......................................................................... 6
Figure 2. High-Level BCAC Process........................................................................................... 16
DoDI 5000.75, February 2, 2017
Change 2, January 24, 2020
SECTION 1: GENERAL ISSUANCE INFORMATION 5
SECTION 1: GENERAL ISSUANCE INFORMATION
1.1. APPLICABILITY.
This issuance applies to:
a. OSD, the Military Departments, the Office of the Chairman of the Joint Chiefs of Staff
and the Joint Staff, the Combatant Commands, the Office of the Inspector General of the
Department of Defense, the Defense Agencies, the DoD Field Activities, and all other
organizational entities within the DoD (referred to collectively in this issuance as the “DoD
Components”).
b. All defense business capabilities and their supporting business systems, including those
with “as-a-service” (aaS) solutions. Chief Management Officer (CMO) certification requirements
in this issuance apply to business systems only.
1.2. POLICY.
It is DoD policy that:
a. DoD acquisition of business systems will be aligned to commercial or government best
practices and will minimize the need for customization of commercial products to the maximum
extent practicable. Thorough industry analysis and market research of both process and
information technology (IT) are expected.
b. Business systems acquisition will facilitate business changes through doctrine,
organization, training, materiel, leadership and education, personnel, facilities, and policy to
drive performance improvements, efficiencies, effectiveness, cyber resilience, and audit
compliance.
c. Business systems acquisition is the joint responsibility of the functional and the
acquisition communities. Both communities are accountable for the successful delivery of
business capability, from business process design through business system deployment and
capability support. Functional and acquisition leadership emphasis on change management is
essential for success, and all leaders must drive toward commercial off-the-shelf (COTS) and
government off-the-shelf (GOTS) solutions, to the extent practicable.
d. The acquisition pathway described in this issuance may be used for other non-
developmental, software intensive programs (including national security systems, productivity
solutions, and IT infrastructure), when approved in program acquisition strategies. Statutory
requirements for other types of IT capabilities developed in accordance with this issuance will
still apply. CMO certification requirements in this issuance apply to business systems only.
e. The authority to proceed (ATP) decision points of the BCAC portrayed in Figure 1
provide the framework for acquisition and business decisions in the life cycle and may be
tailored as necessary to contribute to successful delivery of business capabilities.
DoDI 5000.75, February 2, 2017
Change 2, January 24, 2020
SECTION 1: GENERAL ISSUANCE INFORMATION 6
Figure 1. Business Capability Acquisition Cycle
f. Decision authorities in Table 3 of Appendix 4A of this issuance will tailor the application
of regulatory requirements and procedures to best achieve capability outcomes, consistent with
established statutory requirements outlined in Table 4 of Appendix 4A. In addition, decision
authorities will reduce separate reviews and approvals by other organizations when confirmation
through direct collaboration is sufficient.
g. CCA compliance will be accomplished as an iterative process, as all information may not
be available during early ATP decision points. Full CCA compliance (i.e., compliance with all
CCA criteria) is required no later than the first Limited Deployment ATP. More information on
CCA compliance is in Paragraph 3.2.d and Table 4 of Appendix 4A.
1.3. SUMMARY OF CHANGE 2.
This change clarifies policy, responsibilities, procedures, and definitions to address updates to
Section 2430(a) of Title 10, U.S.C., gaps in current business systems policy as a result of lessons
learned, evolving acquisition practices (including DoD’s Adaptive Acquisition Framework and
5000-series initiatives), and changes to other business systems-relevant issuances. This change
also updates references and organizational symbols, and corrects other administrative concerns.
DoDI 5000.75, February 2, 2017
Change 2, January 24, 2020
SECTION 2: RESPONSIBILITIES 7
SECTION 2: RESPONSIBILITIES
2.1. UNDER SECRETARY OF DEFENSE FOR ACQUISITION AND SUSTAINMENT
(USD(A&S)).
The USD(A&S) is the Defense Acquisition Executive. The USD(A&S):
a. Establishes policy and provides oversight for the business systems life cycle.
b. Delegates milestone decision authority (MDA) for assigned business systems described in
Table 1 of Section 3:
(1) To a DoD Component head, who then may delegate the authority to the Component
Acquisition Executive (CAE), but no further for business system Category (BCAT) I programs.
(2) To another OSD official as the USD(A&S) considers appropriate.
2.2. CHIEF MANAGEMENT OFFICER OF THE DEPARTMENT OF DEFENSE (DOD
CMO).
The DoD CMO:
a. Establishes policy and provides oversight for planning and control of investments in
business systems, to include certification of covered defense business systems in accordance
with Section 2222 of Title 10, U.S.C.
b. Maintains the Business Enterprise Architecture (BEA) and requires all functional
strategies, capabilities, processes and systems to be reflected in the BEA.
c. Establishes policy and processes for:
(1) Business system capability portfolio management and its appropriate linkage to the
BEA.
(2) Validation of business needs and identification of capability requirements for
business systems.
d. Validates capability requirements for assigned business systems in Table 1 of Section 3 to
align business capabilities to functional strategies.
e. Delegates requirements validation authority for BCAT I programs to a Military
Department (MILDEP) CMO.
2.3. DOD CHIEF INFORMATION OFFICER (DOD CIO).
The DoD CIO:
DoDI 5000.75, February 2, 2017
Change 2, January 24, 2020
SECTION 2: RESPONSIBILITIES 8
a. Establishes policy and provides oversight for CCA confirmation for business systems.
b. Confirms CCA compliance for joint systems and delegates CCA compliance authority for
all other business systems to the DoD Component CIO.
c. Approves:
(1) Cybersecurity strategies mission-critical and mission-essential IT and BCAT I
programs before ATP decision points or development contract awards.
(2) IT infrastructure and hosting solutions for joint and enterprise business systems and
BCAT I programs.
2.4. DIRECTOR, COST ASSESSMENT AND PROGRAM EVALUATION.
The Director, Cost Assessment and Program Evaluation, establishes policies and procedures for
the collection of cost data, the conduct of cost estimates, and analysis of solution approaches for
the acquisition of business systems.
2.5. OSD AND DOD COMPONENT HEADS.
The OSD and DoD Component heads:
a. Provide policy and guidance relating to their functional area throughout the business
systems life cycle.
b. When requested, advise the program, the MDA, and the appropriate CMO decision
authority on matters relating to their functional area at or before decision points throughout the
business systems life cycle.
DoDI 5000.75, February 2, 2017
Change 2, January 24, 2020
SECTION 3: ROLES 9
SECTION 3: ROLES
3.1. GENERAL.
a. The roles described in this section will be performed by OSD, MILDEP or DoD
Component level leaders according to designated BCAT and delegation of authority.
b. Table 1 defines BCAT based on systems covered by Section 2222 of Title 10, U.S.C.,
along with minimum required decision authorities.
Table 1. DoD Business System Categories
Business System Category / Reason for Designation
Decision Authorities
I
• Priority defense business system expected to have
a total amount of budget authority over the period
of the current Future Years Defense Program
(FYDP) in excess of $250,000,000; or
•
DoD CMO designation as priority based on
complexity, scope, and technical risk, and after
notification to Congress.
Requirements Validation / CMO Certification:
DoD CMO or as delegated
MDA
: defense acquisition executive or as
delegated (not below CAE)
II
• Does not meet criteria for category I.
• Expected to have a total amount of budget authority
over the period of the current FYDP in excess of
$50,000,000.
Requirements Validation / CMO Certification:
MILDEP CMO or as delegated; DoD CMO or
as delegated for all other DoD Components
MDA: CAE or as delegated
III
• Does not meet criteria for category II.
Requirements Validation / CMO Certification:
DoD CMO or MILDEP CMO may designate
as requiring certification
MDA
: Same as category II and further
delegation is encouraged
1.
Transitions from lower to higher business system categories based on FYDP cost thresholds become
effective no later than when the President’s Budget is submitted to Congress.
2. Business systems will not transition automatically from higher to lower business system category even if
FYDP costs no longer exceed thresholds for the higher category. The MDA, in coordination with the
appropriate CMO decision authority, will make the decision to transition from a higher to lower category.
DoDI 5000.75, February 2, 2017
Change 2, January 24, 2020
SECTION 3: ROLES 10
3.2. ROLES IN BUSINESS SYSTEMS REQUIREMENTS AND ACQUISITION.
a. Functional Sponsor.
(1) The functional sponsor is the DoD or Component senior leader with business
function responsibility seeking to improve mission performance. The functional sponsor
confirms the need for improved business operations and represents the user community interests
throughout the BCAC. The functional sponsor represents the DoD organization(s) with a
business problem or opportunity that may be addressed via the acquisition of a business system,
business process reengineering, or related business changes.
(2) The functional sponsor leads solution analysis and change management and creates a
successful change environment. The functional sponsor:
(a) Engages stakeholders to keep them actively involved in shaping the complete
future solution.
(b) Makes resources available for each phase of requirements and acquisition to
include stakeholders and subject matter experts.
(c) Programs and budgets for lifecycle costs of full business spectrum solutions.
(d) Provides input, including market research, to the MDA for the development of
the business system.
(e) Validates that deployed capabilities meet business requirements, deliver expected
benefits, and provide return on investment.
(f) Designates the functional lead who will report to the functional sponsor and
collaborate with the program manager.
b. CMO.
The CMO role will be performed by the DoD CMO or MILDEP CMO identified as the
decision authority in Table 1 depending on the BCAT and any delegation. The CMO:
(1) Determines that business requirements are valid, capability requirements are
achievable, and capability development efforts are appropriate.
(2) Determines that business systems in development are aligned to processes in the
BEA and meet applicable enterprise standards.
(3) In accordance with Section 2222 of Title 10, U.S.C., and with the support from the
functional sponsor and MDA as needed, determines if a program is a business system.
(4) Certifies business system programs to fulfill the requirements of Section 2222 of
Title 10, U.S.C and may designate specific BCAT III systems as requiring certification.
DoDI 5000.75, February 2, 2017
Change 2, January 24, 2020
SECTION 3: ROLES 11
c. Milestone Decision Authority (MDA).
The MDA:
(1) Approves critical acquisition decisions for ATP decision points or concurs in
contractual commitments.
(2) Oversees business system delivery within approved cost, schedule and performance
parameters included in the baseline.
(3) Establishes oversight controls for programs, including procedures to report cost,
schedule and performance variances and to address reported variances. The acquisition chain of
command supports the MDA by leading the program manager and program execution. Specific
leadership roles vary by organization but often include the CAE and Program Executive Officer.
(4) In coordination with the appropriate CMO decision authority, designates BCAT in
accordance with Table 1 of Section 3.
(5) In accordance with Paragraph 1.2.d, authorizes non-developmental, software
intensive programs that are not business systems to use the acquisition processes and procedures
in this issuance and approves the program’s tailored acquisition approach.
d. Chief Information Officer (CIO).
The CIO role will be performed by the DoD CIO or DoD Component CIO depending upon
the BCAT and any delegation. The appropriate CIO:
(1) Confirms CCA compliance based on program manager input and supporting artifacts
through proactive engagement, participating as early as practical in the life cycle. This ensures a
continuous monitoring approach for CCA and cybersecurity compliance instead of conducting a
checklist assessment at the end of each life cycle phase. CIOs will confirm that CCA
compliance is on track during the early BCAC phases using a tailored approach because not all
information may be available yet and will base their decision on information in the program’s
capability implementation plan, defined in Appendix 4B.
(2) Assists with determination of cybersecurity controls and reviews and approves the
cybersecurity strategy at the appropriate delegation level before ATP decision points or
development contract awards.
(3) Establishes standards and supports determination of program IT infrastructure
solutions and hosting requirements, encouraging shared infrastructure solutions and cloud-based
solutions first with the appropriate program executive officer or service provider.
(4) Works with the functional lead and program manager to ensure agile or incremental
software development processes are used to the greatest extent practical.
e. Functional Lead.
The functional lead:
DoDI 5000.75, February 2, 2017
Change 2, January 24, 2020
SECTION 3: ROLES 12
(1) Leads business process reengineering and execution of business process changes.
(2) Leads definition of functional requirements and training and deployment for the
business capability.
(3) Reports to the functional sponsor and collaborates with the program manager.
f. Program Manager.
The program manager:
(1) Leads development and delivery of the business system that supports the delivery of
business capability.
(2) Provides input to the functional sponsor on process design, requirements, training
and other matters that may influence the acquisition strategy for business systems.
3.3. PROGRAM MANAGER RELATIONSHIP.
The relationship between the program manager and the functional lead is shown in Table 2. The
tasks each individual leads or supports are described by phase in Section 4.
Table 2. Functional Lead and Program Manager Interaction
Activity Paragraph
Functional
Lead
Program
Manager
Identify business capability needs 4.2.a Lead Support
Design future business processes & solutions 4.2.b Lead Support
Define functional requirements 4.2.c Co-Lead Co-Lead
Define solution approach 4.2.c Co-Lead Co-Lead
Evaluate solution selection 4.2.d Support Lead
Define detailed design specifications 4.2.d Support Lead
Develop and deliver business system 4.2.d Support Lead
Support business capability 4.2.e Lead Support
Manage configuration of the business system 4.2.e Support Lead
DoDI 5000.75, February 2, 2017
Change 2, January 24, 2020
SECTION 4: PROCEDURES 13
SECTION 4: PROCEDURES
4.1. OVERVIEW.
a. Tailoring.
The procedures used to develop business capability requirements and supporting systems will
be tailored to the characteristics of the capability being acquired. Tailoring will focus on
application of best practices to the totality of circumstances associated with the program,
including affordability, urgency, return on investment, and risk factors.
(1) Tailoring should be considered throughout the life cycle from both the functional and
acquisition perspective, to include program strategies and oversight, program information,
acquisition phase content, and the timing and scope of decision reviews and decision levels.
(2) The MDA may tailor acquisition content (i.e., acquisition strategy content) for all
BCAC phases. Information requirements supporting requirements validation and the CMO
certification process cannot be tailored and must be provided to decision makers as prescribed.
(3) Statutory requirements for business systems are outlined in Table 4 of Appendix 4A
and may not be waived or tailored unless the statute permits.
b. ATP Decision Points.
Decisions will be informed by measures that assess the readiness to proceed to the next phase
of the process. Decision-making will focus on executability and effectiveness of planned
activities, including cost, schedule, performance, acquisition strategy, incentive structure and
risk.
(1) Decisions are coordinated across key stakeholders and made in a collective forum so
that the decision authority is fully informed by the stakeholders at each decision point.
(2) Decision authority is determined by phase content and type of decision being made.
Decision authorities are described in more detail by phase in this section and summarized in
Table 3 of Appendix 4A.
(3) After the Functional Requirements ATP, the timing and number of all subsequent
decision points are established as part of the capability implementation plan, defined in
Appendix 4B.
(4) ATP decisions must be documented for the record. Approval is based upon
component representation that it has satisfied all statutory, regulatory, and any additional critical
requirements unless otherwise stated. Information supporting the decision must be maintained in
accordance with DoD records management procedures.
(5) Considerations for decision criteria to use in support of ATP decision points are
included in Table 5 of Appendix 4A.
DoDI 5000.75, February 2, 2017
Change 2, January 24, 2020
SECTION 4: PROCEDURES 14
c. Governance.
Governance for business capabilities is not a one-size-fits-all model and must be adaptive,
transparent, and inclusive of key stakeholders to enable rapid decision making on key matters
such as requirements, cost, schedule, performance, and risk. Simplified and effective governance
driven by clear outcomes throughout the capability life cycle is encouraged, as is delegating
governance decisions to the lowest practical levels.
d. Change Management.
Change management proactively prepares the functional community for upcoming changes
resulting from the delivery of a business capability, reduces risk, and increases user adoption.
Change management tasks span the lifecycle of the product’s delivery and include the
development and delivery of training materials and ongoing capability improvements addressed
in the capability support phase. The functional lead and program manager are jointly responsible
for change management.
e. Budgeting by Functional Capability and IT Portfolio.
Every phase outlined in this document will be funded in the planning, programming, budget,
and execution process. To facilitate this, functional capability and IT portfolio program elements
will be established by Components to fund business need definition and business solution design
efforts. Funding in the program objective memorandum will represent the work to be done
across the life cycle, starting with requirements development through deployment and capability
support.
f. Continuous Process Improvement.
The functional sponsor will engage in continuous process improvement throughout all phases
of the BCAC, based on opportunities that emerge in analysis of existing capabilities, processes,
and supporting IT in use within the existing organization and at other organizations. The
functional sponsor will prioritize these continuous process improvement opportunities for current
and future initiatives.
g. Industry Analysis and Market Research.
The functional sponsor and MDA must provide access to domain experts with functional and
technical knowledge to support analysis of processes from industry and government for
capability delivery options. These domain experts must guide the development of business
requirements without preferring business systems over business process improvements. Market
research will identify existing and emerging business systems available to support future
processes.
h. Prototyping and Demonstrations.
To the extent that it benefits the program and at acceptable cost and risk, program managers
are encouraged to use prototyping and demonstrations to inform requirements, support market
research, and support selection of products and services. Program managers will provide the
DoDI 5000.75, February 2, 2017
Change 2, January 24, 2020
SECTION 4: PROCEDURES 15
MDA with the expected benefits that these efforts will provide as well as the approach for
making any prototypes operational, as appropriate.
i. Delivery of Capability.
Functional leads and program managers will apply commercial best practices and lessons
learned to prioritize and more rapidly develop and deploy useable, affordable subsets of
capability.
(1) A release is a manageable subset of functionality, such as minimum viable product,
that provides utility in support of the business capability. Based on the program’s particular
baselining approach, releases will be baselined and documented in the capability implementation
plan, as defined in Appendix 4B. The utility provided by a release does not have to fulfill the
entire business capability. Additional utility may be added through iterative releases based on
user feedback to minimize risk and increase adoption.
(2) A deployment either introduces a new release into the production environment or
expands the user base of existing functionality. Deployment includes training and business
systems operations activities such as help desk support.
j. Integrated Testing.
The MDA will oversee an effective yet efficient testing approach that incorporates:
(1) Integrated testing, in which a single test activity can provide data to satisfy multiple
objectives, as supported by an integrated testing strategy documented in the capability
implementation plan defined in Appendix 4B. Integrated testing may include combined
contractor and government developmental testing, as well as integrated government
developmental and operational testing.
(2) The use of test automation, to the greatest extent practical.
(3) Involvement of users and testers throughout the entire life cycle.
(4) When supported by the appropriate risk analysis, assessments will primarily use data
from integrated test events rather than a dedicated independent operational test event. For
programs on the Director, Operational Test and Evaluation (DOT&E) Oversight List, the level of
test and use of integrated test data, test strategies, as well as dedicated operational test events
should be approved by DOT&E based upon Guidelines for Operational Test and Evaluation of
Information and Business Systems.
k. Delegation.
Decision authorities in Table 3 of Appendix 4A will evaluate remaining risk in business
system programs at each decision point and can delegate authority for specific releases or all
remaining program capability, to empower leaders to provide timely guidance and make
decisions at the lowest practical level.
DoDI 5000.75, February 2, 2017
Change 2, January 24, 2020
SECTION 4: PROCEDURES 16
l. Documentation and Deliverables.
Information requirements will generally not be prepared solely for staff review and approval.
In addition to supporting decision making at ATP decision points, these products should support
program activities such as contracting actions or test events, or serve as planning and
management tools. The information produced will be specific to each program and acquisition
information (e.g., acquisition strategy content) will be tailored to meet individual program needs.
Details will be maintained by the program in a transparent and timely manner, readily available
for reviews as needed.
4.2. BCAC PHASE ACTIVITIES AND DECISION POINTS.
Figure 2 illustrates the five phases in the process. The BCAC is intended to be cyclical and
flexible with phases repeating as necessary to drive timely achievement of outcomes.
Figure 2. High-Level BCAC Process
a. Capability Need Identification.
The functional sponsor leads this phase with guidance and support from the appropriate
CMO decision authority. The objective is to establish a clear understanding of needed business
capabilities so that the functional sponsor and acquisition officials can decide to invest time and
resources into investigating business solutions.
(1) Phase Description.
(a) The capability need is based on the desired end state in a business mission area,
the problem(s) preventing it, and the future capabilities required to achieve it.
(b) Definition of the future capabilities will include analysis of other organizations
with similar capability needs.
DoDI 5000.75, February 2, 2017
Change 2, January 24, 2020
SECTION 4: PROCEDURES 17
(2) Solution Analysis ATP.
At this decision point, the appropriate CMO decision authority, with input from the
functional sponsor, validates the capability requirements, approves the work planned for the next
phase, and verifies the capability is aligned with the BEA as well as organizational or OSD
functional strategy and IT portfolio management goals.
(3) Information Requirements.
Machine searchable capability requirements must be provided for the Solution Analysis
ATP. Capability requirements must include:
(a) A description of the business problem or opportunity and its impact on cost and
mission performance.
(b) Prioritized business capabilities and their attributes, such as testable, quantifiable,
and achievable, capability performance measures with associated current and future values,
including threshold and objective values for future capability performance.
(c) Pertinent law, regulations and policies that will either require modification or
constrain solutions.
b. Solution Analysis.
The functional sponsor leads this phase with guidance from the appropriate CMO decision
authority and support from the program manager and MDA. The objective of this phase is to
determine the high-level business processes supporting the future capabilities to maximize use of
existing business solutions and minimize creation of requirements that can only be satisfied by a
business system.
(1) Phase Description.
(a) Future capabilities are based on reengineering the high-level future business
processes that will deliver the capabilities. This includes selecting and tailoring commercial best
practices to meet the needs of the end user community.
(b) Definition of the future capabilities will include market analysis and research of
other organizations with similar capabilities to identify processes that can be adopted.
(c) The functional sponsor must ensure funding is available to support the phase
activities and must provide a plan for funding future phases, as appropriate. The availability of
funding must be validated by the appropriate resource official prior to the Functional
Requirements ATP.
(2) Functional Requirements ATP.
At this decision point:
DoDI 5000.75, February 2, 2017
Change 2, January 24, 2020
SECTION 4: PROCEDURES 18
(a) The appropriate CMO decision authority validates that sufficient business process
reengineering has been conducted to determine whether a business system is required.
(b) The MDA approves execution of the activities outlined in the capability
implementation plan defined in Appendix 4B.
(3) Information Requirements.
(a) Business Processes.
High-level business processes must be structured to focus on the work to be
conducted and on the information used, not supporting IT.
(b) Capability Implementation Plan.
See Appendix 4B for information on the capability implementation plan.
c. Functional Requirements and Acquisition Planning.
During this phase, the functional sponsor leads execution of approved business process
actions in the capability implementation plan, defines IT functional requirements, and assists the
program manager with assessing the overall solution approach (e.g., COTS, GOTS, “aaS,”
legacy modernization, or new development). Meanwhile, the MDA oversees development of the
acquisition strategy. An objective of this phase is to establish the acquisition strategy and
identify the capability support approach required to meet the functional requirements.
(1) Phase Description.
(a) Functional requirements describe how the business system will achieve the future
business processes.
(b) The program manager engages further with industry (e.g., market research,
benchmarking, requests for information, industry days) so that functional requirements reflect
the current state of practice and inform the acquisition strategy. Additional information on
functional requirements is included in Appendix 4D.
(c) The appropriate cost agency will support development of alternatives and
determination of the solution approach that best fits the needs and organizational goals based on
economic analysis in accordance with DoDI 7041.03.
(d) The acquisition strategy included in the capability implementation plan reflects
the solution approach and describes how the program manager will identify potential business
system solutions and perform solution selection. Additional information on criteria for potential
business system solutions is included in Appendix 4D.
(e) The program manager may, with the approval of the MDA, conduct design
specification activities normally conducted after the Acquisition ATP to inform the acquisition
strategy.
DoDI 5000.75, February 2, 2017
Change 2, January 24, 2020
SECTION 4: PROCEDURES 19
(f) As appropriate, the program manager will partner with the contracting officer to
develop draft request for proposals (RFPs) that align to the acquisition strategy for the contract
actions that follow the Acquisition ATP.
(g) Before the Acquisition ATP is approved, the appropriate CMO decision authority
will approve the initial certification based on the chosen solution approach. Additional
information on CMO certification is in Appendix 4C.
(2) Acquisition ATP.
At this decision point, the MDA:
(a) Verifies the requirement is fully funded across the FYDP to support all the
acquisition activities requested for approval.
(b) Authorizes execution of the acquisition strategy and approves continued
execution of the capability implementation plan.
(3) Information Requirements.
See Appendix 4B for information about the capability implementation plan.
d. Acquisition, Testing, and Deployment.
During this phase, the program manager leads execution of contract award, vendor
management, establishment of baselines, delivery of the business system, and risk management.
Meanwhile, the functional sponsor leads training and deployment. The objective of this phase is
to achieve organizational change through business process changes and delivery of the
supporting business system, with minimal customization.
(1) Phase Description.
(a) Detailed fit-gap analysis follows solution selection based on the acquisition
strategy. Fit-gap analysis will be based on the known capabilities of the COTS/GOTS software
in the selected business system solution.
(b) Design specifications will reflect fit-gap analysis and prioritization of features to
allow for cost and schedule trades within scope.
(c) Development, delivery and support activities will be baselined and detailed in the
implementation plan, expressed in terms of releases and deployments.
1. A limited deployment is any deployment before the Full Deployment ATP that
provides a set of functionality to a set of users of the business system. The functional sponsor
and program manager will recommend the functionality and number of users. Limited
deployments will be approved at a Limited Deployment ATP.
DoDI 5000.75, February 2, 2017
Change 2, January 24, 2020
SECTION 4: PROCEDURES 20
2. The MDA will require sufficient testing before Limited and Full Deployment
ATPs. For business systems on the DOT&E Oversight List, DOT&E will approve all
operational test plans, and an Initial Operational Test and Evaluation will be conducted before
the Full Deployment ATP.
3. Full deployment is the delivery of full functionality planned to all planned
users of the business system in accordance with the Full Deployment ATP.
(d) The MDA will oversee establishment of cost, schedule and performance
parameters for each release before development or delivery.
(2) Limited Deployment ATP(s).
At this decision point, the MDA, in conjunction with the functional sponsor, considers
the results of testing, and approves deployment of the release to limited portions of the end user
community. Multiple limited deployments may be authorized at the same decision point or
delegated to a lower decision authority.
(3) Full Deployment ATP.
At this decision point, the MDA, with the support of the functional sponsor and
appropriate CMO decision authority, considers the results of limited deployment(s) and
operational testing and approves deployment to the entire user community.
(4) Capability Support ATP.
At this decision point, the functional sponsor accepts full deployment of the system and
approves transition to capability support.
(5) Information Requirements.
See Appendix 4B for information about the capability implementation plan and capability
support plan.
e. Capability Support.
During this phase, the functional sponsor manages and governs the business capability and
the program manager manages the technical implementation and configuration of the business
system. The objective of this phase is to provide support for the business capability, including
continued cybersecurity readiness and enduring support for and appropriate upgrades to the
business system.
(1) Phase Description.
(a) The functional lead, with the support of the program manager, leads development
of capability requirements, business process design and re-engineering, and training for the
business system in support of continuous process improvement.
DoDI 5000.75, February 2, 2017
Change 2, January 24, 2020
SECTION 4: PROCEDURES 21
(b) The functional lead and program manager jointly develop and execute tailored
capability implementation plans for each new set of capability requirements addressed in this
phase.
(c) The functional lead and program manager will continue periodic assessments of
opportunities available in the marketplace to determine changes necessary to reduce costs and/or
improve efficiencies to maintain the relevance of the capability and the business system.
(d) The program manager will establish and manage cost, schedule, and performance
metrics associated with upgrades to the approved baseline.
(2) Capability Support Reviews.
Each DoD Component will determine the frequency, content, and format of these reviews
and will outline these details in the capability support plan. These reviews can occur at either the
program or portfolio level. The following scenarios may prompt these reviews:
(a) Cost growth above the approved baseline;
(b) Changes to program requirements; or
(c) Upgrades to the business system in response to approved requirements changes.
(3) Information Requirements.
See Appendix 4B for information on information requirements for capability support.
DoDI 5000.75, February 2, 2017
Change 2, January 24, 2020
APPENDIX 4A: SUPPORTING INFORMATION 22
APPENDIX 4A: SUPPORTING INFORMATION
Table 3 describes decision authorities for each decision point by role. The decision authority
will be at the OSD or DoD Component level according to designated BCAT and delegation of
authority. Table 4 aligns statutory requirements to BCAC decision points. Table 5 provides
considerations for decision criteria; it does not represent a mandatory checklist for decision
points.
Table 3. Decision Authorities
Decision Point
Decision Authority or Authorities
Solution Analysis ATP
CMO
Functional Requirements ATP
CMO (requirements validation)
MDA (materiel solution)
Acquisition ATP, Contract
Award, Limited Deployment
ATP(s), Full Deployment ATP
MDA
Capability Support ATP
Functional sponsor
Capability Support Reviews
(as needed)
Determined in Capability Support Plan
Table 4. Statutory Requirements
Decision Point
Statutory Requirements
Solution Analysis ATP
None
Functional Requirements ATP
None
Acquisition ATP
Section 2222 Title 10, U.S.C. information / CMO
certification
1
Solution approach (fulfills market research,
analysis of alternatives and economic analysis)
Cybersecurity strategy (for mission essential and
mission critical IT)
Contract Award
CCA Compliance
Limited Deployment ATP(s)
Full CCA compliance at first ATP
2
; confirmation
of compliance at additional ATPs
Full Deployment ATP
Confirmation of CCA compliance
Initial Operational Test and Evaluation Report (for
business systems on the DOT&E oversight list)
Capability Support ATP
None
Capability Support Reviews
(as needed)
None
1. CMO certification can occur during prior phases, but must occur before the
Acquisition ATP is approved.
2. Full CCA compliance can occur during prior ATP decision points, but must occur
no later than the first Limited Deployment ATP. Separate documentation should
not be needed to confirm CCA compliance.
DoDI 5000.75, February 2, 2017
Change 2, January 24, 2020
APPENDIX 4A: SUPPORTING INFORMATION 23
Table 5. Considerations for Decision Criteria
Decision Point
Considerations for Decision Criteria
Solution
Analysis
ATP
•
Concise business problem and desired end state, with cost and performance
improvements.
• Documented laws, regulations and policies.
• Alignment with and submission to the BEA.
• Validated capabilities and capability performance measures.
•
Affordable capability with compelling business case for committing
organizational resources for work planned up to next decision point.
Functional
Requirements
ATP
• High-
level business processes include performance measures and supporting
activities and tasks with inputs and outputs.
• Business processes focus on work and not supporting systems or IT.
• Clear understanding of the process and functional changes needed to achieve
future business processes.
• Key processes identified for improvement documented with changes in process
models.
• Business processes reflect knowledge of industry state of the art.
• Business process actions identified, prioritized and included in the capability
implementation plan.
• ROM cost estimate for all business changes to achieve future business processes.
•
Affordability targets for business system with compelling business case for
committing organizational resources for work planned up to next decision point.
• Acquisition strategy outlines planned decision points and decision authorities.
• Consistency with DoD Information Enterprise policies and architecture.
• High-level understanding of capability support requirements.
•
Initial cybersecurity strategy consistent with DoD policies, standards, and
architectures.
DoDI 5000.75, February 2, 2017
Change 2, January 24, 2020
APPENDIX 4A: SUPPORTING INFORMATION 24
Table 5. Considerations for Decision Criteria, Continued
Decision Point
Considerations for Decision Criteria
Acquisition
ATP
•
•
•
•
•
•
•
•
•
•
•
•
Alternatives leverage market research on existing or emerging COTS and GOTS
products and services.
Potential business system solutions reflect traceability to functional requirements
and decomposition.
Potential business system solutions include trade space to minimize
customization.
Potentially expensive or high risk functional requirements are identified with
recommended alternative approaches.
Potential business system solutions address technical and lifecycle support
requirements.
Solution evaluation criteria include: economic analysis; satisfaction of functional
requirements and information assets; satisfaction of technical requirements and
lifecycle support requirements; and overall risk.
Solution evaluation criteria include (if needed): delivery schedule; evaluation of
trade space for functional requirements; and enterprise impacts.
Technical management strategy identifies lifecycle methodology for
development and delivery of the business system, to include capability support.
Consistency with DoD Information Enterprise policies and architecture.
Cybersecurity strategy consistent with DoD policies, standards and architectures
,
including interoperability requirements.
Auditability compliance is reviewed and confirmed, if necessary and appropriate
Certification under Section 2222 Title 10, U.S.C.
Limited
Deployment
ATP
•
•
•
•
•
•
•
Maturity of developed or configured software through pre-production assessment
of functional requirement coverage and defects impacting users.
Execution of change management, training and deployment plans.
Consistency with DoD Information Enterprise policies and architecture.
Test results (including cybersecurity tests) indicating adequate performance and
cybersecurity.
Program progress against baselined cost, schedule and performance.
Ensure CCA compliance
Actions necessary for capability support.
DoDI 5000.75, February 2, 2017
Change 2, January 24, 2020
APPENDIX 4A: SUPPORTING INFORMATION 25
Decision Point
Considerations for Decision Criteria
Full
Deployment
ATP
•
Measured performance of operational software in support of future business
processes and technical and lifecycle requirements.
• Organizational readiness for continued deployment.
• Consistency with DoD Information Enterprise policies and architecture.
• Test results (including cybersecurity tests) indicating adequate performance and
cybersecurity.
• Program progress against baselined cost, schedule and performance.
• Ensure CCA compliance.
• Actions necessary for capability support.
Capability
Support
ATP
• Measured performance of implemented future business processes.
• Continued cybersecurity readiness.
• Organizational readiness for capability support.
DoDI 5000.75, February 2, 2017
Change 2, January 24, 2020
APPENDIX 4B: CAPABILITY IMPLEMENTATION PLAN 26
APPENDIX 4B: CAPABILITY IMPLEMENTATION PLAN
4B.1. DEFINITION.
a. The capability implementation plan is an aggregation of the content needed by the
program office to prepare for and manage the delivery of the capability and to support statutory
and regulatory requirements; it is not a specific document or set of documents. It accounts for all
necessary information products required to support and inform leadership decisions.
b. Capability implementation plan information will be stored and used by the program office
in whatever applicable format or repository is needed and information will be maintained in
accordance with records management procedures. Details will be maintained in a transparent
manner and will be made readily available for reviews as needed.
c. The capability implementation plan must include or reference the information
requirements developed during early BCAC phases that support requirements validation and the
CMO certification process. All other implementation plan content (i.e., acquisition strategy
content), may be tailored to the individual needs of the program unless required by statute.
d. The acquisition strategy content of the implementation plan may need to be maintained
separately to compartmentalize acquisition sensitive information. Similarly, technical content
concerning cybersecurity may also be maintained separately.
e. The program may rely on external content such as portfolio procedures to govern
technical management. In this case, the capability implementation plan content supplements the
portfolio procedures only as needed to tailor the program.
4B.2. CONTENT.
Although content will differ from program to program, an effective capability implementation
plan will include:
a. References to the capability requirements that the capability implementation plan
supports.
b. A description of planned decision points with governance details that describe decision
authorities, information requirements that will support the decision, and actions the decision will
authorize.
c. A description of business process actions and leaders responsible. Common business
process actions include:
(1) Implementation of law, regulation, policy or business process changes, including
those that do not require business systems and those that must occur before the business system
can be acquired.
DoDI 5000.75, February 2, 2017
Change 2, January 24, 2020
APPENDIX 4B: CAPABILITY IMPLEMENTATION PLAN 27
(2) Development of training materials in support of business process changes.
(3) Conduct of user training and deployment in support of the business system.
d. A description of acquisition actions and leaders responsible. Common acquisition actions
include:
(1) Requests for information, peer reviews, RFPs, and contract awards.
(2) Definition and modeling of functional requirements, inputs and outputs, and design
specifications.
(3) Software design, development and testing.
(4) Developmental and operational test and evaluation.
(5) Technical and management assessments (e.g., engineering, test, and program
management) to identify and mitigate risks and manage issues.
(6) Development of training materials in support of the business system.
(7) Coordination and approval of memoranda of agreement, interface control agreements
and service level agreements.
e. The combined schedule actions needed to deliver and support the capability.
f. A component-based representation of the decomposition of the work to be executed to
deliver and support the capability (e.g., work breakdown structure or capability roadmap).
g. Acquisition objectives: a description of the organizational or strategic business goals for
the development and delivery of the business capability in terms of cost and benefits, schedule,
return on investment, and affordability. These should include indicators to identify when a
program may be at risk.
h. Baseline: a reference against which to measure progress of the business capability. The
desired end state of the business system and associated business processes at the program or
release level, expressed in terms of cost, schedule, performance, and other measures as
appropriate. Baselines should be established no later than 24 months after the original Solution
Analysis ATP.
(1) If at the program level, the baseline will be set prior to the development of the first
release/deployment.
(2) If at the release level, the baseline will be set prior to the development of each release
or deployment.
i. Tailored business system acquisition strategy.
DoDI 5000.75, February 2, 2017
Change 2, January 24, 2020
APPENDIX 4B: CAPABILITY IMPLEMENTATION PLAN 28
(1) Acquisition content: a description of the program approach to leverage competition
to acquire the required capability at reduced cost and risk. The approach must describe the
business strategy, including major contracts planned, contract type(s) and incentives, market
research, potential sources, capability support strategy, subcontracting opportunities, special
contracting considerations and special clauses, the business case for or against obtaining
warranties, payment methods, contract management and administration, intellectual property
strategy, and use of COTS or reasons not to use COTS.
(2) Technical management content: a description of the program approach to leverage
systems engineering, test and evaluation (T&E), cybersecurity, and data management processes
to reduce technical risk. Specific T&E management content requirements include:
(a) Test events to collect data must be defined, scheduled, and resourced in the
capability implementation plan, including a Developmental Evaluation Framework matrix.
(b) Cybersecurity T&E should be based on a zero-trust model and incorporate
automated testing practices as much as practical (e.g., static/dynamic code analysis) early in the
lifecycle to remediate and mitigate vulnerabilities. It will include continuous monitoring and
will consider appropriate application of the DoD Cybersecurity Test and Evaluation Guidebook
for cybersecurity T&E activities. The MDA will not tailor cybersecurity T&E solely to meet
authority to operate requirements. For business systems on the DOT&E oversight list,
cybersecurity operational T&E must also include a Cyber Economic Vulnerability Analysis as
outlined in current DOT&E Memoranda.
(c) T&E planning will include mission-oriented development T&E with actual
operators performing end-to-end scenarios in a controlled environment, which may be conducted
as integrated tests to also address operational test goals.
(d) Interoperability developmental T&E will include testing with actual
representations of interface systems in a controlled environment.
(e) Business systems on the DOT&E Oversight List will document T&E
management content in a test and evaluation master plan.
(f) Automated test tools and scientific test and analysis techniques should be
considered to increase test efficiency.
(3) Other content if needed: international considerations, multiyear procurement and
integration of intelligence assessments, and expected benefits for potential prototypes as well as
the approach for making them operational.
j. Capability Support Plan: a strategy for executing capability support activities and the
leaders responsible for these activities. The plan will be developed in a transparent manner and
will be made readily available for reviews as needed.
(1) The capability support plan should include:
DoDI 5000.75, February 2, 2017
Change 2, January 24, 2020
APPENDIX 4B: CAPABILITY IMPLEMENTATION PLAN 29
(a) A governance structure that provides resources, prioritizes changes, and
establishes plans for executing changes that fall within the scope of the original capability
requirements.
(b) A plan for conducting periodic program reviews, including the frequency,
content, and format of these reviews.
(c) A threshold for changes to determine whether or not the change requires re-entry
into the BCAC process. Major capability changes that do not fall within the scope of the original
capability requirements will require re-initiation of the BCAC process to integrate the new
capability.
(d) Tailored capability implementation plans for each new set of capability
requirements addressed in this phase.
(2) The capability support plan will be continuously maintained throughout the
capability life cycle and will be reviewed and updated as appropriate to accommodate for
capability modernization or new capability requirements.
4B.3. PROGRESSION OF CAPABILITY IMPLEMENTATION PLAN CONTENT.
a. During early BCAC phases, the capability implementation plan will contain a low level of
detail because knowledge is limited early in the life cycle. As the life cycle progresses, the
amount of information and the level of detail will mature and evolve. Each program, in
collaboration with the MDA, should assess the information requirements for each BCAC phase
and determine which ones are applicable to manage the program and inform program decisions.
Information requirements that support requirements validation and the CMO certification process
must be completed.
b. Table 6 describes the expected progress of capability implementation plan content as a
program progresses through BCAC phases and decision points.
DoDI 5000.75, February 2, 2017
Change 2, January 24, 2020
APPENDIX 4B: CAPABILITY IMPLEMENTATION PLAN 30
Table 6. Progression of Capability Implementation Plan Content through BCAC Phases
and Decision Points
Solution Analysis
Information Requirements
• References to or updated requirements documentation as applicable.
• High-level business capability process maps.
• Results of market analysis and research that reflect engagement with other
organizations with similar capabilities to understand their business
processes, supporting solutions, and ability to support the capability need.
• Detailed plans for any business process changes required to successfully
deploy the needed capability.
• High-level schedule and resource plans for potential acquisition actions.
• High-level
decomposition of work (e.g., work breakdown structure or
capability roadmap).
• Rough order of magnitude cost and cost benefit analysis for any potential
business system.
• Initial Acquisition Strategy.
Purpose
• Determine if the required business capability can be met by leveraging
existing business processes or solutions; or
•
Set the stage for a new business system by establishing program
management and funding structure to inform Functional Requirements ATP
decisions.
Maturity Level
• Capability requirements and associated business processes are mature and
documented.
• Acquisition strategy and rough order of magnitude are high level, since
business solutions have not been fully analyzed and/or selected. They
should be only as detailed and mature as current program knowledge will
allow and should not constrain decision making of possible business
solutions.
Functional Requirements and Acquisition Planning
Information Requirements
• Functional requirements that include enough detail to inform definition of
potential business system solutions and evaluation criteria, but not too much
detail that would overly constrain solution selection.
• Detailed plans and resource-
loaded schedules for actions required to
implement future business processes.
• Plan to obtain full funding across the FYDP to support the acquisition
activities approved at the Acquisition ATP.
• Initial capability support plan providing insight as to how future capability
solution(s) will be supported and decision making will be governed.
• A plan for baselin
ing, updating, and managing cost, schedule, and
performance at the program or release level as appropriate.
• As appropriate, draft RFPs that align to the initial Acquisition Strategy for
the contract actions that follow the Acquisition ATP.
• Initial test plan.
• CCA compliance initial approval (with limited data).
•
Cybersecurity Strategy initial approval.
Purpose
Inform decisions regarding a solution approach and a path to meet validated
capability requirements.
Maturity Level
• Acquisition Strategy is detailed and the capability support plan includes
high-level detail on governance and decision making for supporting the
business capability.
• All other information requirements continue to mature based on execution
of the capability implementation plan and Acquisition Strategy.
DoDI 5000.75, February 2, 2017
Change 2, January 24, 2020
APPENDIX 4B: CAPABILITY IMPLEMENTATION PLAN 31
Table 6. Progression of Capability Implementation Plan Content through BCAC Phases
and Decision Points, Continued
Acquisition, Testing, and Deployment
Information Requirements
• Updated documentation to reflect current plans, including Acquisition
Strategy, cost documentation, test plans, and requirements documentation
(as applicable).
• Refined capability implementation plan that reflects most current plans and
strategies for releases, testing, and deployments, beginning with the first
deployment.
• Updated draft RFP(s) (if needed).
• Baseline(s) structured at the release or program level.
•
Updated capability support plan including roles and responsibilities for
support activities, a governance structure, a threshold for changes, and a
proposed schedule of periodic capability support reviews.
• Architecture products required by DoDI 8330.01 that provide the necessary
data to support interoperability testing. A separate information support plan
(ISP) document is not required for business system programs following this
guidance.
• Mature and detailed decomposition of work (e.g., work breakdown structure
or capability roadmap).
• Updated test plan.
• Integrated testing results.
• Training materials and training reports.
• Technical review results.
• Cybers
ecurity Strategy final approval before first Limited Deployment
ATP.
• Full CCA compliance before first Limited Deployment ATP.
• Updated schedule and resource plans for acquisition actions.
Purpose
• Supports contract award, development, testing, training, deployment and
capability support.
• Baseline establishment supports effective management of the program.
• At Limited Deployment and Full Deployment ATPs, training and testing
results inform the MDA on the level of operational risk associated with the
capability deployment.
Maturity Level
During this phase, all information and documents are fully mature.
Capability Support
Information Requirements
Tailored capability implementation plans for each new set of requirements
approved by the Functional Sponsor.
Purpose
Support the business system and the continuous improvement of that solution
through the life cycle.
Maturity Level
• Original capability implementation plan information and documents are
fully mature and are updated at least annually to ensure relevance.
• New capability implementation plans that are included as annexes to the
original capability support plan will continue to mature throughout the
development and deployment of the new capability.
DoDI 5000.75, February 2, 2017
Change 2, January 24, 2020
APPENDIX 4C: CMO CERTIFICATION 32
APPENDIX 4C: CMO CERTIFICATION
4C.1. RESPONSIBILITIES.
a. DoD CMO.
The DoD CMO:
(1) Provides certification for all priority business systems under Section 2222 Title 10,
U.S.C., and for other business systems as required that are not under the authority of a MILDEP
CMO.
(2) May require any business system to receive certification and may designate any
business system as a priority business system after notifying Congress.
b. MILDEP CMOs.
The MILDEP CMOs:
(1) Provide certification as required for any business system of their respective MILDEP,
other than a priority business system.
(2) May request designation of a non-priority business system as requiring DoD CMO
certification.
(3) In collaboration with the program manager, participates in the development of
necessary certification artifacts and preparation for certification as early as practical in the life
cycle.
c. Program Manager.
The program manager collaborates with the appropriate CMO decision authority to develop
necessary certification artifacts and prepare for certification as early as practical in the lifecycle.
This proactive approach ensures that risks and issues are addressed before the Acquisition ATP.
4C.2. CMO CERTIFICATION.
a. The appropriate CMO decision authority will certify that business systems covered by
Section 2222 of Title 10, U.S.C., meet the requirements of subsection (g)(1)(A-E) of Section
2222 of Title 10, U.S.C., before proceeding to development and on an annual basis thereafter, for
any fiscal year in which appropriated or non-appropriated funds are expended for development
or sustainment.
b. The initial CMO certification is conducted no later than the Acquisition ATP. This can
occur either at the annual review and certification or during an out-of-cycle review and
certification.
DoDI 5000.75, February 2, 2017
Change 2, January 24, 2020
APPENDIX 4C: CMO CERTIFICATION 33
c. Annual CMO certification after the initial CMO certification is conducted before each
fiscal year in accordance with the procedures in the current DoD CMO Memorandum.
DoDI 5000.75, February 2, 2017
Change 2, January 24, 2020
APPENDIX 4D: BUSINESS SYSTEM SOLUTION DOCUMENTATION 34
APPENDIX 4D: BUSINESS SYSTEM SOLUTION DOCUMENTATION
4D.1. FUNCTIONAL REQUIREMENTS.
a. Functional requirements will be linked to inputs and outputs that define how the
functional requirements support the business processes.
b. Functional requirements will be linked to technical and lifecycle support requirements that
constrain how the functional requirements support the business process.
4D.2. POTENTIAL BUSINESS SYSTEM SOLUTION SELECTION.
a. The program manager, with support from the functional lead and the appropriate cost
agency, establishes criteria for evaluating potential business system solutions.
b. Evaluation criteria must include:
(1) Economic analysis (cost and benefit).
(2) Satisfaction of functional requirements and inputs and outputs.
(3) Satisfaction of technical requirements and lifecycle support requirements.
(4) Overall risk.
c. Other criteria may also include:
(1) Delivery schedule.
(2) Evaluation of trade space for functional requirements.
(3) Impacts to other programs.
4D.3. BUSINESS SYSTEM DESIGN SPECIFICATIONS.
a. Design specifications provide sufficient detail on the solution or service being acquired or
developed to support delivery and verification of the business system.
b. Design specifications are not a specific document. Instead, they are the content needed by
the program office to specify the design of the business system, as stored and used by the
program in whatever applicable format or repository is needed.
c. Design specifications must be prioritized to the extent practicable to allow for cost and
schedule trades within scope.
DoDI 5000.75, February 2, 2017
Change 2, January 24, 2020
APPENDIX 4D: BUSINESS SYSTEM SOLUTION DOCUMENTATION 35
4D.4. CONTENT OF BUSINESS SYSTEM DESIGN SPECIFICATIONS.
Design specifications are based upon the high-level requirements established during functional
requirement definition. This includes the functional requirements, along with associated inputs
and outputs for the functional requirements, and associated technical and lifecycle support
requirements. The detailed design includes:
a. Task-oriented description of end user interaction with the system, e.g., use cases, user
stories, or functional requirements statements expressed as functions that “the system shall”
perform.
b. Technical requirements, e.g., infrastructure, open architecture, data standards, data
management, hosting and security, and lifecycle support requirements (availability, scalability,
maintainability, supportability, and interoperability).
c. System and sub-system design, user interface design, logical and physical data models,
business rules and related architectural products.
d. Communication-oriented description of system interaction with other systems, e.g.,
interface control and interface design documents and related system architectural products.
e. Traceability mappings from requirements through design to method of verification.
DoDI 5000.75, February 2, 2017
Change 2, January 24, 2020
GLOSSARY 36
GLOSSARY
G.1. ACRONYMS.
A
CRONYM
M
EANING
aaS
as-a-service
ATP
authority to proceed
BCAC
BCAT
BEA
Business Capability Acquisition Cycle
Business system category
Business Enterprise Architecture
CAE
CCA
CIO
Component Acquisition Executive
Clinger-Cohen Act
chief information officer
CMO
COTS
chief management officer
commercial off-the-shelf
DoD CIO
DoD Chief Information Officer
DoD CMO
DoDI
Chief Management Officer of the Department of Defense
DoD instruction
DOT&E
Director, Operational Test & Evaluation
FYDP
Future Years Defense Program
GOTS
government off-the-shelf
IT
information technology
MDA
MILDEP
Milestone Decision Authority
Military Department
RFP
request for proposal
T&E
test and evaluation
U.S.C.
United States Code
USD(A&S)
Under Secretary of Defense for Acquisition and Sustainment
G.2. DEFINITIONS.
These terms and their definitions are for the purpose of this issuance.
DoDI 5000.75, February 2, 2017
Change 2, January 24, 2020
GLOSSARY 37
T
ERM
D
EFINITION
baseline
A reference against which to measure progress of the business
capability. Will be included in the capability implementation plan
and will be used to measure cost, schedule and performance (in
addition to other desired measures). Measurement will begin during
the acquisition, testing, and deployment phase and continue through
capability support. The baseline can be measured at the program
level or release level to support agile implementation, i.e., a program
can carry multiple baselines.
business capability
A business capability is the core ability the organization needs to
deliver requisite products and services and provide value. An
example of a business capability is “just in time” inventory
management. This capability is different from other types of
inventory management in that it optimizes resources to minimize
shelf time in specific locations of the supply chain.
business enterprise
architecture
The business enterprise architecture is a blueprint to guide the
development of integrated business processes within DoD. It
includes architectural viewpoints that display: capabilities, activities,
processes, data, information exchanges, business rules, system
functions, services, system data exchanges, technical standards,
terms, and linkages to laws, regulations and policies.
business system
Business systems are information systems that are operated by, for,
or on behalf of the Department of Defense, including: financial
systems, financial data feeder systems, contracting systems, logistics
systems, planning and budgeting systems, installations management
systems, human resources management systems, and training and
readiness systems. A business system does not include a national
security system or an information system used exclusively by and
within the defense commissary system or the exchange system or
other instrumentality of the DoD conducted for the morale, welfare,
and recreation of members of the armed forces using non-
appropriated funds.
change management
Change management is the process of proactively preparing the user
community for changes that will occur to an organization (because of
the implementation of a business system, for purposes of this
issuance).
cyber resilience
An entity’s ability to continuously deliver the intended outcome
despite adverse cyber events.
DoDI 5000.75, February 2, 2017
Change 2, January 24, 2020
GLOSSARY 38
T
ERM
D
EFINITION
decision authority
The individual whose decision allows the program to move forward
in the BCAC process.
deployment
A deployment either introduces a new release into the production
environment or expands the user base of existing functionality.
Deployment includes training and business systems operations
activities such as help desk support.
end state
An end state is a goal to achieve within the context of the business
mission area
information
requirements
Those pieces of information, organized and delivered in a way that
the program sees fit, that decision authorities need to make informed
decisions throughout the BCAC process.
IT infrastructure
IT infrastructure is the supporting hardware, software,
communication, and information security services that a business
system requires to operate, but that can be shared by multiple
business systems for scalability.
lifecycle support
requirements
Lifecycle support requirements are requirements for availability,
scalability, maintainability, supportability, and other requirements as
appropriate for the specific initiative.
MDA
The MDA is the program decision authority and specifies the decision
points and procedures for assigned programs.
program manager
The qualified subject matter expert who has responsibility for
development, operations, and maintenance of the business system.
The MDA will establish procedures to identify these personnel and
standards by which they manage their programs.
release
A release is a manageable subset of functionality that provides utility
in support of the engineered business processes.
technical
requirements
Technical requirements are requirements for infrastructure, hosting,
security and lifecycle support requirements.
DoDI 5000.75, February 2, 2017
Change 2, January 24, 2020
REFERENCES 39
REFERENCES
Chief Management Officer Policy Memorandum, “Defense Business Systems Investment
Management Process Guidance,” June 26, 2018
Defense Acquisition University, “Cybersecurity Test and Evaluation Guidebook,” current edition
Deputy Secretary of Defense Memorandum, “Reorganization of the Office of the Deputy Chief
Management Officer,” July 11, 2014
Deputy Secretary of Defense Memorandum, “Establishment of the Office of the Under Secretary
of Defense for Research and Engineering and the Office of the Under Secretary of Defense
for Acquisition and Sustainment,” July 13, 2018
Director, Operational Test & Evaluation Policy Memorandum, “Cyber Economic Vulnerability
Assessments (CEVA),” April 5, 2018
Director, Operational Test & Evaluation Policy Memorandum, “Guidelines for Operational Test
and Evaluation of Information and Business Systems,” September 14, 2010
DoD Directive 5000.01, “The Defense Acquisition System,” May 12, 2003, as amended
DoD Directive 5105.53, “Director of Administration and Management (DA&M),” February 26,
2008
DoD Directive 5134.01, “Under Secretary of Defense for Acquisition, Technology, and Logistics
(USD(AT&L)),” December 9, 2005, as amended
DoD Directive 5144.02, “DoD Chief Information Officer (DoD CIO),” November 21, 2014, as
amended
DoD Directive 5105.82, “Deputy Chief Management Officer (DCMO) of the Department of
Defense,” October 17, 2008
DoD Instruction 5000.02T, “Operation of the Defense Acquisition System,” January 7, 2015, as
amended
DoD Instruction 5000.74, “Acquisition of Services”, January 5, 2016, as amended
DoD Instruction 7041.03, “Economic Analysis for Decision-making,” September 9, 2015
DoD Instruction 8330.01, “Interoperability of Information Technology (IT), Including National
Security Systems (NSS),” May 21, 2014, as amended
Public Law 114-92, Section 883(e), “Guidance on Acquisition of Business Systems,” November
25, 2015
Public Law 106-398, Section 811, “Acquisition and Management of Information Technology,”
October 30, 2000
United States Code, Title 10
United States Code, Title 40, Subtitle III
