OLMS_Performance Work Statement.pdf

U.S. Forest Service

Operational Loads Monitoring System Software and Services

Request for Information Draft Performance Work Statement

07/28/2026

Table of Contents

1. BACKGROUND

2. SCOPE OF WORK

2.1. Objective

2.2. Transition Planning and Execution

3. TECHNICAL REQUIREMENTS

3.1. Task 1: Software Licensing

3.2. Task 2: Software Maintenance and System Support

3.3. Task 3: Data and Analysis

3.4. Task 4: Hosting

3.5. Task 5: Multi-Factor Authentication (MFA)

4. DELIVERABLES

5. PERFORMANCE METRICS

5.1. Performance Metric 1: Uptime

5.2. Performance Metric 2: Help Desk Mean First Response Time

5.3. Performance Metric 3: Timely and Quality Deliverable Submission

6. LEVEL OF EFFORT

7. CONTRACTING OFFICER’S REPRESENTATIVE (COR)

8. INVOICING

9. INSPECTION AND ACCEPTANCE

10. PLACE, TIME, AND PERIOD OF PERFORMANCE

11. NON-PERSONAL SERVICES

12. FOREIGN NATIONALS

13. BACKGROUND INVESTIGATION

14. PERSONAL IDENTITY VERIFICATION

15. GOVERNMENT FURNISHED PROPERTY

16. DATA RIGHTS

16.1. Data Collected, Generated or Managed

16.2. Privacy Act

16.3. Confidentiality and Non-Disclosure

16.4. Sensitive Information Storage and Disclosure

16.5. Release of Information

16.6. Return of Data

17. SECURITY REQUIREMENTS

18. SECTION 508 – ACCESSIBILITY OF INFORMATION AND COMMUNICATIONS

TECHNOLOGY

18.1. Section 508 Compliance

19. TRAINING

20. SUPPLY CHAIN RISK MANAGEMENT

21. TRAVEL

List of Tables Table 1: Deliverables Table 2: Performance Metric 1 – Uptime Table 3: Performance Metric 2 – Help Desk Mean First Response Time Table 4: Performance Metric 3 – Timely and Quality Deliverable Submission Table 5: Security Requirements Table 6: Training Requirements

1. BACKGROUND

The United States Forest Service (USFS), established in 1905, is a United States federal Government agency within the United States Department of Agriculture (USDA) which is responsible for the stewardship of more than 193 million acres of National Forests and grasslands. Guided by its founding principle, “to provide the greatest amount of good for the greatest amount of people in the long run,” the agency’s mission is to sustain the health, diversity, and productivity of the nation’s forests and grasslands for present and future generations.

The mission of Fire and Aviation Management (FAM), Information Management (FAM-IM), a branch of the USFS, is to support the development, operations, maintenance, and user training of information technology (IT) systems used for wildland fire response. To meet this mission, USFS FAM-IM manages IT applications and web assets designed to support wildland fire operations and management including fire and aviation preparedness, fire detection and intelligence, fire incident response (initial and extended attack), fire resource planning and allocation, firefighter safety, public affairs information dissemination, and fire research and development. These applications and web assets are used nationwide by the interagency wildland fire community which comprises incident management personnel from the USFS, Department of the Interior (DOI), Department of Homeland Security – Federal Emergency Management Administration (DHS-FEMA), State Forestry Agencies (all 50 states) and U.S. territories, and Municipal Agencies.

2. SCOPE OF WORK

2.1. Objective

The intent of this action is for the USFS (also hereafter referred to as ‘Government’) to acquire and utilize commercially available software and system support services for the Operational Loads Monitoring System (OLMS). Following two catastrophic in-flight failures of heavy air tankers in 2002, the National Transportation Safety Board (NTSB) issued Recommendation A-04-29 stating that the USFS should “develop maintenance and inspection programs for aircraft that are used in firefighting operations that take into account and are based on the magnitude of maneuver loading and the level of turbulence in the firefighting environment and the effect of these factors on remaining operational life.” OLMS was developed to accomplish these objectives by enabling the USFS to identify the magnitude and frequency of maneuver loading and level of turbulence experienced by aircraft performing aerial firefighting missions.

OLMS is a web-based application used for the assessment and analysis of operational loads data, such as aircraft gross weight, wind gust loads, and maneuver loads, collected from air tankers during aerial firefighting missions. Currently, aircraft recorders collect the operational loads data in raw data files which are sent to a USFS FTP File Share site (known as FAMShare) and then copied and stored on the OLMS server in the Government’s hosting environment. OLMS then ingests and processes the data files located on its server, and https://www.fs.usda.gov/ https://www.usda.gov/ https://ftp.wildfire.gov/ stores the data in its database. However, this fie process may change depending on the solution proposed by the contractor, e.g., FedRAMP certified Software as Service (SaaS) solution. Finally, OLMS converts flight data to engineering units and enables data analysis and reporting.

The data collected in OLMS is used by the Government to analyze the impact of these loads on the structural health and service life of each aircraft, and to ensure that inspection intervals are appropriately set for aircraft operating in the challenging conditions of aerial firefighting. The data is available to the USFS as well as to university research partners and operators of the aircraft for their statistics and use. Aircraft operators utilize the data to determine needs for required individual aircraft structural health management. OLMS currently supports a user base of fewer than fifteen users, although this is subject to change.

