47QFAA24R0004_T10_08b_Attachment 2 Task Order 01 CLIN 0003 Statement of Objectives_2024-06-10.pdf

Statement of Objectives

I. PURPOSE

The purpose of this Statement of Objective (SOO) is to obtain Contractor support for configuration and customization support to implement automated tasks and processes to perform Budget Execution and the Master Staffing List in the Budget Department Management System (BDMS). Currently, these processes are manual. Business process re-engineering efforts are needed to identify efficiencies and utilize the out of the box capabilities of the OneStream system as much as possible.

End-to-End Budget Execution Capability

Budget Execution (BE) – Provide automation and streamline the preparation and distribution of the spend plans and provide an integrated approach between BDMS and the Consolidated Financial System (CFS) and summarizing financial data to internal stakeholders. This module shall provide the ability to automate the tracking of resources in the year of execution, such as potential unfunded requests, surpluses, reserve balances, etc. at the granular level to provide a projection of the end of year shortfall/surplus balance. Data would be pulled from various sources such as the departmental spend plan, CFS, budget request tool, etc.

The Master Staffing List (MSL) –Provide an automated employee (FTE)/position management process and reports that will reconcile biweekly changes that occur in the Human Resource Department (HRD) staffing reports.

Sub Capabilities

Throughout the estimated 30-month performance period, a number of sub-capabilities shall be configured in pieces in order to achieve this target and capabilities.

● Spend planning,

● Integration with PBGC’s Consolidated Financial System,

● Integration with PBGC’s HR Systems,

● Ability to perform financial analysis and projections,

● Track and report on Master Staffing: Federal Staff Count and Personnel

Compensation & Benefits (PC&B)

II. BACKGROUND

PBGC is actively using BDMS, a cloud-hosted application based on the OneStream software platform, for budget formulation and PC&B processes. There are currently sixty (60) users of the system, although with added features the number may increase to between eighty (80) and one hundred (100).

To execute the management and implementation of the BDMS product backlog, Business Innovation Services Department (BISD) has successfully adopted a modified approach. PBGC seeks a solution that is congruent with the existing PBGC process Agile playbook. The Contractor shall use the processes outlined in the IDIQ PWS.

Additionally, PBGC’s Contractor partner will conduct change management activities to acclimate PBGC’s business area stakeholder, the Budget Department (BD), with the Contractor’s proposed approach and new functionality in BDMS. IDIQ PWS Section C.3 provides further details on the PBGC Agile process.

III. PROBLEM

Currently, the full lifecycle of the budget process is heavily dependent on manual processes that are labor intensive and introduce version-control issues and errors that are time-consuming to rectify. There is no integration with the PBGC financial system, so obligations and liquidations are not transmitted to the financial system in real-time.

Reporting is limited; It forces users to prepare reports piecemeal, making it difficult to make data-informed decisions.

1. PBGC doesn't have the ability to automate the budget execution process; today it is done manually. There are version-control issues, data input is manual and errors are introduced, it’s time-consuming to rectify data-fidelity. There is a learning curve to the process and PBGC needs to introduce a consistent process for when people leave / retire.

2. PBGC doesn’t have the ability to automate the master staffing list process; today it is done manually.

3. There is no interface / linkage to financial systems, so obligations and liquidations are not conveyed to the financial system in real-time.

4. Reporting is limited, users are pulling in information and generating reports piecemeal, and it’s challenging to make data-informed decisions.

5. PBGC has a challenge with ongoing maintenance and resource management for the existing application, so improvements are not implemented timely.

IV. OBJECTIVE

