New Software Adoption for Small Transit Agencies Chapter 4, Step 4: Support the Software

Congratulations! You just acquired a new software system for your transit system. It’s not the same as having a new child born, but there are more similarities than you might realize if you want to have a gratifying outcome for what now begins to unfold.

Assuming that your organization followed a good process to acquire the software—such as the one described in Chapter 3—you now have a software system capable of supporting the core requirements of your transit service as well as the needs of the customers who use that service. But if the capabilities of the software are to be of maximum value to your agency, careful consideration needs to be focused on organizing how you move forward with the software. Just as properly raising a child requires dedicated attention and an on-going concern with providing them an environment that maximizes their potential for development and growth, effectively incorporating a software system into the core of an agency’s service delivery system requires a similar approach.

General Software Support Needs

Now that you have purchased the software— including training in the software for those employees who will work directly with it as well as a maintenance and support contract—it is your responsibility to get full value for your investment.

In this chapter, we will provide you with specific guidance about how to do that. But you will be most successful in those endeavors if from the very start you make your software company your partner in this process.

The Importance of a Software Provider Partnership

Supporting the software begins with your relationship with the company that developed the software. This cannot be over-emphasized. Even the best software doesn’t always function in the ways that we think it should—minor software glitches or frustrating experiences with widely used software applications that have been around for decades are a fact of everyday life. But with special purpose business software, which is the type of software that you have acquired, the relationship with the company that produces the software is different than when you are a normal consumer. The producer of your software application has a powerful business incentive to be responsive to you.

Your transit agency is one of a small number of organizations—often numbering less than 100, and rarely exceeding 1000—with whom the company that produces your software does business. Every one of those customers is typically important, particularly since once they begin using the software company’s product they often do so for many years and represent that which is most valuable to every software producer—recurring revenue. No software company wants to lose a single customer if they can avoid it, as they are both difficult to initially acquire in a competitive market and represent a durable revenue stream which can even significantly increase in value over time.

This means that your agency should view its software provider as a partner in your efforts to make your service work as effectively and efficiently as possible. That partnership begins the day you decided to acquire their software and will continue as long as you are sufficiently satisfied with how the software performs to want to continue to use it. It also means that if you begin to experience dissatisfaction with the software, you need to communicate your concerns to the software provider and afford them the opportunity to improve your situation—which is what partners do. The continuation of the partnership is predicated upon them being responsive to your concerns. If they are unable or unwilling to be responsive, it means that it is necessary to find a new software company partner at the earliest feasible point in time.

How do you become a partner with the software provider? It is very simple—first and foremost you communicate with them. And what is the core message that you communicate? That we are in this together. They are the experts in technology and how it can make your operation work more effectively compared to no such technology—and your team are the experts in your services and the specific objectives you have for those services. Your software provider’s job is to make the software work as well for you as it can—and your job is to help them understand, at a detailed level, what you want the software to accomplish for your organization. Your collective task is to learn from each other so that both parties are aligned to support your objectives for your service(s). This is what software support is really about.

Using the partnership approach as the underlying assumption about your agency’s working relationship with the software producer, the steps shown above will, for most agencies, be the focus of their support for the software system. The specifics of each of these steps are discussed in the sections that follow.

Your Software Type has Major Implications for Support Activities

Before we consider the different types of support activities identified above, it is essential that you understand that the type of software you have acquired will have a major impact on what the specific focus of your organization’s support activities will be. In this context, the “type of software” refers to whether it is intended to be used primarily by your agency’s customers—typically referred to as “customer facing” applications–or by your agency’s staff to manage the operation of your transportation services—referred to for discussion purposes as “agency facing” applications.

Customer-facing applications provide important information directly to the trip maker—the latter is the user of the software, not the agency. In most cases, these applications are highly-automated and the user simply interfaces with their computer or mobile device to obtain the information they need and/or to transact with the transit service in some way, such as booking a DRT trip or purchasing a digital bus ticket.

The ride hailing applications of Uber and Lyft are widely used examples of this type of software, as is Google Maps when used for planning a transit trip. For these types of applications, your agency’s staff has little or no role in the user process.

Sometimes these applications have very fine-grained functionality. For example, DRT software systems often include very robust manual scheduling and dispatching features that are intended to be used only by an experienced scheduler/dispatcher in an operations center. These same systems may also include highly functional trip booking capabilities used by reservations agents. However, the ability of a staff member to handle the reservations element of the software application would provide them with little or no competency vis-à-vis the manual dispatching element of the software. Agency facing applications typically require the users to have specific competency with the different functional components of the software product that they are using.