2.2. Transition Planning and Execution

Transition In The contractor will support Transition In from the current incumbent for OLMS that ensures no degradation of system availability, security posture, and operational performance and functionality during the transition period. Transition In tasks will be treated and documented in an identical manner to all other requirements for OLMS application and software support. All Transition In activities shall be performed with the same quality, rigor, and responsiveness as any other work required under this contract.

The Transition In process shall include, at minimum:

• Coordination and planning, per a timeframe determined by the Government, with the incumbent, Government staff, and relevant stakeholders to ensure a smooth transition within the Government-approved schedule.

• Identification, capture, and validation of all operational and security specifications, processes, and documentation for full operational responsibility of OLMS and its database.

• Collection, formalization, and documentation of processes, procedures, and specifications including, but not limited to:

o System configurations and technical specifications o System diagrams and architecture and design artifacts/documentation o Software inventories, tools, utilities, licenses, and administrative records o Administrative accounts, permissions, and access requirements o Operational workflows and standard operating procedures (SOPs) o Maintenance schedules, patching cycles, and backup processes o Passwords, URLs, credentials, access information, service accounts, and system dependencies o Technology stack specifications

• Verification and establishment of access to OLMS including, but not limited to, administrative tools, monitoring systems, and communication channels.

• Knowledge transfer sessions with the incumbent, including shadowing, walkthroughs, and validation of operational readiness.

• Development and submission of a Transition In Plan, if not already provided, detailing timelines and timeframes, activities, responsible parties, milestones, risks, and mitigation strategies, for Government approval.

Transition Out In the event a successor contract to this contract is awarded to a different contractor, the contractor will fully support the Government in planning and executing a Transition Out to ensure continuity of operations and preservation of system knowledge of OLMS. Transition Out tasks will be treated and documented in an identical manner to all other requirements for OLMS application and software support t. All Transition Out activities shall be performed with the same quality, rigor, and responsiveness as any other work required under this contract.

The Transition Out process will include, at minimum:

• Coordination and planning, per a timeframe determined by the Government, with the successor, Government staff, and relevant stakeholders to ensure a smooth transition within the Government-approved schedule.

• Preparation and delivery of all documentation, artifacts, and system information required for the successor contractor or the Government to assume operational responsibility for OLMS and its database. This includes, but is not limited to:

o Technical specifications and system configurations o Architectural diagrams and design documentation o Software inventories, tools, utilities, licenses, and administrative records o Operational procedures, SOPs, and maintenance workflows o Security configurations, controls applied, and compliance documentation o Passwords, URLs, credentials, access information, service accounts, and system dependencies o Technology stack specifications

• Knowledge transfer and technical handoff sessions for Government personnel and the successor contractor.

• Support for Government-led transition planning, including participation in meetings, walkthroughs, and joint review sessions.

• Cooperation with the Government and successor contractor to ensure a seamless transition without disruption to OLMS availability, performance, and functionality for mission operations.

• Identification and mitigation of transition risks, with recommendations provided to the Government.

• Execution of a Transition Out Plan, created in coordination with the Government, and approved by the Government, outlining timelines and timeframe, resources, deliverables, and responsibilities.

3. TECHNICAL REQUIREMENTS

The requested commercial software solution and system support services for OLMS will contain a comprehensive set of standard and specialized tools for performing durability analysis and completing tasks, as requested, such as digital signal processing. The software will be able to handle large amounts of aircraft operational loads data and provide a graphical, process-oriented environment that includes leading analysis capabilities to assist aviation managers in quantifying and validating the structural impacts of loads on aircraft performing under certain environmental and performance criteria.

3.1. Task 1: Software Licensing

1. The contractor will provide all software licenses, including any third-party licenses, to ensure the operation, functionality, and availability of OLMS as described in this

PWS.

3.2. Task 2: Software Maintenance and System Support

The contractor will perform the following activities to ensure the continued support, maintenance, functionality, availability, and security of OLMS and its software.

1. Provide operations and maintenance support for the software solution provided for OLMS, including maintaining and performing all software updates as necessary to remediate security risks, vulnerabilities, and performance issues in accordance with federal government security requirements, standards, and protocols, throughout the life of the contract.

2. Maintain and support any configurations or patches to the software, including middleware, that is required by the application to maintain the operability and security of OLMS (examples: Apache, Tomcat, or PHP).

3. Ensure access to OLMS and the software is available 99% of time, excluding preplanned outages.

4. Provide user assistance instruction and self-help resources (e.g., user guides, training videos, etc.) for the software as requested by the Government.

5. Respond to and resolve issues/tickets escalated by users, Government staff, and other stakeholders that impact OLMS functionality, security, and availability.

6. Provide user account support including managing and configuring user accounts, roles, and group administration.

7. Provide customization and configuration changes related to the layout, presentation, navigation changes, and overall functionality of OLMS as needed by users.

8. Migrate the OLMS software to other hosting environments/platforms as mandated by the Government

3.3. Task 3: Data and Analysis

The contractor may be responsible for the following data management, administration, maintenance, and analysis activities throughout the life of the contract.

1. The OLMS database may comprise one of two options:

