C250014_Exhibit_A_Scope_of_Work.pdf

RFP 250014

EXHIBIT A

V02182025

SCOPE OF WORK

HARBOR BOULEVARD TRANSIT SIGNAL PRIORITY DEPLOYMENT

1. BACKGROUND

2. PROJECT GOALS AND OBJECTIVES

3. CONSULTANT SERVICES, EFFORTS AND DELIVERABLES

4. TECHNICAL PROPOSAL

FIRM QUALIFICATIONS

STAFFING AND PROJECT ORGANIZATION

TECHNICAL SOLUTION DESIGN (TSD) NARRATIVE

5. DEMONSTRATION/INTERVIEW

6. OCTA RESOURCES

7. CONSULTANT SERVICES, EFFORTS AND DELIVERABLES

8. CONSULTANT TEAM

9. BUSINESS NARRATIVE

10. CONTRACT TASKS

TASK 1 – PROJECT PLANNING AND MANAGEMENT

TASK 2 – REQUIREMENTS GATHERING

TASK 3 – DESIGN AND PROCUREMENT

TASK 4 – CONFIGURE / BUILD

TASK 5 – TEST

TASK 6 – TRAIN

TASK 7 – DEPLOY

TASK 8 – POST-DEPLPOYMENT SUPPORT / WARRANTY

11. ATTACHMENT A: HARBOR BLVD TSP REQUIREMENTS

A1: VENDOR RESPONSE INSTRUCTIONS

A2. FUNCTIONAL AND NON-FUNCTIONAL REQUIREMENTS

A3: VENDOR QUESTIONNAIRE

B1: REPORTS

B2: INTERFACES AND DATA EXCHANGE

B3: SYSTEM USERS

B4: PROJECT STUDY AREA

B5: LOCATIONS

B6: OCTA SYSTEM TOPOLOGY DIAGRAM

12. SOFTWARE PERFORMANCE SERVICE LEVEL AGREEMENT (SLA)

1. BACKGROUND

The Harbor Boulevard corridor is a critical multimodal route in central Orange County, spanning the cities of Anaheim, Fountain Valley, Fullerton, Garden Grove, and Santa Ana. The twelve (12)-mile corridor serves OC Bus routes 543 (Rapid) and 43 (local) routes, which collectively support over 10,000 daily boardings. Eight percent (8%) of all Orange County Transportation Authority (OCTA) bus ridership and over 50,000 vehicles travel this route each day. This corridor connects vital destinations including medical facilities, California State University, Fullerton, Disneyland, Santa Ana College, places of worship, and shopping centers.

In 2023, OCTA was awarded $1.6 million in US Department of Transportation’s Stage 1 Strengthening Mobility and Revolutionizing Transportation (SMART) program funds to pilot a cloud-based transit signal priority (TSP) system on a segment of Harbor Boulevard. This quick-build pilot, implemented in November 2024, was evaluated for both transit performance benefits and impacts to general vehicular traffic, confirming its viability for broader deployment.

Simultaneously, in July 2023, the OCTA Board of Directors (Board) approved the acceptance of Regional Early Action Planning Grants of 2021 (REAP 2.0) funds, administered by the Southern California Association of Governments, to implement Stage 2 of the Harbor Boulevard TSP expansion. As one of the eleven OCTA-led projects under REAP 2.0, this Stage 2 initiative includes the full deployment of cloud-based TSP along the entire OC Bus Rapid 543 Route corridor with a budget of $2.34 million. Improved bus reliability and predictability will allow commuters to reach their jobs, medical appointments, schools, and homes in a safe and timely manner. Lastly, the project would allow OCTA to use buses more efficiently and improve the driving experience for OCTA coach operators.

Orange County agencies have made significant investments in their signal infrastructure, improving communication between the signalized intersections and their respective Traffic Management Centers (TMCs). OCTA buses host a suite of equipment that allows for comprehensive data collection, remote network communications, and location tracking that exchange information between the bus operator and the OCTA Traffic Operation Center (TOC).

Each bus is equipped with a Cradlepoint router (IBR1100 or IBR1700) with cellular connection to OCTA’s Conduent OrbCAD Computer-Aided Dispatch/Automatic Vehicle Location (CAD/AVL) system. Bus locations are polled by the OrbCAD system and uploads the General Transit Feed Specification (GTFS) package to the Swiftly data engine roughly every five to ten seconds. This frequency and level of data detail is well-suited for integration with centralized or cloud-based TSP platforms, enabling timely, data-driven priority requests to traffic signal systems.

2. PROJECT GOALS AND OBJECTIVES

The Harbor Boulevard Transit Signal Priority Deployment (Project) includes fifty-two (52) signalized intersections along the OCTA Harbor Boulevard Rapid 543 Route from the OCTA Santa Ana Base at MacArthur Boulevard and Hyland Avenue in the City of Santa Ana to the Fullerton Transportation Center (FTC) at Commonwealth Avenue and Pomona Avenue in the City of Fullerton, as shown in worksheet B5 of Attachment A. The signalized intersections are owned and operated by the Project partners, cities of Anaheim, Fountain Valley, Fullerton, Garden Grove, and Santa Ana, with remote access for signal operations from each agency’s Advanced Traffic Management System (ATMS) located at their respective TMCs. This Project’s goals and objectives are summarized below.

