Digital Tools to Facilitate Complete Trip Planning Providing a Digital Tool for Complete Trip Planning

The Guidebook on New Software Adoption for Small Transit Agencies goes into significant detail in Chapter 2 / Step 2: “Collaborate with the Software Stakeholders” on how to identify all the relevant stakeholders (including end users) for a project, ways to actively involve them, and how to incorporate their feedback into decision-making processes. Chapter 1 of the Guidebook also mentions the need for a “software adoption lead” to help spearhead the effort; this person could also be referred to as a project manager. “The lead does not need to come from a software development or information technology background. The most important skill sets and knowledge the lead should have include transit operations knowledge, software benefits awareness, and organizational skills.” Early on  to provide digital tools for complete trip planning, the full range of stakeholders, including the transit and mobility system users, should be identified; the person supporting the project management of the entire effort should also be clarified. Once this is complete, the effort will have its project team in place.

First, draft customized “journey diagrams” for the local area.

To understand the types of challenges and gaps that people face when using digital tools for the Complete Trip, the project team should prepare to draft all the known and potential end-to-end journeys in the area as illustrated in Section 1.2. The mapping out of the journeys should have the input of the entire stakeholder group, including the transit and mobility system users, to ensure the set of end-to-end journeys is complete.

This input could be gained through both general public events and by holding smaller gatherings with representatives of specific user groups. Many transit agencies have advisory boards or committees, for example, some involving individuals with disabilities and older adults who provide feedback to the transit agency on an ongoing basis. The input of such groups could be sought to help create the journey diagrams. If a long list of journeys ends up being generated and is considered too unwieldy for discussion, 5-10 common journey types could be selected.

Then, identify digital challenges encountered during specific journeys.

Once the set of end-to-end journeys has been drafted and is considered complete by those involved, the project team and the user groups, the challenges can be identified through discussions and work sessions. It may also be worth considering online feedback options as shown through the “complete street upgrades” project in Westfield, Massachusetts. Each identified challenge should be located on a specific end-to-end journey and with the journey segments to which it applies. To better connect the Complete Trip segments with digital tools that are commonly used during each segment.

Again, the input would ideally be gained through both public events and by holding smaller gatherings with representatives of specific user groups. Some of the highlighted projects in this Guidebook provide examples of types of digital challenges to look out for such as:

• For multi/intermodal trips during trip planning: Trip planners missing entire modes such as demand-response transit, which leads to a fundamental lack of information on transit and mobility options.
• For demand-response transit trips during trip planning/booking: Customer difficulty in booking trips across multiple demand-response transit providers (without contacting each one separately), causing confusion about which one to contact first and what to do when a trip request is denied.
• For transit, cycling, and pedestrian trips during trip planning: Digital gaps in information about physical barriers impacting the feasibility of trips. These physical barriers could include inadequate bus stop conditions, missing bike lanes, or dangerous sidewalk conditions, for example.

Once a complete list of challenges has been generated, the challenges should be compared against each other as ”High”, ”Medium”, or ”Low” impact. While some challenges will have major impacts—presenting significant digital barriers—others will have relatively minor impacts. Making these assessments will be a subjective process involving the project team and user groups. For instance, in Substep 1b, “trip planners missing entire modes” will likely be seen as a High impact challenge. Another challenge example, “customer difficulty in booking trips across multiple demand-response transit providers” may be characterized as Medium or Low impact. It is frustrating for users, but overall may present less impact when compared to the other challenges in question.  For this step, there are no right or wrong answers; the project team and user groups can discuss and debate these topics—using analytical tools for a more precise assessment as they see fit—eventually coming to agreement on how to characterize the challenges.