a. Option 1 – Government Database Solution: The Government uses

EnterpriseDB (EDB) PostgreSQL and Microsoft SQL Server 2019 on database clusters used by multiple FAM applications, at the time of writing. If the contractor chooses to use the Government’s database solution, the software solution provided by the contractor must be compatible with either EDB PostgreSQL or Microsoft SQL Server 2019. The Government’s database solutions are subject to change.

b. Option 2 – Containerized Database: In place of the Government’s database solution, the contractor may provide software with a containerized database as part of the software solution.

2. Support the Government’s database team to configure, set up, maintain, patch, update, and upgrade the OLMS database, as required, if using the Government’s database solution. Currently, the maintenance, patching, updating, and upgrading of most of the Government’s application databases is performed by the Government’s database team, but this is subject to change.

3. Migrate the OLMS database to other database solutions as mandated by the Government, if using the Government’s database solution.

4. Connect the OLMS software/database with the Government’s secure file management and collaboration platform, FAMShare. With role-based folder permissions, FAMShare enables users to securely upload, download, and manage files based on their assigned FAMAuth application role access settings. FAMShare ensures that sensitive data is only accessible to authorized personnel through these permission controls.

5. Configure the software provided for OLMS to retrieve, use, and analyze flight data collected from aircraft that is uploaded to the OLMS folder in FAMShare.

6. Configure OLMS to automate data processing, enable reporting, and deliver informational products in support of decision makers and users.

7. Assist with managing user accounts and group administration.

8. Develop data processes and flows to support needed meta data.

9. Convert collected flight data into engineering units.

10. Ensure the uploading of load data to the OLMS database or library specified by the

Government Product Manager of OLMS.

11. If requested, assist with analyzing the collected data to identify trends and patterns, help develop queries, reports, or flows.

12. Develop and provide reporting of collected data.

13. Process historical and current data received from the date of contract award through the entire life of the contract.

3.4. Task 4: Hosting

The software solution provided by the contractor must satisfy one of two hosting options:

1. Option 1 – Government Hosting: The contractor must permit the software solution to be installed and supported in the Government’s hosting environment which has the authority to operate. The current OLMS software is hosted in the Government’s Azure cloud environment (Azure-AVS). However, this hosting environment is subject to change. The contractor will work with the Government to ensure that the software solution is maintained, available, and secure in accordance with all federal government security requirements and standards, as well as required authentication changes.

a. The contractor is required to install, set up, test, and deploy the software and database in the Government’s hosting environment, in coordination with the Government’s host environment infrastructure team and host environment standard operating procedures (SOPs).

b. The contractor will work with the Government’s security, infrastructure, and product management teams to ensure that the installed software and database meet the security requirements for the host environment’s authority to operate (ATO) as well as all applicable Government security regulations, standards, and protocols.

c. Support the Government’s host environment infrastructure team, as needed, to migrate the software to other hosting environments as mandated by the Government.

2. Option 2 – Provider Cloud Hosting: The contractor may provide a SaaS solution that must be hosted and supported in a FedRAMP certified environment. The contractor will ensure that the SaaS solution is maintained, available, and secure in accordance with FedRAMP standards and policies.

3.5. Task 5: Multi-Factor Authentication (MFA)

The contractor must provide an MFA solution that satisfies one of two options:

1. Option 1 – Government MFA Integration: For software solutions hosted by the Government, the contractor must configure and integrate the software with the Government’s Multi-Factor Authentication (MFA) and authorization solution, FAM Authentication (FAMAuth). FAMAuth serves as the MFA portal for more than twenty Government fire and aviation client applications. Within FAMAuth, the FAMAuth Administration module (FAMAuth Admin) provides user authorization and role management for these applications as needed. The use of FAMAuth/FAMAuth Admin for MFA and user authorization for OLMS is subject to change.

a. The contractor will analyze, design, develop, test, release, and deploy FAMAuth/FAMAuth Admin integration with OLMS and its software.

b. Prior to deployment, the contractor will test user login and access to ensure that FAMAuth/FAMAuth Admin integration with OLMS is functional. The contractor will resolve any issues to ensure all users are able to successfully authenticate and access the OLMS application through FAMAuth/FAMAuth Admin.

c. The Government as a team dedicated to FAMAuth/FAMAuth Admin operations and support. This team will be available to provide technical support to the OLMS team during the FAMAuth/FAMAuth Admin integration effort as required.

https://www.fedramp.gov/ https://famauth.wildfire.gov/

d. The Government will provide a FAMAuth/FAMAuth Admin developer guide to support the integration effort as required.

2. Option 2 – Provider MFA: For SaaS solutions, the software must use an MFA and role-based account management solution for authentication, identity verification, and application access control that is authorized by the Government. If the contractor’s MFA solution does not meet Government standards, negotiations may take place for an agreed upon approved solution by both parties.

4. DELIVERABLES

The contractor will provide the deliverables described in Table 1. Deliverables with due dates are required. Deliverables without due dates may be requested by the Government during the life of the contract.

Table 1: Deliverables

Deliverable Name Deliverable Description Due Date (Draft

Deliverable)

1. Invoice Plan Invoice will include contract number Period of Performance (POP), Contract Line-Item Numbers (CLINS)/Team name(s)

