ITS4US Deployment Accelerator 693JJ3-27-BAA-0001

Attachment 2 – Performance Work Statement

ITS Joint Program Office (ITS JPO)

693JJ3-27-BAA-0001

Attachment 2

Performance Work Statement (PWS)

For

ITS4US Deployment Accelerator

1.0 Overview

This is a non-personal services contract to adapt and implement open-source transportation software for medical transportation, publish changes and extensions of the software as open-source code on the

Intelligent Transportation System (ITS) CodeHub, and document effectiveness of support and artifacts provided by USDOT. The Government will not exercise any supervision or control over the contract service providers performing the services herein. Such service providers shall be accountable solely to the Contractor who, in turn is responsible to the Government as defined in this Performance Work

Statement (PWS). The Contractor shall perform to the standards herein.

1.1 Background

The United States Department of Transportation (USDOT)’s Multimodal ITS Technology Research

Program improves transportation safety, mobility, efficiency, and enhances productivity through the integration of innovative technologies into the nation’s transportation system. All Americans need access to high-quality, affordable, safe, frequent, and accessible transportation options to access employment opportunities, educational opportunities, healthcare services, and other activities.

USDOT’s portfolio of transportation initiatives has delivered large-scale ITS deployment programs, including the ITS4US Deployment Program, the V2X Accelerator, and the Connected Vehicle

Deployment Pilot program, all led by the ITS Joint Program Office (ITS JPO) in collaboration with other

USDOT modal offices including the Federal Transit Agency (FTA), Office of the Secretary of

Transportation (OST), and the Federal Highway Administration (FHWA). These programs develop, test, and deploy mature and emerging transportation technologies to operate at full-scale in real-world settings.

These successful deployments also serve as replicable models that others can use to solve similar transportation challenges in their own localities more rapidly, and at lower cost and risk.

The USDOT has historically focused efforts to encourage replication of deployment successes on public outreach and publishing documentation, data, and code developed by the projects. Now, USDOT is looking to more proactively encourage replication and deployment through activities such as the cohorts program, which established a collaborative environment for vehicle-to-everything (V2X) deployers.

However, engaging with various localities in different stages of the project/deployment life-cycle constrains the ability to expedite follow-on deployment.

Aligned with USDOT’s priority of advancing innovation, the ITS JPO, in coordination with FTA, created the ITS4US Deployment Accelerator Program, an innovative approach to scaling successful technology deployments through peer knowledge sharing, technical expertise from current deployers, and seed funding support. This new initiative will enable new deployers to build faster, better, and cheaper by launching related efforts together, and use the insight of peers who have recently succeeded in addressing similar challenges. This Program targets follow-on deployments following the successful path charted by

ITS4US program sites.1

This effort seeks to conduct concurrent operational deployments to test integrated technology solutions designed to improve healthcare accessibility based on the successes of the ITS4US Heart of Iowa

Regional Transit Agency (HIRTA) Health Connector deployment.2

The primary goal of the Health Connector deployment was to better integrate transportation access with healthcare appointments to improve health outcomes, deliver more efficient transportation management for healthcare transportation, and provide greater financial stability of healthcare transportation programs.

A major innovation produced by the Health Connector project was first-in-the-nation open-source

1 Learn more about the ITS4US Program and its four deployment sites at: https://its.dot.gov/research-areas/ITS4US/.

2 https://www.its.dot.gov/research-areas/ITS4US/deployments/iowa/ https://its.dot.gov/research-areas/ITS4US/ https://www.its.dot.gov/research-areas/ITS4US/deployments/iowa/ middleware that connected transportation scheduling software with electronic health records software.

Some benefits that the Health Connector deployment is seeing and anticipating are:

• Streamlined transit booking process for riders by coupling with appointment booking.

• Reduced administrative burden for transit agency requesting trip reimbursements.

• Healthcare staff can focus on booking trips for transit-dependent patients at risk of missing appointments.

• Finally, for scalability, middleware can expand, with minimal customization, to additional transit software vendors, health record vendors, and Medicaid brokers.

