510a-19.pdf

Invitation No.: 510a-19 Location: Columbus Commodity: Hauling Permit Software Pricing: http://www.dot.state.oh.us/Divisions/ContractAdmin/Contracts/PurchDocs/510apricing.xls

REQUEST FOR PROPOSAL (RFP)

State of Ohio, Department of Transportation

Office of Contract Sales, Purchasing Services Jerry Wray, Director

Bid Submission Deadline (Bid Opening Date):

November 15, 2018 at 2:00 p.m. eastern time

Submitted by:

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 Bid Packages 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

INVITATION TO BID VIA THE FOLLOWING WEBSITE:

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

Invitation No. 510a-19

Invitation No. 510a-19

TABLE OF CONTENTS

REQUIREMENTS/SPECIFICATIONS .............................................................................. Error! Bookmark not defined.

PRICING SECTION .......................................................................................................... Error! Bookmark not defined.

INSTRUCTIONS FOR SUBMITTING BIDS ..................................................................... Error! Bookmark not defined.

GENERAL DEFINITIONS................................................................................................. Error! Bookmark not defined.

STANDARD TERMS AND CONDITIONS ........................................................................ Error! Bookmark not defined.

ODOT COOPERATIVE PURCHASING PROGRAM ....................................................... Error! Bookmark not defined.

DISTRICT MAP ................................................................................................................ Error! Bookmark not defined.

SIGNATURE PAGE .......................................................................................................... Error! Bookmark not defined.

APPENDICES

SECTION I. GENERAL OVERVIEW

1.1 Overview

The Special Hauling Permit Section (SHP) within ODOT issues permits to private and public sector haulers for any loads that exceed statutory weight or dimension limits. Permit issuance is determined based on the analysis of a hauler’s proposed trip and the properties of the structures and road network the hauler and load would encounter. It is vital that the analysis be based on the most current structure and road inventory.

Furthermore, due to the large and increasing volume of permit applications, trip analysis and permit issuance must occur automatically to the greatest degree possible.

Objectives:

The State has the following objectives and it will be the Contractor’s obligation to ensure that the Work meets these objectives:

• Purchase a State-hosted or cloud based solution for Oversize/Overweight OS/OW permitting and the associated planning, deployment, and maintenance services from the highest-ranking offeror. The offeror and their solution must demonstrate the capability and resources required to address current operational challenges and dramatically improve the precision and efficiency of permitting activity.

• The permitting solution must facilitate through automation, and manage all aspects of SHP’s activity including public web based permit application submission, permit application review, trip suggestion and analysis, road and structure inventory management, payment processing, public notifications, and document management. This must be done in accordance with ODOT policies, laws established by the State and Federal governments, and all Technical and Business Requirements.

• In order to meet ODOT’s needs, the permitting solution must be highly scalable and fully configurable and be implemented using current standard technologies and best practices. ODOT’s will consider only those solutions which will not require customization to satisfy requirements.

• The project described in this Request for Proposal may involve project work done at offsite locations, however, project work involving implementation and support activities must take place at the ODOT Central Office address shown below:

Ohio Department of Transportation 1980 West Broad Street Columbus, Ohio 43223

Please use this link to find Hauling Permits Policies and Procedures:

http://www.dot.state.oh.us/Divisions/Operations/Maintenance/Permits/Pages/Regulation.as px

Contract Duration

Once awarded, the term of the Contract will be from the award date until the Work is completed to the satisfaction of the State and the Contractor is paid or June 30, 2019, whichever is sooner. The State may renew this Contract for up to five (5) additional two-http://www.dot.state.oh.us/Divisions/Operations/Maintenance/Permits/Pages/Regulation.aspx http://www.dot.state.oh.us/Divisions/Operations/Maintenance/Permits/Pages/Regulation.aspx year term(s), subject to and contingent on the discretionary decision of the Ohio General Assembly to appropriate funds for the Contract in each new biennium. Any such renewal of all or part of the Contract also is subject to the satisfactory performance of the Contractor and the needs of the ODOT.

Tentative Interview

ODOT may require the top 3 vendors attend an interview and make a presentation before final recommendation of the contract at 1980 W. Broad Street. Evaluation criteria for the presentations will be provided separately to those vendors if a decision is made to conduct interviews.

Cloud Based Solution

In the event that the bid is a Cloud Based Solution, the winning vendor would be expected to sign a Master Cloud Services Agreement (MCSA). An example MCSA is included as attachment A.

SECTION II. SCOPE OF WORK & SPECIFICATIONS OF

DELIVERABLES

In addition to any information or explanations they want to provide, as well as responses to the mandatory requirements, the vendors should anticipate responding to each sub-section under 2.2 in a narrative form explaining how they will meet the “Contractor Deliverables.”

2.1 Scope of Work

The following are the recognized project phases of State’s OS/OW Permitting

Application implementation:

1. Discovery

2. Design

3. Development

4. Training and User Manuals

5. User Acceptance Test (UAT)

6. Implementation and Acceptance

7. Post-Implementation Support

Database and Data Services. The Contractor is responsible for coordinating efforts with the ODOT Project Manager to transition all required legacy data to the proposed solution and for completing any necessary conversions such that the data is available for use within the new solution prior to production deployment.

