00017493 Attachment D_Statement of Work.docx

RFP/Bid Solicitation S-73000-00017493 CVIEW Replacement Project Att D

ATTACHMENT D

DESCRIPTION OF SERVICES AND SAMPLE STATEMENT OF WORK

[Note to Proposers: This Attachment D covers the proposed Tasks, Deliverables, and Schedule of Phase 1 Core CVIEW Deployment, Phase 2 Agency Credential and Permit Integration, and Phase 3 External Data Exchange and Ecosystem Completion. Tasks, Deliverables, and Schedule based on the following Statement of Work will be negotiated for each Phase with the successful Proposer.

References to the RFP and its Attachments will be replaced with references to provisions in, or exhibits, to the negotiated Contract.] A. PROJECT DESCRIPTION and OVERVIEW of SERVICES Oregon Department of Transportation (“Agency”) is seeking vendors to provide a Software-as-a-Service (“SaaS”) Commercial Vehicle Information Exchange Window (“CVIEW”) solution. Contractor shall deliver a secure, vendor-hosted platform and all associated implementation services necessary to replace the State’s legacy CVIEW system and establish a modernized, fully integrated operational environment.

Project Objectives:

Deploy a Federal Motor Carrier Safety Administration (“FMCSA”) Innovative Technology Deployment (“ITD”) core compliant CVIEW system Implement a secure, cloud-hosted SaaS platform Integrate with federal systems [e.g., FMCSA Safety and Fitness Electronic Records (“SAFER”) and Performance and Registration Information Management System (“PRISM”)] Implement e-screening Integrate with state credentialing, permitting, and enforcement systems Migrate required state-owned configuration and operational data Contractor shall provide:

A hosted CVIEW SaaS platform System implementation and configuration services Integration with federal and state systems Migration of required state-owned configuration and operational data User training and knowledge transfer Production deployment and stabilization support Ongoing SaaS subscription, maintenance, and operational support services Phased Implementation Approach:

The CVIEW SaaS implementation is structured into three sequential phases to ensure controlled deployment, integration sequencing, governance oversight, and operational readiness. Each Phase includes defined Tasks and Deliverables that align with approved scope, Requirements Traceability Matrix validation, integration certification, user acceptance testing, and production deployment requirements.

The legacy CVIEW system will remain in parallel operation through Phase 3 to preserve continuity for enforcement, credentialing, and tax workflows. The legacy system will be fully decommissioned upon successful completion of Phase 3 acceptance criteria.

Phases are funded and authorized independently. Contractor must structure staffing, pricing, and contractual obligations to accommodate potential schedule gaps between Phases, separate funding authorizations, and competing agency priorities that may affect Phase initiation timing. Agency does not guarantee continuous engagement between Phases.

All Phases will include:

Formal project management oversight Deliverable review and acceptance procedures Integration validation and certification Data reconciliation and migration validation (where applicable) Phase-gate approvals prior to moving to the next Phase See Appendix 1 Deliverable Schedule for deliverable due dates.

Phase 1: Core CVIEW Deployment Contractor shall provide and configure the SaaS platform, implement the core query module and screening engine, integrate and sync foundational federal data, conduct user testing and training, and deploy the system to production.

Phase 2 – Agency Credential and Permit Integration Contractor shall expand system capabilities through integration with Agency credential and permit issuance systems, clearinghouse exchanges, and internal distribution feeds. Contractor shall validate enhanced screening workflows and operational data exchanges.

Phase 3 – External Data Exchange and Ecosystem Completion Contractor shall enable external query APIs and additional outbound integrations, validate system performance and interoperability, and transition the platform to steady-state SaaS operations.

General Expectations Contractor commits to provide the Services and System as defined in the Contract, and to oversee and direct the Project to obtain the greatest long-term value for the State of Oregon, which reflects the prudent expenditure of public funds within the constraints of the Project, program, context and budget.

Contractor commits to:

Develop a design that is appropriate for the context of the Project and the nature of its function, both present and future as defined in this Contract and all its amendments;

Avoid expenditures for aesthetic effect which are disproportionate to the Project as a whole;

Manage and facilitate all facets of the Project that are reasonably within Contractor’s control to ensure the Project is completed on or ahead of time and within budget;

Apprise Agency throughout the Project of any issues or decisions that may impact the Project budget or schedule;

Use recycled/recyclable products to the maximum extent economically feasible in the performance of this Contract;

