DODI 5000.75 Procedures


a. Tailoring. The procedures used to develop  business capability  A business capability is the core ability the organization needs to deliver requisite products and services and provide value. requirements and supporting systems will be tailored to the characteristics of the capability being acquired. Tailoring will focus on application of best practices to the totality of circumstances associated with the program, including affordability, urgency, return on investment, and risk factors. The functional sponsor, MDA, and CAE or designee will collaborate to tailor program strategies and oversight, including: program information, acquisition phase content, and the timing and scope of decision reviews and decision levels.

b. ATP Decision Points. Decisions will be informed by measures that assess the readiness to proceed to the next phase of the process. Decision-making will focus on executability and effectiveness of planned activities, including cost, schedule, acquisition strategy, incentive structure and risk.

(1) All decisions are coordinated across stakeholders and made in a collective forum so that the decision authority is fully informed by the stakeholders at each decision point.

(2) Depending on the decision point, either the Defense Business Council (DBC) or Defense Acquisition Board (DAB), or Component equivalents, will advise the decision authorities.

(3) Decision authority is determined by phase content and type of decision being made. Decision authorities are described in more detail by phase in this section and summarized in Table 3 of Appendix 4A.

(4) After the Functional Requirements ATP, the timing and number of all subsequent decision points are established as part of the implementation plan.

(5) Statutory requirements, such as Clinger-Cohen Act compliance, that are normally associated with acquisition milestones must be completed and aligned with an appropriate decision point; statutory requirements cannot be waived unless the statute permits. Statutory requirements for decision points are summarized in Table 4 of Appendix 4A.

(6) ATP decisions must be documented through a formal memorandum. Approval indicates satisfaction of all statutory and regulatory requirements unless otherwise stated in the memorandum. Information materials that supported the decision must be maintained in accordance with DoD records management procedures.

(7) Considerations for decision criteria to use in support of decision points are included in Appendix 4A.

c. Governance.

(1) DBC. The DBC provides advice to the Secretary and Deputy Secretary of Defense on developing the BEA, reengineering the Department’s business processes, developing and deploying business systems, and developing requirements for business systems. It is the requirements validation authority for business systems. The DBC will convene for decision points up to and including the Functional Requirements ATP for category I business systems. The MDA or designee will participate in DBC decisions that impact their program.

(2) DAB. The DAB provides advice to the DAE or designee on critical decisions concerning acquisition programs. The DAB will convene for decision points from Acquisition ATPs and beyond where the DAE is the MDA. The DBC chairs will serve as members or advisors of the DAB for decision reviews for business systems.

(3) Configuration Steering Board. A steering board will be established for each program to adjudicate unresolved issues between the functional and acquisition communities involving potential customization or process changes. The steering board will consider development cost, schedule implications, and impacts to sustainment in its decision processes. Steering board membership will include the functional sponsor (co-chair), CAE or designee (co-chair), and resource sponsors.

(4) Director, Operational Test & Evaluation (DOT&E) Oversight. Governance boards for business systems on the DOT&E Oversight List will include DOT&E as a member.

d. Change Management.  Change management The process of proactively preparing the user community for changes that will occur to an organization (because of the implementation of a business system, for purposes of this issuance). proactively prepares the functional community for upcoming changes from the delivery of a  business capability  A business capability is the core ability the organization needs to deliver requisite products and services and provide value. in order to reduce risk and increase user adoption. Change management tasks span the lifecycle of the product’s delivery and include the development and delivery of training materials and ongoing capability improvements addressed in the support phase. The functional lead and program manager are jointly responsible for change management.

e. Budgeting by Functional Capability and IT Portfolio. Every phase outlined in this document will be funded in the planning, programming, budget, and execution process. To facilitate this, functional capability and IT portfolio program elements will be established by Components to fund business need definition and business solution design efforts. Funding program elements will be established for requirements development through deployment and capability support.

f. Continuous Process Improvement. The functional sponsor will engage in continuous process improvement throughout all phases of the BCAC, based on opportunities that emerge in analysis of existing capabilities, processes, and supporting IT in use within the existing organization and at other organizations. The functional sponsor will prioritize these continuous process improvement opportunities for current and future initiatives.

g. Industry Analysis and Market Research. The functional sponsor and CAE or designee must provide access to domain experts with functional and technical knowledge to support industry analysis of processes from industry and government for capability delivery options. These domain experts must guide the development of business requirements without preferring business systems over business process improvements. Market research will identify specific business systems available to support future processes.

h. Prototyping and Demonstrations. Program managers will incorporate prototyping, to the extent practical, and demonstrations to support market research and selection of specific products and services. Program managers will provide the MDA with the expected improvements that prototyping and demonstration will provide at an acceptable cost.

i. Incremental Delivery of Capability. Functional leads and program managers will apply commercial best practices and lessons learned to recommend tailoring for business system programs and to develop and deploy business capabilities. Functional leads and program managers will normally standardize planning and management of business systems by releases and deployments.