As depicted above, the first couple of months would be required to simply onboard the Contractor team, provide Government furnished equipment and access to software, documents, development/test/production environment access to BDMS, etc. to successfully transition-in. Once the Contractor has what they need to begin work, Sprint Zero activities would be required where the Contractor would bring their expertise in OneStream product/modules or capabilities (such as Budget Execution Module, PeoplePlanner, etc.) and elicit understanding of PBGC’s Consolidated Financial System (CFS) and Human Resource (HR) systems integration needs, etc. to deliver an implementation roadmap using PBGC’s approach. Once the various sub-capabilities are completed in an iterative manner, all the completed pieces would need to be integrated for an end-to-end Budget Execution workflow capability to be achieved. The strength and power (using PBGC’s Approach) is employed in configuring and developing the sub-capabilities (light blue boxes). Work involved in the green boxes are sequential and not Agile (e.g., although called “sprint zero”, the foundational activities within are sequential in nature and required to be completed before applying iterative approaches in Sprint One to Sprint N). Individually, sub-capabilities that may be completed on their own do not stand alone and offer no use by the Government nor bring any benefit to the Government. Individual sub-capabilities are dependent on the other sub-capabilities to deliver the full Budget Execution Capability. Collectively, ALL sub-capabilities shall be completed and integrated before even entering testing of the Budget Execution Capability. Each sub-capability, even if only partially completed, would be staged in a TEST environment and added incrementally. This includes data ingestion and data migrations necessary for the sub-capability, and integration with the current BDMS Budget Formulation capabilities. Finally, all the sub-capabilities are integrated together, followed by sequential (non-Agile) End-to-End testing, and turned over the Government to perform End-to-End User Acceptance testing before authorizing the system to be deployed to production, go-live and use of the completed system.

The Contractor that works with PBGC to define the architecture and design in Sprint Zero shall execute the configuration and coding of the system. Thus, during the performance of Task Order 2 tasks, the Contractor would be authorized to perform the work and held to meet contractual requirements including quality of the product and a single authoritative configuration and code base. The work performed shall coordinate with the Continuous Product Improvement team and Operations team in managing version of the Production BDMS code.

Notional Milestones and Deliverables Estimation

1. PBGC estimates approximately 3 months for the “On-board & Sprint Zero” activities.

2. The sub-capabilities configuration can vary in time, sequence, etc., which can only be determined by the OneStream experts. PBGC estimates that the overall configuration of the individual components and integration of those components, followed by the Contractor’s End-to-End testing to be approximately 21 months.

3. PBGC estimates 6 months for Government-led Product Owner (and Budget Department team) incremental testing followed by full End-to-End User Acceptance Testing of a fully integrated system and a period of Hypercare. The Government will “Accept” the system for full production deployment and use with critical bug and data fixes, fine tuning, and stabilization, and transition to the Operations team.

4. PBGC Task Order identified all the deliverables along the way that are produced and updated throughout the effort. Example of these deliverables are Product Roadmap delivered at Sprint Zero and updated throughout the period of performance, Design document updated throughout the period performance, backlog grooming and user story development throughout, Data and Document Migration and Implementation Strategies, BPR Documentation as existing processes are being automated and changed by technology, Change and Communication Management, Training, etc.

V. SCOPE

PBGC seeks Low-code/No-code (LCNC) development services for configuration and customization for BDMS. The services to be provided will include all aspects of the SaaS development process, including planning, design, configuration and customization, prototyping, documentation, testing, training, and help desk support. The services also include support of security documentation and testing.

1. Product Vision

The BDMS system will enable efficient, consistent, accurate, and secure full lifecycle federal budget processes; and data reporting will be flexible and streamline analysis and decision-making.

a. To modernize the budget execution processes and work more effectively and efficiently. (this eliminates the need for manual data entry as well as users operating concurrently in different documents, etc.)

b. Create a centralized location for Master Staffing List (MSL) that automates FTE / position management reporting, improves the quality of staffing data and reporting (i.e. vacant positions), and creates more efficiency for users in management and reconciliation.

c. Automate FTE management process, data projections, and financial management.

d. Provide up-to-date information that is transmitted between systems without the need for manual data entry.

e. Better data quality and tools to help PBGC make informed decisions; meaningful reporting for decision-making; flexible for drill-in capabilities, to save time, be intuitive, and easy to use. More robust data analysis.

f. Centralized location to track and manage budget changes, locate budget data from multiple sources.

g. Consistency in process.

h. The system is secure.

2. Project Management

Project Management Scope: BISD seeks the Contractor to deliver excellence in project management. Project Management includes managing and directing the technical team members of this contract, resources management, scope, cost, and schedule management, risk and issue management, contract management, communications, integration and interface management with other systems, stakeholder management, reporting management, quality management of all deliverables, planning out future needs, and release management.