• Expand Cloud-Based TSP along Harbor Boulevard, implementing TSP at approximately fifty-two (52) signalized intersections to improve bus travel time reliability and on-time performance for OC Bus Rapid 543 Route.

• Leverage real-time data from Swiftly static and real-time GTFS feed to inform dynamic TSP requests based on vehicle location.

• Modernize traffic signal infrastructure to support cloud-based TSP functionality, including:

o Replacement or upgrade of traffic signal controllers;

o Deployment of field communications switches for network reliability;

o Installation or upgrade of firewall and security systems at TMCs.

• Enhance multimodal corridor performance by reducing bus delay without significantly disrupting cross-traffic or vehicular operations.

• Support corridor-wide coordination among multiple jurisdictions (Anaheim, Fountain Valley, Fullerton, Garden Grove, Santa Ana) by implementing a standards-based TSP system, using protocols such as NTCIP 1211 and 1202.

• Establish a scalable, replicable model for future TSP deployment throughout Orange

County.

This Project is fully funded by REAP 2.0 with a funding expenditure deadline expected to be December 30, 2026. the selected Consultant shall provide an understanding of the funding requirements throughout the delivery of the project.

3. CONSULTANT SERVICES, EFFORTS AND DELIVERABLES

OCTA is soliciting proposals from all qualified firms, including but not limited to licensors, authorized distributors, and certified value-added resellers (collectively referred to as “Consultants”). Consultants are invited to propose the most current and effective technology solutions that align with the Project’s objectives and meet the specific requirements outlined in this Scope of Work (SOW) and Request for Proposals

(RFP) 250014.

By submitting a proposal, the Consultant acknowledges that they have reviewed and understand the following documents and criteria:

• Evaluation Criteria

• Project Goals, Objectives, and High-Level Scope

• Attachment A

4. TECHNICAL PROPOSAL

OCTA encourages Consultants to offer the latest available technology solutions that best meet the Project objectives and specific requirements listed herein. Consultant’s proposal response shall include the following information:

FIRM QUALIFICATIONS

As part of the proposal, the Consultant shall provide a comprehensive statement demonstrating their qualifications for selection. This shall include:

• A detailed summary of technical experience in performing work of a closely similar nature.

• An overview of the firm’s overall strength and organizational stability.

• An assessment of the strength, stability, experience, and technical competence of any proposed subcontractors.

• Client references that would are close in nature to the project needs and/or industry alignment.

• This information will be used as a basis for evaluating the Consultant’s capability to successfully perform the services described in this Scope of Work (SOW) and Request for Proposals (RFP).

STAFFING AND PROJECT ORGANIZATION

Consultant shall possess demonstrable experience in the implementation of the software solution specified for this Project.

TECHNICAL SOLUTION DESIGN (TSD) NARRATIVE.

Consultant shall include in the “Work Plan” section of its proposal a TSD narrative section highlighting the proposed technical solution for OCTA. This narrative shall include a description of the technical architecture and the justification for the proposed approach. This shall include hardware and/or cloud hosting environments topology, including network and security components, all third-party software, and integration solutions for disparate components.

• PROPOSED PROJECT SCHEDULE

For the purposes of the proposal, the schedule shall identify all phases/stages of the project and the high-level tasks in sufficient detail as a roadmap for the deliverables. Tasks shall be grouped into the project phases/stages, and shall include all the relevant deliverables, and project milestones. The tasks shall identify Resources, Duration of tasks, and Predecessor relationships (whenever applicable). The schedule shall indicate the tasks for which OCTA is responsible.

During the actual project implementation effort, a more detailed project schedule shall be required (as described in Task 1 – Project Schedule), which shall incorporate OCTA-specified modifications, including duration and start-date modifications, as necessary, to align with regular work-day activities, business cycles, holidays, and other work-day constraints. This alignment may result in eight (8) to twelve (12) weeks of additional project duration if sufficient time was not allocated for OCTA to conduct reviews/approvals of project documentation, testing, etc.

• ROLES AND RESPONSIBILITIES MATRIX

Consultant shall provide the number of resources, and their respective roles. Consultant shall provide an organization chart (Org Chart) that reflects to whom the project personnel report.

• ATTACHMENT A

Consultant shall utilize the Microsoft Excel spreadsheet provided as part of this RFP package to respond to all questions pertaining to Attachments A. The completed Excel spreadsheet file must be included in the proposal submittal. Supplementary screenshots are not required and should not be included as part of the supporting documentation.

• PRICE SUMMARY SHEET

Consultants shall utilize the Price Summary Sheet provided as part of this RFP package.

The completed Price Summary Sheet must be included in the proposal submittal.

Prices shall include all direct costs, indirect costs, profit, and applicable taxes. OCTA intends to award a firm-fixed price contract for a five-and-a-half (5.5)-year solution. The contract term shall start with the six (6)-month implementation phase followed by the five (5)-year software maintenance and support upon formal acceptance of the implemented solution by

OCTA.

5. DEMONSTRATION/INTERVIEW