State and Contractor Roles and Responsibilities. The State will provide oversight for the work, but the Contractor must provide overall project management for the tasks under this Contract, including the day-to-day management of its staff. The Contractor must also assist the State with coordinating assignments for State staff, if any, involved in the work.

Additionally, the Contractor must provide all administrative support for its staff and activities. Throughout the project, the Contractor must employ ongoing management techniques to ensure a comprehensive Project Plan is developed, executed, monitored, reported on, and maintained.

The State will make individuals serving in the following roles available for the project:

ODOT Project Manager. The ODOT Project Manager will be the point of contact for work related matters between the Contractor’s Project Manager and ODOT. This contact will provide project management oversight and monitoring of the ODOT implementation work, ensuring implementation is completed as designed and in accordance with the approved Project Plan.

ODOT IT Manager. The ODOT IT Manager will provide IT resources and monitoring of the ODOT implementation work that involves ODOT Division of Information and

Technology (DoIT) staff, ensuring implementation is completed as designed and in accordance with the approved Project Plan and ODOT DoIT standards, policies, and procedures.

ODOT Technical Lead. The ODOT Technical Lead will provide guidance for any tasks that involve ODOT DoIT staff, including ensuring the solution and data design meets any applicable ODOT and State IT requirements for data interfaces, integrations, conversions, or migrations.

ODOT Business Team Lead. The Business Team Lead will provide guidance on business processes and operations to ensure the solution meets ODOT’s enterprise business needs. This contact will act as the point person for the Agency to direct activities requiring staff involvement and to identify and schedule appropriate subject matter experts as required. The Business Team Lead will be the primary resource responsible for overseeing user acceptance testing and approval of the application for the Agency following testing, and prior to roll-out. As necessary, ODOT will provide subject matter experts from ODOT’s offices, divisions and programs.

ODOT Subject Matter Experts (SMEs). Subject matter experts will be required and made available as necessary for specific business processes, requirements, testing, and implementation.

Contractor Responsibilities and Deliverables. The Contractor must meet all RFP requirements and complete all work milestones and deliverables, as described in this

Scope of Work.

Project Team. The Contractor must provide a Project Team whose members will produce all required project deliverables. The Contractor may use its personnel or subcontractor personnel to meet the needs of this effort. The State may screen or interview members of the Project Team prior to their assignment to the work. The State may reject any Project Team member for business or legal reasons.

Any changes to the Project Team membership after Contract award will not be permitted without prior written approval from the State.

The Contractor is required to provide a single Project Manager whose responsibilities are described below. The Contractor must provide adequate additional personnel as required to produce all project deliverables in a manner and on a schedule acceptable to ODOT.

Project Manager

Responsibilities:

▪ Creates and manages the Project Plan and schedule;

▪ Manages the Contractor Project Team members;

▪ Liaison between State and Contractor Resources;

▪ Initiates Quality Assurance Processes to monitor the Project;

▪ Manages issues and risks;

▪ Point of escalation for project issues; and

▪ Single point of responsibility for all project deliverables;

▪ Manages the deliverable acceptance process.

1. Project Initiation

The Contractor must identify their project standards, methodologies, tools, personnel and other resources and show how they align with acceptable project management best practices to meet the State’s approval.

Kickoff Meeting and Project Plan Overview. Upon Contract Award and within 10 business days after receipt of a purchase order from the State, the Contractor must hold a Kickoff Meeting to discuss the goals and objectives of the project at a high level.

The meeting will discuss the staffing model, introduce teams and members, discuss the project management methodology and specifically how it will be employed for the project. The Contractor must provide a meeting agenda to the ODOT Project Manager at least two (2) business days in advance of the Kickoff Meeting. The Project Manager and other key Contractor staff must be onsite at ODOT for the Kickoff Meeting.

The Contractor must present and confirm the high-level scope of work and planned phases in accordance with the RFP. This must include the scope of deliverables, functions, and features the implementation of the application intends to achieve.

The Contractor Project Plan must provide the following:

• Staffing Plan - Identifying by position and by name, those staff considered key to the project’s success (at minimum, key staff identified must include a project manager).

• Communication Plan addressing both internal and external audiences

• Change Control Process for the project

• Document Control Methodology

• Risk Management Plan

• Issue/Resolution Plan

• Project Schedule

The Contractor must continuously maintain all components of the Project Plan, adding or revising detail as required to ensure accuracy throughout all project phases.

Meeting Attendance and Reporting Requirements. The Contractor's project management approach for the work must adhere to the following work meeting and reporting requirements:

• Immediate Reporting – The Contractor Project Manager or a designee must immediately report any Project Team staffing change to the ODOT Project Manager

(Refer to the ODOT OS/OW Permitting RFP Attachment Four Part Two:

“Replacement Personnel”).

• Attend Weekly Status Meetings – The Contractor Project Manager and other key

Project Team members must attend weekly status meetings with the ODOT Project

Manager and other members of the State’s project team as deemed necessary to discuss work status, activities and issues. These weekly meetings must follow an agreed upon agenda and allow the Contractor and the State to discuss any issues that concern them.

• Provide Weekly Status Reports – The Contractor Project Manager must provide status reports to the ODOT Project Manager at least two (2) full State business days before each weekly status meeting on electronic media acceptable to the

State.

o At a minimum, weekly status reports must contain the items identified below:

