Page 1 of 16
RFP68-2015
DETAILS & SPECIFICATIONS FOR A PARA-TRANSIT
SCHEDULING SOLUTION
SCOPE OF WORK
Transit Profile
Transit Services provides both conventional Transit and Specialized Transit service within the City, as well as operating a Visitor Transportation System in partnership with the Niagara Parks Commission.
A fleet of 7 Specialized Transit vans provide exterior door-to-door transportation service for residents of the City, who, due to a physical or functional limitation, are unable to board, ride or disembark from a conventional transit bus.
Specialized Transit registration, scheduling, trip booking and customer service are provided off site by St. John Ambulance (current Service Provider), on behalf of the City, from the offices at 5734 Glenholme Ave, Niagara Falls, utilizing a manual system.
Purpose
The City is inviting Proposals from qualified firms for the supply, delivery, installation, testing, warranty, and training of a hosted/Software as a Service (“SAS”)/cloud solution/or a client “owned” Para-Transit Scheduling solution complete with software and hardware.
The successful Proponent shall:
a. Supply, deliver, install and commission a Scheduling Solution according to the requirements in this RFP;
b. Customize the hardware, software/firmware for the equipment to function as required; c. Provide training to St. John ambulance and City employees to operate, maintain and
repair the system;
d. Provide a Scheduling System with available features that ensure compliance with the Transportation Standards of the Integrated Accessibility Standards Regulation 191/11, made under the AODA;
e. Complete commissioning of all on-vehicle equipment and all other hardware, software and/or firmware required for the system to meet functional requirements, the City will supply and install all in-vehicle mounting hardware and MDT computers/tablets as specified by the Proponent;
f. Failure on the part of the City to specify precisely each and every item necessary for the system shall not relieve the successful Proponent of total system responsibility.
Page 2 of 16 Benefits
The City expects to derive the following benefits from the scheduling software:
Minimize operating costs associated with the Specialized Transit service;
Maximize productivity of vehicle operators; and
Minimize the time and distance spent on driving for each vehicle while still meeting schedule and time windows of customers;
Implementation Project Organization:
The Proponent must provide an overview of the implementation methodology used for the installation of the system. At a minimum, provide a Microsoft Project file demonstrating the task-time relationships and incorporating the resource requirements for each task. The overview shall include the following:
A. Timetable — the implementation plan must include the projected timetable and identify the deliverables and details of the processes for each stage of
implementation.
B. Project Resources — specify the project team to be provided by the proponent including employee names, their roles, level of effort on the project, and provide a resume for each of these team members. The successful Proponent cannot change any of the team members without Transit Services approval of equal replacements. C. Conversion of Data - Transit Services requires the conversion of existing data.
Proposers must describe the conversion methodology to be utilized.
Project Requirements
Please respond fully to each of the items listed below: 1. Software Requirements
The Proponent shall indicate whether the software solution that they are proposing is a hosted/Software as a Service (“SAS”)/cloud solution/or a client “owned” solution. Where the Proponent has both options available as offerings, they are encouraged to submit pricing information for both offerings in their response. The Storage of Personal information must conform with the Personal Information and Electronic Documents Act (PIPEDA) and the Ontario Personal Health Information Protection Act. The SAS/Cloud Based solution must be hosted in Canada.
a. City “Owned” Solutions
For all City “owned” solutions; the Proponent shall declare whether there would be an additional licensing fee for setup of a “Test Instance” of this software at the City site. The Proponent shall disclose any mandatory upgrade fees/charges that the City should expect when upgrading to newer versions/patch levels. The Central System Server for operating the Scheduling System Software shall be located at City Hall, 4310 Queen Street and will be managed out of the St. John Ambulance (current Service Provider), at
Page 3 of 16 5734 Glenholme Ave and out of the Transportation Services Department, located 8208 Heartland Forest Road.
b. Hosted /SAS/Cloud or City “Owned”Solutions
For all SAS solution Proposals, the Proponent shall include the following details in their Proposal:
i) Disaster recovery site and process that is in place for the primary site; ii) Bandwidth available at the primary and secondary sites, if applicable; iii) Physical security protocols in place for all sites;
iv) Security assessment and penetration testing processes, scope and intervals; v) Other pertinent information for the solution(s).
2. Central System and Cloud Based Requirements
The successful Proponent will provide the City with the necessary means to back up the collected data from the system to the City’s backup servers. The term 'collected data' refers to all generated reports and all data contained within the systems relational database server. The successful Proponent shall provide specific details, including protocol, service etc. that is available within the proposed solution to achieve this requirement. The City will be permitted to connect the systems servers to the City’s intranet for the purpose of creating backups of the collected data. Any of the successful Proponents’ systems that are connected to the City intranet will be required to meet the City's security standards, which includes; virus protection, operating system patching and firewalls. The successful Proponent must agree to facilitate regular security assessments by the City. The City Information Systems (“I.S.”) staff will be given sufficient server access in order to install, configure and maintain the backup solution client software for the purpose of creating backups of the collected data. The City I.S. staff will be given remote access to the systems servers for the purpose of maintaining, monitoring and troubleshooting issues with the backup solution. The City I.S. staff will have direct read-only access to the data contained within the relational database for the purpose of performing queries in order to facilitate audits and other investigations.
3. WORKSTATION / LICENSE REQUIREMENTS
Transit Services will need a total of 5 user licenses (or license concurrency) and 7 vehicle licenses for all functions within the project.
4. Demand-Response(DR)/Computer-Aided Dispatch (CAD) Software Minimum Requirements and Functionality:
The Proponent will be required to convert the existing paratransit system database to the new DR software database and complete all steps to ready the new software for live operation. Transit Services will provide the existing customer and trip data to facilitate the initial set up of data files in an electronic format.
a. Proponents are expected to determine what work is required to make the system ready for operation, remains to be completed as part of the project, and what work is already
complete. All remaining work required to make the system fully operational is to be completed by the Proponent as part of this project. Explain process for ensuring this is accomplished.
Page 4 of 16 b. DR software shall utilize a Geographic Information System (GIS)-based algorithm that takes
into account actual street network and other topographical features included in these GIS data. Explain how your system meets this expectation.
c. Fully-automated real-time scheduler will consistently produce logical and efficient schedules for the fleet and customer demand. Describe the how the system proposed has the capacity to continue to produce logical and efficient schedules as the demand response service grows.
d. Describe how the system proposed provides for batch scheduling of any selected service of customers or vehicles.
e. Describe how the system proposed provides for computer-assisted scheduling to assist a dispatcher in fine tuning driver schedules or recommending to a customer alternate travel times.
f. DR scheduling software must fully integrate with the AVL and MDT/Driver Interface. Transit Services requires that Dispatchers are able to move seamlessly between all major
components of the system without having to turn off or exit from other major components. Dispatchers must be able to perform multiple tasks, for example: continue to monitor vehicle schedules and locations while scheduling a new demand response trip request or while searching for individual vehicle location to respond to a customer information request. Describe how your system meets this expectation.
5. Database Minimum Requirements and Functionality:
a. Operations and performance data will be stored in a historical database that will provide rapid access for common and recurring operational reports and all reporting tools must work equally on both production and archival data.
b. There must be a timeframe of the previous 2 years of live archival storage and all
subsequent years on restorable media. Data must be easily accessed for retrieval either from online memory or from archived memory for user specified time periods of
operation.
c. The system must store, for example, route, schedule and operational performance of each vehicle, call requests, text messages, system and vehicle login and log out information.
d. Transit Services requires the Proponent to provide the database schematic, field definitions, and any encoding.
e. The system must provide tools and utilities to import and export data from its database to other databases and systems.
Page 5 of 16 The Scheduling System shall include, but not be limited to, the following server and workstation functionality:
a) The Scheduling System shall be installed at a minimum of “warm standby” mode with a fully redundant primary and backup application server with automatic failover. Backup server will be located on-site;
b) The successful Proponent shall provide hardware requirements for primary and backup servers; and
c) The successful Proponent shall provide an installation plan and deployment strategy for a disaster recovery system.
d) The Scheduling System shall allow fully customizable administrative and user controls to manage the system and database. This shall include, but not be limited to:
e) The ability to create user groups with customizable user privileges for each group, e.g. System Administrator, Security, Data Manager, Scheduling Agent, Dispatcher;
f) Scheduling System access shall be password-protected. As such, all users shall be assigned unique login IDs and passwords;
g) System Administrator shall be able to define, modify and create global parameters and fields as required;
h) The purpose of this is to enable Transit Service management and/ or staff to manage the Scheduling Software and to analyze data and create reports;
i) The successful Proponent shall install the software on up to 5 desktop computers, provided by the City. The successful Proponent must warrant that their software must function on same; Software concurrency shall be a minimum of 5 concurrent users on the system.
j) The system will be able to accommodate the City’s password requirements 6. Scheduling and Dispatching Functions:
Transit Services has the following requirements and expectations for the functionality of the DR Scheduling Software and the capabilities provided by the software as well as the interface with the other components of this project. Please describe how the system proposed will fulfill the following requirements and expectations:
a. From any screen begin entering a new trip request, cancel a trip, review all trips for a particular client for a specified date range, cancel the original and book a replacement trip, late for delayed returns, modify a trip destination while retaining the original trip information for reporting purposes, track a trip denial at the end of a trip request, etc. b. Dispatchers will be required to have the ability to see the entire route from depot to depot,
filter the view to see just those trips that have not been performed/completed, and for the display to clearly identify the difference in each. Give screen shots of each of the
descriptions highlighting the described functionality. To continue to monitor the vehicle status display and respond as needed. Explain how the system proposed will improve a dispatcher’s ability to manage these tasks on a day to day basis.
Page 6 of 16 c. Simple, easy and efficient to use – DR scheduling process must be user friendly. Use of
function keys for dispatcher to schedule demand trip requests, assign the trip to a vehicle, send the text message to the driver, and receive verification that the trip assignment has been received.
d. Navigation must be accomplished by mouse point and click and alternately by simple function keys. Including the sort ordering (and retention of preferences) for column and screen components within each of the screens and job functions.
e. The system needs to have the ability to print out dispatcher trip notes, special instructions, and trip purpose.
7. Monitor vehicle operations and schedule performance:
Please describe how the system proposed will fulfill the following requirements and expectations: a. Easily identify and monitor paratransit trips in danger of running late for pick up and the ability
to quickly locate alternate vehicles, make trip assignments and notify the drivers by text message of the assignments.
b. Easily identify all will call trips not assigned to vehicles, track the time trip was requested for pickup, quickly locate vehicles available to provide the trip within established system policy, make the trip assignment, notify the driver and provide the customer with confirmation within a maximum of 2 (two) minutes while the customer is on the telephone. Change to create, copy, or modify as not to delete trips in the system. Search should be allowed on partial entry of information for all search fields. Search fields at minimum should include first name, last name, system ID, SSN or alternate ID, address, and home phone. Ability to flip a trip for easy round trip entry as well as multiple flips with new destinations to account for multi-leg trips. System must allow for the same trip request to be booked for multiple days out through calendar selection without requiring the entry of a standing order, or recurring ride request. All accomplished while the customer is on the phone to ensure times can be negotiated and estimated times can be communicated for each of the resultant trips schedules.
c. The software must provide manual, computer-assisted and fully-automated scheduling functions. The scheduling functions must utilize a GIS-based scheduling algorithm utilizing the actual street network/ centerline data. Triangulation and direct line distance will not be acceptable. GIS data used by the DR system will have the ability to be updated as changes are made to the GIS base data.
d. The software must utilize advanced scheduling and routing algorithms utilizing information from the GIS component to calculate efficient and realistic schedules and routes. The software will draw upon the resources of the GIS package in order to perform route
optimization functions based on real street network data. The software is required to easily and efficiently schedule subscription and demand/ response trips. The scheduling
component must effectively support multi-loading trip scheduling where persons in close proximity traveling to destinations in close proximity or along a common path within an acceptable time window are scheduled to share a vehicle.
Page 7 of 16 8. Geographical Map Minimum Requirements and Functionality:
a. The geographic map display will utilize the GIS-base map with overlays showing route shapes, landmarks, boundaries, paratransit origins and destinations, and vehicle scheduling and routing information.
b. The display will show the location, status and movement of paratransit vehicles on the map.
c. Users will navigate around the map using Windows “point and click” to zoom, pan, and locate individual vehicles or specific areas and vehicles operating within the selected area.
d. The graphic display will provide the user the ability to quickly zoom in to look at the location and status of any individual vehicle, pan to look at adjacent areas, zoom out to look at the location and status of all vehicles within a specified area, which may be two or 4 square kilometres or the entire service area.
9. AVL Minimum Requirements and Functionality:
a. The Proponent will provide Transit Services with a DGPS based AVL in a total of 7 vehicles.
b. The AVL component must fully integrate with the GIS-based computerized reservations, scheduling, and dispatch systems and provide mobile data communications capability. c. The AVL system must provide real-time information using graphical mapping of
vehicles, routes, bus stops, paratransit stop addresses.
d. The AVL system will provide navigational support for the paratransit vehicles (current location as well as how to get to the next location on the manifest or schedule). 10. Key measures to be monitored by the AVL component include:
a. Route and schedule adherence for demand response vehicles – on time, early or late. b. Location and schedule adherence for demand response vehicles – on time, early or late c. Stamp events and transmissions with date and time, vehicle ID, driver ID, route and
direction of travel.
d. Vehicle speed and Vehicle location
e. The AVL component will streamline event tracking and response and provide a reviewable database for event review.
f. The AVL component shall employ the latest GPS technology and shall communicate the real time location, status and movement of the project vehicles with a maximum location error of no more than 30 feet in 98% of the current service area.
Page 8 of 16 11. The MDT/MDC/driver interface equipment will provide the following functionality: MDT/MDC’s are required to interface with the DR scheduling software and AVL system in order to provide a dynamic tool for communication of information about vehicle assignments, status and condition between the vehicle and the Dispatcher or other management workstations requiring operating data from the vehicle.
Enable text messaging between driver and dispatcher to improve the accuracy and effectiveness of the information communicated.
The display will be clearly visible under bright daylight as well as dark conditions and from many viewing angles to comfortably accommodate drivers of various heights and seat adjustment preferences without having to move the unit around.
The display will accommodate an adequate number of lines and characters to allow the
message to be easily read by the vehicle operator. An example would be to allow a paratransit driver to read the complete passenger name, address, destination and any special instruction about the assignment on one screen without having to scroll. Any requirement for users to learn special abbreviations and message codes in order to understand information being transmitted or to compose messages to transmit must be minimized. Special key strokes or abbreviations for routine instructions or responses are acceptable to save time.
The alphanumeric keypad and / or touch screen will be user friendly and intuitive in operation. Drivers will be able to review the messages sent and received. It is important for relief drivers to be able to see what instructions are outstanding for the service they are taking over and must be alerted when message is received on unit from dispatch both audibly and visually.
The message that is to be displayed on the driver Onboard Data Device must be fully and easily configurable. All events must be stamped with date and time and formatted to meet the
international standard of yyyy-mm-dd. The Onboard Data Device should keep a record of when it last downloaded data and have a large enough memory to hold at least three days of events. Clocks in the Onboard Data Device must be regularly and automatically synchronized with central system clock at regular intervals to insure schedule consistency between vehicles. 12. The MDT/MDC’s shall function to streamline the collection of daily operating data and
records and ensure the accuracy of the information collected.
Transit Services requires collection of vehicle pull out and pull in time;
Transit Services requires semi-automated (by minimal keystroke sequence) or automated (where appropriate) collection of passenger trip data such as:
Time, location and mileage when a demand response passenger trip is completed;
Time, location and mileage when any emergency alarm is activated;
Time, location and mileage when a text message is received or sent by the driver interface unit and again when the message is acknowledged.
Data collected must be transmitted to central dispatch automatically throughout the operating day. All data collected must be stored indefinitely as part of the system database described
Page 9 of 16 previously to allow for retrieval by management and supervisors for operating reports, statistical analysis, etc.
MDT/MDC with Graphical map display integrated with the GIS map and way finding capabilities installed in passenger service vehicles.
13. Mobile Data Computer General Requirements:
Mobile Data Terminals/Computers are required for all demand-response, to support text
messaging between central dispatch and vehicle operator, for manifest acquisition, to automate or semi-automate data collection, to provide security enhancements as described below, and other functions as described
MDT/MDC mounting and docking systems must be ergonomic and must not pose a safety hazard to the driver nor the passengers
The equipment must be specified to be installed in a location that minimizes exposure to the elements, is unobtrusive to the driver or entering / exiting passengers, but remains easy for the driver to locate, view and operate while seated in the driver compartment of the vehicle.
The specified equipment must be sturdy to withstand the bumps and vibration of a heavy vehicle in service on rough streets as well as those caused by the driver entering and exiting the drivers’ compartment.
The removal of defective or malfunctioning equipment and replacement with a backup unit must be very fast and easy for a non-technical person to accomplish so that drivers are back in communication quickly and service delays are minimal
Proposals shall specify the number of spares required so that units can be removed for repairs or routine maintenance without the need to put the vehicle out of service
14. Report Requirements
The following pre-configured report templates shall be included in the initial deployment. Any exported document or report that may be posted online will need to conform to WCAG 2.0 Level AA standards.
Each report which pulls data from the system should include an error checking report that can be used to validate data quality prior to running said reports. Reports access should not be limited to only named users if at all possible. Repeat specification that the Excel exports not be cluttered with formatting which would prevent the data from being used or simply sorted. All header or sub grouping information should be transformed into column or row data that is reflected in each resulting exported row.
a. The system must have the flexibility to allow the City the ability to generate reports, manage data, and retrieve archived data, including, but not limited to:
b. Accurate reporting shall be made available of performance metrics, customer/trip history, vehicle performance, schedule adherence, passenger hours, revenue kilometres, vehicle operator performance, etc.;
Page 10 of 16 c. Ridership, kilometres, revenue, and revenue-kilometres statistics shall be made available
for each service provider; and
d. The Scheduling System shall be capable of compiling billing information to the respective third-party service providers based on assignments to their respective vehicles.
e. Reports shall be customizable using an intuitive graphic user interface and have output in text, Excel and PDF formats on demand by the Transit’s System Administrator. f. The templates shall be confirmed with City staff prior to final system acceptance.
The DR software should also allow users to create “User Defined” reports on an ad-hoc basis by accessing an easy to use, Wizard-driven, ad-hoc Report Generator that is seamlessly integrated into the software.
Ridership Statistics Reports:
Ridership needs to be tabulated by:
a. Number of one-way trips by passenger type, taken by registered ambulatory and non-ambulatory riders, visitors, companions and/or children, and support persons; b. Age group, e.g. Adults, Senior, Student, Child;
c. Active number of registrants;
d. Grouping into dedicated and non-dedicated service and again by passenger type; and e. Trip purpose, e.g. medical, shopping, work, and school, dialysis, day program, recreation, church, family.
Total number of trips requested; Total number of trips accommodated; Total number of trips un-accommodated; Total number of no shows; Total number of trips; Total number of trips cancelled at door; Total number of missed trips; Total number of vehicle no-shows; Total number of trips late over 20 minutes; Total number of trips moved for lateness; Total number of snow days trips; Total number of trips sent to taxi services; Origin and destination data; and Number of trips to and from major destinations, e.g. day programs, terminals, hospitals etc.
All of the above ridership data needs to be able to be tabulated by day, month, and year; and by age group, vehicle type; and by third-party service provider.
Operating Statistic Reports:
Cost Report(s) - need to be able to obtain detail cost reports, e.g. taxi script, with the following information:
Reports are required: daily, weekly, monthly, and yearly; Each report must identify each route and contain; Total revenue km; Total deadhead km; Total km; revenue and
deadhead combined; Revenue km and deadhead km expressed in a percentage of total scheduled km; Passenger per vehicle manifest; km per vehicle manifest; Flagged passenger list; and cancelation of subscription and other bookings to red flag abuse.
Page 11 of 16 Ride Report:
Need to obtain detail data on each trip including:
Passenger ID; Date of travel; Pick-up and drop off location; Number of trips; Length of trip, in km; Amount that should have been charged by client based on the MP Scrip ride grid; and Daily, weekly, monthly and annual summaries.
Revenue Hours Summary:
Need a report that will calculate Revenue and Non-Revenue service hours:
By Proponent; By service type, e.g.: charter, or special event, or regular service; and Provide daily, weekly, monthly and annual summaries.
Cost and Passenger per Hour Summary :
This summary needs to also calculate the cost per passenger:
By service type; and Provide daily, weekly, monthly and annual summaries.
Route Productivity Report:
This report summarizes each route’s daily, weekly, monthly productivity by: Route number; Unit number; First and last pick up and drop off time; Revenue,
deadhead, and total hours; Revenue, deadhead, and total kms; Number of completed trips; Total passengers; Productivity passenger per hour - total passengers per revenue hours; Productivity average trip length - revenue km/total passengers; and Productivity average deadhead - deadhead km/total kms.
15. System Specifications
It is anticipated that the software supplied will be a combination of both commercially available and proprietary software. The successful Proponent is responsible for acquiring and paying any license fees for all commercially available software that is not already available at the City. Within four weeks following notification of award of the RFP, the successful Proponent shall furnish the City with complete written documentation describing the system to be delivered, including all equipment and software to be furnished. The System Design Specification (“SDS”) shall include, as a minimum, the following information, as applicable:
a. Overall system schematic and architecture; b. Major assumptions and risks;
c. Detailed description of all subsystems and equipment and hardware, including functional description, interface descriptions, communications loading details, material
specifications, e.g. environmental, electrical etc., Material Selection Documentation (“MSD”), configuration details and installation details;
d. Details on all network, data, power/electrical or other requirements provided by a third party;
Page 12 of 16 e. Detailed description of all software, including functional description, system interface
descriptions, Graphical User Interface descriptions, hardware specifications, availability and reliability figures and configuration details;
f. Detailed descriptions of information, materials and timing required by other parties; g. Maintenance and service details may be included in the SDS; and
h. Accessibility features
16. Implementation Support – Installation, Testing, and Training:
Transit Services expectation is for the Proponent to work closely with Transit Services during all phases of implementation, and fulfill certain specific responsibilities. The Proponent must give a detailed description of the level and extent of all services and support to be provided during the implementation of the proposed software including but not limited to the following:
a. The Proponent shall comply with all specific implementation plan responsibilities, the plan having been developed consistent with this RFP response and the executed contract.
b. The Proponent shall describe the installation of the system, and all related software on the hardware. The cost of installation, software and other project components shall be included in the proposal. The Proponent will install all project software and oversee the installation of the in-vehicle hardware at a time and location acceptable to Transit Services. Equipment and software installation that may be disruptive to normal transit operation shall be planned to take place after service closes or on weekends.
c. Proposals shall include a detailed Testing Plan that describes how all components and capabilities will be tested to verify that all are operating according to project design and that the system is performing effectively and as required by Transit Services. As a minimum testing will include the following:
i. Post delivery and installation testing shall be performed by the Proponent at a location determine by the City once the system has been installed and initially checked out but prior to it going operational. This test will constitute an initial demonstration in a controlled environment to a limited number of Transit Services representatives of all the features and functions of the system in order to verify that all aspects of the system are prepared and functioning according to design and project requirements. Any problems or deficiencies must be corrected prior to the system going on line.
ii. The Proponent shall additionally test the system after the system has been
operational for an agreed upon (between Transit Services and the Proponent) period of time to determine that all aspects of the system continue to perform as required; i.e. that all components continue to operate reliably, no post installation problems have occurred that may not be readily detected in daily operation prior to failure, that data and voice communication are delivering the required level of service and that system back up and restoration are functioning properly. Any deficiencies found as a result of this testing or reported to the Proponent by Transit Services prior to or during the test must be corrected and the system successfully re-tested prior to final
Page 13 of 16 project acceptance and payment. When Transit Services determines the test to be successful,the system will be considered live and ready for general use.
d. The Proponent shall provide an overview of the proposed training for each of the items listed below. Include the number of days required for each area, resumes detailing trainer experience, available courses/training, and training materials. All training will be conducted on-site at Transit Services facilities.
e. The successful Proponent will provide a “Train the Trainer program” for all areas of the system. The purpose of the training is to provide City employees with the information and skills needed to operate, maintain and support the system. All training will take place at Transit Services. Training will include, but not be limited to:
i. Van/Bus Operators; ii. System Operators;
iii. Management and St. John Ambulance iv. I.S. Technicians; and
v. Garage Service Staff/Mechanics.
The successful Proponent will be responsible for identifying the supplies and equipment
required to fulfill the training. The Proponent will state the number of hours of training provided. Apply Accessibility Standards for Customer Service, where required, for training.
17. Manuals
All manuals must be written in Canadian English. They must be in a format that is easy for the City to copy or reprint for employee use. The use of diagrams, pictures and photographs is encouraged where it clarifies the written instruction. User manuals must include all necessary warnings and cautions to permit safe operations of the equipment or software. A troubleshooting guide should be included in all manuals. Where appropriate, user manuals should include reference sheets for the user. Maintenance manuals must include a list of all the tools, equipment and any other items that would be required to perform the maintenance task. The manual should describe both preventative and corrective maintenance procedures.
18. Warranty
a. The successful Proponent shall be the warrantor of all system components, not withstanding any manufacturer’s warranties, whether written or implied;
b. The basic manufacturer’s warranty shall be extended to cover a period of 24 months from the date of System acceptance. The warranty shall cover any defects, failures, or malfunctions in materials and workmanship for all system components;
c. The successful Proponent shall provide all labor, parts, transportation, expenses, testing equipment, software and incidentals necessary to provide warranty and support for all elements of the system;
d. The warranty shall also include upgrades to new versions of the Scheduling System and GIS map data that are offered by the software vendor or successful Proponent within the warranty period; and
e. The warranty shall include the following support services, to be provided by the successful Proponent, or their contracted representative:
Page 14 of 16 i. Maximum of one business day on-site response time for issues that can’t be
resolved or repaired over the phone;
ii. On-site troubleshooting, removal, replacement, repair, reconfiguration and testing as required to maintain the system in good operating condition; and
iii. Ensuring that documentation is up-to-date.
f. The successful Proponent shall provide a written report as to the cause of any failure. g. There shall be no repair cost applied to the City over the warranty period, This shall
include software and services performed by the successful Proponent or any of their sub-proponents.
19. Continuing Support and Maintenance Program:
Specify the nature of the post-implementation support provided by the Proponent. The following areas should be addressed:
A. Problem reporting and resolution procedures
1) Reporting method
2) Response time requirement
3) Hours of operation
B. Support
1) Toll-free access; hours of operation
2) On-Line Support
3) Error Corrections
C. Modifications, upgrades, enhancements, etc.
1) Define each type of release and requirements for implementations
2) State policy for providing each type of release 3) Delivery methods for each type of release 4) Cost for each type of release
5) Release schedules for the past two years and projected schedules
as known
6) Will Transit Services be required to implement each new release and if not, what is the Proposer’s policy concerning this issue?
7) Documentation updates
D. Continuing education
E. Describe the terms of the software license. Is the license a one-time fee or an ongoing fee?
G. Availability of users groups 20. OPTIONS
Please provide pricing for optional services and any other options that may be available from the proponent.
a. Notification Option - In order to decrease no shows, provide for automated call outs and alerts to riders to remind them of trips and service updates.
Page 15 of 16 b. Web Based Booking Option - Provide web based on-line booking/cancellation
capabilities for Specialized Transit passengers in a format that conforms to WCAG 2.0 Level AA web standards.
21. AWARD and APPROVAL
Each proposal shall include hardware and software warranty information for all equipment and software to be supplied by the Proponent as a part of this project; detailed instructions and specific resources for obtaining maintenance on hardware (if applicable) and software support; and list the annual cost of software support and periodic updates for each component following the first year of project operation. The cost proposal (Attachment A) shall include the cost of all necessary licenses as well as the cost of software support and upgrades for the first two years of operation as a minimum. The actual period of time for system maintenance, support services and periodic updates included in the initial procurement cost, the schedules and any deadlines for renewal will be fully described in the Cost Proposal.
Evaluation
This is an RFP, which shall be awarded based on evaluation of the criteria set out in this Section.
Evaluation Committee
An Evaluation Committee, comprised of the General Manager of Transit Services Manager of Transit Services Operations, the Manager of Supply and Services, the Manager of Network Services and a Representative from St. John ambulance, will be evaluating submissions using the Criteria outlined below The City reserves the right to change the makeup of the Committee, if required.
Demonstration and Interview
As part of the evaluation process, the Evaluation Committee may undertake an interview process with a short-list of Proponent(s). Should this be required, a date will be determined following the Closing of the RFP. Proponent(s) selected for an interview will be required to provide a demonstration of the software and the requirements of this RFP and answer questions on their submission and presentation. The identified Project Manager must lead the
demonstration and interview. After the presentation, the Evaluation Committee may amend their initial ratings, based on the results of the presentation.
Clarification and References
The City reserves the right to contact any Proponent to seek clarification of the contents of their Proposal. Some scores assigned to the various categories may be determined through
reference checks. The reference checks will be completed for the highest scoring Proponent. The purpose of reference checks is to confirm the elements contained in the RFP submission and to verify the success of the Proponent with past projects. Should the highest scoring
candidate receive one or more negative reference(s), the City, at its discretion, may remove the Proponent and proceed to the next highest candidate. The City may investigate as it deems necessary to determine the ability of the Proponent to provide the goods/services, and the Proponent shall furnish the City all such information and data for this purpose as the City may request. The City reserves the right to contact any or all of the supplied references and may disqualify Proponents who have been given negative performance/service and/or quality ratings
Page 16 of 16 by supplied references or other references contacted. Reference checks initiated by the City may not be limited to contacting those references provided by the Proponent. The City may consider all available Specialized Transit Scheduling Software Supply and Installation information, including prior performance on other City projects, prior performance with the consultant, information concerning other projects, and information provided by other clients contacted by the City as a reference. The City reserves the right to reject any Proposal if the information submitted by the Proponent or investigation carried out by the City fails to satisfy the City that the Proponent is qualified to fulfill the obligations of the Agreement.
Evaluation Criteria
Each Proposal will be evaluated on its own merit in relation to the criteria stated in Appendix D - Evaluation. The City reserves the right not to accept any Proposal.
Proponent with lowest cost will be given full percentage rating for these criteria. Next lowest and all others submitted will be given rating based on percentage difference to lowest cost.
Recommendation/Award
Recommendation for award of this RFP will be based on the Proponent's overall total score. By responding to this RFP, the Proponent agrees to accept the recommendation of the Evaluation Committee as final and binding. The award of this RFP shall be in accordance with the City of Niagara Falls’s current Purchasing By-law. The decision of the City will be final. The successful Proponent shall not make any claims for additional costs, or expenses, due to the delay in, or cancellation of, the award of this RFP due to the approval process.
Requirements on Acceptance of Award
The successful Proponent will be required to submit, within 10 business days of notification of award of the RFP, and prior to the start of the Work, the required copies of the Software License Agreement, and:
a. Completed regarding Accessibility for Ontarians with Disabilities b. Final Work Schedule and
c. All license fees for all commercially available software that is not already available at the City