Of course, some software systems for small transit agencies encompass both agency-focused and customer-focused types of functionality, or the agency uses separate software products that have these different focuses. In such cases, the agency needs to understand the imperatives of software support for both situations.

An example would be a CAD/AVL application for fixed route bus service used by a bus operations manager or dispatcher to monitor the status of vehicle operations. The data collected from wirelessly-enabled GPS devices on the buses is also transmitted to another application designed for the agency’s customers—with a customer-facing web-based user interface—that displays information about when a bus will arrive at specific bus stops and if it is on-time. The functionality needed by the customers is simply to have a user-friendly view of accurate information. The agency staff also needs similar functionality, but in addition the software they use will include functionality for taking remedial action if a vehicle is seriously off-schedule or experiencing operational difficulties, and the staff must be competent in using such functionalities appropriately.

Important implications follow from these distinctions between types of software and are discussed in the following sections. In general terms, for software that is primarily customer facing, the most important focus of support is on (1) maintaining high quality data, and (2) ensuring that the software provider is made quickly aware of any issues that customers have with using the application so that rapid improvements can be made. For agency facing software, support priorities will be on achieving the highest possible levels of knowledge about the software’s capabilities and a correspondingly high level of competency in use of the software by the agency staff.

Step 4a. Plan for One-Time Software Setup and Training

Purchasing a specific software product is merely the first step in the process of making that software useful to your agency. As soon as the procurement is completed, the partnership with the software provider begins, with 3 activities involving both the agency and the software company typically occurring in relatively rapid succession:

It is important to emphasize that user training is a process that begins with training classes organized and led by the software provider, but this is merely the start of the agency achieving competency with the software. In fact, this is the point in the software implementation process where the agency’s support for the software truly begins, as the activities until this point have been driven by the software provider and the imperatives of simply making the software operational for the agency. But with the conclusion of formal training, the agency’s internal processes become the primary locus for support of the software, and the issue of agency engagement comes to the forefront.

Agency Engagement

Successful support of a software application, particularly one which is primarily agency facing, requires the active engagement of the agency to fully integrate the software’s capabilities into their day-to- day operations. When one visits an agency that has achieved this objective, it is obvious—the capabilities of the software are fused with the capabilities of the people in the organization who utilize it to run the transit services. One observes staff members who use the software as an integral element of their work, and often understand its capabilities at a deep level. They can explain to you not only what it does, but its strengths and weaknesses as well. They often are not simply competent; they are experts in the use of the software.

Not surprisingly, these organizations typically have close, partnership-style relationships with the software provider. Equally unsurprising, they have often used the same software system for many years and have little interest in changing to another software provider’s system.

It is commonly said that such agencies have “taken ownership” of the software application. For agency focused software in particular, taking ownership is the single most important thing that an organization can do to support their software system. Activities that naturally follow from the taking ownership perspective—ensuring that users are adequately trained and knowledgeable, embedding the use of the software in core agency processes, maintaining good relationships with the software provider so issues can be quickly resolved if they arise— maximize the usefulness of the software to the agency.

Taking ownership by the agency is also important for customer focused software, but the fact that there are many other users of the software than the agency’s staff in such situations means that it can at least partially rely on its customers to assess how well the software functions and to alert it to issues. It is always preferrable, of course, for the agency itself to be the entity that is most knowledgeable about its own software, but the reality is that the customers will typically have much more experience with the software than the agency staff in the case of customer-facing software. In these circumstances, taking ownership can mean that the agency regularly reaches out to its customers (via surveys, for example)—or has established on-going focus groups for this purpose—to determine their level of satisfaction with the software and to elicit suggestions for improved functionality.

Step 4b. Prepare for Ongoing Support Needs

As emphasized previously, supporting the software is as much about an agency’s orientation towards this technology tool as any specific set of activities. At the same time, there are specific activities that are important to undertake to maximize the value of the software and to minimize the potential for problems to arise.

Impact of SaaS/Hosted Software on Necessary Support Activities

An important distinction for software support activities is between agencies that are using a Software as a Services (SaaS) product or a licensed product that is hosted externally, and those which are using a licensed product that is hosted on the agency’s premises (the CPE model). A compelling advantage of the SaaS/hosted product approach is that the agency itself is not responsible for maintenance of the software or keeping it in an operational state at all times. For small transit agencies, supporting a software application is simply much easier and less prone to problems when another organization, which has the resources and the skills to be able to handle this function as a matter of course, is responsible for keeping the software running properly all of the time. Moving the hosting, maintenance, and support function to another organization for whom this is a core business can be a powerful action to improve the support of the system.

