DoD Business Capability Lifecycle (BCL) Guide (Draft)

DRAFT – as of 4 February 2011
Business Capability Lifecycle
(BCL)
Guide
FEBRUARY 4, 2011

FEBRUARY 2011 i
Table of Contents
Chapter 1: Introduction ................................................................................................................ 1
Business Capability Lifecycle (BCL) Background and Overview......................................................1
Authority....................................................................................................................................................1
Tenets.........................................................................................................................................................2
Document Purpose and Scope...............................................................................................................2
BCL Applicability .....................................................................................................................................3
Governance ...............................................................................................................................................4
Phases (Overview)....................................................................................................................................5
BCL Terminology..........................................................................................................................6
Key Concepts............................................................................................................................................7
Incremental Approach..................................................................................................................7
Incremental Implementation Timelines.....................................................................................7
Enterprise Risk Assessment Methodology (ERAM)................................................................8
Business Process Reengineering (BPR)......................................................................................8
BCL Information Requirements and Support .....................................................................................9
Documents .....................................................................................................................................9
Process Support.............................................................................................................................9
Chapter 2: Roles and Responsibilities.......................................................................................... 11
DoD Component – Level.....................................................................................................................11
Chief Management Officer (CMO) ..........................................................................................11
Component Acquisition Executive (CAE)..............................................................................11
Component Pre-Certification Authority (PCA)......................................................................11
Functional Sponsor .....................................................................................................................11
Program Manager (PM)..............................................................................................................11
Office of the Secretary of Defense (OSD) – Level...........................................................................12
Certification Authorities (CAs)..................................................................................................12
Defense Business System Management Committee (DBSMC)............................................12
Director, Cost Assessment and Program Evaluation (DCAPE)..........................................12
Director, Defense Research and Engineering (DDR&E).....................................................12
Director, Developmental Test and Evaluation (DDT&E) ...................................................12
Director, Operational Test and Evaluation (DOT&E) .........................................................12
Director, Systems Engineering (DSE)......................................................................................12
DoD Chief Information Officer (CIO) ...................................................................................13
DoD Deputy Chief Management Officer (DCMO)..............................................................13
Enterprise Risk Assessment Methodology (ERAM) Team...................................................13

FEBRUARY 2011 ii
Investment Review Boards (IRBs)............................................................................................13
IRB Chair .....................................................................................................................................13
Milestone Decision Authority (MDA)......................................................................................13
Chapter 3: BCL Process .............................................................................................................. 14
Overview..................................................................................................................................................14
Business Capability Definition (BCD) Phase.....................................................................................14
Overview .....................................................................................................................................14
Key Phase Activities....................................................................................................................15
Investment Management (IM) Phase ..................................................................................................19
Additional Phase Considerations ..............................................................................................21
Execution Phase .....................................................................................................................................22
Summary .....................................................................................................................................22
Key Execution Phase Activities.................................................................................................24
Prototyping..............................................................................................................................................24
Key Prototyping Phase Activities..............................................................................................24
Engineering Development....................................................................................................................26
Key Engineering Development Phase Activities....................................................................26
Limited Deployment..............................................................................................................................27
Key Limited Deployment Phase Activities..............................................................................27
Full Deployment.....................................................................................................................................28
Key Full Deployment Phase Activities.....................................................................................28
Operations & Support (O&S) ..............................................................................................................28
Key O&S Phase Activities..........................................................................................................29
Other Key Execution Phase Activities................................................................................................29
Chapter 4: BCL Business Case..................................................................................................... 31
Overview..................................................................................................................................................31
Business Case Content...........................................................................................................................32
Executive Summary.....................................................................................................................32
Problem Statement......................................................................................................................33
Business Case Analysis................................................................................................................33
Acquisition Plan...........................................................................................................................35
Test Plan .....................................................................................................................................35
Chapter 5: BCL Program Charter.................................................................................................. 36
Overview..................................................................................................................................................36
Program Charter Content......................................................................................................................36
Mission Statement .......................................................................................................................36
Program Organization ................................................................................................................36
Resource Management Plan.......................................................................................................36

FEBRUARY 2011 iii
Governance Framework.............................................................................................................37
Implementation Methodology...................................................................................................37
Program Standards ......................................................................................................................37
Chapter 6: Metrics ..................................................................................................................... 38
Overview..................................................................................................................................................38
Appendix A: References .............................................................................................................. 43
Appendix B: Roles and Responsibilities ........................................................................................ 44
Appendix C: Glossary .................................................................................................................. 50
Appendix D: Acronyms................................................................................................................. 54

