DAI_System_Engineering_Plan_ver_5.4_-__Nov_2018_Redacted.pdf

OPR: Defense Agencies Initiative (DAI)

Defense Agencies Initiative

SYSTEMS ENGINEERING PLAN (SEP)

VERSION 5.4

Date: November 13, 2018

Contents Approved by:

1. Introduction – Purpose and Update Plan

1.1 Program Overview

1.2 DAI Stakeholders

2. Program Technical Requirements

2.1 Architectures and Interface Control

2.2 Technical Certifications

2.3 Solution Description

2.4 Joint Capabilities Integration and Development System (JCIDS)

3. Engineering Resources and Management

3.1 Technical Schedule and Schedule Risk Assessment

3.2 Engineering Resources and Cost/Schedule Reporting

3.3 Engineering and Integration Risk Management

3.4 Technical Organization

3.5 Relationship with External Technical Organizations

3.6 Technical Performance Measures and Metrics

4. Technical Activities and Products

4.1 Previous Phase SE Activities

4.2 Technical Reviews for Increment 3

4.3 Requirements Development and Change Process

4.4 Technical Reviews

4.5 Configuration and Change Management

4.6 Design Considerations

4.7 Engineering Tools

Annex A – DAI Integrated Dictionary (AV-2) Annex B – DAI Key References and Sources

Tables and Figures

Tables Table 1.1-1 SEP Update Record…………………………………………………………………………..…..6 Table 2.1-1 Required Memoranda of Agreement………………………………………………………… Table 2.2-1 Certification Requirements……………………………………………………………..………...18 Table 2.4-1 Joint Capability Areas to BEA v10.0 Operational Activities Mapping…………………..… Table 3.1.3-1 Scheduling Roles and Responsibilities………………………………………………………….30 Table 3.2.1-1 EVM Inputs and Descriptions…………………………………………………………………….34 Table 3.2.1-2 EVM Process Entry Criteria………………………………………………………………………35 Table 3.2.2-1 Output Products and Descriptions……………………………………………………………….36 Table 3.2.2-2 EVM Process Exit Criteria…………………………………………………………………......…36 Table 3.4.1-1 DAI Program Roles and Responsibilities………………………………………………………..38

Table 3.4.4-1 IPT Team Details……………………………………………………………………………..……42 Table 3.6-1 Critical Technical Parameters (Technical Performance Measures 1 of 2)………………..…48 Table 3.6-2 Key Performance Parameters and Key System Attributes (Technical Performance Measures 2 of 2)……………………………………………………………………………………………………………………..51 Table 3.6-3 Reliability, Availability, Maintainability (RAM) Metrics…………………………………………71 Table 4.1-1 Increment 3 Systems Engineering Activities……………………………………………………73 Table 4.3.2.3-1 Justification Categories……………………………………………………………………………85 Table 4.4-1 to 6 Technical Review Details……………………………………………………………………… Table 4.5-1 DAI Operational Severity……………………………………………..…………………………..102 Table 4.6-1 Design Considerations.105 Table 4.6-2 R&M Activity Planning…………………………………………………………………………….110 Table 4.7-1 Engineering Tools…………………………………………………………………………………111

Figures Figure 1.1-1 DAI Releases for Increment 3 ………………..………………………………………………….8 Figure 2.1.2-1 DAI High Level Operational Concept Graphic (OV-1)…………………………………………11 Figure 2.1.2-2 DAI High Level End-to-End Business Process Flows…………………………………………11 Figure 2.1.3-1 Systems Physical Architecture…………………………………………………………………..13 Figure 2.1.3-2 Network Architecture……………………………………………………………………………...14 Figure 2.1.4-1 DAI Global Interface Architecture (SV/SvcV-1)………………………………………………..15 Figure 3.1-1 Schedule Coordination between tiers…………………………………………………………...29 Figure 3.1-2 System Technical Schedule……………………………………………………………………...32 Figure 3.4.1-1 Program Office Organization……………………………………………………………………..37 Figure 3.4.2-1 Program Technical Staffing…………………………………………………………………....…40 Figure 3.4.4-1 IPT Team Hierarchy……………………………………………………………………………….41 Figure 4.3.1-1 Requirements Decomposition/Specification Tree/Baselines……………………………...….80 Figure 4.3.1-2 Requirements Decomposition Process……………………………………………………… Figure 4.3.2.1-1 DAI Requirements Review Process……………………………………………………………..83 Figure 4.5-1 Configuration Management Process…………………………………………………………….100 environment through architecture standardization, consolidation of functions, investment accountability, and systems upgrades. Commercial, off-the-Shelf (COTS) Enterprise Resource Planning (ERP) solutions continue to be an important part of addressing these challenges for the Department and across the Federal Government. Further, COTS ERP vendors continue to mature their technology through new releases to meet evolving business, technology, security and control requirements and to improve overall integration, efficiency and usability.

In the 2008 National Defense Authorization Act (NDAA) (Section 1005), Congress formally established the Defense Agencies Initiative (DAI) as the target financial management transformation initiative for the Defense Agencies, with the following core purposes:

To eliminate or replace financial management systems of the Defense Agencies that are duplicative, redundant, or fail to comply with the standards set forth in the Federal Financial Management Improvement Act (FFMIA), and other relevant Federal and Defense-wide policies.

