PLM PWS.pdf

Note: the links and images in this document may point to external sources. Please review them before opening.

PERFORMANCE WORK STATEMENT (PWS)

FOR AF-PLM CAPABILITY INTEGRATION

AND SUSTAINMENT

Development of USAF Digital Service Engineering

Processes for the AF-PLM Capability Support Office

DATE: 2 September 2026

Prepared By: AF-PLM CSO (AFLCMC/EZP)

Table of Contents

Section/Subsection Page

1.0 INTRODUCTION / Executive Summary 4

1.1 Purpose / Background 4

1.2 Objectives 4

1.3 Scope 5

1.3.1 System Description 5

2.0 REQUIREMENTS / Description of Services 6

2.1 Design 6

2.1.1 Define Need Review (DNR) (AFMC/A4 Requirement Approval) 6

2.1.2 Requirements Determination and Analysis 7

2.2 Data 8

2.2.1 Data Model Management 8

Section/Subsection Page

2.2.2 Data Migration 8

2.3 Development / Configuration & Test 8

2.3.1 Agile Development Release Capabilities 8

2.3.2 Requirements Assessment 9

2.3.3 Change Request (CR) and Information Systems Management Tool (ISMT) 9

2.3.4 Product Backlog (PB) 10

2.3.5 Program Increment (PI) Planning (Release Planning) 10

2.3.6 Sprint Planning (Step 2) 11

2.3.7 Sprint Backlog or Active Sprint (Step 3) 11

2.3.8 Sprints and Daily Scrum (Step 4) 11

2.3.9 Sprint Review (Step 5) 12

2.3.10 Increment Release (Step 6) 12

2.3.11 Build 12

2.3.12 System/Software Testing 13

2.3.13 Development Test (DT) 13

2.3.14 Product/System Integration Testing 14

2.3.15 Test Readiness Review (TRR) 15

2.3.16 Qualification Testing 15

2.3.17 Fielding Deployment Decision (FDD) 16

2.3.18 Release Retrospective 16

2.4 Training 16

2.4.1 Scope of Training 16

2.4.2 Training Delivery and Environment 17

2.4.3 Security and Data Handling 18

2.5 Infrastructure 18

2.6 Helpdesk 19

2.6.1 Help Desk Maintenance 19

2.6.2 Help Desk Metrics and Reporting 19

2.6.3 Help Desk Availability 20

2.6.4 Help Desk Resolution Time 20

2.6.5 Help Desk Plan 21

2.7 On-Boarding – ECP Task 21

2.8 Secret and Top-Secret Environments – ECP Task 21

3.0 PROGRAM MANAGEMENT 22

3.1 Program Management Plan (PMP) 22

3.1.1 Funds and Man-hour Expenditure Report (FMER) 22

3.1.2 Risk Management 23

3.2 Integrated Master Schedule (IMS) 23

3.3 Program Metrics 23

3.3.1 Metrics Reporting 23

3.4 Configuration Management (CM) 25

3.5 Quality Assurance (QA) 25

3.6 Cybersecurity 26

3.6.1 Application Cybersecurity 26

3.6.2 Personnel Cybersecurity 26

3.6.3 Assessment and Authorization (A&A) 27

3.6.4 Malicious Logic Protection 28

3.6.5 Security Reporting Responsibility 28

3.7 Security, Privacy, and Safety 28

3.8 Systems Transition 29

3.8.1 Transition Plan at Contract Start 29

3.8.2 Transition Plan at Contract Conclusion 29

3.8.3 Transition Execution 30

3.8.4 Integration/Transition of Systems 30

3.9 Security Safeguarding and Technical Data Rights 30

3.9.1 Safeguarding Covered Defense Information 30

3.9.2 Rights in Technical Data and Computer Software 31

3.10 Service Delivery Summary (SDS) / Quality Assurance Surveillance Plan

(QASP) Matrix

4.0 Key Personnel 33

5.0 APPENDICES 35

5.1 APPENDIX A - Acronyms and Abbreviations 35

1. INTRODUCTION / Executive Summary

The USAF has implemented Product Lifecycle Management (PLM) software to enable Air Force

Program Offices to digitally manage their weapon systems. For most programs this includes a transition from legacy 2D document management with simple independent repositories to integrated digital data and digitization of their business processes with active configuration management. The AF has implemented this as an Enterprise PLM solution utilizing Commercial-

Off-The-Shelf (COTS) software from Siemens known as Teamcenter. To accomplish this, the AF has established this capability as a program of record implemented by the Air Force Product

Lifecycle Management Capability Support Office (AF-PLM CSO). This office is responsible for defining the scope and implementation of Enterprise PLM capability within the AF. This USAF

Enterprise PLM capability operationalizes the AF and AFMC Strategic Plans, empowering USAF

Program Offices (PO) to do lifecycle Digital Material Management. Specifically, it advances

AFMC Strategic Plan, Line of Effort (LOE) #1 (Deliver Integrated Capabilities) and LOE #3

(Revolutionize our Processes) while facilitating other LOEs through the integrated digital management of weapon systems process and data. AF-PLM achieves this mission across the entire weapon system lifecycle from program initiation and acquisition through sustainment and eventual retirement.

1.1. Purpose / Background

