DoDI Business System Requirements and Acquisition

DoDI 5000.75 Business System Requirements and Acquisition
9/16/2018 DoDI Business System Requirements and Acquisition Presented By: David Pearson Director, Engineering and Technology Center Defense Acquisition University

9/16/2018 DoDI Purpose: Establishes policy for the use of the Business Capability Acquisition Cycle (BCAC) DBS that are MAIS must meet the statutory requirements of Title 10 U.S. Code, Chapter 144A, until its repeal takes effect Will not apply to: DBS that hit the MDAP threshold after MAIS goes away (OSD is working on a solution for this) DoDI Note: Click on DoD Instruction to access the report online. was issued on February 2, 2017, cancelling enclosure 12 of DoDI and an October 2014 DoD CIO memo on business systems. A collaborative document, it was approved by USD (AT&L), the DoD CIO and the Department’s Deputy Chief Management Officer This cycle is used to establish requirements and acquire defense business systems. Purpose: Establishes policy for the use of the Business Capability Acquisition Cycle (BCAC) DBS that are MAIS must meet the statutory requirements of Chapter 144A, until its repel takes effect Elimination of statutory requirements for Major Automated Information Systems (repeal of title 10 Chapter 144A -- effective September 30, 2017) Will not apply to: DBS that hit the MDAP threshold after MAIS goes away (OSD is working on a solution for this) 9/16/2018

Defense Business Systems should not be acquired like Weapons Systems!
9/16/2018 Why the Change to DoDI ? DoDI milestones, models and documentation did not provide the proper structure for managing business systems In practice… tailoring for a business system often took too much time and effort, making it hard to justify the benefits it produced DoDI Why this major change? The reason is that defense business systems are not the same as weapon systems. Think about the acquisition of a contracting writing system (mostly COTS hardware and software) versus the Joint Strike Fighter (new advance technology that will go in harm’s way). This is why a new instruction was created for Defense Business Systems. The is vague as compared to the , but was written that way to promote tailoring as much as possible. Defense Business Systems should not be acquired like Weapons Systems! 9/16/2018

Definitions Term Definition Business Capability
9/16/2018 Definitions DoDI Term Definition Business Capability Delivers products and services, provides value Defense Business System Information systems for: Finance Contracting Logistics Planning and Budgeting Installations Management HR Training and Readiness To set the stage, we need to start with some definitions We start with a “Business Capability-core ability an organization needs to deliver requisite products and services and provide value Examples of a business capability may be inventorying and delivering parts, a cost accounting process or managing property. These capabilities can be delivered through a variety of mechanisms, but today it is very likely the capability will be provided through some type of automated computer based system. Where the workflow of a business process is defined and then automated to ensure speed and accuracy. There are many examples, such as DTS for processing travel to MYPAY which automates the pay and accounting system. 9/16/2018

DOT&E DoD CIO USD DCMO (AT&L) DCAPE Policy and Oversight 9/16/2018
USD (AT&L)-Establishes policy and provides oversight for acquisition of the system DCMO- Certifies business system investments. DoD CIO- Oversight for Clinger Cohen Act Confirmation 9/16/2018

Policy and Oversight Policy: Aligned to commercial best practices
9/16/2018 Policy and Oversight Policy: Aligned to commercial best practices Minimize customization Business systems acquisition will facilitate business changes through doctrine, organization, training, materiel, leadership and education, personnel, facilities, and policy to drive performance improvements, efficiencies and effectiveness Business systems acquisition is the joint responsibility of the functional and the acquisition communities. Both communities are accountable for the successful delivery of business capability, from business process design through business system deployment and operations. BCAC 9/16/2018

9/16/2018 USD(AT&L) USD (AT&L) DOT&E DoD CIO DCAPE DCMO Establishes policy and provides oversight for acquisition of business systems Delegates milestone decision authority (MDA) for assigned business systems Policy and Oversight 9/16/2018

9/16/2018 DCMO or Component CMO USD (AT&L) DOT&E DoD CIO DCAPE DCMO Establishes policy and provides oversight for Chief Management Officer (CMO) certification of business system investments Maintains the Business Enterprise Architecture (BEA) and requires all functional strategies, capabilities, processes and systems to be reflected in the BEA Validation of business needs and identification of capability requirements for business systems Validates capability requirements for assigned business systems Policy and Oversight 9/16/2018

