OFC HCM SaaS PWS_20MAY2025 FINAL.pdf

Performance Work Statement (PWS) for Human Capital Management (HCM) Software-as-a-Service (SaaS)

19 May 2025

Prepared by:

Platform Modernization and Integration Branch (AFLCMC/GBHP)

Air Force Life Cycle Management Center (AFLCMC) Joint Base San Antonio-Randolph, TX 78150

Distribution Statement C: Distribution authorized to U.S. Government agencies and their contractors date 14 February 2025. Other requests for this document must be referred to AFLCMC/GBH, 1st Street West, Bldg. 977, Joint Base San Antonio-Randolph, TX 78150.

Destruction Notice – For unclassified, limited documents, destroy by any method that will prevent disclosure of contents or reconstruction of document.

DISCLAIMER - The contents of this document are not to be construed as an official Department of the USAF position unless so designated by other authorized documents. The use of trade names in this document does not constitute an official endorsement or approval of the use of such commercial hardware or software. Do not cite this document for the purpose of advertisement.

This page intentionally left blank

Table of Contents

1.0. Introduction

2.0. Kick-Off Meeting

3.0. Roles and Responsibilities

4.0. Agile Execution & Sprint Deliverables

5.0. Security & Access Control Guidelines

6.0. Testing Protocols & Data Migration

7.0. Contractor Staffing & Minimum Qualifications

8.0. Contractor Training

9.0. Place of Performance

10.0. Government Furnished Property (GFP)

11.0. Performance Metrics & Enhancement

12.0. Services Summary

13.0. Data Migration & Validation Framework

14.0. Agile Deliverables

15.0 Sprint Deliverables

16.0. Overall Project Deliverables and Schedule

17.0. Contract Data Requirements List (CDRL)

18.0. Data Rights

1.0. Introduction

1.1. Purpose and Scope

This PWS defines performance expectations for Task Order 1 under the HCM SaaS IDIQ. It includes performance and deliverables tied to Contract Line Item Numbers (CLINs) 0001 through 0005. This PWS supports the Department of the Air Force’s (DAF) Human Resources (HR) modernization initiative via an Oracle Fusion Cloud (OFC) Human Capital Management (HCM) Software-as-a-Service (SaaS) solution.

The DAF currently utilizes over one hundred legacy applications, contributing to inefficiencies and rising costs. This project aims to reduce legacy systems, modernize HR processes, enhance user experience, and improve data visibility enterprise-wide using a Commercial-Off-the-Shelf (COTS) SaaS platform.

This effort will follow Scrum methodology, ensuring incremental delivery of prioritized HCM capabilities. Work shall be organized into Sprints (nominally two-week intervals), with each Sprint producing tested software increments aligned to Epics, Minimum Viable Product (MVP) objectives, and Contract Line-Item Number (CLIN) based milestone deliverables.

1.2. Governance & Agile Execution

1.2.1. The Government Product Owner shall approve changes to backlog priorities, ensuring traceability to:

1.2.1.1. Requirements Traceability Verification Matrix (RTVM) items (CDRL A005);

1.2.1.2. Quality Assurance Surveillance Plan (QASP) performance metrics; and

1.2.1.3. Milestone acceptance criteria.

1.2.2. The Contractor shall implement a technical debt management process, tracking, unresolved legacy system inefficiencies and design limitations. Technical debt shall be monitored as part of Sprint Retrospectives, and remediation actions shall be prioritized within the backlog.

1.2.3. Updates shall be captured in the Monthly Status Report (MSR) (CDRL A001).

1.3. Definition of Done for Sprint Deliverables

1.3.1. To ensure consistency and adherence to Agile best practices, the contractor shall implement a formal Definition of Done framework, which serves as the completion criteria for each deliverable. A deliverable is considered “done” when it meets the following requirements:

1.3.1.1. Functional Validation: The feature or system component fulfills all requirements as outlined in the RTVM items (CDRL A005)

1.3.1.2. Testing Completion: The feature passes automated and functional testing, with defects remediated.

1.3.1.3. Security & Compliance: Meets FedRAMP Moderate+, DISA STIG compliance, and all applicable cybersecurity standards.

1.3.1.4. Performance Benchmarks: Adheres to system uptime, user concurrency, and response time metrics.

1.3.1.5. Stakeholder Approval: Product Owner must review and accept functional deliverables.

1.3.1.6. Deployment Readiness: The delivered HCM SaaS solution must be integrated and deployable without defects.

1.4. Agile Ceremonies (Contractually Tracked)

1.4.1. Progress shall be visible through Scrum ceremonies and Agile artifacts, including:

1.4.1.1. Sprint Planning & Backlog Grooming:

1.4.1.1.1. Align Sprint Goals with contract CLINs and RTVM items (CDRL A005).

1.4.1.1.2. Incorporate backlog refinement and prioritization decisions from the Product Owner.

1.4.1.2. Daily Scrum:

1.4.1.2.1. Conducted by Contractor.

1.4.1.2.2. Persistent impediments (unresolved beyond 48 hours) must be tracked in MSRs.

1.4.1.3. Sprint Review:

1.4.1.3.1. Demonstrated software shall be evaluated for functionality, usability, and alignment with expected outcomes. Interface Control Agreements (ICAs) and Interface Control Documents (ICDs) are living documents and shall be reviewed and updated as needed, especially if the sprint involved integration work. Each session will be recorded by the Government.

1.4.1.3.2. Functionality must meet pre-defined acceptance criteria and performance metrics (Sprint Velocity, Story Completion Rate, Definition of Done).

1.4.1.4. Sprint Retrospective:

1.4.1.4.1. Lessons learned, and process improvement actions shall be documented and submitted with the MSR. Each session will be recorded by the Government.

1.4.1.4.2. The Government may evaluate whether recurring impediments are resolved over time, as tracked in the QASP. Retrospective findings will be assessed during Program Management Reviews (CDRL A002).