Consultants may be invited to participate in a system demonstration and/or interview as part of the evaluation process. The purpose of the demonstration is to allow the Consultant to present key functionalities of the proposed solution in alignment with OCTA’s business and technical requirements.

6. OCTA RESOURCES

OCTA will establish a project team that will include the following staffing for this project:

• A Project Steering Committee consisting of the Project Sponsors, and major stakeholders which will meet as needed (at a minimum, quarterly) to monitor progress and make any project decisions and course corrections that are needed.

• A Leadership Team consisting of Business Owners, including the OCTA and Partnering Resources, and Information Systems (IS) departments which will meet regularly (every two [2]-four [4] weeks) to drive efforts, address issues.

• An OCTA Project Manager (PM).

• Technical lead(s), who will be available as needed. The technical lead(s) will assist with technical efforts, such as: network configuration, security, databases.

• A Senior Business Analyst (BA) and functional experts will be available as needed, based on the project schedule, at the request of the OCTA PM.

• One (1) or more power users from each department will be available as needed. They will assist with application use-case questions and testing.

• An Application Analyst (AA) will be assigned.

• System users will be available during certain testing periods. All users of the system will participate, provided they have received proper training.

7. CONSULTANT SERVICES, EFFORTS AND DELIVERABLES

Consultant shall provide the following as part of this engagement. The details of each component are outlined in this SOW, and within the Business Requirements.

• Project Management and Documentation – The various administrative efforts and documentation to implement this system / project.

• Electronic device, power supply, and mounting.

• Hosted Application Software – The latest software version, including any related application software or modules required.

• Other Related Software – This includes all software utilities, report writers, workflow software, development tools, hardware drivers, etc., that are required to operate and maintain the application software.

• Annual Maintenance – The annual maintenance and support for a minimum of five (5) years for all software that is being licensed.

• Provision, Install, Configure, Test, and Deploy the software and hardware – The services required to install, set-up and configure all software and hardware products.

• Software Interfaces and Reports – All electronic interfaces between the new system and OCTA’s existing application systems (GTFS), as well as the required reports as defined in the Business Requirements.

• Training for OCTA resources (Section 6, above).

• Organizational Change Management (OCM).

8. CONSULTANT TEAM

Consultant’s personnel shall accept the following as part of this engagement.

• Consultant’s resources shall accept the condition that scheduling flexibility is required since OCTA’s activities are driven by a combination of internal and external dependencies.

• Consultant’s resources shall work closely with OCTA PM to plan the expected work for each reporting/billing period. All project work shall be coordinated through the OCTA PM.

• Consultant may use offshore resources where appropriate; however, the OCTA PM shall be aware and approve of the use of offshore resources. Consultant assumes full responsibility for the quality of the resultant deliverables and the timeliness of their delivery.

• Consultant’s resources shall backup all work products/artifacts at the end of each workday onto an OCTA designated storage device (most likely a SharePoint repository or shared network drive setup for the Project Team). The intent is to create a collaborative work environment, providing visibility to work in progress.

• Consultant’s personnel assigned to work on OCTA projects are responsible for the proper care of OCTA’s facilities and equipment made available to them throughout the term of the contract.

• Consultant shall provide all phone and desktop-sharing conference calling dial-in numbers and Uniform Resource Locators (URLs).

• Consultant’s resources shall respond to voicemail, email, and text messages within a reasonable amount of time, but under no circumstances shall the amount of time exceed two (2) business days. If a deadline or ‘respond by’ date/time is indicated in a communication by OCTA, it will be expected to be met unless it is considered unreasonable by Consultant.

If so, Consultant shall immediately notify OCTA, and provide a reasonable deadline that would need to be approved by OCTA.

9. BUSINESS NARRATIVE

The new system will serve as OCTA’s first TSP solution in Orange County. The new system will be remotely accessible by OCTA and partner stakeholders to manage and monitor TSP operations. Users will have real-time access to communication status, TSP performance metrics, and reporting tools.

Key system features shall include:

• A centralized repository for managing and monitoring transit, traffic, and signal operations with TSP capabilities.

• Customizable dashboards and reports to provide real-time key performance indicators.

• Automated alerts and notifications for critical failures that will impact TSP operations.

Once TSP is enabled, OCTA and partner stakeholder users will have the capability to evaluate the effectiveness of the implemented TSP business rules and their impacts to signalized intersection operations. All data collected from third-party or other integrated platforms, traffic signal controllers, and relevant connected vehicle sources will be securely stored and maintained, ensuring availability and reporting purposes. The TSP system will integrate bus, traffic, and signal operations to improve bus service reliability and provide actionable data insights, thereby enhancing efficiency for OCTA and its partner stakeholders.

10. CONTRACT TASKS

The following Tasks correspond to contractual payment schedule.

TASK 1 – PROJECT PLANNING AND MANAGEMENT

Consultant shall designate a PM, who shall be the single point of contact for Consultant. The administrative project documentation, deliverables and actions (listed below) shall be produced, maintained, and made available by Consultant each week for OCTA to ensure accuracy and completeness. Adequate time shall be allotted within the schedule for OCTA’s review of project documentation, revisions to be made by Consultant, and final approval by OCTA (including potentially the Project Sponsors, and Project Owners, when applicable) prior to the deadline of each document and deliverable. Upon approval, work will be authorized.

