New Software Adoption for Small Transit Agencies Chapter 3, Step 3: Move Forward with a Software Product

This chapter opens with a number of topics that an agency should become familiar with in order to move forward with a software product. This information will prepare you to take the steps provided at the end of the chapter. The topics are shown in the menu above.

Available Software Product Types

When a small transit system obtains software to assist it in managing its services and operations, there are three types of software products that it may wish to consider. These options are described below, including their relevance for small transit systems.

1. Commercial off-the-shelf software, often referred to by its acronym, COTS

COTS software is explicitly a “product” that has been developed by a technology (software) company which not only sells the software, but also provides a license (or a usage agreement) that gives the buyer the right to use the software. The license agreement also warranties that the product will work as intended. In addition, the technology company supports the product for its customers. This includes periodically updating the product, including fixing any defects that are discovered in the course of customers using the software.

For purpose of this discussion, referring to a software product as a COTS solution has no implication for how that product is delivered to customers. As will be discussed subsequently, the recent trend toward software being provided to customers via the Internet from a location in “the cloud”, referred to as Software as a Service (SaaS), still involves COTS software.

COTS software is sold for a price that is specific to the company that has developed the software. Different COTS products that have similar basic functionality may be sold for significantly different prices. The price of a specific product will depend on the scope of its functionality, the importance of the software’s functions to the service being delivered, and the market position and reputation of the technology company. COTS software that is delivered via the SaaS model will have a different pricing structure than such software that is sold as a licensed product to a customer.

Core and optional software modules in COTS products

It is common for COTS products to include multiple software “modules”. In particular, there may be a “core” product which provides the essential functionality for a specific business need as well as optional “add-on” modules which provide further useful functionality, but which may not be necessary for all customers. There is usually an additional cost to purchase each optional module.

It is common for COTS products to include multiple software “modules”. In particular, there may be a “core” product which provides the essential functionality for a specific business need as well as optional “add-on” modules which provide further useful functionality, but which may not be necessary for all customers. There is usually an additional cost to purchase each optional module.

2. Open source/public domain software

Wikipedia defines open source software as “a type of computer software in which source code is released under a license in which the copyright holder grants users the rights to use, study, change, and distribute the software to anyone and for any purpose”. Source code means the actual software programs that make up a software product.

As this definition implies, open source software does not require payment to be able to obtain the software—it is “free”. As will be explained below, such software products are free only in the sense that a person or organization acquiring the software does not need to pay the entity that created the software for the source code.

It bears noting that open source software may have certain limitations on its use which will be specified in the license provided to those who acquire it. In particular, open source software is often restricted from being used in commercial software products. That means that if an organization obtains open source software and then develops—or pays for the development—of a new software application that also uses the open source code, it is legally

restricted from selling the new software. This should not be an issue for the typical small transit agency, but it is important to be aware of the legal restrictions that often accompany open source software.

Public domain software

Public domain software is a close cousin of open source software. Neither cost anything to acquire, but public domain software has absolutely no property rights, and hence no related rights such as copyright, trademark, or patent. Public domain software can be modified, distributed, and even sold by anyone without attribution. It can be used without restrictions.

At the same time, an entity selling public domain software as part (or all) of a software product does not possess any license rights to the public domain software itself, and the buyer can modify that specific software without restriction or additional payments to the seller. Of course, the buyer could obtain the actual public domain software for no cost if it wished. It is typically paying the organization that provides the software it is using because the software producer has embedded the public domain software in a larger product or is in some other way providing additional value to the buyer, such as configuring, supporting, and enhancing the software.

Why open source/public domain software is typically not costless

As indicated previously, open source software—and public domain software as well—can be obtained and used without paying the entity that developed the software. But that is the only sense in which such software is “free”.

In contrast to COTS products that are purchased from the organization that has developed them and which are accompanied by a warranty that legally stipulates that they will work as intended, open source/public domain software is obtained “as is”. The acquirer is totally responsible for installing and configuring the software, testing it with one’s own data, fixing anything that does not work properly, and supporting it once it is being actively used. These are all significant technical activities requiring competent, experienced software professionals in order to be performed satisfactorily. Clearly there are costs associated with engaging such resources, and those costs could be (much) greater than purchasing a COTS solution.

It is not common for organizations to use open source/public domain software for their own business purposes unless they possess technology resources—whether in-house staff or technology company partners—that can work with the software. When open source software is used, the most common approach is to purchase a package

of services from a software company that has demonstrated expertise with the software. Such companies implement the open source software for their clients, potentially modify and customize it for specific customer needs, and generally assist their clients in using it for their business purposes. These companies sell the ability for other organizations to use the software without needing their own technical resources to be able to do so.

Examples of Open Source/Public Domain Software Open source and public domain software have to date been infrequently used by small transit services, but there are a few relevant examples of such software:

When open source/public domain software makes business sense for small transit agencies

Small city/rural/tribal transit agencies require software for specific purposes, and for most of those purposes there is a reasonable set of COTS solutions that can be purchased from technology companies with substantial experience in this sector of public transportation. Moreover, because this sector is relatively mature, the technology vendors’ COTS products are priced competitively for the most part.

Obtaining open source/public domain software for core operations purposes in such circumstances is in most cases unlikely to be a sound business approach. There are certain situations, however, in which open source/public domain software may be relevant and appropriate, notably:

• Open source software that is provided by an established technology vendor which also configures, supports, and further develops the software as part of the product offering, for prices competitive with comparable COTS products.
• Coordination and/or integration of multiple agency’s services, including mobility management initiatives.
• Transit services that are very basic and do not require COTS products that include more comprehensive functionality.

3. Custom developed software

Custom developed software is appropriate when the functional and business needs of an organization are not well met by any existing software product. While this is not uncommon for business situations, which can be highly diverse even within a single industry sector, it is not typical for a sector such as small city/ rural/tribal transit where service approaches are very similar across organizations and there is a well- established eco-system of software companies with viable COTS products.

Where custom developed software is likely to be relevant is in situations where a basic product already exists but is not well-suited to the specifics of the transit agency’s needs. The basic product could be either a COTS product or open source/ public domain software. Using the existing software as the starting point for the custom developed solution could be a sensible business decision in such circumstances, as trying to fit a COTS software solution to a situation it is not designed for often leads to unsatisfactory results.

Determining whether custom developed software is a good solution for a transit agency

Determining whether a custom developed software solution is the most appropriate software for a small transit agency is a challenging exercise, as COTS software vendors will try to persuade prospective customers that their solution is adequate for their needs, even when it is only partially a good fit. It may be necessary for the agency to utilize external resources (e.g., knowledgeable staff members of state DOTs or larger planning or transit agencies) to help them assess their situation if they do not perceive that existing products are truly suitable for their situation.

Statewide or national organizations such as CTAA may also be of assistance, particularly regarding the possibility that an open source software application could be an appropriate starting point for a custom developed software system. These organizations may be more familiar with the open source software that is applicable, which is limited. The advantage of developing a custom software application using open source software is that it is likely to be less expensive—perhaps much less expensive—than customizing an existing software product. But this is predicated upon the existing open source software already including much of the core functionality that the agency needs.

Small city/rural/tribal transit agencies find themselves in many different sets of circumstances, and should not assume that just because their peers use COTS software that there will be a product that meets their specific needs. Custom developed software— particularly a variant on an existing product—can be a much better choice than a poorly fitting COTS product. But custom developed software will cost more than a COTS product—if one exists—and require technically informed and substantial agency involvement in and oversight of the software development process. Technically knowledgeable external resources can augment the agency’s own staff in managing the process, but this will involve additional costs. This is irrespective of whether the starting point is a COTS product or open source software—the latter will reduce the financial impact, but not the need for strong agency involvement and/ or technology consultant oversight.

Only agencies willing to accept these realities should consider this option when procuring software. Custom development is only for the brave.

Computing Platform Considerations

Until about a decade ago, a small transit agency purchasing a software product also needed to provide the “computing platform”—the computer hardware, networking devices, and other underlying hardware and “system software”—which is used by the actual software application that the agency is procuring. The computing platform is an essential element of any software system.

Today, there are multiple ways in which the computing platform can be implemented, with important implications for the transit agency which is procuring a software solution. The 3 major options for the computing platform are:

1. On site hardware and networking equipment (typically referred to by the acronym CPE, which stands for Customer Premises Equipment)
2. Hosted by a third party—which can be arranged by either the customer or the software provider, most typically the latter in the case of small transit systems
3. Hosted “in the cloud” by a Software as a Services (SaaS) provider who provides the computing platform as an integral part of its software offering

Recent Trend Toward Hosted Approaches for Computing Platforms

The strong trend during the past several years has been toward software being hosted “in the cloud” rather than on the customer’s premises. This does not mean that this is the most appropriate solution for every small transit agency, but there is a compelling reason for this trend. Namely, the CPE approach requires the agency to assume responsibility for the core hardware and local networking of computer workstations (personal computers used by staff members to access the software application).

This is clearly technically burdensome for a small agency, as well as associated with performance risk. In contrast, hosted computing platforms move the responsibility to a third party and the agency simply needs to understand how to use the software application and ensure that users have reliable Internet access—the remainder of the technology infrastructure is not their concern.

Potential Disadvantages of Hosted Approaches

Hosted approaches work very well when an agency has reliable high speed access to the Internet, i.e., access at broadband speeds. Broadband typically uses technologies such as cable or DSL which have large data transmission rates; the FCC defines broadband transmission rates as 25 million bits per second for uploading data and 3 million bits per second for downloading data.

The most recent FCC Broadband Progress report finds that approximately 19 million persons—6 percent of the population—still lack access to broadband service. In rural areas, nearly one-fourth of the population —14.5 million people—lack access to this service and in tribal areas, nearly one-third of the population lacks access.

Unfortunately, these data do not enable one to determine the situation in small communities—as opposed to the rural areas outside of those communities—since small transit agencies (tribal systems are a somewhat different matter) are almost always located in an actual city, albeit in many cases a very small one.

If an agency does not have reliable access to the Internet at near-broadband speeds at a minimum, it should probably not consider a software product that can only be delivered via a hosted solution. In such cases the agency will most likely be best off with an on-site computing platform. It is increasingly the case, however, that even small cities in rural areas have broadband access.

Software Product Purchasing Options

As a result of changing business practices in the software industry, as well as the transformative impact of cloud computing, software products are today sold via one of 3 different models, which are explained below:

1. Licensed software product (COTS) with annual support and maintenance fees.
2. Externally hosted version of the licensed software product—the software company (or a third party it designates) is responsible for the hosting arrangements.
3. Software as a Service (SaaS).