2.0. Kick-Off Meeting

2.1. The Contractor shall coordinate and co-host an HCM SaaS Kick-Off Meeting virtually, as approved by the Government no later than five (5) business days after contract award. The meeting shall provide an introduction between Contractor and Government personnel, covering management, technical strategy, and security requirements (CDRL A002).

2.2. Kick-off Meeting Agenda

2.2.1. Project Overview & Objectives:

2.2.1.1. Background on HCM modernization goals; and

2.2.1.2. Expected scope of work and contractual milestones.

2.2.2. Technical Approach:

2.2.2.1. Scrum methodology, Agile execution framework;

2.2.2.2. Sprint and backlog prioritization principles; and

2.2.2.3. Integration and interface strategies for legacy systems.

2.2.3. Security & Compliance Requirements:

2.2.3.1. FedRAMP Moderate+, Defense Information Systems Agency (DISA) Security Technical Implementation Guide (STIG) compliance;

2.2.3.2. Authority to Operate (ATO) maintenance requirements; and

2.2.3.3. Access control, audit trail implementation.

2.2.4. Risk Management & Technical Debt Handling:

2.2.4.1. Risk identification process; and

2.2.4.2. Technical debt tracking and remediation procedures.

2.2.5. Contract Administration & Reporting Expectations:

2.2.5.1. Sprint acceptance process (Product Owner approval)

2.2.5.2 Role of the Contracting Officer Representative (COR) in corrective actions

2.2.5.3. Required Contract Data Requirements Lists (CDRLs)

2.3. The meeting will be recorded, and all relevant documentation shall be made available post-kickoff including:

2.3.1. Initial Risk Assessment; and

2.3.2. Integration Plan.

3.0. Roles and Responsibilities

3.1. Government Roles:

3.1.1. Government Product Owner: Prioritizes the backlog and authorizes changes to backlog items, approves Sprint deliverables per the Definition of Done.

3.1.2. Contracting Officer’s Representative (COR): Reviews sprint failures, enforces corrective actions, and tracks contract compliance.

3.1.3. Program Manager (PM): Oversees contract execution, manages cybersecurity, serves as focal point for communication with DAF leadership.

3.1.4. Contracting Officer (CO): Legal authority over contract execution ensures contractor compliance.

3.2. Contractor Roles:

3.2.1. Scrum Master: Facilitates Agile ceremonies, removes impediments, and ensures adherence to Scrum principles.

3.2.2. Development Team: Implements software increments, ensure testing coverage per PWS Section 8.0.

3.3. Key Personnel Identification & Substitute Approval:

3.3.1. The Contractor shall identify key personnel before project start.

3.3.1. Personnel substitutions require written justification and updated resumes submitted to the CO/COR at least 15 calendar days before personnel changes.

4.0. Agile Execution & Sprint Deliverables

4.1. Sprints, User Stories, and Minimum Viable Product (MVP)

4.1.1. The Contractor shall organize Agile delivery into a hierarchy of Epics, User Stories, and time-phased Sprints, with a prioritized focus on delivering a working Minimum Viable Product (MVP) aligned to CLIN-based milestones.

4.1.1.1. Epics: Represent larger business capabilities (e.g., Onboarding, Talent Management, Workforce Analytics) decomposed into related and manageable user stories.

4.1.1.2. User Stories: Discrete, testable requirements developed and demonstrated iteratively during Sprints.

4.1.1.3. Sprints: Time-phased iterations (2 weeks nominally) resulting in tested, deployable software increments mapped to specific backlog items and contract deliverables.

4.1.1.4. Table 1: Sprint Deliverables, Acceptance Criteria, and Referenced CLINs

Sprint Deliverable Acceptance Criteria Referenced CLINs Sprint Goal Completion 100% Completion of Sprint Goal with Acceptance by Product Owner

All Sprint CLINs

Sprint Review Presentation

Demonstration of tested software aligned to backlog priorities

CLIN 0002

Sprint Retrospective Demonstration

Lessons learned and process improvement actions provided to the COR

All Sprint CLINs

4.1.1.5. Sprint Acceptance Criteria: The Government Product Owner approves sprint deliverables and ensures:

4.1.1.5.1. Sprint Goals are met;

4.1.1.5.2. Functionality meets the Definition of Done; and

4.1.1.5.3. Zero critical defects remain open.

4.1.2. Capability-Based Outcomes and User Stories: User stories define, develop, and validate contract deliverables following the format: “As a [user type], I want [capability] so that [benefit].”

4.1.2.1. Example Epic: Employee Onboarding:

4.1.2.1.1. “As a new employee, I want to complete my onboarding process electronically so that I can quickly access necessary systems and information.”

4.1.2.1.2. “As an HR specialist, I want to automate the onboarding process so that I can reduce manual data entry and improve efficiency.”

4.1.2.2. Epic: Performance Management:

4.1.2.2.1. “As a manager, I want to view employee performance dashboards so I can provide timely feedback.”

4.1.2.2.1. “As an employee, I want digital access to my performance reviews so I can track my development goals.”

4.1.2.3. User stories must:

4.1.2.3.1. Be traceable to CLIN/SLIN deliverables and/or milestone events.

4.1.2.3.2. Meet acceptance criteria approved by the Product Owner.

4.1.2.3.3. Be documented in the RTVM (CDRL A005) and linked to functional demonstrations during Sprint Reviews.

4.1.2.4. Security and Compliance User Stories: To ensure adherence to FedRAMP Moderate+, DISA STIG, and DOD RMF requirements, user stories shall incorporate:

4.1.2.4.1. Access Control: >”As an administrator, I want role-based access controls enforced across the HCM system so that only authorized users can perform HR operations.”

4.1.2.4.2. Audit Trails: > “As a compliance officer, I want system audit logs capturing all user actions so that security incidents can be reviewed and traced.”