Project Schedule

• OCTA preference is to use Microsoft (MS) Project 2019. The schedule shall identify all tasks in sufficient detail to understand critical path. The tasks shall identify Resources (and Owners if applicable), Start- and End-Dates, Duration of tasks, and Predecessor relationships (whenever applicable). The schedule shall indicate the tasks for which OCTA is responsible.

• The project schedule shall need to incorporate OCTA-specified modifications, including duration and start-date modifications, as necessary, to align with their regular work-day activities, business cycles, holidays, and other work-day constraints for specific OCTA personnel who will be assigned to work on this project.

• The initial draft project schedule shall be submitted to OCTA with the Project Proposal.

The project schedule may be further revised during the initial Planning phase, which shall include insertion of OCTA-specific tasks. Then, toward the end of the Design phase, the final project schedule will be approved by OCTA and then baselined to permit identification of future modifications to the schedule. The project schedule shall be updated weekly by Consultant’s PM to accurately identify percent (%) physical work complete, or % effort complete (whichever is applicable).

• Cost. The applicable costs/fees shall be identified on the project schedule in a “Budget” column. Subsequently, “Amendment # ‘x’” columns shall be added, as necessary, to reflect any amendments established during the project lifecycle. “Invoice # ‘x’” columns shall be added, as necessary, for each project invoice. The amounts reflected within these columns shall align with the invoicing payment schedule to accurately reflect monies due based on percent (%) Complete or Milestone (whichever is applicable).

Alternatively, the Budget and Cost information may be managed within a separate Microsoft Excel workbook, approved by the OCTA PM, which must tie to the Project Schedule for the purposes of tracking efforts completed, and their respective payments.

Payments shall be reconciled against the project schedule. All invoices shall be accompanied by a current project schedule to show the monies tied to the project schedule.

Roles and Responsibilities (R&R) Matrix

• This matrix is to be structured in the form of a RACI (Responsible, Accountable, Consulted, Informed), including Resource Name, Title, Role, and % Allocation to the project. Each project document and deliverable shall be identified in the RACI by phase.

This matrix shall also clearly define Consultant’s lines of communications during the project.

Change Orders

