ORR_OPTM_HSPRS_PWS_Public_Acquisition_Neutral.docx

PERFORMANCE WORK STATEMENT

Department of Health & Human Services Administration for Children and Families (ACF) Office of Refugee Resettlement (ORR) Division of Technology ORR OPTM Platform and Home Studies/Post-Release Services Application Enhancement and Support

TABLE OF CONTENTS

1.0 GENERAL

· 1.1 Introduction / Background

· 1.2 Objective

· 1.3 Scope of Work

· 1.4 Period of Performance

2.0 REQUIREMENTS

· 2.1 General Requirements

· 2.1.1 Personnel Requirements

· 2.1.1.1 Key Personnel Requirements

· 2.1.2 Telecommuting

· 2.1.3 Department of Homeland Security Requests

· 2.2 Specific Requirements

· 2.2.1 Task 1: Transition-In (Base Year Only)

· 2.2.2 Task 2: HS/PRS Application Enhancement and Support

· 2.2.2.1 Recent Enhancements and Functionality

· 2.2.2.2 Backlog for This Contract

· 2.2.3 Task 3: OPTM Platform Infrastructure Operation, Maintenance, and Enhancement

· 2.2.3.1 ORR API

· 2.2.3.2 Shared Services Library

· 2.2.3.3 Forms API

· 2.2.3.4 Developer Experience and Governance

· 2.2.4 Task 4: Data Collection and Reporting

· 2.2.4.1 Performance Requirements

· 2.2.4.2 Emergency Response Services

· 2.2.4.3 Material Changes

· 2.2.4.4 System Use and Data Integrity Requirements

· 2.2.4.5 Data Categories, Metrics, Analysis, and Reporting Requirements

· 2.2.4.6 Ad Hoc Reporting Requirements

· 2.2.5 Task 5: Transition-Out

· 2.3 Other Requirements

· 2.3.1 Meetings

· 2.3.1.1 General Requirements

· 2.3.1.2 Contract Status Meetings

· 2.3.1.3 Contract Performance Review Meetings

· 2.3.1.4 Kick-Off Meeting (Base Period Only)

· 2.3.1.5 Sprint Ceremonies and Program Increment Planning

· 2.3.1.6 Tooling

· 2.3.2 Other Required Plans

· 2.3.2.1 Project Management Plan (PMP) Minimum Requirements

· 2.3.2.1.1 Transition-In Plan Minimum Requirements

· 2.3.2.1.2 Transition-Out Plan Minimum Requirements

· 2.3.2.1.3 Contract Management Plan Minimum Requirements

· 2.3.2.1.4 Quality Management Plan Minimum Requirements

· 2.3.2.1.5 Communication Plan Minimum Requirements

· 2.3.3 Reporting Requirements

· 2.3.3.1 Project Progress Reports

· 2.3.3.2 Contractor/Subcontractor Staffing Reports

3.0 CONTRACTOR QUALITY MANAGEMENT

4.0 DELIVERABLES SCHEDULE AND PERFORMANCE REQUIREMENTS SUMMARY

· 4.1 Deliverables Schedule

· 4.2 Performance Requirements Summary (PRS)

· 4.3 CPARS-Aligned Performance Rating Scale

5.0 TRAVEL

· 5.1 General Travel Requirements

· 5.2 Local Area Travel

· 5.3 Travel Planning and Approval

6.0 STAFF CONDUCT

· 6.1 Personnel Standards of Conduct SOLICITATION TEXT (Section H)

· H.1 Media and Social Media

· H.2 Background Investigation and Suitability Determinations

· H.3 Records Management

· H.4 Information Security Requirements

· H.5 Contractor Staff Mandatory Training (Security Training)

· H.6 Compliance Requirements — Section 508 / ICT Accessibility

· H.7 Artificial Intelligence

· H.8 Operations and Maintenance for a Federal IT System

· H.9 Applicable Documents

· H.10 Compliance with Regulations, Policies, and Procedures

· H.11 Conflict Resolution SOLICITATION TEXT (Section D)

· D.1 Government Furnished Property/Equipment

SOLICITATION ATTACHMENTS

· Attachment 7 — Deliverables Schedule and Performance Requirements Summary

· Attachment 8 — Quality Assurance Surveillance Plan (QASP)

· Attachment 9 — Glossary of Abbreviations and Acronyms

1.0 GENERAL

1.1 Introduction / Background

The Administration for Children and Families (ACF) Office of Refugee Resettlement (ORR) within the U.S. Department of Health and Human Services (HHS) provides funding and oversight to state-licensed shelters throughout the United States for children referred to ORR by the Department of Homeland Security (DHS). These children are known as unaccompanied alien children (UACs). They include both children who enter the country without their parents or legal guardians and children who for other reasons have been separated from their parents or legal guardians. By law, HHS has custody and must provide care for each UAC, defined as a child who has no lawful immigration status in the United States; has not attained 18 years of age; and, with respect to whom, there is no parent or legal guardian in the United States, or no parent or legal guardian in the United States available to provide care and physical custody. The increased influx of UACs required a product that could adapt quickly to changing requirements and provide strategic and tactical information.