Once the challenges are confirmed, considerations can move toward identifying various tactics with the project team and the users providing input. Tactics are activities that could be undertaken to help address challenges, often focused on providing a specific tool or taking on a new initiative. For one challenge mentioned under Substep 1b, “trip planners missing entire modes,” different types of tactics could be proposed, for example. One tactic could be “make adaptations to the existing trip planner to enable all modes to be included.” Another tactic could be “provide a new trip planner that includes all modes.” For the challenge “digital gaps in information about physical barriers impacting the feasibility of trips,” tactics could be proposed such as “include barrier-related information within a new trip planner,” “adapt the existing trip planner to include barrier-related information,” or “setup a tool dedicated to providing barrier-related information, to be used along with a trip planner” as was done through the “bus stop accessibility map” project in Northwest Indiana. Tactics are highly context-dependent. Identifying them depends not only on the challenge they could help address, but also on the existing situation surrounding the potential tactic—the projects and initiatives that are, or are not, already in place that could help  or hinder it.

There are various factors that can impact the level of effort of a tactic, making it much easier or more difficult to accomplish. For instance, for the potential tactics that should address the challenge “trip planners missing entire modes” which are “make adaptations to the existing trip planner to enable all modes to be included” and “provide a new trip planner that includes all modes,” more than likely both tactics would involve using GTFS-flex feeds in a trip planner, so that demand-response transit options (one of the missing modes) could be shown in the trip planner. If GTFS-flex feeds had already been created, then both/either of the tactics may involve less effort. If the GTFS-flex feeds had not been created, but one of the organizations on the project team offers one of their staff members to create the GTFS-flex feed, that would likely be easier than, for instance, going through the process of locating funding and procuring a tool/consulting services to create the data. Each situation regarding the status of getting GTFS-flex feeds ready presents information that makes the related tactic more or less effortless.

For this example, the GTFS-flex feeds are not the only input into the tactic. Another input to consider involves the status of the existing trip planner (if one exists); can it be adapted to add demand-response options, or would the difficulty of doing so contribute to considering another trip planner altogether? Is there even an existing product on the market than can include demand-response options, or would pursuing this tactic require the project team to create  a custom software solution?

While the Guidebook Section 2.2 provides information on core topics pertinent to assessing the level of effort, a few more core topics are provided below:

·      Considering existing software vs. creating new software

·      Leveraging available resources

·      Using the project table in Guidebook Section 2.3 as a state of the practice summary

When considering existing software vs. creating new software, there are several factors to consider. In the Guidebook on New Software Adoption for Small Transit Agencies, Chapter 3 goes into detail on this topic, “Small transit agencies today have a choice among multiple types of software products that address the same functional needs of the agency. These include commercial off the shelf (COTS) products, open source/public domain software, and custom software solutions. The advantages and disadvantages of each is discussed in this chapter.” In general, COTS products will be easier to set up, but they may potentially not have all the desired features and functions—and often, this cannot be changed. Custom software solutions typically require a very high level of effort to ensure that software consultants deliver a product that meets what the project team and end users have in mind. The “awesome-transit” list references a “community-maintained list” of “Entities Providing Transportation Software Development Consulting Services” (with an option to add new vendors).

Custom software solutions often need be hosted through a solution provided by the organization that is managing it, but COTS products are increasingly provided as Software as a Service (SaaS) projects. In short, there are several factors to consider related to how software options can influence the level of effort of a tactic. Explained in the Guidebook on New Software Adoption for Small Transit Agencies:

During the past decade, there has been a strong trend in business software in the direction of Software as a Service (SaaS) approaches. Among multiple advantages of a SaaS purchase, a major advantage for a small transit agency is that it does not have to concern itself with the computing infrastructure on which the software is hosted. This chapter discusses the relative merits of SaaS approaches compared to licensed software products that are hosted by the agency itself or for which the agency is directly responsible. For small transit agencies, software solutions that avoid the agency needing to be responsible for their own computing infrastructure are typically advantageous, assuming that broadband data access is available.

