Attachment J-XX - 2030 Census Integration and Implementation Plan (IIP) V1.0 (1).pdf

2030 Census

Integration and

Implementation Plan

May 3, 2024

Version 1.0 i

Approval Signatures

This 2030 Census Integration and Implementation Plan has been reviewed and approved for use.

Barbara LoPresti Date Signed Chief, Decennial Information Technology Division

Jennifer Reichert Date Signed Chief, Decennial Census Management Division ii

Document Logs

Sensitivity Assessment

Verification of Document Content

This document does not contain any:

• Title 5, Title 13, Title 26, or Title 42 protected information.

• Procurement information.

• Budgetary information; and/or,

• Personally identifiable information.

Document Author: Nicole Seamands Date: 03/07/2024

Review/Approval

Name Area Represented Date

Daniel Doyle Deputy Chief, Decennial Census Management Division 05/02/2024

Ann Wittenauer Special Assistant, 2030 Census Planning 05/02/2024

Deidre Hicks Chief, Decennial Program Management Office 05/02/2024

Brian De Vos Assistant Division Chief, Architecture, Integration, Infrastructure, and Testing

03/07/2024

Version History

Version Date Description

1.0 05/03/2024 Baseline version sent for signature.

2030 Census Integration and Implementation Plan iii

Table of Contents

1 Introduction

1.1 Purpose and Scope

1.2 Intended Audience

1.3 Document Maintenance

2 2030 Census Integration

2.1 Why Integrate

2.2 What is Integrated

2.3 Who is Integrated

2.4 Methods of Integration

2.4.1 Overarching 2030 Census Integration

2.4.2 Program/Operation Level

2.4.3 System/Project Level

3 Program Increment Planning Ceremony

4 Program Milestones

4.1 Readiness Reviews: Formal and Informal Milestones

4.1.1 Stakeholder Requirements Review

4.1.2 Critical Design Review

4.1.3 Initial Baseline Review

4.1.4 Program Test Initialization Checkpoint

4.1.5 Program-Level Testing Checkpoint

4.1.6 Test Readiness Review

4.1.7 Production Readiness Review

4.1.8 Operational Readiness Review

4.1.9 Conduct Operations

4.1.10 Closeout Readiness Review

4.2 Star Milestones

4.3 Operational Deliveries

5 Program Monitoring

5.1 Integrated Master Schedule

5.2 Integration and Implementation Plan Milestone Dashboard

5.3 Change Control Process

APPENDIX A: Star Milestone Overview (Customized for Each Operational Delivery)

APPENDIX B: Referenced Documents

APPENDIX C: 2028 Dress Rehearsal Operational Delivery

APPENDIX D: 2030 Census Operational Deliveries iv

List of Figures

Figure 1: Integration and Implementation Plan

Figure 2: Program Milestone and Program Increment Relationship

Figure 3: System and Program/Operation Level Cadence

Figure 4: 2030 Census Readiness Reviews and Milestones

Figure 5: Example TRR and PI Approach

Figure 6: Sample 26CT IIP Milestone Dashboard

Figure 7: Operational Delivery Schedule

List of Tables

Table 1: Primary Artifacts Associated with SRR

Table 2: Primary Artifacts Associated with CDR

Table 3: Primary Artifacts Associated with IBR

Table 4: Deliverables for PLTC

Table 5: Primary Artifacts Associated with TRR

Table 6: Primary Artifacts Associated with PRR

Table 7: Primary Artifacts Associated with ORR

Table 8: Primary Artifacts Associated with CRR

1 Introduction

The 2030 Census Integration and Implementation Plan (IIP) describes the framework for integrating Information Technology (IT) solutions that comprise the 2030 Census systems architecture. The IIP provides an actionable framework for the functional integration of IT activities and operational milestones. It helps realize quality-driven designs, solutions, and methods that fulfill the business goals of achieving a cost-efficient decennial census through modern technology. The 2030 Census IIP also governs the implementation of the operations outlined in the 2030 Census Operational Plan.