▪ Current project schedule and Project Plan with any revisions that have been made since the last weekly report clearly noted.

▪ Status of currently planned tasks, specifically identifying tasks not on schedule and a resolution plan to return to the planned schedule

▪ Issues encountered, proposed resolutions, and actual resolutions along with an updated issue tracking document

▪ Identification of Risks, probability of them occurring, their impact to project scope/budget/schedule, included in an updated risk tracking document

▪ Status of testing and specific results of any testing milestones

▪ Anticipated tasks to be completed in the next week

▪ Task and deliverable status, with percentage of completion and time ahead or behind schedule for tasks and milestones

▪ Proposed changes to the work breakdown structure and/or project schedule

▪ Contractor staff assignments and/or changes

Note: The Contractor's proposed format and level of detail for the status report is subject to the State’s approval.

• Prepare Quarterly Status Reports - During the work, the Contract Project Manager must submit a quarterly status report to the ODOT Project Manager by the fifth business day following the end of each quarter on electronic media acceptable to the State. At a minimum, quarterly status reports must contain the following:

o A description of the overall completion status of the work in terms of the approved Project Plan (schedule and cost, if applicable) o Updated work breakdown structure and project schedule o The plans for activities scheduled for the next quarter o The status of all deliverables, with percentage of completion o Time ahead or behind schedule for applicable tasks o A risk analysis of actual and perceived problems o Testing status and test results o Strategic changes to the Project Plan, if any

2.2 Specifications of Deliverables

o Project initiation, facilitate Kickoff Meeting, prepare agenda and meeting minutes o Document defining the Project Management Methodology and its application to this project o All components of the Contractor Project Plan

State Responsibilities:

1. Provide access to ODOT staff as appropriate.

2. Provide necessary workspace and supplies as identified in the Contractor’s Proposal and mutually agreed to by the State, if needed.

3. Review and approval of the delivered Project Management Methodology.

4. Review and approval of the Project Plan.

2. Discovery

The Contractor in conjunction with the appropriate State team, will analyze the project scope document and agree to the high-level terms therein. The Contractor along with the appropriate State team members will review the State’s Business, Feature, and Technical

Requirements to obtain a broader description of the project with details of the business process and requirements. The Contractor must provide a System Requirements

Specification document detailing and verifying the business requirements and processes, and how their solution will resolve them. The Contractor must begin working with the State teams to refine requirements contained in this RFP, and develop a Requirements

Traceability Matrix. The Contractor must identify functionality, processes, and tools that may be required in the System design that will enable the Contractor to successfully implement their solution that meets the identified requirements of this RFP. Data

Governance Standards and Data Governance Business Rules documents must be developed by the Contractor with input from appropriate State resources. Any additional functionality, processes, and tools identified and recommended and not included in the

Contractor’s accepted Proposal, must be reviewed and may be accepted by the State through the Change Control Process mutually agreed to by the Contractor and the State.

The requirements analysis and documentation activities completed through the Contract must include mutually agreeable meeting times between the ODOT SMEs and the

Contractor’s Project Team to affirm and detail all requirements.

Included in the Discovery phase and associated documentation, the Contractor must develop and provide a Technical Environment Document that identifies at a minimum the

Contractor’s:

• System transition and integration strategies

• Initial capacity / configuration considerations

• Security and system access environment

• Identification, documentation and agreement to solution performance standards

Contractor Deliverables:

1. Project Team meetings, agendas, minutes

2. Revised Project Plan reflecting all changes to any of its components

3. Refined System Requirements Specifications (SRS)

4. Requirements Traceability Matrix

5. Data Governance Standards document

6. Data Governance Business Rules document

7. Technical Environment document

8. Test Strategy Document

9. Training Plan Document

1. Provide access to ODOT and Local Agency staff as appropriate

2. Review and approval of the updated detailed Project Plan documents

3. Review and approval of System Requirements Specifications (SRS)

4. Review and approval of the Technical Environment Document

5. Review and approval of the Test Strategy

6. Review and approval of the Training Plan

3. Design

The Contractor must identify functionality, processes, and tools required in the project that will enable the Contractor to successfully implement their solution and meet the requirements identified in this RFP. Any additional functionality, processes, and tools identified and recommended that are not included in the Contractor’s accepted Proposal, may be reviewed and accepted by the State through the Change Control Process.

The Contractor must work with the ODOT Technical Lead and other technical staff to develop a System Architecture Design. The System Architecture Design must contain the detailed IT requirements for the project, and will continue to be refined throughout the project.

As part of this effort, the Contractor must work with ODOT staff to identify and document all the permitting application interfaces, and provide a detailed data mapping solution document for the State’s approval. The Contractor must communicate with ODOT Project Manager and ODOT IT Manager concerning any integration solution that involves ODOT IT staff.

The offeror’s Proposal must describe the offeror’s approach, methods and tools for the design, development, and implementation of historical data conversion and data migration, including support and execution of the conversion activity after implementation.

The offeror must describe how it will meet the user configuration management requirements and provide the deliverables for this phase of the work documented in the

RFP.

The Contractor must provide a Configuration Management Plan that includes the various facets of configuration. Including, but not limited to the following configurable management possibilities:

• User/Role management at the various levels (internal users and external users)

• User preferences

• Web portal content management

• Legislative or Administrative changes that require business process changes