The Health Connector project developed three open-source software components that the Government seeks to replicate and expand through the ITS4US Deployment Accelerator awards:

• MOD-EHR3: The MOD-EHR middleware bridges the gap between the Mobility on Demand

Platform (MOD) system (sometimes referred to as demand response scheduling software) used by the transit agency and the Electronic Health Record (EHR) software used by the medical facility, hospital, or other organization. The purpose of this middleware is not to move clinical data. It focuses only on limited appointment-related information that is necessary to coordinate transportation. That includes things like appointment timing, status changes, and when an appointment has ended or is running late. This web application allows HIRTA and healthcare staff to track the status of transportation to and from medical appointments. Staff can see whether the transportation is confirmed, not confirmed, or declared as not needed by the patient. This allows staff to focus on ensuring that the upcoming appointments without confirmed transportation bookings are prioritized to reduce missed appointments. By sharing this information securely, transit staff and healthcare staff have better visibility into what is happening in real time, which helps with scheduling trips to an appointment, coordinating return trips, and making same day adjustments. This reduces the need for phone calls and manual follow-up, and it helps avoid situations where riders are waiting too long or vehicles arrive too early.

• MOD-Medicaid4: The MOD-Medicaid middleware connects the mobility platform with

Medicaid transportation brokerage workflows, allowing trip authorization and trip status information to move more efficiently between systems. This helps reduce duplicate data entry and manual reconciliation, which often happens when trips are scheduled in one system and reported in another. With better visibility into trip assignments and completions, staff will spend less time tracking down information and more time focusing on service delivery. It also helps ensure that

Medicaid funded trips are coordinated more smoothly with non-Medicaid trips, which is especially important in shared ride and demand response environments. Overall, this integration supports more reliable service while reducing administrative burden.

• HC-Kiosk5: This open-source software is a web application that allows HIRTA riders to book rides and track their ride status directly from a physical kiosk. The physical kiosk is located in the hospital so patients can request a real-time return trip or book a future trip while they wait.

1.2 Objective

The objectives of this contract are to: (1) implement and adapt the Health Connector middleware using

USDOT-provided resources in order to provide feedback on the effectiveness of support and artifacts provided by USDOT that can inform future ITS deployment programs; (2) demonstrate the ability of the

3 https://github.com/HIRTA-HC/MOD-EHR 4 https://github.com/HIRTA-HC/MOD-Medicaid 5 https://github.com/HIRTA-HC/HC-Kiosk https://github.com/HIRTA-HC/MOD-EHR https://github.com/HIRTA-HC/MOD-Medicaid https://github.com/HIRTA-HC/HC-Kiosk transportation industry to leverage and expand open-source code on the ITS CodeHub to accelerate replication of successful ITS deployment components.

1.3 Detailed Requirement

The Contractor shall provide all personnel, equipment, supplies, facilities, transportation, tools, materials, supervision, and other items and non-personal services necessary to perform the work described in the following tasks:

• Task 1: Project Management

• Task 2: Project Concept and Development

• Task 3: System Demonstration

• Task 4: Project Assessment

NOTE: The Contracting Officer’s Representative (COR) will supply supporting materials and technical assistance to the Contractor to perform the work. Technical assistance includes templates for deliverables, examples of these deliverables from other deployments (where available), and establishing a cohort of awardees to provide technical and peer support throughout the performance.

NOTE: All final reports under this contract will be made publicly available. All publications resulting from this program shall follow the current USDOT Public Access Plan6 and ITS JPO Publication

Editorial Guidelines.7 In addition, code and data produced through these efforts are expected to be made widely available where appropriate. See Section 1.3.2 for more information.

1.3.1 Task 1: Project Management

This task shall extend over the entire period of performance.

The Government expects to make up to five awards in response to this solicitation (collectively described henceforth as “awardee cohort”). The awardee cohort is anticipated to execute project tasks on roughly the same schedule to encourage collaboration between awardee cohort members throughout the period of performance. Participation in cohort activities is optional but encouraged. The Government estimates that cohort meetings will be one to two hours in length and there will roughly be 12 meetings held over the period of performance. A description of technical support services and materials provided by the

