The following is the sixth in a series of blogs on demand response transportation design and operations from guest blogger Steve Yaffe. This blog highlights how to prepare a Request for Proposals in procuring transit technology.
The technologies requested in a RFP Scope has to be scaled in two directions: the functionalities needed and the funding available over the contract term. The Independent Cost Estimate (ICE) should correspond to the expected available funding as well as the functionalities discussed in the Scope.
Solid RFPs are best prepared as a partnership with a purchasing officer, who can serve two purposes:
- Ensure that the document is in compliance with procurement best practices and your agency’s policies; and
- Provide a non-transportation perspective and ask you for clarifications to ensure that the language is clear, and the flow is logical.
While references below to Contractor would refer to the vendor, the Client would be the organization or agency purchasing the functionality.
Service Area Description
The characteristics of the service area affect the functionalities that can be obtained. By characteristics, please think beyond just the jurisdictions served, land area, and population of the service area; the peak bus requirement; annual ridership, costs, revenues, service miles and hours; discussion of clientele groups and their service needs; and annual or monthly reports.
Technology vendors need to know the environment of the service area. Does the service area have cellular coverage throughout; mostly but with holes; only in sections; or little-to-none? Does the service area have FM-band coverage throughout; mostly but with holes; only in sections; or little-to-none? Dispatch technology can be adapted either to cellular tracking or FM tracking – whichever makes more sense locally. If both are available, the vendors would provide a cost comparison. A general description of the topography might also be relevant – especially for mountain ranges and deep valleys.
Description of Current Service
Vendors will inquire as to the current technology being used for scheduling and dispatch including communications. This section needs to include the service structure, which may include a call center, multiple ride providers, and several agencies that fund rides. The fare structure and client intake process should be included, as well as average weekday/Saturday/Sunday trip and call volumes.
Purpose of the Procurement and Data Ownership
A statement is needed regarding the purpose of the functionalities to be procured. What deficiencies need to be remedied? A general statement might begin with enabling the client (or call center) to manage and operate multiple transportation programs and services in a manner that equitably, efficiently and fairly distributes all trips. This functionality includes passenger trip reservations, program/provider selection, and automated and manual vehicle scheduling. The software shall support vehicle dispatching by the dedicated fleet transportation vendor as well as that vendor’s provision of Medicaid Non-Emergency Transportation rides booked through the program. Other services shall also be supported, whether provided by dedicated vehicles or taxi-dispatch. The software shall provide operational and financial reporting, and National Transit Database reports on a monthly basis by provider. The software must be capable of alerting riders traveling to or from a service site, if that location is closed or must close early due to unforeseen circumstances.
This section should also specify that the client retains ownership and all rights thereof to all data and reports produced and be granted unencumbered access to all client data. The vendor shall provide a “data dictionary” showing each database and defining each field in those databases. The software, hardware and licenses associated with producing and transmitting that data shall be the property of the Contractor (vendor).
Demand Response Transit Technology Functionalities
As discussed in the previous blog, the price sheet should split out the cost of each overall functionality: Telephonics; Booking and Scheduling; Dispatch; Website; etc., recognizing that these are interdependent. These functionalities can be both listed in a table and detailed in text.
This section should begin with a paragraph or two stating the procurement objectives. Vendors will want to focus on strategies to improve performance in areas already identified as lacking.
The functionalities table was adapted from a combined call center/demand response technology procurement. The foundational scheduling strategy leading to this table was discussed in my fourth blog. Some of the italicized line items in the table may be viewed as optional. Vendors could be offered the opportunity to comment on each provision. Sections 1.38-1.48 refer to optional appendices that provide detailed descriptions.
Your comments to these blogs are welcome – please email the author at yaffe@YMobility.info.
Steve Yaffe is an independent consultant and a contractor for the National Aging and Disability Transportation Center. He draws upon 40 years’ experience planning, procuring, overseeing and evaluating demand response and fixed route transit services, including 16 years with a consolidated human service transportation program. He has served on research panels and co-chaired the 2019 Transportation Research Board’s International Conference on Demand Responsive and Innovative Transportation Services.