• Workflow and business rule process frequencies (e.g., alerts, approvals, deadlines, staff routing)

The Contractor must complete the following design activities and tasks:

• Complete required configurations items and modifications to meet the agreed upon application requirements as documented and approved during requirements analysis, including;

o Data construction: data structure, data acquisition, importing, cleansing, updating, and validation o Application user and system software functionality and processes o Reporting and analysis functionality and processes o Appropriate design documentation

2. Revised Project Plan reflecting all changes to any of its component

3. System Architecture Design document

4. Application interfaces document and detailed mapping solution

5. Detailed Data Conversion/Data Migration Strategy document

6. Users and user role migration strategy document

7. Configuration Management Plan document

2. Review updated Project Plan documents

3. Review and approve System Architecture Design

4. Review and approve the application interfaces and detailed mapping solution

5. Review and approve the Data Conversion/Data Migration Strategy

6. Review and approve the User Configuration Management Plan

4. Development

The offeror must describe the offeror’s configuration and development approach, methods, tools, and techniques for completing the development process. Development tasks must include any data integration/migration tools required to populate the data structures in the Contractor’s proposed solution. During the Development project phase, the Contractor must also update, complete, and deliver all design and development documentation.

The Contractor must develop a Data Conversion Plan that includes the recommended conversion strategy for ODOT historical data. Throughout the application implementation, the Contractor must update and maintain, as needed, the approved Data Conversion Plan until all required data is converted. In addition to addressing the conversion strategy the Conversion Plan must include the following elements, at a minimum:

• Data mapping specifications

• Testing

• Timing considerations

• Data cleansing

• Data loading

• Error identification and correction

• Data validation

• Data reconciliation

• Data auditing (logging the entries)

Conversion Activities. The Contractor must coordinate and perform the conversion efforts and identify the specific tasks and timelines in the project schedule.

The Contractor must complete the following development activities and tasks:

• Develop a data integration/migration tools

• Apply application security and access

• Apply user configurations

• Perform all necessary software upgrades as appropriate

• Finalize system test and user acceptance test scripts

• Finalize user training materials and documentation

• Document system administration, operations, training and support of the configuration items, including identification of Contractor provided post-implementation support, backup/disaster recovery and business continuity plans

• Deliver the finalized design and development documentation

• Conduct appropriate system, stress, integration testing of the software solution with a mutually agreed to volume of data, number of users and user application activities

• Make the complete solution available for testing as required

2. Revised Project Plan reflecting all changes to any of its components

3. Revised design documents

4. A complete instance of the solution available for testing and training

5. Completion of configuration tasks necessary to satisfy all ODOT requirements

6. System documentation establishing that the system configuration satisfies all requirements

7. Data Conversion Plan document

8. Coordination and performance of conversion activities

9. Coordination and performance of stress and integration testing

10. Report test results

2. Final review and approval of all Design and Development phase documentation

3. Review system configuration

4. Review system test results

5. Training and User Manuals

The Contractor must assist ODOT with the setup of the training environment, via the internet, that replicates the production environment. The Contractor must conduct at least 2 instructor led, hands-on training sessions at State facilities for internal user audiences only. Each instructor led session must accommodate up to 20 participants. External User training will be accomplished through Computer Based Training (CBT) or Web Video. The Contractor must provide instructional Web Video or CBT courses and comprehensive online help for all internal and external user audiences.

Training Plan and Course Design. The Contractor must develop the Training Plan based on the functional and technical components of the system. Training must be provided for all user roles (e.g., Permits Office staff, System Administrators, and external users).

The Training Plan must include:

• Learning objectives and a description of course content

• A matrix of ODOT staff and external users indicating which components of the training each group will receive

• A description of all training methods and media to be used (e.g. Instructor led, online CBT self-study, web video, etc.)

• A description of all training materials that will be developed and delivered

• A description of all participant activities and exercises

• A description of any participant assessment tools

• A description of the levels of online help that will be available to users of the system

Training Facilities. ODOT will provide classrooms at a designated State training site(s).

Classrooms include internet connections and materials (personal computers, desks, chairs, etc.) necessary for up to 20 students. ODOT may record any training sessions and use any training materials for future training, user documentation, or promotional purposes.

Training Materials. The Contractor must develop necessary training materials for all courses. All training materials must be reviewed and approved by ODOT prior to the start of training. The Contractor must provide the rights to reproduce training materials as needed.

Training Delivery. Prior to system deployment, the Contractor must submit a letter certifying the completion of training.

System and User Instructional Materials. The Contractor must create and maintain the following training materials:

• User Documentation. Documentation for Internal and External Users must be separate and independent. User Documentation for the system must include, but is not limited to: log-on and log-off procedures, basic access, user account, user role and help procedures and navigation instructions. The Contractor must prepare user documentation for each functional component of the system.

• User Instructional Videos. Videos suitable for publication on internal or public websites instructing the viewer on how to accomplish all required tasks using the system for all user roles and system features.

• System Administration Documentation. The System Administration

Documentation must describe in detail how all administrative functions within the system are performed.

1. Comprehensive Training Plan document

2. Training Curriculum document

3. Training Materials in electronic and hard copy formats

4. User and System Administration Documentation and videos

5. Conduct all training sessions

6. Letter Certifying Completion of Training Delivery