Ensure compliance with Agency and state policies, along with state and federal laws as related to Agency’s Commerce and Compliance Division (“CCD”); and Embody sound and cost-effective sustainability principles in the Services performed under the Contract consistent with the provisions of the Oregon Sustainability Act (2001 HB 3948) that are included in ORS 184.421-.423.

Acronyms and Definitions [Proposers, see RFP Attachment F Acronyms and Definitions.]

Contractor shall perform the Services:

a. Employing a methodology that conforms to the standards established by the Project Management Institute (“PMI”) as described in the Project Management Body of Knowledge (“PMBOK”), current edition (PMBOK Guide, ANSI/PMI 99-001-2017), supplemented by standards set forth in ISO 12207;

b. In compliance with information technology standards established by the Department of Administrative Services (“DAS”) Enterprise Information Services (“EIS”), found at: https://www.oregon.gov/das/Pages/policies.aspx, (which may be updated from time to time);

c. Statewide Cloud Computing policy (if applicable): http://www.oregon.gov/das/policies/107-004-150.pdf; and

d. In compliance the standards listed in the System Requirements (Exhibit L).

2. Software Requirements Contractor’s software must produce Deliverables that are fully compatible, readable and useable by Agency software, requiring no modification or translation of Contractor’s Deliverables.

Agency's Project Manager(s) (“APM”), or such other individual identified in specific tasks or as designated in writing to Contractor, is the primary contact on behalf of Agency for this project.

To the extent possible, all transmittals from Contractor to Agency must include the Contract number and Project name.

Contractor shall represent Project and Agency in an appropriate and professional manner in public.

5. Format Requirements Contractor shall submit draft and final Deliverables in electronic format via email (and hard copy if requested).

Contractor shall also submit any graphic files accompanying reports separately in .jpg or .tif formats unless specified differently by Agency.

Each draft and final text-based or spreadsheet-based Deliverable must be provided in MS Office file formats (i.e., MS Word, Excel, etc.) and must be fully compatible with version used by Agency.

Additional format requirements may be listed with specific tasks/Deliverables throughout the Statement of Work (“SOW”) or in the Contract.

6. Contractor Project Team Roles Contractor team must be of a size sufficient to have the depth and experience in the delivery of the proposed System within time constraints. It is Agency’s experience that a project of this size and complexity will typically require Contractor resources that, at a minimum, can support the roles of Project Manager and Lead Business Analyst. Contractor’s Project Manager and Business Analyst are identified on Exhibit E (Contractor’s Personnel) of RFP Attachment A (Sample Contract) and are designated Key Persons per Contract Section 4.1.

The Project Manager, Lead Business Analyst, Lead Technical Manager must be consistent throughout the Project to ensure continuity. Responsibilities of these roles include, but are not limited to:

Project Management functions:

Coordination and facilitation of Project Kickoff Meeting Preparation and maintenance of Contractor Project Plan Preparation and maintenance of Contractor Status Reports Attendance at and participation in Project Performance Meetings Attendance at and participation in monthly Project Progress Meetings Preparation and maintenance of other documents needed by Contractor to provide the Project Management oversight necessary to successfully complete the engagement Attendance at and participation in Project Steering Committee Meetings, as requested by Agency Task management within Contractor project team Project communication Maintenance of scope, issue, and change control Contractor sign-off on change requests

Lead Business Analyst functions:

Lead project meetings Attend key project meetings Lead the support team on a daily basis Provide quality assurance on all Deliverables Provide configuration and design recommendations to support best practices in meeting the requirements Contribute to traceability of requirements to System and testing Design and implement test plans for unit and functional testing Provide support to Agency staff involved in user acceptance testing Facilitate the delivery of training and user documentation Answer questions pertaining to System functionality

Lead Technical Analyst functions:

Leads system development and configuration efforts, data migration and feature management Leads overall system and technical client support on a daily basis Attend key project meetings Provide configuration and design recommendations to support best practices in meeting the requirements Design and execute test cases for unit testing Design and implement test plans for unit and functional testing Provide support to Agency staff involved in user acceptance testing Facilitate the delivery of training and user documentation Contractor staff must be available as appropriate, to attend meetings, conduct interviews, lead work sessions, and perform other activities requiring extensive interaction with Agency staff. Onsite visits may be required upon the APM request. In addition, Contractor staff must be available for Agency defined critical steps of the implementation process to ensure effective and timely transition to full production operations. Contractor staff must be available for the duration of the project to consult with Agency remotely during business hours, via phone, email, Microsoft Teams and Skype or comparable applications.

C. REVIEW, COMMENT and SCHEDULE OVERVIEW Contractor shall coordinate with Agency staff as necessary and shall revise draft Deliverables to incorporate Agency draft review comments.