FEBRUARY 2011 1
Chapter 1: Introduction
Business Capability Lifecycle (BCL) Background and Overview
In October 2009 the National Defense Authorization Act (NDAA) for Fiscal Year 2010
(Reference (a)) was signed into law. Section 804 of the NDAA directed the Secretary of
Defense (SecDef) to develop and implement a new acquisition process for Information
Technology (IT) systems based on recommendations in chapter 6 of the March 2009 report
of the Defense Science Board (DSB) Task Force (Reference (b)). The DSB report found that
the conventional Department of Defense (DoD) acquisition process, instantiated in DoD
Instruction (DoDI) 5000.02 (Reference (c)), is too long and too cumbersome to fit the needs
of the many IT systems that require continuous changes and upgrades. Implementation of
the Business Capability Lifecycle (BCL) is the first step in responding to Section 804 of
Reference (a).
BCL is tailored for the rapid delivery of enterprise business capability. It combines multiple,
disjointed oversight processes into a single process. It recognizes that technology rapidly
evolves and changes, and consequently, BCL mandates rapid capability delivery – within
eighteen months or less of program initiation. BCL is outcome-based, and modeled on best
commercial practices. The process allows for the fact that not all solutions are purely
technical. The entire DOTMLPF (Doctrine, Organization, Training, Materiel, Leadership
and education, Personnel and Facilities) spectrum of potential solutions are considered.
BCL leverages tools, technology and process efficiencies including; the Business Enterprise
Architecture (BEA), Enterprise Transition Plan (ETP) and Investment Review Board (IRB)
processes as codified in title 10, United States Code (U.S.C.) (Reference (d)). The objective is
to timely bring the right information to the right people at the point of decision-making,
without a traditional abundance of paperwork normally required to inform investment
decisions.
The catalyst of BCL is the identification of a business need. This business need is analyzed
and matured into a Problem Statement, a desired outcome, a “To-Be” re-engineered
business process, and a set of metrics to show how success will be measured. This business
need is then compared to DOTMLPF solution sets, each based upon the business enterprise
architecture, end-to-end business processes, and the priorities established in the
Department’s Strategic Management Plan (SMP) (Reference (e). Once a DOTMLPF
solution has been selected, an implementation plan is developed for all aspects to include the
technology to be used and the acquisition of the technology. This plan is then executed
within the BCL oversight framework, concurrently with the other DOT_LPF aspects, until
the business need is solved to the satisfaction of the user.
Authority
BCL aligns DoD Defense Business System (DBS) requirements, investment, and acquisition
processes under a single governance framework founded on the principle of tiered

FEBRUARY 2011 2
accountability. This governance framework delegates authority and accountability for
program outcomes and compliance to the appropriate levels.
Requirements: The Chairman of the Joint Chiefs of Staff Instruction (CJCSI) 3170.01g “Joint
Capabilities Integration and Development System (JCIDS) (Reference (f))” states that DBSs
will use BCL and employ the BCL Business Case rather than JCIDS documents to justify the
need for a solution, and that in the case where joint oversight of the DBS is required, the
Business Case will be reviewed in lieu of the appropriate JCIDS documents.
Investment: Directive-Type Memorandum (DTM) 08-020, “Investment Review Board (IRB)
Roles and Responsibilities” (Reference (g)) states that oversight for investment and
acquisition reviews are aligned under the IRB and Defense Business System Management
Committee (DBSMC) governance structure established by sections 2222 and 186 of
Reference (d).
Acquisition: On November 15, 2010, USD (AT&L) Dr. Ashton Carter issued BCL Interim
Acquisition Guidance for DBS (Reference (h)). It requires the use of the BCL model as the
acquisition process for DBS and assigns responsibilities and provides procedures for meeting
BCL and DBS requirements pending formal issuance of a DTM. As of the issuance of
Reference (e) and this document, the DTM is in formal coordination.
Tenets
Six major tenets guide BCL:
1. Rapidly deliver capability to the end-user.
2. Focus the Program Manager (PM) on program execution, not on program
justification.
3. Enable timely decision making while reducing bureaucracy.
4. Base acquisition decisions on comprehensive and appropriate information.
5. Allow acquisition-related decisions to be made at the lowest level possible.
6. Allow for flexibility in program implementation strategies.
Document Purpose and Scope
This guide provides a consistent approach for user engagement with BCL. Although the
scope of this document encompasses the complete lifecycle of a business capability, it
focuses heavily on the acquisition-related portions and the content of the Business Case and
the Program Charter. This includes the roles and responsibilities of those involved
throughout the process, the phases of BCL acquisition, and the information requirements
across those phases. It serves as a BCL reference to support all DoD staff responsible
throughout a DBS’s lifecycle. This guide is intended for Office of the Secretary of Defense
(OSD) or DoD Component personnel responsible for, accountable for, contributing to,
and/or supporting the development of DBSs,
The goal of this document is to help the following people understand BCL’s purpose, intent,
and outcomes through each of its phases:

FEBRUARY 2011 3
• Functional Sponsors
• Chief Information Officers (CIOs)
• Chief Management Officers (CMOs)
• PMs
• Program Executive Offices (PEOs)
• Acquisition Executives
• DoD IRB membership and leadership
• Other stakeholders
This guide addresses roles, responsibilities, and information requirements for DBS Major
Automated Information Systems (MAIS) and below. This document does not apply to
MAIS MDAPs. In the case of a DBS MAIS MDAP, the process shall incorporate not only
the requirements of BCL, but also all applicable MDAP-related statutory and regulatory
requirements.
All DBS entering in the IRB Process, whether for certification or acquisition review, must
comply with this Guide. DoD Components are responsible for their internal processes and
procedures in order to comply with this guidance. While this BCL Guide does not prescribe
DoD Component processes and procedures or establish policy, Components shall utilize
sound program management practices, understanding that the IRB reserves the right to
request additional information to resolve any issues raised during an investment review.
This Guide is to be used in conjunction with “DoD IT Defense Business Systems
Investment Review Process: Guidance,” January 2009 (henceforth “IRB Guidance”)
(Reference (i)), which describes the investment review processes associated with BCL.
BCL Applicability
BCL applies to all defense business capabilities with lifecycle modernization costs over $1M.
These capabilities must obtain obligation authority in the form of certification from the
IRB/DBSMC in order to obligate modernization funds per section 2222 of Reference (d).
The level of oversight and subsequent governance required for BCL acquisition activities
depends on the cost of the DBS.
• The MDA for MAIS and MDAP is either the USD (AT&L) or is delegated to the
DoD Deputy Chief Management Officer (DCMO).
• Below the MAIS threshold, MDA is normally delegated to the Component
Acquisition Executive (CAE) or designee.
For DBSs that do not meet the MAIS threshold, DoD Components are expected to
establish or employ decision bodies with similar responsibilities as stated in Reference (d).
PMs for DBSs currently in the acquisition process should consult with their CAE and
/ or MDA to develop a plan to transition their program to BCL.

FEBRUARY 2011 4
Governance
BCL incorporates the oversight requirements of three different DoD investment and
acquisition processes into a single governance framework:
• JCIDS, per Reference (f);
• The IRB and DBSMC processes established by sections 2222 and 186, of Reference
(d) and described in References (g) and (i); and
• DoD Instruction 5000.02, “Operation of the Defense Acquisition System”,
December 8, 2008 Reference (c);
The IRB / DBSMC process provides a governance and oversight framework for effective
investment decision-making, enabling the Department’s senior leadership to guide
investments to maximize the impact to the Warfighter. As an integral part of this governance
framework, the IRBs are responsible for overseeing the investment review process for
business capabilities that support activities in their designated areas of responsibility and
supporting the DBSMC. Each IRB assesses investments relative to their functional needs, as
well as the impact on end-to-end business process improvements as guided by the BEA,
articulated in the ETP, and described in Component architectures and transition plans.
These products provide both the end-state and the roadmap to deliver more robust business
capabilities.
For MAIS and MDAP, the IRBs review requirements changes and technical configuration
changes during the development process that have potential cost and schedule impacts on
the program. Such changes will generally be disapproved or deferred to future increments
and will not be approved unless funds are identified and schedule impacts mitigated.
The DBSMC is chaired by the Deputy Secretary of Defense (DepSecDef) and has direct
participation of top leadership of each DoD Component. The DBSMC guides the
Department in developing and implementing integrated business functions and capabilities.
The DBSMC is the final approval authority for all certification decisions.
The MDA is responsible for making DBS acquisition decisions and relies on information
provided by the Component to include functional requirements; the Business Case;
appropriate BPR and BEA compliance (as determined by the Component CMO/DoD
DCMO); and a DBSMC-approved investment decision.

FEBRUARY 2011 5
Figure 1 depicts the single integrated decision-making framework that provides business
capability investment, acquisition oversight, and DBS development and deployment.
Throughout the lifecycle of a DBS, the DBSMC has final authority over investment
decisions, while the MDA has overall responsibility for DBS acquisition decisions. The IRBs
provide the central support structure which integrates the investment and acquisition reviews
into one process, while supporting both the DBSMC and the MDA simultaneously.
Figure 1: Integrated BCL Governance
Phases (Overview)
BCL is comprised of three distinct Phases: Business Capability Definition (BCD),
Investment Management (IM), and Execution (the acquisition portion of BCL).
Conceptually, BCL encompasses more than just the acquisition of a DBS; it weaves together
all DOTMLPF to deploy a stand-alone business capability. Oversight, acquisition and
investment management activities are all integrated in the BCL Acquisition Business Model,
as depicted in Figure 2:
Defense Business Systems
Management Committee
(DepSecDef)
Investment Decisions
MDA
USD(AT&L) / DoD DCMO
Acquisition Decisions
DoDDCMO
Combined IRB for Acquisition
Functional Sponsor
Enterprise/Component
USD(C), (P&R), (AT&L); DoD CIO
PSAs / CAs
Investment Review Boards (IRBs)Investment Review Boards (IRBs)
Certification & Review
Financial Management (FM)
Human Resources Management (HRM)
Weapon Systems Lifecycle Management / Materiel
Supply & Services Management (WSLM / MSSM)
Real Property & Installations Lifecycle Management
(RPILM)
Other IT Business Systems (DoDCIO)

FEBRUARY 2011 6
Figure 2: BCL Acquisition Business Model
BCL Terminology
The terms used to reference the stages of a DBS may vary throughout its lifecycle based on
its level of maturity. The terms generally used are business need, proposed DOTMLPF solution,
materiel solution, program, and DBS, as depicted in Figure 3 with the corresponding BCL
phases:
Figure 3: BCL DBS Terminology
Business Capability Definition (BCD) Phase: The BCD Phase of BCL consists of analyzing a
perceived business need, determining its root cause, conducting initial business process
reengineering (BPR), developing high-level solution recommendations, and documenting the
results of that analysis in a clearly defined and scoped Problem Statement.
Investment Management (IM) Phase: During the IM Phase, the analysis conducted during
the BCD Phase expands in order to refine the solution scope, identify alternatives, propose a
materiel solution, and define the parameters of the proposed materiel solution and
BusinessNeed Program
Defense BusinessSystem
Proposed
DOTMLPFSolution MaterielSolution

FEBRUARY 2011 7
operation. In this phase, the DoD Component develops a defendable and justifiable
Business Case and Program Charter.
Execution Phase: The BCL Execution Phase is supported by the BCL Acquisition Business
Model and consists of Prototyping, Engineering Development, Limited Deployment, Full
Deployment, and Operations & Support.
Prototyping reduces risk by refining the materiel solution described in the Business
Case. It tests the capability and the software in a development environment against
user requirements and business process reengineering requirements as outlined in the
Business Case.
Engineering Development builds the materiel solution and validates its consistency with
the approved Business Case and Program Charter through developmental and
operational testing.
Limited Deployment involves delivering the materiel solution to a limited number of
users and conducting Initial Operational Test and Evaluation (IOT&E).
Full Deployment fields the materiel solution to the user community in accordance with
the Business Case.
Operations and Support (O&S) consists of sustaining the program or program
increment over its total life cycle. Any modernizations on a program or program
increment in O&S are subject to IRB review requirements and processes as
described in References (d) and (e).
Key Concepts
Incremental Approach
An incremental approach to acquisition facilitates development and implementation. It
encourages delivery of IT business capability in discrete, fully-funded, and manageable
increments. This approach quickly puts capability into the hands of the user while balancing
DoD Enterprise needs, priorities, and resources. In addition, it allows room for continued
maturity as desired outcomes evolve. The success of this approach depends on the
consistent and phased definition of outcomes and the maturation of knowledge to provide
increasing capability over time. BCL requires that each increment consist of a useful and
supportable operational capability that can be developed, tested, produced, deployed, and
sustained.
Incremental Implementation Timelines
In BCL, increments are delineated by timelines which guide a DBS through capability
prototyping and deployment (depicted in Figure 3 above). For each increment:
• No more than 12 months shall normally elapse between a proposed materiel
solution’s Materiel Development Decision (MDD) and Milestone (MS) A.

FEBRUARY 2011 8
• No more than 12 months shall normally elapse between the initial contract or option
award following MS A and MS B.
• No more than 18 months shall normally elapse between contract or option award
following MS B and the Full Deployment Decision (FDD).
• The MDA shall not grant a MS A decision if Initial Operating Capability (IOC)
cannot be achieved within 5 years.
• In no event shall FDD occur later than 5 years from when funds were first obligated
for the program.
• No more than 12 months shall normally elapse between any follow-on increment’s
Authorization to Proceed (ATP) (or option award following ATP) and contract or
option award following its corresponding MS B.
It is important to take these timelines into consideration during program planning and
Business Case development. Timeline breaches and any exceptions to the rules as stated
require re-validation of the Business Case by the IRB (and the MDA, as required) and can
slow down the delivery of capability to the user or potentially result in program cancellation.
Enterprise Risk Assessment Methodology (ERAM)
BCL utilizes an independent risk assessment process, known as the Enterprise Risk
Assessment Methodology (ERAM), as one of many inputs available to the MDA for MS A
and MS B decisions. Additional ERAMs can be requested by an IRB Chair, the Certification
Authority (CA), or the MDA if there is reason to believe that there is risk with the program
that may impair its ability to deliver capability. ERAMs provide critical insight to decision
makers regarding program risks and the program’s corresponding mitigation plans. For
DBSs that do not meet the MAIS threshold, the CAE is responsible for establishing
procedures designed to assess risk aligned with the ERAM approach.
Business Process Reengineering (BPR)
BPR efforts are to be conducted in accordance with section 2222(a)(1)(B) of Reference (d)
and applicable guidance provided by the office of the DoD DCMO. In accordance with the
aforementioned statute, Component BPR efforts must, at a minimum, ensure that:
• The business process to be supported by the DBS modernization will be as
streamlined and efficient as practicable; and
• The need to tailor Commercial-off-the-Shelf (COTS) systems to meet the unique
requirements of the Department or to incorporate unique interfaces has been
eliminated or reduced to the maximum extent practicable.
The results of ongoing BPR activity, beginning during the BCD Phase, should be
incorporated into the Business Case as appropriate (or as directed by the template). More
information on BPR, to include relevant guidance and requirements and other critical
information, can be located on the DCMO’s website: http://dcmo.defense.gov/index.html.

FEBRUARY 2011 9
BCL Information Requirements and Support
BCL places focus on analysis, critical thinking, and thorough development of implementable
requirements – the information requisite for developing and successfully executing a DBS.
BCL’s iterative approach to capability delivery allows PMs to apply lessons learned to
subsequent increments, to refine requirements, and to continue to rapidly deliver capability
to the user.
Documents
Two primary documents are used throughout BCL in the governance process: the Business
Case, which includes the Problem Statement and the Program Charter. The Business Case
documents the business justification for the resolution of an existing business need. The
Problem Statement serves as the Business Case foundation, documenting the analysis of the
business need and scoping it in solvable, measurable terms. The Program Charter provides a
framework for managing the development and delivery of the materiel solution described in
the Business Case and articulates the manner in which the program will be managed.
The “BCL Business Case Template and Guide” and the “BCL Program Charter Template
and Guide” shall be used to develop a Problem Statement/Business Case and Program
Charter, respectively. The templates are purposely designed to be flexible thereby
encouraging critical thinking.
Submittal of a Problem Statement/Business Case or Program Charter for review and
approval using these templates does not guarantee approval in the BCL governance process.
Furthermore, utilizing these templates does not excuse BCL users from complying with applicable statutes
and regulations or conducting the rigorous analysis required to make business decisions.
These templates streamline previously cumbersome processes in two critical ways: (1) there
is less documentation moving through less governance and signature structures, and (2)
decision makers will see the same Business Cases and Program Charters as they are revised
and move through the process, enabling them to gain institutional program knowledge and
ensure continuity, thus reducing review time while also facilitating more robust reviews and
discussions on potential DBS investments and acquisition decisions.
Process Support
As explained in Chapter 1, the IRBs provide pivotal support structure. IRB’s integrate the
investment and acquisition reviews into one process, supporting both the DBSMC and the
MDA simultaneously. Timely submission of information is key to a successful IRB
experience. The deadline for submitting program documentation for review is no later than
30 days before a meeting of the IRB. The IRB Chairs will not accept a program that misses
this deadline.
To create process efficiencies, information is increasingly being submitted through the
Business Process Management (BPM) Automated IRB workflow process for Certification
and Acquisition decisions.

FEBRUARY 2011 10
The BPM is administered through secure Defense Knowledge Online (DKO) and MilBook
and is supported by the IRB Support Staffs. On-line training is available (and is required for
all new users).
(Step 1): DKO Account Access: https://www.us.army.mil/
(Step 2): MilBook Account Access: https://gft.kc.us.army.mil/login/
(Step 3): Visit the BPM Group and Join:
https://www.kc.army.mil/book/groups/acquisition-automation-bpm-training-group
(Access to training and the BPM).

FEBRUARY 2011 11
Chapter 2: Roles and Responsibilities
DoD officials and organizations have specific investment and acquisition related roles and
responsibilities to fulfill throughout BCL. Roles and responsibilities are summarized at a high
level below, while more detailed roles and responsibilities broken down by BCL Phase are
available in a table in Appendix B. Many of these officials and organizations also have
complimentary roles and responsibilities specific to the DBS investment process (i.e., IRB
Process); however, those are detailed in References (h) and (i) and are not included in this
document in extensive detail.
DoD Component – Level
Chief Management Officer (CMO)
In accordance with section 2222 of Reference (d), the CMO for each of the Military
Departments is responsible for determining that DBS investments within their area of
responsibility have adequately performed BPR activities and that their DBS complies with
the BEA.
Component Acquisition Executive (CAE)
CAEs are responsible for all acquisition functions within their Components. This includes
both the Service Acquisition Executives (SAEs) for the Military Departments and acquisition
executives in other DoD Components. The CAE designates the MDA for DBSs other than
MAIS and MDAP (or as otherwise delegated).
Component Pre-Certification Authority (PCA)
Generally, the Defense Agencies will employ PCAs in absence of their own CMOs to
complete the BEA and BPR determination process, though the Military Departments may
utilize PCAs in their internal processes as well. Generally, the PCA assesses and pre-certifies
compliance with the BEA and ensures required documentation is available for IRB review
prior to the IRB meeting. More information about the role of the PCA is available in
Reference (h).
Functional Sponsor
The Functional Sponsor is responsible for defining and managing capabilities, remaining
actively engaged in the program throughout the DBS’s lifecycle in order to achieve the
complete DOTMLPF solution, and therefore holding certain review, approval, and
decisional responsibilities such as declaring IOC and Full Deployment (FD).
Program Manager (PM)
A PM is designated during the IM Phase and is accountable for the successful development
and deployment of the DBS. It is critical that the appropriate Component authorities select
PMs with the suitable background and competency in IT solutions as well as the ability to
build and manage multi-disciplinary, integrated teams, and identify and mitigate risk.

FEBRUARY 2011 12
Office of the Secretary of Defense (OSD) – Level
Certification Authorities (CAs)
Defined in section 2222 of Reference (d) as Approval Authorities and established as CAs by
Reference (h), CAs use the IRBs to provide oversight of investment review processes and
procedures for DBSs supporting their area(s) of responsibility to advise the MDA. CAs may
serve as IRB Chairs, or may designate the IRB Chair.
Defense Business System Management Committee (DBSMC)
The DBSMC, per sections 186 and 2222 of Reference (d), provides investment oversight for
DBS and guides the transformation activities of the business areas of the Department. The
DBSMC approves both CA Certifications and CMO/DCMO BPR determinations.
Director, Cost Assessment and Program Evaluation (DCAPE)
The DCAPE generally provides independent analysis and advice and is responsible for
activities pertaining to Analysis of Alternatives (AoA) Study Guidance and Study Plans for
MAIS and MDAP. The DCAPE may also review and / or provide independent assessments
of cost estimates, cost analyses and economic analyses as appropriate and may conduct other
statutory duties as appropriate.
Director, Defense Research and Engineering (DDR&E)
For MDAP (if developmental non-commercial off the shelf technology is included in the
planned program), the DDR&E coordinates Technology Readiness Assessments (TRAs)
with the appropriate DoD Component Science and Technology (S&T) representatives.
Director, Developmental Test and Evaluation (DDT&E)
The DDT&E establishes a proactive program oversight process that ensures the appropriate
levels of systems engineering are applied through all phases of program development for
each DBS. The DDT&E works in partnership with the DOT&E to review the test plans
described in the Business Case.
Director, Operational Test and Evaluation (DOT&E)
The DOT&E is responsible for the test and evaluation of each DBS. The DOT&E works
with the Functional Sponsor and PM to ensure that roles and responsibilities, along with
required test resources, are adequately addressed with mutual agreement early on in the
process. The DOT&E also works with the DDT&E to approve the test plan described in
the Business Case.
Director, Systems Engineering (DSE)
The DSE reviews and approves the systems engineering sections of the Business Case.

FEBRUARY 2011 13
DoD Chief Information Officer (CIO)
The DoD CIO works with DoD Components, the IRBs, the DBSMC, and other
stakeholders to ensure that DBSs develop in compliance with applicable statute and
regulation and in accordance with DoD policy on architecture, design, interoperability,
security, and information assurance.
DoD Deputy Chief Management Officer (DCMO)
In accordance with section 2222 of Reference (d), the DCMO is responsible for determining
that DBS modernization investments of the Defense Agencies or that will support the
business processes of more than one military department or Defense Agency have
adequately performed BPR activities and comply with the enterprise architecture. The
DCMO may also hold delegated MDA authority for certain DBS programs and may also
serve as the Chair of governance forums to achieve necessary acquisition decisions.
Enterprise Risk Assessment Methodology (ERAM) Team
Prior to MAIS or MDAP MS A and MS B reviews, ERAM teams conduct a risk assessment
to identify risk, recommend risk mitigations to the PM, and provide insight to decision-
makers as part of the governance process.
Investment Review Boards (IRBs)
The IRBs (the Members of each IRB) generally advise the IRB Chair and the MDA and
provide cross functional expertise and oversight for DBSs. The IRBs also review Problem
Statements (for all potential DBS), Business Cases, and requirements changes / any technical
configuration changes for MAIS and MDAP in development that has the potential to impact
program cost and schedule. The IRBs also work to ensure that investments are aligned with
the BEA.
IRB Chair
In addition to reviewing all information mentioned above as a member of the IRB, the IRB
Chair has decision authority, and will therefore decide on Problem Statement approvals,
make acquisition-related recommendations to the MDA, serve as the validation authority for
DBS requirements, and hold specific duties regarding IRB Certification actions in addition to
those duties identified in References (d), (h), and (i).
Milestone Decision Authority (MDA)
The MDA for DBS is responsible for making DBS acquisition decisions as well as
determining the appropriate BCL entry / acquisition phases and the extent to which
regulatory documentation can be tailored. The MDA also receives information from the
IRB Chairs during the review process.

FEBRUARY 2011 14
Chapter 3: BCL Process
Overview
The BCL Process is described in the BCL Interim Acquisition Guidance for DBS (Reference
(g)); this Chapter gives further explanation and detail that was not provided in Reference (g).
The rest of this Guide will also delve into the content of a Problem Statement, Business
Case, and Program Charter, as well as provide a brief overview of the importance of
developing sound metrics.
Business Capability Definition (BCD) Phase
Figure 4: BCD Phase
Overview
The Functional Sponsor conducts activities in the BCD Phase which begin when the
functional community (which includes, but is not limited to, the end user, functional subject
matter experts, and/or key stakeholders) identifies a measurable business capability need,
gap, or problem (henceforth, business need) and begins root cause analysis and scope
definition. It is important to note that BCL requires the Functional Sponsor’s involvement
throughout a DBS’s entire lifecycle, but especially during root cause analysis, initial BPR, and
identification and definition of criteria and measurements for success. The Functional
Sponsor’s continued participation provides greater assurance that an investment in a
particular DBS will solve the identified business need.
The activities and analysis in the BCD Phase result in a clearly defined Problem Statement
and measurable outcomes. The foundational piece of a Business Case- the Problem
Statement - is meant to guide Business Case development and aid the IRB in determining
whether additional effort should be applied to solving an identified business need.
As noted in Figure 4, the BCD Phase occurs only one time for the entire DBS, which makes
it a critically important part of BCL. If teams or Program offices find that that key parts of
the BCD Phase are being consistently revisited and potentially revised (such as the Problem
Statement or Root Cause Analysis) it is likely that the business need was not properly / fully
analyzed in the first place, and it is not prudent to progress further through BCL without
proper revalidation of the entire Problem Statement to determine its relevance.
Close Out
Review
Operations and
Support
Business
Capability Definition
Investment
Management
Upto 12 Months
A
18 Months* MS B to IOC12 Months*
Prototyping
Engineering
Development
Acquisition Decision
Points
Limited
Deployment
IOT&E
Full
Deployment
IOC
FDD
MDD
B C
Close Out
Review
Operations and
Support
Prototyping
Engineering
Development
Limited
Deployment
IOT&E
Full
Deployment
IOC
FDD
B C
Authorization
to Proceed
Increment 2 / N

FEBRUARY 2011 15
Key Phase Activities
Problem Statement Development
The Problem Statement, and the analysis behind it, is perhaps the single most important
informational product developed during BCL. It serves as the foundation for all subsequent
analyses. Upon completion of the BCD Phase analysis, the Functional Sponsor must
document the results in a clearly defined and well-scoped Problem Statement which then
becomes the foundation of the Business Case. The IRB and the MDA use these results to
determine whether or not a materiel solution should be pursued. A Problem Statement is
mandatory for all identified business needs involving non-materiel and/or materiel solutions.
The Problem Statement must include:
• The context of the business need (such as the organization’s operating environment
and mission);
• The business need, stated and defined within the context;
• The root cause of the business need;
• Business need boundaries (organizational, functional, infrastructure);
• Results of the DOTMLPF analysis and impact on the status quo;
• Explanation of the “to-be” business process that will address the business need and
create efficiencies;
• The operational improvement(s) and measurable outcomes derived from addressing
the business need;
• Constraints and assumptions affecting any solution to the business need;
• Recommended potential solutions for future investigation; and
• Rough order of magnitude (ROM) cost estimate for any potential solution that
entails a materiel solution.
Root Cause and Doctrine, Organization, Training, Materiel, Leadership and Education,
Personnel, and Facilities (DOTMLPF) Analysis
In order to develop a clearly defined Problem Statement, a root cause and DOTMLPF
analysis must be conducted.
Once a business need has been identified, the Functional Sponsor, in collaboration with the
functional community, must lead a thorough analysis to determine the root cause of the
identified business need. It is imperative that this analysis be conducted as extensively and
thoroughly as possible. This aids the functional community in understanding and scoping
the business need at a level at which it can be solved (i.e., one can’t “boil the ocean” or
“solve world hunger”). It also ensures the reliability of the information in the Problem
Statement. In the process of root cause analysis, the functional community will typically:
• Assemble evidence (historical performance statistics, funding trends, audit reports);
• Compare key pieces of information and look for relationships or patterns (industry
benchmarks, mission-area outcome goals, same or similar functions);

FEBRUARY 2011 16
• Quantify various courses of action (consequences of continuing with status quo,
expected effects after the status quo is changed)
It is critically important that after root cause analysis is deemed complete, what results is
actually a root cause or the root causes, rather than symptoms or aggravating factors of a
root cause. A common simple technique to use is “the 5 Whys”, in which a root cause of the
business need is proposed and decomposed by asking “Why”, repeatedly, until the
underlying root cause is reached. It is important to try and remove as much bias and
assumption from the analysis process and often, utilization of “the 5 Whys” leads to
business processes, people processes, or behaviors as the root causes of the business need.
After identifying the root cause of the business need, a DOTMLPF framework-based
analysis of the business need must be conducted. This analysis determines whether the
business need can be completely solved without a materiel solution. If not, it identifies,
from the user’s perspective, the requirements to satisfy the business need.
Although there is no universally accepted framework for conducting a DOTMLPF analysis,
it may be valuable to establish an internal or DoD Component standard. However, the
analysis must, at a minimum, address the following questions:
• Is there existing doctrine that addresses the business need or relates to the business
need?
• Is the root cause a result of a lack of training or of generally inadequate training?
• Do the senior officials understand the scope of the root cause?
• Is the issue caused, at least in part, by inability or decreased ability to place qualified
and trained personnel in occupational specialties?
As a result of the root cause and DOTMLPF analyses, the Functional Sponsor must develop
initial solution options (materiel and / or non-materiel); define specific, measurable
objectives and outcomes; and identify metrics for measuring how well the business need has
been satisfied (i.e., “what good looks like”). This must be established before BCD phase
activities proceed.
Preparing the Problem Statement for the IRB
It might be helpful to think of the Problem Statement as a question that needs to be
answered in six parts, using the following considerations:
1. What is the business need?
Express the business need in a manner that is specific, testable, and (where possible)
quantitative in nature.
2. Who is affected by the business need?
Provide a clear and specific context so that decision makers will understand where
the business need falls within the DoD Component environment and the DoD
Enterprise, as applicable.

FEBRUARY 2011 17
3. What is the root cause of the business need?
Present analytic or statistical evidence to prove that the root cause of the business
need has been reliably identified.
4. Why is the business need worth solving?
Describe the impact of the business need on the current and future strategic and
business operating environment in specific, quantitative terms.
5. What are the recommended potential solutions and benefit(s) of solving the
business need?
Recommend potential solutions for solving the business need and provide the
specific intended benefit(s) of doing so.
6. How will we know the business need has been solved?
Identify operational metrics that can be used to measure progress towards success,
and describe high-level outcomes in measurable terms1
1) Does the Problem Statement concisely and convincingly demonstrate that the
business need exists and merits solving?
. Identify “what good looks
like” so the end is not a consistently moving target.
Prior to submitting the Problem Statement to the IRB for review, the Functional Sponsor
shall determine whether the following questions have been adequately answered:
2) Have extensive root cause and DOTMLPF analyses been performed?
3) Have external influences been identified?
4) Have specific and measurable success factors been defined and agreed upon among
the functional and stakeholder community?
5) Does the Problem Statement present a valid case to prove that the identified
business need warrants investment?
6) Do the BPR efforts result in enough streamlining and efficiencies to warrant
investment?
Problem Statement Review and Approval
IRBs review all Problem Statements falling within their respective functional area. If the
Problem Statement recommends a course of action that requires a non-MAIS materiel
solution, the DoD Component is responsible for managing it through its acquisition
processes.
The Functional Sponsor shall submit the Problem Statement to the IRB for review and
approval through the appropriate CMO. The submission must occur at least 30 days prior to
the date of the IRB meeting at which the Functional Sponsor will present the Problem
Statement. Each IRB, per Reference (i), publishes information submittal deadlines based on
their individual meeting schedules.
1
This information will be documented in the Business Case and reported through the BPR Assessment Process (BPR Checklist). See
the DCMO Website for more information: http://dcmo.defense.gov/