Government are included in Sections 4.1 and 4.3.

Task 1.A: Kickoff Meeting

The Contractor shall attend a kick-off meeting to be held via virtual meeting with the CO, COR, and its representatives to ensure that all parties have a common understanding of the government’s requirements and expectations. The Contractor shall develop a brief slide deck with contract information and next steps. At a minimum, all Key Personnel must attend this meeting, and the COR will arrange the virtual meeting platform, the agenda, and the list of other (non-Contractor) attendees. This Kick-Off meeting shall occur no later than 15 business days after contract award.

Task 1.B: Monthly Reports

The Contractor shall provide a monthly report that documents accomplishments during the reporting period and planned activities in the next reporting period by task, a project schedule and risk registry.

Monthly reports shall be submitted no later than the 15th of the month following the reporting period. The

6 United States. Department of Transportation. (2022) DOT Public Access [Home Page].

https://ntl.bts.gov/ntl/public-access 7 https://its.dot.gov/news-info/Publication-Editorial-Guidelines/ https://its.dot.gov/news-info/Publication-Editorial-Guidelines/

Contractor shall also provide a table in the monthly progress report that identifies all deliverables, deliverable status (not initiated, in progress, draft delivered, in revision, final delivered, accepted), due dates (per the contract deliverable schedule. See Exhibit 2.), estimated delivery dates, and, if invoiced for payment, the date of the submitted invoice. The Government can provide a template on request.

The Contractor may use outputs of their chosen software development/project tracking software to reduce the administrative burden of developing the monthly report. If outputs are used in lieu of narrative descriptions, the COR must approve a draft report prior to the submission of the first report to confirm that the report satisfies all monthly reporting requirements.

Task 1.C: Cohort Meetings

The government will establish a cohort of awardees to provide technical and peer support throughout the performance. This cohort creates a peer-based forum designed to:

• Share insights, challenges, and solutions in real time;

• Decrease deployment risk and reduce implementation failures; and

• Facilitate continuous improvement of the technical approach developed by the original deployer.

Cohort meetings led by USDOT and the technical assistance team will be available to the Contractor throughout the deployment period. Participation in these meetings is optional. The purpose of cohort meetings is to discuss a variety of implementation topics such as:

• Software Integration – Technical implementation strategies, system integration approaches, and software configuration best practices;

• Transit/Healthcare Partnership Building – How to strengthen and reinforce relationships and grow partnerships with additional organizations; and

• Transit Rider Marketing/Recruitment – Strategies for outreach, engagement, and enrollment of target populations.

1.3.2 Task 2: Project Concept and Development

The purpose of this task is to develop a refined deployment concept, based on the Concept of Operations

(ConOps) 8 for HIRTA’s Health Connector deployment and tailored as needed to the specific project.

Among other elements, the Operational Concept Plan shall define the systems that will be integrated, relevant vendors and project partners, use cases, and system requirements.

The Contractor shall follow accepted systems engineering practices. The USDOT recognizes the practical value of well-defined software development approaches (e.g., Agile, Waterfall) in keeping solutions focused on user needs, reducing the risk of failure, and enabling the ability to test and deploy new features easily. To develop resilient, flexible deployments, the Contractor shall identify the development practices they will use, and the structure of the Operational Concept Plan is informed by the same priorities.

Task 2.A: Operational Concept Plan

The Contractor shall follow the template, provided by the Government, to describe the proposed deployment. The template will identify mandatory information to cover within the Operational Concept

Plan and provide instructions for the Contractor to customize the document according to the specifics of the proposed deployment. With the COR’s approval, the Contractor may reorganize or extend the base provided by the template to include additional information or context. The Contractor may use content

8 FHWA-JPO-21-859; https://rosap.ntl.bts.gov/view/dot/90796 https://rosap.ntl.bts.gov/view/dot/90796 from reports9 developed by the HIRTA Health Connector project, including their ConOps, to expedite the development of this Plan.

The Operational Concept Plan will include, at a minimum, the following items (or their equivalent in their chosen incremental development approach):