Ten days after award and if updated

2. Monthly Status Reports

Monthly reports that include, but are not limited to:

• Accomplishments

• Explanations for uncompleted work

• Staffing status/changes

• Risk and issues

• Performance measurement status

• Relevant dashboards as needed

First report due 30 days after contract award.

Successive reports due by the fifth business day of each month.

3. Transition In Plan

See Section 2.2.

Within 30 days of award and if updated

4. Transition Out Plan

See Section 2.2.

30 days before the end of the contract or upon Government request

5. Quality Assurance Surveillance Plan (QASP)

The contractor will deliver a Quality Assurance Surveillance Plan (QASP) that fully supports Government oversight of contract performance.

The QASP must define the performance standards, metrics, monitoring techniques, and reporting procedures required to evaluate compliance with the PWS.

Within 10 days of award

6. Data Export Provide data export of historical and active data Upon Government request

7. Service Desk Operations Plan/Strategy

Service desk strategy/plan, which may include but is not limited to:

• Support levels/tiers

• Ticket/request escalation strategy

• Workflow prioritization strategy

• Defined incident severity levels

• On-call schedule and contacts

• Response (acknowledgement) timeframes

• Action (i.e., when work starts on a ticket) timeframes based on defined incident severity levels

Upon Government request

5. PERFORMANCE METRICS

The contractor will adhere to and report on the following performance metrics (PM) detailed in Tables 2-4:

• Table 2: Performance Metric 1 – Uptime

• Table 3: Performance Metric 2 – Help Desk Mean First Response Time

• Table 4: Performance Metric 3 – Timely and Quality Deliverable Submission

5.1. Performance Metric 1: Uptime

Table 2: Performance Metric 1 – Uptime

1. PERFORMANCE METRIC OVERVIEW

1.1. PM # One (1)

1.2. PM NAME System Uptime

1.3. PM

DESCRIPTION

Measures the extent to which OLMS is available 24/7/365, except for authorized downtime periods for maintenance and downtime periods caused by the hosting environment or external factors.

1.4. RATIONALE Incentivizes the contractor to ensure that the system is available when needed by users.

1.5. PRIMARY PWS

REFERENCE

Section 3.

1.6. PERFORMANCE

PERIOD

This PM is in effect 24/7/365 as described in Section 3 of this

PWS.

2. PERFORMANCE METRIC MEASUREMENT

2.1. METHOD OF

MEASUREMENT

Uptime is the percentage of time that OLMS (including its software and database) are up and running for users during the measurement interval.

2.2. MEASUREMENT

INTERVAL

One (1) calendar month.

2.3. MEASUREMENT

PERIOD

Period begins at 00:01 on the first day of the calendar month and ends at 24:00 on the last day of the calendar month.

2.4. MEASUREMENT

TIMING

PM is calculated after the end of the measurement period.

2.5. MEASUREMENT

DATA SOURCE

• OLMS monitoring information (e.g., system logs) and/or contractor monitoring system(s).

• Planned and unplanned outage documentation.

2.6. EXCEPTIONS • Planned downtime for maintenance, deployments, and releases of OLMS.

• Downtime due to hosting environment outages and factors outside the OLMS team’s control (e.g., network outages, etc.) are also excluded.

2.7. APPLICATION Applicable to OLMS (including its software and database) supported by this contract.

2.8. ASSUMPTIONS/

CONDITIONS

Outage is defined when OLMS is unavailable to users due to being offline or non-functional, for which the cause cannot be contributed to external factors outside the application or web asset team’s control.

3. PERFORMANCE METRIC CALCULATION

3.1. STANDARD OR

TARGET

System uptime is at or exceeds 99%.

3.2. SUCCESS

CRITERIA

OLMS is up and running and available to users at or exceeding the target listed in Section 3.1. of this table.

3.3. NUMERATOR Number of minutes of System Uptime during the measurement interval.

3.4. DENOMINATOR Number of minutes of System Uptime + System Downtime – Planned System Downtime during the same measurement interval.

4. PERFORMANCE METRIC REPORTING AND ADMINISTRATION

4.1. REPORTING

FREQUENCY

• Performance reporting to commence in the first monthly status report.

• Frequency: Monthly, as reported in each Monthly Status Report.

4.2. HOLD

HARMLESS PERIOD

Two (2) calendar months after contract award. Performance measurement begins on the second calendar month, and measurement reporting in the Monthly Status Report begins on the third calendar month, after contract award.

4.3. NOTES AND

COMMENTS

• The contractor’s performance against this metric will be documented and may be reflected in the Government’s rating of the contractor’s past performance in CPARS.

• The contractor’s reporting may reflect both the contractor’s meeting and exceeding these metrics as well as failing to meet them.

• The Government wishes to acknowledge superior performance a+++s well as unsatisfactory performance.

5.2. Performance Metric 2: Help Desk Mean First Response Time Table 3: Performance Metric 2 – Help Desk Mean First Response Time

1. PERFORMANCE METRIC OVERVIEW

1.1. PM # Two (2)

1.2. PM NAME Help Desk Mean First Response Time (FRT)

1.3. PM

DESCRIPTION

FRT is the average time before the contractor responds to help desk tickets elevated to them regarding OLMS outage and issues.

1.4. RATIONALE