In some cases, available resources from among the project team can be leveraged to support efforts to provide digital tools for Complete Trip planning. The Guidebook on New Software Adoption for Small Transit Agencies provides information on this topic in Chapter 1, Step 1c. Anticipate Resources to Apply to Software Adoption, “Resources relevant to the software adoption process include (at a minimum) financial resources, staff resources, existing software and computing infrastructure assets, and collaborator resources—financial, staff resources, or assets from partner organizations. An agency should create an inventory of its likely available resources early to be prepared for later steps in the process.” Resources that could be particularly useful for complete trip-related efforts include existing data sets, software already in use that can be expanded, existing methods for centralizing data for multiple organizations, as well as in-kind financial and staff resources to help build and manage the work. If resources can be provided through a partner organization, instead of seeking out funding and going through a procurement process, then a tactic could become more feasible.

The Guidebook on New Software Adoption for Small Transit Agencies is a key reference for learning more about software options and the level of effort required for their success as well as how to pinpoint available resources from among the project team.

The project table in Guidebook Section 2.3 is also a key reference to better understand the potential effort level of tactics. Though not intended to be an exhaustive resource, the project table reflects the current state of the practice of digital tools for Complete Trip planning as of November 2021. When professionals are considering a certain tactic and are wondering if what they’d like to do has been done before, the project table could illuminate that question.

Once a complete list of tactics has been created, the tactics should be compared against each other as ”High”, ”Medium”, or ”Low” effort. While some tactics will be ”High” effort—representing a lot of work and effort—others will require relatively ”Low” effort. Making these assessments will be a subjective process involving the project team and user groups. For example, in Substep 2a, the tactic “include barrier-related information within a new trip planner” would likely be ”High” effort, but that would depend largely on if the trip planner already enables barrier-related information to be included (most do not), if data on barrier-related information already exists (it is difficult to collect), and what it would take to keep such datasets continually updated and accurate since barriers (e.g., deteriorating sidewalks and missing bike lanes) are constantly in flux. For this step, there are also no right or wrong answers; the project team and user groups can discuss and debate these topics—using analytical tools for a more precise assessment as they see fit—eventually coming to agreement on how to characterize the tactics.

First, plot the tactics according to the level of effort and impact.

To gain a basic understanding of how the tactics compare, professionals should plot them as shown in the example of Figure 32. On the x-axis, the placement of the dot represents the challenge it seeks to address. The further to the right, the more impactful the challenge. The most impactful challenge, for example, would present an extremely significant barrier. On the y-axis, the placement of the dot represents the effort the tactic requires. The further toward the top, the more effortful the tactic. If a tactic has the potential to address multiple challenges, and its impact varies, estimate the combined impact of the challenges to plot the tactic on the table. In some cases, it can be difficult to consider tactics on a stand-alone basis because the tactics have the potential to reinforce each other—doing one could lay the groundwork for the other, or by combining them they can achieve much more impact than the sum of both. In these cases, a line can be drawn between the dots to show their potential for reinforcement. Further, if together their impact would change, a “ghosted” single tactic could be shown to represent their combined impact (keeping the effort level on par with the highest of the two unless the combination leads to a higher effort level) as shown in the figure below (points 3, 4, and 3+4). Once the comparison table has been plotted, it can be used as a planning aid.

Then, add the tactics to the Complete Trip timeline. 

Using the comparison table, a tentative 10-year timeline can be drafted. As shown below, of the nine sections, only one is green and one is red. The others are orange. The green section would encompass all the tactics that are High impact and Low effort; in general, these tactics would make sense to implement. The red section would encompass all the tactics that are Low impact and High effort; in general, it would not make sense to implement these tactics. The interpretation of the remaining seven sections, in orange, is at the discretion of each project team. For example, some teams might find tactics that are in the middle of the table, those that are Medium impact and Medium effort, reasonable to pursue; other project teams may see this very differently. Tactics that are High impact and High effort may make sense to pursue, at least in the longer term, since they can address major barriers. Tactics that are Low impact, regardless of if their effort level is Low or Medium should be assessed individually to decide if they are worth pursuing—even low effort tactics can reduce the overall bandwidth to take on more impactful and important efforts.