Contractor shall incorporate comments within 7 business days from receipt by Agency and return the revised Deliverables to Agency staff, unless a different timeframe is specified for specific tasks or otherwise agreed to in writing by Agency.

D. OVERARCHING APPROVAL CRITERIA FOR CONTRACTOR DELIVERABLES

Agency will approve all Deliverables delivered by Contractor to Agency, and the System as a whole, when Agency verifies that the Deliverables conform to the specifications, functions and performance standards set forth in the Contract, including the SOW and all attachments. Approval will signify that Agency has found that all Approval Criteria specified in the Contract, this SOW, and the Deliverable description are completed and free from error or defect that materially impairs their use or accuracy.

To obtain Approval of a completed Deliverable, Contractor shall provide a written statement describing the work or product provided. The information required on the written statement will vary by Deliverable and the information provided on statements is subject to Agency approval.

For Deliverable work that results in an Agency reviewed document, the document itself will be considered the written statement.

Contractor shall track all changes to Contractor Deliverables. Changes from a previous version must be clearly identifiable for Agency review of a Deliverable document.

The default days-durations listed below in the Default Deliverable Review and Approval processes may vary by Deliverable. These variances (if any) will be identified in the Task or Schedule, respectively.

Default Deliverable Review and Approval Process

Contractor shall provide a Warranty Period that begins on Contractor’s completion, and Agency’s acceptance, of Task 9.1.1 deliverables, and ends 365 days thereafter.

2. System (Support and Maintenance) Agency’s obligation to pay for annual support and maintenance begins when the Warranty Period ends.

F. TASKS, DELIVERABLES and SCHEDULE Contractor shall complete all Tasks and provide all Deliverables (collectively, the “Services”) included in this SOW, unless specifically stated otherwise in a particular Task. Contractor shall provide all labor, equipment and materials to manage, coordinate, and complete the work in accordance with the performance and delivery schedules identified in this SOW.

Unless otherwise identified in the Tasks below, Deliverable due dates for subtasks are compiled in Appendix 1 Deliverable Schedule.

Contractor shall provide the Deliverables to the APM.

Phase 1 – Core CVIEW Deployment The Contractor shall initiate implementation of the CVIEW SaaS solution through Phase 1, which establishes the operational foundation of the system. Phase 1 is intended to enable controlled deployment of the core SaaS platform, configuration of primary system functionality, activation of foundational integrations, and preparation for production operations.

In Phase 1 Contractor shall deliver:

Provisioned SaaS environments (Dev/Test/Prod) Configured core CVIEW query/display module, user management, reporting & other core system modules Configured screening engine Role-based access controls Integration with foundational federal credential data sources Syncing federal data back to ODOT CVIEW Limited migration of state-owned configuration elements User testing, training, and production deployment Progression to subsequent phases shall be contingent upon successful completion of Phase 1 deliverables and formal Agency approval. Phase 1 includes, at minimum, the following tasks and associated deliverables:

Task 1 Project Management Services Contractor shall provide all project management services necessary to complete the implementation of the System from kickoff meeting through Project closeout. In addition, Contractor shall provide substantive input and feedback to Agency in Agency’s development of all information or documents necessary for Agency to receive State approvals to proceed with the Project. Contractor shall ensure the Project is completed on time, within budget, and will meet Agency’s objectives for the Project.

Task 1.1 Project Management Plan The Contractor shall develop, in coordination with APM, a comprehensive Project Management Plan (“PMP”) that defines the governance and management framework for execution of all three implementation Phases:

Phase 1 – Core CVIEW SaaS Deployment (“P1”) Phase 2 – ODOT Credential and Permit Integration (“P2”) Phase 3 – External Data Exchange and Ecosystem Completion (“P3”) The PMP must establish the structured processes by which the Project will be managed across all Phases. The PMP governs how scope, schedule, integrations, data migration activities, risks, issues, communications, and deliverables will be controlled and monitored. The PMP is a living document Contractor shall review and update periodically, at minimum, at the conclusion of each implementation Phase or as otherwise directed by the Agency. The PMP must include at a minimum:

Governance Structure and Decision-Making Hierarchy Roles and Responsibilities (“RACI”) Escalation Matrix Scope Management and Change Control Risk Management Methodology Issue Management Process Communications Management Plan Quality Assurance Framework Reporting Standards Deliverable Approval & Billing Approach Phase-Gate Review Process (P1, P2, P3) Version Control and Approval Page Task 1.2 Project Plan (Implementation Work Plan and Schedule) Contractor shall develop an Implementation Plan. Contractor shall maintain and update the Project Plan (Implementation Plan and Project Schedule) throughout the Project to reflect actual progress.