Incentivizes the contractor to provide timely support and response to customer tickets to ensure that OLMS is available and functional as needed by users.

1.5. PRIMARY PWS

REFERENCE Section 3.

1.6. PERFORMANCE

PERIOD

This PM is in effect 24/7/365 as described in Section 3 of this

PWS.

2. PERFORMANCE METRIC MEASUREMENT

2.1. METHOD OF

MEASUREMENT

• Average time before the contractor responds to all tickets escalated to them over the measurement interval.

2.2. MEASUREMENT

INTERVAL One (1) calendar month.

2.3. MEASUREMENT

PERIOD

Period begins at 00:01 on the first day of the calendar month and ends at 24:00 on the last day of the calendar month.

2.4. MEASUREMENT

TIMING PM is calculated after the end of the measurement period.

2.5. MEASUREMENT

DATA SOURCE Contractor’s monitoring or tracking system(s).

2.6. EXCEPTIONS N/A

2.7. APPLICATION Applicable to OLMS.

2.8. ASSUMPTIONS/

CONDITIONS

• Help Desk tickets and responses are typically communicated by email and phone. However, the contractor may choose to employ a different communication protocol/ticketing system with Government approval, as long as it’s documented.

• FRT does not include when action or work starts on a ticket.

The latter will depend on the ticket severity level and workflow prioritization strategy developed by the contractor and approved by the Government (e.g., work on low severity tickets may start days from when the ticket is first escalated to the contractor).

3. PERFORMANCE METRIC CALCULATION

3.1. STANDARD OR

TARGET

No later than 24 hours after ticket escalation or communication to the contractor.

3.2. SUCCESS

CRITERIA

There is documented acceptance of the ticket by the contractor within the target timeframes listed in Section 3.1. of this table.

3.3. NUMERATOR Total number of minutes before the contractor responds to all escalated tickets during the measurement interval.

3.4. DENOMINATOR Total number of tickets received during the same measurement interval as the numerator.

4. PERFORMANCE METRIC REPORTING AND ADMINISTRATION

4.1. REPORTING

FREQUENCY

• Performance reporting to commence in the first Monthly Status Report.

• Frequency: Monthly, as reported in each Monthly Status Report.

• Reporting should include a summary of the total tickets received by the contractor and their FRTs over the measurement interval.

4.2. HOLD

HARMLESS PERIOD

Two (2) calendar months after contract award. Performance measurement begins on the second calendar month, and measurement reporting in the Monthly Status Report begins on the third calendar month, after contract award.

4.3. NOTES AND

COMMENTS

• The contractor’s performance against this metric will be documented and may be reflected in the Government’s rating of the contractor’s past performance in CPARS.

• The contractor’s reporting may reflect both the contractor’s meeting and exceeding these metrics as well as failing to meet them.

performance as well as unsatisfactory performance.

5.3. Performance Metric 3: Timely and Quality Deliverable Submission Table 4: Performance Metric 3 – Timely and Quality Deliverable Submission

1. PERFORMANCE METRIC OVERVIEW

1.1. PM # Three (3)

1.2. PM NAME Timely and Quality Deliverable Submission

1.3. PM DESCRIPTION

Measures compliance with deliverable due dates and quality standards as described in Section 4 and Section 9 of this PWS.

1.4. RATIONALE Incentivizes the contractor to stay in compliance with deliverable requirements as described in this PWS.

1.5. PRIMARY PWS

REFERENCE Section 4 and Section 9.

1.6. PERFORMANCE

PERIOD

This PM is in effect 24/7/365 as described in Section 4 and Section 9 of this PWS.

2. PERFORMANCE METRIC MEASUREMENT

2.1. METHOD OF

MEASUREMENT

Timely delivery of deliverables to the COR, and the COR’s review and acceptance of deliverables.

2.2. MEASUREMENT

INTERVAL

Per deliverable required by the Government. See Section 4.

2.3. MEASUREMENT

PERIOD

Per deliverable required by the Government. See Section 4.

2.4. MEASUREMENT

TIMING

Per deliverable required by the Government. See Section 4.

2.5. MEASUREMENT

DATA SOURCE COR.

2.6. EXCEPTIONS None.

2.7. APPLICATION Applicable to all deliverables described in this PWS.

2.8. ASSUMPTIONS/

CONDITIONS None.

3. PERFORMANCE METRIC CALCULATION

3.1. STANDARD OR

TARGET Deliverable due dates. See Section 4.

3.2. SUCCESS

CRITERIA

Deliverable due dates are met by the contractor as detailed in Section 4 of this PWS.

3.3. NUMERATOR None.

3.4. DENOMINATOR None.

4. PERFORMANCE METRIC REPORTING AND ADMINISTRATION

4.1. REPORTING

FREQUENCY

• As required when deliverables are due. See Section 4 of the PWS for deliverable due dates.

• Communications should document contractor submission of deliverable and Government/COR receipt of deliverable.

4.2. HOLD HARMLESS

PERIOD

Period before first deliverable is due after contract award.

See Section 4.

4.3. NOTES AND

COMMENTS

• The contractor’s performance against this metric will be documented and may be reflected in the Government’s rating of the contractor’s past performance in CPARS.