• User Needs and System Requirements. The Operational Concept Plan shall identify user needs and associated system requirements following the structure of their chosen development approach. For example, if a team is using Agile, the Operational Concept Plan should include a set of user personas and associated user stories. In that case, relevant user personas for a deployment could include a dispatcher, who needs to be able to schedule vehicles and operators; a traveler, who needs to attend medical appointments; and a healthcare provider, who needs to ensure that communications with patients are confidential and secure. Then the user personas are used to frame user stories, which are individual system features considered from a functional, end-user perspective. User needs and system requirements should represent discrete elements of functionality and include both a goal and a rationale to support prioritization.

• Product Backlog. The Operational Concept Plan shall identify deployment needs and features through a preliminary product backlog. A product backlog is an itemized, prioritized list of development tasks that will collectively comprise the proposed deployment. The product backlog of tasks may be reprioritized over the course of the project and is a living document. The

Operational Concept Plan should include development tasks organized in a preliminary product backlog, organized in logical and deployable features, prioritized by importance to the overall functioning of the proposed deployment.

• Development Milestone Schedule. The Operational Concept Plan shall include a schedule of the expected development milestones for the project and the associated development tasks that will be completed prior to the release. Development milestones are defined as completion of a selected piece of major functionality that meets a defined user need and system requirement. The development milestone schedule allows for a quick review of the project status and can help identify risks that require mitigation to successfully complete the development effort on time.

• Code Sharing.10 All source code and code documentation, including documentation of the code, test datasets, and any other data or artifacts needed to independently modify, test, and execute the software developed through Federal funding shall be shared with the USDOT and the community.

Existing applications brought to the deployment need not be made open-source; however, new interfaces and any enhancements are required to be open-source. Open-source software and supporting documentation shall be clearly identified within the Plan. The Contractor shall identify all open-source components and the processes used to manage, version, and publish them to a

USDOT public-facing repository. Providing all identified open-source code/software and supporting documentation is a required deliverable for Task 2.

• Performance Measures. The Operational Concept Plan shall identify a set of performance measures that will assess whether the deployment met its objectives to improve access to healthcare through integration of transportation. The Government anticipates this to be 5-10 performance measures where the Contractor can capture adequate “before” data and “after” data to assess success. The Government recommends that at least 60% of performance metrics be

9 ITS4US Documentation; https://www.its.dot.gov/research-areas/ITS4US/documents/ 10 Learn more at: https://www.its.dot.gov/code/about https://www.its.dot.gov/research-areas/ITS4US/documents/ https://www.its.dot.gov/code/about passively obtained from registered users, reducing dependence on survey responses or manual user submissions.

• Gap Analysis. The Operational Concept Plan shall identify any gaps between the existing HIRTA

Health Connector project and this planned development effort. Gaps could include the development of new features, refactoring code to improve system performance, or removing features that are not relevant to the planned system.

Task 2.B: Software Development

Once the COR approves the Operational Concept Plan deliverable, the Contractor shall begin executing the Plan. The Contractor shall develop the enhancements to the Health Connector middleware as one or more forks of the most recently updated repository. The Contractor shall develop necessary artifacts, code, and tests needed to later make their production branches available to the public as open-source software.

The Contractor shall report software development progress through monthly reports (Task 1.B), meetings with the COR, and during cohort activities (Task 1.C). The Contractor shall provide ongoing access to software development management tools and code repositories for up to five ITS4US Deployment

Accelerator Program representatives (USDOT staff or contractors).

1.3.3 Task 3: System Demonstration

In this task, the Contractor shall develop the Draft Demonstration Plan, demonstrate the system, and prepare a Final Demonstration Plan documenting the demonstration results. This system demonstration shall align with the operational capabilities identified in the Operational Concept Plan.

System Acceptance Demonstration. No later than 12 months after award, the Contractor shall execute a full end-to-end demonstration of the system to allow the COR and other Government personnel to evaluate whether the system is ready for deployment into operational practice and meets the user needs and system requirements as laid out in the Operational Concept Plan.

The demonstration shall be conducted in real time for the COR and other Government personnel, allowing them to directly observe whether it succeeds or fails. The Contractor may conduct portions of the demonstration through a virtual meeting, with COR approval.