Project Management Objective: Include, but are not limited to: Deliver all projects and releases on time, in cost, within scope, with quality.

3. Ceremonies and Backlog Management

Backlog Management Scope: All activities and ceremonies included in creating, grooming, and maintaining a comprehensive system product backlog.

Backlog Management Objectives: Include, but are not limited to:

a. Facilitate sessions to elicit user stories and/or product backlog items from the product owner.

b. Each product backlog item has been groomed, has at least one user story connected to the PBI, clearly documents the definition of ready and acceptance criteria before being entered into a sprint.

c. Project follows PBGC best practices.

4. Testing

Testing Scope: All activities including but not limited to manual and automated testing, end-to-end product team testing, regression testing, creating test plans and scripts in DevOps, testing support, bug tracking from User Acceptable Testing (UAT), etc.

Testing Objectives: Include, but are not limited to:

a. Delivered the minimum viable product prior to UAT.

b. All test plans are written and stored in DevOps.

c. All completed tests are performed in DevOps with results captured.

d. All test scripts are successfully completed, passed, and signed off on by the product owner prior to production deployment.

e. Manual testing is created and updated at each release (at minimum), and automated testing is created and maintained when available (example: product owner sprint testing, end-to-end testing, user acceptance testing (UAT), performance testing, etc.).

f. Successful testing is completed by the product team prior to the start of UAT (example: end-to-end, regression testing).

g. Bugs found through product owner testing and UAT are captured in DevOps and remediated.

5. Training, Change and Communication Services

Training, Change and Communication Services Scope: All activities and efforts to ensure appropriate stakeholders are trained to understand, use, administer, and support BDMS in its current state and/or new or changed functionality being implemented.

Training, Change and Communication Services Objectives: Include, but are not limited to:

a. End users are trained and comfortable using BDMS.

b. Maximize user adoption for new capabilities among new and existing stakeholders through targeted marketing efforts.

c. User materials are made available to end users (videos, documents, etc.).

6. Sprint Zero

Sprint Zero Scope: Sprint Zero activities include, but not limited to, onboarding personnel, solidifying the high-level design, acquire and stand-up various tools needed by the developers, build and refine the product backlog by identifying epics, features, user stories, sizing (e.g. story points), priority, acceptance criteria, etc., identify the Minimum Viable Product (MVP) and creation of the initial product roadmap.

Refer to the IDIQ Section C.7 Major Product Improvement for more details of sprint zero expectations.

Sprint Zero Objectives: Include, but are not limited to:

a. All outcomes and deliverables are complete at the end of sprint zero, as outlined in IDIQ Section C.7 Major Product Improvements.

b. The product backlog is established with the MVP by the end of sprint zero.

c. The product roadmap is updated monthly.

d. The Data Migration and Interface Implementation Strategy plan is created, approved, and followed.

e. Sprint zero is complete within three months of the contract start date.

7. Business Process, Internal Controls, and Performance Metrics

Business Process, Internal Controls, and Performance Metrics Scope: Design, support, and implementation activities for internal controls, business process re-engineering efforts, and performance metrics.

Business Process, Internal Controls, and Performance Metrics Objectives:

Include, but are not limited to:

a. Documentation (new processes, procedures, standards, templates, flow charts, Information Technology Solution Lifecycle Management (ITSLCM) documentation, etc.) is authored and kept up to date to support business process re- engineering (BPR) efforts.

b. All documentation (ITSLCM and other required documentation and materials) is modified or created as needed and kept current as BDMS implementation progresses.

c. Repeatable processes to collect and track Government approved metrics and measures are established and documented.

d. Internal controls are identified, designed, documented, and embedded as appropriate within the current system and To-Be processes.

8. Product Stabilization and Hypercare

Product Stabilization and Hypercare Scope: All activities related to incorporation of new modules, processes, functionality, etc. into BDMS standard operation procedures.

Also includes reviewing UAT and the product backlog to determine if items that were not included in the initial major CPI should be prioritized and implemented before the major CPI is fully functional.

Product Stabilization and Hypercare Objectives: Include, but are not limited to:

1. Efforts needed for items or development that may remain lingering from the initial development, or uncovered in UAT, or after initial deployment will be addressed in a period of Hypercare so that the system can truly be deemed complete, accepted, and fit for use and benefit to PBGC.

9. Backlog

The set of preliminary epics / user stories set forth below will be the starting point for the development of software to be provided by the Contractor under this task order. These preliminary epics / user stories are provided only for illustrative purposes, and do not comprise the full scope or detail of the project. PBGC expects that the Contractor will work closely with PBGC Product Owner(s) to develop and prioritize a full gamut of user stories as the project progresses.

Individual user stories listed in this document may be modified, added, retracted, or reprioritized by PBGC at any time, and PBGC expects that the user stories will be continuously refined during the development process.

10. Backlog of Preliminary User Stories

Budget execution

a. As a Budget Analyst, I want the ability to create a spend plan based on the budget formulation data in the existing module in BDMS, so that I can kick-off the budget execution planning process.

b. As a Budget Analyst, I want to conduct various financial analyses on data from the financial system of record (including at least two years of actuals), so that I can develop the spend plan, budget formulation and budget execution.

c. As a Budget Analyst, I want to make adjustments to align the Congressional Budget Justification (CBJ) number to an interim spend plan (current service level (CSL), or prior year level), and then when a budget is enacted, take CSL level to the enacted budget so that PBGC is executing against the approved budget plan.

d. As a Budget Analyst, I want to have a template for the Program and Financing Table, so that in budget formulation I can avoid manual data entry errors, utilize the latest data, and ensure the outyear projections are accurate.

e. As a Budget Analyst, I want the ability to do annual, quarterly, and monthly financial projections (spend plan), so that we have accurate estimates of expected spend and I can compare projections to actuals from the financial system of record.

f. As a Budget Analyst, I want to have a template for the A-34 Report of Outlays so that in budget execution I can avoid manual data entry errors, utilize the latest data, and ensure the actuals are accurate.

11. Master staffing list

1. As a Budget Analyst, I want to streamline FTE/position management and reporting so that I can reconcile biweekly changes that occur in the Human Resources (HR) staffing reports to ensure our data aligns with the official HR data.

2. As a Budget Analyst, I want the ability to filter reports by multiple components, such as corporation, department, division, and other categories, so that I have more robust data analysis and can save time.

3. As a Budget Analyst, I want to record and view position-specific comments and notes of historical value, so that I can conduct research, and provide justification to leadership, and substantiate how and when changes happened over time.

4. As a Budget Analyst, I want to view historical position information and reporting, including archived past pay period data, so that I can compare the current state with historical data and explain changes over time.

5. As a Budget Analyst, I want to provide for separate tracking and reporting of employees by program and funding source (i.e., American Rescue Plan), so that PBGC can accurately report on data by program and funding source and conduct accurate planning and execution.

6. As a Budget Analyst, I want to have access to actual payroll expenses, so that I can monitor spending against spending plan and available funding, and generate biweekly, quarterly, and annual projections for PC&B.

7. As a Budget Analyst, I want the ability to import detailed HR payroll data so that I may perform various cost projections to be used for funding and financial analysis.

8. As a Budget Analyst, I want to compare current and future state position data so I can assess the budgetary impact of reorganization packages, so that we can provide recommendations to leadership.

9. As a Budget Analyst, I want to automate personnel agreements (i.e., ARP Employee Transfer forms, requests for over-hires, and position upgrade justifications) workflows, so that they’re centrally managed and tracked for records management and historical reference.

10. As a Budget Analyst, I want to export a staffing organizational cost accounts (OCA) data file biweekly that maps onboard employees to the appropriate OCA table. So that, the Financial Operations Department can map new OCA or organizational costs within the financial system, and ensure alignment, so that payroll doesn’t fail.

VI. SCOPE Operating Constraints (Non-functional

Requirements)

1. Environment

a. The Contractor shall be a certified OneStream partner. If a large business subcontract to a small business, that small business shall be one-stream certified as well.

b. PBGC has already purchased OneStream. The Contractor does not need to provide the platform.

c. Project management will be on PBGC’s Microsoft Project Online and Sharepoint IT solution. The Contractor does not need to provide a project management tool.