The Implementation Plan must contain, but is not limited to the following:

· Purpose/Objectives

· Implementation Approach

· Tools Needed

· Roles

· Test Support

· Assumptions and Risks

· Interfaces and Data Migration and Integration Considerations

· Go-Live Support Contractor shall maintain the Project Schedule to track progress of all implementation tasks, milestones and deliverables in Microsoft Project or other mutually agreeable project tracking applications. Contractor shall make the Project Schedule available to the APM to review and to monitor Project progress. The Project Schedule must conform to the payment schedule that is a part of this Contract, Exhibit TBD.

Task 1.3 Weekly Status Reporting Contractor shall conduct recurring weekly project status meetings and provide corresponding written status reporting throughout the duration of the Project, including all implementation Phases (P1, P2, and P3).

The purpose of the weekly status process is to provide project governance and performance oversight. Its purpose is to maintain scope, schedule, budget, risks, dependencies, and deliverables; monitor variance against approved baselines; and ensure timely identification, escalation, and resolution of issues. The weekly status report must include but not be limited to:

Accomplishments during the reporting period Planned activities for the upcoming period Schedule performance versus baseline Open and closed action items Current risks and mitigation strategies Active issues and change control items Escalations, if any Task 1.4 Kickoff Meeting Contractor shall conduct a formal Project Kickoff Meeting to initiate each Phase of the CVIEW SaaS implementation. The purpose of the meeting is to confirm project scope, objectives, governance structure, integration sequencing, schedule, roles and responsibilities, and immediate next steps.

Contractor shall prepare meeting agenda, presentation, and summary notes.

The Kickoff Meeting will align stakeholders on the applicable Phase’s activities, including SaaS provisioning, core configuration, foundational integrations, limited configuration migration, and testing approach.

Task 1.5 Monthly Status Reporting Contractor shall prepare and deliver a written Monthly Status Report throughout the duration of the Project, including all implementation Phases.

Each Monthly Status Report must include:

Executive Summary — Overall project health narrative and any items requiring Agency leadership attention Schedule Performance — Cumulative progress against baseline, milestone status, and critical path variance Budget and Resource Performance — Expenditures and resource utilization against baseline, with explanation of material variances Deliverable Status — Status of all deliverables due during the period and any past due or at risk Risk and Issue Summary — Updated risk register and issue log, including newly emerging items and resolutions Change Control Summary — Status of pending or approved change requests and their impacts 30/60-Day Lookahead — Upcoming milestones, decisions required from Agency, and known constraints Monthly Status Reports must cover the full preceding calendar month.

Task 1 Deliverables Deliverable 1.1: Project Management Plan

1.1.1 PMP

Deliverable 1.2: Project Plan (Implementation Work Plan and Schedule)

Deliverable 1.3: Weekly Status Reports

Deliverable 1.4: Kickoff Meeting Agenda, Presentation, and Summary Notes

1.4.1 Phase 1 Kickoff Meeting Agenda, Presentation, and Summary Notes Deliverable 1.5: Monthly Status Reports

Task 2 SaaS Environment Provisioning and Security Compliance Validation Task 2.1 SaaS Environment Provisioning Contractor shall provide Development, Test, and Production SaaS tenant environments within the Contractor’s hosted infrastructure and configure each environment to support each Phase’s implementation activities. This task includes establishing appropriate access controls, security configurations, system monitoring, logging capabilities, and validation that each environment is fully prepared for integration and testing activities.

Task 2.2 EIS Cyber Security Services (“CSS”) Security Validation Contractor shall coordinate with the APM and, if needed, the Oregon Enterprise Information Services (“EIS”) Cyber Security Services (“CSS”) unit, to validate compliance with all applicable State security requirements. Any required configuration updates or remediation actions necessary to achieve compliance must be identified, documented, and implemented prior to activation of integrations or movement to production.

Agency will provide an initial CSS Document. Contractor shall update the CSS Document.

Task 2 Deliverables Deliverable 2.1: SaaS Tenant Provisioning Report Deliverable 2.2: Updated CSS Document

Task 3 RTM Development and Core CVIEW Configuration Task 3.1 Phase 1 Requirements Traceability Matrix (“RTM”) Development Contractor shall develop, baseline, and obtain approval of a Phase 1 Requirements Traceability Matrix (“RTM”) prior to configuration validation. The RTM must define uniquely identified functional and technical requirements, map each requirement to system configuration components, and specify acceptance criteria and verification methods.