1.  Licensed software products

Until recently, COTS software products sold to small transit agencies were almost exclusively licensed software products. With a licensed COTS product, an agency is provided with a copy of the software that is installed on hardware in its own computing environment—typically the CPE approach, although essentially the same situation for third party hosting—and the agency receives a license to use that software for some defined period, perhaps indefinitely (usually referred to as a perpetual license).

Perpetual software licenses provide the agency with the ability to use the software for an indefinite period of time, but usually only the specific version that the agency purchases. Moreover, purchasing the license does not provide the agency with access to support for the software nor any maintenance

of the software beyond the warranty period, which is a defined period of time specified in the license agreement. The warranty promises that any defects in the software that are discovered will be fixed at no cost to the agency. Consequently, an agency will typically pay the additional fees for support and maintenance, since it wants to have a defect-free, reasonably current version of the software and the ability to communicate with the software vendor’s technical support team if it experiences difficulties in working with the software.

Each software company has its own practices— which are spelled out in the license and support agreement that the agency signs—about upgrades to licensed COTS products. Sometimes the support and maintenance contract enables the agency to obtain new upgrades at no additional cost; many software companies require additional payment for major upgrades.

2. Externally hosted licensed software

An externally hosted licensed software product will have essentially the same licensing terms. The only difference is that the contract will include payments for hosting of the software in an environment which the software provider is responsible for, and there will be certain guarantees of performance for the computing platform. These guarantees of computing platform performance will typically be in the form of a Service Level Agreement (SLA).

An SLA will include such criteria as “up-time” guarantees, e.g., 99.9% uptime. This means that the software system will be operational 999 out of every 1000 hours—or only 1 hour of “down-time” (when the system is unable to function) in 71 days if the service operates 14 hours per day. SLAs may also include criteria for response times for users and the average and maximum times for scheduling customer bookings for a demand responsive service. One of the major advantages of using a hosted version of the software are these SLAs, which provides the agency with a contractual assurance that the reliability and performance of the software will be adequate for its needs.

3. Software as a Service (SaaS) arrangement

In a SaaS arrangement, the agency does not actually acquire a licensed version of the software, as in the other 2 models. Instead, it pays for the right to use a hosted version of the software for a specific period of time, typically a minimum of 12 months.

The actual software itself will usually be essentially the same as a licensed product. In essence, the agency is “renting” the ability to use the software for the duration of the SaaS arrangement.

The advantages for the agency in this model are two-fold. First, the computing platform is provided by a third party via an arrangement with the software vendor. Typically, this will be a cloud-based platform provided by large organizations such as Amazon Web Services or Google Cloud which provide high quality, very reliable computing environments.

Second, the agency will automatically receive updates and upgrades to the software whenever the software company improves its product, which tends to be relatively frequent for typical SaaS arrangements. There is no support and maintenance agreement necessary, as all customers use the same, most recent version of the software.

While all SaaS customers of a specific software application use the same software, each has the software configured to their specific needs and circumstances in the cloud-hosted computing environment. Each customer typically has a separate instance of the software application operating in the cloud environment, although sometimes certain computing infrastructure will be shared even as each customer’s data is maintained separately.

SaaS vs. Traditional Models of Software Ownership: What to Consider

The SaaS approach has transformed how software is provided to customers in all industries over the past several years. Most contemporary software applications are now designed to be delivered via the SaaS model. For small transit agencies with broadband Internet access, there are few if any significant non-financial disadvantages to the SaaS model. Moreover, a SaaS approach provides at least 3 significant advantages to an agency.

1. The agency can change software vendors— and applications—with minimal complications if it is not satisfied with the performance of the software that it is using.
2. The agency avoids the direct equipment (hardware) costs and staff/technical responsibilities required to host the software.
3. The agency gets software support and automatic upgrades without doing anything.

At the same time, it is important for small transit agencies to recognize that the “lifetime” costs of software purchased via the SaaS approach may be somewhat greater than the licensed product approach, as illustrated by the following hypothetical—albeit realistic—comparison.

Software Functional Types for Small Transit Systems

Small city/rural/tribal transit systems provide different types of transportation services, but all include 5 common elements:

1. vehicles;
2. drivers;
3. customers;
4. a specific service modality (e.g., fixed route service, demand responsive service) is used to organize the operation of the service, with the understanding that small agencies frequently provide both fixed route and demand responsive service;
5. data is generated by the operation of the service, and the performance of the service can be understood by means of the analysis of this data and reports produced from such analysis.

The software needed by a small transit agency will ideally encompass each of the above areas. It is not necessary for a single product to include all of the important functionality. For example, vehicle maintenance software applicable to many different types of vehicle fleets is widely available and can be obtained separately from software that is specific to an agency’s service delivery system.

Two other types of software have become increasingly important during the past decade, and for some agencies they may also be considered as essential for their core needs.

Software for Fixed Route Transit Operations

A fundamental need of small transit agencies which operate fixed route services is for software that monitors real-time vehicle operations. A common name for this software is CAD/AVL—the acronym stands for Computer Assisted Dispatch/Automatic Vehicle Location. Such software, which requires a GPS-enabled device in each vehicle with wireless connectivity that enables it to transmit its location frequently (e.g., every 15 seconds), is able to track the location of all vehicles in service and make this information available—via a user-interface, which may be map-based—to both the operations staff of the agency and the public. For the operations staff, the software application informs them whether the vehicle is adhering to its schedule or not; it may also make predictions of when the vehicle will arrive at downstream locations on its route.