FEBRUARY 2011 18
After the Problem Statement has been submitted, the IRB Support Staff coordinates its
review with the members of the IRB (which includes Joint Staff), appropriate partner IRBs,
and functional subject matter experts. This coordinated review negates the need for the
Functional Sponsor to coordinate separately with OSD and Joint Staff stakeholders. Each
IRB consists of representatives from various OSD organizations and represents a virtual
“one stop shop” for review and approval of BCL information, allowing for more efficient
and streamlined oversight.
If information is missing or other issues arise during this coordinated Problem Statement
review, the IRB Support Staff facilitates resolution by returning the submission to the DoD
Component using the Issue Paper process detailed in IRB Guidance. Once the identified
issues have been resolved and the Problem Statement has been re-submitted, the Problem
Statement moves forward in the review process.
BCD Phase Decisions and Exit
During IRB review the IRB Chair, with the advice of the IRB members and stakeholders:
• Approve the Problem Statement Disapprove the Problem Statement; or
• Direct that the Problem Statement be re-worked and re-submitted for approval,
which is done in accordance with direction provided by the IRB Chair.
• Determine if a non-materiel solution is warranted
If the IRB agrees that a non-materiel solution may address all or part of the business need,
the Functional Sponsor coordinates and tracks its resolution and periodically reports on
progress made on the implementation of that solution to the IRB, as directed by the IRB
Chair. For non-materiel solutions impacting the Department, IRBs may, at the IRB Chair’s
discretion, forward their recommendation to the appropriate Principal Staff Assistant (PSA),
CMO, DCMO, or even DBSMC for consideration.
Analysis of Alternatives (AoA) Guidance
Within thirty (30) days of the IRB Chair approving the Problem Statement:
• For DBS that do not meet the MAIS thresholds, the DoD Component equivalent of
DCAPE will prepare, approve, and submit AoA Study Guidance in accordance with
the DoD Component's acquisition process.
• For MAIS and MDAP, the DCAPE approves AoA Study Guidance and submits it
to the IRB Chair.
The BCD phase ends when the IRB Chair approves the Problem Statement and approved
AoA Study Guidance is approved and submitted it to the IRB Chair.