4.1.2.4.3. FedRAMP Compliance: >”As a cybersecurity lead, I want all software updates to undergo security scans per FedRAMP requirements so that vulnerabilities are mitigated before production release.”

4.1.3. Minimum Viable Product (MVP) Exit Criteria: The MVP shall include:

4.1.3.1. Secure authentication (SSO, Role-Based Access).

4.1.3.2. Configured core HCM modules (Core HR, Talent Management).

4.1.3.3. At least one bi-directional integration and interface with the legacy HR system (MilPDS).

4.1.3.4. Working dashboards and reports.

4.1.3.5. Successful migration of 100% of personnel data with zero critical errors.

4.1.3.6. Comprise the foundational capabilities required for initial production deployment to include training (CDRL A004).

4.1.4. Final MVP Approval & Verification:

4.1.4.1. All MVP user stories marked “Done” per RTVM (CDRL A005);

4.1.4.2. No Critical or High-severity defects remain open; and

4.1.4.3. 100% unit/integration and interface test pass rate has been achieved.

5.0. Security & Access Control Guidelines

5.1. Clearance Requirements

5.1.1. All personnel must have a favorably adjudicated National Agency Check (NACI) or Tier 1 investigation at a minimum.

5.1.2. Privileged access users (developers, architects) must hold Security+ Certifications and Informatica BI training.

5.2. CAC Issuance & Control

5.2.1. The Contractor shall manage all CAC issuance and retrieval processes.

5.2.2. Any lost or compromised CACs must be reported within 24 hours to the CO and

COR.

5.3. Remote Security

5.3.1. Personnel must access systems only via authorized VPNs; no local storage of PII/CUI is allowed.

5.3.2. Immediate revocation of access for security violations.

6.0. Testing Protocols & Data Migration

6.1. Integration, Interface, & Security Testing: The Contractor shall define protocols for:

6.1.1. API Functionality Test for bidirectional data exchange integrity;

6.1.2. Load and Performance Testing ensuring scalability under production workloads; and

6.1.3. Security Testing aligning FedRAMP, DISA STIG, and RMF vulnerability mitigation.

6.2. Data Migration Validation Framework: The Contractor shall validate migration via:

6.2.1. Automated data validation scripts ensuring zero critical errors; and

6.2.2. Government review of validation results before production acceptance.

7.0. Contractor Staffing & Minimum Qualifications

7.1. This Task Order requires fully qualified personnel meeting the specified baseline certifications, clearance levels, and skillsets detailed below. This table lists minimum qualifications, for example Labor Categories and is not exhaustive; the Contractor may propose additional or tiered labor categories (e.g., Software Engineer I, II, Sr.) as needed. While individual personnel may not possess all listed qualifications within a category, the proposed team’s collective qualifications must satisfy all requirements to fulfill deliverables and tasks. The Contractor may propose blended labor categories to achieve this. A staffing matrix, updated quarterly, must be submitted at kickoff and all key personnel resumes maintained in the contract file. All key personnel are subject to Government approval, and any substitutions or backfills require written justification and updated resumes submitted to the Contracting Officer (CO) and Contracting Officer’s Representative (COR) at least 15 calendar days prior to the change.

7.2. Table 2: Labor Categories, Required Certifications, Clearances, and Key Roles

Labor Category Required Certifications Clearance Key Role?

Project Manager PMP, Agile, Scrum Master SSBI Yes Oracle Cloud Architect Oracle Certified Cloud Architect (CCA) Secret Yes Software Engineer Security+ Secret Yes Scrum Master Agile, PMP SSBI Yes Business Analyst Agile SSBI Yes Senior Developer Oracle Cloud Engineer, Security+ Secret Yes Data Interchange Analyst Integration platform-specific cert Secret Yes Cloud Integration Engineer Oracle Cloud Engineer, Security+ Secret Yes

8.0. Contractor Training

8.1. The Contractor shall ensure all personnel assigned to this Task Order are trained and qualified to perform their respective duties upon start of performance. All baseline training shall be completed before access to Government systems or environments is granted.

8.2. Contractor Staff Training: The Contractor is fully responsible for funding, tracking, and documenting training related to: Oracle Fusion Cloud configuration and support, Agile methods and tools (e.g., JIRA, Confluence), Software development, DevSecOps, and integration best practices. Training must occur prior to assignment to any Agile role (e.g., Developer, Architect, Business Analyst). Any training required by the Government for specific tools or environments will be coordinated and approved in writing by the COR.

8.3. Information Assurance (IA)/Cybersecurity Training:

8.3.1. All Contractor personnel accessing Government systems shall:

8.3.1.1 Complete the current DoD Cyber Awareness Challenge training before system access is granted; and

8.3.1.2. Re-certify annually.

8.3.2. The Contractor shall maintain a master training log and provide quarterly updates to the COR. Individuals who fail to complete required IA training will be denied CAC issuance or GovNet access.

9.0. Place of Performance

9.1. The work performed under this contract will primarily be performed at the Contractor’s designated facilities. Any work performed at Government facilities will require prior approval from the Contracting Officer and will adhere to all applicable security regulations.

10.0. Government Furnished Property (GFP)

10.1. The Government may provide GFP, such as system credential or access to development tools, as specified in individual TOs. The Contractor shall be responsible for the proper use, maintenance, and security of all GFP.

10.2. The Contractor acknowledges that all data within the HCM SaaS system is the property of the Government. The Contractor shall implement appropriate measures to safeguard, maintain, and facilitate Government access to the data, ensuring compliance with relevant data rights provisions and security requirements.

10.3. The Government will not be liable for schedule delays resulting from Contractor failure to request or manage GFE access in accordance with onboarding procedures.

11.0. Performance Metrics & Enhancement

11.1. Key Performance Indicators (KPIs) & Tracking: Performance metrics will be captured through JIRA, Confluence, survey platforms, and security testing suites and reported in:

11.1.1. Monthly Status Reports (MSRs);

11.1.2. Program Management Reviews (PMRs); and

11.1.3. Sprint Reviews.

12.0. Services Summary

12.1. Failure to meet performance thresholds may result in Government issuance of cure notice, withheld milestone payments, or Sprint deliverable rejection or CLIN acceptance delays.

12.2. Table 3: Services Summary

Metric Definition Target Thresh old

Acceptance Criteria

Consequences for Falling Below

Threshold CLIN Link

Sprint Goal Deliver tested, working functionality aligned to Sprint Goal

100% of Sprint Goal Met

90% The Product Owner accepts Sprint deliverable as meeting the Definition of Done, signifying that the Sprint Goal has been achieved. Any unmet goals are documented with corrective actions.

The Contractor shall develop and implement a corrective action plan within 24 hours of missing the threshold. Failure to achieve the target for two consecutive sprints may result in a 5% withholding of the sprint payment and sprint reassessment.

All Sprint CLINs

Sprint Velocity

Number of story points per Sprint

Stable trend line within +/- 15%

Deviati on > +/- 25% from baseline over 2+ Sprints

Story points tracked in JIRA and MSR;

deviation beyond +/- 25% triggers PMR review and adjustment plans

Is deviation exceeds +/-25% the Contractor must submit a variance report within 48 hours detailing corrective actions (e.g., resource

All Sprint CLINs adjustments, scope revisions. Persistent instability over two consecutive sprints may result in a 5% withholding of the sprint payment.

User Story Completion Rate

% of committed user stories completed “done” by Sprint end

100% <90% for two consecu tive Sprints

Stories marked “Done” in backlog, traceable to backlog priority.

Unfinished stories are reviewed for reprioritization in subsequent Sprints.

Mandatory backlog grooming session and adjustment plan submitted within one sprint cycle. If the completion rate remains below 90% after two consecutive sprints, a 5% payment withholding is applied.

All Sprint CLINs

Defect Rate Defects identified post-acceptance by severity

Critical/High ; <2 Medium; <3 Low per Sprint

>2 Critical/ High or >5 Mediu m per

MVP/P

roducti on delivera ble

Post-deployment defects logged in Jira; resolved or dispositioned within 5 business days. Defect trends are analyzed for systemic improvements.

Critical defects must be resolved within 48 hours. High severity issues trigger escalation and a dedicated sprint.

Failure to meet remediation deadlines for two sprints may lead to scope reduction and a 5% withholding of the sprint payment.

MVP &

Production CLINs

User Satisfaction

Avg, score from user feedback post-deployment

>85% satisfaction

<75% avg.

score on surveys or feedbac k sessions

User adoption and Product Owner acceptance. Low scores trigger targeted improvement actions and training enhancements.

A user engagement improvement strategy must be submitted within five business days.

Repeated failures mandate targeted training and adoption workshops.

Training & Deployment CLINs

Retrospective Follow-through

% of improvement actions completed within 2 Sprints

>80% <50% for two consecu tive cycles

Improvement actions are tracked in backlog, with ownership assigned to ensure execution.

The Contractor shall submit a corrective action plan within 24 hours of missing the threshold, ensuring improvement actions are fully implemented.

All Sprint

Continued failure after two cycles may result in performance review and withholding of milestone payments.

Regression Test Pass Rate

% of tests passed without breaking previous functionality

100% <95% pass rate at any milesto ne release

All testing is documented, defects prioritized in backlog and fully tested before production deployment.

Failures trigger immediate remediation plans.

If testing failures exceed the threshold, the Contractor must provide a testing failure mitigation strategy within 48 hours. Persistent failures require additional regression cycles before deployment approval.

MVP &

Production CLINs

Production Ready Solution

Deliver a production-ready OFC HCM SaaS solution that meets all

PMO

requirements and achieves a successful

ATO.

100% compliance with all requirements

100% *Successful deployment of the OFC HCM SaaS solution to the production environment, passing all user acceptance tests.

Any ATO concerns are addressed before full implementation.

If production readiness fails, deployment is halted.

ATO rejection results in funding freeze until compliance is achieved.

Production CLINs

SCCA

Compliance

Implement SCCA per DoD & DAF policies

Compliance Non-complia nce with security policy

ATO package submitted by 6 months prior to need date, approval before Production

CLIN 0002.

Any non-compliance results in an immediate halt of deployment until remediation.

Prolonged failure beyond two sprints cycles may trigger contract renegotiation.

MVP &

Production CLINs

Configuration Management

Maintain security-related configuration management

Fully documented plan

Missing process docume ntation

Verified via audit. If documentation is missing, compliance audit is triggered.

Persistent failures beyond two sprints impact contract performance ratings.

All CLINs

STIG &

Security Hardening

Conduct

STIG

analysis and implement

100% of applicable STIGs, SRGs, >5 unresol ved findings

STIG Matrix approved by Sprint

Security non-compliance triggers escalation to security leadership.

MVP &

Production security measures

IAVAs implemented at MVP accepta nce

Continued failures results in funding delays and corrective remediation requirements.

Secure Development & Testing

Apply secure software development/ testing

Integrated security testing

Any critical vulnera bilities unresol ved before Sprint 4

100% of artifacts scanned, vulnerabilities remediated before Sprint 4.

If security vulnerabilities persist, development pauses until resolution.

Unresolved issues beyond two sprint cycles impact payment schedule.

ALL CLINs

Incident Response & Documentatio n

Maintain incident response plan for accreditation

Fully implemented plan

Missing docume ntation or outdate d artifacts

Approved Incident Response Plan by Sprint 3

Lack of updated response documentation triggers compliance audit. Extended failures risk ATO revocation.

ALL CLINs

Cybersecurity Personnel Qualifications

Ensure personnel have required credentials

100% compliance

Missing or outdate d certifica tions

Certification documentation maintained quarterly

Personnel failing qualifications must be replaced or certified within one sprint. Continued issues result in compliance restrictions.

ALL CLINs

Legacy System Interface & Integration

Maintain secure data integrations

Fully operational integrations

Any interfac e failure before product ion accepta nce

Bi-directional synchronization validated pre-MVP.

Integration and interface failures require immediate troubleshooting within the next sprint. Repeated failures impact production acceptance.

ALL CLINs

Data Migration

Migrate personnel data securely

100% migrated with zero critical errors

Migrati on issues causing data loss

Automated validation ensures zero critical errors

Migration errors trigger manual data reconciliation.

Unresolved issues after two cycles impact data integrity ratings.

MVP &

Production CLINs

Mobile Accessibility

Ensure mobile-friendly interface

Fully functional on mobile platforms

Mobile compati bility issues impacti

Mobile testing validation ensures zero critical errors

Mobile failures require immediate usability refinement in next sprint.

ALL CLINs ng usabilit y

Reporting & Analytics

Implement reporting and analytics

Fully delivered reports

Missing or inaccur ate reportin g functio ns

Delivery and validation of all reports

Missing reports must be rectified within five business days.

Persistent failures impact compliance ratings

ALL CLINs

13.0. Data Migration & Validation Framework

13.1. The Contractor shall define and execute a structured data migration plan, ensuring integrity when transitioning personnel records from legacy EBS systems to HCM SaaS.

13.2. Data Validation Framework:

13.2.1. Pre-Migration Data Profiling: Assess existing data quality, completeness, and anomalies before migration.

13.2.2. ETL (Extract, Transform, Load) Integrity Checks: Ensure validation at every ETL phase with predefined data consistency checks.

13.2.3. Post-Migration Verification: Conduct automated validation scripts ensuring:

13.2.3.1. 100% migration of required data;

13.2.3.2. Zero critical errors; and

13.2.3.2. Government reviewer approval.

14.0. Agile Deliverables

14.1. Deliverables under this Task Order shall align to Sprint-based Agile execution and be traceable to CLINs and milestone payments as defined in the CLIN and Sub-CLIN. The Contractor shall submit all deliverables in accordance with the schedule below. Acceptance is contingent on meeting performance metrics, documented Definition of Done, and Government validation under the Quality Assurance Surveillance Plan (QASP). Failure to meet AQLs may trigger Corrective Action Plans (CAP) and delay payment authorization.

14.2. CLIN 0001 – Agile Kickoff & Planning: This CLIN covers the initial phase of the project, including the kick-off meeting and planning activities necessary to set the foundation for successful execution. The deliverables under this CLIN will ensure that all stakeholders are aligned, and the project is set up for effective management and execution.

14.2.1. SLIN 0001AA – Initial Deployment Plan: The Initial Deployment Plan outlines the strategy for deploying the Oracle HCM SaaS solution. It includes timelines, resource allocation, risk management strategies, and key milestones. Acceptance Criteria include:

14.2.1.1. Completeness: The plan must cover all aspects of deployment, including timelines, resource allocation, risk management, and key milestones;

14.2.1.2. Feasibility: The plan must be realistic and achievable within the given constraints;

14.2.1.3. Stakeholder Approval: The plan must be reviewed and approved by all relevant stakeholders; and

14.2.1.4. Alignment with Project Goals: The plan must align with the overall project objectives and goals.

14.2.2. SLIN 0001AB – Project Management Plan (PMP): The PMP details the approach for managing the project, including methodologies, tools, roles and responsibilities, communication strategies, and performance metrics. Acceptance Criteria include:

14.2.2.1. Detailed Methodologies: The plan must include detailed descriptions of the project management methodologies to be used;

14.2.2.2. Roles and Responsibilities: Clearly defined roles and responsibilities for all team members.

14.2.2.3. Communication Strategy: A comprehensive communication strategy that ensures effective information flow among stakeholders.

14.2.2.4. Performance Metrics: Defined performance metrics to measure project progress and success.

14.2.3. SLIN 0001AC – Requirements Traceability Verification Matrix (RVTM): The RTVM is a document that maps and tracks the requirements throughout the project lifecycle. It ensures that all requirements are met and provides a clear linkage between requirement, design, development, and testing. Reference CDRL A005 for Acceptance Criteria.

14.2.4. SLIN 0001AD – Draft Systems Architecture: The Draft Systems Architecture provides an initial overview of the system’s structure, including components, interfaces, and data flow. It serves as a blueprint for the development and integration of the Oracle HCM SaaS solution. Acceptance Criteria include:

14.2.4.1. Clarity and Detail: The architecture must be clearly defined and detailed, covering all major components and interfaces.

14.2.4.2. Feasibility: The architecture must be feasible and align with the project’s technical requirements and constraints.

14.2.4.3. Stakeholder Approval: The draft must be reviewed and approved by all relevant stakeholders.

14.2.4.4. Alignment with Requirements: The architecture must align with the project’s requirements and objectives.

14.3. CLIN 0002 – Minimum Viable Product (MVP) Development: This CLIN covers the development of the MVP for the OFC HCM SaaS solution. It includes core configurations, initial integrations, and the provisions of draft training documents. The deliverables under this CLIN will ensure that the MVP meets the necessary requirements and is ready for demonstration and deployment. Acceptance Criteria include:

14.3.1. Draft Training Documents: Comprehensive and clear training materials that cover all aspects of the developed solution;

14.3.2. Refined Deployment Plan: An updated and detailed deployment plan that aligns with the project’s objectives and timelines; and

14.3.3. Accepted MVP Demonstrated to the Government: Successful demonstration of the MVP to the Government Product Owner, meeting all specified requirements and functionalities.

14.3.2. SLIN 0002AA – Draft Training Documents: The Draft Training Documents provide initial training materials for users of the Oracle HCM SaaS solution. These documents should cover key functionalities, user roles, and step-by-step instructions for using the system. Acceptance Criteria include:

14.3.2.1. Comprehensive Coverage: The documents must cover all key functionalities and user roles within the Oracle HCM SaaS solution;

14.3.2.2. Clarity and Usability: The documents must be clear, easy to understand, and usable by the intended audience.

14.3.2.3. Stakeholder Approval: The documents must be reviewed and approved by relevant stakeholders.

14.3.3. SLIN 0002AB – Deployment Plan: The Deployment Plan outlines the refined strategy for deploying the Oracle HCM SaaS solution. It includes detailed timelines, resource allocation, risk management strategies, and key milestones. Acceptance Criteria include:

14.3.3.1. Detailed and Updated: The plan must be detailed and reflect any updates or changes since the initial deployment plan;

14.3.3.2. Feasibility: The plan must be realistic and achievable within the given constraints.

14.3.3.3. Stakeholder Approval: The plan must be reviewed and approved by all relevant stakeholders.

14.3.4. SLIN 0002AC – Accepted MVP Demo by Government Product Owner: This SLIN involves the demonstration of the MVP to Government Product Owner. The MVP should showcase core functionalities and integrations of the Oracle HCM SaaS solution.

Acceptance Criteria include:

14.3.4.1. Functionality: The MVP must demonstrate all specified core functionalities and integrations;

14.3.4.2. Performance: The MVP must perform reliably and meet the performance criteria outlined in the project requirements

14.3.4.3. Approval: The MVP must be reviewed and accepted by the Government Product Owner.

14.3.5. SLIN 0002AD – Initial Integrations Complete: This SLIN covers the completion of initial integrations required for the Oracle HCM SaaS solution. These integrations should ensure seamless interactions between the HCM system and other relevant systems.

Acceptance Criteria include:

14.3.5.1. Integration Completeness: All specified integrations must be completed and functioning as intended;

14.3.5.2. Testing and Validation: The integrations must be thoroughly tested and validated to ensure they meet the project requirements; and

14.3.5.3. Stakeholder Approval: The integration must be reviewed and approved by relevant stakeholders.

14.4. CLIN 0003 – Core Capabilities Delivery: This CLIN covers the delivery of expanded HCM modules, implementation of test automation, and preparation for User Acceptance Testing (UAT). The deliverables under this CLIN will ensure that the core capabilities of the Oracle HCM SaaS solution are effectively implemented and ready for user validation. Acceptance

Criteria include:

14.4.1. Training Materials: Comprehensive training materials delivered to the Government Product Owner;

14.4.2. Delivery of Core Capabilities: Successful implementation and delivery of expanded HCM modules;

14.4.3. Test Automation: Implementation of automated testing processes; and

14.4.4. UAT Preparation: Completion of all necessary preparations for User Acceptance Testing.

14.4.5. SLIN 0003AA – Training Materials Delivered to Government POC: This SLIN involves the delivery of training materials that cover all aspects of the Oracle HCM SaaS solution. These materials should be comprehensive and user-friendly, providing clear instructions and guidance for end-users. Acceptance Criteria include:

14.4.5.1. Comprehensive Coverage: The training materials must cover all key functionalities and user roles within the Oracle HCM SaaS solution;

14.4.5.2. Clarity and Usability: The materials must be clear, easy to understand, and usable by the intended audience; and

14.4.5.3. Stakeholder Approval: The materials must be reviewed and approved by the Government Product Owner.

14.4.6. SLIN 0003AB – Delivery of Core Capabilities in HCM: This SLIN covers the delivery of core configurations within Core HR and Talent Management Modules as retailed in the RTVM. Acceptance Criteria include:

14.4.6.1. Functionality: The expanded HCM modules must include all specified functionalities and meet the project requirements;

14.4.6.2. Performance: The modules must perform reliably and efficiently; and

14.4.6.3. Stakeholder Approval: The modules must be reviewed and accepted by relevant stakeholders.

14.4.7. SLIN 000AC – Test Automation: This SLIN involves the implementation of automated testing processes to ensure the reliability and performance of the OFC HCM SaaS solution. Test automation should cover key functionalities and integrations.

Acceptance Criteria include:

14.4.7.1. Coverage: The automated tests must cover all critical functionalities and integrations;

14.4.7.2. Reliability: The tests must reliably identify issues and validate performance; and

14.4.7.3. Stakeholder Approval: The automated testing processes must be reviewed and approved by relevant stakeholders.

14.4.8. SLIN 000AD – User Acceptance Testing (UAT Preparation): This SLIN covers the preparation for UAT, including the setup of test environments, creation of test cases, and coordination with end-users. UAT preparation ensures that the system is ready for validation by end-users. Acceptance Criteria include:

14.4.8.1. Test Environment Setup: The test environments must be fully set up and configured for UAT;

14.4.8.2. Test Cases: Comprehensive test cases must be created to cover all key functionalities and scenarios;

14.4.8.3. Coordination: Effective coordination with end-users to ensure their participation in UAT; and

14.4.8.4. Stakeholder Approval: The UAT preparation must be reviewed and approved by relevant stakeholders.

14.5 CLIN 0004 – Production Readiness and Final Delivery: This CLIN covers the final phase of the project, ensuring that the OFC HCM SaaS solution is ready for deployment. It includes full UAT, configuration of dashboards and reports, and preparation for operational support. The deliverables under this CLIN will ensure that the system meets all performance, security, and functionality requirements and is ready for transition to production. Acceptance Criteria include:

14.5.1. System Availability: Achieves 99.9% uptime;

14.5.2. Performance: Key processes meet response and throughput targets;

14.5.3. Security: Passes all security measures;

14.5.4. Functionality:

14.5.4.1. Requirements: 100% of critical requirements met;

14.5.4.2. UAT: Successful completion and sign-off;

14.5.4.3. Workflows: Configured and functioning; and

14.5.4.4. Reporting: All required reports are operational.

14.5.5. Operations:

14.5.5.1. Support: Support team trained and ready;

14.5.5.2. Documentation: Complete system documentation;

14.5.5.3. Training: End-user training complete;

14.5.5.4. Cutover: Tested cutover plan; and

14.5.5.5. Disaster Recovery Plan: Tested disaster recovery plan.

14.5.6. Contractual:

14.5.6.1. Deliverables: All deliverables accepted; and

14.5.6.2. Sign-off: Formal project sign-off.

14.5.7. Transition:

14.5.7.1. Knowledge: Knowledge transfer complete; and

14.5.7.2. Support: System transitioned to support.

14.5.8. Closure:

14.5.8.1. Documentation: Project documentation complete;

14.5.8.2. Report: Final project report delivered; and

14.5.8.3. Financials: Project financially closed.

14.5.9. SLIN 0004AA - Interface Control Agreements (ICAs) and Interface Control Documents (ICDs) Finalized: This SLIN involves the finalization of ICAs and ICDs. These documents define the interfaces between the OFC HCM SaaS solution and other systems, ensuring seamless integration. Acceptance Criteria include:

14.5.9.1. Completeness: All ICAs and ICDs must be complete and cover all necessary interfaces;

14.5.9.2. Accuracy: The documents must accurately reflect the interfaces and integration points; and

14.5.9.3. Stakeholder Approval: The ICAs and ICDs must be reviewed and approved by relevant stakeholders.

14.5.10. SLIN 0004AB – Full UAT Complete and Test Reports Turned into the Government: This SLIN covers the completion of full UAT and the submission of test reports to the Government. UAT ensures that the system meets all business requirements and is ready for deployment. Acceptance Criteria include:

14.5.10.1. Completion: All UAT activities must be completed.

14.5.10.2. Test Reports: Comprehensive test reports must be submitted to the Government.

14.5.10.3. Approval: The test reports must be reviewed and approved by the Government.

14.5.11. SLIN 0004AC - UAT Passed: This SLIN involves the successful passing of UAT.

The system must demonstrate that it meets specified requirements and is ready for production. Acceptance Criteria include:

14.5.11.1. Validation: The system must pass all UAT test cases;

14.5.11.2. Sign-Off: Successful completion and sign-off by the Government Product Owner; and

14.5.11.3. Performance: The system must perform reliably in real-world scenarios.

14.5.12. SLIN 0004AD – Dashboards and Reports Configured: This SLIN covers the configuration of dashboards and reports within the OFC HCM SaaS solution. These tools provide critical insights and data visualization for effective management and decision-making. Acceptance Criteria include:

14.5.12.1. Configuration: All dashboards and reports must be configured according to the project requirements;

14.5.12.2. Functionality: The dashboards and reports must function correctly and provide accurate data; and

14.5.12.3. Stakeholder Approval: The dashboards and reports must be reviewed and approved by relevant stakeholders.

14.6. CLIN 0005 – Deployment Support and Hypercare: This CLIN covers post-deployment support, training refinement, and feedback monitoring for the OFC HCM SaaS solution. The deliverables under this CLIN will ensure that the system is fully operational, users are adequately trained, and feedback is continuously monitored to address any issues promptly. Deliverables should include support logs and user feedback reports. Acceptance criteria include:

14.6.1. P1 Incident Rate (Bugs): Less than 2 incidents per week;

14.6.2. P1 Resolution Time: 95% of P1 incidents resolved within 24 hours;

14.6.3. System Uptime: Greater than 99% availability;

14.6.4. Concurrent User Capability: System supports up to 7,500 concurrently;

14.6.5. Key Process Usage: Greater than 80% of users utilize the new system for key processes;

14.6.6. User Satisfaction Score: 5 on a scale of 1-5;

14.6.7. Critical Data Accuracy: 99.9%;

14.6.8. Data Integrity Checks: 100% of data integrity checks passed; and

14.6.9. Data Reconciliation Completion: 100% of data reconciled and validated.

14.6.10. SLIN 0005AA – Finalized System Architecture: This SLIN involves the finalization of the system architecture for the OFC HCM SaaS solution. The architecture must be comprehensive and detailed, covering all components, interfaces, and data flows.

Acceptance criteria include:

14.6.10.1. Completeness: The architecture must cover all necessary components, interfaces, integrations, and data flows;

14.6.10.2. Accuracy: The architecture must accurately reflect the system’s design and functionality; and

14.6.10.3. Stakeholder Approval: The finalized architecture must be reviewed and approved by relevant stakeholders.

14.6.11. SLIN 0005AB – Final Training Materials: This SLIN covers the delivery of final training materials for end-users of the OFC HCM SaaS solution. Materials should enhance user proficiency in system functionalities and key processes. Acceptance criteria include:

14.6.11.1. User-Focused Refinement: Training materials must be updated based on feedback from end-users;

14.6.11.2. Comprehensive Coverage: The training materials must cover all key functionalities and processes;

14.6.11.3. Clarity and Usability: The materials must be clear, easy to understand, and usable by the intended audience;

14.6.11.4. Stakeholder Approval: The final training materials must be reviewed and approved by relevant stakeholders.

14.6.12. SLIN 0005AC – Hypercare: This SLIN ensures intensive post-deployment support, monitoring, and incident resolution to stabilize the system and provide immediate assistance to end-users. Hypercare support will focus on system performance tracking, incident resolution, and data integrity verification. Acceptance criteria include:

14.6.12.1. Incident Resolution: P1 incidents must be maintained at fewer than 2 per week, with a resolution time of 95% within 24 hours;

14.6.12.2. System Uptime: Continuous monitoring to ensure greater than 99% availability;

14.6.12.3. Key Process Adoption: Over 80% of users must utilize the system for key processes;

14.6.12.4. User Satisfaction: Achieves a satisfaction score of 5 on a scale of 1-5;

14.6.12.5. Data Accuracy & Integrity: Ensures 99.9% data accuracy and 100% integrity checks passed; and

14.6.12.6. Stakeholder Approval: Hypercare processes must be reviewed and accepted by relevant stakeholders.

15.0 Sprint Deliverables

15.1. Sprint deliverables are recurring and tied to each sprint-based CLIN.

15.1.1. Working Software Increment: Functionality meets Definition of Done, demonstrated at Sprint Review, 100%-unit test passed, <2 defects, the acceptance criteria of the user stories completed during the Sprint. The working software increment is traceable to CLIN 0002.

15.1.2. Sprint Review Presentation: Demonstration of the working software increment at the end of the sprint to the Government Product Owner and stakeholders confirm delivery.

15.1.3. Sprint Retrospective Documentation: Documented lessons learned, and process improvement actions provided to the Government COR in the MSR.

16.0. Overall Project Deliverables and Schedule

16.1. The following deliverables are due at the times identified in Table 4 below.

16.2. Table 4: Project Deliverables and Schedule

Deliverable Due Date CLIN Acceptance Criteria Minimum Viable Product

(MVP)

Within 6 Months

0002 All MVP user stories “Done”; core modules configured; integration and interface with 1 legacy system; ATO artifacts submitted; 100% unit/integration tests passed

Production-Ready OFC HCM Solution

Within 9 months

0002 All PWS requirements met; UAT passed;

Gov acceptance of final documentation, architecture, and training materials

Deployment Plan (Initial) Sprint 1 0001 Outlines migration, cutover, and rollback strategy; Government approval received

Training Materials (Draft)

(CDRL A004)

Sprint 2 0001 Covers MVP features; reviewed by Product Owner

Training Materials (Final)

(CDRL A004)

Sprint 3 0002 Updated per user feedback; formatted for end-user distribution

User Acceptance Test Plan Sprint 3 0002 Approved test scenarios, data sets, success criteria

UAT Execution & Report Sprint 4 0002 All test cases passed; issues resolved or dispositioned

System Architecture Updated each Sprint

0002 Incorporates Government feedback;

reflects actual deployments

Training Delivery & Adoption Tracking

Post-MVP 0002 User metrics reported in MSRs; feedback loop in place

ICAs/ICDs (Final) Within 9 Months

0002 Within 8 Sprints/At Production Readiness Government acceptance of final documents

17.0. Contract Data Requirements List (CDRL)

17.1. Table 6: CDRL Requirements

CDRL Frequency Acceptance Criteria Tied to CLIN Monthly Status Report

(MSR) (CDRL A001)

Monthly Summary of deliverables, metrics (velocity, story completion, defect rate), user feedback

All

Presentation Materials

(CDRL A002)

As Required Submission to COR All

Test Inspection Reports

(CDRL A003)

Bi-weekly Summary of tests with pass rate, defects, and resolutions

Program Management Review (PMR) (CDRL A002)

Bi-Monthly Clear depiction of schedule, CLIN status, QASP compliance, CAPs if applicable

All

Training Materials (CDRL A004)

As Required Coverage of features required for any user

Requirements Traceability Verification Matrix

(CDRL A005)

Monthly, Initial submission per

CDRL

Clear depiction of requirement and verification method.

CLINs 0001-0004

18.0. Data Rights

The Government shall retain all rights, title, and interest in any data generated, collected, or processed within the HCM SaaS system. The Contractor shall ensure that all Government data remains accessible and transferable upon request, in accordance with applicable federal regulations and contractual provisions.

Appendix A – Glossary Acronym Title AFI Air Force Instruction AFIPPS Air Force Integrated Personnel and Pay System AFMAN Air Force Manual AFNET Air Force Network AI Action Item AO Authorizing Official ATO Authority to Operate A&A Assessment & Authorization BCAP Boundary Cloud Access Point BES Business Enterprise Systems CAC Common Access Card CAP Cloud Access Point CCA Oracle Certified Cloud Architect CI Configuration Item CNSSI Committee on National Systems Instruction CONOPs Concept of Operations COR Contracting Officer’s Representative COTS Commercial-off-the-shelf DAF Defense Acquisition System DISA Defense Information Systems Agency DNS Domain Name System DoD Department of Defense DoDI Department of Defense Instruction DoDM Department of Defense Manual EDI Electronic Data Exchange FOIA Freedom of Information Act FOUO For Official Use Only FPCON Force Protection Condition GBHP Platform and Integrations Branch HCM Human Capital Management HR Human Resources IA Information Assurance IAVA Information Assurance Vulnerability Alert IAVM Information Assurance Vulnerability Management ID Identification IDIQ Indefinite Delivery Indefinite Quantity IRP Incident Response Plan ISSM Information System Security Manager IT Information Technology JIRA Software Development Tool (Atlassian) LAN Local Area Network MilPDS Military Personnel Data System MSR Monthly Status Report

MVP Minimum Viable Product NACI National Agency Check with Inquiries NIST National Institute of Standards and Technology OFC Oracle Fusion Cloud OKTA Identity and Access Management Platform OPSEC Operations Security PK Public Key PKI Public Key Infrastructure PM Program Manager PMO Program Management Office PMP Program Management Plan POA&M Plan of Action and Milestones PPS Ports, Protocols, and Services PPSM Ports, Protocols, and Services Matrix PWS Performance Work Statement RAMS Random Antiterrorism Measures RMF Risk Management Framework RTVM Requirements Traceability Verification Matrix SaaS Software as a Service SBIR Small Business Innovation Research SCCA Secure Cloud Computing Architecture SR Service Request SRG Security Requirement Guide SBBI Single Scope Background Investigation STIG Security Technical Implementation Guide UI/UX User Interface/User Experience VDSM Virtual Data Management Service VDSS Virtual Data Storage Service