The RTM must include:

Unique requirement identifiers and requirement categorization (functional, technical, security, reporting, integration) Detailed requirement descriptions aligned to approved scope Mapping to specific CVIEW SaaS modules, configuration parameters, or system components Defined acceptance criteria for each requirement Verification method (configuration validation, system testing, UAT, etc.)

Status tracking fields (configured, validated, deferred, not applicable) The RTM will serve as the authoritative requirements baseline for configuration validation, testing, and acceptance activities. Agency approval of the RTM is required prior to formal configuration validation and initiation of Integration Testing.

Task 3.2 Core CVIEW Configuration and RTM Validation Contractor shall configure the core CVIEW SaaS application in accordance with the approved RTM. Configuration must include query functionality, screening engine rules and thresholds, Single Sign On (“SSO”) & non SSO authentication, Role-based access control (“RBAC”), audit logging, and required dashboards/reports. Contractor shall validate configured components against RTM acceptance criteria and document requirement-level traceability prior to Integration Testing and UAT.

Contractor shall provide documentation confirming completion of configuration, requirement traceability validation, validation results, and certification of readiness for Integration Testing and UAT.

Task 3 Deliverables Deliverable 3.1: Phase 1 Requirements Traceability Matrix (“RTM”) Deliverable 3.2: Core Configuration and RTM Validation Report

Task 4 Interface Design and Documentation Task 4.1 Develop Interface Design and Documentation for all Phases Contractor shall develop detailed Interface Control Documents (“ICDs”) for all integrations in each phase, which define the technical and operational specifications for each interface. ICDs do not include re-documenting the full SAFER schema.

ICDs must include:

Authentication method Transmission protocol Interface and Frequency (real-time vs batch) Error handling and retry logic Reconciliation method Monitoring and alerting procedures Each ICD must define the technical and operational specifications of the interface, including purpose, source and destination systems, data elements and formats, authentication method, transmission protocol, processing frequency, error handling, reconciliation procedures, and monitoring requirements.

For Phase 1 Contractor shall develop and approve ICDs for communication with Federal systems (e.g. SAFER).

For Phase 2 Contractor shall develop and approve ICDs for tax and permit data, vehicle and credential data (ODOT and federal), updates to the ODOT Lakehouse API, and transponder data.

For Phase 3 Contractor shall develop IDCs for updates to the ODOT Lakehouse API, SAFER Transponder, DMV Data Push and Query APIs, Enforcer, Green Light, SCRAM, DMV LEDS, ODOT Inspection Data Push, Observation Data Push, ORION Permit Push and Query, WIM Data Push and Query, and PRISM Carrier Query.

Task 4 Deliverables Deliverable 4.1 Approved Interface Control Documents for all Phases integrations

Task 5 Phase 1 Data Exchange Integration and Validation Task 5.1 Develop Data Exchange Configuration, Integration, and Validation Contractor shall configure and implement integrations for all Phases in accordance with the approved ICDs. This task includes technical configuration, endpoint validation, secure connectivity setup, data mapping, transformation logic (if applicable), and operational readiness testing.

Contractor shall:

Establish secure connections between systems Configure API endpoints or batch transfer mechanisms Validate authentication and authorization controls Confirm data element mapping and format compliance Implement error handling and retry logic Configure monitoring and alerting for each interface Conduct integration testing to verify functional accuracy and data integrity Perform reconciliation between source and target data All integrations must be validated prior to advancement to User Acceptance Testing (“UAT”).

Contractor shall provide an Integration Test Plan defining test scenarios, validation criteria, data sets, expected results, reconciliation procedures, and pass/fail thresholds for integrations in all Phases. The plan must align with approved ICDs and RTM requirements and be approved prior to execution of integration testing.

Task 5.2 Integration Testing and Data Reconciliation Contractor shall execute integration testing in accordance with the approved Integration Test Plan and conduct data reconciliation across integrations in all Phases. Testing must validate functional accuracy, data integrity, error handling, and screening logic for each interface prior to advancement to UAT.

Contractor shall:

Execute test scenarios defined in the approved Integration Test Plan Compare source system data to data received, processed, and displayed within CVIEW Verify key data element mapping, format compliance, and transformation accuracy Validate error handling, retry logic, and monitoring alerting behavior Document discrepancies, root cause, and resolution status Confirm that all integrations operate in accordance with approved ICDs and RTM requirements All integration testing and reconciliation must be completed and accepted by ODOT prior to advancement to UAT.