FEBRUARY 2011 19
Investment Management (IM) Phase
Figure 5: IM Phase
Summary
The IM Phase justifies the most efficient fulfillment of a business need based on analysis of a
well developed Business Case and Program Charter. The IM Phase begins at the MDD,
which is mandatory for all DBS. For those proposed materiel solutions that do not meet the
MAIS thresholds, similar activity will occur at the appropriate DoD Component level. At the
MDD, the Functional Sponsor presents the business need as described in the IRB-approved
Problem Statement and the DCAPE (or, for DBS that do not meet the MAIS thresholds,
the DoD Component equivalent) presents the AoA Study Guidance to the MDA for
consideration. The MDA decision, documented in an Acquisition Decision Memorandum
(ADM) to which the AoA Study Guidance will be attached, specifies the acquisition entry
phase for the proposed materiel solution and designate the next milestone review. A MS A
review shall be scheduled to occur within twelve (12) months of MDD approval unless the
ADM instructs otherwise.
At the end of the IM Phase, the Business Case, the Program Charter, and appropriate IRB
certification documentation as outlined in Reference (i) are submitted to the IRB for MS A
decision review and IRB certification of modernization funds. The IRB forwards its
certification recommendation to the DBSMC for certification approval and its MS A
recommendation to the MDA for a MS A decision.
As noted in Figure 5, the IM Phase occurs one time for the entire DBS, which makes it a
critically important part of BCL. There are, however, multiple opportunities for IRB
certification and review for the DBS outside of the IM Phase.
Key Phase Activities
During the IM Phase, the scope of the proposed materiel solution, solution options, cost,
implementation schedule, and the acquisition approach are analyzed, refined, and
documented in a Business Case. In addition, the Program Charter documents the roles and
responsibilities, methods, processes and procedures for managing, measuring, and
controlling the proposed materiel solution’s implementation.
Close Out
Review
Operations and
Support
Business
Investment
Management
Upto 12 Months
A
Prototyping
Engineering
Development
Points
Limited
Deployment
IOT&E
Full
Deployment
IOC
FDD
MDD
B C
Close Out
Review
Operations and
Support
Prototyping
Engineering
Development
Limited
Deployment
IOT&E
Full
Deployment
IOC
FDD
B C
Authorization
to Proceed
Increment 2 / N