Draft Demonstration Plan. No less than two months prior to the planned System Demonstration, the

Contractor shall prepare a Draft Demonstration Plan. The Draft Demonstration Plan shall document the

Contractor’s approach to verifying that their system meets its requirements and has fulfilled user needs sufficiently. The Contractor shall also document what specific demonstration plans and procedures will be used to demonstrate individual capabilities and functionalities.

The Draft Demonstration Plan shall incorporate at a minimum the following elements:

• Demonstration Descriptions. The descriptions identify the objective, general location, participants, equipment, and high-level actions to be taken within the demonstration to illustrate the successful deployment of each user need and system requirement.

• Demonstration Procedures. Procedures describe the specific sequence of events that will be conducted and the observable validation criteria that will define a successful demonstration.

• Demonstration Data. Describes the data collected before, during, or after the Demonstration to support the observable demonstration validation criteria related to demonstration success.

• Demonstration Results Summary. Documents the results of the demonstration against the observable validation criteria. This will be updated in the Final Demonstration Plan.

Final Demonstration Plan. Within one month after completion of the Demonstration, the results shall be documented within the Final Demonstration Plan and the plan updated to reflect the final procedures used during the Demonstration. The Demonstration Results Summary section shall identify the pass/fail status of the various aspects of the Demonstration; any defects that were found and resolved; open defects, if any; the severity/impact of those defects on the system; and the timeframe for when they will be resolved.

1.3.4 Task 4: Project Assessment

Following an accepted final demonstration plan and any necessary actions to remediate identified defects, the Contractor shall implement the deployment into operational practice for a minimum of three months of data collection.

The focus of this task is measuring the impact of the deployment and its replicability, as self-measured by the Contractor according to the Operational Concept Plan, and the ITS4US Deployment Accelerator

Program.

Task 4.A: Lessons Learned and Impacts Report

The Contractor shall document the project through a Lessons Learned and Impacts Report (Impacts

Report) that identifies high-level project outcomes and lessons learned as part of the deployment activity.

The Government will provide the Contractor with a template for the Impacts Report.

The Impacts Report shall consist of, at a minimum, the following components:

• Quantitative Performance Assessment. Following the Performance Measures section of the

Operational Concept Plan, the Contractor shall provide a quantitative assessment of before and

“after” data to indicate whether the measure showed a positive outcome. This assessment is not required to determine whether a change was “statistically significant” but must have evaluated enough data to identify directional trends.

• Qualitative Performance Assessment. The Contractor shall conduct interviews and document perspectives of key stakeholders in the project, as well as end users, that assess whether the project met its performance goals. Testimonials and other verbal feedback that document stakeholder perceptions of success or failure of project components shall be included

• Replicability Assessment. Based on the Contractor’s experience replicating the Health

Connector middleware, the Contractor shall briefly assess whether there is potential for additional organizations to replicate the deployment without additional federal funding, what type of staff, vendors, skills, and systems are needed to replicate, and a rough estimate of the cost to replicate the deployment.

• Next Steps. The Contractor shall document what components will continue to operate beyond the project’s period of performance and any operational considerations for how those will be maintained (funding, staff, etc.). The Contractor shall identify any future improvements/extensions under consideration, if any. The Contractor shall identify any components that will no longer be supported at the end of the project, if any, along with rationale for discontinuing that component (funding, staff, limited adoption, etc.).

• Lessons Learned. The Contractor shall describe lessons learned during the course of the deployment. Lessons learned may highlight items such as successful or unsuccessful mitigation of risks, internal and external issues, best practices identified through collaboration with the cohort, and other things that would be of relevance to future deployers pursuing similar projects.

• Supporting Data Artifacts. The Contractor shall provide data sets used in the evaluation of the projects aligned with the requirements on the ITS Data Hub.

Task 4.B: Program Reflection

Within the final quarter of the period of performance, the USDOT will provide a Program Reflection template to the Contractor. The purpose of Program Reflection is to solicit feedback on the structure of the ITS4US Deployment Accelerator Program, identify recommendations and improvements for Program efficacy, and to update processes for future iterations of the ITS4US Deployment Accelerator Program.