d. PBGC utilizes Microsoft on-prem Azure DevOps Server 2020. The Contractor does not need to provide a development environment or hosting.

e. Host and Licensing. OneStream licenses and hosting is a separate contract owned by another department in PBGC.

f. NIST Compliance. At PBGC, the Enterprise Cybersecurity Department (ECD) works with all of the Information Security Owners and Information owners to review the NIST controls, determine their applicability to specific applications, and work with those control owners to implement them. Back-office departments, such as ITIOD, ECD, etc., own a good portion of the controls. Controls are then filtered to system-specific. These designations are tracked and managed in the

Environmental Protection Agency (EPA)’s CyberSecurity Asset Management (CSAM) system. Those system-specific requirements will be specially identified by the information security owner and for the System Owner of TPIMS to implement in the system. Those will be identified by the information security owner and the system owner for implementation.

2. Timing

a. Timing based on previous BDMS implementations. Based on the two major capabilities previously implemented in BDMS (which did not have any direct integration with other systems), we estimate that on average it takes approximately 12 months per major capability. This implementation is more complex and requires multiple sub-capabilities.

b. Limited system owner availability. The product owner’s capacity remains constant and does not have the bandwidth to engage with a larger Contractor team. Having a bigger team will not decrease the time it will take to complete this project since the system owner does not have more bandwidth.

c. Process time. PBGC’s IT System Life Cycle Management (ITSLCM) governance process (gate reviews, change control boards, UAT time) is thorough. While ensuring only sound solutions make their way to Production, the governance portion of our ITSLCM is sequential by design and inhibits agile approaches.

3. Personnel Skills and Knowledge

Key Personnel

PBGC envisions that based upon Government knowledge of historical efforts and analysis of SOO Objectives, the support team will be composed of the below key personnel for this task order.

PBGC has listed the following positions as key personnel:

# Key Personnel Expertise

1 Project Manager

● Active Project Management Professional (PMP)®.

● hands-on experience providing project management on Federal

Government contracts, including Project Management Tools, work breakdown structures, project structure, scheduling, and performance reporting.

● prior hands-on experience implementing OneStream in a federal agency.

# Key Personnel Expertise

● Written and verbal communication skills, including experience in presenting material to senior Government officials.

● Management of manpower utilization, procurement, problem resolution, and employee relations.

● Maintenance of project schedules and deliverables completed according to Government requirements

2 Scrum Master ● Certified as a ScrumMaster by Scrum Alliance®

● Demonstrated experience in using an Agile development framework to gather requirements, estimate tasks, distill business requirements into incremental features, and demonstrate new functionality to product owners.

3 Lead OneStream Developer

● Certified as OneStream Certified Professional (OCP) Lead Architect by OneStream™.

● Demonstrated experience in planning and designing solutions for OneStream Integration to include maximizing efficiency and developing a strategic design for the end-to-end solution (including interfaces).

● Expertise in providing technical, managerial, and administrative direction for problem definition, analysis, requirements development and implementation for complex systems in the subject matter area.

4 Lead OneStream Business Analyst

● Demonstrated experience in using an Agile development framework to gather requirements, estimate tasks, distill business requirements into incremental features, and demonstrate new functionality to product owners.

VII. Period of Performance, Place of Performance and Contract Type

1. Period of Performance

The Period of Performance (PoP) shall be 30 months.

2. Place of Performance

The Contractor may work offsite to perform the required service. The contractor is not expected to work on federal holidays. If the federal government shuts down for any reason, contractors may seek approval from the COR to telework during this time. All work performed under this contract must be performed within the United States.

3. Contract Type

The Government intends to issue a Firm Fixed Price (FFP) Task Order under the PBGC IDIQ Technology's Special Item Number (SIN) 54151.

VIII. Deliverables

Section Deliverable Format Timing Stored Location

V.2

Meeting minutes and agendas.

Capture attendees, topics discussed, decisions, etc.

Word template

Agenda sent prior to meeting; Meeting minutes within two days of meeting completion

SharePoint

V.2

Quality control plan. Ensure services and deliverables for the contract meet the highest level of quality and demonstrate continuing quality improvement.