To transform the budget, finance, and accounting operations of the Defense Agencies to enable the Defense Agencies to achieve accurate and reliable financial information needed to support financial accountability and effective and efficient management decisions.

The 2008 NDAA further prescribed the required elements of the DAI program:

Utilization of commercial, off-the-shelf technologies and web-based solutions A standardized technical environment and an open and accessible architecture Implementation of common business processes, shared services, and common data structures Capabilities within the following process areas for general funds:

o Budget formulation o Budget to report, including general ledger and trial balance o Procure to pay, including commitments, obligations, and accounts payable o Order to cash, including billing and accounts receivable o Cost accounting o Acquire to retire (account management) o Time and attendance and employee entitlement o Grants Financial Management

DAI Increments 1 and 2 successfully implemented capabilities that align with meeting the Department’s needs for establishing an auditable and efficient business environment for the Defense Agencies and meeting congressionally mandated requirements for auditability.

To further comply, the DAI Increment 3 Implementation Plan will be used to guide the evaluation of the gaps with their associated risks, challenges and opportunities that exist in the current business environment and to define and justify an investment in Increment 3, using a sound approach aligned to achieving measurable business outcomes. This evaluation also establishes scope and implementation recommendations for Increment 3 and intends to facilitate determination and direction by the Milestone Decision Authority (MDA) and Defense Business Council (DBC) approval for continued program investment.

Gaps/Opportunities identified for the DAI program are categorized and evaluated as follows:

COTS ERP Technical upgrade requirement. Premium vendor support of the current software supporting the DAI program will reach end of support by October 2023. A technical upgrade of the Oracle software will provide for continuity of full spectrum vendor support. The upgrade is expected to include many improvements to current functionality that will enable savings, as well as improved integration within the business systems environment.

Migrate additional Defense Agencies to DAI and retire legacy financial systems. While several Defense Agencies have completely transitioned from legacy financial systems to DAI, additional Agencies still need to be transitioned. A total cost savings from retirement of many of these systems cannot be realized until all Agencies using them transition to a target solution, enabling a complete shutdown of those systems.

Develop and implement additional in-scope functional capabilities, including Defense Working Capital Fund (DWCF), Re-Sale Accounting, and maturation of current processes.

o The number of Agencies and activities that continue to rely on non- US Standard General Ledger (USSGL) compliant and non-integrated core financial and feeder systems directly impact the cost and risk of successfully executing a Defense-wide financial audit. These costs are further impacted by the inability of existing legacy financial systems to support strong internal controls and exchange compliant data.

o The concept of operations for maximizing cost effectiveness of Defense-wide audits provides for distributing audit engagements by general ledger systems versus by individual Agencies or activities. This approach should enable a single annual audit to be performed covering all or most Agencies using DAI, and therefore significantly reduce overall cost of the audit acquisition and execution process.

Objectives of the DOD Agency Strategic Plan include simplification of the financial management systems environment, maximizing ERP utilization across all financial end-to-end processes to achieve greater operating efficiency, greater utilization of Defense and government-wide shared services platforms, and improving Defense-wide capability to utilize financial data to support effective decision-making. The extent to which the Department can meet these objectives relies heavily on its ability to integrate and flow standard business and financial information consistently and efficiently through modern systems that are capable of supporting this.

Figure 1.1-1: DAI Releases for Increment 3

1.2 DAI Stakeholders

The primary stakeholders involved in validating and approving the DAI requirements include:

Office of the Deputy Under Secretary of Defense – Comptroller - Business Integration Office (OUSD(C)

BIO)

Defense Logistics Agency (DLA) (Acquisition oversight)

Defense Agencies and Field Activities included in the deployment (completed & planned) depicted in Figure 2.1.2-1 (OV-1)

2. Program Technical Requirements

2.1 Architectures and Interface Control

2.1.1 Overview of Architecture efforts

The program developed architecture views compliant with DoD Architecture Framework (DoDAF) Version 2.0, in accordance with Business Enterprise Architecture (BEA) guidance.

Chairman of the Joint Chiefs of Staff Instruction 6510.01E (CJCSI 6212.01F) is the primary DoD policy requiring that DoDAF products be included in the acquisition documents for programs following the DoD Acquisition Lifecycle Process. DAI DoDAFs can be made available upon request.

In line with these policy requirements, “DLAI 8000.01, Enterprise Architecture” [September, 2018], determines the viewpoints required from DAI for compliance. These products are to be viewed as living documents, which will be incrementally updated in order to continue to reflect the functional and technical solution implemented with DAI.

These products are part of the overall framework that supports several activities for verification, test evaluation, including BEA Assertions, and Interoperability Certification efforts.

As a general rule, the Operational Viewpoints (OV Diagrams) are process/organizational-driven in nature, and include the operational scenarios, activities, and requirements that support capabilities. Therefore, those views will be directly impacted by the establishment and modification of requirements.

Following DLA’s direction, Systems Viewpoints (SV Diagrams) and Services Viewpoints (SvcV Diagrams) are integrated into common diagrams and articulated the systems/services, their composition, interconnectivity, and context providing for or supporting operational and capability functions. As a consequence, these architecture products will be more closely related to the engineering design, and will reflect the technical activities inherent to the solution. Below is a summary of the architecture products the program is maintaining:

High-Level Operational Concept Graphic (OV-1) The High-Level Operational Concept Graphic (OV-1) is a high level graphic representation of the model being implemented for DAI, capturing the key end-to-end processes as well as the Agencies in the planned scope. It is meant to provide a quick overview for decision makers and other interested parties.

Project Timeline (PV-2) The PV-2 provides a timeline perspective on DAI solution implementation and illustrates the high level dependencies and Milestones.

Operation Event-Trace Description (OV-6c) The OV-6c is a swim-lane based process flow diagram showing time-ordered sequencing of Operational Activities, responsible organizations, and triggering events, depicting hand-offs between the distinct organizations involved as they occur. For DAI, the diagram is primarily business process centric, following the Business Process Model and Notation (BPMN), and also showing the specific activities associated with the systems that are part of the solutions portfolio.

Operational Activity Decomposition Tree (OV-5a)

The Operational Activity Decomposition Tree (OV-5a) describes the operations that are conducted in the course of achieving DAI’s mission or business goal. It describes operational activities (i.e. business tasks) in an Activity Hierarchy Diagram.

Operational Resource Flow Description (OV-2) The Operational Resource Flow Description (OV-2) is intended to track the need to exchange information or other resources between operational nodes, where an operational node is defined as an element of the operational architecture that produces, consumes, or processes information. For DAI, it will represent either internal components of an agency or external organizations that exchange information with the agency.

Operational Resource Flow Matrix (OV-3) The OV-3 identifies resource transfers that support operations. It captures the sending and receiving Organization and the sending and receiving Operational Activity within an organization along with important high-level characteristics of each Information Exchange, e.g., criticality, timeliness, etc.

Organizational Relationships Chart (OV-4) The Organizational Relationships Chart (OV-4) illustrates the command structures of the organizations responsible for the operational nodes in the OV-2 based on the key players identified there. The OV-4 shows relationships between organizations across all levels of the organization hierarchy.

Operational Rules Model (OV-6a) Operational Rules are statements that define or constrain some aspect of the architecture focusing primarily on the mission (not systems). These rules can include such guidance as the conditions under which operational control passes from one operational activity to another or the conditions under which an operational activity is authorized to proceed.

Conceptual Data Model (DIV-1) and Logical Data Model (DIV-2) DAI uses a combined Conceptual/Logical Data Model (DIV1/2) since such is reasonable for describing the program’s Reports, Interfaces, Conversions, Extensions, Forms and Workflows (RICE-FW) objects. The DAI PMO does not change core COTS code. Given that DAI is based on a COTS solution (Oracle EBusiness suite), Data Models for the standard out-of-the-box solution are developed by the Vendor. For the custom objects identified as part of the solution (Interfaces and Extensions), the program will build the integrated data models (i.e. DIV-1 and DIV-2 unified in a single diagram) associated with each custom object.

The Conceptual/Logical Data Model (DIV-1/DIV-2) describes the high-level information concepts and their relationships using verb phrases. It constitutes the business definitions that underlie the solution data model, and defines the characteristics of operational business concepts by detailing their characteristics (or Data Attributes).

System/Services Interface Diagram (SV/SvcV-1) This model shows which systems/services exchange data with DAI, and specifies the key content being exchanged

Systems/Services Resource Flow matrix (SV/SvcV-6) The SV/SvcV-6 specifies the characteristics of Resource Flow exchanges between systems. The SV-6 is the physical equivalent of the logical OV-3 work product and provides detailed information on the system connections which implement the Resource Flow exchanges specified in OV-3.

Systems/Services Measure Matrix (SV/SvcV-7) The SV/SvcV-7 specifies performance parameters for systems, hardware/software, services, (defined in the SV/SvcV-1) and their communications path (defined in SV/SvcV-2).

Capability Taxonomy (CV-2) The CV-2 captures capability taxonomies. The model presents a hierarchy of capabilities. The CV-2 specifies all the capabilities that are referenced throughout one or more architectures.

Capability to Operational Activities Mapping (CV-6) A CV-6 shows which elements of capability may be utilized in support of specific operational activities by means of a mapping matrix.

2.1.2 DAI High Level Concept

The DAI High Level Operational Concept (OV-1) shown below depicts an elevated overview of the program, reflecting the agencies that are already or are planned to be operating under the DAI solution. It also reflects the main end-to-end processes (E2E) that are deployed as part of the solution.

Figure 2.1.2-1: DAI High Level Operational Concept Graphic (OV-1) as of 7-September-2018

The OV-1 diagram depicts the two core aspects that drive the implementation of the DAI solution. The first aspect, surrounding the diagram, corresponds to all the agencies that are either currently utilizing the DAI solution, or are planned to join the deployment in future phases.

The second aspect of the diagram, in the center, is the core of the DAI Global Model being deployed to the agencies, and corresponds to the End-to-End Processes that will form the DAI business solution at FDD.

Currently, six of these are already implemented. Please note that the Grant Financial Management and Budget Formulation Processes are embedded within the high level Procure-to-Pay and Budget-to-Report respectively.

The Level 1 Process Flows for each of the high level End-to-End business processes currently implemented are depicted below:

Figure 2.1.2-2: DAI High Level End-to-End Business Process Flows

2.1.3 DAI Technical Environment