Contractor shall provide a Data Reconciliation Summary confirming validation of integrations by comparing source system responses (e.g., SAFER) and related credential feeds) to data received, processed, and displayed within CVIEW. The summary must document key data element verification, screening logic validation, error handling confirmation, identified discrepancies, and resolution status. This deliverable certifies that integrations operate in accordance with approved ICDs and RTM requirements prior to advancement to UAT or production deployment.

Task 5 Deliverables Deliverable 5.1 Integration Test Plan

5.1.1 Phase 1 Integration Test Plan

5.1.2 Phase 2 Integration Test Plan

5.1.3 Phase 3 Integration Test Plan

Deliverable 5.2 Data Reconciliation Summary

5.2.1 Phase 1 Data Reconciliation Summary

5.2.2 Phase 2 Data Reconciliation Summary

5.2.3 Phase 3 Data Reconciliation Summary

Task 6 User Acceptance Testing Task 6.1 Phase System Validation and User Acceptance Contractor shall support and coordinate User Acceptance Testing (“UAT”) to validate that the configured CVIEW SaaS solution meets approved all Phase requirements and operates as intended within the production-like test environment.

In UAT Contractor shall confirm:

Core query functionality (carrier, vehicle, inspection views) Screening engine logic and pass/fail outcomes RBAC permissions Proper display and processing of integrated SAFER and credential data Error handling and system response behavior Alignment with the approved RTM Contractor shall prepare a UAT Plan defining test scope, test scenarios, RTM traceability, participant roles, acceptance criteria, testing schedule, and defect management procedures.

Contractor shall conduct UAT to validate real-time API responsiveness, WIM screening logic, observation ingestion, ORION permit queries, PRISM validation, and RTM alignment.

Contractor shall prepare test scenarios and scripts, support test execution, document results, and resolve identified defects prior to production deployment.

Task 6.2 UAT Results Reporting Contractor shall prepare and deliver a UAT Results Report documenting the outcomes of all executed test cases, including pass/fail status, defects identified, remediation actions taken, and final validation outcomes.

Task 6.3 Defect Tracking and Resolution Contractor shall prepare, maintain and deliver a Defect Log and Resolution Summary documenting all issues identified during UAT, including assigned ownership, resolution status, and confirmation of closure for each defect prior to Phase acceptance.

Task 6 Deliverables Deliverable 6.1 UAT Plan

6.1.1 Phase 1 UAT Plan

6.1.2 Phase 2 UAT Plan

6.1.3 Phase 3 UAT Plan

Deliverable 6.2 UAT Results Report

6.2.1 Phase 1 UAT Results Report

6.2.2 Phase 2 UAT Results Report

6.2.3 Phase 3 UAT Results Report

Deliverable 6.3 Defect Log and Resolution Summary

6.3.1 Phase 1 Defect Log and Resolution Summary

6.3.2 Phase 2 Defect Log and Resolution Summary

6.3.3 Phase 3 Defect Log and Resolution Summary

Task 7 Training & Knowledge Transfer Task 7.1 Training Plan Development Contractor shall develop a Training Plan to prepare Agency personnel for operational use of the CVIEW SaaS solution for each Phase. The Training Plan must:

Define the training strategy, audience segmentation, schedule, delivery method, and learning objectives aligned to Phase 1 scope; and Outline the training approach, targeted user groups, delivery format, schedule, and define learning objectives aligned to the applicable Phase system functionality.

Task 7.2 Development of Training Materials Contractor shall develop role-based training materials consistent with the configured system functionality and validated RTM requirements for each Phase. Materials must support both instructor-led sessions and ongoing Agency reference needs.

The role-based training materials include a User Guide, Quick Reference Guide, Administrator Guide, and presentation materials sufficient to support system use and internal knowledge transfer.

Task 7.3 Training Delivery and Completion Documentation Contractor shall conduct training sessions for Agency-designated user groups, including enforcement users and system administrators for each Phase. Training must occur prior to production deployment.

Contractor shall prepare a Training Completion Report confirming training delivery, including session summaries, attendance records, and confirmation that designated user groups have completed required training.

Task 7.4 User Documentation Contractor shall develop and deliver user documentation prior to production activation of each Phase. Documentation must cover role-appropriate system functions, lookup and display capabilities. Documentation must be updated to changes introduced in each subsequent Phase.