The 2030 Census IIP document has an accompanying IIP Milestone Dashboard developed for each decennial census effort (2026 Census Test (26CT), 2028 Dress Rehearsal (28DR), and 2030

Census). The IIP Milestone Dashboard is a living artifact refined and adjusted to minimize risk and maximize efficiency while meeting the required timelines of the 2030 Census.

1.1 Purpose and Scope

The purpose of the 2030 Census IIP document is to outline the systematic approach for integrating various components, solutions, and processes within the 2030 Census. The 2030

Census is a complex program with interdependent relationships among numerous systems, solution providers, and stakeholders.

This document outlines the integration process across all parties involved, aiming to facilitate effective communication, resource allocation, and timely execution. The specific objectives of the IIP include:

• Establishing an Integration Framework: The IIP outlines a framework and methods for actively monitoring and communicating progress among stakeholders, solution providers, systems, and other relevant parties.

• Coordinating Integration Issues: Driving early coordination and resolution of integration issues to ensure the timely alignment of stakeholders, solution providers, and integrators for testing and deployment.

• Providing a Comprehensive Overview: Offering a comprehensive overview of the 2030

Census, aiding in identifying integration points and dependencies.

• Promoting a Collaborative Approach: Encouraging a collaborative approach to minimize risks, optimize efficiency, and adhere to the mandated timelines of the 2030 Census.

1.2 Intended Audience

This document is intended for all those involved in the systems architecture, engineering, program management, and IT solution development for the 2030 Census:

• Decennial Systems Engineering (SE) and Technology Integration (TI).

• Decennial Census Management Division (DCMD).

• Decennial Census purpose-built systems.

• Enterprise Initiatives (Business Ecosystem (BE)).

• Office of the Chief Information Officer (OCIO).

• Decennial Contracts Execution Office (DCEO) (contractor-delivered solutions).

• Other key 2030 Census stakeholders such as Population Division (POP), Decennial

Statistical Studies Division (DSSD), etc.

• Third-party contracted solutions.

1.3 Document Maintenance

The Decennial Information Technology Division (DITD) is responsible for creating and maintaining the 2030 Census IIP. This document is reviewed and updated periodically for continuity and accuracy.

2 2030 Census Integration

The success of the integration of the 2030 Census relies on effective communication and collaboration among diverse stakeholders and solution providers, each with their own development disciplines, schedules, and deliverables. The 2030 Census IIP outlines the methodology to integrate the people, processes, and technology across subsystems, systems, and the overarching System of Systems (SoS). Due to the number of stakeholders and scale of the 2030 Census, the program will utilize the Scaled Agile Framework (SAFe) to help ensure the successful integration of the 2030 Census SoS. The figure below demonstrates the levels and methods of integration.

Figure 1: Integration and Implementation Plan

2.1 Why Integrate

The 2030 Census SoS is extensive and intricate, encompassing numerous systems, interfaces, and thousands of people (users). This necessitates a comprehensive integration approach to ensure the SoS operates seamlessly as a unified, coordinated entity rather than a collection of disparate, disjointed capabilities.

To successfully execute the 2030 Census and coordinate the 2030 Census SoS integration activities, the Census Bureau brings together individuals1 from various teams, divisions, and directorates, each with their own goals, timelines, and focus areas. This setup underscores the importance of a comprehensive integration approach to describe how people and processes align with the overall 2030 Census objectives.

1 Individuals are different stakeholders and participants of the 2030 Census Program, such as various members of the teams from DITD, DCMD, OCIO, Field Operations Directorate, POP, DSSD, Geography Division (GEO), and others.

2.2 What is Integrated

The 2030 Census SoS architecture is created based on goals, objectives, and requirements from

Census Bureau subject matter experts (SMEs) and the Program Area stakeholders. The 2030

Census SoS consists of systems that span multiple directorates and third-party vendors and fall into the following groups, also referred to as subsegments:

• Data Capture and Processing: Systems dedicated to data capture during peak 2030

Census operations including various systems such as Internet Self-Response (ISR), Telephone, Field/Mobile Data Capture, Paper Capture, and Workflow Control.