• The contractor’s reporting may reflect both the contractor’s meeting and exceeding these metrics as well as failing to meet them.

performance as well as unsatisfactory performance.

6. LEVEL OF EFFORT

The contractor is requested to propose the level of effort and labor categor(ies) necessary to install, configure, maintain, support, and integrate the OLMS software and database based on the technical requirements previously outlined in this PWS.

7. CONTRACTING OFFICER’S REPRESENTATIVE (COR)

The COR monitors all technical aspects of the contract and assists in contract administration. The COR is authorized to perform the following functions: assure that the contractor performs the technical requirements of the contract: perform inspections necessary in connection with contract performance: maintain written and oral communications with the contractor concerning technical aspects of the contract: issue written interpretations of technical requirements to the Contracting Officer, including Government drawings, designs, specifications: monitor contractor's performance and notifies both the Contracting Officer and contractor of any deficiencies; coordinate availability of government furnished property, and provide site entry of contractor personnel. A letter of designation issued to the COR, a copy of which is sent to the contractor, states the responsibilities and limitations of the COR, especially with regard to changes in cost or price, estimates or changes in delivery dates. The COR is not authorized to change any of the terms and conditions of the resulting contract or order.

8. INVOICING

Invoices will be submitted electronically through the Department of Treasury’s Invoice Processing Platform (IPP). The contractor will follow Government provided IPP instructions on how to register and submit invoices via IPP as prescribed at the IPP website https://www.ipp.gov. Additional Information regarding what constitutes a proper invoice can be found by reviewing the Prompt Payment Act (31 USC Chapter 32 - Prompt Payment Act).

The contractor will adhere to the following invoice requirements:

Provide a complete contractor-generated invoice electronically, as an attachment via IPP.

• Submit monthly reports and any other information or documentation required by other clauses of the award to support the invoice.

• Maintain original receipts and make them available to Government auditors upon request.

• Comply with the Government’s invoicing period, which runs from the first through the last day of the month of the calendar.

• Invoice the Government in arrears for every month services are provided by the 15th day of the following month. All invoices will be rendered based on calendar month cycles.

• Proration: When applicable, monthly charges will be prorated by the number of days the service was performed divided by the number of days in that month.

• Rounding: all charges will be rounded to two (2) decimal places.

• Submit information and a PDF invoice per the CO and/or COR’s requirement. The total(s) in the invoices must match IPP totals for reconciliation between IPP, invoice data feed, and contract operational data.

https://www.ipp.gov/ o Monthly report will be submitted with the invoice or coordinated and sent directly to the COR and PM at the same time as the invoice is submitted.

9. INSPECTION AND ACCEPTANCE

Inspection and acceptance of all work performance, reports, and other deliverables under this PWS will be performed by the Contracting Officer/Contracting Officer Representative/Government Program Manager.

All deliverables will be inspected for content, completeness, accuracy, and conformance to contract requirements by the Contracting Officer/COR and the Program Manager (PM).

Inspection may include validation of information or deliverables (e.g., reports) through the use of automated tools, testing, or inspections of the deliverables, as specified in the Contract. The scope and nature of this inspection will be sufficiently comprehensive to ensure the completeness, quality, and adequacy of all deliverables.

In the context of application development specifically, inspection and acceptance will largely occur through the iterative application development process and the government inspection of software features and other products developed within the sprints and demonstrated at the end of these sprints. These outputs will be evaluated for consistency with acceptance criteria defined during the work prioritization process. The Government may elect to reflect the contractor’s performance against these expectations during the past performance reporting process.

10. PLACE, TIME, AND PERIOD OF PERFORMANCE

Place of Performance The anticipated place of performance will be at the contractor site(s) and the sites identified by the COR.

Time of Performance The time of performance of this PWS is as follows:

• Standard Business Hours for this contract are 8:00 Mountain Time to 17:00 Mountain Time, Monday through Friday, excluding federal holidays.

• The contractor’s schedule must be designed for the preponderance of the team’s working hours to fit within the Standard Business Hours.

• Support may be needed outside of Standard Business Hours (including nights, weekends, and Federal holidays) for (a) after-hours release and deployment activities; (b) execution of emergency and critical patches; (c) troubleshooting and remediation of situations where OLMS is unavailable; and other similar high-priority events.

• The team will agree to set meeting times with consideration for different time zones but ultimately with the Government’s decision.

Additionally, Government personnel and potentially facilities may not be available during federal holidays. Federal holidays can be found via OPM’s website at https://www.opm.gov/policy-data-oversight/pay-leave/federal-holidays/#url=Overview

Period of Performance The Government’s intent is to award a base period plus up to four options periods (period = one year) during the life of the contract.

11. NON-PERSONAL SERVICES

The Government will neither supervise contractor personnel nor control the method by which the contractor performs the required tasks. It will be the responsibility of the contractor to manage its employees and to guard against any actions that are of the nature of personal services or give the perception of personal services. If the contractor believes that any actions constitute, or are perceived to constitute personal services, it will be the contractor’s responsibility to notify the Contracting Officer/COR immediately.

12. FOREIGN NATIONALS

In accordance with Executive Order 11935, Citizen Requirements, it is the policy of the U.S.

