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

MDAUSD(AT&L) / DoD DCMO

Acquisition Decisions

DoD DCMOCombined IRB for Acquisition

Functional SponsorEnterprise/Component

USD(C), (P&R), (AT&L); DoD CIOPSAs / 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

Business Need Program

Defense Business System

Proposed DOTMLPF Solution Materiel Solution


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.

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).

https://www.us.army.mil/�

https://gft.kc.us.army.mil/login/�

https://www.kc.army.mil/book/groups/acquisition-automation-bpm-training-group�


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

Up to 12 Months

A

18 Months* MS B to IOC12 Months*

PrototypingEngineering

Development

Acquisition Decision Points

Limited Deployment

IOT&E

Full Deployment

IOC

FDDMDDB C

Close Out Review




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




Up to 12 Months

A



Development


Limited Deployment

IOT&E

Full Deployment

IOC

FDDMDDB C

Close Out Review




Development

Limited Deployment

IOT&E

Full Deployment

IOC

FDD

B C


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.

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: o Demonstrates the capability of the selected technical

platform to meet the BPR requirements documented in the Business Case;

o Reviews and / or conducts more BPR, as appropriate o Gains knowledge necessary to inform the

development of the Acquisition Program Baseline (APB)

o Identifies the BEA version to which the material solution demonstrates / will demonstrate compliance

Close Out Review




Up to 12 Months

A



Development


Limited Deployment

IOT&E

Full Deployment

IOC

FDDMDDB C

Close Out Review




Development

Limited Deployment

IOT&E

Full Deployment

IOC

FDD

B C


Increment 2 / N


FEBRUARY 2011 23

Phase High-level description o Demonstrates alignment to previously defined

performance measures (Business Case) Engineering Development • Begins upon receiving MS B approval. In this phase, the

DoD Component: o Demonstrates that the program has been designed,

configured, developed and tested in a manner consistent with the Business Case

o Asserts compliance to the BEA version stated prior to MS B and, if requested, provides BEA compliance test results to the IRB

o Reviews and / or conducts more BPR, as appropriate o Ascertains whether the program is ready to be proven

in an operational environment o Demonstrates alignment to previously defined

performance measures (Business Case) Limited Deployment • Begins upon receiving MS C approval. In this phase, the

DoD Component: o Asserts compliance to the BEA and, if requested,

provides BEA compliance test results to the IRB; and o Deploys the program to a limited number of users for

testing in an operational environment o Reviews and / or conducts more BPR, as appropriate o Demonstrates alignment to previously defined

performance measures (Business Case) Full Deployment • Begins upon receiving a Full Deployment Decision

(FDD). In this phase, the DoD Component: o Fields the increment’s business capability into a full

production environment o Reviews and / or conducts more BPR, as appropriate o Defines Full Deployment (FD) o Demonstrates alignment to previously defined

performance measures (Business Case) 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: o Executes a support program that meets materiel

readiness and operational support performance requirements

o Sustains 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.


FEBRUARY 2011 38

Chapter 6: Metrics

Overview Metrics, or measurements of progress of a program or project, are critical “must-haves” for the success of IT programs. Metrics factor heavily throughout BCL and are essential to successful decision-making by the IRBs and MDA. There are varying methodologies and practices which programs can use to develop a useful set of metrics; this Guide provides a high-level overview of one approach – this approach is not required for usage, it is merely given as an option.

Figure 7: Example Metrics Approach