• Statistical Processing: Systems used to continually maintain the optimal 2030 Census result throughout the decade. This is key to the transformational nature of the architecture as it leverages transactional and event-driven processing to process responses as they are captured.

• IT Support: Systems enabling infrastructure, including identity management, system health and security monitoring, Service Oriented Architecture (SOA) and microservices, provisioning and management of cloud native services, and Development, Security, and

Operations (DevSecOps) systems aiding deployment and engineering task management.

• Operational Support: Systems supporting the human/operational needs during peak

2030 Census operations, including solutions for Time and Attendance, Recruiting, Training and Field Infrastructure.

Effective SoS integration ensures seamless collaboration among various systems, interfaces, and operators, maximizing efficiency and accuracy in data collection, processing, and dissemination. By addressing interoperability, communication, data exchange, and coordination among the constituent systems, the 2030 Census integrated solutions can function as a cohesive and efficient entity.

2.3 Who is Integrated

The 2030 Census SoS complexity is compounded by the interdependency of systems, necessitating cooperation, collaboration, and communication among various stakeholders, including:

• Solution Providers: Teams building each system that makes up the SoS.

• Operational Providers: Teams operating the system, performing system processes, and/or executing non-system processes.

• Operational SMEs: Organizations defining methodologies and approaches for 2030

Census performance and providing requirements for the solution, such as DCMD, DSSD, and POP.

• Program Engineering Teams: Specialized teams driving integration between systems, including the Program Test Team, Program Requirements Team, Program Security

Team, Program Architecture Team, and others.

Each solution provider must not only understand their scope and timelines but also comprehend risks, scopes, timelines, and integration points with other systems. Engaging stakeholders, solution providers, and personnel from diverse organizations is essential to foster collaboration, cooperation, and coordination toward the common goal of 2030 Census integration.

2.4 Methods of Integration

The 2030 Census leverages the SAFe, customized to suit the program's unique needs to coordinate the integration. This tailored approach addresses three key levels of integration required for success:

• Overarching 2030 Census Integration.

• Program/Operational Level.

• System/Project Level.

For all levels it is imperative to foster close collaboration across the different stakeholders and technical teams to effectively navigate the complexities of the 2030 Census. This approach accelerates the delivery of working software and ensures that the solution meets the needs of stakeholders and overall program objectives.

2.4.1 Overarching 2030 Census Integration

At the highest level of integration, the 2030 Census progresses through three major efforts, each building upon the previous one: 26CT, 28DR, and 2030 Census execution.

Following this progressive approach, teams iteratively build and refine the SoS, avoiding the pitfalls of technical debt and ensuring that each integration stage contributes to the overall success of the 2030 Census. There is an iterative level of testing in between these large-scale tests to evaluate innovative technologies and/or strategies that do not require full scale tests but do require technical integration and the application of Readiness Reviews (RRs) and

Program Milestones to manage the effort.

2.4.2 Program/Operation Level

At the Program/Operational level, the SoS comes together to form the systems used in each major 2030 Census effort (section 2.4.1). The critical integration unit at this level is the

Operational Delivery (OD), which is the technical, logistical, and field work that must be coordinated to execute a set of operations that occur within the same timeframe and often use shared system functionality. The focus is on implementing and testing the operation and solution delivery (both IT and operational) and interfaces between the systems. This level of integration is facilitated by two key methodologies: Program Milestones and Program

Increments (PIs).

Each OD progresses through program milestones, calculated based on individual production go-live dates. The program milestones consist of formal, informal and star milestones that allow the program to drive and assess progress and readiness toward production. They also help ensure that all systems, solution providers, and various stakeholders align towards the same objectives and schedule.

Figure 2: Program Milestone and Program Increment Relationship

This level of integration also exercises the agile principles of planning, implementing, and tracking progress using a cadence of PIs that drive the completion of work towards the goals set by the program milestones. PIs are time-boxed and focus on delivering tangible value to stakeholders, allowing for rapid feedback loops and SAFe-based mechanisms for adaptation to potentially changing requirements. By breaking down integration efforts into manageable increments, teams can mitigate risks, maintain momentum, and ensure continuous improvement throughout the program life cycle.