FEBRUARY 2011 20
Business Case Development
Upon receiving MDD approval from the MDA, the Functional Sponsor and the PM jointly
develop the expansion of the Problem Statement into a Business Case. Three components of
the Business Case must be addressed in the IM Phase (see Chapter 4 for more detail on
contents):
1. Business Case Analysis, including the AoA and Program Justification
2. Acquisition Approach
3. Test Plan
The BCL Business Case is an evolving, executive-level document that reflects program
planning and includes summaries of the information identified in Tables 1-3 of Attachment
3 of Reference (g) i.e., summaries do not substitute for the completion of detailed and
rigorous analysis required for such summaries or conclusions; documentation of detailed
analysis should be made available to the MDA and/or IRB Chair upon request.
It is critical that any relevant test community stakeholders are involved early and up-front in
the process of developing a test plan. Collaboration with the test community early in the
process will ensure a more robust, streamlined, and effective process. In addition, plans to
become BEA compliant should be integrated as appropriate. More information on BEA
Compliance is located in the “DoD Business Enterprise Architecture Compliance
Guidance”, Reference (j).
For an initial program increment, the Business Case must demonstrate an implementation
timeline that provides a maximum of twelve (12) months from initial contract or option
award following MS A to MS B.
ERAM Assessment
A MS A ERAM assessment must commence at least 90 days prior to the date at which the
Functional Sponsor will present the MS A Package detailed below to the IRB. The PM must
notify the ERAM lead no later than 120 days prior to that date to schedule the ERAM. The
ERAM team in collaboration with the PM and the Functional Sponsor develops the ERAM
findings and jointly presents the results to the IRB and the MDA prior to the MS A decision.
IRB Review and Approval
The IRBs and the DBSMC maintain oversight of the investment activities occurring
throughout BCL. During the IM Phase, the DoD Component submits information required
in Reference (i) to obtain the appropriate IRB certification and DBSMC approval of
modernization funds.
When the Functional Sponsor determines that enough information has been acquired and
the Business Case reaches a level of detail sufficient to obtain a MS A decision, the
Component prepares a MS A Package that includes the following documents:
• A Business Case, including:
o DOT&E and DDT&E joint approval of the Test Plan;

FEBRUARY 2011 21
o DSE approval of the Systems Engineering section; and
o CAE signature
• A Program Charter approved by the CAE;
• DBSMC approval to obligate modernization funds;
• A memorandum from the CAE to the MDA (CAE Compliance Memo): certifying
that the proposed materiel solution complies with all applicable statutory and
regulatory requirements; describing any issues related to the requested Milestone
decision; and recommending MDA approval of the MS A request;
• A completed ERAM Assessment and risk mitigation plan;
• Any additional documentation required to comply with statutory and regulatory
requirements for MS A.
Once complete, MS A Package is submitted to the IRB. The IRB Support Staff coordinates
a review with the members of the IRB (which includes Joint Staff), appropriate partner
IRBs, and functional subject matter experts. The ERAM team briefs detailed findings to the
MDA and the IRB Chair. This coordinated review negates the need for the Functional
Sponsor to coordinate separately with OSD and Joint Staff stakeholders.
If information is missing or other issues arise during this coordinated review, the IRB
Support Staff facilitates a resolution by returning the submitted MS A Package to the DoD
Component using the Issue Paper process detailed in Reference (i). Once the identified
issues are been resolved, the review process continues.
IM Phase Decisions and Exit
During the IRB review, the IRB Chair, with the advice of the IRB members and
stakeholders:
• Reviews the Business Case;
• Provides a MS A recommendation to the MDA, and
• If necessary, recommends certification and DBSMC approval of the materiel
solution’s request for modernization funds.
The MS A recommendation to the MDA includes the alternative positions presented to the
IRB Chair by the IRB Members and other appropriate stakeholders.
The IM Phase ends when the IRB Chair forwards the MS A recommendation to the MDA
as part of the IRB-approved MS A Package.
Additional Phase Considerations
In addition to preparation of MS A decisional materials, other required critical activities
(such as BPR) occurring during the IM Phase remain essential to the success of the
proposed material solution. These activities, and those individuals/organizations responsible
for their execution, are identified in Appendix B, and specific Business Case content is
outlined in Chapter 4. More information on BPR, to include relevant guidance and
requirements and other critical information, can be located on the DCMO’s website:
http://dcmo.defense.gov/index.html.

FEBRUARY 2011 22
IRB review of a materiel solution’s certification request is not a pre-requisite for review of
that materiel solution’s MS Package, or vice versa – the IRB can review these requests
concurrently. However, DBSMC approval of the IRB certification is required before the
MDA may consider a milestone (MS A or MS B) request for the materiel solution, as
described in References (c) and (g).
It is important to note that if IM Phase activities exceed 12 months from the signature date
of the MDD ADM, the IRB Chair reviews the business need and advises the MDA whether
the IM Phase activities should be terminated.
Execution Phase
Figure 6: Execution Phase
Summary
The Execution Phase (Figure 6) begins when the MDA approves the Business Case and
documents the decision in a MS A ADM and funds certification provided. During this
Phase, each increment of the materiel solution documented in the Business Case is designed,
developed, tested, and deployed into initial and production environments, in accordance
with the Business Case and the Program Charter. Eventually, the DBS is also sustained and
disposed of. Table 1 summarizes each of these phases:
Phase High-level description
Prototyping • A materiel solution’s initial increment begins upon
receiving MS A approval. In this phase, the DoD
Component:
oDemonstrates the capability of the selected technical
platform to meet the BPR requirements documented
in the Business Case;
oReviews and / or conducts more BPR, as appropriate
oGains knowledge necessary to inform the
development of the Acquisition Program Baseline
(APB)
oIdentifies the BEA version to which the material
solution demonstrates / will demonstrate compliance
Close Out
Review
Operations and
Support
Business
Investment
Management
Upto 12 Months
A
Prototyping
Engineering
Development
Points
Limited
Deployment
IOT&E
Full
Deployment
IOC
FDD
MDD
B C
Close Out
Review
Operations and
Support
Prototyping
Engineering
Development
Limited
Deployment
IOT&E
Full
Deployment
IOC
FDD
B C
Authorization
to Proceed
Increment 2 / N