Task 7.5 Technical Documentation Contractor shall develop and deliver technical documentation, API reference materials, and a data dictionary covering all Contractor-provided APIs and integration interfaces prior to production activation of each Phase. Integration interfaces must include endpoint specifications, authentication requirements, versioning policies, and integration guidance sufficient for Agency and source system partners to independently consume and troubleshoot APIs.

Documentation must be updated to reflect integrations, data elements, and API changes introduced in each subsequent Phase. Documentation must be updated to reflect integrations, data elements, and API changes introduced in each subsequent Phase.

Task 7 Deliverables Deliverable 7.1 Training Plan

Deliverable 7.2 Training Materials Package

Deliverable 7.3 Training Completion Report

Deliverable 7.4 User Documentation

Deliverable 7.5 Technical Documentation

Task 8 Production Deployment and Stabilization Task 8.1 Production Readiness Verification Contractor shall conduct a formal readiness assessment prior to production activation. This assessment must confirm that Phase 1 configuration, integrations, configuration migration, UAT, security validation, and training activities have been successfully completed.

Contractor shall prepare a Production Readiness Assessment Report which verifies:

Successful UAT completion and defect resolution Configuration migration validation EIS CSS compliance confirmation User access and RBAC validation Monitoring and logging readiness Defined rollback procedures Agency approval is required prior to production cutover.

Task 8.2 Disaster Recovery Planning Contractor shall develop and deliver a Disaster Recovery Plan (“DRP”) prior to production activation of each Phase. The DRP must document:

Recovery Time Objective (“RTO”) and Recovery Point Objective (“RPO”) commitments for the CVIEW environment Backup and restoration procedures for application, data, and integration layers Recovery roles, escalation paths, and stakeholder communication procedures DR testing requirements and success criteria Coverage must include all CVIEW components and federal data connections active at the time of Phase activation. Agency approval is required prior to production cutover.

Task 8.3 Program Plan and Top-Level Design (“PP/TLD”) Support Contractor shall provide technical support to ODOT in preparing and updating the FMCSA Program Plan and Top-Level Design (“PP/TLD”) prior to production activation of each Phase. Support must include documentation of the system architecture, SAFER and PRISM data exchange interface documentation, and CVIEW connectivity as required by FMCSA ITD program requirements.

Agency approval is required prior to FMCSA submission.

Contractor shall provide Agency with responses to FMCSA technical inquiries.

Task 8.4 FMCSA ITD Certification Readiness Self-Assessment Contractor shall conduct a certification readiness self-assessment prior to production activation of each Phase using the FMCSA PP/TLD Evaluation Checklist. The assessment must confirm that the system as configured meets ITD Core Compliance requirements applicable to the Phase scope and that all checklist items are addressed prior to FMCSA review.

Agency approval is required prior to FMCSA submission.

Task 8 Deliverables Deliverable 8.1 Production Readiness Assessment Report Deliverable 8.2 Disaster Recovery Plan

8.2.1 Phase 1 Disaster Recovery Plan

8.2.2 Phase 2 Disaster Recovery Plan (Contingent)

8.2.3 Phase 3 Disaster Recovery Plan (Contingent)

Deliverable 8.3 PP/TLD Technical Content

8.3.1 Phase 1 PP/TLD Technical Content

8.3.2 Phase 2 PP/TLD Technical Content (Contingent)

8.3.3 Phase 3 PP/TLD Technical Content (Contingent)

Deliverable 8.4 ITD Certification Readiness Self-Assessment

8.4.1 Phase 1 ITD Certification Readiness Self-Assessment

8.4.2 Phase 2 ITD Certification Readiness Self-Assessment (Contingent)

8.4.3 Phase 3 ITD Certification Readiness Self-Assessment (Contingent)

Task 9 Production Cutover and System Activation Task 9.1 Production Cutover and System Activation Contractor shall execute controlled production deployment in accordance with the approved cutover plan. Activities include:

Activation of production integrations Final validation of API connectivity Validation of screening logic in production Confirmation of user access Verification of system performance and availability Contractor shall coordinate production activation with the Agency and ensure minimal operational disruption.

Contractor shall prepare a Production Deployment Plan summarizing cutover activities, production activation steps, validation results, and confirmation of operational functionality in the production environment.

Task 9 Deliverables Deliverable 9.1 Production Deployment Plan

9.1.1 Phase 1 Production Deployment Plan

9.1.2 Phase 2 Updated Production Deployment Plan (Contingent)

9.1.3 Phase 3 Updated Production Deployment Plan (Contingent)