PIs and Program Milestones (described in more detail in Sections 3 and 4) create both predictability and attainable cadence to all aspects of the program, which allows transparent and effective communication between 2030 Census executive-level leadership, business, and technical teams, and show timely dependencies among teams.

2.4.3 System/Project Level

At the System/Project level, solution providers are responsible for designing and developing their respective systems. Integration efforts at this level focus on interfaces between subsystems and aligning system functionalities with stakeholder requirements.

Each solution provider adopts modern DevSecOps methodologies and Continuous

Integration/Continuous Deployment (CI/CD) approaches to facilitate the continuous delivery and testing of code within their environments. While agile development methodologies are commonly used and recommended, Solution Providers can employ alternative approaches, such as Waterfall or Spiral, provided they adhere to the overarching models and constructs described at higher levels of integration.

The 2030 Census IIP, Program Milestones, PI Planning Ceremonies, and participation in these

PIs serve as critical resources for solution providers to better understand the integration points of other involved solution providers and stakeholders, important delivery dates, and help foster a common understanding of the goals and timelines required.

3 Program Increment Planning Ceremony

PI planning ceremonies are collaborative, structured, and fixed timebox sessions conducted every 8-12 weeks for all program participants. The goal is to set objectives, align work priorities, and track progress toward program milestones. During a PI planning ceremony, program leadership communicates the vision for the upcoming PI. That vision is then decomposed and allocated across all teams in the form of tasks and commitments.

These ceremonies offer a comprehensive view of all the planned work across the program, emphasizing dependencies across teams, operations, and schedules. Participants actively review prioritized and planned work for the upcoming PI to establish dependencies and integration points. PIs promote common understanding among stakeholders, ensuring that the delivered solutions adhere to the required schedule and effectively meet stakeholder requirements (Figure 3).

Figure 3: System and Program/Operation Level Cadence

During each PI, all participants of the 2030 Census Program come together to:

• Communicate accomplishments and upcoming deliverables.

• Report progress toward commitments.

• Demonstrate work products as appropriate, with most demos performed at the system level. Demos may also occur at the PI level if deemed appropriate.

• Provide timely feedback and suggest changes to dependent systems and solution providers.

4 Program Milestones

Program milestones serve as a planned and documented management methodology designed to assess the preparedness of a set of activities within the 2030 Census. They also mark the commencement and completion of major operational or programmatic activities, ranging from

RRs to critical dates like Census Day. These milestones serve as objective and independent data points, validating the satisfaction of prerequisites/dependencies and the review of administrative/technical procedures. Milestones can take on formal or informal characteristics:

• Formal milestones: Comprehensive and structured reviews with a clear decision-making process. RRs are a management methodology used to evaluate the preparedness of a set of activities. Each RR is a planned, documented activity providing visible, objective, and independent evidence that prerequisites for upcoming activities have been met.

• Informal milestones: Checkpoints in the program schedule to provide confidence that progress towards formal milestones is being maintained. An example of an informal milestone can be the readiness of a test environment or the completion of a work product.

• Star milestones: Interim milestones that breakdown program milestones into smaller, more manageable sections. Star milestones provide earlier checkpoints to identify potential issues and make necessary adjustments to remain on track. They are tracked at both the Program level and the OD level.

The following sections focus on program RRs and Star milestones.

4.1 Readiness Reviews: Formal and Informal Milestones

Readiness Reviews are a subset of program milestones that provide a logic gate to assess OD readiness when transitioning to a new life-cycle phase. The following figure depicts the sequence of the major RRs and milestones. Each of the RR milestones is defined throughout this section; however, details such as prerequisites and responsibilities are documented in the

2030 Census Systems Engineering Management Plan (SEMP) and the 2030 Census Test and

Evaluation Management Plan (TEMP).

Figure 4: 2030 Census Readiness Reviews and Milestones

4.1.1 Stakeholder Requirements Review