Small transit agencies may wish to purchase both the operational software and the customer facing software together. If they are purchased separately, the CAD/AVL system should be purchased initially, and then the customer facing application can be procured, with one of the requirements being that the software selected must be able to be integrate the locational data feed.

Other fixed route transit software that may be needed by a small agency will be that which generates GTFS data for its operations—including its schedules—and creates a data package that can be utilized by Google Maps and other third party applications for trip planning purposes. Such capabilities can also be purchased as a service from a few technology companies. The availability of transit trip planning can be very valuable for local residents and visitors who want to know what their transit options are for a specific trip and how to travel from point A to point B on the bus.

Small fixed route operators may also need some type of software for driver management (including generating driver schedules) and vehicle maintenance, but as noted previously this could be as simple as an Excel application developed by a knowledgeable staff member. Both driver management and vehicle maintenance software are also relevant for DRT services, and are discussed following the section below on DRT software.

Software for Demand Responsive Transit (DRT) Services

Small transit agencies that provide DRT services require a more comprehensive software application than for fixed route operations. This is because a DRT operation includes customer booking of trips, scheduling and dispatching of vehicles with at least some real-time elements, and increasingly an application used by the driver that directs his/her activities. In addition, the DRT software application will include an administrative component that encompasses service configuration settings, driver schedules, and vehicle management.

During the past few years the functionality and sophistication of DRT software has improved substantially, in important part due to the entrance of a number of recently established technology companies into this market with more advanced products. This has stimulated competitive responses by the established software companies. Many DRT software packages now include self-service trip booking by customers via a web-based application or smartphone-based app. Fully automated scheduling and minimization of manual dispatching is another hallmark of the newer software applications.

A contemporary DRT software system will include the following functionality:

• Customer information and registration (can be self-driven)
• Trip booking—by agents at a minimum, and self-service if appropriate
• Trip scheduling, consisting of the automated scheduling of passenger trip requests onto specific vehicles with estimated arrival times at each pickup and drop-off location, and the routing of vehicles from one stop location to the next.
• Vehicle dispatching, including the transmission to the driver application (explained next) of each pickup and drop-off location in driving sequence as well as the identity of the individual(s) being processed at each such location.
• Driver application, which encompasses driver manifest management, display of routing information (usually map-based) to help the driver navigate from stop to stop, recording of passenger arrivals and departures on the vehicle, and registering of fares collected including the type of fare.
• Administrative module, which includes functionality for the agency staff to be able to manage the service configuration and day to day operations:
  • Service configuration—service zone boundaries, operating hours, type of DRT operation (specific address to specific address, fixed and virtual checkpoints, sub-zones, locations visited on a scheduled basis, etc.)
  • Operational schedules—starting times and ending times for the service zone by day of week, exclusion of days as appropriate
  • Driver management—driver schedules and information about drivers’ qualifications for different types of vehicles if relevant to the operation
  • Vehicle management—including vehicle deployment schedules, vehicle capacity, and vehicle characteristics (such as wheelchair lifts)
  • Data management and data reporting, including management reports

Software for Vehicle Fleet Maintenance/Asset Management

An agency’s vehicles are its core physical asset— without vehicles, there is no transportation service. Vehicles have certain key characteristics— manufacturer, model year, engine type (gasoline, diesel, electric), number of seats, equipment to handle wheelchairs, etc.—and a finite life span that is primarily dependent on how much they are driven. Vehicles require periodic maintenance to renew and replace parts and fluids they use.

Vehicle fleet maintenance software enables a transportation operator to record and track information on each of the vehicles in its fleet, including the specific equipment that is installed on each vehicle and when maintenance and other key events—such as renewing vehicle registration—are scheduled to occur. Software can be quite detailed, including functionality to record when certain parts are replaced, manufacturer and part number of the replacement part, and how much it cost.

Agencies have 3 options for vehicle fleet maintenance/asset management software:

1. purchase a stand alone fleet maintenance product (SaaS options are now available);
2. purchase a fleet maintenance module that is included with a fixed route or DRT software product;
3. use a tool such as Excel to manage the basic fleet maintenance data for its vehicles. There is a very robust ecosystem of software companies that provide fleet maintenance software, some of which is very appropriate for the needs of small transit operators and is not expensive. At the same time, if a DRT or fixed route product that is of interest to the agency has a fleet maintenance module that is competitively priced with the stand alone fleet maintenance software option, there can be advantages to using a single product.

Software for Driver Management

Driver management software encompasses functionality for both recording and displaying information on drivers and their key attributes, most notably their training and qualifications for driving certain types of vehicles and handling different types of clients (riders), and driver scheduling. It is not uncommon for basic driver management functionality to be included with DRT and fixed route software, although this does not usually include the ability to automatically generate optimized weekly driver schedules meeting specified criteria. Many small agencies manage their driver schedules and information about their drivers in Excel. As with vehicle maintenance software, there are advantages to having driver management integrated into the core software product used by an agency but it is not essential. Using Excel for such purposes is a reasonable alternative for agencies with fewer than 20-25 drivers.

Software for Fare Payments including Mobile Payments and Ticketing