ORR's Division of Technology is modernizing all technology applications and products that support UACs; this service ecosystem is known as ORRbit. A major near-term goal for ORR is to retire the legacy UAC Portal. To accomplish this, ORR has moved some user workflows, functionality, and infrastructure to a microservice-based application model within the ORRbit ecosystem. While some functionality is a 1:1 lift and shift, most of the applications being developed within ORRbit are being re-imagined, incorporating modern technology practices and human-centered design. The end goal is to ensure all functionality meets user needs and allows them to do their jobs as efficiently and effectively as possible.

The HS/PRS applications transitioned into production in August 2025, and users across Provider grantees, Federal Field Specialists (FFS), and ORR headquarters staff are now conducting live case management work supporting unaccompanied alien children within the OPTM environment. The applications are actively supporting time-sensitive case workflows, and both the ORR API and Shared Services Library are in continuous use by multiple integrated product teams across the ORRbit ecosystem. The applications and platform infrastructure require uninterrupted operation, maintenance, tier 3 support, and continued backlog delivery to support ORR's statutory child welfare responsibilities. Continuity of the technical team performing this work is essential during the bridge period to prevent service degradation, preserve institutional knowledge of the OPTM microservice architecture and legacy UAC Portal integration points, and maintain application uptime for users conducting active case work. This contract will provide continuity of operations and continued delivery while the Government completes the competitive follow-on acquisition and transitions services to the successor contractor

1.2 Objective

The purpose of this requirement is to accelerate ORR's modernization by seamlessly supporting users as they transition from legacy systems to modern applications. As such, users may experience significant changes in how they work. This contract will ensure that users are fully supported during these transitions through onboarding, training, access permissions, testing, and other adoption activities while collecting feedback to continuously improve the ORRbit user experience.

1.3 Scope of Work

This contract requires an agile delivery team to continue expanding and developing two existing applications on the ORR modern platform and infrastructure. These applications for Home Studies and Post-Release Services (HS/PRS) are currently in production. A Contractor team is required to continue building out and enhancing functionality from the backlog as well as provide tier 3 end-user support and training for the applications.

The Contractor shall deliver prioritized enhancements to the HS/PRS functionality. ORR is sunsetting its legacy case management system, UAC Portal. This system lacks many modern technology and design principles that are incorporated as part of HS/PRS development.

These applications are hosted in ACF's AWS Next Generation Secure Cloud (NGSC) and push to an AWS S3 bucket. The Contractor shall maintain that integration as well as potential additional S3 or other integrations that may be established later. Additionally, the applications were developed with a Java Springboot backend and NextJS/React frontend. They are deployed using GitLab CI/CD, Terraform, Helm, and Flux.

Other frameworks may be proposed and implemented by the Contractor. Any proposed tech stack changes require prior written approval from the Contracting Officer's Representative (COR) and, where the change affects security posture or the FedRAMP boundary, from the ACF OCIO. Any proposed tech stack changes shall not disrupt the current application uptime or roadmap.

Additionally, the Contractor shall operate, maintain, develop, and enhance the ORR data abstraction layer and associated infrastructure. This includes the APIs, CI/CD Pipeline, and overall developer experience for the platform and the services built on it. Additional pieces of infrastructure that may need to be operated and maintained under this contract include an API gateway, service mesh, system-to-system authentication, and potentially others.

The Contractor shall be required to manage and maintain aspects of developer experience across product teams. This includes onboarding, documentation, access procedures, and other activities that enable teams to build on top of the capabilities developed and maintained under this contract in a seamless manner.

The Contractor shall develop and manage a governance process to facilitate multiple teams' ability to develop new microservices while maintaining high code quality and reliability. Any team should be able to propose an API change without a high level of difficulty while maintaining high reliability and adhering to code quality standards.

The Government may also request proof-of-concept or demos of ideas that can create efficiency in overall development and deployment processes.

1.4 Period of Performance

The period of performance for this contract consists of a 12-month base period beginning on the date of award. In accordance with Federal Acquisition Regulation (FAR) clause 52.217-8, Option to Extend Services, the Government may require continued performance of any services within the limits and at the rates specified in the contract for a period not to exceed six (6) months. The Contracting Officer (CO) may exercise this option by written notice to the Contractor within the period specified in the contract clause.

The total potential period of performance, including exercise of the FAR 52.217-8 extension, shall not exceed 18 months from the date of award.

The Contractor shall perform the requirements of this PWS while the Government completes a competitive follow-on acquisition. The Contractor shall support an orderly transition of services to the successor contractor or the Government in accordance with the transition requirements of this PWS. The Contractor shall plan and execute all work under this contract with the understanding that services will transition to a successor contractor selected through full and open competition at the conclusion of the period of performance.

2.0 REQUIREMENTS

2.1 General Requirements

2.1.1 Personnel Requirements

The Contractor shall provide qualified personnel with the technical skills necessary to execute the tasks defined in Section 2.2. Personnel must meet all onboarding, background investigation, and security training requirements defined in the solicitation.

2.1.1.1 Key Personnel Requirements

Key personnel shall be identified in the Contractor's proposal. Any changes to key personnel during contract performance require advance written notification to and approval by the CO/COR.

2.1.2 Telecommuting