The Stakeholder Requirements Review (SRR) is a formal RR milestone, meticulously overseen by

DCMD. Its primary objective is to drive the collection and baseline of stakeholder requirements

(STRs). During the SRR, the business presents STRs to the 2030 Census, continuing the process until all requirements are shared and baselined. One SRR is completed where the business

Program Readiness Reviews (RRs) and Milestones

SSRS

RR

Initial Baseline Review

(Operational Delivery)

Solution requirements are designed, integrated, and documented to ensure system development and project level testing can begin.

Test Readiness Review

(Operational Delivery/Program Level Testing and Configuration

Management )

At TRR, End- to-End (E2E) integration testing of all functionalities begins.

Stakeholder Requirements Review

(DCMD/Program Areas)

Critical Design Review

(Architecture Team)

Production Readiness Review

(Operational Delivery/Program Level Testing and

Configuration Management)

Operational Readiness Review

(DCMD)

An informal milestone to ensure program test environments are available able to support DevSecOps implementation for Program Level Test (PLT) team to begin system checkout testing.

Program Test Initialization Checkpoint (PTIC)

Review and baseline of Stakeholder Requirements (STRs) by engineering and operations.

Allocation of STRs to solution providers begins.

Review high-level architecture and detailed business processes.

Solution Providers accept the STRs allocated to them.

Review and assess program level test results of an operation to ensure systems are ready for operational testing to begin.

Final check to validate all components of an operation are ready before the operations commence in Production.

CDR IBR TRR PRR ORR

An informal milestone to commence program level testing of incrementally delivered functionality.

Program Level Testing Checkpoint (PLTC)

SRR OD Kickoff ~2 Weeks Before CDR

CDR IBR* TRR* PRR* ORR

presents STRs for the scope of each OD.2 This enables requirements delivery to occur incrementally versus delivering all at once.

Concurrently, as SRRs take place for each OD, the DITD and Solution Architecture Teams engage in parallel activities, reviewing and discussing STRs with solution providers to build the SoS high-level architecture.

In response to lessons learned from the 2020 Census, the 2030 Census STRs incorporate the concept of Cross Operations (X-Ops) functions. X-Ops is a shared business component, needed by more than one Program Area and/or OD, to support execution of the census. DCMD business leads are assigned to each X-Ops. They collaborate across ODs to gather all requirements for their specific function. This approach ensures consistency, reduces duplicative efforts, and offers additional consideration for the first OD which leverages the specific cross-operation function. For example, a “Hiring” OD includes cross-functional areas such as Training, Kitting, Payroll, Crew Formation, and Time and Expense.

Table 1: Primary Artifacts Associated with SRR

Draft Baselined

• Solution Provider POC List

• Systems List

• Business Analysis Package (BAP), Business Process Models

(BPMs), Integrated Operations Diagram (IODs), etc.

• STRs (including functional and non-functional requirements)

• Detailed Operational Plans

After each SRR, the Solution Architecture team has the information necessary to start allocating requirements and creating the required SE and TI Architecture artifacts to be delivered at

Critical Design Review (CDR). The allocation of requirements to solution providers is completed on a flow basis after each SRR.

4.1.2 Critical Design Review

CDR is a formal milestone managed by DITD conducted once for the 2030 Census itself. At CDR, the SoS high-level architecture and supporting artifacts such as the Systems List and What Goes

Where Diagram are reviewed and baselined. At this milestone, the solution and operational providers fully understand and accept the STRs assigned to them. After accepting the STRs, solution providers begin documenting solution-level requirements.

2 For maximum flexibility for the 2026 Census Test, DCMD defined work by Program Areas (PAs) instead of ODs, so one SRR is conducted for each of the 10 PAs.

Table 2: Primary Artifacts Associated with CDR

Draft Baselined

Interface Catalog

• STRs

• Line of Business (LOB) Solution Architecture Diagram

• Solution Provider List

• System List

• “What Goes Where” diagram

4.1.3 Initial Baseline Review

Initial Baseline Review (IBR) is a formal milestone managed by the Business and the OD IT