DAI is hosted at the DISA Data Centers in Ogden, Utah and Columbus, Ohio. Physical security considerations to include network infrastructure and hardware operation system are supported by the hosting service provider, whereas the application and database security is provided by the DAI PMO following the Risk Management Framework (RMF). User access to DAI is browser based via the Non-classified Internet Protocol Router Network (NIPRNet) for DoD agencies users (Common Access Card (CAC) enabled). DAI production environment resides in DISA Ogden Data Center and the development, Continuity of Operations Plan/Disaster Recovery (COOP/DR), and test environments in DISA Columbus Data Center.

The application and database security will be provided by the DAI PMO following Risk Management Framework (RMF) control process.

The environment to support Oracle EBusiness Suite R12 includes a production environment and a COOP environment.

The figure below provides an overview of the production architecture:

Figure 2.1.3-1: Systems Physical Architecture

The COOP environment is configured in a similar fashion, except with slightly reduced capacity.

Network Architecture

DISA infrastructure will support internal and external connectivity to DAI. The main components of the current network design are described below:

a) Demilitarized zone (DMZ): DoD DMZs provide defense in depth for DoD systems accessed via the NIPRNet. Enterprise Systems Directorate (ESD) maintains redundant, geographically disperse DoD

DMZ extensions to provide inbound and outbound access control for partner systems hosted in the DISA Data Center.

b) Business to Business (B2B): The B2B is a Virtual Private Network (VPN) solution for encrypting traffic to and from non-DoD locations. This solution is only used when encrypted site-to-site connections are needed to non-DoD entities. If encrypted site-to-site connections are not needed, traffic is routed natively over NIPRNet and Internet.

c) Out-of-Band (OOB) network: The proposed server will be accessible from the OOB for privileged access. All users requiring administrative or developmental access will be required to submit DD Form 2875 to the security officer at each site that hosts the systems to which the administrator requires access.

d) Physical Network Connectivity: Physical servers provisioned through the Capacity Services contract for which ports have been pre-positioned do not require a project specific network connectivity solution.

Figure 2.1.3-2 provides an overview of the proposed network architecture:

Figure 2.1.3-2: Network Architecture

2.1.4 DAI Functional Interfaces

The Application Program Interfaces have been updated for Inc 2 Rel 3. The changes have been highlighted in Figure 2.1.4-1, the DAI Systems Interface Description (SV/SvcV-1). The SV/SvcV-1 addresses the composition and interaction of Systems. The SV/SvcV-1 links together the operational and systems architecture models by depicting how resources are structured and interact to realize the logical architecture.

The SV/SvcV-1 depicts all System Resource Flows between Systems that are of interest:

Figure 2.1.4-1: DAI Global Interface Architecture (SV/SvcV-1)

Table 2.1-1 captures the System Interface Agreements, for each exchange partner depicted in the SV-1:

Table 2.1-1 Required Memoranda of Agreement as of 26-April-2018

2.2 Technical Certifications

Table 2.2-1 captures the system-level technical certifications which must be obtained during program’s life-cycle:

Cost Accounting (CA) Cost Accounting is a form of managerial accounting that can support reimbursable variables such as rates, performance-based measures such as Key Performance Indicators (KPIs), or task level cost detail for large scale projects and other efforts.

Procure to Pay (P2P) The Procure to Pay process encompasses the initial request for goods or services through the payment for those goods and services. There are several purchasing business scenarios that DAI will support including:

• Standard Financial Information Structure/ Standard Line of Accounting (SFIS/SLOA) - With Release 1, DAI supports every obligation down to the Contract Line Item (CLIN) level with an associated unique line of accounting throughout the requirement lifecycle.

• Contract Procurement – Contract procurement involves the procurement of goods and services through the award of a contract or Purchase Order.

• Non Contract Procurement – Including miscellaneous payments not based upon contract or purchase order transactions such as those associated with Purchase Card and Syncada (PowerTrack) third party payment capabilities.

• Intergovernmental Procurement – Intergovernmental procurement involves the purchase of goods and services through other agencies. This process is usually accomplished through the use of a Military Interdepartmental Purchase Request (MIPR).

o Procurement Request Data Standard (PRDS) (DAI sourced purchase requests (PRs) sent to servicing Contract Writing System (CWS) via DLA TS).

o Procurement Data Standard (PDS) (CWS sourced award and modification contract obligation data sent and posted in DAI).

• Travel – DAI will support the financial accounting events associated with travel including temporary duty and permanent change of station.

• Direct Treasury Disbursing – DAI sends the Ready to Pay file directly to US Treasury rather than DFAS.

Order to Cash (O2C) The Order to Cash business process encompasses billing and accounts receivable activities. Billing and accounts receivable processing is a core business process for many of the Defense Agencies

Acquire to Retire (A2R) Provide for General Ledger financial accounting transactions that arise from externally managed Real Property and Personal Property assets; recording incoming financial transactions for asset additions, transfers, disposal, Military valuation, imputed cost and depreciation.

Time and Labor (T&L) The DAI solution must provide Time and Labor functionality to achieve fully integrated cost accounting capabilities against labor costs. Since labor costs often account for the largest portion of the Defense Agencies’ budgets, it is important for the Defense Agencies to understand how that labor is being utilized.

Budget Formulation