(1) A release is a manageable subset of functionality that provides utility in support of the engineered business processes. The utility provided by a release does not have to fulfill the entire future process. Additional utility may be added through iterative releases based on user feedback to minimize risk and increase adoption.

(2) A deployment either introduces a new release into the production environment or expands the user base of existing functionality. Deployment includes training and business systems operations activities such as help desk support.

(3) The functional sponsor and CAE or designee may establish increments of business system programs to organize tracking and reporting of releases grouped by increment.

j. Integrated Testing. The CAE or designee will oversee effective use of integrated testing, combining developmental and operational testing where practical. When supported by the appropriate risk analysis, assessments will primarily use data from integrated test events other than a dedicated independent operational test event. For programs on DOT&E Oversight List, the level of test and use of integrated test data as well as dedicated operational test events should be approved by DOT&E using guidance provided by September 14, 2010 DOT&E Memorandum.

k. Delegation. Decision authorities in Table 3 will evaluate remaining risk in business system programs at each decision point and delegate authority, when appropriate, to empower leaders to provide timely guidance and decisions. Specifically, the Acquisition ATP represents significant risk removal, and decision authorities should structure delegation so that leaders can provide timely decisions in support of leveraging COTS/GOTS functionality.

l. Documentation and Deliverables. Information deliverables will generally not be prepared solely for staff review and approval, but be intended primarily for use within the program either as products used in later phases of the process or as planning and management tools. The information produced will be specific to each program and tailored to meet individual program needs. Details will be maintained by the program in a transparent and timely fashion, available for oversight reviews as needed.


Figure 2 illustrates the five phases in the process. The BCAC is intended to be cyclical and flexible with phases repeating as necessary to drive timely achievement of outcomes.

Figure 2: High-Level BCAC Process

a. Capability Need Identification. The functional sponsor leads this phase with guidance and support from the CMO. The objective is to establish a clear understanding of needed business capabilities so that the functional sponsor and MDA can decide to invest time and resources into investigating business solutions.

(1) Phase Description.

(a) The capability need is based on the desired end state in a business mission area, the problem(s) preventing it, and the future capabilities required to achieve it.

(b) Definition of the future capabilities will include analysis of other organizations with similar capability needs.

(2) Solution Analysis ATP. At this decision point, the CMO, with input from the functional sponsor, approves the capability requirements, approves the work planned for the next phase, and verifies the capability is aligned with the BEA as well as organizational strategy and IT portfolio management goals.

(3) Information Requirements. Machine searchable capability requirements must be provided for the Solution Analysis ATP. Capability requirements must include:

(a) A description of the business problem or opportunity and its impact on cost and mission performance.

(b) Prioritized business capabilities and their attributes.

(c) Capability performance measures and associated current and future values, including threshold and objective values for future capability performance.

(d) Pertinent law, regulations and policies that will either require modification or constrain solutions.

b. Solution Analysis. The functional sponsor leads this phase with guidance from the CMO and support from the CMO and CAE or designee. The objective of this phase is to determine the high-level business processes supporting the future capabilities so that the functional sponsor and CAE or designee can maximize use of existing business solutions and minimize creation of requirements that can only be satisfied by a business system.

(1) Phase Description.

(a) Future capabilities are based on reengineering the high-level future business processes that will deliver the capabilities. This includes selecting and tailoring commercial best practices to meet the needs of the end user community.

(b) Definition of the future capabilities will include industry analysis of other organizations with similar capabilities to identify processes that can be adopted.

(c) The initial implementation plan to achieve the future capabilities will include all business changes to deploy the capabilities, including a rough order of magnitude estimate and cost benefit analysis for any business systemInformation systems that are operated by, for, or on behalf of the DoD, including: financial, contracting, logistics, planning and budgeting, installations management, human resources management, and training and readiness..

(2) Functional Requirements ATP. At this decision point:

(a) The CMO validates that sufficient business process reengineering has been conducted to determine that a business system is required.

(b) The MDA approves execution of the implementation plan.

(c) The functional sponsor must provide full funding, to the approved cost estimate, available to support all of the business process activities being approved.

(3) Information Requirements.

(a) Business Processes. High-level business processes must be structured to focus on the work to be conducted and on the information used, not supporting IT.

(b) Market Research. Market analysis must reflect engagement with other organizations with similar capabilities to understand their business process and supporting COTS/GOTS solutions.

(c) Implementation Plan. In this phase, the implementation plan contains detailed plans for business process actions and high-level schedule and resource plans for acquisition actions. Additional information on the implementation plan is in Appendix 4B.

c. Functional Requirements and Acquisition Planning. During this phase, the functional sponsor leads execution of business process actions in the implementation plan, definition of IT functional requirements, and determination of overall solution approach (e.g., COTS, GOTS, legacy modernization, or new development). Meanwhile, the MDA oversees development of the acquisition strategy. An objective of this phase is to establish the acquisition strategy that will support functional requirements.

(1) Phase Description.

(a) Functional requirements describe how the business system will achieve the future business processes.