Management Team (Technical OD Team). It is conducted for individual ODs several months before the program-level testing. In preparation for IBR, solution providers collaborate with their respective SMEs to review the allocated STRs to define the solution-level requirements.

Table 3: Primary Artifacts Associated with IBR

Draft Baselined

• Functional Integration Plan (FIP)

• Initial assessment from Section 508 program office of level of required compliance for systems (where applicable)

• Prioritized business threads by PIs

• Interface Catalog

• Workflow Diagrams (WFDs)

• System Sizing Models

• OD schedule (Level 2 Schedule)

• Solution Requirements (features)

• Detailed Design Document(s)

At the conclusion of an IBR, the approved solution-level requirements and/or created documentation enable teams to begin development and project-level testing. Additionally, environments such as Project-Level Test Quality Assurance (QA) and Project-Level User

Acceptance Test (UAT) (for identified solutions) are delivered and Ready for Use (RFU) for solution providers. At this stage, the OD Group of 4 (Go4) and Program-Level Test team prioritize business threads by PIs.

4.1.4 Program Test Initialization Checkpoint

The Program Test Initialization Checkpoint (PTIC) is an informal program milestone managed by the DITD. PTIC is conducted to ensure program test environments are available and can support

DevSecOps CI/CD pipeline implementations for program-wide test efforts. While not required, it is suggested that automated test suites are written in a matter to be run within a given stage of the CI/CD pipeline to reduce the potential of introducing unforeseen bugs into the system and therefore increase program-wide stability. PTIC covers the provisioning of higher test environments, which includes (where applicable) the Integrated Test Environment (ITE), Staging

(STG), and Training (TRN) environments and implementing processes necessary to adopt a

DevSecOps CI/CD pipeline. In summary, by PTIC, program-level test environments need to be

RFU, and systems must be ready to deploy an initial code base set to move to the next milestone – Program-Level Testing Checkpoint (PLTC).

Though not a formal review, the following artifacts must be delivered to meet this informal milestone: System Sizing Model and Systems Architecture and System Deployment Plan.

4.1.5 Program-Level Testing Checkpoint

Program-Level Testing Checkpoint (PLTC) is an informal milestone signaling the start of program-level testing for an OD. It ensures that appropriate test objectives, methods, procedures, scope, and test data are identified and coordinated to support the planned testing.

Based on the PI schedule, solution providers deliver testable code incrementally to facilitate program-level testing of prioritized business threads.

Table 4: Deliverables for PLTC

Delivered

Test Objectives, methods, procedures, scope, and test data

4.1.6 Test Readiness Review

Test Readiness Review (TRR) is a formal milestone for each OD to perform End-to-End (E2E) integration testing. TRR is managed by DITD. Program-level testing commenced at PLTC for the initial prioritized functionalities, referred to as business threads, which were developed and delivered incrementally in testable units. Testing continues in this incremental manner until the

TRR milestone date when all required functionality or business threads for an OD have been developed and delivered to the Program-Level Test (PLT) team to enable complete business thread E2E testing.

This approach allows teams to focus on designing, building, and testing functionality needed incrementally for an OD instead of waiting for all functionality to be delivered simultaneously.

Figure 5 provides an example diagram of the TRR and PI approach to delivering incremental functionality for two sample ODs.

Figure 5: Example TRR and PI Approach

TRR aims to start E2E Testing of all functionalities and certify that all pre-TRR star milestones have been completed. For example, by the date of TRR, the following must be completed:

• Project-level testing with no outstanding critical defects.

• Pairwise testing between solutions.

• The business tested and accepted the solution(s) UAT.

• Program-level test environments (ITE, STG, TRN, UAT) are RFU with code deployed.

• Authorization to operate (ATO) is acquired, if applicable.

Table 5: Primary Artifacts Associated with TRR

Draft Baselined

Production Runbook • Integration and Test (I and T) Plan

• ATO Status

• Prioritized business threads by PIs

• Release Notes by PIs and TRR

• Project-Level Test Analysis Report (TAR)