Federal Government to employ only U.S. citizens or persons owing permanent allegiance to the U.S. Under 5 CFR 213.3102.31(bb), a non-citizen may be hired in the absence of a qualified citizen when authorized by the Office of Personnel Management (OPM). §7.3(c) grants OPM the authority, as an exception to this rule and to the extent permitted by law, to authorize the appointment of noncitizens to positions in the competitive service when necessary to promote the efficiency of the service in specific cases or for temporary appointments.

Federal employees, contractors, subcontractors, experts, consultants, and paid/unpaid interns hired for work within the U.S. or its territories who require access to USDA mission areas, agencies, and staff offices, or to controlled facilities, IT systems, security items, or products, must be either U.S. citizens or lawful permanent residents, also known as “green card” holders. All contractors assigned to this contract may be performed by a U.S. Citizen or lawful permanent resident alien with at least three (3) or more years of U.S. residency from the date of legal entry to the U.S.

This policy applies to all federal contractor positions with the USDA in the continental U.S.

This policy does not apply to non-U.S. citizens who are:

• A citizen of another country and the U.S. at the same time (dual U.S. citizenship or dual U.S. nationality)

• Employed by a federal contract on a temporary H-1B (Specialty Occupation) visa in accordance with immigration laws.

https://www.opm.gov/policy-data-oversight/pay-leave/federal-holidays/#url=Overview

13. BACKGROUND INVESTIGATION

The USDA/USFS is required under the Homeland Security Presidential Directive (HSPD) 12 “Policy for a Common Identification Standard for Federal Employees and Contractors” to perform a National Agency Check with Inquiries (NACI) for contractors. For more information, please go to: USDA HSPD-12 Information. The USFS uses Defense Counterintelligence and Security Agency (DCSA) National Background Investigation Services (NBIS) for processing and managing background investigations.

All contract personnel who require onboarding for access to Government systems, and who require USFS credentials, must pass the Federal Bureau of Investigation (FBI) criminal history check. A current and successful clearance is required for all contractor personnel to work under this contract. All contractors on this contract will be required to pass a tier 2 level background investigation. Tier 2, formerly MBI or level 5B, is a public trust position that may be performed by a United States (U.S.) citizen or lawful permanent resident with at least three (3) or more years of U.S. residency from the date of legal entry to the U.S. This investigation will be conducted for contractor personnel assigned to this contract. The CO/COR, or other designated program/project officers, in conjunction with USFS HCM HSPD-12 staff, will assist the contractor in processing the required security background investigations/clearances. The contractor employee will provide two (2) forms of acceptable identification, a current photograph, and be fingerprinted. At this time, the Government will pay for, and process, all required security investigations/clearances, except as identified differently.

The contractor should be aware of any of its employees possibly having had a background investigation through another Government agency. The investigation that was conducted, if verifiable by the USFS HSPD-12 staff, and if it was completed within the last five (5) years, can be accepted by the Government in lieu of a background check.

The contractor will also ensure compliance with applicable security regulations and operations requirements for facility access and handling of information and materials.

USDA USFS data and work environment are considered sensitive but unclassified. All non- Government employees with unescorted access to USFS facilities, computer systems, and/or USFS information must have background investigations commensurate with the level of risk and magnitude of loss or harm.

14. PERSONAL IDENTITY VERIFICATION

The contractor will be responsible for ensuring compliance by its employees with all applicable U.S. federal regulations, including those of the General Services Administration (GSA), National Institute of Standards and Technology (NIST), USDA, USFS and HSPD-12.

Contractors and their employees are subject to all U.S. federal laws applicable to https://www.dhs.gov/homeland-security-presidential-directive-12

Government installations and are under the jurisdiction of the Federal Protective Service

(FPS).

Performance of this contract will require access to the USFS network, and contract personnel will be required to have USFS network access. Contractors will follow the “Person Model” process to obtain a USDA Personal Identity Verification (PIV) card also known as LincPass. Allowance of six (6) to eight (8) weeks should be anticipated for activation of a LincPass.

The USDA PIV card sponsor for this contract is the USFS FAM-IM Program Specialist, at the time of writing. The USDA PIV card sponsor will be available to receive contractor identity information from 08:00 MT to 16:00 MT, Monday through Friday. The Program Specialist and/or the Program Manager will reach out to the contractor Program Manager upon award of this contract to initiate onboarding of all team members. The Government will notify the contractor if there is a change in the USDA PIV card sponsor, office address, or office hours for registration.

The contractor and all contractor personnel assigned to this contract will adhere to the following requirements to obtain, receive, and use a USDA PIV card:

• Complete all required training including Information Security Awareness (ISA) training, Role Based Security Training (RBST), and any other assigned training prior to being given access to USFS systems and periodically thereafter as required by USFS security policies.

• Comply with USDA PIV card policies and procedures established by USDA Directives 3800 series. Should the results of the PIV card process require the exclusion of a contractor’s employee, the Contracting Officer will notify the contractor in writing.

• Appoint a contractor representative to manage this activity and to maintain a list of employees eligible for a USDA PIV card required for performance of the work.

• Ensure that each of the contractor’s employees has been issued either a temporary or permanent PIV card from the Government. A permanent PIV card will not be issued until the security questionnaire has been completed and favorably reviewed.