FEBRUARY 2011 23
Phase High-level description
oDemonstrates alignment to previously defined
performance measures (Business Case)
Engineering Development • Begins upon receiving MS B approval. In this phase, the
DoD Component:
oDemonstrates that the program has been designed,
configured, developed and tested in a manner
consistent with the Business Case
oAsserts compliance to the BEA version stated prior
to MS B and, if requested, provides BEA compliance
test results to the IRB
oAscertains whether the program is ready to be proven
in an operational environment
Limited Deployment • Begins upon receiving MS C approval. In this phase, the
DoD Component:
oAsserts compliance to the BEA and, if requested,
provides BEA compliance test results to the IRB; and
oDeploys the program to a limited number of users for
testing in an operational environment
Full Deployment • Begins upon receiving a Full Deployment Decision
(FDD). In this phase, the DoD Component:
oFields the increment’s business capability into a full
production environment
oDefines Full Deployment (FD)
Operations & Support (O&S) • Begins when an increment or DBS has been successfully
fielded. O&S has two major efforts: Lifecycle
Sustainment and Disposal. In this phase, the DoD
Component:
oExecutes a support program that meets materiel
readiness and operational support performance
requirements
oSustains the system in the most cost-effective manner
over its total life cycle
Table 1. Execution Phase Description
The IRBs and the DBSMC maintain oversight of the investment activities during the
Execution Phase. For those IRB meetings during which an acquisition review is performed,
the IRB Chair ensures the participation of executive staff from acquisition and testing

FEBRUARY 2011 24
disciplines necessary for a comprehensive and rigorous review. In coordination with the
IRBs, the MDA has acquisition oversight; the DoD Components provide oversight for their
internal processes and procedures.
Key Execution Phase Activities
Prototyping
In BCL, the purpose of Prototyping is to demonstrate the capability of the software to meet
business process requirements as outlined in the Business Case. Prototyping includes
installing IT in a relevant environment to gain the knowledge necessary to refine user
requirements and gain the sufficient knowledge needed to inform APB development. For a
program’s initial increment, the Prototyping phase begins upon MDA approval of MS A and
release of the MS A ADM. Upon MS A approval, the PM begins the necessary activities to
award contracts and to baseline the current increment(s) of the materiel solution.
For subsequent increments, the Prototyping phase begins after the DBSMC approves the
materiel solution’s request for authority to obligate modernization funds for the increment
and the MDA releases an ADM documenting the increment’s ATP. Therefore – there is one
MS A per DBS, but there may be multiple ATPs.
During Prototyping, the PM conducts the activities necessary to gain the sufficient
knowledge needed to baseline cost, schedule, and performance parameters resulting in an
APB. The PM conducts these activities in accordance with the approved Business Case, the
MS A ADM, and the solution-specific implementation methodology being employed.
If the impact of these changes requires updates to any of the materiel solution’s documented
and approved baselines, including the scope baseline established in the Business Case, the
IRB and the MDA are to be notified immediately. If more than eighteen months elapse
between contract or option award following MS B and IOC the DBS must come back to the
IRB and MDA (depending on the issue) for the appropriate decision.
Activities in this phase iterate until there is confidence that the scope defined for the materiel
solution or increment(s) and the cost, schedule, and performance baselines can be
maintained throughout the remainder of the materiel solution or increment(s)
implementation.
Key Prototyping Phase Activities
Include, but are not limited to:
Initial Increment Subsequent Increments
• Obtain DBSMC approval to obligate
modernization funds;
• Leverage lessons learned from other
similar DoD programs;
• Conduct procurement of software
and services;
• Obtain DBSMC approval to obligate
modernization funds;
• Obtain MDA ATP ADM;
• Review and incorporate lessons
learned;
• Re-validate the Business Case (to be

FEBRUARY 2011 25
• Develop and refine high-level,
outcome-based system requirements;
• Conduct gap analysis;
• Develop high-level design for the
end-to-end materiel solution;
• Define and create detailed
requirements and design for the
initial increment;
• Declare which version of the BEA to
which the increment will deliver;
• Complete detailed design of the
capability aligned with the BEA;
• Conduct implementation planning;
• Develop an APB; and
• Document lessons learned
performed by the Functional
Sponsor);
• Re-validate the Program Charter;
• Conduct contract actions, as needed;
• Define and create detailed
requirements and design for the
current increment;
• Complete detailed design of the
capability aligned with most recent
approved major release of the BEA;
• Conduct implementation planning
for the increment;
• Develop cost, schedule, and
performance baselines (included in
the APB developed for each
increment);
• Ensure full funding is available (to be
performed by the Functional
Sponsor); and
• Document lessons learned.
ERAM Assessment
A MS B ERAM assessment must commence at least 90 days prior to the IRB date at which
the Functional Sponsor will present the MS B Package detailed below. The PM must notify
the ERAM lead no later than 120 days prior to that IRB date to schedule the ERAM. The
ERAM team develops the ERAM findings and forms suggestions for any risk mitigations.
The Functional Sponsor and the PM develop the mitigations for the key risks and jointly
present the results to the IRB and the MDA prior to all MS B decisions.
IRB Review and Approval
When the Functional Sponsor determines that enough information has been analyzed and
documented to obtain a MS B decision, the PM prepares a MS B Package that includes the
following documents:
• A draft APB;
• An updated Business Case with:
o DOT&E and DDT&E joint approval of the test section;
o DSE approval of the systems engineering section; and
o CAE signature
• DBSMC approval to authorize obligation of modernization funds;
• A memorandum from the CAE to the MDA
o Certifying the program meets all applicable statutory and regulatory
requirements;
o Describing any issues related to the requested Milestone decision; and
o Recommending MDA approval of the MS B request;

FEBRUARY 2011 26
• A completed ERAM Assessment and risk mitigation plan; and
• Any additional documentation required to comply with statutory and regulatory
requirements for MS B) as identified in Tables 1-3 of Attachment 3 of Reference (g).
Once complete, the MS B Package, excluding the ERAM Assessment, is submitted to the
IRB and reviewed through the same processes as described for MS A.
Prototyping Phase Decisions and Exit
During the IRB review, the IRB Chair, with the advice of the IRB members and
stakeholders:
• Reviews the Business Case;
• Provides a MS B recommendation to the MDA; and
• If necessary, recommends certification and DBSMC approval of the materiel
solution’s request for modernization funds.
The IRB Chair, with the advice of the IRB members and other appropriate stakeholders,
provides a MS B approval recommendation to the MDA. The recommendation to the
MDA includes the alternative positions presented to the IRB Chair by the IRB Members and
other appropriate stakeholders.
The Prototyping phase ends when the IRB Chair forwards the MS B recommendation to the
MDA as part of the IRB-approved MS B Package.
Engineering Development
The Engineering Development phase begins upon MDA approval of MS B. Upon MS B
approval, the PM is authorized to initiate a program, award a contract, commence the
activities needed to deploy the current increment(s) of the program, and obligate funds.
Key Engineering Development Phase Activities
During Engineering Development, program activities include, but are not limited to:
• Refining business outcomes;
• Configuring the technical platform and build functionality;
• Planning for and coordinating developmental and operational testing with the OTA
and DOT&E in accordance with the Operational Test Plan (note: a degree of test
planning and collaboration with the test community has already occurred in the IM
Phase);
• Testing to ensure that the capability to be delivered adheres to the outcomes defined
in the Business Case and that it complies with the DoD BEA;
• Demonstrating that the program or program increment has been designed,
configured, developed and tested in a manner consistent with the Business Case and
the Program Charter; and
• Preparing for delivery into an operational environment.

FEBRUARY 2011 27
At the end of the Engineering Development phase, the PM prepares a MS C Package to
submit to the appropriate MDA that includes the following documents:
• An updated Business Case;
• If necessary, DBSMC approval to authorize obligation of modernization funds; and
• Any additional information / documentation required to comply with statutory and
regulatory requirements for MS C.
BEA Compliance
Prior to MS C, the increment must be tested against BEA compliance criteria (i.e., tested
to assert compliance to the version declared at MS B). Any capability delivered must
comply with the BEA.
Limited Deployment
The Limited Deployment phase begins when the Functional Sponsor and the MDA approve
the fielding of the capability into an operational environment for IOT&E and the MDA
documents the decision in the MS C ADM.
An approved APB (from MS B, which should be updated post-MS C), a MS B ADM, and a
valid DBSMC approval of an IRB certification are required before the MDA may consider
the MS C request.
MDA MS C approval permits fielding of the program or program increment into a limited
operational environment for IOT&E. After the program or program increment has been
fielded, the PM engages an Operational Test Agency to verify satisfaction of the functional
requirements described in the Business Case and to determine the operational effectiveness
and suitability of the increment.
Key Limited Deployment Phase Activities
During Limited Deployment, program activities include, but are not limited to:
• The Functional Sponsor, informed by IOT&E results and DOT&E
recommendations (for DBS on the OT&E oversight list), issues a written declaration
to the PM that the system achieves IOC.
• The PM notifies the MDA, via the IRB Chair, that the system achieves IOC.
Unless otherwise documented in the MS B ADM, if IOC is not declared within eighteen (18)
months of MS B contract or option award, then MDA withdraws delegation of authority to
the lead DoD Component, if previously granted. MDA review and approval is required
before additional modernization funds may be obligated for the program or program
increment.
The Limited Deployment phase ends when phase requirements have been satisfied, IOT&E
completed, and IOC declared.