• Project-Level Test Requirements Traceability Matrix (RTM)

• FIP

• Application Programming Interfaces (API) Interface Control Documents (A/ICDs) for program-level test

4.1.7 Production Readiness Review

Production Readiness Review (PRR) is a formal milestone managed by the Technical OD Team.

The goal of the PRR is to review program-level test results, integration points, finalized documentation, and performance results of solutions to assess readiness to begin Operational

Readiness Testing (ORT). At PRR, the Technical OD Team confirms that program-level testing has been completed with no outstanding critical defects that would impact the ability to begin

ORT or perform stakeholder verification tests such as User Integration Acceptance and/or

Reports Testing. The definition of defect criticality and response plans are outlined in the 2030

Census Defect Management Plan.

Table 6: Primary Artifacts Associated with PRR

Baselined

• ORT

• PLT Team Test Analysis Report (TAR)

• Performance and Scalability TAR

• 508 Compliance or Certification Requirements Met (where applicable)

• A/ICDs ready for Production

• Production Runbook

4.1.8 Operational Readiness Review

Operational Readiness Review (ORR) is a formal milestone managed by DCMD that validates all applicable operations and cross-operational components are ready before the operation is conducted in Production. ORR is the final check that required resources (i.e., people, processes, solutions, and facilities) are available and fully equipped to begin Production activities. ORRs typically occur two weeks to a month before the conducting of operations and/or key operational start dates. At the conclusion of ORR, the expectation is to give formal approval to commence operations.

Table 7: Primary Artifacts Associated with ORR

Baselined

• ORT results / report

• System Checkout / Production smoke test results

• IT Production Operations Management Plan

4.1.9 Conduct Operations

The Conduct Operations (CO) milestone, although not a gate review, is a significant formal step overseen by the OD Team Go4. It signifies the official launch of an OD into production and the shift from a development to an Operations and Maintenance (O&M) model. The IT Production

Operations Management Plan (referenced in 0) serves as a guide for managing the production operations of the 2030 Census. Solution providers and stakeholders must use the IT Production

Operations Management Plan to understand the expectations for production OD support, incident reporting and escalation, rapid response processes, and ODs integration with

Enterprise O&M processes.

4.1.10 Closeout Readiness Review

The Closeout Readiness Review (CRR) is a formal review milestone conducted after the completion of operations for an OD. Managed by the technical OD team, its purpose is to assess whether the transition and shutdown/sunset activities of the OD can commence. Closeout plans describe the transition of the IT systems; confirm completion of business processes such as offboarding of employees; and detail the appropriate decommissioning, destruction, and/or transfer of materials, IT equipment, and data to their post-production target states.

Table 8: Primary Artifacts Associated with CRR

Baselined

• Data Reconciliation Report

• Transition Plan – Includes plan for transitioning to the next OD, closing out or transitioning systems, de-staffing plans, and system dispositions

4.2 Star Milestones

Star milestones are a set of interim progress milestones that occur between RRs. These star milestones ensure a common understanding of milestones, demonstrate major dependencies, and enable participants to act earlier rather than just relying formal RR milestones. Star milestones are aligned with program milestones and PIs for easy tracking and scheduling.

Leveraging star milestones maximizes the efficiency of downstream activities. Appendix A lists star milestones, when they occur, and whether they are OD or Program driven.

4.3 Operational Deliveries

The 2030 Census IIP is driven by ODs, comparable to the SAFe concept of Release Trains. ODs use the high-level program milestones dates from the IIP to develop and manage lower-level schedules for their respective ODs. An OD consists of a group of functionalities released to production at a specific time to meet a set of business objectives. The goal of the OD is to ensure the complete set of activities/solutions are delivered per requirement and on time. ODs may be split into sub-ODs to better manage and track unique functionalities.

The OD Team managing an OD is referred to as the Go4. The Go4 is responsible for preparing for, executing, and monitoring the production of the OD in the 26CT, 28DR, and 2030 Census

Peak Production to ensure successful outcomes. The DCMD Program Manager commissions the