The Contractor (and Subcontractors) are permitted to telecommute under the performance of this contract.

2.1.3 Department of Homeland Security Requests

The Contractor is expected to cooperate with and abide by all requests made by DHS (data, permission to visit, requests for custody for law enforcement purposes) and the Contractor is to notify U.S. Citizenship and Immigration Services (USCIS) / Immigration and Customs Enforcement (ICE) and ORR of any arrest of a UAC or refugee.

2.1.4 Scope Limitation – No Direct Contact with Children

Contractor personnel under this contract perform technology infrastructure development, application enhancement, tier 3 end-user support, and platform operations. Contractor personnel do not have direct or supervisory contact with unaccompanied alien children (UAC), do not perform care-provider functions, and do not have physical access to ORR-controlled facilities where UAC are housed. Accordingly, requirements applicable only to personnel with direct child contact (including child abuse affirmation, mandatory reporting, and child-contact background investigation components identified in UAC Bureau Policy Guide Sections 4.3.3, 4.3.3.1, and 4.3.3.3) are not incorporated into this contract. All personnel security, background investigation, records management, and information security requirements applicable to Contractor personnel with access to HHS/ACF/ORR information, IT systems, or data remain fully applicable.

2.2 Specific Requirements

This contract consists of five tasks:

· Task 1: Transition-In (Base Year Only)

· Task 2: HS/PRS Application Enhancement and Support

· Task 3: OPTM Platform Infrastructure Operation, Maintenance, and Enhancement

· Task 4: Data Collection and Reporting

· Task 5: Transition-Out

2.2.1 Task 1: Transition-In (Base Year Only)

The Contractor shall execute transition-in activities necessary to establish performance under this contract and ensure continuity of services without interruption. The Contractor shall coordinate with the Government and, as applicable, the outgoing contractor to assume responsibility for the required services and achieve full operational capability within the transition-in period.

The Contractor shall complete all transition-in activities within 30 calendar days of award. Transition-in activities shall include, at a minimum:

· Confirmation that sufficient qualified key personnel and staff are assigned and available to perform under this contract in accordance with Section 2.1.1.1;

· Verification that all active background investigations, suitability determinations, Personal Identity Verification (PIV) credentials, Government-Furnished Equipment (GFE) assignments, and system access remain current and transferable to this contract;

· Confirmation of access to all source code repositories, CI/CD pipelines, Terraform/Helm/Flux configurations, cloud environments, API and service documentation, and knowledge management repositories necessary for contract performance;

· Confirmation of continuity of all in-flight sprints, Program Increment (PI) objectives, and open backlog items, with no interruption to sprint cadence or delivery;

· Confirmation of continued tier 3 end-user support operations with no gap in coverage or response times;

· Confirmation of continued platform infrastructure operations, including uninterrupted monitoring, logging, alerting, incident response, and vulnerability management for the ORR API, Shared Services Library, and Forms API;

· Delivery of an updated Contractor roster in accordance with Section H.4, Information Security Requirements.

Transition-In Plan. The Offeror shall provide a Transition-In Plan as part of its proposal, which shall be a component of the Contractor's Project Management Plan defined in Section 2.3.2.1. The Transition-In Plan shall describe how the Contractor will assume responsibility for the required services, complete necessary knowledge transfer and administrative activities, and maintain continuity of operations. The plan shall describe how the Contractor will:

· Ensure zero interruption to application availability, tier 3 support, in-flight sprints, and platform infrastructure operations;

· Complete all administrative and contract vehicle establishment activities within 30 calendar days;

· Identify any personnel, credentialing, or access continuity risks and mitigate them prior to the effective date of this contract;

· Maintain full sprint velocity and PI commitments during the transition-in period.

Transition-In Reporting. During the 30-day transition-in period, the Contractor shall provide weekly status reports to the COR that include:

· Any updates to the Transition-In Plan; - Timeline and milestones to achieve full operational capability;

· Confirmation of continuity in staffing, access, credentialing, GFE, sprint delivery, tier 3 support, and platform infrastructure operations;

· Staffing: detailed by-position (and name, as necessary) status of onboarding, background check/suitability determination status, turnover, and full performance;

· Known and potential risks to continuity of services and the Contractor's mitigation plan; Other issues and challenges;

· Assistance required from the Government.

Upon completion of transition-in, the Contractor shall notify the COR in writing that transition-in is complete and shall confirm that all required services are being performed without interruption under this contract. The Contractor shall submit this notification to the COR via email and, in addition, via API submission consistent with the reporting infrastructure established under Task 4 (Section 2.2.4).

See PWS Section 4.0 and Attachment 7, Deliverables Schedule and Performance Requirements Summary.

2.2.2 Task 2: HS/PRS Application Enhancement and Support

A user in UAC Portal would generate a referral for a Home Study at the request of a Case Manager. That referral turns into a Home Study case that is completed by a Home Study Provider. This application facilitates the home study case management process. Users for these applications include Provider grantees and Federal Field Specialists (FFS). Like Home Studies, a user in UAC Portal generates a referral for Post-Release Services at the request of a Case Manager. That referral turns into a PRS case that is completed by a PRS Provider. This application facilitates the post-release service case management process. Users for these applications include Provider grantees and FFS.