2.0 Period of Performance

The period of performance shall be 18 months from the effective date of the award. There are no option periods.

3.0 General

The Contractor shall develop and maintain an effective Quality Control Plan (QCP) to ensure services are performed in accordance with this PWS. The Contractor shall develop and implement procedures to identify, prevent, and ensure non-recurrence of defective services. The Contractor’s QCP is how the

Contractor assures that their work complies with the requirement of the contract. The QCP shall be delivered to the Government as part of the Operational Concept Plan (Task 2A). After government acceptance of the QCP, the Contractor shall receive the COR’s acceptance in writing of any proposed change to the government accepted QCP.

3.1 Place of Performance

The work to be performed under this contract shall be performed at contractor’s facilities.

3.2 Physical Security

The Contractor shall be responsible for safeguarding all government equipment, information, and property provided for Contractor use.

3.3 Special Qualifications

Pursuant to 48 CFR 1252.237-73, the Recipient must request prior written approval from the CO for any change in Key Personnel specified in the award. The following positions are/have been identified as Key

Personnel, and are defined in further detail below:

• Deployment Lead (DL)

• Systems Engineering Lead (SEL)

• Project Management Lead (PML)

Deployment Lead (DL): The DL will be responsible for articulating the vision, approach, and objectives of the overall deployment concept. The DL is responsible for creating team agreement on specific and practical performance measures, and for the implementation of performance management best practices.

The DL is responsible for organizing and leading the deployment team partnership.

Systems Engineering Lead (SEL): The SEL will oversee the integration of technologies and services and manage planning integrated design, installation, operations, and maintenance. The SEL is responsible for the application of appropriate systems engineering (SE) processes and the quality of all SE artifacts. Most importantly, the SEL must manage the scope and detail of the SE process to ensure the quality of the artifacts developed as well as ensuring that the SE process can be satisfactorily completed within the designated period of performance.

Project Management Lead (PML): The PML will be responsible for the quality and timely provision of project management artifacts required in the contract and for tracking project progress against target performance throughout the project lifecycle. The PML is responsible for risk tracking and risk mitigation.

Note: The USDOT expects that three different individuals will be named for each of these Key Personnel roles. The DL or the PML can be designated as the primary point-of-contact (POC) with the government

CO and government COR. This POC must be from the organization entering into the contract.

3.4 Periodic Progress Meetings

The Contractor agrees to attend progress meetings. The CO or COR, and other Government personnel, as appropriate, may meet periodically with the Contractor to review the Contractor's performance. At these meetings, the CO will apprise the Contractor of how the government views the Contractor's performance and the Contractor will apprise the Government of problems, if any, being experienced. Appropriate action shall be taken to resolve outstanding issues. These meetings shall be at no additional cost to the government.

3.5 Organizational Conflict of Interest

Contractor and subcontract personnel performing work under this award may receive, have access to, or participate in the development of proprietary or source selection information (e.g., cost or pricing information, budget information or analyses, specifications or work statements, etc.), or perform evaluation services which may create a current or subsequent Organizational Conflict of Interests (OCI) as defined in FAR Subpart 9.5. The Contractor shall notify the CO immediately whenever he/she becomes aware that such access or participation may result in any actual or potential OCI, and may merit the submittal of a plan to the CO to avoid or mitigate any such OCI. This mitigation plan would be determined to be acceptable solely at the discretion of the CO, and in the event the CO unilaterally determines that any such OCI cannot be satisfactorily avoided or mitigated, the Contracting Officer may effect other remedies as he or she deems necessary, including prohibiting the Contractor from participation in subsequent contracted requirements which may be affected by the OCI.

4.0 Government Furnished Equipment and Services

4.1 Services

The Government anticipates providing the following technical assistance to the awardee cohort to support their replication efforts:

• A series of virtual technical meetings targeted at integrator and transit agency staff, where subject matter experts will walk through technical components of the middleware, point to references in

HIRTA ITS4US project documents, and have a questions and answer period. These meetings will occur 6-12 times during the period of performance, with most occurring in the first few months after award.