Strategic Metrics Strategic Metrics link directly to the achievement of organizational goals and describe a capability’s desired end state at the highest level. Ideally, these metrics would align directly to the 5 Business Goals listed in the DoD SMP (Reference (e). DOTMLPF and BPR help develop and refine the problem statement. Once approved by the IRB, the Problem Statement becomes the foundation for the Business Case and the High Level Outcomes (HLOs). HLOs describe a capability’s desired end-state (what good looks like) with specific strategic Measures of Effectiveness (MOEs) to ensure that the capability delivered meets the objective. It is the responsibility of the Functional Sponsor to define HLOs. HLOs should (in most cases) map back to the SMP Business Goals. An example of a Problem Statement, HLO, and associated strategic MOE is provided below. Example:

• Problem Statement: The Agency or Component lacks the ability to verify financial data to enable a clean financial audit on an enterprise level.

• HLO: The Department or Component has the capability to manage and account for

financial transactions, i.e. accounts balances, transfers, commitments and obligations,


FEBRUARY 2011 39

etc. In accordance with required statutes and Financial Management Regulations in an efficient and effective manner to enable a clean Audit by 2016.

• MOE: Capability to execute the Department’s End-to-End Financial Management

Processes, i.e. Execute Requisitions, Execute Purchase, Execute Disbursements with 97% accuracy within a 48-hr period.

Business Metrics Business Metrics measure the Business Outcomes and are developed as standardized business practice measures common across other DBSs. These Metrics provide progress visibility for enterprise initiatives that may exceed the bounds of a single program or organization, in the context of aligning investments with the BEA and strategic outcome priorities for the enterprise. Business Outcomes are aligned to the BEA and should support HLOs and “to be” business processes. The Functional Sponsor is responsible for defining Business Outcomes. The AoA and other supporting analyses provide the analytic foundation for determining the appropriate thresholds and objectives for the business attributes. The analysis also aids in prioritizing outcomes and increments. An example of a Business Outcome and associated MOE is provided below. Example

• Problem Statement: The Agency or Component lacks the ability to verify financial

data to enable a clean financial audit on an enterprise level. • HLO: The Department or Component has the capability to manage and account for

financial transactions, i.e. accounts balances, transfers, commitments and obligations etc. In accordance with required statutes and Financial Management Regulations in an efficient and effective manner to enable a clean Audit by 2016.


Processes, i.e. Execute Requisitions, Execute Purchase, Execute Disbursements with 97% accuracy within a 48-hr period.

• BO: Capability to effectively manage and execute Acquire-to-Retire (A2R), Order-

to-Cash (O2C), and Procure-to-Pay (P2P) activities to achieve auditability in accordance with 2011 SMP Objectives.

• MOE: Capability to interface with US Treasury and applicable financial feeder systems to execute A2R, O2C, P2P transactions for 96% of the end-to-end Business Process with no manual intervention.


FEBRUARY 2011 40

Program Metrics Program Metrics track the general progress and health of the overall program, typically in the form of cost, schedule, and performance as established in the APB. Program Metrics should be selected and combined with Delivery Metrics (see below) as needed to support specific Business and Strategic progress achievement visibility. Along with BOs, Program Outcomes are also a part of IM Phase and are based on the activities that support the BOs and define the “to be” business process and business rules as derived from BPR or BEA planned compliance. POs are unique to the organization/agency, and are supported by BPR analysis. During the AoA, POs are further developed in concert by the Functional Sponsor and the PM. Each PO has specific MOEs. An example is provided below. Example



financial transactions, i.e. accounts balances, transfers, commitments and obligations etc. In accordance with required statutes and Financial Management Regulations in an efficient and effective manner to enable a clean Audit by 2016.


Processes, with 97% accuracy within a 48 hour period. • BO: Capability to effectively manage and execute A2R, O2C, and P2P activities to

achieve auditability in accordance with 2011 SMP Objectives.


• PO: Capability for agencies/components to effectively manage Negative

Unliquidated Obligations (NULO). • MOE: Capability for agency/component to research and correct 97% of Negative

Unliquidated Obligations, and unmatched disbursements within 120 days of the date of disbursement.

Delivery Metrics Delivery Metrics support the System Requirements (SRs) and track the implementation of key system or capability attributes or performance requirements as defined in schedules or plans. Internal to a process or program, Delivery Metrics are best defined and captured


FEBRUARY 2011 41

during the Investment Management Phase to include key system attributes and performance requirements. While outcome-based SRs are captured during the IM phase, they are refined during BCL Prototyping (Execution Phase) with their foundation in BPR/BEA and supported by Gap Analysis/Gap Resolution conducted as part of the activities that support the program outcomes, and may include key performance parameters, applicable system attributes and other additional system performance outcomes that are measurable and testable. The Net-Ready Key Performance Parameter (NR-KPP) and other interoperability and supportability certification requirements are still required and performance outcomes must comply with the standards articulated in the NR-KPP. The System Integrator will, with participation by the PM and the Test and Evaluation Community, identify these performance outcomes. Each increment in the development must be supported by early and continuous prototyping to ensure that the necessary technologies and functionality will be available in real time to support development. Example



financial transactions, i.e. accounts balances, transfers, commitments and obligations etc. IAW required statutes and Financial Management Regulations in an efficient and effective manner to enable a clean Audit by 2016.


Processes, with 97% accuracy within a 48 hour period. • BO: Capability to effectively manage and execute A2R, O2C, and P2P activities to

achieve auditability in accordance with 2011 SMP Objectives.


• PO: Capability for agency/component to effectively manage Negative Unliquidated

Obligations (NULO). • MOE: Capability for agencies/components to research and correct 97% of negative

unliquidated obligations, and unmatched disbursements within 120 days of the date of disbursement.

• SR: Capability for system to automatically notify the fund holder of NULOs.


FEBRUARY 2011 42

• MOE: System will automatically notify agency/component fund holders at 60, 90 and 120 days of the date of disbursement for 98% of NULOs and unmatched disbursements using an automated email notification.


FEBRUARY 2011 43

Appendix A: References

a. Public Law 111-84, National Defense Authorization Act for Fiscal Year 2010 http://www.gpo.gov/fdsys/pkg/PLAW-111publ84/html/PLAW-111publ84.htm

b. Defense Science Board, “Final Report of the Defense Science Board Task Force on Department of Defense Policies and Procedures for the Acquisition of Information Technology”, March 2009 http://www.acq.osd.mil/dsb/reports/ADA498375.pdf

c. DoD Instruction 5000.02, “Operation of the Defense Acquisition System”, December 8, 2008 http://www.dtic.mil/whs/directives/corres/pdf/500002p.pdf

d. Title 10, United States Code http://uscode.house.gov/download/title_10.shtml e. “Fiscal Year 2011 Strategic Management Plan; Department of Defense”, December

30, 2010 http://dcmo.defense.gov/documents/DoD-Releases-FY-2011-SMP-DCMO-article.pdf

f. CJCSI 3170.01, “Joint Capabilities Integration Development System”, March 1, 2009 http://www.dtic.mil/cjcs_directives/cdata/unlimit/3170_01.pdf

g. “Interim Acquisition Guidance for Defense Business Systems (DBS)”, November 15, 2010 https://acc.dau.mil/adl/en-US/408952/file/54480/BCL%20Interim%20Acquisition%20Guidance%20Final.pdf

h. Directive-Type Memorandum 08-020, “Investment Review Board (IRB) Roles and Responsibilities”, January 26, 2009 http://www.dtic.mil/whs/directives/corres/pdf/DTM-08-020.pdf

i. “DoD IT Defense Business Systems Investment Review Process: Guidance”, January 2009 http://www.bta.mil/products/IRB-Guidance-2009.pdf

j. “DoD Business Enterprise Architecture Compliance Guidance: BEA 7.0”, May 14, 2009 http://www.bta.mil/products/bea_7_0/BEA/products/bea_compliance_guidance.pdf

http://www.gpo.gov/fdsys/pkg/PLAW-111publ84/html/PLAW-111publ84.htm�

http://www.acq.osd.mil/dsb/reports/ADA498375.pdf�

http://www.dtic.mil/whs/directives/corres/pdf/500002p.pdf�

http://uscode.house.gov/download/title_10.shtml�

http://www.dtic.mil/cjcs_directives/cdata/unlimit/3170_01.pdf�

https://acc.dau.mil/adl/en-US/408952/file/54480/BCL%20Interim%20Acquisition%20Guidance%20Final.pdf�

https://acc.dau.mil/adl/en-US/408952/file/54480/BCL%20Interim%20Acquisition%20Guidance%20Final.pdf�

http://www.dtic.mil/whs/directives/corres/pdf/DTM-08-020.pdf�

http://www.bta.mil/products/IRB-Guidance-2009.pdf�

http://www.bta.mil/products/bea_7_0/BEA/products/bea_compliance_guidance.pdf�

http://www.bta.mil/products/bea_7_0/BEA/products/bea_compliance_guidance.pdf�


FEBRUARY 2011 44

Appendix B: Roles and Responsibilities Detailed roles and responsibilities for BCL stakeholders are detailed in the tables below. Any documentation submitted to an IRB for usage in the decision making process must be submitted 30 days prior to the publicized IRB date.

Business Capability Definition Principal Roles and Responsibilities Functional Sponsor • Leads the development of the Problem Statement;

• Presents the Problem Statement to the appropriate IRB; • Works closely with the appropriate CMO to guide initiatives

and investments through the IRB/DBSMC process; • Facilitates the BPR process; • Ensures user needs are represented; • Defines measurable high-level business outcomes

CMO • Approves and submits required documentation through the IRB/ DBSMC process.

IRB(s) • Recommends IRB Chair approval of proposed solution(s) to

the business need documented in a Problem Statement after determining: it is aligned with the Department’s strategic goals and objectives; that it addresses a problem, a capability gap, or functional requirement in the functional portfolio; and that it is not duplicative of a solution (materiel or non-materiel) already in place within the Department.

DCAPE • For MAIS and MDAP, develops AoA Study Guidance and

submits it for IRB Chair review prior to the MDD review.

Table 1. Business Capability Definition Phase: Roles and Responsibilities

Investment Management Principal Roles and Responsibilities Functional Sponsor • Presents the IRB approved Problem Statement to the MDA

at the MDD review; • Develops the AoA Study Plan in accordance with DCAPE-

approved AoA Study Guidance, and coordinates it with the IRB;

• Ensures DBS investments are aligned to their functional areas and meet strategic business priorities;

• Leads the development of the proposed materiel solution’s Business Case;

• Facilitates the BPR process; • Ensures user needs are represented;


FEBRUARY 2011 45

• Ensures that the proposed materiel solution documented in the Business Case complies with all statutory and regulatory requirements;

• Ensures that all necessary funding is identified and obtained to support the DBS’s progress through BCL;

• Works closely with appropriate Component POCs to guide DBS investments through the IRB/DBSMC process;

• Leads the development of functional requirements; • Ensures OSD staff is engaged as appropriate for guidance

relating to the Acquisition Approach and Test Plan content areas of the Business Case;

• Signs the Business Case and the Program Charter; • Integrates the DOTMLPF solution specified in the Business

Case and, as appropriate, conducts business process reengineering.

PM • In coordination with the Functional Sponsor, collaborates

on the Business Case, as appropriate • Signs the Program Charter; • In coordination with the Functional Sponsor, defines the

program outcomes that support the business outcomes; • In coordination with the Functional Sponsor, refines the

program outcomes during the AoA; • Oversees the program activities necessary to ensure the

proposed materiel solution and its associated documentation demonstrate compliance with statutory and regulatory requirements, e.g., Clinger-Cohen Act;

• Is an active participant in the ERAM assessment of the proposed materiel solution and is responsible for creating and managing risk mitigation strategies for risk factors identified during the ERAM assessment;

• Prepares for the IRB and MDA MS A review; • Replicates the requirements of the Program Charter and

appropriate sections of the Business Case for this phase and any succeeding phases in the Request for Proposal (RFP).

DOT&E • Collaborates on and approves the test plan in the Business

Case

DDT&E • Collaborates on and approves the test plan in the Business Case

DCAPE • Develops an independent cost estimate (ICE) for all MDAP;

• Develops an ICE for MAIS when the USD(AT&L) is the MDA and a Critical Change has occurred as defined by


FEBRUARY 2011 46

section 2445c of Reference (d); • Approves the AoA Study Plan within 30 days of receipt for

MAIS and MDAP. CAE • Signs the Business Case;

• Approves the Program Charter; • Submits a Compliance Memo to the MDA through the IRB

stating that the proposed materiel solution is compliant with applicable statute(s) and regulation(s) and recommends its approval, as appropriate.

ERAM • Provides independent ERAM assessment findings prior to

MS A

CMO • Approves and submits required documentation through the IRB/ DBSMC process

IRB • Reviews and (IRB Chair/CA) certifies modernization funds

pursuant to Reference (d); • (IRB Chair) Tracks identified solutions through BCL and

reports to the appropriate authority the status and alignment of all capabilities in the portfolio in their area of responsibility;

• Reviews and (IRB Chair) approves a proposed materiel solution’s Business Case; reviews and (IRB Chair) recommends MS A approval for potential materiel solutions to the MDA.

CA • Prioritizes DoD Enterprise requirements and provides

oversight of processes and procedures for DoD Enterprise-level systems that support their functional area via the investment review process inherent in their associated IRB.

DBSMC • When appropriate, coordinates its investment oversight

responsibilities with the MDA for each DBS it reviews; • Provides input to the development of DBS investment and

acquisition policies; • Approves IRB (CA) certification recommendations.

MDA • At MDD, reviews the IRB-approved Problem Statement

and AoA Study Guidance and issues an ADM with AoA Study Guidance attached;

• Specifies the acquisition entry phase and designates the next milestone.


FEBRUARY 2011 47

Table 2. IM Phase: Roles and Responsibilities

Execution Principal Roles and Responsibilities Functional Sponsor • Works very closely with the appropriate Component POCs

to guide DBS investments through the IRB / DBSMC process

• Supports the PM; • Ensures user needs are represented; • Leads the development of remaining functional

requirements, as necessary and appropriate; • Ensures DBS investments are aligned to their functional

areas and meet strategic business priorities; • Validates past BPR activities and facilitates further BPR, as

necessary; • Updates the Business Case as required; • Defines IOC and FOC; • Ensures that the materiel solution documented in the

Business Case complies with all statutory and regulatory requirements;

• Ensures that all necessary funding is identified and obtained to support the DBS’s progress through BCL;

• Ensures OSD staff is engaged as appropriate for guidance relating to the Acquisition Approach and Test Plan content areas of the Business Case;

• Integrates and achieves the DOTMLPF solution specified in the Business Case and, as appropriate, conducts business process reengineering;

• Declares IOC and FOC.

PM • Ensures stakeholder engagement. • Updates and signs the Program Charter; • In coordination with the Functional Sponsor, collaborates

on updates to the Business Case, as appropriate; • In coordination with the Functional Sponsor, refines the

materiel solution’s requirements during the Prototyping phase of Execution;

• Oversees the activities necessary to ensure the materiel solution and its associated documentation demonstrate compliance with statutory and regulatory requirements;

• Is an active participant in the ERAM assessment of the materiel solution and is responsible for creating and managing risk mitigation strategies for risk factors identified during the ERAM assessment;

• In coordination with the Functional Sponsor, where


FEBRUARY 2011 48

appropriate, is responsible for maintaining and updating the materiel solution’s BCL documentation, particularly when a significant change occurs in the program’s scope, schedule, requirements, or expected capability delivered;

• Prepares for the IRB and MDA MS B and C reviews; • Executes against the cost, schedule and performance

described in the APB and MDA requirements, if any, that are documented in an ADM;

• Delivers the business capabilities described in the Business Case;

• Conducts a PIR and prepares for the IRB Close Out Review.

DOT&E • Signs the materiel solution’s Operational Test Plan (OTP)

prior to Limited Deployment for DOT&E oversight programs only.

CAE • Submits a Compliance Memo to the MDA through the IRB

stating that the proposed materiel solution is compliant with applicable statute(s) and regulation(s) and recommends its approval, as appropriate.

ERAM • Conducts an ERAM assessment prior to MS B.

CMO • Approves and submits required documentation through the

IRB/ DBSMC process

IRB • Reviews and (IRB Chair / CA) certifies additional modernization funds pursuant to Reference (d), as necessary;

• (IRB Chair) Tracks identified solutions through BCL and reports to the appropriate authority the status and alignment of all capabilities in the portfolio in their area of responsibility;

• Reviews and (IRB Chair) approves a proposed materiel solution’s Business Case; reviews and (IRB Chair) recommends MS B approval for materiel solutions to the MDA;

• Conducts Annual Reviews; • Conducts Close-Out Reviews.

DBSMC • Coordinates its investment oversight responsibilities with

the MDA for each DBS it reviews; • Provides input to the development of DBS investment and

acquisition policies.


FEBRUARY 2011 49

MDA • Renders milestone approval, documented in an ADM.

Table 3. Execution Phase: Roles and Responsibilities


FEBRUARY 2011 50

Appendix C: Glossary

Term Description Business Enterprise Architecture

A strategic information asset base that defines the business missions, the information and technologies necessary to perform those missions, and the transitional processes for implementing new technologies in response to changing mission needs. The BEA is the blueprint to guide and constrain investments by the DoD Components as they relate to or impact business operations.

Business Capability The ability to execute a specific course of action. It can be a single business enabler or a combination of business enablers (e.g. business processes, policies, people, tools or systems, information) that assists an organization in delivering value to its customer.

Business Case A summary of essential information necessary to enable effective management decisions resulting from the rigorous analysis and associated documentation produced by the Functional Sponsor and PM. The Business Case clearly defines and articulates the business problem, the desired outcomes, and the holistic plan for delivering the capability. As more knowledge is acquired progressing through the lifecycle, the Business Case is updated for ongoing decision making.

Business Capability Lifecycle

An investment and acquisition approach that emphasizes rigorous analysis of requirements to enable delivery of business capabilities to the warfighter in a compressed timeframe. BCL aligns the existing Department business capabilities policies by consolidating requirements, acquisition, and Business Enterprise Architecture (BEA) compliance into a single oversight structure.

Business Process Reengineering

An approach aiming at improvements by means of elevating efficiency and effectiveness of the business process that exist within and across organizations within the context of an end-to-end business process.

DoD Component DoD Components are defined to be the Office of the Secretary of Defense, the Military Departments, the Chairman of the Joint Chiefs of Staff, the combatant commands, the Office of the Inspector General of the Department of Defense, the Defense agencies, the DoD field activities, and all other organizational and operational entities within the DoD.

Defense Business System

As defined in section 2222 (j)(2) of Reference (d), an information system, other than a national security system, operated by, for, or on behalf of the Department of Defense, including financial systems, mixed systems, financial data feeder systems, and information technology and information assurance infrastructure, used to support business activities, such as


FEBRUARY 2011 51

acquisition, financial management, logistics, strategic planning and budgeting, installations and environment, and human resource management.

Defense Business System Management Committee

The Committee established by the Secretary of Defense under authority delegated pursuant to section 186 of Reference (d).

Engineering Development

Part of the Execution Phase of BCL. The purpose is to demonstrate that the materiel solution for the increment has been designed, configured, developed, and tested in a manner consistent with the approved Business Case and Program Charter, and that the materiel solution is ready to be proven in an operational environment.

Enterprise Risk Assessment Methodology

ERAM is an independent collaborative risk assessment model that provides Decision Makers and Program Managers with needed program insight as well as actionable and measurable feedback. ERAM collaborates with the program, functional sponsors and other stakeholders to identify and mitigate risk.

Full Deployment Part of the Execution Phase. The purpose is to field an increment of capability for operational use in accordance with the Business Case.

Functional Sponsor The OSD or DoD Component executive responsible for defining and managing capabilities, verifying that capability requirements are met for IOC, representing the user community’s interests, and ensuring funding for DBS investments

Increment A useful and supportable operational capability that can be effectively developed, produced, acquired, deployed and sustained. Each increment of capability will have its own set of threshold and objective values to be documented in an APB.

Information Technology

Any equipment or interconnected system or subsystem of equipment that is used in the automatic acquisition, storage, manipulation, management, movement, control, display, switching, interchange, transmission, or reception of data or information by the an executive agency (DoD). For purposes of the preceding sentence, equipment is used by an executive agency (DoD) or the equipment is used directly by the DoD or is used by a contractor under a contract with the executive agency (DoD) which requires the use of such equipment or requires the use, to a significant extent, of such equipment in the performance of a service or the furnishing of a product. The term information technology includes computers, ancillary equipment, software, firmware and similar procedures, services (including support services), and related resources. The term information technology does not include any equipment that is acquired by a Federal contractor incidental to a Federal contract.

Investment Review Board

The Boards established by an Under Secretary or Assistant Secretary of Defense under authority delegated pursuant to


FEBRUARY 2011 52

section 2222 of Reference (d). Limited Deployment Part of the Execution Phase of BCL. The Purpose is to limit risk

by providing the capability as documented in the Business Case to a limited number of users and testing it in an operational environment.

Major Automated Information System

As defined in chapter 144A of Reference (d), a Major Automated Information System (MAIS) program is designated by the USD(AT&L) as a MAIS; or estimated to require program costs in any single year in excess of $32 million (FY 2000 constant dollars) or total program costs in excess of $126 million (FY 2000 constant dollars), or total lifecycle costs in excess of $378MM (FY 2000 constant dollars) . Note: MAIS do not include Information Technology (IT) that involves equipment that is an integral part of a weapons system or is an acquisition services program.

Major Defense Acquisition Program

As defined in section 2430 of Reference (d), a Major Defense Acquisition Program (MDAP) is estimated by the USD(AT&L) to require an eventual total expenditure for research, development, test and evaluation (RDT&E) of more than $365 million in fiscal year (FY) 2000 constant dollars or, for procurement, of more than $2.190 billion in FY 2000 constant dollars.

Milestone Decision Authority

The designated individual with overall responsibility for making DBS acquisition decisions. Has the authority to approve entry of an acquisition program into the next phase of the acquisition process and shall be accountable for cost, schedule, and performance reporting to higher authority, including congressional reporting.

Operations & Support (O&S)

Part of the Execution Phase of BCL. The purpose is to execute 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 lifecycle. 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.

Problem Statement The Problem Statement is the foundation of the Business Case and serves to inform that a business need exists; ensures that an analysis has been performed to consider whether it can be solved without a materiel solution (results of the DOTMLPF analysis); external influences have been identified; success factors have been defined and can be measured (i.e., how to know the business need no longer exists); and that the recommended solution is worthy of investment.

Program Charter A companion document to the Business Case, the Program Charter establishes the roles and responsibilities for the functional community, program office, and contractors. The Program Charter articulates the way in which a Program


FEBRUARY 2011 53

Manager will go about executing, monitoring, and controlling the implementation of the program; articulates the way in which a program team will go about the process of solving the business need defined by the Problem Statement in the Business Case; and is not duplicative in content.

Prototyping Demonstrates the capability of a software to meet business process requirements by installing IT in a relevant environment to gain the knowledge necessary to refine user requirements and inform APB development. During the Execution Phase, the PM conducts prototyping as outlined in the Business Case.

Tiered Accountability A management approach whereby DoD Components are empowered with responsibility and accountability for business investment and acquisition management.


FEBRUARY 2011 54

Appendix D: Acronyms ADM Acquisition Decision Memorandum AoA Analysis of Alternatives APB Acquisition Program Baseline ATP Authorization to Proceed BCD Business Capability Definition (Phase) BCL Business Capability Lifecycle BEA Business Enterprise Architecture BPM Business Process Management BPR Business Process Reengineering CA Certification Authority CAE Component Acquisition Executive CIO Chief Information Officer CJCSI Chairman of the Joint Chiefs of Staff Instruction CMO Chief Management Officer DAS Defense Acquisition System DBS Defense Business System DBSMC Defense Business System Management Committee DCAPE Director, Cost Assessment and Program Evaluation DCMO Deputy Chief Management Officer DDR&E Director, Defense Research and Engineering DDT&E Director, Developmental Test and Evaluation DEPSECDEF Deputy Secretary of Defense DKO Defense Knowledge Online DoD Department of Defense DoDI Department of Defense Instruction DoD CIO Department of Defense Chief Information Officer DOT&E Director, Operational Test & Evaluation DOTMLPF Doctrine, Organization, Training, Materiel, Leadership and education, Personnel,

and Facilities DSE Director, Systems Engineering ERAM Enterprise Risk Assessment Methodology ETP Enterprise Transition Plan FD Full Deployment FDD Full Deployment Decision FY Fiscal Year IM Investment Management (Phase) IOC Initial Operational Capability IOT&E Initial Operational Test & Evaluation IRB Investment Review Board IT Information Technology JCIDS Joint Capabilities Integration Development System JROC Joint Requirements Oversight Council


FEBRUARY 2011 55

MAIS Major Automated Information System MDA Milestone Decision Authority MDAP Major Defense Acquisition Program MDD Materiel Development Decision MS A Milestone A MS B Milestone B MS C Milestone C O&S Operations & Support OSD Office of the Secretary of Defense PEO Program Executive Office PM Program Manager SMP Strategic Management Plan T&E Test and Evaluation USD (AT&L) Under Secretary of Defense for Acquisition, Technology and Logistics

dod business capability lifecycle (bcl) guide (draft)

Business

bcl process

bcl applicability

bcl terminology

bcl information requirements

dod component level

chief management officer

process support

cost assessment