The Contractor shall maintain and enhance functionalities that have been developed or are currently under development and shall design and develop new functionality identified in the backlog using modern technology and design principles. Additional functionality and enhancements may be added after award as prioritized by the Government.

Core functionality for both HS and PRS has already been built, and the applications were launched to users in August 2025. It is possible that any of the features listed below will need to be enhanced or iterated upon during performance.

2.2.2.1 Recent Enhancements and Functionality

Home Studies:

· Table of Home Study referrals (minimal)

· Case detail view (minimal)

· Ability for users to assign case to case manager

· Ability for users to assign case to supervisor

· Referral list view (detailed)

· Case detail view (detailed)

· Ability of user to accept cases

· Ability for users to create and submit Home Study Assessment form

· Ability for users to create and submit Home Study Addendum

· Ability for users to take various case actions

· Ability for a user to close a case Post-Release Services:

· Referral list view

· Active cases view

· Case detailed view

· Ability for users to accept cases

· Ability for user to assign case to a case manager

· Ability for users to assign case to supervisor

· Ability for users to create and submit Addendums

· Approval workflow for submitted forms

· Notice of Concern form

· PRS Report form

· Virtual Check-In form

· Ability for users to take various case actions

· Ability for users to close a case

· Case Notes

· Child Profile View with tabs, relationships, and other information

· Table of children past and present in ORR care

· Upload documents and display documents from legacy system

· Add, edit, and comment on flags

· Decoupling permissions from legacy system

2.2.2.2 Backlog for This Contract

The following functionality shall be prioritized and delivered under this contract. Except where HS or PRS are specified, backlog tasks shall be applied generally to children within the system. All functionalities shall be designed and developed from end-to-end.

Approval of Workflows and Case Actions

· Ability for home study providers to request extension of a case close date. Integrate with ORR's Horizon and Integrated Care and Case Management (ICCM) platforms to allow FFS to approve extensions in ICCM. These platforms are built on Palantir Foundry.

· Enhance close case functionality for PRS to allow for data and reason of closure.

· Enhancements to overall approval workflow for HS/PRS including case extensions, addendum requests, referral requests, and direct transfers.

· Enhancements to comments, Addendums, and forms.

· Improved review commenting for requested edits.

· Flexible case review structure and a multi-reviewer workflow.

· Priority case flagging.

Case Assignment

· Ability for users to assign and auto-assign cases. Automatically assign related cases to a provider who accepted the first in a group.

· Auto-assign cases based on capacity, past cases with the same sponsor or related children, location, level, or other factors.

· Allow users to assign additional case team roles.

· Ability for users to assign a subcontractor to case.

· Ability of ORR users to refer PRS cases. National Call Center (NCC) users can request PRS referrals from ORR.

· External Home Study direct transfer ability, allowing a user to transfer case directly to another Provider.

Notifications and Messaging

· Configurable notifications system including user notifications of important changes and actions requiring review. Unread notification indicator.

· Cross-application notifications so that when an action is taken in another ORRbit application it triggers a notification in HS/PRS where applicable. Leverage Kafka for logging and notifications.

· Messaging and commenting on objects within the application.

Search and Navigation

· Keyword search of documents and flags within a child profile.

· Global search.

· View My Cases page.

· Referral list enhancements.

· Information Architecture expansion and enhancement.

· Activity feeds.

· Document lists.

· Inbox.

Profiles and Related Information

· Add a profile page for sponsors, alternate caregivers (ACGs), and household members.

· Update related cases for shared sponsors and locations.

· Update PRS household members, alternative caregiver, and other household information post-release.

· Save important contacts and information.

· Update profile information with form submission, user interface opt-in.

· Ability of users to change address. Currently UAC Portal is unable to do this outside the Notice of Concern (NOC) form.

· Link related objects and documents.

Forms and Reporting

· Improve forms for usability, may require Paperwork Reduction Act (PRA) requests.

· Multi-page form user experience with progress indicators and improved print functionality.

· Enhance Custom Notes, Reports, and Extensions (CNRE) forms library to include new components such as image and file upload, advanced text editor, and tables.

· Updated forms and case actions to automate quarterly provider reporting.

External Integrations

· Integration with Salesforce staffing module.

· External API for providers to submit reports, case notes, and updated case information directly from their provider systems.

· Display provider capacity when accepting cases, integrate with grants management tool.

· Integrate with ICCM to display legacy Sponsor Assessment and significant incident reports (SIRs).

· Additional legacy information to support HS/PRS Providers.

Documents and Legacy Data

· Display documents from the legacy system.

· Display medical assessments and information in the applications.

Dashboards, Analytics, and Landing Page

· PRS oversight dashboard for Project Officers (POs) to view analytics and flag anomalous behavior.

· Enhanced landing page to include role-specific dashboards.

· Ability to display available Provider locations via Map.

· Ability to display HS and PRS case capacity view.

Training and In-Application Support

· Host all training materials, release notes, and user guides within the application.

· In-application training materials.

2.2.3 Task 3: OPTM Platform Infrastructure Operation, Maintenance, and Enhancement The Contractor shall operate, maintain, develop, and enhance the ORR data abstraction layer and associated infrastructure, including the components identified below.