Temporary or visitor PIV cards will be provided for persons who are identified as having an infrequent or temporary legitimate business need for access to a site. As noted above, periods that exceed 180 days will require a permanent PIV card.

• Ensure the safekeeping, wearing, and visibility of Government-furnished PIV cards and badges.

• Comply with any PIV card requirements for the issuance of building access, facility badges, etc.

• Ensure that all subcontracts and subcontractors who are required to have access to a federally controlled information system or facility stipulate compliance with PIV card and facility badge requirements as listed in this PWS.

The responsibility for maintaining a sufficient workforce remains with the contractor.

Employees may be barred by the Government from performance of the work should they be found ineligible, or to have lost eligibility, for a USDA PIV card. Failure to maintain a sufficient workforce of employees eligible for a USDA PIV card may be grounds for termination of the contract.

All contractor personnel assigned to this contract will immediately return all PIV cards, badges, and permits to the Government when such a need to use the item ceases to exist.

The contractor will take immediate possession of terminated personnel’s PIV card and will close or restrict access to all USDA or USFS accounts upon termination of their employment. The PIV card of terminated or separated personnel will be returned to the Government within three (3) business days.

15. GOVERNMENT FURNISHED PROPERTY

The Government will provide Government furnished property to the contractor for use in the performance of work. This property must be used and maintained by the contractor in accordance with the provisions of the “Government Furnished Property”, Contract Clause, 52.245-4 incorporated into this award instrument.

The following items will be furnished by the Government for use by contractor personnel during the execution of this PWS:

• Government furnished equipment (GFE), such as personal laptops, required for any staff requiring network access.

• Access to USDA/USFS buildings during standard business hours and after standard business hours for emergency work. Badges for facility access must be worn or with the contractor employee at all times while in the facility and must be displayed above the waist. The individual will retain possession of the badge as long as continued admittance to the facility is needed. The contractor will comply with any facility security requirements for access to USDA/USFS facilities, and with all applicable rules governing parking at USDA/USFS locations.

• Access to necessary systems (hosting environment, etc.) and administrative accounts.

• Access to Government approved tools and technologies.

• List of Government approved software as necessary.

The contractor must return the Government-issued property at the end of the period of performance of this award instrument in accordance with instructions provided by the

COR.

16. DATA RIGHTS

16.1. Data Collected, Generated or Managed

The contractor will be responsible for properly protecting all information used, gathered, or developed as a result of work under this task. The contractor will also protect all unclassified Government data, equipment, etc., by treating information as sensitive business, confidential information, controlling and limiting access to the information, and ensuring the data and equipment are secured within their facility.

To the extent required to carry out a program of inspection to safeguard against threats and hazards to the security, integrity, and confidentiality of Government data, the contractor will afford the Government access to the contractor's or other external organization’s facilities, installations, technical capabilities, operations, documentation, records, and databases. The contractor will cooperate with federal agencies and their officially credentialed representatives during official inspections or investigations concerning the protection of USDA information.

Cooperation may include providing relevant documentation showing proof of compliance with federal and agency requirements, and rendering other assistance as deemed necessary.

16.2. Privacy Act

The contractor agrees to:

• Comply with the Privacy Act of 1974 (the Act) and the agency rules and regulations issued under the Act in the design, development, or operation of any system of records on individuals to accomplish an agency function when the contract specifically identifies:

o The systems of records; and o The design, development, or operation work that the contractor is to perform;

• Include the Privacy Act notification contained in this contract in every solicitation and resulting subcontract and in every subcontract awarded without a solicitation, when the work statement in the proposed subcontract requires the redesign, development, or operation of a system of records on individuals that is subject to the Act; and

• Include this clause, including this paragraph, in all subcontracts awarded under this contract, which requires the design, development, or operation of such a system of records.

• In the event of violations of the Act, a civil action may be brought against the agency involved when the violation concerns the design, development, or operation of a system of records on individuals to accomplish an agency function, and criminal penalties may be imposed upon the officers or employees of the agency when the violation concerns the operation of a system of records on individuals to accomplish an agency function. For purposes of the Act, when the contract is for the operation of a system of records on individuals to accomplish an agency function, the contractor is considered to be an employee of the agency.

• Definitions of the clause:

o “Operation of a system of records,” as used in this clause, means performance of any of the activities associated with maintaining the system of records, including the collection, use, and dissemination of records.

o “Record,” as used in this clause, means any item, collection, or grouping of information about an individual that is maintained by an agency, including, but not limited to, education, financial transactions, medical history, and criminal or employment history and that contains the person’s name, or the identifying number, symbol, or other identifying particular assigned to the individual, such as a fingerprint or voiceprint or a photograph.

16.3. Confidentiality and Non-Disclosure

Any USDA proprietary information, data, and/or equipment that the contractor has been granted access by USDA to perform work under this order, will be returned to the USDA when no longer required to perform work under this order. The public release of USDA proprietary information must be authorized in writing by the Contracting Officer.

The component parts of this effort and reports are expected to contain highly sensitive information that may act as a guide for hostile entities to cause harm to the Department’s critical infrastructure. Any such information made available in any format will be used only for the purpose of carrying out the provisions of this agreement. Such information will not be divulged or made known in any manner to any person.

The contractor will immediately notify the contractor Program Manager, the contractor on-site…