FEBRUARY 2011 28
Full Deployment
The purpose of the Full Deployment Phase is to field an increment of capability in
accordance with the Business Case.
Entrance into the Full Deployment Phase for an increment depends on completion of
IOT&E, declared IOC by the Functional Sponsor, and satisfaction of the DOTMLPF
solution outlined in the Business Case for the specific increment. The complete DOTMLPF
solution as defined in the Business Case may not be attained until all increments of the
solution are delivered.
In addition to documentation required to comply with statutory and regulatory requirements
for an FDD, the following standard information and documentation are required in order to
receive an FDD from the DoD Component MDA:
• An updated Business Case
• The results from IOT&E, and
• DOT&E recommendations (for DBS on the OT&E oversight list).
During this phase the Functional Sponsor also defines the criteria to be considered for an
FDD and Full Deployment and will record those criteria in the Business Case.
Key Full Deployment Phase Activities
The Full Deployment phase begins at the FDD. At the FDD, the MDA reviews the
Business Case, the IOT&E results and DOT&E recommendations (if applicable), and
documentation required to comply with statutory and regulatory requirements to determine
whether the capability is ready to proceed to full deployment. The FDD is documented in
an ADM.
Upon completion of the Full Deployment phase, the PM schedules a Close Out Review for
the program/program increment with the IRB (described in IRB Guidance). The Close Out
Review:
• Includes the results of the program / program increment’s Post-Implementation
Review;
• Offers an opportunity for the discussion of user feedback; and
• Enables understanding of how well the completed program increment met user
needs prior to finalizing the requirements for a subsequent program increment.
Operations & Support (O&S)
Entrance into the O&S phase depends on meeting the following criteria: an approved
Business Case, satisfaction of any conditions imposed by the MDA at the FDD, and the
Functional Sponsor’s written declaration that the system achieves FOC, as defined in the
Business Case. The O&S phase begins when an increment or DBS has been successfully
fielded.

FEBRUARY 2011 29
Key O&S Phase Activities
This phase executes a support program that meets materiel readiness and operational
support performance requirements and sustains the system in the most cost-effective
manner over its total life cycle. Planning for this phase begins prior to program initiation
and is summarized in the Business Case. O&S has two major efforts: Lifecycle Sustainment
and Disposal.
Lifecycle Sustainment planning and execution seamlessly spans a system’s entire life cycle,
from investment management to disposal. It translates business capability and performance
requirements into tailored product support to achieve specified and evolving life cycle
product support availability, maintainability, sustainability, scalability, reliability, and
affordability parameters. It is flexible and performance-oriented, reflects an evolutionary
approach, and accommodates modifications, upgrades, and re-procurement.
During Lifecycle Sustainment, the PM optimizes operational readiness and the Functional
Sponsor conducts continuing reviews of sustainment strategies, comparing performance
expectations as defined in performance agreements and the Business Case to actual
performance results. The Functional Sponsor and PM continuously identify deficiencies in
these strategies and adjust the Business Case as necessary to meet performance requirements.
At the end of its useful life, an increment is disposed of in accordance with all statutory and
regulatory requirements and policy relating to safety, security, and the environment. During
the design process, PMs estimate and plan for the system’s safe disposal.
Other Key Execution Phase Activities
Business Case Updates
In coordination with the Functional Sponsor, the CAE, and the IRB, the PM must review
and, when necessary, update the Business Case to incorporate any changes prompted by an
increment to ensure that:
• The problem to be solved remains valid;
• The selected solution is still appropriate to achieve the desired outcomes;
• The materiel solution can continue to be executed within the established cost,
schedule and performance parameters; and
• The expected benefits will be realized.
Additionally, the PM must update and/or revise the materiel solution’s Business Case if
changes occur to the problem scope, context or the requirements for additional
modernization funding.
For those materiel solutions with a Business Case describing a deployment consisting of
multiple increments of business capability, each increment must achieve IOC within 18
months of contract or option award following MS B approval. At a minimum, IOC requires
the first attainment of the capability to effectively employ a DBS of approved specific

FEBRUARY 2011 30
characteristics operated by an adequately trained and supported user community. In addition,
in no event can FDD occur later than 5 years from when funds were first obligated for the
program.
Business Case Re-validation
The Functional Sponsor validates the Business Case at the beginning of each new increment.
This re-validation ensures that:
• The materiel solution stays focused on the business need;
• Required resources remain available;
• The business need for the materiel solution still exists;
• The materiel solution remains capable of delivering the needed capability
If the Business Case is deemed no longer valid, but the capability still needed, the Functional
Sponsor, along with the CAE, notify the IRB and the MDA immediately to determine how
to proceed. If the Business Case is deemed no longer valid and the capability no longer
needed, the Functional Sponsor, along with the CAE, immediately notify the IRB and the
MDA of their intention to discontinue the program.
Funding
Throughout the Execution Phase, the Functional Sponsor must ensure the availability of
fully funding each increment of the development and delivery of the materiel solution. If the
funding profile changes significantly for any reason, the Functional Sponsor must return to
the IRB for re-certification of modernization funds.

FEBRUARY 2011 31
Chapter 4: BCL Business Case
Overview
The Business Case is the single document used to justify DBS investments and acquisition
decisions in BCL. All DBSs which exceed $1,000,000 must have a Business Case. The
Business Case ensures progress and outcomes remain in alignment and further justify
continued funding throughout the lifecycle of the materiel solution. It must be revalidated
upon any major changes to scope, outcomes, cost, schedule, assumptions, risks, constraints,
and/or success factors. Such updates allow the Department to ensure that the problem to be
solved, the approach to solving it, and the benefits to be derived remain valid.
The Business Case ensures that a problem, its root cause and DOTMLPF issues are
thoroughly analyzed; that all options have been considered; that risks are identified; and that
there is a high degree of confidence the expenditure of resources and funds are justified. It
provides leadership with sufficient information to make informed investment decisions
within the context of enterprise priorities and available resources. Components are
responsible for the development and maintenance of the Business Case.
The principal purposes of the Business Case are to:
• Facilitate a way of thinking that causes Components to consider a business
capability’s value, risk and relative priority as fundamental elements of submission;
• Require those proposing a solution to justify its value and to self-eliminate any
proposals that are not of demonstrable value;
• Enable DoD leadership to determine if a concept or proposed solution is of value to
the enterprise and is achievable compared to the relative merits of alternative
proposals; and
• Enable DoD leadership to objectively measure the subsequent achievement of the
capability’s benefits.
The Business Case provides a compelling, defendable and credible justification for the
recommended approach to solving a defined problem. The problem is considered solved
upon reaching the stated objectives, which have financial and other business values made
tangible through the Business Case analysis. The contents of the Business Case describe the
full range of resources and actions required to reach these objectives.
A Business Case develops in stages based on information known at the time of its creation.
Business Case re-validation and updates are performed throughout the proposed solution
and program’s lifecycle as more information becomes available, technology changes, statute
and regulations dictate, requirements and outcomes change, or other significant events
occur.
The Business Case development process should ensure:
• Thorough consideration and documentation of the required issues;

FEBRUARY 2011 32
• Availability of sufficient information to facilitate fair evaluations of different
proposals;
• Clarity of both the value and risks inherent in the proposed solution;
• An executive with the capability and authority to deliver the benefits sponsors and
commits to the investment;
• All key aspects can be quantified so their achievement can be tracked and measured;
• The delivery of the outcomes and benefits can be traced and measured;
• Tailoring the Business Case to the size and risk of the proposed solution to the or
initiative;
• The Business Case concerns the business capabilities and impact, rather than
focusing on technical aspects;
• Inclusion of all factors relevant to a complete evaluation;
• Clearly relevant and logical contents which are simple to evaluate;
• Direct justification of key elements in a transparent manner; and
• Clear accountability and commitment for the delivery of benefits and management
of costs.
A Business Case will be evaluated to ensure:
• The investment has value to the enterprise and aligns with enterprise priorities;
• Proper management and support of senior officials for the proposed solution;
• Definition of the scope for the proposed solution and measurable desired outcomes;
• Clear evidence that BPR has been done or is being completed;
• Ability of the Component to deliver the benefits; and
• Dedicated resources are working on the highest value opportunities.
The estimated cost of a proposed solution generally dictates the rigor of scrutiny and the
level of detail its Business Case considers. As a general rule, the Problem Statement for a
(projected) MAIS materiel solution should be less than 9 pages in length and, depending on
the number of alternatives considered, the total Business Case may vary from 15 to 40 pages.
The Business Case will always be judged on the quality of information it contains, not on the
length of the content.
There are four main sections of the Business Case: the Problem Statement; the Business
Case analysis the Acquisition Plan, and the Test Plan. The Business Case also contains an
Executive Summary.
Business Case Content
Executive Summary
The Executive Summary illustrates the essence of the entire Business Case by providing a
cogent summary of the subject, scope, methods of analysis and major results. This section
may provide historical information, but it should be succinct and include only what is
deemed directly relevant for providing context in addition to being understandable to the
Business Case’s audience.