2.2.3.1 ORR API

This API fetches from the UAC Oracle database system of record and can pull any data point. The goal of the ORR API is to expose data storage — including both old and new UAC databases and S3 buckets — in a way that is logical and consistent with business understanding and data entities, such that meaningful integrations can be built on top of it without needing to understand the underlying data structures.

As functionality is progressively launched into the ORRbit ecosystem, the Contractor shall evolve the ORR API to integrate with new ORRbit services while continuing to maintain the original API.

The Contractor shall:

· Develop new endpoints for the API as requested and prioritized with the Government.

· Coordinate with internal and external teams for usage and integration with this API.

· Perform data ETL (extract, transform, load) operations in accordance with compatibility and business logic.

· Integrate with access management and permissions structure used by the case management system.

· Understand and translate business requirements for API integrations into technical architecture and completed implementation.

· Establish and maintain robust observability and reliability practices including monitoring, logging, alerting, tracing, and incident response plans.

2.2.3.2 Shared Services Library

This microservice Java library is imported and used by other APIs and microservices that ORR has developed. It provides essential functionality for building microservices within the ORR Process and Technology Modernization (OPTM) ecosystem. The library streamlines development by offering pre-configured components and standardized implementations of common patterns. The main functions of this library include:

· Authentication and SSO integration. Manages user access to applications using Office of the Administration for Children and Families Information Systems (OASIS) App Launcher credentials. App Launcher is the single sign-on service managed by a separate contract team. The Contractor shall provide integration support for the Authentication API, including updating roles needed by service-to-service accounts.

· Error handling and logging. Ships logs and errors to relevant observability systems such as Grafana.

· Database integration. Provides a data model configuration for use by the API that integrates with Oracle.

2.2.3.3 Forms API

This API-connected form generator allows custom form generation and pushes data to the UAC database system of record. The Contractor shall work with the Government to move toward a drag-and-drop front-end and away from JSON, which will allow for user-created forms. The goal is to allow any user to access the service to generate forms. New forms shall require additional enhancements to CNRE. The Contractor shall be responsible for these enhancements as prioritized by the Government.

2.2.3.4 Developer Experience and Governance

The Contractor shall manage and maintain aspects of developer experience across product teams, including onboarding, documentation, access procedures, and other activities that enable teams to build on top of the capabilities developed and maintained under this contract in a seamless manner. The Contractor shall develop and manage a governance process to facilitate multiple teams' ability to develop new microservices while maintaining high code quality and reliability.

2.2.4 Task 4: Data Collection and Reporting

The Contractor shall establish and maintain a comprehensive data collection, analysis, and reporting system to support program oversight, performance monitoring, and continuous improvement. Data shall be collected in accordance with ORR policies and reported in accordance with this section as well as Section 2.3.3, Reporting Requirements, and Section 4.0 and Attachment 7 (Deliverables Schedule and Performance Requirements Summary).

To support program oversight and continuous improvement, the Contractor shall provide robust data collection, analysis, and reporting, which shall include, but is not limited to, application usage and adoption metrics, system performance and reliability metrics, backlog delivery velocity, user support ticket outcomes, and real-time development and operational status. This data shall be made available through:

· Secure, interoperable dashboards with role-based access controls.

· Direct connection to existing ORR platforms and tools via documented integration methods that comply with HHS security standards (including application programming interfaces (APIs), secure file transfer protocols, and cloud storage solutions such as S3 buckets).

· Network infrastructure development and ongoing maintenance to ensure reliable, secure connectivity between systems, including uptime monitoring, security patching, and performance optimization.

· Documentation of data definitions, collection methodologies, and reporting specifications, system architecture diagrams, data flow maps, and network topology to ensure transparency and reproducibility.

The Contractor shall use this data to identify trends, assess service delivery effectiveness and Contractor performance, and provide actionable recommendations to ORR. All data collected under this contract shall be made available through dashboards and direct connections to existing ORR platforms and tools (including APIs). Data shall be made available in a structured, searchable database format (Parquet, JSON, XML, or CSV as appropriate for system integration).

2.2.4.1 Performance Requirements

· Data Collection and Data Management Infrastructure and Systems. The Contractor shall maintain a data collection and management system that (1) ensures compliance with ORR reporting requirements, and (2) centralizes all information related to system performance, application delivery, and user support activities. To the maximum extent practicable, data entry into the system shall be concurrent with services provided. The Contractor shall maintain all data and information related to individual services and shall not delete, destroy, or permanently remove any data throughout the duration of this contract and for the time further required by Records Management provisions.

· Secure Data Reporting Infrastructure. The Contractor shall maintain a secure and scalable data infrastructure and computing environment that enables:

· Raw data ingestion from disparate sources;

· Extract-transform-load (ETL) processes to clean, organize, and connect data from various sources;

· Analysis of quantitative data at a scale appropriate for the work completed.

· Third-Party Data Validation. The Contractor shall validate all data received from third parties (including Subcontractors) prior to transmission to ORR systems. This includes ensuring data accuracy, completeness, and consistency with supporting documentation. The Contractor shall implement quality control procedures, including routine audits and reconciliation of reported data against source records.