The purpose of this effort is to develop and sustain the AF-PLM Enterprise PLM solution, utilizing Teamcenter hosted within the Cloud One environment. Currently, the Air Force relies on disparate systems and disconnected data silos. This fragmentation leads to operational inefficiencies, compromised data integrity, and critical delays in decision-making. To resolve these challenges, the Air Force requires a centralized, robust, and scalable Product Lifecycle

Management (PLM) system to securely manage the entire lifecycle of its critical assets— spanning from initial design and development through sustainment and retirement.

1.2. Objectives

The primary objectives of this enterprise PLM implementation are detailed in the table below:

Objective Operational Impact

Authoritative

Source of Truth

Establish a single, secure, and authoritative source for all product data to guarantee enterprise-wide data integrity.

Process

Streamlining

Optimize engineering, manufacturing, and sustainment workflows to reduce cycle times for engineering changes.

Configuration

Management

Enhance configuration control and maintain rigorous compliance with

Department of Defense (DoD) regulations, aligned with authorized secondary Department of the Air Force (DAF) administrative frameworks.

Enterprise

Collaboration

Drive seamless collaboration and secure data sharing between internal teams, external suppliers, and defense partners.

Sustainment of the AF-PLM Enterprise solution eliminates data silos and establishes a single source of truth, directly accelerating decision-making and enhancing total lifecycle management for Air Force assets.

1.3. Scope

The scope of this Performance Work Statement (PWS) encompasses the planning, design, configuration, deployment, and sustainment of the AF-PLM Enterprise platform. This includes, but is not limited to, product data management (PDM), Computer-Aided Design (CAD) data management, Bill of Materials (BOM) management, engineering change management, and integration with existing enterprise systems. The Contractor shall provide all necessary program management, systems engineering, configuration management, Teamcenter configuration, integration, testing, training, and sustainment activities to deliver the capabilities outlined in the requirements documents. Furthermore, the Contractor shall plan and execute software and hardware maintenance for all test and production environments within Cloud One, including the maintenance of Contractor development suites used for compiling end-item products.

1.3.1. System Description

1.3.1.1. AF-PLM Environment

The AF-PLM environment is a cloud-based, Commercial-Off-The-Shelf (COTS) solution hosted within the Air Force's Cloud One enterprise platform. The foundational software driving this environment is Siemens Teamcenter, designated as the standard Air Force PLM platform. This environment functions as a centralized, collaborative data repository for both engineering and logistics information. It is designed to be accessible to a wide range of authorized stakeholders, including the USAF Engineering Community, weapon system program offices, and Air Logistics

Complexes, thereby breaking down traditional functional silos.

2. REQUIREMENTS / Description of Services

2.1. Design

The design shall encompass all necessary hardware, software, data architecture, and security components to deliver a robust, scalable, and secure PLM capability across the enterprise. The contractor shall employ disciplined systems engineering processes including, but not limited to, requirements development, technical management and control, system architecture/software design, risk management, configuration management, data management, and test, evaluation, verification and validation practices throughout the period of performance in accordance with

AFI 63-1201, Life Cycle Systems Engineering. The contractor shall provide related systems engineering documents. The contractor shall support governance checkpoints such as systems engineering and test reviews and work with the Government team to develop a streamlined documentation approval process and Agile incremental systems engineering reviews leveraging the ongoing visibility/collaboration.

2.1.1. Define Need Review (DNR) (AFMC/A4 Requirement Approval)

As requested by the Government, the Contractor shall support the Define Need Review (DNR) as a technical advisor. The DNR (aka Functional Review Board) Phase is where representatives for the AF-PLM CSO review the validity of BCRs and TCRs with the functional user community. If the requirement is deemed current and valid, a CR shall be created in ISMT. After this CR creation, the Contractor shall be asked to provide an analysis and preliminary design (if needed) along with an estimate using story points. Preliminary designs are often put forward via

Technical Interchange Meetings to the functional user community for discussion prior to the CR approval. The AF-PLM CSO team has adopted one story point equating to one day of development activity for a single person. Once the estimate and analysis are provided back to

PMO, the CR shall be put forward for AFMC/A4 approval. Once approval has been received, the

AF-PLM CSO shall move the epic forward in the workflow which results in related stories going into the developer backlog. The Contractor shall develop and document high-level system designs (including all necessary interfaces and database design) that implement the release requirements and deliver the high-level design in the SDD. The Contractor shall work closely with the AF-PLM CSO, other external hosting providers, COTS Vendors, and other Air Force personnel to ensure the design provides an acceptable solution within the DoD and AF computing environments. If additional Technical Interchange Meetings (TIM) are needed to finalize the design, Contractor shall request them; otherwise, the preliminary design shall be carried forward for development. The Contractor shall maintain on-going coordination with and support to the AF-PLM CSO personnel developing and maintaining Interface Control Documents

(ICDs) or Interface Requirement Agreements (IRAs) for existing or new interfaces. As necessary, the Contractor shall provide interface change investigation, analysis, and draft

ICD/IRA updates.

2.1.2. Requirements Determination and Analysis

As requirements originate from users and policy mandates, the Contractor shall collaborate with

AF-PLM CSO product owners, subject matter experts and functional users to document and track requirements and allow the government to maintain a prioritizing list of requirements. The