In the past few years, several software companies have developed fare payment systems that enable passengers to pay public transit fares via mobile phones. As smartphone penetration now approaches 85% of the adult population, it is clear that most transit users are able to pay for a transit ride via a mobile device if this option is available. In addition, some mobile ticketing approaches merely require a basic mobile phone, not a smartphone.

The subject of mobile payments and ticketing is sufficiently broad and complex that it is beyond the scope of this Guidebook. Nonetheless, it is important for small transit agencies to carefully assess their fare payment situation when they are considering acquiring new software—if they have not done so as a separate priority. Particularly if they are acquiring new DRT software, there are mobile payment solutions that are readily integrated with such software and it may make sense for an agency to move to a new fare payment system at the same time.

Software for Trip Planning

Another major recent development in software for transit services has been the advent of trip planning software, often based on a software platform named Open Trip Planner (OTP). OTP itself is open source software, and commercial products have extended its functionality. The purpose of trip planning software is to provide the trip maker with the ability to use their computer and/or smartphone to pre-plan a trip that involves using public transit. Google Maps provides basic transit trip planning capabilities for fixed route transit if a transit agency has made its GTFS data available. Trip planning applications that are optimized specifically for public transit include more extensive and in-depth capabilities. Examples include trip planners from companies such as Transit (Transit App) and Moovit, which are now available to the public at no cost in many larger cities.

Small transit agencies do not necessarily need their own software to take advantage of trip planning functionality. With the appropriate GTFS data provided by the local agency, Google Maps will automatically include public transit options in the trip plans it generates for its users, even in small cities.

At the same time, if a small transit agency wants to tailor trip planning for its own purposes, it will need to identify a commercial or open source software application that it can use. Particularly for agencies which operate both fixed route and DRT services, trip planning software offers the potential of making services more easily discoverable by local residents with information more tailored to their specific trips. Moreover, OTP-based trip planning software is now able to make trip makers aware of the presence of DRT services via the GTFS-Flex extension of the GTFS data standard. This makes possible the integration of trips plans with DRT software, creating the ability for a customer to plan a trip and then—if the trip involves using DRT in any way—book the DRT component via the same user application (assuming the DRT software is in fact integrated with the trip planner software).

For most agencies, orchestrating the implementation of an integration of trip planning software with its DRT or consumer-facing fixed route software is likely to be beyond their capabilities, but the software companies themselves are moving in this direction.

Even before the end of 2021, it is possible that such integrated software products will be available to small transit agencies. As they do become more widely available, they will represent another type of core software for small agencies.

Inter-Operable Software Considerations: A Short Discourse

Some small transit systems not only provide transit service but also function as Mobility Managers for a variety of transportation services—not just their own—in their service area. Such services can include those provided by human service transportation (HST) organizations, those funded by Medicaid (and delivered by service providers via Medicaid transportation brokers), and various other local services, including those relying on volunteer drivers.

In order for Mobility Management programs to be able to function as efficiently and cost-effectively as possible, the software systems used to manage the different transportation services—with are mostly or exclusively demand responsive in nature—need to be able to inter-operate, at least at a basic level. Currently, this is only rarely the situation—inter- operability is a desired state, not an actuality.

As discussed in Chapter 1, inter-operability between software systems requires other software—typically in the form of Application Programming Interfaces (APIs)—that enables them to not only share data, but to do so for specific functional purposes. For example, one DRT system—call it System A— may wish to transmit a trip order to another DRT system—call in System B—and if the latter system has an API it can do so in a standard way. However, System A must communicate with System B using the language of the latter’s API—call it API B— and is restricted to using the functionality made available via API B. This will require new software development for System A. Even if System A has its own API—call it API A—that will not be sufficient for it to inter-operate with API B, as API A has its own functionality and language syntax which is highly unlikely to be the same as API B. The situation is shown below.

The situation described is actually a best case scenario in the sense that both software systems already have the capability to inter-operate with other systems. But actual two-way communication between System A and System B can only occur after both have developed additional software capabilities to use the command set and data syntax and data requirements of the other’s API—only then will it be possible to send trip orders and data messages back and forth. Moreover, if System A wants to perform some functional action which System B’s API does not support—such as updating a previously transmitted trip—then yet more software development will be needed by one or both parties to make such functionality feasible.

As this discussion illustrates, achieving inter- operability between software systems is not a simple matter, even when all parties are committed to this outcome. Resources and time will be required if the relevant software systems are not already inter- operable with each other. The current reality is that there is very little “off the shelf” inter-operability among the software systems used by small transit agencies, particularly for DRT systems. For fixed route software, inter-operability is less complex, such as a map-based interface to show the location of vehicles on routes and their schedule adherence— where the data is sourced from the CAD/AVL software of one company even as the map-based interface is the software of another company.

Given that inter-operability is a very important objective for some small agencies—particularly those providing DRT services—who participate in Mobility Management systems, what can such agencies do when they are purchasing software to advance their systems towards this objective? One answer is to select a product from a software company that has already made clear by its actions that inter- operability is important.

In particular, if the software product has an API— even though that does not ensure inter-operability with another software vendor’s product—it is evidence that inter-operability is a priority. It is also an indicator that the company uses contemporary software approaches, which is a pre-requisite for technically efficient inter-operability with other software platforms. In addition, if a software company is able to document that it has actually achieved some level of data integration with the software product of another company, that is further evidence of its commitment to inter-operable software.