• If there are any modifications to Scope, Resources, Budget, or Schedule, Consultant is required to submit those requests and obtain approval from OCTA in advance of the work being initiated. The Change Orders shall reflect all additions, deletions, or modifications. Consultant shall provide a detailed report for each required change including the issue number (#), title, date identified, description, alternatives, recommended alternative and impacts to schedule, budget, and resource for the recommended alternative.

Issues, Risks, Action Items, Bugs, Future Enhancements Log (aka Item Log)

• The log shall include: item Type, Title, Date Opened, Date Updated, ETA, Opened By, Priority, Description, Assigned To, Status, Comments (updated weekly / date-stamped), and Date Closed. Risks shall be quantified (Occurrence: probability / impact; Control:

effective / efficient) in a Risk Assessment. An Item Log shall be developed and maintained by the Consultant, and shall be accessible to OCTA, during post-implementation for system item-logging management purposes.

Project Status Reports

• Submitted to OCTA twice each month (and more frequently if the project is off-schedule, off-scope, or off-budget) and it will be received by noon (Pacific Time) on the Friday it is due. The format for progress reporting can be in Consultant’s format. Efforts shall be delineated within the status report for each workgroup (aka project workstream) to permit a clear representation of the individual efforts. The Consultant shall present a Project Status Report template that will be used during the Project for OCTA PM approval prior to submitting the reports. The following elements must be included within the report:

o Overall Project Status (Green, Yellow, Red). Green = project is on-track with schedule, budget, scope and/or resources, no major issues; no minor issues that will not be resolved in short-term; nothing to escalate. Yellow = project is at risk of slippage with one or more area of schedule, budget, scope, and/or resources;

deviation could be 10% to 20% of plan; the project team has plan to correct the deviation. Red = project is slipping in one or more areas of schedule, budget, scope, and/or resources; management assistance is needed to re-set project.

o Trend (Steady, Improving, Degrading). The Trend is a forecast of the probable change in Status within the upcoming one (1) to two (2) weeks.

o Tasks Completed during the reporting period.

o Tasks In-Progress.

o Next Steps / Work Planned for the next reporting period including, but not limited to, those identified per the baseline project plan.

o Resources utilized since the previous Status Report, or those Resources needed during the next reporting period.

o Project Issues, including description, viable solution(s), owner, deadline, impact if not addressed by the deadline.

o Identification of Short-Term Risks, thirty (30) days or less that affects the project’s progress, deliverables, or milestones. The risks shall be noted, o potential solution(s) identified, action required for resolution, and estimated duration of solution.

o Identification of Long-Term Risks, sixty (60) days or more that affects the project’s progress, deliverables, or milestones. The risk shall be noted, potential solution(s) identified, and action required for resolution, and duration required.

Project Meetings

• Consultant’s project team shall co-lead the Kick-Off meeting with OCTA’s PM. This shall be scheduled to occur after the signing of the contract and the acceptance of the project schedule.

• All Consultant’s identified team members or their alternates are required to attend the meeting, unless approved by the OCTA PM. Consultant’s PM shall discuss the project approach (describing how the project will be successfully completed, and the implementation approach), the project’s goals and objectives, scope, out-of-scope items, work plan, timeline, and team member roles and responsibilities during the meeting, and allow time for questions.

• Consultant’s PM shall co-lead the ongoing Project Meetings, including the Kick-Off Meeting, and Status Meetings with OCTA’s PM. The meetings shall be held at OCTA’s facility in Orange, CA, but Consultant’s team may attend the meeting by tele-conference.

The purpose of the meetings shall be to review project status, project schedule, Item Log, resolution of issues, assess risk, determine corrective action as required, and to discuss future efforts. At a minimum, meetings with the OCTA’s project team shall occur once every month to discuss project progress. Project Status Meetings with Key Stakeholders and Management shall occur at least every two (2) months, as deemed necessary by the OCTA PM. Attendance will be taken at each meeting.

• Ongoing (working) Meetings shall primarily be led by Consultant PM, or Consultant Leads throughout the course of the project lifecycle.

• Meeting Agendas. The content shall include a list of Topics, Start- and End-time for each Topic, Presenter, Follow-Up Items from previous meetings.

• Meeting Minutes. The content shall include a summary of the discussion, Decisions, and Action Items. Minutes shall be distributed after the meeting to the meeting attendees (within one (1) business day).

• Ancillary Project Deliverables. Detailed examples of any/all project-specific deliverables that shall be produced by Consultant during the project engagement shall be provided to OCTA in advance of the start of project to permit OCTA adequate time to assess the reasonableness of the content and approve the format and proposed content.

• Documentation Repository. OCTA will establish a MS Teams or MS SharePoint site for the project, to which Consultant shall have access. All ‘master’ versions of documentation shall be posted to this site by Consultant. The documents shall be

‘checked-out, and –in’ to provide control, versioning, and collaboration during the process of drafting the documentation. The project documentation must always be maintained within the Repository.

• All Deliverables / Documentation must be submitted to OCTA in digital formats that are compatible with the OCTA Microsoft Office suite, or as approved by the OCTA

PM.

Objectives Effective and efficient administration of the project.

Complete and accurate information.

Transparency.

Readily accessible information for the appropriate resources.

Deliverables Project Schedule Roles and Responsibilities Matrix Change Orders Item Log Project Status Reports Kick Off Meeting Various Meetings Meeting Agendas Meeting Minutes Ancillary Project Deliverables Documentation Repository Documentation Formats

TASK 2 – REQUIREMENTS GATHERING

Consultant shall gather and document OCTA and agency stakeholder requirements, including use-cases, from OCTA and stakeholder personnel to ensure the system is configured in a way that meets the needs of OCTA processes and policies. This includes gathering necessary equipment cutsheets for the traffic signal controllers and communication switches identified in Section B6 of Attachment A for OCTA approval prior to procurement, configuration, and installation.

Business Analysis Joint Application Development (JAD) sessions shall be conducted to gather the Requirements Documentation. This includes both the functional and the non-functional requirements. The JAD session must ensure consensus from cross-functional teams (business, technical and testing teams) by documenting complete, non-redundant, prioritized, and valid features, functions, and requirements. The requirements shall describe the problem, business case, process, and procedures (input, process, output), data model, and any other pertinent information. The ultimate deliverable shall provide the business solution that will be used for the Build/ Configuration, and by the Test Team. The final Requirements deliverable must be approved by the OCTA Business and Technical teams.

Objectives Consensus among cross-functional teams.

Complete, non-redundant, prioritized valid list of features, functions, and requirements.

Define all business rules.

Define the business processes and procedures, including workflow routing, alerts, notifications.

Define all data interfaces from and to solution.

Define the user screen views.

Define the reports required.

Documentation that can be used during Build/Construction and Testing.

Deliverables Hardware cutsheets for approval.

Detailed and approved Requirements documentation in the form of a Requirements

Matrix.

TASK 3 – DESIGN AND PROCUREMENT

Design reviews shall be conducted during the Design Phase to evaluate progress, as well as to evaluate the technical adequacy of the design and conformance with performance, usability, and OCTA/agency stakeholder technical standards. Prior to each review, Consultant shall submit a design review package that includes the design and other information required for the review, including an architecture topology diagram, data flow diagram, hardware, and software versions, network, and security diagrams.

Unless Consultant proposes an alternate approach, which is acceptable to OCTA, design review shall include the following:

• Preliminary Design Review

• Final Design Review

Preliminary Design Review is designed to review the adequacy of the selected design approach and evaluate requirement conformance. The Preliminary Design Review shall represent approximately sixty-five percent (65%) completion of the total engineering effort for the system.

At a minimum, the Preliminary Design Review shall include:

• Detailed technical descriptions of the system’s major components, allowing a thorough understanding of the implementation of the proposed System Components.

• Interface diagrams.

• Software system level flow charts, if applicable. Software data backup and recovery procedures.

Final Design Review shall be conducted when detailed design is complete. The Final Design Review shall determine whether the detailed design will conform to the design requirements.

Data submitted for the Final Design Review shall be updated to a level of detail consistent with the completed design and submitted for the Final Design Review. At a minimum, the Final Design Review shall include:

• Latest revisions of the drawings and documentation submitted for the Preliminary Design Review.

• Data documentation at the second level, including all software development.

documentation available or used in Consultant’s design process, consisting of structured data flow diagrams, event tables and/or dialogue diagrams (as available) to the lowest level of decomposition with software module descriptions (or elemental process descriptions) in structured narrative format. The second level of software documentation is one level above source code.

• Review of Consultant’s final interoperability and integration with onboard systems, including verification and test plans.

The Design Review shall be to acquaint OCTA and OCTA stakeholders with Consultant's intended design and procurement activities, and resolve external interfaces. At a minimum, the Design Review shall accomplish the following:

• Confirm Consultant's management team and the scope of supply of sub-suppliers.

• Provide narrative descriptions of the major subsystems proposed by Consultant.

• Provide narrative descriptions of TSP business rules proposed for Project corridor, including recommended timing modifications to achieve the proposed operation.

• Identify information needs and decisions required from the agency.

• Confirm that Consultant is familiar with the intended operations and maintenance environment.

• Provide block diagrams showing functionality and interfaces between System Components and elements, such as OCTA’s GTFS feed, that are not to be provided by Consultant but affect the system provided by Consultant.

• Review the solution design, including block diagrams and features.

• Review artificial intelligence (AI) capabilities with full descriptions of how the solution incorporates AI technology. Details should include learning models, diagrams, legal/ethical considerations, integration(s), deployment, data sources, data handling, data security/privacy, data ownership and explainability (decision making) features.

• Consultant’s staff shall work closely with OCTA to accurately complete the application implementation and configuration, as well as all related services. Consultant shall also answer questions posed during the application implementation process. All decisions shall be documented.

• Consultant’s technical staff shall work with OCTA’s security and project team to review security requirements in the new hosted environment.

• Where necessary, Consultant’s technical staff shall assist in evaluating consultant architecture and configuration as related to security and access.

• The website must be using https.

Objectives Perform necessary documentation on how solution will be configured/set up and implemented, including security needs.

Answer and document application set up questions during the application implementation process.

Procure solution and supporting field equipment per approved design.

Deliverables Design Documentation that includes all implementation and configuration changes.

A comprehensive Security Plan, which is easily implemented via standard security tools, and which requires minimal maintenance to maintain OCTA’s desired level of security.

Procurement of approved signal equipment.

TASK 4 – CONFIGURE / BUILD

Consultant shall build / customize / configure the application to ensure compatibility with the system requirements. Consultant shall procure the traffic signal equipment and deliver to the respective agency stakeholders, who will be responsible for configuring and installing the traffic signal controllers and communication switches in preparation for the TSP solution. Consultant shall be responsible for implementing any TSP-related parameters and configurations into every traffic signal controller following the installation by agency stakeholder resources. Changes shall be documented and reviewed with OCTA.

Execute the build and configuration of the solution in test environment.

Objectives Perform application build according to the requirements.

Fully configured, installed and operational solution in a test environment Create all identified data interfaces and reports.

Deliverables Documented System Configurations, including deviations to the system requirements.

Test environment solution installed, configured, and developed addressing all listed.

TASK 5 – TEST

Consultant shall be required to thoroughly test the application to ensure stability, performance, and system functionality prior to making the system available for OCTA testing efforts.

Consultant shall develop the Test Plan, Test Cases, and Test Scripts (if automated testing is being conducted).

Test Plan Consultant shall develop a Testing Plan for the entire project. The Testing Plan shall address each type of testing.

• The Testing Plan shall include who is conducting the testing, what type of testing shall be conducted, when the testing shall be conducted, how long the testing shall be performed, where the testing shall be performed, the purpose of the test (why), and how to conduct the testing.

• The testing shall include unit-, system-, integration-, load-, stress-, functional-, non-functional-, device-, and network-testing.

• Testing may include backup and restore, and disaster recovery procedures.

• Consultant’s technical members shall assist OCTA and agency stakeholder project staff as needed, to complete all User Acceptance Testing.

Test Cases The Test Cases is a set of conditions or variables under which a Tester shall determine whether a system under test satisfies requirements or works correctly. The process of developing test cases can also help find problems in the requirements or design of an application. The Test Cases shall include a Description, any assumptions or pre-conditions, the steps, and the expected result.

User Acceptance Testing (UAT) OCTA will conduct UAT of all system functionality. The duration of UAT may be determined by a specific project. It is recommended the duration of UAT be approximately five (5) weeks.

Consultant shall be responsible for supporting the UAT efforts, including:

• Clarifying system functionality.

• Troubleshooting and correcting errors and invalid results.

• Updating system documentation (as applicable).

Objectives Testing efforts are thorough, effective, and efficient.

All pertinent resources are clear on the testing process and efforts that will be completed.

Acceptance Test success criteria is defined.

Bugs are documented, prioritized, and resolved.

Any necessary corrections or configuration changes are completed.

All planned testing is completed successfully.

Deliverables Test Plan.

Test Cases (and Test Scripts if automated testing is being conducted).

Testing Results.

Defect logging in Item Log.

Stakeholder sign-off on the completed testing.

TASK 6 – TRAIN

Consultant shall develop a Training Plan for the entire project. The Training Plan shall include the following information: who is conducting and attending the training, what the training will include, when and where the training will be conducted, the purpose of the test (why), and how the training will be conducted.

• Approved training artifact that describes the mediums that will be used (videos, manuals, classes, etc.).

• Comprehensive training documentation shall be provided covering all system features and functionality for specific use by OCTA users, as well as partnering agencies and non-OCTA users identified in the scope of the Project. Detailed manuals, outlines, and lesson plans shall be prepared and submitted for approval. Instructional materials shall address all relevant equipment, system features, and functionalities to ensure full comprehension. The documentation shall be provided in both digital and print formats and shall include clear descriptions and explanations of all features and functions of the application, step-by-step guidance on how to operate the application, and common troubleshooting techniques. Training materials shall also include video tutorials and concise Quick Reference Guides to support both OCTA and partnering agencies in effectively utilizing the system.

• Consultant shall be required to provide training for IT (technical training), and System Administration, Super-Users, and End-User training for OCTA, agency stakeholders, and OCTA contracted employees. Specific training topics shall be focused on the audience, for example:

o Basic administration for all users o Customization of user interface and customer fields o API or batch process integration with data specialists o Configurations (i.e. TSP business rules) for administrators o Updates and Patch Release process with IT personnel

• Training shall be conducted at OCTA’s administrative offices in Orange, CA. Other methods shall require OCTA approval.

• Consultant shall allocate sufficient training time to ensure all trainees achieve the necessary confidence and competency to perform their assigned job functions. The Consultant shall develop and submit a comprehensive training plan that provides a minimum of sixteen (16) hours of instruction, delivered over a four (4) weeks prior to User Acceptance Testing (UAT), and an additional four (4) week period prior to system go-live. Each training period shall consist of four (4) training days per week, with two (2) hours of instruction per day. The proposed training delivery method, schedule, and supporting materials shall be submitted to OCTA for review and approval prior to implementation. OCTA will provide the Consultant with a list of users to be included in the training plan.

Objectives Ensure that the OCTA team members have an understanding to internally manage and support all technological components involved in consultant’s solution.

Provide training to OCTA project team on how to use system features and functionality.

Deliverables Training Plan that denotes the people providing the training, and the resources attending the training, the objectives and expectations of the training, the content that shall be provided, schedule and location, and the purpose of the training.

Training Documentation, including Quick Reference Guide, manuals, outlines, lesson plans, etc., either paper or digital, for each training session.

TASK 7 – DEPLOY

Consultant shall be responsible for the implementation / deployment of the application into a Production Environment for OCTA to use it as a production system. The Go-Live date is the date OCTA will commence using the application as a Production system. Consultant shall coordinate closely with OCTA stakeholders to ensure the deployment of traffic signal devices is completed prior to moving forward with the TSP solution implementation.

Go-Live Assessment Consultant’s PM shall prepare a Readiness Assessment Report for submission to OCTA’s Project Sponsors. This report shall identify any incomplete efforts, tasks, and bug fixes and prioritize their importance from a technical perspective to the cutover date, as well as the plan for addressing the incomplete tasks in the post go-live phase. Contingency plans for Go-Live will be documented.

Go-Live Plan A meeting shall be held prior to production deployment to review the Implementation (Deployment) Plan. The Implementation Plan shall include who is participating in the deployment, what the deployment will encompass, when the deployment efforts/tasks will be conducted, where the deployment will be performed.

• Consultant and OCTA PM shall work with the project teams to draft an appropriate Schedule that includes the following: tasks, durations, resources, start- and end-times, status reporting, and production Validation Tests (to ensure the deployment was completed successfully). This shall be included within the Implementation Plan.

• A Deployment Checklist must be documented to ensure all changes are moved to production accurately and completely.

• A Support Plan must be documented to follow a structured time allocation, with defined days of service to be provided each week. Service level expectations will be highest during the initial phase and will be systematically reduced over time.

Specifically, support will be provided five (5) days per week during the initial go-live period, tapering to three (3) days per week after the first month, and subsequently to one (1) day per week by the end of the third month, unless otherwise agreed upon by OCTA.

• OCTA requires that all changes to the Production environment be approved by the project sponsor, business owner and OCTA PM.

Go-Live / Deployment, Execute the build and configuration of the solution into the production environment.

Objectives Complete Readiness Assessment Report.

Identify outstanding tasks and identify estimated completion dates.

Prepare the implementation efforts.

Approved Change Control.

Plan for support-related activities.

Create schedule.

Determine Production Validation tests.

Fully configured, installed and operational solution in a production environment.

Create all identified data interfaces.

Evaluate documented Validation Test scripts.

Summarize test script processes that did not yield desired results.

Review and prioritize pending defects.

Evaluate system setup and process decisions to achieve desired results.

Completion and sign-off on testing.

Identification of required action items for project completion.

Production environment solution installed and configured addressing all listed requirements (including all identified interfaces).

Deliverables Readiness Assessment Report.

Draft the Implementation (Deployment) Plan.

Approved Implementation (Deployment) Plan.

Go-Live Schedule.

Deployment Checklist.

Production Validation Tests.

Go-Live Support Plan.

Approved Change Control.

Final Acceptance, consultant shall assist OCTA in evaluating results of Production

Acceptance Testing. Based on the outcome of this testing, decisions related to setup and processes may need to be re-evaluated in order to achieve desired results.

Approved Validation Test scripts.

Updated System Documentation (based on deployment revisions).

Updated Items Log that with any remaining defects that must be addressed.

Deployment Acceptance.

TASK 8 – POST-DEPLPOYMENT SUPPORT / WARRANTY

OCTA expects Consultant to provide system warranty. Following system acceptance of the application, Consultant shall warranty their work to conform to requirements set forth in this SOW, for a minimum of sixty (60) calendar days after final software is deployed to production at Go-Live. Consultant shall correct and repair, at no cost to OCTA, any defect, malfunction, or non-conformity that prevents the application from performing in accordance with requirements set forth in this SOW.

• The warranty period shall begin on the Go-Live date if all bugs and defects previously reported during testing have been resolved to OCTA’s satisfaction. Go-Live constitutes the date when the solution is formally accepted in writing and ready for deployment in OCTA’s production environment. All bugs, defects, and issues.

• Previously reported during testing must be fixed to OCTA’s satisfaction before the solution can be formally accepted for Go-Live and before warranty can begin. A test in production is not considered Go-Live.

• If minor issues remain and it is mutually agreed by OCTA and Consultant to proceed with the Go-Live in production to allow Consultant additional time past Go-Live to resolve these minor issues that shall not initiate the start of warranty. In this case a separate written acceptance will be provided to commence the warranty period after all remaining issues have been fixed by Consultant and accepted by OCTA.

• Consultant shall provide Help Desk Services to troubleshoot and resolve system issues or questions. Consultant shall provide a support phone number and website where issues can be raised, documented, managed, and monitored.

• Consultant shall develop and submit a comprehensive post-deployment Support Plan to OCTA for approval, to accompany the application. The Support Plan shall cover a five

(5) year period following deployment and shall include provisions for application stabilization, limited enhancements, and ongoing maintenance. The Support Plan should be structured as a phased approach, with the highest allocation of support efforts in Year 1, followed by a progressive reduction in each subsequent year. The plan shall include a total number of hours reasonably proposed by Consultant and agreed to by OCTA to be allocated over the five (5)-year term.

• Consultant shall clearly define the annual support schedule and associated hourly allocations in the submitted Support Plan, which must be incorporated into the overall proposal.

Objectives Ensure resolution of all pre-Go-Live defects and system issues to OCTA’s satisfaction.

Support system functionality in alignment with the SOW during the warranty period.

Deliver Help Desk services for issue resolution and end-user support plan ongoing support clearly defined.

Provide access to a support phone line and web portal for issue tracking.

Provide a minimum 60-calendar-day warranty beginning after Go-Live and final system acceptance.

Develop and submit a Support Plan.

Deliverables Help Desk contact information, web-based tracking tool, Help Desk services and software fixes, where appropriate.

Regular installation of software patches or releases to the application.

11. ATTACHMENT A: HARBOR BLVD TSP REQUIREMENTS

This section includes an outline of the various worksheets within Attachment A: Harbor Blvd TSP Business Requirements.xls.

A1: VENDOR RESPONSE INSTRUCTIONS

Definitions for Consultant Response to the Business Requirements:

A2. FUNCTIONAL AND NON-FUNCTIONAL REQUIREMENTS

Consultant shall submit response to the Requirements in Microsoft Excel (.xls) format with Consultant’s proposal. Provide a response for each individual functional and non-functional requirement relevant to how Consultant’s system meets the respective requirements.

The figure below is a screen shot of the Requirements List in the Microsoft Excel file. OCTA’s requirements are organized by Category, Sub-category / Process, and Priority. Consultant is expected to review these requirements in detail and indicate their understanding by populating the proposed system’s capability, method to implement, costs for customizations, and third-party software, and any relevant comments and assumptions (columns G through L for functional requirements and columns F through K for non-functional requirements of the Requirements Microsoft Excel file).

• Proposed Solution’s Capability: Does the solution meet the requirement?

• Method to Implement: How is the requirement achieved?

• Software Customization Costs & 3rd Party Software Costs shall be provided if the requirement shall be accomplished by implementing a software customization or third-party software. If a software customization or a piece of third-party software is proposed to satisfy multiple requirements, then the cost by line item is not required. Instead, Consultant shall reference the customization, or third-party software in their requirements response and include the customization or third-party software and interface development costs in the Price Summary Sheet (Exhibit B).

• Consultant Comments may be added to Consultant’s response for any requirement. If customization or partial customization is indicated, then Consultant shall explain level of effort and risk. If future release is expected, Consultant shall indicate target release number and date within project timeline. If third-party software is proposed, Consultant shall indicate which software.

• Consultant Assumptions shall be identified and included, as applicable.

A3: VENDOR QUESTIONNAIRE

Use the table to identify software and hardware requirements, as well as software support responses and other system highlights. Use the table to indicate a clear response to the project implementation tasks and deliverables under Section 10 of the SOW, “Contract Tasks”. This table shall be submitted in Excel format as part of Consultant’s proposal.

B1: REPORTS

For the purpose of defining the…