1. Provide training environment(s) for all types of client devices included in this solution

2. Provide appropriate training facilities

3. Contribute information for creating training exercises

4. Monitor execution of the Training Plan

6. User Acceptance Test (UAT)

The Contractor must develop, a UAT plan that covers, at a minimum:

• Documentation of UAT cases, scripts, procedures, timelines and processes

• Training of designated UAT staff before the actual testing

• Scope of the tests and expected outcomes

• Methods for reporting, reviewing, and correcting discrepancies identified during UAT

Monitor and Support the UAT Processes. The Contractor must monitor and support the

UAT process. During UAT, staff trained by the Contractor must use the system to test the system functionality. The Contractor must support this effort in the following ways:

• Provide data to execute the user acceptance test

• Provide full time, on-site Contractor staff to assist State staff for the first two weeks of the UAT and have these specialists on-call throughout the duration of UAT

Log, Track and Resolve System Problems. The Contractor must track all defects throughout UAT and repair the defects throughout the UAT process. All corrections must be reported to the ODOT Project Manager.

Produce UAT Final Report. The Contractor must provide the UAT Final Report which includes the UAT outcome. The UAT Final Report must include sufficient information to enable ODOT to validate that the test has been successfully executed. The Contractor must include all defects identified and their resolutions in the UAT Final Report.

Certify System is ready for Deployment. The Contractor must provide a signed UAT

Certification Letter stating that UAT and any required remedial actions are complete and that the system is ready for production.

1. UAT Plan document

2. Conduct and support user acceptance testing, perform any required remedial actions, and thoroughly document all results

3. UAT Final Report document

4. UAT Certification Letter

1. Create and maintain UAT environment

2. Execute UAT Plan

3. Review and accept UAT Final Report

4. Acknowledge receipt of UAT Certification Letter

7. Implementation and Acceptance

The Contractor must oversee and facilitate the transition of all required State business activity to the Contractor’s system. The Contractor’s Proposal must fully describe the Contractor’s approach, methods, tools, and techniques for deploying/implementing the Contractor’s System. Provide production implementation and on-going production support services for the implemented application, including at minimum software maintenance, and software upgrades, including ongoing technical support and assistance.

The Contractor must have a business continuity plan in place that the Contractor tests and updates at least annually. The plan must address procedures for response to emergencies and other business interruptions. Part of the plan must address backing up and storing data at a location sufficiently remote from the facilities at which the Contractor maintains the State’s Data in case of loss of that data at the primary site. The plan also must address the rapid restoration, relocation, or replacement of resources associated with the State’s Data in the case of a disaster or other business interruption. The Contractor’s business continuity plan must address short- and long-term restoration, relocation, or replacement of resources that will ensure the smooth continuation of operations related to the State’s Data. Such resources may include, among others, communications, supplies, transportation, space, power and environmental controls, documentation, people, data, software, and hardware. The Contractor also must provide for reviewing, testing, and adjusting the plan on an annual basis.

The Contractor must provide standard business continuity procedures and processes, and validate the plan works as outlines.

1. Implementation Plan

2. Business Continuity Plan

3. Scheduled Backup Plan

4. Certification letter indicating that the application and data structure environment have been implemented

5. The Contractor must organize and turn over to ODOT, in an electronic form, all files, documents and other artifacts produced for use by ODOT internal staff or ODOT partners within 90 days after acceptance of the final Post-Implementation Support

2. Review and approve the Implementation Plan

3. Review and approve the Business Continuity Plan

4. Review and approve the Scheduled Backup Plan

5. Confirm receipt of implementation certification letter

8. Post-Implementation Support

Following production implementation of the system the Contractor must provide production support for the system through the term of the Contract and any renewal terms. The Contractor must develop and submit for approval a Post-Implementation Support Plan which identifies both the Contractor and the State production environment activities and responsibilities, at a minimum this document must identify:

• The Contractor’s methodology and processes for upgrading and enhancing the system.

• The Contractor’s on-going production responsibilities, including at minimum proposed solution administration/operations, technical support and any applicable hardware/software maintenance support

• Other Contractor solution consulting and support services that are available to the

State

• State responsibilities as they may pertain to the on-going production operation of the system

1. Post-Implementation Support Plan.

2. Provide production technical support via a toll-free number for appropriate State staff. Production technical support must be provided from 5:00 a.m. to 11:59 p.m.

Columbus, Ohio local time during State business days in accordance with the established Service Level Metrics

3. Provide production environment maintenance and support of the system including on-site support as required

4. Provided documentation of all issues or problems encountered during implementation and operation of the system on a continuous basis during the support period:

a. Problem description

b. Type of problem

c. Number of problems

d. Anticipated fix date

e. Resolution

f. Frequency of problem occurrence and problem cause(s)

1. Review Post Implementation Support Plan providing feedback, revisions and approval as appropriate

2. Review Contractor provided artifacts and documentation providing feedback, revisions and approval as appropriate

3. Provide appropriate feedback on solution response time, user functionality and system operations

4. Review, provide revisions and/or approve Contractor Deliverables and applicable system changes

5. Maintain any applicable licensing and maintenance support associated with the system

6. Provide Final Project acceptance

SECTION III. VENDOR QUALIFICATION

3.1 Mandatory Requirements – vendors MUST meet the following qualification requirement:

1. The vendor software must be able to accommodate the following; Load-Structure analysis must apply AASHTO Load Factor and Load and Resistance Factor methods utilizing the bridge models in the AASHTOWare Bridge Rating (BrR) version 6.8.2 or later either as a line girder or a full system for loads up to 25 axles of standard 6 feet center to center or non-standard gauge.

Vendors that do not meet the above qualification will be disqualified from further consideration for contract award

SECTION IV. BUSINESS REQUIREMENTS

Instructions for the Offeror

The Business Requirements and content must not be modified. If the requirements are modified, reformatted or omitted, the Offeror’s response may be disqualified. MUST

BE INCLUDED WITH BID SUBMISSION

Offerors must complete the “Capability Assessment” column for each requirement in all tables, and provide comments to further qualify the response. Simply checking a specific box without providing further qualification is not considered sufficient to distinguish one offeror from another. For each requirement documented in the RFP the offeror must also provide a narrative description of its solution. Please be robust in your response to how your solution meets each requirement. The offeror must also provide a summary of any proposed third party products or services that will be used to meet the requirements.

An Offeror’s selection of a response within the Capability Assessment column must be made according to the following criteria:

Out of the Box: Requirement must be fully met with out-of-the-box functionality that can be presented for business use with minimal effort beyond tuning a feature “on” or

“off” (e.g., built in processes, rules or reports).

Configuration Required: Requirement will be met with functionality that can be presented for business use after modifications utilizing the proposed software configuration tools. This would include managing or creating new business rules or process flows via tools provided as part of the proposed solution.

Scheduled Enhancement: Requirement will be met with functionality that is included as a part of a scheduled future release of the solution. Functionality that is planned but that does not have a specific release target does not satisfy the requirement.

Not Available: Requirement will not be met as part of the offeror’s proposed solution.

Offeror Comments / Narrative: The offeror must use this column for narrative and/or additional comments as applicable.

ODOT OS/OW Permitting – Future State

Required User Roles:

The following logical User Roles provide a means to organize functionality in terms of authorizations. The following is not a list of specifically required user types or classes. Any configuration of a proposed solution that produces an equivalent user authorization matrix would continue to qualify for consideration.

The system must support any number of users in any of the roles. An individual user may perform in more than one role. In that event, the user is authorized to perform all functions that are authorized for any of their assigned roles.

Users in Role I99 “Supervisor/System Admin” may perform any system function. Users of any other role may perform only those functions explicitly authorized in the functional requirements.

ID Role Description

External Users

X01 External User Candidate

Represents an anonymous public Internet user who is requesting access to the OS/OW Permitting system. They are authorized only to request a new user account (online OS-7). ODOT receives approximately 50 new system access requests per month.

X02 Authorized External User

Represents an individual Hauler or Permit Service representative. ODOT currently has approximately 50k OS/OW Permitting Authorized External Users.

X03 Priority Authorized External User

This role inherits all authority from Role X2 and submissions from a user in this role are prioritized ahead of other user submissions. Intended for use by ODOT District Permit Clerks. ODOT currently has approximately 12 Priority Authorized External Users.

X04 Emergency Authorized External User

This inherits all authority from Role X2. This role may also submit Emergency Permit Applications.

ODOT currently has approximately 100 Emergency Authorized External Users.

X05 Enforcement User Represents a law enforcement or other permit enforcement user. ODOT currently has approximately 1000 Enforcement Users.

X06 Insurance Carrier Representative

Represents an insurance carrier employee who is authorized to submit Insurance Endorsements (online OS-32). ODOT currently has approximately 75 Insurance Carrier Representative Users.

ID Role Description

Internal Users

I01 Central Office Permit Clerk

Represents the clerical staff members of the Permits Office. ODOT currently has 3 Central Office Permit Clerks.

I02 Routine Permit Technician

Central Permits Office staff who are authorized to issue Routine permits. This role includes all I01 authority. ODOT currently has approximately 3 Routine Permit Technicians.

I03 Superload Permit Technician

Central Permits Office staff who are authorized to issue Superload permits. This role includes all I01 authority. ODOT currently has approximately 3 Superload Permit Technicians.

I04 Structure/Roadway Inventory/Route Restriction Custodian

Represents ODOT Central Office staff who are authorized to submit new structure or road inventory and route restriction changes for review. ODOT currently has approximately 4 Structure/Roadway/Restriction Custodians.

I05 District Construction/Engineering

Represents ODOT District staff who are authorized to submit new route restriction changes for review. ODOT currently has approximately 30 District Construction/Engineering Users.

I99 Supervisor/System Administrator

A Central Permits office manager or supervisor who is authorized to perform any system function. ODOT currently has 4 System Administration Users.

ID Role Description Capability Assessment

Offeror Comments / Narrative (Please use red font color)

Automatic Processes

A01 Permitting Process Represents the automated process for analyzing permit applications and trips and issuing permits.

☐ Out of The Box

☐ Configuration Req.

☐ Scheduled Enhancement

☐ Not Available

A02 Notification Process Represents the automated process to perform customer notifications via any combination of voice, fax, email, and SMS text according to customer preference.

☐ Out of The Box

☐ Configuration Req.

A03 Trip Analysis Process Performs automatic trip recommendations and validation.

