ODOT_525-20_-_IBI_GROUP.pdf

Technical Proposal | 525-20

Advanced Traffic Management Systems

Submitted to Ohio Department of Transportation by IBI Group July 10, 2019

Photo by Jonathan Rivera

Invitation No.: 525-20 Location: Statewide - Central Office Commodity: Advanced Traffic Management Systems Pricing: http://www.dot.state.oh.us/Divisions/ContractAdmin/Contracts/PurchDocs/525pricing.xls

REQUEST FOR PROPOSAL (RFP)

State of Ohio, Department of Transportation

Office of Contract Sales, Purchasing Services Jack Marchbanks, Ph. D., Director

Proposal Submission Deadline (Proposal Opening Date):

June 27, 2019 at 2:00 p.m. eastern time

Company Name:

Federal Tax ID No.:

Physical/Mailing Address: Remit to Payment Address:

Street Address:

P.O. Box:

City:

St:

Zip:

Contact Person and Phone Number:

(authorized to answer questions about your company’s bid)

E-Mail Address (required):

(person who filled out bid)

E-Mail Address (required):

(for notification of future bid opportunities)

Telephone Number 800 Number Fax Number

Return Properly Marked, Complete Proposals To:

Ohio Department of Transportation Office of Contract Sales, Purchasing Services, 1st floor 1980 West Broad St. Mail Stop 4110 Columbus, OH 43223

BIDDERS MUST SUBMIT ANY QUESTIONS, CLARIFICATIONS, OR INQUIRIES REGARDING THIS RFP

VIA THE FOLLOWING WEBSITE:

http://www.dot.state.oh.us/Divisions/ContractAdmin/Contracts/Pages/PurchasePBQ.aspx

Submitted by:

IBI Group Engineering Services (USA) Inc.

(dba M-E/IBI Group, OAKS No. 55958)

8101 North High Street, Suite 100

Columbus

Ohio 43235

Mike Haas 503-747-8352 mike.haas@ibigroup.com mike.haas@ibigroup.com

614-818-4900 614-818-4901

8101 North High Street, Suite 100

Columbus

Ohio 43235

31-1442777 http://www.dot.state.oh.us/Divisions/ContractAdmin/Contracts/Pages/PurchasePBQ.aspx

IBI Group Engineering Services (USA) Inc. is a member of the IBI Group of companies

IBI GROUP

8101 North High Street, Suite 100 Columbus OH 43235 USA tel 614 818 4900 fax 614 818 4901 ibigroup.com

July 10, 2019

Mr. Jack Marchbanks Director Ohio Department of Transportation 1980 West Broad St. Mail Stop 4110 Columbus, OH 43223

Dear Mr. Marchbanks :

RFP 525-20: ADVANCED TRAFFIC MANAGEMENT SYSTEMS

IBI Group is pleased to submit our Technical proposal for RFP 525-20. Our response fully complies with the terms and conditions as defined in the Request for Proposal document and Addenda 1-5. IBI Group certifies to the best of our knowledge we have no real or perceived conflicts of interest in submitting this response. IBI Group attests that the preparation of this response is conducted fairly and without collusion or fraud.

Mike Haas is our proposed Vendor Project Manager and main contact for this project.

Mike Haas ATMS Program Manager

T: 503-747-8352 F: 416-596-0644 E: mike.haas@ibigroup.com

Thank you for the opportunity to submit this response. If you have any questions concerning this proposal, please feel free to contact Mike Haas, Project Manager.

Yours truly

IBI GROUP

Mike Haas ATMS Program Manager

STATE OF OHIO, DEPARTMENT OF TRANSPORTATION ADVANCED TRAFFIC MANAGEMENT SYSTEMS

Table of Contents

A Project Approach and Implementation/Staffing Plan

1.0 Project Approach and Implementation

2.0 Staffing Plan

C Technical Proposal Response to Requirements

APPENDICES

Attachment A: Optional Value Added Ideas Attachment B: Resumes Attachment C: inSIGHT ATMS Platform Attachment D: inSERVICE Patrol Platform Attachment E: Road Conditions Reporting System Attachment F: inFORM ITS Asset Maintenance Management Platform

A Project Approach and Implementation/Staffing Plan

1.0 Project Approach and Implementation

The intent of the Project Approach and Implementation Section is to provide the following information for Ohio Department of Transportation (ODOT) review:

1.1 Project Understanding (EC # 7) - partial

coverage): Submit a statement of our understanding of the project.