Contractor shall review Epics and build individual stories, tasks, and subtasks capable of being developed and completing Developmental Test & Evaluation at the end of each sprint. The

Contractor shall represent and provide an understanding of requirements at Functional

Requirements Boards (FRB) and Configuration Control Boards (CCB). The Contractor shall conduct activities to support the system/software requirement issue types (Deficiency Reports

(DRs), Problem Reports (PRs), Information Support Requests (ISRs), Baseline Change

Requests (BCRs), Technical Change Requests (TCRs), defects, stories, tasks, bugs, spikes, or other issue types in Jira or ISMT. The Contractor shall conduct investigation and initial solution recommendation in accordance with (IAW) the configuration management plan(s) and the HQ

AFMC/A4 Logistics Information Technology (Log IT) Change Control Process (CCP), implemented 18 February 2016. The Information System Management Tool (ISMT) is the mandated application directed by AFMC/A4 to be used for reporting, documenting, tracking, and boarding all BCRs and TCRs. AF-PLM CSO subject matter experts shall submit the BCR and

TCR requirements via developing a Change Request (CR) and submitting through the AFMC

Logistics IT Tiered Governance Approval Levels as depicted in the AFMC Requirements

Management Plan. After CR approval and placement of user stories into the development

Backlog, the Contractor shall host a Release (aka Program Increment) Planning event for each release to review requirements, determine security posture, and review/address CDRL requirements to support the Release Planning, and set release scope.

2.2. Data

2.2.1. Data Model Management

The contractor shall manage the baseline AF-PLM Data Model. The contractor shall modify the baseline AF-PLM Data Model as required to accommodate all relevant engineering and logistical data, the creation of automated workflows to streamline change management and review processes, and the establishment of robust integrations with existing and future enterprise systems. The Contractor shall manage and evolve the AF-PLM data model to ensure the data consistency, integrity and useability of deployed capabilities and to enable integrations with CSO-targeted and PLM-related initiatives and systems. The Contractor shall develop and manage the interoperability of the data model leveraging DoD and Open Standards to enable integration of supporting mission functions to include contracting, financial management, operational test, product support, logistics, maintenance, and operations.

2.2.2. Data Migration

The contractor shall provide data migration solutions or use existing data migration solutions to perform data migration for new and existing AF-PLM users.

2.3. Development / Configuration & Test

The contractor shall configure and extend the Siemens Teamcenter platform to establish a unified and integrated Product Lifecycle Management (PLM) environment for the AF-PLM program. The configured system must support a comprehensive digital thread, ensuring seamless data traceability and accessibility across the entire lifecycle of Air Force assets, from initial design and engineering to manufacturing, sustainment, and eventual retirement. The configuration shall include, but is not limited to, the development and implementation of a standardized data model that accommodates all relevant engineering and logistical data, the creation of automated workflows to streamline change management and review processes, and the establishment of robust integrations with existing and future enterprise systems. The final configured solution will provide a secure, multi-user environment with user interfaces and roles tailored to the specific needs of different user groups within the Air Force and its industry partners. The contractor's performance will be measured by the successful deployment of a fully functional and scalable Teamcenter environment that meets the performance and data management requirements of the AF-PLM program.

2.3.1. Agile Development Release Capabilities

The Contractor shall establish Scrum development team(s) to support AF-PLM capabilities covered under this task order and apply Scrum-based Agile development. The Contractor shall support the AF-PLM Product Owner (PO) or Proxy Product Owner (PPO) who shall set direction, prioritize choices, building a Product Roadmap, and develop the Portfolio and Product Backlog

(PB) to address AF-PLM’s business capability needs. The Contractor shall provide a Scrum

Master for the sustainment support effort covered under this PWS. The Scrum Master shall support the AF-PLM Team by leading, training, and coaching in Scrum adoption, and removing barriers between stakeholders and Agile Pods.

2.3.2. Requirements Assessment

The Contractor shall review epics and break down those requirements into individual stories, tasks, and subtasks with the objective of maximizing efficiency throughout the Sprints and

Release cycle. The Contractor shall review Defects/Bugs and build applicable tasks and subtasks for inclusion during Release and Sprint Planning to address operational deficiencies.

The PO or POA leads BCR and TCR requirements definition and workflow within ISMT. The

Contractor shall represent and provide an understanding of requirements at Functional

Requirements Boards (FRB) and Configuration Control Boards (CCB). The Capability Delivery

Manager (CDM)/Program Manager (PM) and/or PPO may request support in evaluating new requirements to determine workload and cost (i.e., technical solution and rough order of magnitude). Requirement evaluation support includes participation in Technical Interchange

Meetings (TIMs), product demonstration attendance and review technical documentation. High

Level Requirements and derived stories, tasks, and subtasks shall be tracked in Jira.

Established AF-PLM requirements management workflow shall begin with the CRs in ISMT and ultimately result in epics and related stories being recorded in the Product Backlog.

2.3.3. Change Request (CR) and Information Systems Management Tool (ISMT)

The Contractor shall support the investigation and initial solution recommendation in accordance with (IAW) the configuration management plan(s) and the HQ AFMC/A4 Logistics

Information Technology (Log IT) Change Control Process (CCP). The Contractor shall perform analysis, draft a technical solution, perform story point estimation, and labor hour estimates if required, on all prioritized user stories and epics in Jira. At times, the Government shall require more advanced ROM estimates. When required, the Contractor shall provide a detailed technical solution and rough order of magnitude estimate (TS-ROM) describing the proposed technical solution, schedule, and estimated labor hours required. The Contractor shall provide estimates for these CRs in corresponding Jira stories using story points. The PO or PPO shall convert the story point estimates into hour estimates for entry in ISMT. After a CR has been approved by the government in ISMT, the Contractor shall enter into Jira any required tasks or sub-tasks needed to perform the work.

2.3.4. Product Backlog (PB)

The PO or PPO uses established requirements management workflow for replicating the ISMT

BCRs and TCRs into Jira Epics. The Contractor shall assist the Government in further defining and decomposing requirements into multiple stories for inclusion into the backlog. The

Contractor shall assist with integration of Government owned tools and workflows associated with complementary Agile tools (e.g., Jenkins CI Server; Git/Bitbucket; Confluence). The

Contractor shall support semi-annual AF-PLM Vision and Product Portfolio planning that shall be performed collaboratively by an Integrated Product Team (IPT) to define/refine the Product

Roadmap of epics and Features. The Contractor shall also support the PO in refining/grooming

AF-PLM epics/Features as User Stories are developed. As part of Sprint Planning, the

Contractor shall assist the PO in developing the Definition of Done criteria to enable the PO and stakeholders to verify User Story requirements and design completion. The Contractor shall also assist the PO in developing Minimum Viable Product (MVP) criteria to validate product release candidate readiness for production release. The Contractor shall estimate the size of each User

Story and evaluate it in priority order to determine if sufficient information is available to estimate. The Contractor shall estimate User Story size in Story Points and decompose them into Tasks that shall be input into a Scrum-based tool (i.e., Jira). Once User Stories in the PB have been estimated, they shall be selected for inclusion in the Sprint based on historical velocity and maximum business value. The AF-PLM PO shall serve as the sole owner of the PB.

The Contractor shall support the PO in PB briefings, auditing, and reporting tasks. Additional AF

SMEs shall be made available by the Government as needed to assist in the PB development process and contributing technical meetings (e.g., IPTs/TIMs) and User Centered Design (UCD) discussions.

2.3.5. Program Increment (PI) Planning (Release Planning)

AF-PLM uses PI planning to scope releases and execute the product roadmap. The Contractor shall participate in and support PI Planning events. The Contractor shall provide feedback as to what requirements, epics, features, stories, and defects can fit within a given PI release period.

This scope shall be documented in the program’s IBR which is maintained by the AF-PLM CSO and shall constitute the Minimally Viable Product for the PI period. The length of a given PI timeframe shall be directed by the Government.

2.3.6. Sprint Planning (Step 2)

The Contractor shall implement 2-week Sprints for Agile team(s) on the AF-PLM program. A

Sprint Planning meeting shall occur at the beginning of each Sprint. It shall be led by the

Contractor who shall coach the PO, CDM, and development team regarding the work to be done during the upcoming Sprint.

2.3.7. Sprint Backlog or Active Sprint (Step 3)

The Contractor shall further decompose User Stories and PB Items into discrete Tasks. The team shall collectively own the tasks to completion and post them to Scrum Boards. Scrum

Boards shall support visualizing the flow of work and establish the metrics that shall measure the workflow. The key outcome of the Sprint Backlog step is a list of tasks that can only be modified by the Scrum team.

2.3.8. Sprints and Daily Scrum (Step 4)

The Contractor shall use User Centered Design (UCD) and Test-Driven Design (TDD) during development when applicable, such as with development of new software. The Contractor shall strive to maximize automated testing as it creates test scripts. Development Sprints shall include frequent security testing using security scans to detect and remove cybersecurity-related coding errors. Security Testing shall be conducted prior to committing code to a development sandbox.

The Contractor shall conduct Daily Scrum of Scrum sessions, to include AF-PLM CSO and

Government test team members as requested by the Government, to ensure everyone is on the same page, aligned with the Sprint goal, and to help establish a plan for the next 24 hours. The collective team shall assess progress using best practice Agile development quality metrics

(e.g., Sprint Backlog Burndown, Velocity, Cumulative Flow). Each Agile team shall conduct daily

Scrums for reporting progress toward sprint goals. The Contractor shall use web-based Jira

Scrum boards and dashboards provided by the Government to track issues and risks. The

Contractor shall update Jira as items are worked to reflect an accurate status of work in process.

2.3.9. Sprint Review (Step 5)

At the end of each Sprint, the Contractor shall demonstrate the product in a development environment and discuss maturity of capability or product transparently with the PO and CDM.

The PO can rework and revise the PB based on any deficiency found in the current Sprint which shall feed into the next Sprint planning session. At the end of the final Sprint Review of the release cycle, the Contractor shall deliver to the AF-PLM CSO and stakeholders the Release

Package with the refactored solution from the Sprint Demo and submit the appropriate CDRLs.

Features that have completed the development iteration Sprint Review shall be reviewed at the

Sprint demo. Upon completion of the configuration cycle and PMO approval to allocate to a release, the release shall be promoted to the Test Zone environment for User Acceptance

Testing (UAT). Government Involvement: The AF-PLM PO participates in Sprint Review meetings.

2.3.10. Increment Release (Step 6)

The Sprint Review Step shall be conducted in the development environment to verify the increment meets MVP “Definition of Done” criteria. Additionally, the Contractor shall provide incremental Feature-focused design artifacts for initial review to enable the PO to make informed decisions to proceed forward with development efforts that shall eventually be merged into final release CDRLs once the designs are complete. In addition, the Contractor shall run rollback/uninstall testing to ensure an AF-PLM roll-back capability is in place to minimize any negative impact upon users in the event of a release failure.

2.3.11. Build

The Contractor shall develop and update a final system design that implements the approved requirements (including all necessary interfaces and database design and database information

(such as, but not limited to, logical and physical structures, data dictionary, maintenance stored procedures, and special privileges/environment settings/security concerns). The Contractor shall be responsible for the integration, testing, final packaging and installation documentation.

The Contractor shall coordinate installation or update any COTS products provided by AF directly. The Contractor shall appropriately integrate the use of the Government selected code scanning software tools into the software development process. When appropriate, the

Contractor shall use the findings to improve the security posture of the system code.

2.3.12. System/Software Testing

The Contractor shall conduct and support system/software testing, including load testing in accordance with OI 99-103 as tailored and approved by the Government and outlined in the

Integrated Test Plan. The Contractor shall deliver the Computer Program End Items

Documentation (CPEID) following the Requirements Operability Test (ROT) phase and update and redeliver as necessary from later testing phases.

2.3.13. Development Test (DT)

The Contractor shall conduct development and integration testing to ensure the software changes have been tested prior to turn over for Government functional or evaluation testing.

The developmental testing shall be conducted in the Development Zone hosted by the

Government. The Contractor shall support an approach in which AF-PLM CSO testers participate in architecture definition, initial design, functional analysis, Software Test Plan (STP) and Software Test Description (STD) evolution, and system integration and testing. The

Contractor shall conduct document testing to include unit, system, integration, and external interface testing for all software products against the System/Subsystem Specification (SSS).

Testing shall be built and documented using the Government provided instance of Zephyr for

Jira. The Contractor shall document test cases/scripts in a step-by-step type outlining, at a minimum, the Step, Test data, and Expected Results, Estimated Time. The Contractor shall document execution of test cycles and test plans and shall record actual test execution time.

The Contractor shall develop, update, and deliver an STP, an STD, and a Software Test Report

(STR). These artifacts and reports shall be provided by Zephyr via the Confluence plug-in. STP shall address the Contractor ’s testing and test environments. The STD shall include test cases and test scripts with test data inputs/outputs and be sufficiently definitive to enable the functional users to assess the testing and its results. The STR shall document the Contractor ’s testing and test results that were accomplished. All Priority 1 and 2 Deficiency Reports (DRs) from development testing shall be corrected prior to Test Readiness Review (TRR). Unless accepted by the Government, all Priority 1 and 2 DRs determined against COTS code shall be addressed prior to TRR. Priority 3 DRs shall be addressed as determined by the Government.

2.3.14. Product/System Integration Testing

The Contractor shall perform testing and inspections of all system services to ensure the technical adequacy and accuracy of all work, including reports and other documents required in support of that work. The Contractor shall conduct on-site testing when requested. The

Contractor shall provide system and database support for test activities required for each software release. This includes server preparation and software loads and communications set up with interface partners. The Contractor shall perform testing against any version of Microsoft

Edge, Google Chrome, and Mozilla Firefox currently in use by the Air Force. The Contractor shall test each version of software being developed or currently fielded to ensure it integrates and is compatible with existing USAF Standard Desktop Configuration (SDC) platforms. The

Contractor shall manage and participate in the SDC testing for AF-PLM. The Contractor shall test and validate that all SDC versions in use on the AFNET are interoperable with AF-PLM. The

Contractor shall report the status of all SDC versions to the AF-PLM CSO and System Engineer.

The Contractor shall continuously monitor upcoming SDC releases and shall perform compatibility testing. The Contractor shall evaluate compatibility issues with the SDC and provide reports to the PMO which shall, at a minimum, summarize the issues and provide solutions. When specified by the government, the Contractor shall participate with the government in testing the complete system or application which may include AF-PLM equipment, distribution systems or any additional telecommunications equipment or operating support systems identified in the Contract. After appropriate corrective action has been taken, all tests including those previously completed related to the failed test and the corrective action shall be repeated and successfully completed prior to government acceptance. Pre-cutover audits shall consist of verification of all testing completed by the Contractor such that the system is deemed ready for functional cutover. As part of this audit, any engineered changes or approved waivers applicable to the installation shall be reviewed and agreed upon between the

Contractor and the Government. Post-cutover audits shall verify that all post-cutover acceptance testing has been performed satisfactorily IAW the standard practices and identify those tests, if any, which have not been successfully completed and must be re-tested prior to acceptance. Testing shall be performed in two steps: operational testing, then SAT. The

Contractor shall provide a logical test process that minimizes interruptions and avoids sustained downtime and presents a contingency procedure to be implemented in the event of systems failure during testing.

2.3.15. Test Readiness Review (TRR)

The Contractor shall facilitate the Test Readiness Review (TRR). In advance of the TRR, the

Contractor shall publish to Confluence a list of all CDRLs related tasks required for the remainder of the effort and identify those that shall/shall not require update/submission based on the content of the release and results of testing to date. The Contractor shall provide updated Application and Security Development Security Technical Implementation Guides

(STIGs), and any other applicable STIGs, using the current benchmark available from the DISA

Information Assurance Support Environment (IASE) website with each software delivery. The

Contractor shall provide current security code scan reports with every software delivery using the Government directed security code scanning tools. If at any time after submission, the

Contractor determines otherwise (one or more of the identified documents does require update/submission), the Contractor must notify the Government PM within 24 hours by e-mail.

For documents not requiring update/submission, the approved list shall constitute the required delivery.

2.3.16. Qualification Testing

The Contractor shall support independent testing performed by the Government in an AF-PLM hosted test environment. The Contractor shall monitor and respond to testing and update all necessary test documentation as appropriate to reflect changes. Unless formally accepted or waived by the Government, all Priority 1 and Priority 2 Jira bugs/deficiencies shall be resolved prior to the completion of Qualification Testing and production deployment. Priority 3 Bugs shall be addressed as determined by the Government including migration of the Jira Bug to

Deficiency Report which is put in Product Backlog for future completion. The AF shall consider software testing successful when it has passed AF testing at its test site.

2.3.17. Fielding Deployment Decision (FDD)

The Contractor shall support the Fielding Deployment Decision (FDD). For AF-PLM releases, the Contractor shall support the AF-PLM CSO CM Manager regarding delivery of the approved software to AF-PLM CSO, and coordinate installation with local users and administrators.

Alternatively, where a pipeline has been constructed the Contractor shall support PMO in deploying the products into the DISA environment.

2.3.18. Release Retrospective

During the Release Retrospective, the Contractor shall collaborate on ways to improve how the

Contractor, AF-PLM PO and CSO can work more efficiently in subsequent releases. The team shall decide how to fix any problems, with the intent of improving their efficiency in the next release cycle. The benefit is that the team will be more efficient and produce more work with each new cycle.

2.4. Training

The Contractor shall develop, deliver, and maintain a comprehensive training program tailored to the Air Force Product Lifecycle Management (AF-PLM) Siemens Teamcenter environment.

This ensures Department of the Air Force (DAF) and joint Department of Defense (DoD) personnel achieve operational proficiency in digital engineering, product data management, and lifecycle workflows. All training materials and sessions must be appropriate for an unclassified/Controlled Unclassified Information (CUI) environment.

2.4.1. Scope of Training

The Contractor shall provide role-based initial, sustainment, and major-release software training for AF-PLM Siemens Teamcenter. The training program must ensure users are fully capable of utilizing Teamcenter capabilities to execute the digital thread and manage weapon system data.

Specific training tracks shall be developed for the following user roles: General Users

(Consumers): Navigation, searching product data, viewing 3D models (e.g., via Active

Workspace), and participating in review workflows. Authors / Engineers: Part and Bill of

Materials (BOM) management, CAD integrations, document authoring, and executing

Engineering Change Notices (ECN) or Engineering Change Requests (ECR). System

Administrators: Access control, workflow configuration, organization structure management, and system troubleshooting.

2.4.2. Training Delivery and Environment

The Contractor shall employ a blended learning approach to accommodate various operational tempos. Approved delivery methods include: Instructor-Led Training (ILT): Conducted in-person at designated government facilities or virtually via government-approved, IL5-compliant platforms. Computer-Based Training (CBT): Self-paced modules hosted on the government's designated learning management system (LMS). Train-the-Trainer (TtT): Specialized sessions to qualify designated government personnel to conduct internal unit-level AF-PLM training.

Dedicated Training Environment: The Contractor shall establish and maintain a dedicated

Siemens Teamcenter "sandbox" or training environment that mirrors the production environment's configuration for hands-on exercises.

The Contractor shall provide a continuous and adaptable training lifecycle for the AF-PLM

Siemens Teamcenter system. The training program must include the following specific types of training: AF-PLM 101 (Foundational Training): A high-level, introductory overview covering the basics of Product Lifecycle Management, the digital thread concept, and fundamental navigation within the Teamcenter environment. Target audience: All new users and program stakeholders.

Onboarding Training: Comprehensive, role-based instruction required for new personnel joining the program before they are granted full operational access. This includes specific tracks for

General Users (Consumers), Authors/Engineers, and System Administrators. Release Training:

Targeted instruction and documentation delivered prior to or concurrent with major software releases, system upgrades, or patch deployments. This training shall focus strictly on new features, user interface changes, and modified engineering workflows. Just-in-Time (JiT)

Training: On-demand, bite-sized training resources (e.g., micro-learning videos, interactive tooltips, or embedded digital adoption guides) designed to assist users at the exact moment of need while executing complex or infrequent workflows (e.g., Engineering Change Notice routing).

2.4.3. Security and Data Handling

All AF-PLM training scenarios, databases, and materials shall utilize unclassified, synthetic engineering data (e.g., mock CAD models, dummy BOMs). If the software training environment requires the use of actual Controlled Unclassified Information (CUI) or Export Controlled technical data, the Contractor must ensure the environment and materials are marked and handled in accordance with DoDI 5200.48 and applicable IL5 security protocols. Under no circumstances shall live Personally Identifiable Information (PII) or Protected Health Information

(PHI) be used in the training environment.

2.5. Infrastructure

The Contractor shall support the technology infrastructure of AF-PLM by providing cloud computing architecture and Teamcenter expertise to design, plan, implement and system and cyber test cloud-hosted operating environments. The Contractor shall analyze system requirements, advise and select appropriate services and design scalable, reliable, secure, cost effective and interoperable architectural concepts at the CUI classification level. The Contractor shall leverage Cloud best practices to provide scalability and effectivity of the solution. Core practices include deployment automation, Infrastructure-as-Code, virtual private cloud/networks, system integration, and cyber compliance for sandbox, development, test, training, data loading, integration, cyber test and production. Activities shall be integrated into the overall Agile and capability delivery framework and dependencies and risks identified and managed throughout the lifecycle of capability. The Contractor shall recommend solutions and leverage their expertise in on-premises, commercial cloud and USAF Cloud One hosting to ensure the continuous improvement of the solutions as AF-PLM evolves and expands. Infrastructure decisions, designs and diagrams will be documented.

2.6. Helpdesk

The Contractor shall provide comprehensive, multi-tiered Helpdesk support services (Tier 1 through Tier 3) for the Air Force Product Lifecycle Management (AF-PLM) system to ensure continuous operational readiness and user adoption. Support shall encompass issue logging, troubleshooting, user account management, and resolution of inquiries related to AF-PLM system functionality, engineering workflows, and data integration. The Contractor shall utilize the

Government-designated enterprise IT service management tool (e.g., Jira Service Desk) to track, manage, and report on all service tickets. Furthermore, the Contractor must adhere to

Government-defined Service Level Agreements (SLAs) for response and resolution times, proactively maintain a robust knowledge base to drive first-contact resolution, and identify recurring technical issues to recommend continuous system improvements.

2.6.1. Help Desk Maintenance

The contractor shall provide ongoing maintenance and support of the Jira AF-PLM help desk.

This includes setting up and managing the custom AF-PLM Jira project to manage support tickets and configuring/managing workflows, fields, users, and screens, to support ticket management, and working with the BES Atlassian Tools (BAT) Team as required. The

Contractor shall respond to support tickets in a timely and effective manner, escalating issues as necessary, and communicating status updates to users.

2.6.2. Help Desk Metrics and Reporting

The contractor shall provide regular metrics and reporting on the performance of the Jira help desk. This includes tracking and reporting on key performance indicators (KPIs) like time to respond, resolve, ticket resolution time, customer satisfaction, and volume utilizing Jira Help

Desk reports. The contractor shall also provide recommendations for continuous improvement of the help desk based on these metrics.

Definitions:

Time to Respond: The amount of time it takes from first logging an issue with IT support, through to when an IT technician first begins working to resolve the challenge.

Time to Resolution: The time it takes from first logging an issue with IT support, through to the resolution – when the issue is solved.

The contractor shall provide performance metrics for service desk resolutions to include response time, resolution time, quantity and category of tickets, and trends over time. The contractor shall provide a listing of the types of issues and FAQs expected to be resolved on first contact, and provide ad-hoc help desk training as specific issues arise.

2.6.3. Help Desk Availability

Adverse conditions impacting AF-PLM functionality documented within ticket queues must be addressed 24 hours, 7 days a week, 365 days a year in accordance with the severity levels defined in Section 2.6.4 of this PWS to address any emergency, critical, highest, or high priority requests. Ticket queue monitoring may be aided by technological functions (i.e., monitoring tooling) that can allow personnel to be informed of ticket submissions. The help desk/site support staff shall be available to users and shall address all ticket priority levels during the agency's normal business hours (Monday through Friday, 8:00 AM to 6:00 PM Eastern Time) except when BES takes the tools offline for routine maintenance or patching during business hours and shall respond to support tickets within 2 hours of receipt.

2.6.4. Help Desk Resolution Time

The contractor shall resolve support tickets in a timely and effective manner. Help desk reported issues that are related to bugs or deficiencies may remain open and be linked with a development story. These stories shall be prioritized from Backlog during Sprint Planning.

Ticket severity definitions:

Emergency (P0) = System down.

Critical (P1) = User experiencing a system issue with significant impact to mission and no work around OR Interface partner issue of significant impact with no workaround. A massive number of users are affected, core functionalities are completely broken, and/or persistent data loss may be occurring.

High (P2) = User experiencing a system issue of significant impact with a workaround OR interface partner issues of significant impact with a workaround. A severe issue that significantly degrades the user experience or business operations but is not causing a total system halt. A large set of users or important features are disrupted, but a workaround may exist.

Medium (P3) = An error that affects a limited portion of the software or a smaller subset of users. A specific capability is malfunctioning, but standard operations can continue using a non-technical or manual workaround.

Low (P4) = A minor inconvenience or defect that has negligible impact on the overall user base or system functionality. The software is fully usable, but the issue causes minor annoyance.

Lowest (P5): Lowest priority; typically assigned to feature enhancements, suggestions, or extremely minor visual inconsistencies that do not break the design system. Zero effect on functionality or standard user journeys.

2.6.5. Help Desk Plan

The contractor shall support the creation of an overarching PMO help desk plan using a help desk plan framework provided by the Government.

2.7. On-Boarding – ECP Task

Government representatives will conduct planning with programs to evaluate readiness for on-boarding into AF-PLM. The contractor shall provide support to program on-boarding by evaluating program needs and provide ROM estimates for data migration support to programs planned for onboarding.

2.8. Secret and Top-Secret Environments – ECP Task

Upon Government issuance of an approved Engineering Change Proposal (ECP) task order, the

Contractor shall plan, design, configure, test, and deploy the AF-PLM Enterprise platform

(Siemens Teamcenter) within designated Secret (SIPRNET / Cloud One IL6) and/or Top-Secret

(JWICS) cloud-hosted operating environments. The Contractor shall provide security-cleared personnel possessing active Secret and/or Top-Secret/SCI clearances in accordance with the contract's DD Form 254. The Contractor shall apply RMF controls, perform system vulnerability scanning, and generate Cybersecurity Test Reports (CSTR) tailored for classified domains. The

Contractor shall coordinate with the AF-PLM CSO ISSM to obtain and maintain an Authorization to Operate (ATO) for all classified deployments.

3. PROGRAM MANAGEMENT

The Contractor shall conduct program planning and control, to include, but not limited to, system transition planning; work breakdown structure and risk management; program schedule and metrics tracking; configuration and change management; quality assurance; and

Subcontractor management. The Contractor shall provide a Program Manager (PM) with demonstrated skills to coordinate cost, schedule, and performance tasks. The Contractor PM shall supervise the entire Contractor team to include systems engineers, support staff, lead site representatives, training staff, and administrative staff. The Contractor PM shall integrate teams and implement standard development and sustainment policies and processes across the team.

The Contractor PM shall also be responsible for technical contract management, communications with the program staff, system site representatives, scheduling, and contractual clarifications. The Contractor shall comply with all Federal regulatory compliance associated with the development and use of software in accordance with applicable standards within the

Department of Defense, including Section 508 of the Rehabilitation Act of 1973 (29 U.S.C. §

794d). IAW CDRL A001, Contractor shall provide comprehensive status reports to the

Government, to include but not be limited to monthly production statistics, software license/hardware updates, financial, contract and task status, help desk statistics, and the status of Government Furnished Property/Equipment (GFP/E), if applicable.

3.1. Program Management Plan (PMP)

The Contractor shall develop and maintain a PMP that describes the management methodology for maintaining, sustaining, and developing/modifying the AF-PLM capabilities. The PMP shall include the Contractor's organization: assignment of functions, duties, and responsibilities; a responsibility-based work breakdown structure; management procedures, policies, and reporting requirements; and methodology for accomplishing contract tasks. The Contractor ’s

PMP shall include a comprehensive description of the tools, methodologies, and processes for managing AF-PLM such as, but not limited to, requirements, development, integration, test, training, implementation support, maintenance, and sustainment activities. The Contractor shall include the Risk Management Plan (RMP) and Contractor ’s Configuration Management Plan as appendices to the PMP.

3.1.1. Funds and Man-hour Expenditure Report (FMER)

The Contractor shall report financial status as applicable to this contract in accordance with the requirements stated herein, and in the CDRL instructions for the Funds and Man-hour

Expenditure Report. The Contractor shall refer to applicable Contract Line-Item Numbers

(CLINs).

3.1.2. Risk Management

The Contractor shall adhere to the cross functional team Risk Management Plan published by the AF-PLM CSO. The Contractor shall create, monitor, and collaborate all risks with the cross functional team using the Jira Risk Register. Risks shall be identified, documented, and tracked for Release Candidates, operational issues, and overall health programs. Contractors will participate in periodic risk review meetings and report changes or closure associated with risks.

3.2. Integrated Master Schedule (IMS)

The Contractor shall work in conjunction with AF-PLM CSO Program Manager to develop and maintain/update a Release Plan for AF-PLM capabilities, and an Integrated Master Schedule for all technical refreshes and capability delivery and on-boarding activities. These activities shall also include providing updates on schedule slippage and delays and opportunities to expedite schedules and/or items.

3.3. Program Metrics

The Contractor shall establish, maintain, and use metrics that are appropriate to the authorized scope of work and shall routinely report these to the Government as contractually specified. The

Contractor shall base the metrics on product-oriented and/or performance parameters that are discretely measurable. The Contractor shall support the Government PM in developing and reporting these metrics to the AF-PLM CSO and to other Government personnel. The

Contractor shall obtain approval from the Government prior to making changes that impact

Contractor-delivered metrics.

3.3.1. Metrics Reporting

The Contractor shall report and deliver the status of key performance metrics to the

Government in accordance with the delivery schedule. At a minimum, the Contractor shall ensure the metrics are measured against an established performance baseline and have thresholds established to indicate when management attention is warranted. Metric charts shall reflect trends over time and indicate whether performance is improving or degrading. When metric thresholds are exceeded, the Contractor shall immediately notify the Government, take appropriate corrective action, and present an action plan for recovery/mitigation. Metrics may include, but not be limited to, the following categories:

Cost/Funding status

Testing status

Software performance

System performance

Manpower staffing and retention

Help desk metrics

Interface failure rates

Interface account management status

Discrepancy reports, Problem reports, and resolution

Software quality and security scans showing trends over time

Line of Code…