FEBRUARY 2011 33
Problem Statement
The Problem Statement clearly defines and articulates the business need to be solved, the
value of solving it and the approach to solving it. It presents information in such a way that
it enables the decision makers to quickly make decisions and to provide the context for
subsequent analysis and execution.
The Problem Statement results from a structured analysis of an aspect of the business where
a perceived business need exists. This stems from either anecdotal evidence or where the
value of an operational business metric exceeds boundaries. Developing a Problem
Statement ensures that a problem actually exists, the root cause of the symptoms is identified
as the true problem and that the problem is bounded and understood to a level where it can
be solved and desired outcomes can be measured. The Problem Statement provides the
foundation for the overall Business Case and requires IRB review and approval before
progressing beyond the BCD phase.
Within the Business Case Template, the Problem Statement section is clearly marked and
contains multiple subsections that drive the user to think critically about the business need.
Analysis and content included in the Problem Statement section includes items like:
• Defining the broader operational environment
• Summarizing the business problem within the proper context;
• Describing how the problem impacts the current operating environment;
• Describing the business need in terms of underlying root cause and in a specific,
quantifiable manner that provides a clear description of the current strategic and
tactical environment;
• Identifying internal and external boundaries and constraints
• Scoping the business need in such a way that considers the boundaries and
constraints and that will enable an incremental approach within BCL timeframes
• Describing potential DOTMLPF drivers of or contributors to the business need;
describing how each driver contributes and how the business need can be changed
or eliminated if the contributor is removed
• Expected benefits and improvements, to include a description of the desired end
state (or, “what good looks like”) and the metric(s) by which the improvements will
be tracked and measured
• Summarizes the recommended course of action upon which further analysis and
execution will be based
Business Case Analysis
The Business Case analysis provides a convincing, defensible and reliable justification for the
recommended approach to solving a defined problem. The overarching problem defined
will be considered solved upon reaching the stated objectives, which have financial and other
business values that are made tangible through the Business Case analysis. This section
examines the full DOTMLPF range of resources and actions required to reach stated
objectives, and should be clear in the Component’s effort to achieve a solution with
DOT_LPF (or non-materiel) efforts only before resorting to a materiel solution as well.

FEBRUARY 2011 34
Unplanned broadening of boundaries, ambiguities or changes in the scope of the problem
must be validated against the Business Case. However, Business Case impacts must be
understood before making decisions to include or exclude changes in scope or bounds.
Updating the Business Case to reflect these changes requires IRB approval.
Solution Scope
Solution Scope describes the materiel capabilities needed to solve the problem resulting from
the previous DOTMLPF analysis. It must provide enough detail to enable scope to be
controlled throughout continued analysis and execution. The Solution Scope section drives
further detail into content such as constraints and dependencies and business outcomes. The
scope of the solution set itself is typically defined at multiple levels with increasing
granularity of detail over time.
Analysis of Alternatives
The AoA should be based off of AoA Guidance provided to the program and should be
summarized in the AoA section of the Business Case. An AoA should focus on the
alternative options for meeting defined objectives; and the basis for deciding which
alternative better meets those objectives based on the recommended course of action
presented in the Problem Statement.
Each alternative is evaluated based on a set of criteria defined by the program. At a
minimum, for each viable alternative being considered the following should be documented:
• A summary of the alternative;
• An assessment of its viability;
• Estimated life-cycle cost and benefits (in comparison to the status quo);
• Estimated risks and impact on viability;
• Detailed system and business process alternatives; and
• Detailed cost, benefit and sensitivity analyses of each alternative.
This section ends with a summary of the recommended course of action upon which further
analysis and execution will be based.
Program Justification
The Program Justification provides a logical and defendable argument as to why the
recommended material solution is the preferred course of action. At MS A, the content of
the Program Justification is based on knowledge at this particular time and should be
considered an estimate; it will be matured as more information becomes known. Subsections
of the Program Justification include summaries of or high-level details regarding:
• The assumptions underlying the solution analysis;
• The business process requirements addressed (relevant to BPR efforts);
• Changes likely to be required across the DOTMLPF spectrum in order to implement
the recommended solution.
• The critical success factors;

FEBRUARY 2011 35
• Key risk factors to be considered;
• The financial analysis conducted;
• Sensitivity analysis reflecting changes in assumptions and/or risks;
• The funding and resources required to implement the DOTMLPF solution; and
• The expected schedule for delivering capability derived from the materiel solution,
including IOC and FDD.
Acquisition Plan
The Acquisition Plan describes the method for procuring the capability required to solve the
business problem, if it has been decided that a DOT_LPF solution will not alone solve it. It
guides the process of contracting for the materiel solution and the services required to
implement it. The Acquisition Plan also lays out how the program meets the statutory and
regulatory requirements for competition and describes the appropriate types of contracts or
the contract vehicles, if appropriate, to implement the solution. Finally, then plan describes
the process by which the Government intends to research the available vendors, small
business objectives, incentive methodology, special contracting considerations, evolutionary
acquisition approach and approach to life cycle sustainment. This section of the Business
Case should include summaries of or high-level details regarding:
• How the acquisition will be conducted for each increment and the milestones /
decision points associated
• The results of market research that has been conducted in support of the acquisition
• The contracting approach to be used to acquire the services and goods required to
implement the recommended materiel solution to include a discussion of contract
types, competition, sources identified, and consideration of small businesses
• The process and parameters by which the system integrator and other vendors will
be selected
Test Plan
The Test Plan summarizes the planning for the materiel solution’s test strategy and the
technical approach to its implementation. Portions of this section of the Business Case are
updated at specific milestones. It summarizes the planning for the materiel solution’s test
strategy and the technical approach to its implementation. The DOT&E and DDT&E (or,
for DBS that do not meet the MAIS thresholds, the DoD Component equivalent) approve
the initial Test Plan and updates submitted at subsequent decision points; the DSE, as
appropriate, approves the Systems Engineering section of the Test Plan.

FEBRUARY 2011 36
Chapter 5: BCL Program Charter
Overview
The Program Charter generally articulates the manner in which the program will be
managed. It incorporates the system integrator’s (SI’s) or other contracted technologist’s
methodologies and requirements with program management controls and represents an
agreement between the PM, Contractor, and functional community as to the methods of
execution. The Program Charter does not represent a Contract.
The Program Charter is an evolving document that develops additional levels of detail as the
program matures. At MS A, the Program Charter contains information at varying levels of
completeness and confidence. Additional information and detail obtained throughout the
remaining lifecycle phases, including input based on the selected SI’s methodology, feeds
back into the Program Charter. This iterative process results in a more comprehensive
Program Charter with which to guide execution.
Program Charter Content
Mission Statement
The Mission Statement describes, in an overarching fashion, how the program intends to
execute the solution defined in the Business Case.
Program Organization
This section describes the program’s organizational structure and identifies its key
stakeholders. Critical pieces of information within the Program Organization section include,
but are not limited to:
• Identifying the Functional Sponsor and creating a succession plan
• Depicting a program / organizational structure and the roles and responsibilities of
the organization’s members
• Describing all key functional roles (customer definition)
• Documenting the roles of all stakeholders with a vested interest in the outcomes of
the program
Resource Management Plan
The Resource Management plan describes how the program management team ensures the
availability of the right skills sets to the program at the time they are needed and at the level
at which they must be committed to the program. It shows the processes by which new team
members join the program and integrate into the team, as well as how team members exit
the team. These processes ensure minimal down time and maximum knowledge transfer.

FEBRUARY 2011 37
Governance Framework
The Governance Framework introduces the processes that manage the implementation of
the solution. It describes how leadership ensures that standards are followed, that processes
are executed, and that they are effective in achieving their intended result. This section may
require revision after an SI is on contract in order to align with their implementation
approach or methodology. Key pieces of information captured within the Governance
Framework section include, but are not limited to:
• A discussion of the processes that will be used to manage the implementation of the
solution
• The processes by which parties outside of the program engage with the program
• The processes by which issues and problems will be resolved, to include how the
responsibilities for addressing these issues will be shared (escalation process, etc.)
• How status and activities will be reported, to whom, and how often (to include who
is responsible for which types of program metrics, both for developing them,
reviewing them, and reporting them)
• Articulates how to document and manage risks
• Documents what management system monitors a contractor’s effort in addition to
how to make changes to the contract, in addition to monitoring contractor
deliverables
• Describes how the program ensures scope remains aligned to the Business Case, and
what occurs if this alignment is broken
• Defining engagement of the testing and systems engineering communities
• Defines who is responsible for status reports and managing the program metrics
Implementation Methodology
The Implementation Methodology describes the approach to be used to implement the
solution, including any phases or key events. The selected and contracted SI’s methodology
should be used as the basis of this section of the Program Charter. This section remains
blank until an SI is selected and engaged.
Program Standards
Program Standards discusses operational aspects of program management that benefit from
formal standards, such as: Organizational Change Management, Communication Planning,
Training, Testing, Document Management / Version Control, Software Configuration
Management, and Control Plan and Coding Standards, if appropriate. It focuses on what
standards will be created, not the documentation of the standards themselves. This section
requires revision after an SI is hired in order to be consistent with the contractor’s
implementation approach or methodology.

DoD Business Capability Lifecycle (BCL) Guide (Draft)

DoD Business Capability Lifecycle (BCL) Guide (Draft)

Recommandé

Recommandé

Contenu connexe

Tendances

Tendances (18)

En vedette

En vedette (9)

Similaire à DoD Business Capability Lifecycle (BCL) Guide (Draft)

Similaire à DoD Business Capability Lifecycle (BCL) Guide (Draft) (20)

Plus de GovCloud Network

Plus de GovCloud Network (20)

Dernier

Dernier (20)

DoD Business Capability Lifecycle (BCL) Guide (Draft)