Planning and Budgeting for Support Activities

Software support costs money. Not merely the money your agency has already paid—or will pay in upcoming years—for the support and maintenance contract you presumably purchased from your software provider. But also, money to ensure that your staff continues to be adequately trained in how to use the software—since you can anticipate some staff turnover as time goes on and new staff members will need training if their position requires use of the software. Money will also be needed to pay for major upgrades of the software if those are not included in the cost of the original purchase or the maintenance/support contract. If the software system has optional modules that you did not purchase but could be of value in the future, their potential costs need to be accounted for. The same applies to other types of software that now become relevant as a result of the software that you have just acquired or could enhance the value of that software.

In addition, if the software is “mission-critical”— fundamental to the core transportation service you provide, as is typically the case and almost always applies to DRT software—you may wish to invest in improving your staff’s knowledge and competency vis-à-vis the software. Most software producers have annual events—sometimes called user group conferences—at which they provide courses in more advanced learning about their software. Attending the annual event will have a cost but the courses are typically included in the registration fee. Moreover, if your staff attends such an event, they will meet “power users”—individuals highly proficient in the software—from other agencies. Such persons are typically an excellent source of additional knowledge and “tricks of the trade”. While sending one or more staff members to attend a user group conference may represent a significant investment for a small transit agency, it often can result in significant dividends, and needs to be seriously considered.

Since the potential costs to the agency associated with support activities such as those cited above have budgetary implications, they must be considered as part of an agency’s planning and budgeting process. If an agency purchases software in Year N, and intends to purchase an optional module in 2 years, and also wants to send a staff member to the software provider’s user conference in that same year to obtain training and knowledge from other agencies in how to use this new module, it will need to make provision for these additional expenditures in Year N+2. If the agency anticipates it will be too financially constrained to afford these expenditures in Year N+2, it will be necessary for it to develop plans for how to effectively support its transit service in the absence of the optional module in Year N+2.

In general, the agency should develop an annual software support budget that includes all of the relevant potential expenses shown below.

Software Maintenance

If on-going satisfactory operation of the software system is or must be the sole responsibility of the small transit agency—as will be the situation with a licensed software product that operates on the agency’s own computing infrastructure—maintenance of the software will be a key on-going activity. As noted in Chapter 3, it may be possible to engage a local technology firm to take on the responsibility for this function, and agencies are encouraged to consider this approach.

The software provider will typically provide its customers with a documented, recommended set of maintenance activities (e.g., shutting down the server once every 7 days and re-starting it to clear the memory of the computer) that should be followed in order to minimize the possibility of problems occurring. Every software application has a different set of recommended/required maintenance activities, often relatively minimal for contemporary hardware and software.

Occasionally software providers will release “patches” to a software application. This occurs when a defect has been discovered in the software that is significant enough to warrant developing a “fix” (a term used more or less synonymously with “patch”). The software provider distributes the patch to its customers (either on a CD it sends to them or via a download from the Internet to the server running the software), who install it and then re-start the software application.

While this process normally goes smoothly, there are times when problems occur when installing a patch. For this reason, some organizations are reluctant to install patches, particularly if their system has never manifested the problem that is being fixed. (This will be the case if the patch is related to functionality that the agency never uses.) The philosophy of “if it’s not broke, don’t fix it” is not necessarily incorrect. However, if by following this approach, i.e., not installing some or all patches, the version of the software that the agency is using begins to deviate significantly from the current version of the product, difficulties can occur when the agency really does need to install a patch. Hence it is important that agencies do follow the software provider’s recommendations about maintenance updates to their system.

Software Upgrades

Software providers typically release upgrades to their products periodically, sometimes on a regular cycle. These software upgrades are of two types:

For agencies that use a SaaS product, both routine and major upgrades occur automatically with no action needed by the agency. (This is one of several reasons that small agencies should be seriously considering SaaS products.) The SaaS software provider will inform its customers of such upgrades, and for major upgrades—which are less common than for licensed products, as smaller upgrades typically occur frequently, reducing the need for major upgrades—it will make its customers aware well in advance of the changes that are coming.

For agencies using a licensed product (even when hosted externally), routine upgrades are typically provided at no additional cost beyond that associated with the annual support and maintenance agreement. However, major upgrades typically must be paid for separately, and the cost to the customer may be significant. Every software provider has a different approach to pricing of upgrades.