In view of the currently fragmented nature of software solutions for small transit systems, and the absence of any data standards to facilitate inter- operability among such software, inter-operable software is likely to remain an aspiration rather than a reality for at least the next 12 to 24 months.

Software Requirements, Functions, and Features

Before a small transit agency initiates the process of searching for, and eventually acquiring, a new software system, it must determine the essential capabilities of the software. The prior section has briefly described the different types of software applications that are relevant for small agencies. Knowing what type of software it needs, the agency then must determine what its core requirements are for that specific type of software.

The IEEE Standard Glossary of Software Engineering Terminology defines a requirement as

A condition or capability needed by a user to solve a problem or achieve an objective.

• Features and functions of the software are the means by which requirements are met.
• Features are the “tools” you use within a system to complete a set of tasks or actions.
• Functionality is how those features actually work to provide you with a desired outcome.
• Functional requirements define the basic software system behavior. Essentially, they are what the system does or must not do. An example is shown below.

It is the agency’s task to document each of the important functional requirements for the software they intend to acquire. In addition, the agency should identify and document all features which are important to it. For example, if the software should be able to show the current location of all vehicles in service on a map, and for each vehicle provide a list of passengers currently on board, this feature must be specified as required by the agency.

All of the important requirements, features, and functions must be documented and included in the RFP document. Collectively they represent the target for the software that the agency intends to acquire.

Software “Ownership” Requirements

As every organization which uses software to assist in the performance of its core functions is aware, the activities associated with acquiring, implementing and using such software impose significant resource commitments over and above the direct cost of the software application. Small transit agencies, who are typically resource constrained, need to carefully assess their situation vis-à-vis these software ownership requirements as they embark on the process of acquiring new software to manage their services and operations.

It bears emphasizing that the activities and resource commitments discussed below occur after the decision has been made to acquire a specific software application. However, these factors should be considered prior to initiating the software acquisition process.

In particular, the agency needs to consider how these factors are likely to be impacted by the different software products under consideration—the impacts are unlikely to be identical. In particular, there is a significant difference between a SaaS product and a licensed software product for some of these factors. Achieving clarity about the agency’s capabilities and situation will be important in determining which of those options is more appropriate.

The following major activities/resource commitments are key elements of software “ownership” after an agency has purchased a software application:

• Software system implementation—including the computing infrastructure if necessary.
• Software system configuration
• Staff training—both internal staff and any affiliated organizations.
• Staff time necessary to learn how to use the software at a high level of competency, including using it to monitor and improve operational performance.
• Handling new versions and upgrades of the software.

Software System Implementation

New software systems don’t just happen. An agency acquires a new software application and then must implement it for its own purposes. If it has decided to use a SaaS software solution, implementation will be simpler and less burdensome than if it has purchased a licensed software product that will be installed on its own computing infrastructure.

In the latter case, the agency must determine its specific hardware and networking requirements, obtain and install the hardware (unless they already own the necessary hardware), install the actual software, and then ensure that the infrastructure works properly by testing the system. Technical resources are needed for at least some of these activities. The software vendor may be able to provide some of these resources; local information technology firms are another possible source of such resources, and some agencies may have staff with competency for at least some of the necessary tasks.

In some cases, software vendors will arrange for the hosting of the system and this option is comparable to a SaaS approach in terms of relieving the agency of the responsibility for the details of implementation.

For agencies which do not have easy access to the resources needed to implement the necessary computing infrastructure, the SaaS option or third party hosting of a licensed product are likely to result in a better outcome.

Software System Configuration

Software applications must be configured and “localized” to an agency’s specific circumstances. For a demand responsive service, this includes such factors as defining the service area boundaries and operating hours, setting scheduling parameters, determining the level of service (e.g., maximum wait time and ride time) for passengers, and setting up existing customers in the system. For fixed route services, data on routes and stops and timetables must be entered in the software, as well as driver schedules and information on vehicles. Since these data are known only to the agency, its staff will need to be heavily involved in implementation even in cases where the software vendor plays a significant role in system configuration.

Staff Training

Training the agency’s staff in how to use a new software product usually begins a few weeks (sometimes as few as 1 to 2 weeks) prior to the agency actually using the software for production operations. Most software companies provide competent training to their customers, and a vendor- taught training class will almost always be part of the package of services that are included in a software purchase (as discussed in “Topic 8: Software Application Procurement”).

If other organizations in addition to the agency need to use the software for certain purposes—such as entering trip requests or looking up scheduled rides—they will also need to be trained in how to use their specific functions. They can be included in the vendor-taught training class, but the agency will ultimately be responsible for ensuring that external organizations can properly use software functions that they have been given access to.

If the software system is something totally new to the agency—as opposed to replacing an older software package with similar functionality—there is likely to be a significant learning curve for the staff members who are using the software. In such situations, the vendor-led training will only be the beginning of the process of the agency learning how to use the software to its—and its customers’—best advantage. The level of effort needed for the staff to handle the basic features of a new software system is easily under-estimated.

Achieving Staff Competency in Use of the Software