· Routine Changes. The Contractor's data environment shall accommodate routine changes (service areas, policy updates, service delivery modifications) with implementation within 30 calendar days of notification.

· Volume Fluctuations. The Contractor's data environment shall automatically scale to accommodate up to a 50% increase or decrease in data volume without performance degradation.

2.2.4.2 Emergency Response Services

Emergency response services are time-sensitive adaptations necessary to support urgent operational, statutory, oversight, interagency, or humanitarian needs as determined by ORR. These may include rapid modifications to data collection, reporting, system access, integration interfaces (including APIs), or data transmission processes. Such adaptations may require accelerated configuration, development, testing, or deployment activities.

The Contractor shall implement required emergency changes within five business days of notification, unless otherwise directed by the COR. The Contractor shall:

· Acknowledge receipt of emergency change requests within four business hours;

· Provide daily status updates to the COR during implementation;

· Conduct expedited testing protocols while maintaining data integrity and security standards;

· Document all emergency changes and provide post-implementation reports within 10 business days.

2.2.4.3 Material Changes

Material changes to program services are programmatic, statutory, policy, operational, or oversight changes determined by ORR to have a meaningful impact on system functionality, data requirements, reporting obligations, integration needs, user access, or performance expectations. Such changes may require updates to:

· Data elements or data transmission formats;

· API specifications or integration mechanisms;

· Reporting structures;

· User roles or permissions;

· Workflow configurations;

· Compliance or audit functionality.

Examples of material changes include, but are not limited to:

· Implementation of new federal reporting requirements affecting multiple data domains;

· Addition of new program services or beneficiary populations;

· Changes to interagency data sharing agreements requiring new security protocols;

· Modifications to case management workflows affecting multiple user groups;

· Integration with new federal systems or data exchanges.

Upon notification by the COR of a material change, the Contractor shall submit a detailed implementation plan within 15 business days of notification. The plan shall be approved by the COR prior to implementation. Implementation shall occur within 30 to 90 calendar days based on the scope and complexity of the change, as determined by the COR. The implementation plan shall include, at a minimum:

· Technical approach and architecture diagrams;

· Detailed timeline with milestones and dependencies;

· Risk assessment and mitigation strategies;

· Testing and validation approach;

· Data migration or transition plans (if applicable);

· Impact analysis on existing system functionality;

· Resource allocation and staffing plan;

· Rollback procedures;

· Training requirements for ORR staff or end users.

The Contractor shall ensure its system remains adaptable to material changes and shall implement necessary material changes as directed by the COR.

2.2.4.4 System Use and Data Integrity Requirements

· The Contractor shall ensure all Contractor personnel working on this contract are trained on use of the Contractor's system, including, but not limited to, data entry into the platform.

· The Contractor shall ensure the timeliness, completeness, and accuracy of third-party data entry practices.

2.2.4.5 Data Categories, Metrics, Analysis, and Reporting Requirements The Contractor shall collect, analyze, and report quantitative and qualitative data on services performed ("program data") in fulfillment of this contract as follows, and deliver such data per the timeline and in the format shown in Section 4.0 and Attachment 7 (Deliverables Schedule and Performance Requirements Summary).

2.2.4.5.1 Application and Platform Metrics

The Contractor shall report to ORR the following individual analysis related to delivery of HS/PRS applications and OPTM platform services:

· Sprint velocity and completed story point delivery per sprint and per PI;

· Backlog items delivered, in progress, and remaining, by task area;

· Application uptime, latency, and error rates by service;

· API request volumes, response times, and error rates;

· Tier 3 support ticket volumes, categorization, time-to-resolution, and root-cause analysis;

· User onboarding, training completion, and access provisioning metrics;

· Deployment frequency, change failure rate, and mean time to recovery (DORA metrics);

· Security scan results, vulnerability remediation status, and Plan of Action and Milestones (POA&M) status.

2.2.4.5.2 General Analysis

On a monthly basis, the Contractor shall report to ORR the following general analysis:

· Number and summary of concerns received during the previous month regarding Contractor services and analysis of Contractor response and resolution;

· Quantitative and qualitative measurement of satisfaction of the following individuals and officials, as determined by the Contractor's surveys, interviews, and other methodologies for obtaining quantitative and qualitative data to assess program services:

· Provider grantee end users;

· Federal Field Specialists (FFS);

· Other integrated product/contract teams;

· ORR headquarters staff;

· Qualitative Data Development Requirements: the Contractor shall employ surveys, interviews, and other methodologies to produce qualitative data necessary to assess program services.

2.2.4.5.3 Trend Analysis and Evidence-Based Recommendations

The Contractor shall perform ongoing quantitative and qualitative analysis to develop recommendations to ORR regarding:

· Improvements to service delivery and user experience;

· Efficiency of funding allocation and cost reductions;

· Effectiveness of platform and application services;

· Technical debt reduction and modernization opportunities;

· Goal of achieving outcomes in the best interest of UAC served under this contract.

2.2.4.6 Ad Hoc Reporting Requirements