Word One month after award. Updated annually or as needed.

SharePoint

V.2

Baselined project schedule in P3M. Resource loaded and contains all milestones

P3M (PBGC’s Project Online Tool)

One month after award. Updated as needed.

P3M

V.2

Project/Contract Management Plan (includes Risk Management Plan) Outlines plan for staffing, managing risk and issues, and other PM related tasks.

Word 10 days after kickoff meeting and annually thereafter.

Project SharePoint Site

V.2

Ad hoc reporting Word or as requested

As requested, no more than four per month

Project SharePoint Site

V.2

Project and Release/Sprint Status Reporting. PBIs planned vs accomplished, other highlights and/or impediments as they relate to current work, planned work, major milestones

Word or other as approved by the Government

Biweekly SharePoint

V.2 Sprint retrospectives/Lessons Learned: The capture and dissemination of Lessons Learned on an ongoing basis. In Agile, lessons learned are captured during Sprint Retrospectives and at additional key milestones

Private Sprint Retrospective s attended by the Scrum Team

Retrospectives (Lessons Learned) happened at the end of each sprint cycle and at the end of the release cycle.

SharePoint

Section Deliverable Format Timing Stored Location throughout the project as well as at the end of a project.

Release Cycle Lessons Learned are with the IPT and other stakeholders

V.2 Groomed Prioritized Backlog items. Product Backlog contains User Stories related to desired enhancements. Throughout release lifecycle new User Stories are created, existing user stories are refined and prioritized.

Accepted User Stories are completed/implemented requirements, configured, tested, and verified by Product Owner.

DevOps Epics, Features, Product backlog items, user stories/tasks

Biweekly DevOps

V.2 Sprint Plan: The output of Sprint planning, which kicks off the sprint, and defines what can be delivered in the sprint and how that work will be achieved.

SCRUM

Ceremony:

Sprint Plan

Beginning of Every Sprint.

Mapped to MVP

Azure DevOps Also, RTM (SharePoint)

V.3 Test scripts. Created for dev (product team testing), test (UAT), and prod (product owner) testing.

DevOps test plans

Developed for each release

DevOps Test Suites

V.3 Test Reports. At the end of each test cycle, a report is generated to include number of pass/fail test cases, bugs found, status, etc.

PowerPoint and/or DevOps and/or other approved format.

Delivered via email.

At the end of each testing cycle

DevOps and/or SharePoint

V.3 Automated Budget Execution Process in BDMS

Deployment Once BDMS;

configuration changes and code stored in DevOps Repos

V.4 Automated Master Staffing List in BDMS

Deployment Once BDMS;

configuration changes and code stored

Location in DevOps Repos

V.4 Training materials. Include training videos, user guides, job aids, user emails, etc.

Video, Word, email, other as approved by the Government

As needed SharePoint

V.4 Change and Communications Management plan. A comprehensive plan that documents the strategy to maximize BDMS end-user adoption, including stakeholder analysis, the marketing materials (e.g., intranet announcements, flyers), Training Plans and Training materials.

PowerPoint or Word

As needed, evaluated at each release/upgrade

SharePoint

V.5 Test Plan Process Document – Comprehensive process and strategy document that covers how to identify the scope of testing, test methods, approval processes, ensuring implementation meets its objectives, handling of defects, and tracking tests to user stories.

Word Prior to sprint zero completion. Updated as needed

SharePoint

V.5 Product Roadmap. Visual of all planned updates, releases, upgrades, etc. The product roadmap is the key communication tool for the Product Owner and PBGC executive leadership to communicate the BDMS implementation’s vision and timeline. Includes Planned Business Process Re-engineering Changes, broken out for sprints 1-N.

PowerPoint Monthly SharePoint

V.6 Initial Project Kick-off Meeting and slide deck. Covers understanding of work to be accomplished, stakeholders, planned upcoming activities and

PowerPoint Within two weeks from contract start

Location milestones. Can include both Operations, CPI, and major CPI

V.6 Business Process Re-engineering documentation for Budget Execution. New documented processes, procedures, standards, templates, flow charts, etc.

Word or other as approved by the Government

Prior to sprint zero completion

SharePoint