The DAI solution must support budget formulation by providing an environment that supports the management, analysis, and final creation of budget data. This repository shall store data such as prior year budget execution data, past spending plans, congressional markups, and all revisions. For organizations that have working capital funds or rely on rates to generate revenue, the formulation system must be able to store the data required to use those rates in analyzing and formulating the budget. In addition, the budget formulation module will be able to break down payroll costs by position or the appropriate level of detail required in order to support the personnel portion of the budget.

Grants Financial Management Grants are a part of Defense Agency financial management with some Defense Agencies receiving (grantee) and distributing (grantor) grants. Grants financial management capabilities are integrated with the DAI financial management system. The DAI solution supports many grants-related transactions, including recording advances, collections and disbursements in the general ledger, validating funds availability, updating budget execution data, and recording other grant-related transactions, leveraging primarily the Procure-to-Pay process.

3. Engineering Resources and Management

3.1 Technical Schedule and Schedule Risk Assessment

As a Business Category I (BCAT) Priority Defense Business System, the DAI Program applies a rigorous process, for both the Technical Schedule Management, and for Risk Management. The Technical Schedule will incorporate Program, Increment and Release level event structures and applicable technical reviews, utilizing DoDI 5000.75 decision points applicable to each program level. Schedule Risk Assessments will incorporate Critical Path Analysis techniques for agency implementation project schedules and the integrated program schedule as a whole. Furthermore, the program will maintain a tight coordination with the Integrated Master Plan (IMP), the Integrated Master Schedule (IMS), the Work Breakdown Structure (WBS), and the Earned Value Management (EVM) Reporting.

3.1.1 DAI Schedule Management Methodology

DAI will utilize the formalized DAI Schedule Management Plan (SMP). This plan provides guidance to the program, their support staff, and stakeholders on processes and roles for schedule development and schedule management.

The SMP and the scheduling management process is driven by an experienced team of schedulers that reports to the DAI Acquisition Team. Some of the assumptions guiding the scheduling process and the SMP are:

The durations allocated to activities/tasks/subtasks are consistent to the experience from the prior increment of the program and with industry experience of similar Release 12 technical upgrades.

Likewise, the critical-path activities identified represent areas that were identified as such based on historical experience.

Interfaces are expected to continue being required within the new release. However, all Reports, Interfaces, Conversions, Extensions, Forms, Workflows (RICE-FW) objects will undergo detailed review, and estimates of efforts could be revaluated accordingly.

Workforce preparation efforts are taken into account, focusing mostly in the differences in functionality in the new release, and the new Oracle modules being deployed (e.g. Contract Lifecycle Management).

Acquisition process requirements and related activities that serve as phase gates are factored into the schedule as dependencies for certain tasks.

The SMP:

Explains how DAI will utilize the program’s WBS and the IMP in the development of the IMS.

Explains how schedule information will be captured, expressed, updated, and maintained.

Sets the format and establishes criteria for developing and controlling the schedule.

Describes how schedule contingencies will be reported and assessed.

Explains how DAI will utilize the IMS and project schedule data for EVM Integrated Program

Management Reports (IPMRs).

Additionally, the SMP provides guidance to DAI regarding scheduling requirements and expectations such as:

What tools should be used to create a project schedule

What the project schedule should contain The level at which the DAI PMO maintain the schedule When the project schedule should be baselined When schedule documents (e.g., milestone charts, team calendars, etc.) should be updated When and how project schedule status should be reported up to the PMO to be updated in the program-level IMS Who/What role is responsible for updating the project schedule

Since the IMS is developed as a hierarchy of project schedules, the SMP also establishes scheduling standards and conventions to allow scheduling information to be efficiently integrated across all program participants. Scheduling conventions are established for:

Standard code field definitions Standard program calendar Keys for program and project milestones Treatment of dependencies between component schedules Utilization of the DAI Work Breakdown Structure

This SMP addresses the methodology behind maintaining the IMS, and its use in reporting the status of the Critical milestones.

3.1.2 DAI Schedule Solution

In keeping with requirements to support overall program execution and program earned value management requirements, as well as to accommodate customer-specific requirements, DAI’s solution is a strategy that supports a three level schedule structure. This strategy allows visibility at a high level (driven by the Integrated Master Plan and the Program Master Schedule) while at the same time supporting the detailed deployment activities at the individual agency level.

Tier 1 – Integrated Master Plan (IMP) and Program Master Schedule (DAI Government IMS)

The DAI Increment 3 IMP outlines the hierarchy of program events and major milestones necessary for successful deployment of all capabilities and releases planned for Increment 3 of the Program.

The DAI Government IMS builds directly from the IMP, by incorporating all IMP events and milestones, and is used to conduct critical path analysis. It includes all program phases, agency deployments, critical milestones, and key tasks. The DAI management team uses the DAI IMS to plan, manage, evaluate, communicate, and report on the program. Finally, the DAI Government IMS is leveraged by functional schedules for more detailed planning.

Tier 2 – DAI Government Functional Schedules

Functional schedules provide lower level details to support program elements requiring more stringent management such as agency implementation schedules and detailed execution plans for program functional areas. Agency Implementation schedules are used to integrate DAI Government IMS execution to external agency schedules for implementation planning. The Functional area schedules assist DAI PMO team members in coordinating activities to complete the defined segment of DAI Program execution. The schedules communicate requirements, facilitate reviews, manage resources, highlight and manage activity interdependencies, and monitor progress at a lower working level. Detailed schedules may also be used by some DAI functional areas to manage day-to-day execution and detailed planning.