Each tactic should be added to the timeline as shown in the example in Figure 33. Those in the green section would typically be placed in the early years of the timeline, while those in the red section would be removed. The tactics in the orange section can be placed on the timeline, relative to an estimate of when they could be completed; they can also be removed at the discretion of the project team. The timeline is a simple approximation of what should happen when—representing basic draft ideas. Notes can be included and lines can be drawn between the tactics to help add on additional layers of information the project team finds helpful.

After Substep 3a is complete, it is time for the project team to look at the big picture and consider the supportive infrastructure—the physical, service, and governance infrastructure—that will be needed not only for separate tactics but for the effort as a whole. Each infrastructure element should be added generally where it is likely needed within the overall time frame; for example, perhaps some elements should be up and running prior to a certain tactic being implemented. It is typical that an infrastructure element could support multiple tactics at once. If helpful, the tactic numbers can be noted beside the infrastructure elements to keep them connected.

First, establish the general direction of the first three years through exploratory questions.

Substeps 3a and 3b helped generate a rough idea of what the effort might include over the ten-year horizon. At this point in the planning process, a closer look is called for into the first three years. The draft generated during Substeps 3a and 3b should be used as a start, but the project team can look at this more closely for the near-term effort. To decide if the tactics and supportive infrastructure listed are what should be pursued, the project team should consider the following questions:

• What is the reinforcement potential for the tactics listed for the first 3 years? The reinforcement potential refers to the way the tactics build upon each other to have a more significant impact as a set rather than separately. If the reinforcement potential is Low, but that is true for most/all of the tactics, that means the tactics are largely stand-alone tactics. If the reinforcement potential is Low, but moving a few years out on the timeline starts to gain some traction, it may be worth detailing the tactics on a five-year basis instead of three years—that would still be in the near term while allowing for some benefits of combining the efforts. By the end of discussing and debating this question, the project team should have agreed to keep the tactics as shown or revise  them, including revising the time horizon as needed for the near term (around three to five years).
• Once the tactics have been agreed upon, are all the supportive infrastructure elements that are needed included in the draft for the agreed upon time horizon? If not, but the elements are included in the timeline at a later point in time, then they can slide over to an earlier time in the near term. If not, but the elements are not included in the draft at all, they should be added. At the end of this discussion, the project team should determine the supportive infrastructure elements that will be needed for the near term.

Then, establish the specifics for the first three years through a project management plan.

After the previous discussions have confirmed “what” will be done, the question becomes “how” will it be done? This will generally involve sorting through the issues of who to involve, the roles each organization/individual will have, what tasks and subtasks need to be completed, and when certain milestones should be met. The person supporting the project management role would help guide the project team in creating a project management plan, which could be created in excel or a software specifically designed for task and project management. If a procurement process is required, a set of procurement tasks would be included within the plan. More details on this can be found in N-CATT’s “Procurement Playbook.” Creating a realistic and well-detailed project management plan is a major task, and the project team may need to gather additional information to be able to compete it.

For background reading on “how to move forward with a software product” see chapter 3 of the Guidebook on New Software Adoption for Small Transit Agencies which includes a “series of 7 steps that need to be navigated from the time when the agency decides it wishes to acquire new software until the point when the software becomes operational for the agency, enabling them to move forward with a software product.” These steps include:

• Step 3a. Determine What Type of Software Your Agency Needs
• Step 3b. Understand Your Available Software Choices
• Step 3c. Determine Whether to Obtain a SaaS System or a Licensed Software Product
• Step 3d. Determine Your Core Requirements for the Software
• Step 3e. Develop the Request for Proposals
• Step 3f. Evaluate the Proposals and Select the Most Appropriate Software Product
• Step 3g. Begin the Software Implementation Process

For additional reading on how to “support the software,” see Chapter 4 of the same resource. The steps include:

• Step 4a. Plan for One-Time Software Setup and Training
• Step 4b. Prepare for Ongoing Support Needs
• Step 4c. Consider Additional Support as the Software Scope Expands

Once the roles, tasks, and milestones are clear for the time horizon (typically 3-5 years), implementation can begin.