• A series of virtual meetings targeted at transit agency and healthcare partner staff, where subject matter experts will provide best practices and lessons learned, point to references in HIRTA

ITS4US project documents, and have a questions and answer period. Topics are likely to include establishing partnerships, marketing, recruiting users, training staff, funding opportunities, etc.

These meetings will occur 6-12 times during the period of performance on a monthly or bimonthly basis.

• Regularly scheduled “office hours” where Contractors can bring questions to subject matter experts between meetings. These are expected to occur weekly for the first several months of the project and transition to every two weeks thereafter.

• A document sharing website where the awardee cohort can post materials to share with other cohort members.

4.2 Materials

The Government will provide:

• Reference list for all relevant HIRTA Health Connector materials, including source code repositories.

• Templates for reports developed in Tasks 2, 3, and 4.

5.0 Attachment/Exhibit List

5.1 Exhibit 1

Performance Requirements Summary

5.2 Exhibit 2

Deliverables Schedule

5.3 Exhibit 3

Control Clauses for ITS JPO Contracts and Orders

TECHNICAL EXHIBIT 1

PERFORMANCE REQUIREMENTS SUMMARY

The Contractor service requirements are summarized into performance objectives that relate directly to mission essential items. The performance threshold briefly describes the minimum acceptable levels of service required for each requirement. These thresholds are critical to mission success.

Performance Objective

(The Service required— usually a shall statement)

Performance Standard

Performance

Threshold (This is the maximum error rate.)

Method of

Surveillance

PRS # 1.

The Contractor shall provide the Operational

Concept Plan that includes define the systems that will be integrated, relevant vendors and project partners, user personas, and system requirements.

[Task 2A]

The Contractor provided a

Plan that included all content required by the Government provided template with a level of detail that allows the

Government to assess the likelihood of successful execution of the approach.

No more than one

Government comment requesting additional detail per template section.

Review of content by the

COR.

PRS # 2

The Contractor shall provide the Open-Source

Code and Documentation

[Task 2B]

The materials provided meet the requirements listed on the

ITS CodeHub.

No deviation from the published requirements.

Review of content by the

ITS CodeHub contractor and approval by the COR.

PRS # 3

The Contractor shall provide the Lessons

Learned, data artifacts, and

Impacts Report [Task 4A]

The Contractor provided a

Report that included all content required by the

Government provided template.

No more than one

Government comment requesting additional detail per template section.

Review of content by the

COR.

TECHNICAL EXHIBIT 2

DELIVERABLES SCHEDULE

This technical exhibit lists any reports or documentation that is required as a deliverable to include the frequency, # of copies, medium/format and who/where it is to be submitted. A deliverable is anything that can be physically delivered but may include non-physical things such as meeting minutes.

Deliverable

Compliant Frequency

Due Date Medium/

Format Submit To

Kickoff Meeting

Slides

(Task 1A)

No One time Within 15 business days of award.

Virtual

Meeting

COR

Monthly Progress

Reports

(Task 1B)

No Monthly By the 15th of every month.

PDF COR

Operational

Concept Plan

(Task 2A)

No One time Within 4 months of award

PDF COR

Open-Source Code and associated artifacts

(Task 2B)

No One-time Within 15 months of award (Initial submission for

USDOT review of completeness)

GitHub repository

(1 or more)

COR

Draft

Demonstration

Plan

(Task 3)

No One-time.

Within 10 months of award.

No less than 2 months prior to

System

Demonstration

Event.

PDF COR

Final

Demonstration

Plan

(Task 3)

Yes One-time.

Within 13 months

No later than 1 month following

Demonstration

Event.

PDF COR

Lessons Learned and Impacts

Report and associated supporting data artifacts (Task 4A)

Yes One-time.

Within 16 months of award

PDF COR

Program

Reflection

(Task 4B)

No One-time.

Within 17 months

Digital

Form or

PDF

COR

TECHNICAL EXHIBIT 3

CONTROL CLAUSES FOR ITS JPO CONTRACTS AND ORDERS