At the Government's request, the Contractor shall provide stand-alone reports focused on key areas of interest, or that present statistics best measured on a less frequent cadence than regular reports, or that are responsive to ad hoc requests. The COR will specify the technical parameters for the response to a particular ad hoc request.

2.2.5 Task 5: Transition-Out

The Contractor shall develop and maintain transition-out planning throughout the period of performance to support an orderly transition of services to a successor contractor or the Government, as directed by the CO.

Transition-out is the planned process for the outgoing Contractor to transfer all operational responsibilities, data, and knowledge to the incoming contractor and/or the Government, ensuring continuity of services and compliance with PWS requirements. The Contractor shall complete this process starting 90 calendar days prior to the end of the contract (or as directed by the CO or COR) without service disruption. If necessary, in accordance with FAR clause 52.237-3, Continuity of Services, the Government reserves the right to require additional transition services for up to 90 days after this contract expires.

· The Contractor shall perform the Transition-Out task per the requirements of this section. The Contractor shall develop and execute a Transition-Out Plan as a component of the Contractor's Project Management Plan, per Section 2.3.2.1 of this PWS. The Contractor must work cooperatively with the incoming contractor/service provider and the Government to provide a seamless transition of services specified in the PWS. The Contractor shall work collaboratively with government personnel identified by the CO and/or COR to ensure a seamless transition of the activities included in this contract to the incoming service provider/government personnel. Transition-out shall include transfer of all documentation, system components, source code, and other items relating to the development, deployment, and operations of the solutions, APIs, and deliverables.

· During Transition-Out, the Contractor shall provide the transition-out and project status to the COR weekly or as otherwise directed by the COR. The Project Status shall include:

· Any updates to the Transition-Out Plan;

· Timeline and milestones to transition services to the incoming provider or the Government;

· Status of transitioning out PWS tasks and services;

· Staffing: detailed by-position (and name, as necessary) staffing on hand and turnover;

· Known and potential risks to maintaining continuity of services through the end of the contract and to transitioning all services to the follow-on provider or Government, and the Contractor's plan to mitigate or eliminate the identified and anticipated risks;

· Other issues and challenges;

· Assistance required from the Government.

See PWS Section 4.0 and Attachment 7, Deliverables Schedule and Performance Requirements Summary.

2.3 Other Requirements

2.3.1 Meetings

2.3.1.1 General Requirements

· The Contractor shall attend, participate, and provide input and agenda information for scheduled and unscheduled meetings, conferences, and briefings that relate to the functions and services herein, as required by the CO or COR to provide effective communication and impart necessary information.

· Meeting Participation.

· The Contractor's designated Project Director (PD) or equivalent level representative shall attend meetings at the request of the CO or COR.

· Contractor managerial, supervisory, and other personnel knowledgeable of the subject matter shall attend meetings as necessary as determined by the CO or COR.

· Meetings will generally be via Zoom, Microsoft (MS) Teams, or similar video teleconference technology approved by the COR. In-person meetings may be required at the COR's discretion. The Contractor shall prepare meeting agendas as directed by the COR. Unless otherwise directed by the COR, the Contractor shall submit the meeting agenda to the COR not less than three business days prior to the scheduled meeting. When meeting with ORR personnel, the Contractor shall prepare meeting minutes in writing and submit those minutes to the COR within two business days after the meeting for review and contract documentation. The Contractor shall revise meeting minutes if the COR identifies information that should/should not be included or at the request of the COR for any other reason.

· See delivery requirements in Section 4.0 and Attachment 7.

2.3.1.2 Contract Status Meetings

· The Contractor shall prepare for and participate in monthly (unless directed otherwise by the COR) conference calls or video teleconferences to discuss:

· Estimated capacity for delivery of services;

· Capacity changes;

· Operational or service delivery challenges; and

· Other business items identified by the Contractor or COR, as agreed upon in advance.

· See delivery requirements in Section 4.0 and Attachment 7.

2.3.1.3 Contract Performance Review Meetings

· The Contractor shall prepare for and participate in performance review meetings to be scheduled every other month unless directed otherwise by the COR. To support these meetings:

· The Contractor shall provide an overall project performance assessment to include performance issues and challenges. The Contractor shall complete a performance assessment on a template and in the format as directed by the COR and shall provide it to the Government no less than two business days prior to the performance review meeting.

· The Contractor shall take the actions necessary to resolve outstanding issues identified during the Contract Performance Review within 10 business days after identification of the issue.

· See delivery requirements in Section 4.0 and Attachment 7.

2.3.1.4 Kick-Off Meeting (Base Period Only)

· Within 10 business days of contract award, or as directed by the COR, the Contractor shall schedule a kick-off meeting, which will consist of the following:

· Introduction of both key contractor and government personnel performing work related to this contract;

· Brief overview of contract administration and reporting;

· Discussion of substantive risks and issues that may impact delivery of the project;

· The specific activities and deliverables associated with the period of performance specified in the contract;

· Review by the Contractor of its understanding of the work to be accomplished under this contract, to ensure that the Contractor understands the requirements and the respective responsibilities and obligations of the parties;

· Review by both the Government and the Contractor of the required methods to resolve, track, and report on risks and issues;

· Details of the Transition-In Plan.

· See delivery requirements in Section 4.0 and Attachment 7.