A major software upgrade can represent an opportunity to obtain a significantly improved version of a software application, particularly when desirable new functionality is included in the upgrade as can often be the case. At the same time, since major upgrades typically need to be purchased separately from the annual maintenance and support contract, the agency will need to make a determination of the merits of the necessary investment. As explained in the Planning and Budgeting section, an agency that has purchased a licensed software product should be allocating funds in its annual budgets to be able to afford the cost of periodic major software upgrades.

If an agency does decide to purchase a major upgrade of the software, it should also allocate resources for additional staff training if the upgrade contains significant new functionality, which will often be the case. This may involve sending one or more staff members to a training class conducted by the software provider. The staff member(s) who have themselves been trained can then train other staff members who use the software.

Additional Software Modules

As discussed previously, many software systems have additional, optional modules that can be purchased either as part of the original acquisition of the core software application or at a future point in time. An important part of supporting your software is to periodically evaluate the functional needs of your service—and your customers functional needs for using the service—and determine whether the optional modules from your software provider would be of significant benefit in meeting such needs. If so, your agency should seriously consider purchasing them.

Step 4c. Consider Additional Support as the Software Scope Expands

The fundamental reason for small transit agencies acquiring and using software is to improve their capabilities for service delivery management and customer inter-action. Typically, those capabilities are limited to discrete services provided by a single transit organization operating in a defined geographic area. For some agencies, however, it can be the case that the scope of their service offerings expand over time, or they begin to engage in activities with other, near-by agencies in pursuit of common objectives.

For example, Mobility Management programs typically involve multiple agencies and making service capabilities available to the public that may be broader than the services provided by a single agency. Or an agency that has been providing fixed route transit and ADA paratransit services determines that it also wishes to provide general public DRT services in all or a portion of its service area.

In such cases, the scope of the original software system will often not be adequate for the needs of the new or planned situation. In some cases, an optional software module linked to the core software application may be able to fill the need, but in other cases the original software system cannot be “stretched” sufficiently to meet the requirements of the new situation.

In these latter situations, the agency is likely to require additional types of software to meet its needs. These software solutions will typically be one of the following:

In important ways each of these situations represent new software procurements and not more typical software support activities, hence the guidance presented in Chapter 3 about procuring new software is completely relevant and applicable. At the same time, for the first two situations, the primary objective is to extend and expand the capabilities of the agency’s existing software so that it can support important new agency objectives, and in this sense those situations fall squarely into the software support category.

Moving Towards Inter-Operability, Integration and Platform Capabilities

When a small transit agency needs or desires to significantly expand the capabilities of its existing software to encompass functionalities associated with other software systems, it is moving into a different type of software support situation. Assuming that it is satisfied with the software it is already using, the agency’s objectives are likely to include one or both of the following:

Agencies which find that their needs and opportunities are evolving in this direction should be aware that they are on the cutting edge of developments in small city transit services. While relevant and applicable software does exist, there is very little experience in actually developing effective Mobility Management programs or MaaS-type services for small city/rural/tribal transit systems.

There are software companies who have some experience in doing this, but many do not—and the experience base to date is quite limited and primarily involves urbanized area transit services.

National level organizations such as CTAA or RTAP are keenly aware of the opportunities for software technologies to serve as the building blocks for actual implementation of such concepts as Mobility Management and MaaS and have sponsored the creation of resources to disseminate up-to-date knowledge about the state of the art and current possibilities. Some state DOTs (e.g., Minnesota, Michigan among others) are also knowledgeable about this emerging situation and can serve as effective resources.

We recommend that small transit agencies whose next steps of software support activities involve this movement towards more comprehensive software platforms—including some level of data integration and functional inter-operability with other software products—should reach out to external resources to educate themselves about their options. Software for small transit systems is continuing to expand in scope, sophistication and ease of implementation— particularly as a result of the advent of SaaS solutions—and the available capabilities have never been greater.

Adopting a Partnering and Learning Approach

This chapter began with the suggestion that effectively supporting an agency’s core software systems is somewhat akin to raising a child from birth. Hopefully the applicability of that metaphor is now more apparent. By creating a partnership with your software provider, achieving a high level of staff competency with the software application that you have purchased, carefully considering how much computing infrastructure support your organization should be providing and how much it should obtain from others, and allocating your financial resources carefully to increase your software’s capabilities— and your staff’s capabilities to use the software effectively—as your software provider releases major upgrades, your agency can develop a growth and maturation pathway for the integration of your core software with your core service operations.