In order to facilitate the tracking and reporting of cost, schedule, and performance information, the following information shall be submitted in accordance with specified formats and procedures and may be amended periodically:

1. Invoice Reporting

The contractor shall submit invoices according to the specified monthly period addressing work completed and hours expended. The contractor shall submit invoices in accordance with the invoice guidance and billing instructions included in the contract and/or order.

The Contractor shall submit invoices directly to the Delphi system or as otherwise specified.

Additionally, the Contractor shall submit invoices concurrently to the COR, ITSProjects@dot.gov, and other recipient(s) (if applicable) as directed by the COR. The Contractor shall include the contract number and order number (if applicable) in the subject line of emails to ITSProjects@dot.gov, as well as any specified keywords requested by the Government.

2. Schedules and Performance Reporting

The Contractor shall provide monthly progress reports:

a) Monthly Status Reports – the Contractor shall submit monthly status reports in accordance with the contract and order (if applicable) in the format specified by the COR.

b) Project Schedule – the Contractor shall submit, an initial project schedule utilizing the ITS JPO

Project Schedule Template within sixty (60) days after the effective date of the contract or order and updates showing the percent complete of major deliverables every thirty (30) days thereafter.

The schedule shall include at a minimum, the major deliverables and milestones and adhere to the

ITS JPO Project Schedule Template structure provided by the COR. Any changes to due dates after the initial project schedule baseline must be approved by the COR. The Contractor shall support the identification of schedule dependencies related to the project and in accordance with the Government defined process.

c) Risk Register – the Contractor shall document risks that might affect the project and the characteristics of the risk defined by the ITS JPO. The COR will provide an ITS JPO Risk

Register Template for the Contractor to populate and update as necessary. Each risk shall have a unique number, probability of occurrence and impact of occurrence rating. The risk log shall be updated monthly and submitted with monthly progress reports.

3. Deliverables

The Contractor shall submit Interim and Final Deliverables concurrently to the COR and to

ITSProjects@dot.gov. The Contractor shall include the contract number (and order number if applicable) in the email subject line for each deliverable. The Government may request the Contractor to include additional specified keywords in the subject line of emails containing deliverables. Additionally, the

Government may request the Contractor to submit Deliverables to an electronic repository as specified by the COR.

Specific directions for reports, data, and software codes are provided below:

a) Reports – all the reports developed from the subject project shall be published through the ITS

JPO. Detailed information, including ITS JPO Publication Template and 508 Compliance

Guidance, is available on the Publication Editorial Guidelines page at https://www.its.dot.gov/news-info/Publication-Editorial-Guidelines/Checklist/. If the Contractor https://www.its.dot.gov/news-info/Publication-Editorial-Guidelines/Checklist wants to publish the report(s) through a different publication procedure, the Contractor shall first consult and obtain an approval from the ITS JPO Program Manager (PM) through the COR, and later submit a link to the final published report to the COR who will then forward the link to the

ITS JPO PM.

b) Data – all the data collected or produced from the subject project shall be uploaded to the ITS

DataHub at https://its.dot.gov/data/. Detailed directions on how to submit a data set is presented on the page titled “ITS DataHub Submissions” at https://its.dot.gov/data/data-submission/. If the

Contractor wants to upload the data at a different location, the Contractor shall first consult and obtain an approval from the ITS JPO PM through the COR, and later submit a link to the final published data to the COR who will then forward the link to the ITS JPO PM.

c) Software Codes – all the software codes developed from the subject project shall be uploaded to the ITS CodeHub at https://its.dot.gov/code/. Detailed directions on how to upload a code(s) is presented on the section titled “Registering a Repository” at https://its.dot.gov/code/about. If the

Contractor wants to upload the software codes at a different location, the Contractor shall first consult and obtain an approval from the ITS JPO PM through the COR, and later submit a link to the final published software codes to the COR who will then forward the link to the ITS JPO PM.

The Contractor shall submit invoices, all deliverables, and all required reporting to the COR and to

ITSProjects@dot.gov.

https://its.dot.gov/data/ https://its.dot.gov/data/data-submission/ https://its.dot.gov/code/ https://its.dot.gov/code/about