2.3.1.5 Sprint Ceremonies and Program Increment Planning

In addition to the general meeting requirements above, and given the agile delivery model required under this contract, the Contractor shall participate in the following recurring agile ceremonies. Each sprint will be two weeks long to keep delivery cycles short:

· Team stand-ups: daily

· Backlog Refinement: weekly

· Sprint Planning: bi-weekly

· Mid-Sprint Check-Ins: bi-weekly

· Sprint Review/Demo: bi-weekly

· Quarterly demo to leadership

· Scrum of Scrums: weekly

· Program Increment (PI) Planning: multi-day PI planning event, every 12 weeks Each Program Increment will be 12 weeks long (six sprints per PI). Every 12 weeks, all teams contributing to the service-oriented platform will gather to map out potential dependencies and blockers and set objectives and key results for the subsequent PI.

The Contractor shall be required to work closely with other product and contract teams to ensure all functionality delivered provides a consistent user experience across ORRbit products.

2.3.1.6 Tooling

The Contractor shall default to using ACF enterprise tools where possible, including Jira Cloud, Confluence, Slack, and Microsoft products. As requested by the Government, the Contractor will upload information into ACF-furnished tools such as SharePoint or Box. Slack will be the primary communication method between the technology team and the Contractor team.

All applications shall be hosted and developed in ACF AWS cloud environments. All deliverables and materials developed under this contract are the property of the U.S. Government and shall be stored on U.S. Government-owned systems in accordance with Section H.3 (Records Management) and Section H.4 (Information Security Requirements).

2.3.2 Other Required Plans

2.3.2.1 Project Management Plan (PMP) Minimum Requirements

· The Contractor shall provide an updated Contractor PMP to the COR within five business days after the kick-off meeting to fully document its management approach for the recruitment, delivery, and execution of contracted services. See delivery requirements in Section 4.0 and Attachment 7.

· If the PMP is returned with comment or rejected in part or in whole by the COR, the Contractor shall then have seven business days to submit a revision that fully addresses the comments/reasons for rejection.

· The Contractor shall update the PMP or its individual component plans and submit them to the COR as necessary and appropriate during contract performance as described in this PWS section. The Contractor shall also update the PMP and submit it to the COR at least 90 calendar days prior to the commencement of the next period of performance, or as otherwise directed by the COR.

· PMP Components. The PMP shall consist of a Transition-In Plan, Transition-Out Plan (post-award only), Contract Management Plan, Quality Management Plan, and Communication Plan.

2.3.2.1.1 Transition-In Plan Minimum Requirements

The Transition-In Plan shall, at a minimum, describe the Contractor's plan to meet the requirements set forth in Section 2.2, Specific Requirements, including Section 2.2.1, Task 1: Transition-In, and how the Contractor will fully staff to meet the required timeline to achieve full performance without degradation of service.

· Transition-In Plan Submission Timelines. The Contractor shall submit an updated Transition-In Plan per the PMP submission schedule. The Contractor shall present an overview of the Transition-In Plan at the Kick-Off meeting.

· The Transition-In Plan shall:

· Describe the transition-in project management processes;

· Provide transition-in timeline and milestones to achieve full operational capability within 30 calendar days of award;

· Include a Responsibility Matrix: a comprehensive listing of the responsibilities of all personnel participating in the transition;

· Include a Risk Management Plan: a plan to identify, assess, mitigate, or manage potential risks during the transition-in period;

· Provide transition-in points of contact;

· Identify how the Contractor will coordinate with government personnel to receive necessary knowledge/information to facilitate and ensure a seamless transition;

· Identify actions required by the Government to facilitate the Contractor's performance during transition-in.

· See delivery requirements in Section 4.0 and Attachment 7.

2.3.2.1.2 Transition-Out Plan Minimum Requirements

The Transition-Out Plan shall, at a minimum, describe the Contractor's plan to meet the requirements set forth in Section 2.2.5, Task 5: Transition-Out, to transition services to a follow-on service provider or the Government with no disruption in services.

Transition-Out Plan Submission Timelines. Because this contract is a bridge to a competitive follow-on procurement, the Contractor shall develop and maintain a Transition-Out Plan throughout the period of performance to ensure the Government is prepared to transition services to a successor contractor at any point after month six of the base period.

The Contractor shall submit the Transition-Out Plan in accordance with the following schedule:

· Draft Transition-Out Plan — no later than 90 calendar days after contract award. The draft plan shall establish the full transition-out framework, including responsibility matrix, service continuity plan, risk management plan, transition timeline and milestones, location and access instructions for all technical and project management documentation, and coordination approach with the incoming contractor and/or Government personnel.

· Interim Updates — the Contractor shall update the Transition-Out Plan and submit it to the COR at least every 90 calendar days during the period of performance, or upon material change to the scope, staffing, technical architecture, or in-flight work, whichever occurs first.

· Pre-Transition Update — no later than 120 calendar days prior to the end of the contract (including any exercised FAR 52.217-8 extension period), the Contractor shall submit a revised Transition-Out Plan that reflects the current state of all work, in-flight sprints and Program Increments, open backlog, technical infrastructure, and support operations.

·…