DoD CIO or Component CIO
9/16/2018 DoD CIO or Component CIO USD (AT&L) DOT&E DoD CIO DCAPE DCMO Establishes policy and confirms Clinger Cohen Act compliance Reviews and approves the cybersecurity strategy before decision points or contract awards All Chief Information Officer (CIO) reviews of IT infrastructure and hosting solutions Policy and Oversight 9/16/2018

DOT&E Oversight of the TEMP and IOT&E if on the DOT&E oversight list
9/16/2018 DOT&E USD (AT&L) DOT&E DoD CIO DCAPE DCMO Oversight of the TEMP and IOT&E if on the DOT&E oversight list Policy and Oversight 9/16/2018

9/16/2018 Director, CAPE USD (AT&L) DOT&E DoD CIO DCAPE DCMO Establishes policies and procedures for the collection of cost data, the conduct of all cost estimates and analysis of solution approaches for the acquisition of business systems. Policy and Oversight 9/16/2018

Roles in Business Systems Requirements & Acquisition
9/16/2018 Roles in Business Systems Requirements & Acquisition Functional Sponsor MDA Program Manager Functional Leader & PM Roles in Business Systems Requirements and Acquisition Click on the “yellow” names to open the text. Ex- click on Functional Sponsor to see their specific roles 9/16/2018

9/16/2018 Roles in Business Systems Requirements & Acquisition Functional Sponsor MDA Program Manager Functional Leader & PM Functional Sponsor Senior leader with business function responsibility Represents user community’s interests Leads Solution Analysis phase Leads change management Programs and budgets for lifecycle costs of solution Validates that the deployed capabilities meet business requirements, expected benefits and return-on- investment Roles in Business Systems Requirements and Acquisition Before going into more detailed coverage of the process, lets first define the roles of key players in the process. This begins with the functional sponsor 9/16/2018

9/16/2018 Roles in Business Systems Requirements & Acquisition Functional Sponsor MDA Program Manager Functional Leader & PM Milestone Decision Authority Approves critical acquisition decisions for Authority To Proceed (ATP) decision points or concurs in contractual commitments Oversees business system delivery within cost, schedule and performance parameters Establishes oversight controls Cost, schedule and performance reporting procedures Roles in Business Systems Requirements and Acquisition 9/16/2018

9/16/2018 Roles in Business Systems Requirements & Acquisition Functional Sponsor MDA Program Manager Functional Leader & PM Program Manager Leads development and delivery of the business system Provides input to the functional sponsor on process design, requirements, training and other matters that may influence the acquisition strategy for business systems. Roles in Business Systems Requirements and Acquisition 9/16/2018

9/16/2018 Roles in Business Systems Requirements & Acquisition Functional Sponsor MDA Program Manager Functional Leader & PM Functional Leader Leads Business Process Reengineering Executes business process change Leads definition of functional requirements Leads training and deployment Program Manager Leads development and delivery of the business system Provides input to functional sponsor on process design, requirements, training and other matters influencing the acquisition of the business system Roles in Business Systems Requirements and Acquisition Note: Click on the screen to get the Program Manager bullets to come up. 9/16/2018

Business System Categories
9/16/2018 Business System Categories Business System Category/ Reason for Designation Decision Authorities I Priority defense business system expected to have a total amount of budget authority over the period of the current Future Years Defense Program(FYDP) in excess of $250M; or DCMO designation as priority based on complexity, scope, and technical risk, and after notification to Congress. Requirements Validation / CMO Certification: DoD DCMO or as delegated MDA: DAE or as delegated (not below CAE) II Category II: $50M or more over FYDP Requirements Validation / CMO Certification: MILDEP CMO or as delegated; DoD DCMO or as delegated for all other DoD Components MDA: CAE or as delegated Category II business systems can also include systems that the DCMO or MILDEP CMO has designated as requiring CMO certification. III Below Category II Threshold All Decision Authorities: Same as category II, except CMO certification not required. Business System Categories These business systems are assigned to one of 3 categories as detailed in this table from the instruction. These categories align with section 2222 of Title 10 of U. S. Code DCMO- Deputy Chief Management Officer CAE-Component Acquisition Executive DAE-Defense Acquisition Executive 9/16/2018