As implied by the above discussion, it can be challenging for an agency’s staff to achieve true competency in the use of a software application. But if the agency only has basic competency, many useful capabilities of the software may not be able to be used, and the agency is not able to take full advantage of its financial investment. This is particularly the case with different configuration options in the software which, through proper use, may enable the agency to achieve improved operational efficiencies or performance. In addition, data management and analysis made possible by the software may be able to help the agency understand how to operate their services more efficiently and effectively, but the software system must be well-understood by the staff for such outcomes to even be possible. Agencies often do not take full advantage of the capabilities of their software, and intelligent software ownership will avoid such outcomes.

Handling New Versions and Upgrades of the Software

It is important that the agency be able to quickly move to a new version of the software when one is released by the software provider. A new version will include defect fixes as well or new or modified features and functions that have been included in the software in response to the requests of customers. If the software is a SaaS product, the customer will typically have no choice about using a new version, although the changes in SaaS products are typically incremental; licensed software products are more likely to have major new versions. In either case, an important part of the ownership of a software application is to be able to handle new versions of the software.  The starting requirement for that is for the agency’s staff to be highly competent with the current version.

Software Affordability

What does it mean when we say that a software system is “affordable”—or is not? This is an important question for every small transit agency contemplating buying new software or replacing the software it now uses with that purchased from another software provider. Small agencies are almost always resource constrained, and purchasing an expensive—relative to limited available funds—product immediately raises the question “can we really afford this software?”

The question of affordability has 2 dimensions:

For example, consider a new DRT software system that includes a web booking application and/or smartphone app that enables customers to reserve and schedule their trips without calling the agency, and which also includes sophisticated automated scheduling and dispatching that substantially reduces the need for a human dispatcher to manually schedule and dispatch trips. This combination of functionality might reduce the staffing requirements for the DRT operation by 0.5 FTE, resulting in significant cost savings. On the other hand, acquiring a software system that requires local computing infrastructure might require an agency to obtain technical services from a local information technology firm via a support contract. The cost of the service contract would be part of the net out of pocket cost of the new software.

After an agency has developed an estimate of its net out of pocket cost for the software, it is better able to evaluate the affordability of the software. Two examples are presented below for the acquisition of a DRT software system, one involving the purchase of a licensed software product and the other a SaaS product.

In both cases, the DRT application enables customers to make their own trip bookings, and includes fully automated scheduling and dispatching. These features make it possible for the agency to reduce its staffing for the DRT operation by 0.5 FTE, which equates to $18,000 in annual labor savings.

Over a 5-year period, this totals $90,000 in reduced out of pocket costs.

As the two examples show, in both cases the net out of pocket cost of the software system is relatively low, which is attributable to the operating cost savings it makes possible. The two software options have relatively comparable annual net costs over a 5-year period, although the software acquisition costs used in this analysis are merely representative, and not indicative of what can be expected in any specific situation.

Is this software affordable? Given that its net cost per year is less than $7,000 in either case, one can make a strong argument that it is affordable.

Aother useful measure of affordability is the cost per annual passenger trip. If this DRT service was handling 120 trips per weekday (about 36,000 trips per year), the software cost would be no more than $.18 per trip irrespective of the type of the software. Even if there were no operating cost savings associated with the software, the net cost of the software system would be less than $.70 per trip. Given that the total operating cost for a small DRT service is likely to be at least $10-12 per trip, a technology related cost representing 6-7% or less of the operating cost would seem to be relatively affordable. A general rule of thumb is that the technology should not cost more than 10% of the total operating cost of a DRT service. For fixed route services, technology costs will typically be significantly less.

Software Application Procurement

Transit agencies typically procure new or replacement software via a formalized procurement process. In most cases, as public organizations—or organizations using public funds—this procurement process must adhere to certain legal requirements which will be specified in state or local laws or regulations. It is not uncommon for certain legal requirements to only apply for purchases of more than a certain amount, such as $2,500. However, in virtually every case, there are laws and regulations that will affect how an agency conducts a procurement. In the following discussion, it is assumed that the software procurement will be conducted on the basis of formal proposals, including price proposals, from all organizations seeking to sell their software system to the transit agency. The actual publication of a request for proposals (RFP) is one of the final steps in the software procurement process.

Leveraging the base of information provided in the first part of Chapter 3, through the eight topics, consider what actions your agency can take to move forward with a software product. A series of seven steps is provided to walk you through the process, as shown below.

Step 3a. Determine What Type of Software Your Agency Needs

As discussed previously, there are several types of software which could be relevant to a small transit agency (fixed route, DRT, integrated trip planning, etc.). Occasionally an agency may wish to obtain multiple types of software in a single procurement, such as integrated trip planning and DRT software or DRT software and mobile fare payments. This will potentially be more complex than procuring a single type of software. If the agency has limited experience in software procurement, it may be more prudent to conduct separate procurement processes. On the other hand, if the two types of software are known to work effectively together in other settings, the risk is significantly reduced.

Step 3b. Understand Your Available Software Choices

For core software products for DRT or fixed route service management, the number of choices available from commercial software companies is not huge, typically no more than 10 or 12 products (less for fixed route). Agencies can quickly educate themselves about the available products by talking to their peers and other informed organizations—their state DOT, industry associations such as CTAA, the Rural Transit Assistance Program (which is funded by FTA), etc. The latter organizations are unlikely to recommend specific products, but they are generally knowledgeable about the software vendors and their products and can often provide referrals to knowledgeable agencies who are using specific software systems.