☐ Out of The Box

☐ Configuration Req.

A04 System Interface process

Manages data from other ODOT systems including roadway/structure inventory, planned construction, and traffic.

☐ Out of The Box

☐ Configuration Req.

Functional Requirements:

The system must satisfy the following functional requirements. Generally, within the functional requirement descriptions below, “manage” or “management” refers to the authorized User Role’s ability to view, create, modify, delete/disable/expire, etc. information within the subject area.

ID Description Authorized Roles Capability Assessment

Offeror Comments / Narrative

(Please use red font color)

10.00 System Access Request Management

10.01 Submit system access request. X01 ☐ Out of The Box

☐ Configuration Req.

10.02 Review/Approve system access

request.

I01 ☐ Out of The Box

☐ Configuration Req.

20.00 User Profile Management

20.01 Manage User Profile (name, contact information, etc.)

X02-X06 (self), I02-

I05 (self), I01 (all)

☐ Out of The Box

☐ Configuration Req.

20.02 User password reset. I01 (all) ☐ Out of The Box

☐ Configuration Req.

20.02.01 Self-service password reset. X02-X06 (self), I02-

I05 (self), I01 (all)

☐ Out of The Box

☐ Configuration Req.

20.03 Immediately suspend all user

activity.

I99 ☐ Out of The Box

☐ Configuration Req.

ID Description Authorized Roles Capability

Offeror Comments / Narrative

(Please use red font color)

30.00 Permit Application Management

30.01 Create permit application. X02-X04 (self), I01-

I03

☐ Out of The Box

☐ Configuration Req.

30.02 Modify permit application. X02-X04 (self), I01-

I03

☐ Out of The Box

☐ Configuration Req.

30.03 Submit permit application. X02-X04 (self), I01-

☐ Out of The Box

☐ Configuration Req.

30.04 Withdraw permit application. X02-X04 (self), I01-

☐ Out of The Box

☐ Configuration Req.

30.05 Copy permit application. X02-X04 (self), I01-

☐ Out of The Box

☐ Configuration Req.

30.06 Renew existing permit. X02-X04 (self), I01-

☐ Out of The Box

☐ Configuration Req.

30.07 Specify requested trip. X02-X04 (self), I01-

☐ Out of The Box

☐ Configuration Req.

Offeror Comments / Narrative

(Please use red font color)

30.07.01 Specify trip using GIS based

route selection.

X02-X04 (self), I01-

I03

☐ Out of The Box

☐ Configuration Req.

30.07.02 Specify trip using text based

route selection.

X02-X04 (self), I01-

I03

☐ Out of The Box

☐ Configuration Req.

30.08 View pending applications. X02-X04 (self), I01-

☐ Out of The Box

☐ Configuration Req.

30.09 Expedite walk-in permit

applications.

I01-I03 ☐ Out of The Box

☐ Configuration Req.

30.10 Refund application fee. I99 ☐ Out of The Box

30.99 Perform 30.01-30.07 Permit

Application Management functions for Emergency

Permits.

X04 ☐ Out of The Box

☐ Configuration Req.

40.00 Permit Application Review

40.01 Issue permit. I02-I03, A01 ☐ Out of The Box

☐ Configuration Req.

Offeror Comments / Narrative

(Please use red font color)

40.02 Request modification to permit

application.

I01-I03, A01 ☐ Out of The Box

☐ Configuration Req.

40.03 Request manual trip analysis. I01-I03, A01, A04 ☐ Out of The Box

40.04 Perform manual trip analysis. I02-I03 ☐ Out of The Box

40.05 Override trip failure. I03 ☐ Out of The Box

40.06 Override default permit fee

amount.

I99 ☐ Out of The Box

☐ Configuration Req.

40.07 Manage payments. I01 ☐ Out of The Box

40.99 Perform all 40.00 Permit

Application Review functions for

Emergency Permits.

I02-I03, A01 (Only

I03 Can override)

☐ Out of The Box

☐ Configuration Req.

50.00 Permit Management

50.01 Search permits. X02-X04 (self), X05, I01-I05

☐ Out of The Box

☐ Configuration Req.

Offeror Comments / Narrative

(Please use red font color)

50.02 View, Download, Print, and

email permits.

X02-X04 (self), X05, I01-I03

☐ Out of The Box

☐ Configuration Req.

50.03 Revoke permit. I01-I03, X05 ☐ Out of The Box

50.04 Revoke all hauler permits. I01-I03 ☐ Out of The Box

60.00 Hauler Profile Management

60.01 Create hauler profile. X02-X04, I01-I03 ☐ Out of The Box

☐ Configuration Req.

60.02 Update hauler profile. X02-X04, I01-I03 ☐ Out of The Box

60.02.01 Manage hauler notification

preferences, any combination of voice, fax, email, and SMS text.

X02-X04 (self), I01-

I03

☐ Out of The Box

☐ Configuration Req.

60.02.02 Manage hauler contact

information.

X02-X04 (self), I01-

I03

☐ Out of The Box

☐ Configuration Req.

60.02.03 Manage Insurance/Bond

information.

I01-I03 ☐ Out of The Box

☐ Configuration Req.

60.02.04 Submit Insurance

Endorsement/Bond.

Information.

X06, I01 ☐ Out of The Box

☐ Configuration Req.