9/16/2018 Requirements Process DBS do not follow the JCIDS process, unless special interest by JROC No Problem Statement Now called Capability Requirements CMO with support from the Functional Sponsor approves the Capability Requirements at the Solution Analysis ATP Capability Requirements must include: A description of the business problem or opportunity and its impact on cost and mission performance; Prioritized business capabilities and their attributes; Capability performance measures and associated current and future values, including threshold and objective values for future capability performance; and Relevant Laws, Regulations, and Policies Requirements Process DBS do not follow the JCIDS process, unless special interest by JROC No Problem Statement Now called Capability Requirements CMO with support from the Functional Sponsor approves the Capability Requirements at the Solution Analysis ATP Results in a Capability Requirement Document (CRD) Capability Requirements must include: A description of the business problem or opportunity and its impact on cost and mission performance; Prioritized business capabilities and their attributes; Capability performance measures and associated current and future values, including threshold and objective values for future capability performance. Relevant Laws, Regulations, and Policies 9/16/2018

Business Capability Acquisition Cycle (BCAC)
9/16/2018 Business Capability Acquisition Cycle (BCAC) BCAC Requirements for these business capabilities and the acquisition of systems which enable the capabilities are now developed by the Business Capability Acquisition lifecycle. Overall review of the process From the diagram you can see a 5 step process of Identifying the needed capability Conducting a business solution analysis Developing the business system’s functional requirements coupled with the development of acquisition plans Acquiring, testing and deploying the business system And then supporting that capability across the rest of its lifecycle. 9/16/2018

BCAC Authority To Proceed (ATP) are milestone-like-events
9/16/2018 BCAC Authority To Proceed (ATP) are milestone-like-events 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. Entrance criteria are tailorable Six ATPs ATP decisions must be documented through a formal memorandum. Approval indicates satisfaction of all statutory and regulatory requirements unless otherwise stated in the memorandum. BCAC The ATPs are: Solution analysis ATP. At this decision point: Requirements approved by CMO Work plan for solution analysis phase is approved Alignment with Business Enterprise Architecture (BEA), organizational strategy and IT portfolio management goals Functional Requirements ATP. At this decision point: The CMO validates that sufficient business process reengineering has been conducted to determine that a business system is required. The MDA approves execution of the implementation plan. The functional sponsor must provide full funding, to the approved cost estimate, available to support all of the business process activities being approved. Acquisition ATP. At this decision point: The MDA authorizes acquisition of the business system and approves continued execution of the updated implementation plan. The CMO approves initial CMO certification based on the chosen solution approach. 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. Limited Deployment (ATPs). 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. 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. Capability Deployment ATP. At this decision point: The functional sponsor accepts full deployment of the system and approves transition to capability support. 9/16/2018

ATP Decision Authorities
9/16/2018 ATP Decision Authorities Decision Point Decision Authority or Authorities Solution Analysis ATP CMO Functional Requirements ATP CMO (requirements validation) MDA (materiel solution) Acquisition ATP CMO (CMO certification) MDA (acquisition strategy) Limited Deployment ATP MDA Full Deployment ATP Capability Support ATP Functional sponsor BCAC 9/16/2018

