New Software Adoption for Small Transit Agencies Guidebook Structure
- Date: February 18, 2022
Jump to section
Guidebook Focus and Software Types
The Guidebook primarily focuses on specific types of software—shown below—that are common for many small transit agencies. Of approximately 1750 small transit systems of less than 20 vehicles in the USA, over 1125 (65%) are providing some form of demand responsive transportation service and therefore require trip booking and scheduling capabilities (although for very small systems this function can often be accomplished without an actual software product designed specifically for this purpose). However, the Guidebook is applicable to essentially all software relevant to small transit agencies.
1. Trip planning
Trip planning software enables a customer to view their transportation options online, typically across most or all available choices such as fixed-route transit, demand-responsive transit, bike sharing, walking, and other modes that may be available in an area. This software type enables a customer to quickly compare their options across multiple factors such as trip duration, departure/arrival time, cost, and other factors. More advanced versions of this type of software support “trip chaining” or combining multiple legs of different modes in a single trip (e.g., bike to fixed-route transit or demand-responsive transit to fixed-route transit). This type of software is typically accessed through a website or mobile app.
2. Trip booking and scheduling
Trip booking software enables a customer to book a ride on a demand responsive transit (DRT) service and to be provided with information on when the vehicle will pick them up. The trip booking process may be done directly by the customer via a web-based or smartphone app-based application, or may be accomplished by an agent on behalf of the customer using an on-line booking application. Trip booking is often directly connected to trip scheduling in the software application.
Vehicle scheduling is a fundamental element of all transportation services, and takes different forms for fixed-route transit and DRT, with corresponding differences in the types of software required. For small fixed-route transit operations, the vehicle trips to be scheduled are those on a fixed set of routes with pre-determined timetables for the vehicles. Such schedules can often be managed in spreadsheets or very basic software that also includes driver scheduling.
DRT scheduling software manages the capacity of the vehicle fleet used in the service. It determines the routing of each vehicle and how customer pick-ups and drop-offs are sequenced; the scheduling system is at the heart of the software that manages a DRT system and there are many levels of sophistication in different software applications.
3. Trip payment
Trip payment software, accessed via a mobile app or a website, enables a customer to purchase “tickets” for transit services via digital mechanisms. Such software utilizes payment methods such as credit and debit cards, and may also have options for “unbanked” customers. In some cases, trip payment software is directly connected to trip planning and/or trip booking software (i.e., customer reviews options via a trip planner, books the preferred trip, and then pays in advance).
Chapter 1 / Step 1: Set the Software Scope
This chapter breaks down the process of setting the software scope into three activities.
1. Clarify the Software’s Purpose
Clarifying the purpose of the software involves identifying which software type is needed. For service operation needs, it is usually clear to the agency’s staff the type of software which is needed, but there may need to be a more formalized process if the functional needs span different types of software or if customer facing software is involved. A suggested approach for handling these types of situations is presented.
2. Identify General Software Connectivity Needs
Whether an agency is acquiring multiple types of software to meet its needs or is adding a new type of software to its current software ecosystem, it is essential that it determine how much connectivity between the software applications will be needed. If the different software applications need to exchange data with one another, then the software must be “interoperable”. When interoperability is necessary, the agency must ensure that its software acquisition process makes this a high priority in terms of the scope of the acceptable software solutions.
3. Anticipate Resources to Apply to Software Adoption
Resources relevant to the software adoption process include (at a minimum) financial resources, staff resources, existing software and computing infrastructure assets, and collaborator resources—financial, staff resources, or assets from partner organizations.
An agency should create an inventory of its likely available resources early on in order to be prepared for later steps in the process. Substantial financial and staff resources will be necessary for the procurement process that is part of Step 3: Move Forward with a Software Product and may also be needed in Step 4: Support the Software for tasks such as training staff members on the software and maintaining it.
Chapter 2 / Step 2: Collaborate with the Software Stakeholders
This chapter discusses the importance of working effectively with stakeholders and how that can be accomplished. Ways to identify the stakeholders to include in the process, and to then to actively involve them, are provided. Identifying the full range of stakeholders is important both to ensure that the software being acquired has the necessary functionality—an outcome facilitated by all of the key software users being involved in the planning and acquisition process—and to establish the collaborative process needed for the adoption of the software to move forward smoothly and effectively. The software stakeholders can generally be disaggregated into 3 categories, as explained below.
The manager of the overall process, the software adoption lead, is responsible for creating a tailored information gathering approach to integrate stakeholder findings. These findings will be incorporated into the development of the procurement documents—integrating the key concerns of each stakeholder group into the process.
Chapter 3 / Step 3: Move Forward with a Software Product
Small transit agencies today have a choice among multiple types of software products that address the same functional needs of the agency. These include commercial off the shelf (COTS) products, open source/public domain software, and custom software solutions. The advantages and disadvantages of each is discussed in this chapter.
During the past decade, there has been a strong trend in business software in the direction of Software as a Service (SaaS) approaches. Among multiple advantages of a SaaS purchase, a major advantage for a small transit agency is that it does not have to concern itself with the computing infrastructure on which the software is hosted. This chapter discusses the relative merits of SaaS approaches compared to licensed software products that are hosted by the agency itself or for which the agency is directly responsible. For small transit agencies, software solutions that avoid the agency needing to be responsible for their own computing infrastructure are typically advantageous, assuming that broadband data access is available.
This chapter provides high level descriptions of the various functional types of software products that are relevant to small transit agencies and the roles they may play. This includes products for both fixed route and demand responsive services, and for operational use as well as those used primarily by the agency’s customers. There is also a discussion on software inter-operability, which becomes increasingly important as agencies acquire multiple software products and/or wish to engage in programs—such as mobility management—with other organizations.
It is important for small transit agencies to understand just what it is that software ownership requires of them if that software is to be most effective in serving their purposes, and the chapter includes a relatively detailed explanation of this. This includes such topics as software implementation, configuration, staff training, and upgrades.
The affordability of the software product is obviously of major concern to a small transit agency, and the different costs associated with the acquisition and on-going use of new software are identified and explained. There is a comparison of the different costs for the purchase of a SaaS product and a comparable licensed software product that is hosted and managed by the agency itself.
The chapter concludes with a series of 7 steps that need to be navigated from the time when the agency decides it wishes to acquire new software until the point when the software becomes operational for the agency, enabling them to move forward with a software product.
Chapter 4 / Step 4: Support the Software
The acquisition of a software product is merely the beginning of the process of incorporating it into the operations and daily use by the staff and customers of a small transit agency. For the capabilities of the software to be of maximum value to the agency, the agency needs an effective approach to support the software.
Agencies are likely to obtain the greatest value from their software if they forge a strong partnership with their software provider, a process that should begin as soon as the decision has been made about which company’s product will be purchased. Using the partnership approach as the underlying assumption about an agency’s working relationship with the software producer, support for the software system will mostly involve the following 3 activities:
- Plan for One-Time Software Setup and Training
- Prepare for Ongoing Support Needs
- Consider Additional Support as the Software Scope Expands
Support activities will differ for software that is primarily “customer facing” compared to that which is “agency” facing, and the needs for each of these types of software are described and contrasted.
A series of post-procurement, one-time activities will be necessary in order to make the software operational, namely (1) software deployment, (2) software configuration, and (3) training of the agency’s staff in how to use the software. Once these activities have been accomplished, it is essential that the agency make a full commitment to effective use of the software on an ongoing basis. What that means in practical terms is described, in particular the importance of incorporating software support priorities into the agency’s planning and budgeting process. This is directly relevant to the ability of the agency to obtain major upgrades of the software and/or additional modules, which is typically desirable.
This chapter, and the Guidebook, conclude with a discussion of how opportunities to expand the scope of an agency’s activities are likely to have implications for its software needs and the factors that they need to be aware of as they assess how to respond to such possibilities.