Tier 3 – Execution Schedules

Execution schedules show detailed work plans within the DAI Government IMS structure. The results include objectives and goals, measurable steps for completing objectives, activity ownership, critical milestones, and key tasks.

The detailed schedules coordinate the PMO team members’ activities to complete the defined segment objectives of the DLA DAI Program. The schedules communicate requirements, facilitate reviews, manage resources, highlight and manage activity interdependencies, and monitor progress at a lower level than the IMS. The detailed schedules are updated per the schedule management requirements of the Schedule Management Plan.

Figure 3.1-1 Schedule coordination between tiers

3.1.3 Roles and Responsibilities

Role Responsibilities

DAI Program Manager

Ensures schedule processes are applied in a manner supporting project requirements and objectives.

Responsible for schedule development and EV guidelines, schedule development, schedule execution, and baseline control of the integrated schedule.

Accountable for oversight and decision-making of the entire program throughout the lifecycle to include cost, schedule and technical performance.

Continuously evaluates DAI cost, schedule and technical performance.

Reports to external stakeholders the cost, schedule and technical performance of DAI.

Approves the implementation schedule risk mitigation corrective actions.

DAI IMS Team Implements schedule management processes to ensure program objectives are successfully achieved.

Develops schedules through coordination with functional area teams to define program requirements and schedule objectives.

Reports schedule progress, performance, variances, and forecasts.

Evaluates risks and performing “what-if” analysis.

Assists the functional area teams in managing schedule change, including baseline change control; and using project management software tools and techniques to develop, maintain, and control the Government IMS.

DAI PMO

Functional Leads and Integrated Product Teams

Understand all tiers of the Government IMS and how it relates to their work processes and responsibilities. For example, the Business Support Team coordinates with DAI PMO schedule coordinators to ensure budget phasing integrates with the Government IMS timeline.

Develop timely, unbiased cost and schedule assessments for their functional area of responsibility.

Work with the DAI Program Risk Manager to develop and track risk mitigation corrective action plans to closure for risks associated with cost, schedule and technical performance.

Facilitate development of materials necessary to assess cost, schedule and technical performance by contractor personnel for cost reimbursable contracts under their functional area of responsibility.

Development Team Leads

Responsible for schedule performance in respective area Responsible for developing execution schedule for activities in each area of responsibility (Acquire to Retire (A2R), Cost Accounting (CA), Budget to Report (B2R), Procure to Pay (P2P), Order to Cash (O2C), Oracle Time and Labor (OTL), Oracle Business Intelligence Enterprise Edition (OBIEE), etc.).

Validate input from development team and provide status to IMS Schedule team.

Work with IMS Schedule team to mitigate schedule issues and incorporate changes.

Operational Performance/EVM Lead

Supports DAI PM agenda ensuring compliance with schedule management processes across the program supports program management objectives, particularly those concerning implementation of EV.

Coordinates with the Contracting Officer Representatives and with the DAI PMO schedule coordinators to ensure contractual deliverables and the Government IMS are aligned and appropriate status is taken.

Provides government oversight and guidance to IMS Schedule team.

Support linkage with EVM Team.

EVM Team(Cost and EVM Analysts)

Draft Performance Management Baseline (PMB) based on inputs from the Functional Leads when a contract is awarded, an option period is exercised, or there is a significant change to an existing contract. The data is housed in the ‘EVM Tracking Matrix’ developed for each contract and summarized at the Program level.

Aggregate the cost and schedule data and prepares the monthly EVM report and analysis.

Request information from contractor PM as required.

Develop the Contract WBS, incorporating the Project Work

Scope (PWS).

Coordinate the WBS detail with the Schedule Team for incorporation as the IMS high level structure to support the required the Integrated Program Management Report (IPMR) detail.

Determine the IPMR’s required for each contractor and evaluate the Variation Analysis parameters.

Prepare the Memorandum of Record for the PM approval for the

IPMR.

Provide the requirements detail to the EVM Lead to forward to the Contracting Officer (KO) / COR for incorporation into the contracts.

Establish the IPMR’s using the PMB developed by the Cost Analyst and the IMS.

Prepare the IPMR’s for the Program and submit to the EVM Lead, using the Actual Cost Data provided by the Cost Analyst and the Performance data provided by the IMS / Schedule team.

Defense Finance and Accounting (DFAS) Conversion Team

Coordinate and make schedule updates for individual agency activities as it relates to data cleansing, data conversion and cutover.

Table 3.1.3-1 Scheduling Roles and Responsibilities

3.1.4 Technical Schedule and Planned Milestones

Figure 3.1-1 below depicts the current draft DAI Technical Schedule, including major phases, acquisition milestones, technical reviews, and the core activities for Increment 3 of DAI, including Development, Deployment, Logistics/Infrastructure, Workforce Preparation, Testing, and Contracting. Note that the current schedule definition is still in progress, so a number of changes are to be expected.