Task 10 Stabilization and Transition to Steady-State Operations Task 10.1: Conduct Stabilization Activities Following production deployment, Contractor shall provide a defined stabilization period to monitor system performance, resolve defects, and ensure operational continuity.

Stabilization activities include:

Monitoring system performance and availability Resolving post-deployment defects Validating screening accuracy in live operations Confirming compliance with service level commitments Transition planning to steady-state support Contractor shall prepare a Stabilization and Operational Transition Report summarizing system performance during stabilization, issues identified and resolved, confirmation of operational stability, and formal transition to steady-state operations.

Task 10 Deliverables Deliverable 10.1: Stabilization and Operational Transition Report

10.1.1 Phase 1 Stabilization and Operational Transition Report

10.1.2 Phase 2 Stabilization and Operational Transition Report (Contingent)

10.1.3 Phase 3 Stabilization and Operational Transition Report (Contingent)

Phase 2 – ODOT Credential and Permit Integration Contractor shall expand system capabilities through integration with ODOT credential and permit issuance systems, clearinghouse exchanges, and internal distribution feeds. Contractor shall validate enhanced screening workflows and operational data exchanges.

In Phase 2 Contractor shall focus on activation and integration of:

Carrier and Company data Tax and Permit data Vehicle and Credential data (Federal and ODOT) Transponder data (ODOT and SAFER) Progression to Phase 3 will be contingent upon successful completion of Phase 2 deliverables and formal Agency approval.

Phase 3 External Data Exchange and Ecosystem Completion Contractor shall implement Phase 3 to complete the CVIEW ecosystem by enabling external query consumers, analytical data feeds, advanced roadside integrations, and outbound interoperability. In Phase 3 Contractor shall focus on activation and integration of Carrier and Company Data, SAFER Transponder Data, DMV integrations, consumer query APIs, ODOT Inspection and Observation data, ORION Over Dimension permits, WIM data, and PRISM carrier queries. All integrations must be API driven in real time or near real time and implemented in accordance with approved ICDs. Completion of Phase 3 will result in full external interoperability and transition to steady state SaaS operations.

G. CONTINGENCY TASKS

The table below is a summary of contingency tasks that Agency, at its discretion, may authorize Contractor to perform. Details of the contingency tasks and associated deliverables are stated in the Task section of the SOW. Contractor shall complete only the specific contingency task(s) identified and authorized via written (email acceptable) Notice-to-Proceed (“NTP”) issued by Agency's APM. If requested by Agency, Contractor shall submit a detailed cost estimate for the agreed-to contingency Services (within the NTE amount(s) in the Contingency Task Summary Table) within the scope of the contingency task.

If Agency chooses to authorize some or all of these tasks, Contractor shall complete the authorized tasks and deliverables per the schedule identified for each task. The NTP will include the contingency task name and number, agreed-to due date for completion and NTE for the authorized contingency task.

Each contingency task is only billable (up to the NTE amount identified for the task) if specifically authorized per NTP. In the table below, the “NTE for Each” amount for a contingency task includes all labor, overhead, profit, and expenses for the task. The funds budgeted for contingency tasks may not be applied to any non-contingency task or other contingency tasks without an amendment to the Contract. The total amount for all contingency tasks authorized shall not exceed the maximum identified in the table below. Each authorized contingency task must be billed as a separate line item on Contractor’s invoice.

[Proposers – do not complete this table or submit it as part of your proposal.] Contingency Task Summary Table Contingency Task or Deliverable Number

7.1.2 Phase 2 Training Plan

7.1.3 Phase 3 Training Plan

7.2.2 Phase 2 Training Materials Package

7.2.3 Phase 3 Training Materials Package

7.3.2 Phase 2 Training Completion Report

7.3.3 Phase 3 Training Completion Report

7.4.2 Phase 2 Updated User Documentation

7.4.3 Phase 2 Updated User Documentation

7.5.2 Phase 2 Updated Technical Documentation

7.5.3 Phase 3 Updated Technical Documentation

8.2.2 Phase 2 Disaster Recovery Plan

8.2.3 Phase 3 Disaster Recovery Plan

8.3.2 Phase 2 PP/TLD Technical Content

8.3.3 Phase 2 PP/TLD Technical Content

8.4.2 Phase 2 ITD Certification Readiness Self-Assessment

8.4.3 Phase 3 ITD Certification Readiness Self-Assessment

9.1.2 Phase 2 Updated Production Deployment Plan

9.1.3 Phase 3 Updated Production Deployment Plan

10.1.2 Phase 2 Stabilization and Operational Transition Report

10.1.3 Phase 3 Stabilization and Operational Transition Report