As your agency’s technologically-enabled functional capabilities increase and become more efficient – just as a child’s capabilities and scope of competency increase as they grow and develop— more possibilities for effective outcomes for your organization and its customers become manifest.

With the advent of new generation software platforms for integrated trip planning, fully automated DRT services, Mobility as a Service, and mobility management types of initiatives such as the Denver Trip Exchange, small transit agencies can afford themselves of technology capabilities that even 7 or 8 years ago they could not conceive. Moreover, with the rapid adoption of Software as a Service models of software delivery, small agencies can now access such sophisticated technology with far fewer practical complications than has been the case previously.

By adopting a partnering and learning approach, a small transit agency can use its necessary software support activities to create a foundation for scope expansion initiatives when those would provide additional functional and customer-serving benefits. This Guidebook is intended to provide you with developmental pathways to more cost-effective and comprehensive service delivery capabilities—which is the ultimate objective in terms of your agency delivering customer benefits. Software clearly has a major role to play in achieving such results and understanding the accomplishment of these objectives as being fundamentally a developmental process—like bringing up baby—can help clarify the needed activities.

Illustrative Project

The Denver Ride Alliance Trip Exchange is a cutting-edge example of scope expansion. It is a new software-enabled transportation program just implemented in the Denver region that will enable providers of human services transportation (HST) to share capacity and exchange trips. Beginning in 2015, multiple organizations in the Denver region—the Regional Transportation District (RTD, the region’s public transit agency), 3 large HST service providers (one of which is part of a city/county government), and a regional scale organization responsible for overseeing human services transportation—embarked on a multi-year effort to develop the technology necessary to achieve the objective of actually accomplishing transactional coordination of human service transportation resources. They secured 2 large federal grants and sponsored the development of the software platform that makes this feasible.
The Trip Exchange software platform makes it possible for agencies—or actually any participating entity—that have trip requests for which they have no available capacity to send the data for such trips from their DRT software systems to the Trip Exchange software platform via automated means. Participating organizations—whether human service agencies, transit agencies or local governments—whose transportation programs have the capacity to fulfill these trips can claim them via the functionalities built into the Trip Exchange software.

Such claimed trips are then exported—via automated means—into the claimant agency’s DRT software system. In addition, the Trip Exchange software platform includes API’s (discussed in Chapter 3) that enable the RTD’s FlexRide system (DRT for the general public in 23 service zones) to also participate via its software system. The software platform has been designed so that the RTD’s Access-A-Ride (ADA paratransit for the region) system is also technologically capable of being easily connected with the Trip Exchange and this may occur during 2021.

The HST service providers use a DRT software application from the same large software provider, and that software application has been modified so that it can now interface with the Trip Exchange software. Data for the trips of the HST providers can be transferred back and forth with the Trip Exchange using automated mechanisms. The RTD’s own FlexRide services (which use a different DRT software product) can also interface automatically to the Trip Exchange to claim trips under appropriate circumstances.

The Trip Exchange software application itself is an example of public domain software, as the funds for its development (accomplished by a different DRT technology company than the one whose software is used by the HST providers) came from the FTA grants secured by the region. Moreover, its inspiration and original functional model came in important measure from an open source software application developed for an organization in the Portland (OR) region.

Within the Denver region, the precursor to the Trip Exchange system was itself an earlier scope expansion of DRT software applications. The Longmont Coordination System (Longmont is a city of 80,000 population located in the northern portion of the RTD’s service district) operated from 2012 to 2019 and enabled the FlexRide program and Via Mobility Services, a large human services and health care transportation service provider, to exchange trips local. A data interchange mechanism was developed by the same two software companies involved in the Trip Exchange project, making it possible for the FlexRide service to utilize Via’s excess vehicle capacity during certain hours of the day, and for Via to place ambulatory passengers onto the schedules of the FlexRide vehicles when Via had insufficient capacity.

It is important to emphasize that while the Trip Exchange software itself was newly developed for the Denver region, the ability of the agencies in Denver to interface with the Trip Exchange is a case of pure scope expansion. DRT software already existed for the RTD services and for the HST providers, what was needed was the determination and the resources to extend the capabilities of the DRT—and the DRT software—to be able to cross-utilize available capacity. First the Longmont Coordination System, and then the Trip Exchange, made it possible to achieve this objective.

More details about this project are available on the National Center for Mobility Management’s (NCMM) One-Call/One-Click Resource Center, on the Denver metro area spotlight project page.