Note regarding Physical Configuration Audit (PCA): Based on the upgrade of the Oracle EBusiness Suite software, PCA will validate the Configuration Items associated with the business software solution (COTS product and RICE-FW objects) are installed per design into the production system, after each limited production release. All PCA events are taking place before Full Deployment (FD).

Hardware components are maintained by DISA, and are not expected to change as part of this release, therefore will not constitute a central part of PCA.

Figure 3.1-2 System Technical Schedule

3.1.5 Schedule Risk Assessment

Schedule Risk Assessment (SRA) is performed through Critical Path (CP) analysis at DAI, to determine program schedule uncertainty, validate schedule structure, and verify adequate schedule contingency. DAI performs SRA against the program’s critical paths to determine:

Likelihood that the project completion date will occur How much schedule risk contingency is needed to provide an acceptable level of certainty for completion by a specific date Risks most likely to delay the project How much contingency reserve each risk requires Paths or activities that are most likely to delay the project.

DAI will utilize their Subject Matter Experts (SMEs) to determine if the planned activities are reasonable to complete the agreed upon requirements outlined in the contract Statements of Work (SOWs).

3.2 Engineering Resources and Cost/Schedule Reporting

The following functions are fully supported by the resource assignment for the program, and tie with the methodology described here:

a. Modeling – as described in section 3.1

b. Risk Management –see section 3.3

c. Requirements – Process is explained in detail in section 4.3

d. Program Protection – as per the Program Protection Plan (PPP)

e. Software – schedule and resource allocation is driven by the program’s prior experience in Increments 1 and 2, and by best practices in industry on similar deployments

f. Logistics – management of engineering logistics activities (i.e. infrastructure) are fully incorporated into the IMS, utilizing the Subject Matter Experts knowledge for scheduling these activities

g. Deployment/Production – reflected in the detailed implementation schedule, based on prior experience

h. Configuration Management – explained in detail in section 4.5

i. Quality – Activities explained in detail in the DAI Test and Evaluation Master Plan

(TEMP)

j. Safety – not applicable

k. Reliability and Maintainability – Explained in detail in section 3.6

l. Integration and Test - Activities explained in detail in the DAI Test and Evaluation Master

Plan (TEMP)

3.2.1 Inputs and Entry Criteria to Integrating Resources, Cost and Schedule Inputs The inputs that contribute to the EVM process are shown in Table 3.2-1. These inputs serve as the basis for implementing DAI EVM. They also cover the entire scope of EVM to include the following: Organization; Planning, Scheduling, and Budgeting; Accounting; Analysis and Management Reports; and Revision.

Table 3.2.1-1 identifies the information requirements necessary to develop the products listed in Outputs and Exit Criteria. These inputs may depend on other activities associated with the life-cycle process or other procedures or other tasks.

Input Description DAI Program Schedule

The DAI Program Schedule defines the program timeline and activities to be executed over time.

DAI Work Breakdown Structure (WBS)

The DAI Program WBS identifies a mutually agreed to program scope that constitutes the Performance Measurement Baseline (PMB) and supports EVM. This document formal-izes the activities, products, and human capital roles required for each process. It defines the related processes and procedures, roles and responsibilities, entry criteria, inputs, steps, and exit criteria.

EVM SOP This document discusses the practice of EVM as it is implemented for DAI. It comprises applicability, techniques, methods, Integrated Baseline Reviews (IBRs), reporting, process flow, and the specific steps contributing to successful EVM.

IBR Process An IBR allows DAI staff, as well as the support contractor(s), to review and resolve issues in the proposed PMB and come to an agreement that the PMB accurately reflects the scope of the work to be performed, the appropriateness of its schedule, the appropriateness of the assigned recognition methods, and the investment’s key milestones. The IBR process defines the scope, triggering actions, preparation, execution, and conclusion of each WBS Work Package (work activity in the DAI Program). At the conclusion of an IBR, a Memorandum for the Record (MFTR) is created to document the baselining as agreed during the IBR Process and establishes basis as an EVM measurement input.

WBS/

Organizational Breakdown Structure (OBS) Dictionary

This document explains and illustrates the DAI work elements. It associates the responsibility for each element to the appropriate Government lead and staff entity as assigned. It is not intended to bind contractors to perform the work described, but is intended to show logical assignment based on the particular competencies and expertise provided by each contractor. Performance of the work is dependent on execution of appropriate contractual vehicles.

Table 3.2.1-1 EVM Inputs and Descriptions

Entry Criteria Table 3.2.1-2 identifies logical flow and when the process can begin. The workflow/process diagrams are to be used to identify prerequisite tasks. Before beginning the process, a check will be done to ensure that each criterion has been met.

Entry Criteria Personnel involved with implementing EVM have adequate training and experience necessary to integrate WBS, OBS, Schedule, and Cost information.

Personnel involved with implementing EVM have adequate training and experience necessary to conduct Integrated Baseline Reviews.

Personnel involved with implementing EVM have adequate training and experience necessary to analyze and report accurate EV performance.

Table 3.2.1-2 EVM Process Entry Criteria

Process Steps and Responsibilities

The EVM process is comprised of five functional components that are discussed below.

Step Functional Component Person Responsible 1 Organization DAI Program Manager

The Organization will implement EVM. Collectively, these promulgate the WBS, OBS, Control/Cost Account Plans, and the associated integration required to monitor project performance and estimate costs at completion.