Attending a state, regional, or national conference with a focus on small city/rural/tribal transit service is another avenue to obtain information, as many software vendors are likely to be participating in the trade shows that are a normal part of such events. Such conferences are also an ideal forum in which to meet peers who can discuss their experiences with different software systems.

From these multiple resources, the agency can assemble a list of the software companies and their products that seem to be a good fit for its specific needs.

Step 3c. Determine Whether to Obtain a SaaS System or a Licensed Software Product

This is a very important step in the procurement process. The strong trend towards SaaS solutions in the larger software market is much more than a fad, it reflects multiple well-considered business reasons for obtaining software in this manner. Of particular importance, SaaS solutions largely eliminate concerns about the computing platform itself, normally a significant burden for a small transit agency.

If an agency perceives that its best available software choices are licensed products, it should then strongly consider procuring a package of software and computing platform hosting, or at least make this an option in the procurement. SaaS and hosted software solutions should only be excluded when broadband data connectivity is not available to the agency.

Step 3d. Determine Your Core Requirements for the Software

As discussed in “Software Requirements, Functions, and Features,” the core requirements for the software define what the agency expects it to do. What features and functions do they need to operate their service? Do they need a fully automated scheduling system if they are providing DRT service, or can some mixture of automated and manual scheduling better fit their needs? What administrative functionality is needed in the software? Is an application for drivers part of the system, or does the software only need to include functionality for customers and the agency staff? Does the software system need to provide customers with the ability to directly interact with the software, at least for certain purposes? Does the software need to handle vehicle maintenance and/or the work schedules of drivers? Should the software for the agency staff be web- based, or can it be an application that is resident on a desktop computer or uses a technology such as Citrix to simulate desktop operations?

Relative to the capacity of the software, is the number of concurrent users likely to be a concern? If so, how many concurrent users need to be supported? (If the software is a SaaS application, this is not usually a concern.) Is a SaaS solution desired? If a licensed product is the preference of the agency, should the software be hosted on the customer’s premises or should it be hosted in the cloud by a third party (or the software vendor)?

Determining core requirements is an extremely important step in the process, as the decisions made in this step will shape in a decisive way the contents of the Request for Proposals (RFP) document.

Step 3e. Develop the Request for Proposals

This is often the most challenging element of the software procurement process for small transit agencies, as most have little or no experience in actually creating a Request for Proposals (RFP) document. Consequently, most agencies lack knowledge and/or confidence in how to accomplish this. However, there are several alternatives to developing an RFP solely with an agency’s own resources.

For example, there is almost always a question and answer phase to the RFP process, but if the consultant’s role does not include this phase it is possible that the agency staff will have great difficulty answering the technical questions—even relatively simple questions—from the software companies interested in submitting proposals. Similarly, if the consultant is not available to assist the agency staff in evaluating the proposals, the agency staff may be out of its depth technically in assessing the relative advantages and disadvantages of different software company proposals.

Irrespective of who is responsible for the actual development of the RFP document, the content of that document represents a significant piece of work and needs to include the following:

1. The RFP must define the desired new software system at a significant level of detail, often including a set of relatively precise specifications for the features and functionality of the software which the agency wants.
2. The RFP must provide clear instructions and guidance to the proposers about how to describe their software solutions, and what will be their scope of work for implementing the software for the agency.
3. The RFP must include a structure for the pricing proposal which includes all of the different costs that are associated with making the software operational for the agency and that ensures a fair comparison of different software products.
4. A proposal evaluation and scoring framework must be created that includes considerations of product functionality, ease of use, the degree to which the product fits with the agency’s service delivery approach, and the experience of other agencies with the software product and the software company—as well as the total price of the system.

Step 3f. Evaluate the Proposals and Select the Most Appropriate Software Product

The final step in the RFP process is for the agency’s evaluation team to review the proposals and provide a score for each one. This necessitates a careful reading and review of each proposal, with each reviewer typically evaluating the proposal on multiple criteria that were set forth in the RFP document. After summarizing the scores from each of the evaluators, the proposals can be ranked. Sometimes there is strong consensus at this stage that one proposal is clearly superior to the others, and there is no need to interview the proposers or to have them make presentations about their proposal. More typically, the evaluation team will want to have in-depth presentations by the highest scoring candidates. It is typical to have such presentations, which often include product demonstrations, from the 3 top scoring candidates. After the presentations, there is typically another tallying of the scores as the presentation itself will usually be evaluated.

At this point, one company will have the highest score. Some agencies then request the highest ranked proposer to provide them with a Best and Final Offer—a BAFO. The purpose of the BAFO is typically to try to get the highest rated company to reduce its price by at least a modest amount from that which it bid in its proposal. The BAFO phase is totally optional and many agencies do not include this in their evaluation process. Whether a BAFO phase is included or not, at this stage in the process a tentative winner has been determined. Negotiations over the final price could still occur, but the software selection process is essentially completed.

Step 3g. Begin the Software Implementation Process

Once the preferred software provider has been selected and a contract signed, the software implementation process begins. The software company will need to set up the software in either the customer’s computing environment or in the hosting environment. It will then engage in a variety of activities to make the software operational and configure it for the agency’s specific circumstances. This may also necessitate significant involvement of agency staff.

Following the installation of the software, the next major activity in the implementation process is to train those staff members responsible for using the software in how it works. After the initial training session(s), the staff members will typically continue their learning activities in a less formalized fashion, as achieving true competency in a large software application can require a substantial amount of “hands on” effort.