60.02.05 Manage Insurance/Bond

expiration/cancellation.

I01, A01 ☐ Out of The Box

☐ Configuration Req.

Offeror Comments / Narrative

(Please use red font color)

60.02.06 View escrow

transactions/projected balance.

X02-X04 (self), I01-

I03

☐ Out of The Box

☐ Configuration Req.

60.02.07 Submit escrow payment. X02-X04 (self), I01-

☐ Out of The Box

☐ Configuration Req.

60.02.08 Process escrow payment. I01-I03 ☐ Out of The Box

60.02.09 Manage saved vehicles. X02-X04 (self), I01-

☐ Out of The Box

☐ Configuration Req.

60.02.10 Manage saved trips. X02-X04 (self), I01-

☐ Out of The Box

☐ Configuration Req.

60.02.11 Set special conditions

requirement.

I01-I03 ☐ Out of The Box

☐ Configuration Req.

60.02.12 Report violation. X05, I01-I03 ☐ Out of The Box

60.03 Deactivate hauler profile. X02-X04 (self), I01-

☐ Out of The Box

☐ Configuration Req.

70.00 Route Restriction Management

70.01 Submit route restriction change

request.

I01-I05 ☐ Out of The Box

☐ Configuration Req.

70.02 View pending route restriction

change requests.

I03-I05 ☐ Out of The Box

☐ Configuration Req.

70.03 Modify pending route restriction

change requests.

I01-I05 ☐ Out of The Box

☐ Configuration Req.

70.04 Accept/Reject route restriction

change request. Add, modify, or remove restriction.

I03-I04 ☐ Out of The Box

☐ Configuration Req.

70.05 Notify haulers/services of

restriction change on permitted or saved trips using the methods selected in the hauler profile.

I03-I04, A02 ☐ Out of The Box

☐ Configuration Req.

80.00 Structure Inventory Management

80.01 Submit structure inventory

change request.

I01-I04, A05 ☐ Out of The Box

☐ Configuration Req.

80.02 View pending structure

inventory change requests.

I01-I05 ☐ Out of The Box

☐ Configuration Req.

Offeror Comments / Narrative

(Please use red font color)

80.03 Modify pending structure

inventory change request.

I01-I04 ☐ Out of The Box

☐ Configuration Req.

80.04 Accept structure inventory

change request.

I02-I03 ☐ Out of The Box

☐ Configuration Req.

80.05 Add, modify, or remove

structure inventory.

I02-I03 ☐ Out of The Box

☐ Configuration Req.

80.06 Update system and hauler

saved trips with structure inventory change.

I02-I03, A05 ☐ Out of The Box

☐ Configuration Req.

80.07 Notify haulers of structure

change on permitted and saved trips using the methods selected in the hauler profile.

I01-I03, A02 ☐ Out of The Box

☐ Configuration Req.

90.00 Roadway Network Inventory Management

90.01 View pending roadway network

inventory change requests.

I01-I05 ☐ Out of The Box

☐ Configuration Req.

90.02 Submit roadway network

inventory change request.

I01-I05, A05 ☐ Out of The Box

☐ Configuration Req.

90.03 Modify roadway network

inventory change request.

I01-I05 ☐ Out of The Box

☐ Configuration Req.

Offeror Comments / Narrative

(Please use red font color)

90.04 Accept roadway network

inventory change request.

I02-I03 ☐ Out of The Box

☐ Configuration Req.

90.05 Add, modify, or remove

roadway inventory.

I02-I03 ☐ Out of The Box

☐ Configuration Req.

90.06 Update system and hauler

saved trips with roadway inventory change.

I02-I03, A05 ☐ Out of The Box

☐ Configuration Req.

90.07 Notify haulers of roadway

network change on permitted and saved trips using the methods selected in the hauler profile.

I03-I04, A02 ☐ Out of The Box

☐ Configuration Req.

100.00 Reporting Requirements

100.01 Daily financial detail. I01-I03 ☐ Out of The Box

☐ Configuration Req.

100.02 Financial summary by period. I01-I03 ☐ Out of The Box

100.03 Permits by geographic location

and trip date.

X05, I01-I03, I05 ☐ Out of The Box

☐ Configuration Req.

Offeror Comments / Narrative

(Please use red font color)

100.04 Permit detail. X02-X03 (self), X05, I01-I03, I05

☐ Out of The Box

☐ Configuration Req.

100.05 Permit summary. X02-X03 (self), X05, I01-I03, I05

☐ Out of The Box

☐ Configuration Req.

100.06 Permit type summary. X02-X03 (self), X05, I01-I03, I05

☐ Out of The Box

☐ Configuration Req.

100.07 Permitter activity. I99 ☐ Out of The Box

100.08 Insurance form processing

activity.

I99 ☐ Out of The Box

☐ Configuration Req.

100.09 System performance analytics. I99 ☐ Out of The Box

100.10 Audit reporting. I99 ☐ Out of The Box

110.00 Workflow/Automation Functions

110.01 Queue Management –

Common queueing features to manage workflow.

110.01.01 Maintain permit applications

queue.

I99, A01 ☐ Out of The Box

☐ Configuration Req.

110.01.02 Maintain route restriction

change request queue.

I99, A05 ☐ Out of The Box

☐ Configuration Req.

110.01.03 Maintain structure…