2 Planning, Scheduling, and Budgeting DAI Operations Manager

The Planning, Scheduling, and Budgeting component implements the project schedule, milestones, budgets, work packages, EV metrics, overhead budgets, management reserves, undistributed budgets, and overall allocation resolutions necessary to account for and budget all work and to cover all expenses in the execution of the project.

3 Accounting DAI BFM or Control Account Manager

The Accounting element implements the recording of direct, unit or lot costs, and their sum-marization and accumulation over time.

4 Analysis and Management Reports DAI Operations Manager

The Analysis and Management Reports implements actual performance against the project baseline, and the actual cost based on the project baseline. These also promulgate variances, their causes, corrective actions, and associated revised estimates at completion.

5 Revision and Data Maintenance DAI Operations Manager

The Revision and Data Maintenance element implements authorized changes to the baseline, reconciling budgets, controlling changes, minimizing changes, and documenting changes.

3.2.2 Outputs and Exit Criteria to Integrating Resources, Cost and Schedule

Outputs The products in Table 3.2.2-1 are produced as outputs from the activities of this process. These outputs may feed subsequent processes, procedures, activities, or tasks.

Product Description

Baselined Integrated Master Schedule

(IMS)

The IMS is developed for the DAI Program so that tasks and milestones are clearly defined. It is updated regularly to identify elements that are behind as well as those ahead of schedule. The IMS maps directly to the program WBS enabling the operations management team a single point of reference for all activities.

IBR IBRs and the resulting reports ensure that the baseline captures the entire technical scope of work in that contract, that it is consistent with schedule requirements, and that the appropriate mix and level of resources have been assigned to the program. These IBRs are performed to enhance the DAI Program Manager’s and the project team’s confidence in the cost and schedule management and baseline formulation.

Periodic Earned Value Reviews

Earned Value reviews examine the Budgeted Cost of Work Scheduled; the PMB upon which all program level analyses are performed; Budgeted Cost of Work Performed (the numerical value of how well the staff is performing against budgets); and Actual Cost of Work Performed (the actual cost from accounting for that investment by WBS element).

Periodic Earned Value Reports (such as IPMRs)

The Integrated Program Management Report (IPMR) presents the cost and schedule data for the current period as well as in a cumulative format. Formats 1 and 5 provide the DAI Program Manager the insight needed to manage the investment. Format 1 is a WBS-oriented report. Costs are organized by WBS element at a level pre-determined by the DAI Operations team. Format 5, Variance Narrative, is a problem analysis and variance-oriented report. It provides explanations for cost and schedule variances that have exceeded thresholds. It provides a written explanation as to why the variance occurred, as well as written descriptions on how the staff plans to resolve the cause of the variance.

Table 3.2.2-1 Output Products and Descriptions

Exit Criteria Table 3.2.2-4 identifies logical flow and when the process can be considered complete. The workflow/process diagram is used to identify subsequent processes, procedures or tasks to be performed. Before this process can be declared complete, the following exit criteria must be met.

Exit Criteria

Functioning EVM using and influencing the maintenance of program WBS, OBS, and Schedules.

Periodic assessments of DAI Program status including publication to the Oversight Authority

Management tool and presentation at appropriate management and governance reviews.

Table 3.2.2-2 EVM Process Exit Criteria

3.3 Engineering and Integration Risk Management

This section is addressed in the DAI Risk, Issue, and Opportunity Management Plan from March 23, 2018. A detailed analysis of the Risk Management process will be found in that document.

3.4 Technical Organization

3.4.1 Government Program Office Organization

The DAI Program leadership structure, key personnel and reporting relationships are illustrated in Figure 3.4.1-1 below.

Figure 3.4.1-1: Program Office Organization

The DAI Program Management Office (PMO) organizational roles and responsibilities for appropriate business areas are highlighted in Table 3.4.1-1 below:

DAI PMO Team Duties Program Manager

(PM)

Responsible and accountable for oversight and decision making of the entire program throughout the lifecycle to include cost, schedule, and performance. Responsible for compliance with this policy, its review processes, and documentation requirements for their programs or initiatives.

Deputy Program Manager (DPM)

Responsible and accountable for the daily organizational and acquisition activities associated with the entire program throughout the lifecycle.

Responsible and accountable to accomplish PM duties in the event of PM absence. Advises the PM on all issues relating to entire program.

Systems Engineering (SE) – including infrastructure and architecture teams

Provides consultation on business process design, database administration functions for project implementation teams, maintenance & enhancement teams, and training teams

Ensures application software/hardware is consistent with technical environment & standards.

Designs the architecture and support hardware / software components required by system implementation (servers, network printers, operating system, databases, user security, and network connectivity).

Builds the DAI Program architecture documentation consistently with DoDAF and BEA guidelines.

Performs all Database Administration (DBA) duties.

Acquisition Team Produce all acquisition documentation necessary to acquire new increments, support milestones and enhance DAI PMO function.

Configuration Management Team

Coordinates and facilitates Configuration Control Board and Production Technical Review Board activities.

Administers the CM Tool Suite and manages changes to the database library.

Maintains CM processes, configuration item (CI) version management, Change Request management, baseline management, and release management activities.

Audits and Publishes Configuration Status Accounting Reports.

Performs Configuration Audits and Verifications.

Production Support…