1.2 System Description (EC # 8): Describe a system that

will exceed ODOT’s needs and standards.

1.3 Project Management (EC # 7 & # 9): Describe

IBI Group’s capabilities to deliver the project scope including our management plan.

1.4 Service Level Agreement (EC # 10): Demonstrate that

IBI Group’s approach to SLA’s meets ODOT needs.

1.5 Project Schedule and Milestones (EC # 11):

Show a timeline identifying project phases, key milestones, and challenges.

1.6 Implementation (EC # 12 - 21): Address IBI Group’s

approach to project phases listed in ODOT RFP.

1.1 Project Understanding

The Ohio ATMS project represents the System-Foundation for ODOT’s TSMO program for the next decade. Ohio’s transportation infrastructure is critical infrastructure for the State and the Nation. Ohio is one of only four states in the United States that include three metropolitan areas of over two million people and also has major regional and national freight corridors criss-crossing the state with Interstates 90, 70, 71, 75, and 76. In addition, Ohio experiences severe weather conditions that threaten traveler safety and impact reliable transportation system performance.

In the past, Ohio has developed and maintained much of its TSMO software capabilities in house. Successful programs like Buckeye Traffic have given the Department deep insights into their system needs as well as into the process of developing successful software systems. Buckeye Traffic has been in service since 2007 and has reached the end of its useful life.

Moving forward, ODOT has documented their needs along with challenges with the current ATMS solution. After carefully evaluating various alternatives ODOT has determined to procure a commercially available ATMS. Key objectives for this project include:

• Substantial improvement in efficiency and precision of TMC operations.

• Automated event response functionality driven by intelligent decision support algorithms and served to system operators in an intuitive user-friendly manner.

• A solution based upon contemporary best-practice technologies that will avoid obsolescence through ongoing evolution with new and emerging technological advances.

• A working relationship with the selected team that reflects genuine partnership. ODOT is seeking collaboration at all levels through the project and a working relationship that will be built upon mutual respect and trust.

The outcome of this project will be the deployment and maintenance of a mature full-featured ATMS product that will serve Ohio travelers for the next decade. Key success criteria will include a proven product as well as a proven team that is committed to a long-term partnership working with Ohio over the life of this important project.

1.2 System Description: IBI Group inSIGHT ATMS

IBI Group will provide inSIGHT ATMS, our integrated ATMS platform, to meet and exceed the ODOT requirements. IBI Group’s integrated TSMO platform is a nationally proven, state-of-the-art software solution. Over the past decade, IBI Group has become a one-stop-shop for ATMS capabilities as well as other complementary TSMO systems. These modular solutions will meet Ohio’s needs today and into the future. The illustration below is a simplified depiction of IBI Group’s integrated suite of TSMO products.

IBI GROUP | TECHNICAL PROPOSAL

inSIGHT is the premier software platform for managing and operating transportation networks. It includes a browser-based user interface developed using the latest widely adopted web technologies, approaches and frameworks, allowing operators to perform all event and ITS infrastructure management functions through a single, seamless portal. Key operational functions include unplanned and planned event management, decision support and automatic response plan generation, integrated response management, external events/alerts integration, dynamic message sign (DMS) management, lane control sign (LCS) management, highway advisory radio (HAR) management, CCTV camera control, road weather information systems (RWIS) integration, automatic weather event detection, traffic data sensor integration, traffic data aggregation and fusion, travel time calculation and display management, automatic incident and queue detection, weather and traffic data driven variable speed limit sign (VSLS) management, advanced ramp meter management, and truck parking systems integration. inSIGHT provides features supporting the dissemination of real-time information via DMS, HAR, Email, API and SMS, and system directed coordination with internal and external stakeholders such as agency maintenance personnel and emergency responders.

The inSIGHT User Interface (UI) is browser based and has been developed using the latest widely adopted web technologies, frameworks and development approaches. The UI allows users to perform all event, subsystem, device and information dissemination management functions through a single, seamless portal, which can be accessed using modern Windows, macOS, Chrome OS, Android and iOS devices, without the need for client-side software installation.

The UI is capable of handling a high number of concurrent users, due to incorporating scalable back-end services and efficient inter-service data exchange, and can be made accessible from anywhere, subject to the availability of an internet connection and secure network connectivity.

Event and response management work flows and capabilities, a focal point of the inSIGHT platform, have been carefully refined through close collaboration with numerous agency partners across the United States, Canada, Europe, South Africa, India and Mexico. inSIGHT platform features have been designed to minimize operator effort and cognitive load, in order to increase operational efficiently and effectiveness, as part of a continuous improvement process. IBI Group views its software products as ‘living’, with the objective of developing and maintaining best in class platforms across the complete spectrum of transportation management and mobility solutions.

Figure 1 inSIGHT Platform inSIGHT

UI API

MS Web API

ITS Field Device Services

MS Windows Services

DMS, PCMS, VSLS, LCS

HAR

CCTV Cameras

RWIS

Traffic Sensors Traffic Probes Ramp Meters Truck Parking Systems Wrong Way Systems

Operational Database MS SQL Server

External

API

MS Web API

Service Patrol App inSIGHT UI HTML5 / Angular

Road Conditions

ITS Field Devices

Authorized Entities

AVL

Services

Parking Services

Mobile App API

MS Web API

Data Integration Services MS Windows Services

GIS

Services Waze HEREInrix NWS

Application Services

MS Windows Services

Mapping Notifications and Alerts Event Management Response Management Weather Event Detection Speed Limit Management Traffic Data Processing Incident/Queue Detection Travel Time Calculation

Lane Reservation

App inSIGHT functionality is provided by back-end services adhering to service-oriented/microservice architecture (MSA) design principals, ensuring that platform services are modular, scalable and inter-operable with future services. This is a leading architectural approach that separates core functional areas into distinct self-contained services, which interact as needed using open-standard protocols (HTTP) and data encoding formats (XML/JSON). Each deployment of the inSIGHT platform may consist of a different combination of back-end services, based on the specific subsystems/devices being managed, and the external systems/interfaces being integrated. inSIGHT back-end services have been implemented as Microsoft Windows services, and internal/external APIs as Microsoft ASP.NET Web APIs (REST, with SignalR/WebSockets for internal APIs).

inSIGHT incorporates Microsoft SQL Server Standard or Enterprise as its operational database, and optionally, as a reporting/ analytics database.

The inSIGHT platform has been designed to be hosted on a virtualized environment, including agency owned private cloud infrastructure and third party cloud hosting services such as Amazon AWS and Microsoft Azure. For third party cloud hosting, a VPN tunnel is implemented to support secure communication between the inSIGHT platform and field systems/devices, over redundant internet connections.

1.3 Project Management

Project Management is a shared responsibility between IBI Group and the ODOT and forms a foundation of communication and trust necessary to allow IBI Group and ODOT resources to unite as a single ATMS Team. Successful ATMS projects must meet requirements and satisfy expectations. The ODOT Project Manager and their IBI Group counterpart will collaborate closely ensuring project deliverables meet ODOT requirements and establishing communication essential to building common expectations across the entire team.

The Project Management section of the proposal describes the tools and processes to be used to control the work to be done.

The primary tool supporting project management is the Project Management Plan.

The Project Management Plan (PMP) will provide a comprehensive framework for how the project will be managed.

The Plan will establish the approach used manage and guide the execution of the tasks. IBI Group will deliver the baseline PMP within ten business days of notice to proceed. The PMP will be amended if needed to meet ODOT’s requirement for a Detailed Project Plan. The IBI Group Team has used the proposed Plan format successfully on numerous projects and recommends this as the starting point for this initial project deliverable.

The Plan will provide the opportunity for ODOT and the IBI Group Team to clearly document project structure, deliverables, and procedures. The Plan will also document decisions about project scope, tasks, and schedule. The Plan will follow the format of a Software Project Management Plan, conforming to the IEEE 1058-1998 standard. The Plan includes the technical and managerial processes necessary to develop software work products that satisfy the project requirements.

The sections shown in the table will be included in the ODOT ATMS Project Management Plan.

I Preface

Purpose

Audience

1.0 Overview

1.1 Project Summary

1.2 Deliverables

1.3 Schedule Summary

1.4 Budget Summary

1.5 Evolution of the Project Management Plan

2.0 References

3.0 Definitions

4.0 Project Organization

4.1 Ket Stakeholders

4.2 Roles and Responsibilities

5.0 Management Process Plan

5.1 Staffing Plan

5.2 Work Plan

5.3 Control Plan

5.3.1 Documentation Control

5.3.2 Change Management Process

5.3.3 Scedule Control

5.3.4 Quality Control and Quality Assurance

5.3.5 Budget Control

5.3.6 Communications Management Plan

5.4 Risk Management Plan

6.0 Supporting Process Plan

6.1 Configuration Management Plan

PMP Table of Contents

1.3.1 Project Management Plan (PMP)

There is not enough space within this proposal to provide an overview of each of the 27 elements of the outlined Project Management Plan. IBI Group would be happy to provide examples of recent PMPs in use on similar projects if this would be helpful in the evaluation process. Key features of the PMP will be addressed to demonstrate a clear and consistent management plan for the work, as requested within ODOTS RFP.

PMP - PROJECT ORGANIZATION

The Project Organization section of the Plan lists all project stakeholders and their relationship to / dependence upon the ATMS project. Roles and responsibilities of the Project Team are also clearly called out. This is where ODOT Support Requirements for the project will be captured. All ODOT Support Requirements are valid only if ODOT agrees to the commitment and is willing and able to provide such support.

The RFP requires that IBI Group identifies any support required of ODOT to achieve the proposed work. IBI Group does not require any support from ODOT beyond what is offered in the RFP. Specific ODOT-led activities that IBI Group believes are consistent with the RFP and in the best interest of the project include:

• ODOT Project Management – Responsible for monitoring the progress of the IBI Group team and ensuring the work done is in accordance with valid project requirements, ODOT needs, and industry best practices. All project submittals shall be provided to ODOT Project Management who will be responsible for circulating documents internally at ODOT, gathering feedback, and communicating or coordinating with the IBI Group team. The ODOT Project Manager is the primary point of contact for the IBI Group team with the ODOT.

• ODOT IT Support – The ODOT IT Support will be responsible for all IT and networking related work is accomplished consistent with State IT Computing Requirements and coordination with IBI Group. They will be primarily responsible for providing, supporting and maintaining the hosting environment upon which IBI Group will deploy the inSIGHT ATMS and any other software platforms.

PMP - MANAGEMENT PROCESS PLANS

The Management Process Plans are the heart of the PMP. They address work execution, configuration management, staffing and other key systems of management guidance and control. To comply with the required format of this proposal the following information that will be included in the PMP is addressed in other sections of the proposal as indicated.

MANAGEMENT PROCESS PLANS ADDRESSED IN OTHER PROPOSAL SECTIONS

• The Staffing Plan is addressed in Section 2.0 Staffing Plan of the proposal.

• The Work Plan is addressed in Section 1.7 Implementation

• Configuration Management Plan is in Section 1.7, in the Configuration Management Activity

PMP - QUALITY CONTROL AND QUALITY ASSURANCE PLAN

Control and assurance of quality in the project are separate but related activities that are addressed together in this section of the Plan. QA/QC applies to all project work processes and resulting products including software, documentation, and services. The quality goals for the ATMS are defined by the performance requirements and service level agreement established for the project.

QUALITY ASSURANCE

The quality of work within the project shall be assured through the application of the standards and best practices defined in IBI Group’s proposal and task orders including:

• Application of the Systems engineering process

• Adherence to PMBOK1 practices for project management including those documented in this Plan

1 Project Management Institute publication: Project Management Body of Knowledge

• Experience with and application of Agile software development methodologies

• Use of widely available commercial off-the-shelf tools including Microsoft development environments, Microsoft SQL Server database instances, VMWare virtualization environments and Microsoft Office tools for project documentation

• The ATMS Test Plan, System Integration Testing, System Acceptance Testing, and Burn-in period provide redundant iterative processes to verify, evaluate, and confirm the delivered NG ATMS capabilities

• Ohio IT policies.

The work invested by ODOT in developing the project ConOps, Requirements, and Request for Proposal, IBI Group’s response, the work undertaken in a separate discovery phase are all elements of the Project approach for NG ATMS that directly impact the Project Quality Assurance. Following the systems engineering process also, inherently, introduces quality control activities at multiple levels of a software systems project as illustrated in the simplified systems engineering V-diagram provided below.

QUALITY CONTROL

Quality Control is both a top-down and a bottom-up practice within the Project. From the top down, all project deliverables are accounted for in the project schedule and include time for internal review, client review, a review meeting when applicable, and time to respond to comments prior to delivering the final product. For larger deliverables, more time and formality is provided with the biggest example being the ATMS itself that includes testing, test documentation, UI demonstrations, and a formal acceptance process.

For interim deliverables, such as design documents, the project manager reviews all prior to submitting and a review cycle is built into the project schedule.

From the bottom-up, each member of the team is familiar with project requirements and evaluates their own work, via unit testing of software or proof reading of documentation, prior to informing project management or technical team leaders that a deliverable is ready for review.

PMP - COMMUNICATIONS MANAGEMENT PLAN

Effective project communication is essential to the success of the ODOT ATMS project. The Communications Management Plan, part of the PMP, includes:

• list of project participants, their roles, and contact information;

• communications tools such as the project SharePoint site and issue tracking software; and,

• recommendations about the appropriate methods of correspondence for various project communications.

A variety of meetings and workshops will be conducted throughout the project. Meeting dates will generally be shown on the project schedule but may be adjusted and finalized via email to accommodate participant availability. Microsoft Outlook will be used to schedule meetings, invite participants, and distribute agendas, attachments, and meeting notes.

Simplified Systems Engineering V-Diagram

GoToMeeting, or other online meeting tools as agreed to by ODOT and IBI Group will be used at all meetings where remote participants will be engaged. Meeting agendas will be distributed in advance of meetings and meeting notes will be documented by IBI Group and distributed within two business days of the conclusion of the meeting. Some of the meetings and workshops anticipated for the project include:

• Project Management Meetings: We are proposing these meetings be scheduled once a month. The format of the meeting will be the same as the weekly status meeting but provide more time for discussion and cover all agenda items in more detail than may be needed on a weekly basis. At ODOT’s discretion, the attendance of the monthly meeting may be larger than the weekly meeting to allow ODOT stakeholders unable to commit to a weekly meeting to participate in project progress. The primary purpose of the meetings will be to ensure smooth progression of the project against scope and schedule objectives. The Project schedule, risks, dependencies, actions from previous meetings, and upcoming activities will be reviewed at each meeting. The agenda for the project management meetings will follow a mutually agreed upon format.

• Weekly Project Status Meetings: From notice to proceed through initial system acceptance, during weeks without a scheduled Monthly PM Meeting, IBI Group will schedule a regularly occurring weekly call with IBI Group and ODOT project management and other team members as needed to maintain active communications and address emergent project issues in a timely fashion. The format of the meeting will be defined by ODOT and IBI Group Project Managers and will mirror the content and arrangement of the Weekly Status Report.

Develop Draft for Comment (as needed)

Develop and Distribute Workshop Content

Delivery Workshop Develop and

Distribute Deliverables with Document

Review, Comment and Accept

Present Document purpose, overview, & preliminary content Review options for Document format and content, and select preferred approach Gather additional data required Document the comments and decisions

Review and Comment

Draft Comments (if applicable) Workshop Content Key Stakeholders Identified and available

Approved Preliminary Content All Required Data Provided to IBI Group Input on Document Content & Format Recieved All Comments Documented

EXIT CRITERIAENTRANCE CRITERIA

• Document Deliverable Workshop: To increase quality and efficiency in the documentation process IBI Group will conduct interactive workshops for document deliverables. As IBI Group works with ODOT to refine the draft project schedule included in this proposal, workshops will be scheduled to correspond with all relevant deliverable items. Where feasible, workshops will coincide with regular onsite meetings to reduce project costs. The general workflow for document development, regardless of document type, is shown in the figure. Deliverables which require greater degrees of ODOT input may be distributed as a draft for comment as an additional step prior to distributing workshop content.

• Technical Meetings: Technical meetings may be held to address ATMS system capabilities as well as ODOT existing conditions and operational concepts. The agenda of technical meetings will be clearly defined to ensure all required participants are identified and included. The purpose of these meetings covers a broad range of needs from initial introduction to technical or operational concepts to making design decisions on specific system details.

IBI Group Deliverable Documentation Work Plan

• Agile Process Review Meetings: During the Development and Deployment of the ATMS, IBI Group will be following an Agile approach to the configuration and implementation of the ATMS system components. A key part of the Agile method is the use of review meetings which combine elements of system delivery, validation, and design within a disciplined iterative process.

PMP - RISK MANAGEMENT PLAN

The primary activities in risk management are actively identifying risks, documenting identified risks, developing action plans for resolving or mitigating risks, and carrying out those risk resolution plans. The Project Risk List is the tool for managing risks to the project. The proposed format and a screenshot of the Excel Risk List spreadsheet are shown below.

An integral part of this plan includes regular visibility as a part of the project status meetings, as well as immediate visibility via email and/or phone regarding any critical risks that are identified. Risks will be assessed qualitatively and quantitatively, and appropriate risk response strategies will be developed for each. In addressing risks, the management team will be careful to identify any residual or secondary risks arising from risk mitigation and avoidance actions.

Likelihood Selection Options Impact Selection Options

Very Unlikely: 0% - 20% probability Low – if realized risk may have a minor impact on project scope, schedule, or budget

Unlikely: 20% - 40% probability Medium – if realized, this risk may have a moderate impact on project scope, schedule, or budget

Possible: 40% - 60% probability High – If realized, this risk may have a significant impact on project scope, schedule, or budget

Probable: 60% - 80% probability Critical – If realized, this risk will have a major impact on project scope, schedule, or budget

Imminent: greater than 80% Impasse – If realized, the project will not be able to continue until resolved.

Issue: 100% - Risk is realized

1.4 Assumptions and Support Requirements

IBI Group has made no assumptions in preparing this proposal. IBI Group is not requesting any additional ODOT support beyond what is offered in the RFP.

Pennsylvania Turnpike Risk List Example

1.5 Service Level Agreement

IBI Group fully supports ODOT’s need to effectively control the ATMS project and provide objective measures for evaluating the acceptability of deliverables. This entire proposal speaks to IBI Group’s ability to meet and exceed service level agreements established for this project. Due to the page constraints of the proposal we cannot restate proposed service levels here, but refer the reader to the Project Management and Post-Implementation Support sections of the proposal for additional details.

IBI Group has carefully reviewed SECTION V SERVICE LEVEL AGREEMENTS and agrees with the stated approach.

1.6 Project Schedule and Milestones

The Draft project schedule includes critical path tasks highlighted in red. This schedule is a starting point in a conversation with ODOT to refine the work plan. IBI Group and ODOT will work together to craft a work plan that minimizes risk while meeting project needs.

1.7 Implementation

IBI Group has successfully delivered over 20 ATMS solutions on four continents. Partnership is the foundation of our approach.

Close collaboration between ATMS users and system developers guides ATMS configuration and development to achieve the project goals and objectives. We follow an Agile – Systems Engineering approach, endorsed by Federal Highway Administration (FHWA), which minimizes risk and accelerates the delivery of functioning system components.

The benefits of the proposed approach are:

• Collaboration: The nature of the Agile delivery approach followed by IBI Group is collaborative. IBI Group places demands for participation on the entire team from developers to end users and provides improved transparency and communication.

ODOT will see the state of the project over its assembly and IBI Group developers will fully understand the operational context of the components they are configuring or developing.

• It’s proven: In just the last 36 months of ATMS and ATIS projects, IBI Group has used this approach successfully with Pennsylvania, Wisconsin, New York, Massachusetts, Florida, Connecticut, South Africa, Montreal, Alberta, and others.

This approach works.

• Efficiency: By repeatedly applying a successful process, and using demonstrable ATMS products, components, and document sets as the basis for ODOTs solution, the IBI Group Team will deliver a solution that exceeds ODOTs needs and expectations quickly and at exceptional value.

Simple FHWA Systems Engineering Vee Model

LIFE CYCLE TIMELINE

• Low Risk: Primary project risk sources on large systems integration projects are poor communication, system complexity, and team capability. IBI Group’s approach identifies and mitigates all major project risks transparently and directly.

-- Agile methods maximize communication pairing ODOT with the technical team throughout design and implementation;

-- complexity is minimized by reuse of proven system components; and, -- our project team has accomplished multiple successful deployments of similar scope and scale using this proven approach.

• Consistent With ODOT RFP: The proposed implementation approach is entirely consistent with the approach identified within ODOT’s RFP. There are ten phases identified in the RFP Scope of Work. These phases exist already within IBI Group’s implementation approach and are briefly addressed in the following sections of the proposal.

1.7.1 Project Initiation

During project initiation the ATMS Team members, comprised of ODOT and IBI Group staff, will kick-off the project and begin to become acquainted as work gets underway. The key outcomes of this phase are a clear plan of how project work will be accomplished and beginning the process of developing the group into a high-performing Team.

The key activity of the Project Initiation Phase is the Project Kick-Off Meeting to be held within ten business days of NTP and the primary deliverable is the Detailed Project Plan.

1.7.2 Requirements Verification and Documentation

OPERATIONS AND EXISTING CONDITIONS REVIEW

Prior to requirements verification, IBI Group recommends that a review of operations and existing conditions is accomplished.

This review is essential to ensure that the entire ODOT ATMS Team share a common understanding of operational needs, goals, and objectives that will be addressed by the project. This will be accomplished via on‑site meetings and observations to review TMC operations, current ITS assets, communications infrastructure, and TMC organization. The ATMS Feasibility Study, or preferably the Concept of Operations document if it is available, will be used as the baseline definition of operations to confirm the IBI Group Teams understanding of the operational scenarios and clarify any areas that may require additional detail.

This work will directly support successful requirements validation and system design activities. The outcome of this review will be an annotated ConOps, if available, or a simple document identifying any additional needs, roles, or responsibilities that may impact required functionality. In addition, IBI Group will request the information necessary to adequately specify all of the required ATMS interfaces to systems and devices. This review will provide data and context that will improve the quality of the requirements verification.

SOLUTION REQUIREMENTS VERIFICATION

IEEE Well-formed requirements checklist

ODOT’s set of functional requirements, and IBI Group’s responses documented in the Functional Requirements Response Matrix, will be the basis for conducting the functional requirements verification. This exercise will be detailed and extensive to cover the currently identified functional requirements and new requirements that are articulated in the RFP or captured through the TMC operational review.

Each requirement will be examined to ensure that there is a shared understanding of each between ODOT and IBI Group and that the requirements are well formed. As part of a structured examination, we will address what each requirement means, why it is needed, and how it will be delivered. The work will be conducted in a set of workshops. Verification is a two-step process where step 1 is the initial preparation work done in advance of each workshop, and step 2 is the workshop itself. The objective of the workshops will be to ensure the project has a complete set of ATMS solution requirements documented in the

ATMS Requirement Document. Any additions, changes, or clarifications of the functional requirements that results from the requirements verification that significantly impact project schedule, scope, or budget will be clearly identified to ensure they are addressed appropriately.

REQUIREMENTS TRACEABILITY

Some requirements can and will evolve over the life of the ATMS project. Establishing the software management infrastructure early in the project to support those changes proactively is an important step towards managing project complexity and mitigating risk. Traceability details will be managed in an Excel spreadsheet stored on the project SharePoint site. The project traceability matrix includes verified functional requirements, derived requirements (which are identified within preliminary and critical design activities), notes/cross references, and related test case IDs. In IBI Group’s documentation model, the design documents for system components tie back to the operational concepts and the verified requirements to ensure we design and configure what is needed functionally in the manner most operationally relevant. The traceability from use cases through detailed design is shown in the figure included. The figure assumes a ConOps, but the model is not dependent upon a formal ConOps document if one does not exist for the ODOT ATMS.

Functional Requirements

Responses ConOps

Functional Requirements

Validated Requirements

Requirements Traceability Matrix

System Design Document

Software Derived Requirements

System Component

System Acceptance

Final Acceptance

1.7.3 Configuration Management

The Configuration Management Plan (CMP) outlines how the configuration parameters of the system are set and managed by the Project Team. The ATMS is made up of a mix of documentation, commercial software such as operating systems, virtual machines, and databases, as well as existing IBI Group software products such as the core inSIGHT ATMS solution, and software developed specifically for, or significantly enhanced for ODOT’s ATMS. The purpose of the CMP is to identify the procedures to be used in the ATMS project for proper identification of the configuration, control of changes, and records the change implementation status of the major software components and interfaces that comprise the ATMS.

SOFTWARE CONFIGURATION ITEMS

IBI Group will develop a table of inSIGHT ATMS Software Configuration Items (SCI). Following industry standard classifications to provide an organizational structure to identify and track the characteristics / configuration/version of each discrete software product that collectively comprise the ODOT ATMS.

MANAGING SOURCE CODE

Managing source code modifications is a critical part of the software development process and IBI Group’s Software Development Team uses Microsoft Team Foundation Server as its version control software. When a software component is deemed complete by a programmer, the finalized component is “checked in” to the version software and it enters a more formal Unit Testing stage, whereby the component is tested with regards to its functionality, including any data collection, manipulation and migration tasks, prior to being merged into the corresponding release branch. As part of the ATMS software enhancement development stage, the Software Lead provides regular progress reports on any new components being developed, including information regarding the types of defects found and the number of defects identified in the Unit Testing stage.

Project source management includes all source code required to create and install the ATMS (e.g. database scripts, web pages, report templates, source files and configuration files).

VERSION RELEASE GUIDELINES

IBI Group’s Software Development Team has an established, well-defined Version Release (going from Version 1.1 to Version 1.2) process. This process includes:

Version Release Guidelines: This checklist provides the step-by-step procedures to be followed for a Version Release. There are steps leading up to the Version Release (notification, archiving the current version etc.) as well as steps to follow after the Version Release (Regression Testing). If a problem is encountered, the Version Release Guidelines also include steps to roll the system back to the previous version.

Regression Test Procedures: Regression Test Procedures describe a set of tests to confirm that the new version includes the same base functionality as the previous version.

Team Foundation Server (TFS) Guidelines: The Version Release Guidelines include details about labelling versions within TFS.

If ever there was a need to go back to a previous version, the labeled version of the system can be easily checked out from TFS and rebuilt.

IBI Group’s Software Development Team uses Team City and Octopus Deploy for automated release management to internal and client environments and will continue using this for the ODOT deployment.

CONFIGURATION MANAGEMENT OF ATMS DOCUMENTATION

ATMS software documentation are also Configuration Items under this plan. Upon ODOT acceptance of software documentation deliverables, those items will be placed under configuration management. The purpose of applying disciplined configuration management to the software documents is to protect all project stakeholders from unintended and/or unnecessary changes to project scope or schedule.

1.7.4 Design and Development of Customized Functionality

IBI Group will use our standard Software Design Document (SDD) template to develop the ATMS Software Design Document.

The delivery of the SDD will be organized as multiple submissions around the major ATMS components.

IBI Group’s approach to developing each of the SDD submissions is iterative and includes a preliminary design review and critical design review as shown in the IBI Group Design Document Workflow diagram. Note that, for the system components which are available as off the shelf products satisfying ODOTs requirements with only proper configuration required, product documentation will be provided instead of design documentation. Requirement traceability and associated testing will be maintained for all ATMS components.

Finalize SDD Focused on for distribution and review

Develop Design SDD Focused on Software Architecture, detailed user interactions, security interface, secs, database

Develop Preliminary

SDD Focused on Business needs derived requirements, and high level design options

Project Planning and Operations

Review

Development & Deployment

The benefit to ODOT of the proposed approach is that successive passes in greater detail through the design material is the most efficient means of capturing all relevant design details and reflects how people inherently design complex systems.

PRELIMINARY DESIGN REVIEW (PDR) MEETING

A Preliminary Design Review meeting will be scheduled and held to review and confirm preliminary design information.

IBI Group will produce and distribute PDR materials in advance of the meeting. PDR entrance criteria includes:

• completed SDD Section 1: Overview;

• completed SDD Section 2: Business Design Details which includes UI scenarios, reporting requirements, and high-level data model and persistence information;

• questions from IBI Group Team regarding design decisions about the components under design; and

• questions and comments from ODOT reviewers regarding distributed PDR materials.

• All questions and comments received prior to and at the PDR meeting will be logged and addressed. An updated SDD with a comments log showing the adjudication of all questions and comments will be delivered for ODOTs review and acceptance as the preliminary SDD.

CRITICAL DESIGN REVIEW (CDR) MEETING

A CDR meeting will be scheduled and held to review and confirm critical design information and the completed SDD.

IBI Group will produce and distribute CDR materials in advance of the meeting. CDR entrance criteria includes:

• accepted PDR version of the SDD including comments log;

• completed SDD Section 3: Software Design Details which includes discussion of software technologies used, component architecture, data model and persistence, logic workflows, GUI wireframes, and

• reporting capabilities;

• questions from IBI Group Team regarding design decisions regarding the components under design; and,

• questions and comments from ODOT reviewers regarding distributed CDR materials.

All questions and comments received prior to and at the CDR meeting will be logged and addressed. An updated SDD with, a comments log showing the adjudication of all questions and comments will be delivered for ODOTs review and acceptance as the completed SDD for the component addressed by the document.

1.7.5 User Acceptance Test (UAT), Remediation, and Configuration Acceptance

Our team’s experience with the deployment and integration of large scale ATMS and ATIS systems provides the team with proven credentials to plan and execute these activities in a systematic, organized and manageable fashion so that all functions and interfaces are fully tested prior to launch.

IBI Group uses test plans as a regular part of our systems engineering process. System documentation and testing documentation will be provided in advance of testing and IBI Group will lead pre‑test meetings to answer questions and prepare ODOT for the acceptance testing process. Acceptance testing will be conducted by IBI Group and observed by ODOT.

Any system elements that fail acceptance testing are corrected and retested. All anomalies are documented and tracked within JIRA, IBI Group’s issue tracking database. ODOT will have access to this database through system delivery and through the life of the ATMS contract.

Anomalies detected during acceptance testing are assigned to the system acceptance punch list for correction and re‑testing.

IBI Group has allocated time in the schedule, following each acceptance testing task, for correction of punch list items.

IBI Group will collaborate with ODOT to assign punch list items impact classifications of high, medium, or low. Items categorized as high impact are addressed prior to concluding the acceptance testing task where the anomaly was discovered. Medium and low impact punch list items by definition do not prevent essential system operational capabilities.

All punch list items will be resolved to ODOT’s satisfaction quickly and efficiently. Medium and low impact items will not impede the successful completion of an acceptance test task. Any punch list items that remain outstanding after acceptance are tracked through the JIRA program, are resolved as quickly as practicable by the technical team, and will be monitored and reported on by the Project Manager via regular project meetings.

1.7.6 Conversion and Integration of Legacy Data

Data will be assessed based upon criteria provided by ODOT for quality, and cleansed and transformed to fit within the new ATMS database schema. For example, lists of devices and their properties and communications profiles. IBI Group will work with ODOT to define appropriate policies for handling bad data (incomplete, invalid, or stale records). This approach is very straightforward and should not require any input from state staff once screening and assessment criteria are established.

The approach for transitioning from the legacy ATMS system to the new ATMS will be spelled out and submitted for ODOT comment and approval within the Project Migration Plan.

1.7.7 Integration of Data

Integration of Data in this context refers to interfacing with information systems outside of the ATMS such as ODOT GIS, Inrix, and others. A core function of IBI Group’s ATMS is to implement the central hub of TSMO data management and exchange.

Interfacing with external sources of data is a regular task of every ATMS implementation. The process is managed via preliminary and critical design documentation and review in the same way as adding new features and configuring existing capabilities. This process is described in the Design and Development of Customized Functionality section of the proposal.

Success of data integration depends upon partnership with ODOT to ensure the requirements accurately reflect operational needs and the delivered capabilities satisfy requirements and expectations.

1.7.8 Implementation, Rollout, and Acceptance

IBI Group appreciates the importance of maintaining continuity of operations within the TMC as the new ATMS is brought online and functions previously performed in multiple disparate systems are integrated into ODOTs new Transportation Management Framework.

IBI Group’s extensive experience conducting similar transitions mitigates a great deal of the risk that unplanned disruptions might occur. This is an activity that is particularly improved by close collaboration between IBI Group, ODOT, and other ATMS stakeholders. Dependencies sometimes exist upon legacy systems, especially those that have had a long life such as Buckeye Traffic, that are not discovered in the preliminary engineering of a system replacement. IBI Group will work with ODOT and its partners to provide a smooth rollout of all new ATMS capabilities. A key tool to accomplish this is the Migration Plan.

As an element of the Project Management Plan, a Migration Plan will be developed which clearly defines the steps for transitioning from ODOTs existing systems solutions to ODOT’s new ATMS. Simple risk mitigating steps such as parallel operations and preliminary cut-overs prior to going live and observing a burn in period after going live until confidence in the new solution is established are…