BCAC Phases Functional Requirements and Acquisition Planning
9/16/2018 BCAC Phases BCAC Phases Functional Requirements and Acquisition Planning Functional Sponsor MDA PM Cost agency determines solution approach which best fits the need and organizational goals Information requirements Acquisition ATP Acquisition Testing and Deployment Achieve organizational change through business process changes and delivery of the supporting business system, with minimal customization. Information requirements Limited Deployment ATP Full Deployment ATP Capability Support ATP Capability Support Provide enduring support for the capability established by the business system Information requirements Business Solution Analysis Phase Determines the high level business processes which support the future capability. Information requirements Functional Requirements ATP Capability Need Identification Establishes a clear understanding of needed business capabilities based upon: Future capabilities are based upon the reengineering of future business processes Information requirements Solution analysis ATP 1`Note: Clicking the plus signs next to each phase will open up a pop-up window. Capability Need Identification Led by functional lead, supported by PM Performance measures include current and future values, threshold and objective values for future capability performance. Establishes a clear understanding of needed business capabilities based upon: Desired end state in a business mission area The problems which prevent us from achieving that end state The future capabilities required to achieve the end state Future capabilities are based upon the reengineering of future business processes Selecting and tailoring commercial best practices Includes an industry analysis to identify processes which could be adopted Information requirements Business problem description/opportunity and impact Performance measures Implementation plan Solution Analysis Phase Solution Approach should answer how we are going to use the system Determines the high level business processes which support the future capability. Maximize use of existing solutions Minimize the creation of new requirements which can only be satisfied with a business system Market Research Implementation Plan (Note- not a document) All business changes needed to deploy the capability to include cost benefit analysis Functional Requirements and Acquisition Planning Functional requirements and solution approach are the coresponsibility of both the functional lead and PM Functional Sponsor Leads execution of business process actions Defines IT functional requirements Determines overall solution approach MDA Oversees development of acquisition strategy PM Engages with industry to ensure functional requirements reflect the latest state of the practice Starts to develop design specifications Cost agency determines solution approach which best fits the need and organizational goals Functional requirements Draft RFP Acquisition Testing and Deployment Led by PM, supported by functional lead Achieve organizational change through business process changes and delivery of the supporting business system, with minimal customization. Full Deployment-delivery of full functionality to all planned users Limited deployment-any deployment which does not provide full functionality Design Specifications Test results Capability Support plan Capability Support Provide enduring support for the capability established by the business system Continuous process improvement to include supporting technology and hosting solution Achieved through tailored implementation plans 9/16/2018

BCAC Overview 9/16/2018 BCAC Phases
This graphic is a summary of activities/products required for each phase. 9/16/2018

DoDI 5000.75 compared to DoDI 5000.02, Model 3
9/16/2018 DoDI compared to DoDI , Model 3 New DoDI model Similar to RFP Release & MS B (for some programs) New Combined Problem Statement Approval & MDD Full Deployment Limited & Full Deployment Decisions DoDI Model 3 BCAC Phases This slide shows the relationship between the Model 3 from the DoDI and the new model based on DoDI Most of the decision points are similar except the Solution Analysis ATP- which is new. The Acquisition ATP now combines the Development RFP Release Decision and Milestone B decisions. 9/16/2018

DoDI 5000.75 Entrance Points 9/16/2018
Starting Over Minor Modifications Going back to the beginning of BCAC Software version upgrade which requires significant BPR LRP change which drives modification to software or process Organizational realignment which modifies roles and responsibilities Major budget cuts Entering BCAC at a mid-point step Software version upgrade which doesn’t require major process change (i.e., “fact of life”) Going back to the beginning of BCAC Software version upgrade which requires significant BPR LRP change which drives modification to software or process Organizational realignment which modifies roles and responsibilities Major budget cuts Entering BCAC at a mid-point step Software version upgrade which doesn’t require major process change (i.e., “fact of life”) BCAC Phases Click on words at the bottom to see the pop-ups, and click on the words Starting Over and Minor Modifications to see the pop-ups. New programs: enter into BCAC like you would the DoDI Programs in development: Only revise your documentation in the case it makes sense – leverage what you already have; map things to BCAC requirements and see where gaps may exist MAIS: a memorandum that will transition all existing MAIS programs over to the right business systems category and MDA Non-MAIS: MDA should provide guidance to transition you to BCAC and place you into the right category Programs in sustainment: You don’t need to do anything unless you have to modernize, upgrade, etc. Minor Changes should have some kind of explanation with it that indicates that minor changes won't go through ATP decisions by the MDA, rather they fall under the governance structure MAIS: a memorandum that will transition all existing MAIS programs over to the right business systems category and MDA Non-MAIS: MDA should provide guidance to transition you to BCAC and place you into the right category Programs in sustainment: You don’t need to do anything unless you have to modernize, upgrade, etc. Programs in development: Only revise your documentation in the case it makes sense – leverage what you already have; map things to BCAC requirements and see where gaps may exist New programs: enter into BCAC like you would the DoDI 9/16/2018 New Programs Programs in development MAIS Non-MAIS Programs in Sustainment

9/16/2018 Program Management The program manager, with support from the functional lead and the appropriate cost agency, establishes criteria for evaluating potential business system solutions. Program managers will apply commercial best practices and lessons learned to recommend tailoring for business system programs and to develop and deploy business capabilities 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. 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 Functional Responsibilities 9/16/2018

Program Management (cont.)
9/16/2018 Program Management (cont.) The acquisition strategy reflects the solution approach and describes how the program manager will identify potential business system solutions and perform solution selection. The program manager will provide draft RFPs that align to the acquisition strategy for the contract actions that follow the Acquisition ATP The functional lead, with support from the program manager, identifies tailored implementation plans for changes that support continuous process improvement during the Acquisition, Testing and Deployment Phase The functional lead and program manager are jointly responsible for change management. Functional Responsibilities 9/16/2018

9/16/2018 Program Management (cont.) Implementation Plans: Provide sufficient detail on the work to be performed to manage the delivery of the capability and support leadership decision Tailored to a level of detail appropriate for progress through the cycle. Functional Responsibilities Implementation plan is not a document 9/16/2018

9/16/2018 Program Management (cont.) Implementation Plan Content: Reference information Decision points with governance details Description of business process actions and responsibilities Description of acquisition actions and responsibilities Master Schedule Work Breakdown Structure Acquisition objectives: business goals, ROI, BCA Tailored business system acquisition strategy Functional Responsibilities 9/16/2018

9/16/2018 Program Management (cont.) Change Management: Proactively prepares the functional community for upcoming changes Reduce risk while increasing user adoption Ensure user training over the lifecycle Responsibility of both Functional lead and Program Managers Critical to project success Functional Responsibilities 9/16/2018

9/16/2018 Program Management (cont.) Earned Value Management reporting is a requirement that may or may not apply depending on the value and type of contract. Business systems are not exempt from EVM. Functional Responsibilities 9/16/2018

Capability Requirements Functional Requirements
9/16/2018 Engineering Systems engineering practices should be leveraged for the technical management of the project. Capability Requirements Delivered Capability Functional Requirements Validated Solution Realization Decomposition Inputs Outputs Design Product The slide states, “Systems engineering practices should be leveraged for the technical management of the project.” So what does this mean? The engineering team will be involved with: (a) definition of functional requirements; (b) software design, development and testing; (c) coordination of interface control agreements; (d) identifying risks and issues; (e) developing work break-down structures; (f) development evaluation framework; and (g) Develop the design specification based on a fit-gap analysis Also, the system engineering team will decide what technical reviews are necessary for their specific program. The team may decide a System Requirement Review and a System Functional Review are required, but a Preliminary Design Review is not necessary. DAG Chapter 3 discusses the SE processes and that DASD(SE) has adopted IEEE Standard for Technical Reviews and Audits (available free for govt use via DLA ASSIST only). Functional Responsibilities 9/16/2018

9/16/2018 Engineering Design specifications are based upon the high-level requirements established during functional requirement definition. This includes the functional requirements, along with associated inputs and outputs for the functional requirements, and associated technical and lifecycle support requirements. Design specifications will reflect fit-gap analysis and prioritization of features to allow for cost and schedule trades within scope. Specifications are based upon high level functional, technical and support requirements Provide sufficient detail to support delivery and verification of the solution Prioritized to allow cost and schedule trades Functional Responsibilities 9/16/2018

9/16/2018 Testing If on DOT&E Oversight List- must have TEMP, if not on oversight list- no TEMP is required, but the test strategy must be addresses in the in acquisition strategy 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. 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. Functional Responsibilities 9/16/2018

Developmental Testing:
9/16/2018 Testing (cont.) Developmental Testing: Test events to collect data must be defined, scheduled, and resourced in the implementation plan, including a Developmental Evaluation Framework matrix for developmental testing events. Interoperability developmental T&E will include testing with actual representations of interface systems in a controlled environment. Initial Operational Test and Evaluation (IOT&E): 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. If not on DOT&E Oversight List, IOT&E is not statutorily required Functional Responsibilities 9/16/2018

Testing (cont.) Test results:
9/16/2018 Testing (cont.) 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. Functional Responsibilities 9/16/2018

Cybersecurity Testing & Evaluation
9/16/2018 Cybersecurity Testing & Evaluation Cybersecurity developmental and operational T&E must include cooperative vulnerability identification and adversarial cybersecurity testing. Cybersecurity operational T&E must also include a Cyber Economic Vulnerability Analysis as outlined in September 14, 2010 and January 21, 2015 DOT&E Memoranda. The MDA will not tailor cybersecurity T&E solely to meet authority to operate requirements. Functional Responsibilities 9/16/2018

9/16/2018 Logistics Capability Support Plan. The capability support plan documents the roles, responsibilities for sustainment activities. The capability support plan must include: A governance structure that provides resources, prioritizes changes, and approves implementation plans for changes that fall within scope of the original capability requirements, 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, and Plans for conducting a post implementation review. For the PIR- The Functional Sponsor, in coordination with the DoD Component Chief Information Officer (CIO) and Program Manager, plans and conducts a PIR for all fully deployed Information Technology (IT). PIRs report the degree to which doctrine, organization, training, materiel, leadership and education, personnel, facilities, and policy (DOTmLPF-P) changes have achieved the established Measures of Effectiveness (MOEs) for the desired capability; evaluate systems to ensure positive return on investment; decide whether continuation, modification, or termination of the systems is necessary to meet mission requirements; and document lessons learned. Functional Responsibilities 9/16/2018

Documents & Deliverables (cont.)
9/16/2018 Documents & Deliverables (cont.) 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. Decision Point Statutory Requirements Solution Analysis None Functional Requirements ATP Acquisition ATP Solution approach (fulfills analysis of alternatives and economic analysis) Limited Deployment ATP Cybersecurity Strategy (for mission essential IT) Full Deployment ATP CCA compliance (separate documentation of CCA compliance isn’t required) Capability Support ATP Documents and deliverables has total changed from the DoDI to DoDI The amount of requirement and acquisition documentation has dramatically been reduced. The table on this slide shows the statutory requirement documents, which is not very many. Documents & Deliverables 9/16/2018

Documents & Deliverables (cont.)
9/16/2018 Documents & Deliverables (cont.) Listed below are some documents that are no longer required: Acquisition Program Baseline (APB) Life Cycle Sustainment Plan (LCSP) Systems Engineering Plan (SEP) Concept of Operations (CONOPS) Problem Statement Program Protection Planning This just more confirmation that documents will generally not be prepared solely for staff review and approval, but be intended primarily for use within the program. For example, if the program offices decides that they need to write a Systems Engineering Plan they can, but the DoDI does not mandate it. Documents & Deliverables Information-centric approach to evaluating programs rather then reliance on acquisition and requirements documents 9/16/2018

Governance Defense Acquisition Board (DAB)
9/16/2018 Governance Defense Business Council (DBC) Defense Acquisition Board (DAB) Provides advice to the DAE or designee on critical decisions concerning acquisition programs 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 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 Defense Business Council (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, Developing requirements for business systems and 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. Defense Acquisition Board (DAB) Configuration Steering Board Click to open DBC, DAB and CSB for text for each. The Council shall be chaired by the Under Secretary of Defense for Business Management and Information 1 and the Chief Information Officer of the Department of Defense. Membership.—The membership of the Council shall include the following: (A) The Chief Management Officers of the military departments, or their designees. (B) The following officials of the Department of Defense, or their designees: (i) The Under Secretary of Defense for Acquisition, Technology, and Logistics with respect to acquisition, logistics, and installations management processes. (ii) The Under Secretary of Defense (Comptroller) with respect to financial management and planning and budgeting processes. (iii) The Under Secretary of Defense for Personnel and Readiness with respect to human resources management processes. Governance 9/16/2018

For more formation, please click on:
9/16/2018 Summary DoDI removes DBS from the DoDI , except Will not apply to DBS that hit the MDAP threshold after MAIS goes away (OSD is working on a solution) BCAC model Five phases Six ATP (similar to a milestone event) Tailorable process Three Business System Categories Category I- FYDP in excess of $250,000,000 or DCMO designation Category II- FYDP in excess of $50,000,000 Category- does not meet criteria for category II Teaming approach for acquisition with limited documentation Functional Sponsor Functional Lead Program Manager Governance to address Version upgrades, technical refresh, Capability gaps and cost impacts Prioritization and funding Summary For more formation, please click on: 9/16/2018

Point of Contact for DAU
9/16/2018 Point of Contact for DAU David Pearson Director, Engineering and Technology Center Defense Acquisition University (703) Point of Contact 9/16/2018

DoDI Business System Requirements and Acquisition

Similar presentations

Presentation on theme: "DoDI Business System Requirements and Acquisition"— Presentation transcript:

Similar presentations

About project

Feedback

Log in

Auth with social network:

DoDI Business System Requirements and Acquisition

Similar presentations

Presentation on theme: "DoDI Business System Requirements and Acquisition"— Presentation transcript:

Similar presentations

About project

Feedback