(b) The program manager engages further with industry (e.g., market research, benchmarking, requests for information, industry days) so that functional requirements reflect the current state of practice and inform the acquisition strategy. Additional information on requirements is included in Appendix 4D.

(c) The appropriate cost agency will support development of alternatives and determination of the solution approach that best fits the needs and organizational goals based on economic analysis in accordance with DoDI 7041.03.

(d) The acquisition strategy reflects the solution approach and describes how the program manager will identify potential business system solutions and perform solution selection. Additional information on potential business system solutions is included in Appendix 4D.

(e) The program manager may, with the approval of the MDA, conduct design specification activities normally conducted after the Acquisition ATP to inform the acquisition strategy.

(2) Acquisition ATP. At this decision point:

(a) The MDA authorizes acquisition of the business system and approves continued execution of the updated implementation plan.

(b) The CMO approves initial CMO certification based on the chosen solution approach. Additional information on CMO certification is in Appendix 4C.

(c) The MDA will require full funding, to the approved cost estimate, for the program to be available to support all of the acquisition activities approved at this decision.

(3) Information Requirements.

(a) Functional Requirements. Functional requirements will include enough detail to inform definition of potential business system solutions and evaluation criteria, but without including too much detail that would overly constrain solution selection.

(b) Implementation Plan. During this phase, the implementation plan contains detailed plans, including resource loaded schedules, for actions required to deploy the future business processes. Additional information on the implementation plan is in Appendix 4B.

(c) Draft Request for Proposal (RFP). The program manager will provide draft RFPs that align to the acquisition strategy for the contract actions that follow the Acquisition ATP.

d. Acquisition, Testing, and Deployment. During this phase, the CAE or designee leads execution of contract award, supplier management, establishment of baselines, delivery of the business system, and risk management. Meanwhile, the functional sponsor leads training and deployment. The objective of this phase is to achieve organizational change through business process changes and delivery of the supporting business system, with minimal customization.

(1) Phase Description.

(a) Detailed fit-gap analysis follows solution selection based on the acquisition strategy. Fit-gap analysis will be based on the known capabilities of the COTS/GOTS software in the selected business system solution.

(b) Design specifications will reflect fit-gap analysis and prioritization of features to allow for cost and schedule trades within scope.

(c) Development, delivery and capability support plans for the business system will be detailed in the implementation plan, expressed in terms of releases and deployments.

1. A limited deployment is any deployment before the Full Deployment ATP that does not provide full functionality to all planned users of the business system. Limited deployments will be approved at a Limited Deployment ATP.

2. The MDA will require adequate testing before Limited and Full Deployment ATPs. For business systems on the DOT&E Oversight List, DOT&E will approve all operational test plans, and an Initial Operational Test and Evaluation will be conducted before the Full Deployment ATP.

3. Full deployment is the delivery of full functionality planned to all planned users of the business system in accordance with the Full Deployment ATP.

(d) The CAE or designee will oversee establishment of cost, schedule and performance parameters for each release before development or delivery.

(2) Limited Deployment ATP(s). At this decision point, the MDA, in conjunction with the functional sponsor, considers the results of developmental and operational testing and approves deployment of the release to limited portions of the end user community.

(3) Full Deployment ATP. At this decision point, the MDA, with the support of the functional sponsor and CMO, considers the results of limited deployment(s) and operational testing and approves deployment to the entire user community.

(4) Capability Support ATP. At this decision point, the functional sponsor accepts full deployment of the system and approves transition to capability support.

(5) Information Requirements.

(a) Design Specifications. The design specifications satisfy the intent of a DoD CIO information support plan required by DoDI 8330.01. A separate information support plan document is not required for business systems developed in accordance with this issuance.

(b) Test results. Supporting information for a Limited Deployment ATP or Full Deployment ATP must include the status of training and test results. This includes developmental or operational testing before the decision point based on the level of operational risk associated with the capability deployment.

(c) Implementation Plan. The program manager updates the implementation plan throughout this phase to reflect releases, deployments, and capability support beginning with the first deployment.

(d) Capability Support Plan. The capability support plan documents the roles, responsibilities for sustainment activities. The capability support plan must include:

1. A governance structure that provides resources, prioritizes changes, and approves implementation plans for changes that fall within scope of the original capability requirements.

2. A threshold for changes to determine whether or not the change requires a new BCAC initiative. Major capability changes that do not fall within the scope of the original capability requirements will require re-initiation of the process.

3. Plans for conducting a post implementation review.

e. Capability Support. The functional sponsor leads this phase with support from the CAE or designee. The objective of this phase is to provide enduring support for the capability established by the business system. This includes active engagement in both functional and technical opportunities for continuous process improvement to maintain the relevance of the capability, the supporting technology, and the hosting solution.

(1) Phase Description. The functional lead, with support from the program manager, identifies tailored implementation plans for changes that support continuous process improvement. The program manager and functional lead execute the implementation plans and update applicable enterprise architecture repositories to reflect capability changes.

(2) Information Requirements. The functional lead and program manager develop tailored implementation plans and information requirements for this phase.

Share This