V.6 Business Process Re-engineering documentation for the Master Staffing List. New documented processes, procedures, standards, templates, flow charts, etc.

Word or other as approved by the Government

Prior to sprint zero completion

SharePoint

V.6 Product Backlog contains the Minimum Viable Product: During Sprint Zero and before commencing Sprint One, the product backlog is developed and refined in order to establish the BDMS Minimum Viable Product (MVP) so that Sprints can be planned, scheduled, and communicated in the Product Roadmap. User stories that are part of the MVP are labeled clearly as such.

DevOps user stories

End of sprint zero DevOps

V.7 Data Migration and Interface Implementation Strategy Plan.

This document shall describe, at minimum, the migration approach (e.g., what migrates, over what duration (e.g., current and 7 previous years, details on how the migration will be accomplished, how migration will be reconciled, etc.)), which interfaces will be approached in which order, roles, dependencies, key milestones and timing. In addition, it shall describe, at minimum. In addition, it shall include strategy for collecting data requirements, inventory of all the data and associated applications, current state of data (including data cleanup), and detailed migration

Word By the end of sprint zero. Updated as needed.

Location steps for extract, transform and load process (including data mapping, recovery, testing, etc.)Data Migration and Interface Implementation Strategy Plan.

This document shall describe, at minimum, the migration approach (e.g., what migrates, over what duration (e.g., current and 7 previous years, details on how the migration will be accomplished, how migration will be reconciled, etc.)), which interfaces will be approached in which order, roles, dependencies, key milestones and timing. In addition, it shall describe, at minimum. In addition, it shall include strategy for collecting data requirements, inventory of all the data and associated applications, current state of data (including data cleanup), and detailed migration steps for extract, transform and load process (including data mapping, recovery, testing, etc.).

V.7 Documented Risks and Dependencies.

P3M entry Prior to end of sprint zero

P3M

V.7 Team Working Agreement.

Document that outlines a baseline understanding of team norms and expectations.

Word Prior to end of sprint zero

SharePoint

V.7 Executive reporting deck.

Executive level briefing deck that covers background, scope, project snapshot, sprint zero status and/or delivery status, communications management status, next steps, etc.

PowerPoint Finalized prior to end of sprint zero.

Updated monthly

SharePoint

V.7 Deployment plan - Includes all the changes for PBGC and integrated systems and activities of any team or individual required to complete a deployment.

Word After each Prod deployment

SharePoint

V.7 ITSLCM documentation. BDMS documentation shall be high

Word (or other as

Updated/reviewed no less than quarterly.

Location quality, technically accurate, written for the appropriate audience and contain minimal grammatical and spelling errors.

BDMS should have all documents listed in the ITSLCM process unless otherwise stated by the Government approved by the Government)

Updated as needed after each release

V.7 ITSLCM process compliance. All gate reviews are met and appropriately signed off on by the Government, materials such as presentations are created, tracked, managed to completion through the project lifecycle.

PowerPoint, Word, DevOps, or as agreed upon

Biweekly SharePoint

V.8 Design Document and Technical Review Board Design Slide Deck: Design Artifacts are created /updated as part of acceptance criteria of the user stories. Include (or update) a network topology diagram. Compiled Design Document is finalized prior to all production releases. TRB design presentations are created as required.

Word (Design Doc) / PowerPoint (TRB Design Deck)

During sprint zero and updated throughout the duration of the effort and/or with each production release (as needed).

Azure DevOps SharePoint (Extract from Azure DevOps completed release)

V.10 Solution Environment Plan: This document defines BDMS environmental needs and provides a documented means of delivering and sustaining the environments needed to support BDMS milestones and production support.

Solution Environment Plan

Initially reviewed/updated during Sprint 0 and then updated through sprint cycles and finalized prior to production deployment.

SharePoint

V.11 Data Dictionary: Documents the collection of names, definitions, and attributes about data elements that are being used or captured across BDMS, including describing the meanings and purposes of data elements within the context of a project, and provides guidance on interpretation, accepted definitions and representation. The Data Dictionary also provides metadata about data elements such that it

Word Created during BPR and updated as required

Location assists in defining the scope and characteristics of data elements, as well the rules for their usage and application.