Go4 which consists of the OD Lead, Readiness Lead, Technical OD Manager, and, where needed, a representative from another division such as a Field Division lead or others.

Depending on the scope of an OD, the OD Team Go4 representation can consist of more than four members.

The primary roles of the Go4 are:

• To make decisions (“command and control”) and lead the effort up to and during production, starting at the IBR gate review.

• To help ensure solution providers and operations deliver on time by completing a series of RRs and related activities.

Once the 2030 Census ODs are defined, the schedule for each OD is baselined by CDR. In preparing an OD schedule, general guidelines are followed to establish the duration and milestones of each OD. The OD schedules are customized based on the complexity of the OD and on planned activities such as a soft launch and training. The Operational Delivery

Management Plan (ODMP) provides further information on ODs, including how the 2030

Census plans, tracks, manages, and deploys ODs throughout their life cycle.

5 Program Monitoring

Program Monitoring begins with establishment of the Integrated Master Schedule (IMS). High-level dates are used to create the IIP Milestone Dashboard (Level 1 schedule), which breaks down the major milestones into ODs and RRs. The Level 2 schedule is further broken down into the star milestones. PIs is used to plan work against major and star milestones dates to monitor work to be accomplished for an OD. Lastly, the Change Control Process controls scope, schedule, and cost changes.

5.1 Integrated Master Schedule

The 2030 Census Schedule Management Plan (SMP) documents the schedule framework and the management processes covering schedule development, baselining, reporting, quality, risk analysis, statusing, and change control. The objective of the SMP is to ensure that a comprehensive, accurate, IMS is developed with sufficient detail and summary levels to manage the 2030 Census.

The IMS builds a comprehensive timeline incorporating infrastructure, solution design, development, and deployment activities to provide insight into program performance at multiple levels. The milestone dates for each census test, the 2030 Census, and the ODs are baselined and statused in the IMS. The IIP Milestone Dashboard, which establishes ODs and program milestone dates, feeds into the IMS. The IMS is the master schedule that ties together the IIP, acquisition, OD, and other schedules.

5.2 Integration and Implementation Plan Milestone Dashboard

The IIP Milestone Dashboard reflects the set of ODs for a particular census test or the 2030

Census and indicates critical milestone dates to guide program delivery. Development of the IIP

Milestone Dashboard is a collaborative endeavor shared by DITD, DCMD, solution providers, and other key stakeholders. To produce the IIP Milestone Dashboard, DITD holds meetings with

DCMD to understand existing ODs and define the relevant milestones and dates. The milestone dates are then used to create the solution provider schedule templates. A sample of the 26CT

IIP Milestone Dashboard is shown in Figure 6.

Figure 6: Sample 26CT IIP Milestone Dashboard

5.3 Change Control Process

The 2030 Census Program Change Control Process is where proposed changes to the 2030

Census’s scope, schedule, and cost are reviewed and dispositioned. Approved changes must be implemented, documented, and communicated to all stakeholders. The 2030 Census Change

Management Plan outlines the change request (CR) workflow and other relevant guidance.

APPENDIX A: Star Milestone Overview (Customized for Each Operational Delivery)

APPENDIX B: Referenced Documents

The document Planning and Coordination Documents for 2030 Census Program contains an active directory of planning and coordination documents for the 2030 Census Program. Examples include the DMP, the ODMP, the IIP, and the IIP Milestone

Dashboard. Items in this list are subject to change based on the needs of the 2030 Census Program. As new versions of each document become available, this document will be updated to the latest complete version.

2026 Census Test ODs

The list of ODs identified for the 2026 Census Test is maintained at the DITD Operational

Delivery IT Management Branch SharePoint site.

Figure 7: Operational Delivery Schedule

APPENDIX C: 2028 Dress Rehearsal Operational Delivery

Once determined, the list of ODs identified for the 28DR will be available on the DITD OD IT

Management Branch SharePoint site.

APPENDIX D: 2030 Census Operational Deliveries

Once determined, the list of ODs identified for the 2030 Census will be available on the DITD

OD IT Management Branch SharePoint site.