New Software Adoption for Small Transit Agencies Chapter 2, Step 2: Collaborate with the Software Stakeholders

  • Date: February 18, 2022

A core aspect of software adoption involves working effectively with stakeholders. Far from an optional step, this aspect requires significant attention early in the adoption process. First, ways to identify which
stakeholders to include will be explained. Then, ways to actively involve them will be provided. Although the involvement of stakeholders is proposed to begin after Step 1, it is possible that a stakeholder group should be involved earlier—during Step 1. In fact, for situations mentioned in Step 1, when the software type is initially unknown, a more thorough stakeholder-related effort is suggested to take place during Step 1.

Identifying the full range of stakeholders is important for two reasons. First, it establishes a deeper understanding of who should be included in the decision-making and adoption process, increasing the likelihood that the needs of each group are met. This, in turn, helps the software adoption process to be more effective and run more smoothly. Second, it helps avoid the pitfalls that can occur when software decisions are made on behalf of software users without their direct involvement in the process.

Pitfalls that may happen in this case include a lack of use of the software by users or a premature commitment to a software that does not have all the required functionality—either of which may lead to a waste of funds and staff time.

Software stakeholders can generally be broken down into three categories:

Software stakeholders, Managers and Producers, Users, Influencers

1. Managers and procurers

The management of a software adoption process involves guiding its direction and ensuring it remains on track. As mentioned in Chapter 1, a staff member who is responsible for the entire software adoption process from start to finish should be identified. This person, the software adoption process lead, would be the primary manager of the effort. Similar to a project management role, the software adoption process lead would ensure that all the parts—the results from Step 1 through Step 4—connect.

Procurement involves selecting the software in accordance with the agency’s requirements, policies, and procedures. Staff involved on procurements tend to break into two types, dedicated procurement staff and subject matter expert(s). While the former ensures that the policies and procedures are adhered to, the latter helps draft the detailed content in procurement materials. The subject matter expert is not necessarily knowledgeable about the software itself, but about the work areas the software will support (e.g., on-demand transit service) and how it will be applied to meet the agency’s needs. It is likely that the main subject matter expert involved in the procurement will be the software adoption process lead. Sometimes procurers and managers are also the only direct users of the software, but other times they procure and manage the software on behalf of a larger user group.

2. Users

The software user groups encompass everyone who will interact with the software; they should be identified up- front to ensure later steps of the adoption process take the viewpoints of all users into account. For some types of software, the user groups include both members of the public and agency staff. For on-demand transit operations, for example, typical software components include an app for customers (i.e., public users), an app for vehicle operators, and a management console for operations staff. This diversity of software interactions leads to a more complex set of user groups. Each user group will have a different set of requirements based on their needs.

3. Influencers

Influencers are stakeholders that won’t directly use the software, nor will they be procurers or managers, but they will provide input into the process. For example, it is common in human services transportation to include the advice of groups that represent older adults, individuals with disabilities, and others with specific mobility considerations. Such groups might review the software options from an online accessibility standpoint or check that users can communicate specific types of information regarding accommodations through the booking process (e.g., inclusion of a travel companion).

Some software adoption efforts will have a simpler and shorter list of stakeholders. For example, some efforts will only have procurer and manager stakeholders, and they may also be the only users. For other efforts, all three categories may be involved, and the users may break down into several user groups—adding up to a more complex and longer list of stakeholders. As a general rule, the more complex the software, the more stakeholders will be involved—and the interests of the stakeholders will vary more widely.

Staff at small transit agencies are often wearing many hats and have little available time, so it is critical that the stakeholder involvement aspects of software adoption be handled in an efficient, yet effective, manner. To this end, three key activities are proposed.

Step 2a. Create a Stakeholder Map

As a first step, the stakeholders will be identified through a stakeholder map. The software adoption process lead might complete this step alone or with co-workers as a group brainstorming activity. A stakeholder map can be a list or a graphical sketch that identifies connections (e.g., cases where the “procurer/manager” stakeholders are the same as the “user” stakeholders). Points to consider to help identify the stakeholders for each stakeholder category are shown in the table on the following page.

Step 2 diagram: Collaborate with the Software Stakeholders

Stakeholder Category: Managers and Procurers

Points to Consider:

  • All organizations and known roles/individuals who will be taking part in the management or procurement of the software should be listed.
  • For management, this would include the software adoption process lead as well as others working on management aspects. For instance, there may be a broader management team involved in the effort, or there could be staff members who will support the software adoption process lead during certain steps due to their specific role or specialized knowledge.
  • For procurement, this would include dedicated procurement staff (i.e., those who ensure policies and procedures are adhered to) and subject matter experts (i.e., those who help draft the detailed content in procurement materials).

Stakeholder Category: Users

Points to Consider:

  • First, the user groups should be identified. The user groups will be different for each software type. For example, for trip planning and trip payment, a key user group would be the customers, members of the public who will use the app. Drilling down further, there could be more nuanced public user groups, such as individuals with disabilities or older adults—this depends entirely on the purpose of the software and the agency’s goals for its use.
  • For trip booking and scheduling, the user groups would align with the software components. Members of the public, as app users and customers, would be a key user group. Various staff members would also be users, since interacting with the software will become a part of their daily work. Typically, the vehicle operators would have an on-board app to help navigate routes, and service operations administrators would have software to assist them with set-up and configuration, reporting, and data analysis. This example is not exhaustive or standard and depends on specifics of the software platform that is needed.
  • It is common that the manager/procurer stakeholders will be users themselves, but it is not always the case—some software is managed or procured on behalf of users who are entirely different.
  • After all the user groups are listed, then the list can be further completed with organizations and known roles/individuals at the organizations.


Stakeholder Category: Influencers

Points to Consider:

  • Any organization with a role in the effort that has not already been listed should be added.
  • Typically, such an organization would be included because they will provide input into the process, but it is also possible that they have some other vested interest in the software adoption effort.

Step 2b. Identify Key Topics for Each Stakeholder Group

Each group will have a set of topics that pertain closely to their interests. Points to consider to help identify the key topics for each stakeholder category are shown in the table below.

Stakeholder Category: Managers and Procurers

Points to Consider:

  • Initial topics for managers and procurers relate to the software scope as covered in step 1, including the purpose of the software/software type(s), software connectivity needs, and a resource summary (i.e., available resources, required resources, and resource gaps) for the software adoption effort.
  •  They would lead the selection and procurement process during step 3, with the input of other stakeholders, and would ensure plans are in place for various aspects of step 4—the setup and maintenance of the software.
  • Managers and procurers would also typically lead the project management aspects of the effort, including setting the overall software adoption and procurement timeline, establishing the tasks/activities to be completed during the timeline, pinpointing the responsible parties for each task/activity, and ensuring the entire effort stays on track.

Stakeholder Category: Users

Points to Consider:

  • User groups will provide input into the required and optional features and functions of the software, covered in depth in step 3. The software adoption process lead would oversee the process of documenting the features and functions with the user groups. They may also have input into identifying viable product options as step 3 makes progress.
  • Topics to discuss with user groups will often pertain to the challenges and pain points they face as related to the software type in question. Understanding their challenges will lead to considering certain features and functions to help alleviate their issues.

Stakeholder Category: Influencers

Points to Consider:

  • For influencers, the topics to be discussed with them will be unique to the reasons why they are involved in the adoption effort.

Step 2c. Create a Tailored Information- gathering Process to Integrate Stakeholder Findings

Gathering information from stakeholders, overseen by the software adoption process lead, would typically be handled during virtual/in-person meetings and events. Planned meetings and events should be built into the adoption process and procurement timeline to ensure the input gained aligns with the decision-making process. Communication methods should be tailored to each stakeholder group and individual stakeholder as much as possible. Points to consider for approaching this process are shown in the table on the following page.

Stakeholder Category: Managers and Procurers

Points to Consider:

  • Managers and procurers would likely meet informally during meetings to discuss the software scope as covered in step 1. A series of meetings over a period of a few months might be planned, for example, to cover the step 1 items one at a time with space between the meetings for research to answer questions that arose.
  • As the effort develops, they would meet to draft and refine the overall software adoption process timeline, the procurement timeline aligned within it.
  • Users and influencers could be involved in some of these meetings, if their input is needed on certain topics.
  • Stakeholder findings, the results of these meetings, would be integrated into project documents such as a draft resource summary and the software adoption process timeline.

Stakeholder Category: Users

Points to Consider:

  • In order to gain input on the required and optional features and functions of the software, the software adoption process lead would plan collaborative events. Rather than have all user groups present at one big event, it may be more effective to have a smaller event for each user group. This way, the content can stay very focused on what each user group needs to discuss.
  • In the trip booking and scheduling example above, there were two staff member user groups mentioned: vehicle operators and service operations administrators. Members of the public, as app users and customers, were also identified as a user group.
  • One way to structure the interactions would be to hold a series of small collaborative events, perhaps in two rounds for each user group. The first round would involve the software adoption process lead explaining the effort, the user group’s role within it, and an open conversation about which features and functions they’d like to have included.
  • The software adoption process lead would work between the two rounds to distill the information into key points, which would then be summarized at the beginning of the second round of events.
  • The user groups would have an opportunity to confirm the direction, and add on details as needed. The second round could close with a discussion about the anticipated next steps for each user group, such as their involvement on the selection committee during the procurement process.
  • Stakeholder findings, the results of these events, would be integrated into the required and optional features and functions document, a prominent driver in the procurement and software selection process.
  • Contact would be kept with the user groups until they become users of the new software, and afterwards to get their input over time on changes needed.

Stakeholder Category: Influencers

Points to Consider:

  • Depending on the reasons why they are involved in the adoption effort, influencers may take part in the meetings and events mentioned above.
  • If the topic to which they are contributing is separate from the topics involving managers, procurers, and users, separate meetings or events could be planned for them.

Aligning user group needs with specific software features and functions can be a challenging process, especially when the user group includes members of the public, but also for internal staff in some cases. If this becomes too difficult to handle internally, an agency may benefit from hiring a consultant specialized in user experience. Such professionals formalize the connections between the needs that users have for software and what a software can provide to help make the most effective match between the two—a promising investment for particularly complex software adoption efforts.

It can also be challenging to gain access to members of the public in order to gain input. An agency may have a list of members of the public they commonly reach out to who serve as representative stakeholders on certain topics such as service changes or policy changes. Such a list could be leveraged for software topics as well; it could potentially be located by inquiring with staff members across departments to find out if one exists. The software adoption process lead could also check into local organizations with regular events where such contact could be made. In addition, partner organizations may have advisory panels or other organized groups that include such contacts.

Working with stakeholders is all about relationships. The software adoption process lead will be the primary person responsible for managing the wide range of relationships involved in working with stakeholders. Early on in the software adoption process, these relationships will be established, but as the process goes forward, they will continue building and further develop. It is important that the agency commit to incorporating stakeholder feedback into software decision-making processes, so that the stakeholders know their input was impactful.

Key Takeaways

  • Create a stakeholder map by listing the managers and procurers, users, and influencers of the new software, including the organizations and known roles/individuals at the organizations. Hold brainstorming sessions with colleagues or partners to fill the gaps if some contacts are missing initially.
  • Identify key topics for each stakeholder group by reviewing Steps 1, 3, and 4 and pinpointing which topics would be of most importance to each group.
  • Create a tailored information-gathering process, and integrate stakeholder findings back into Steps 1, 3, and 4 to close the loop between information gathering and decision- making.

Illustrative Project

Gwinnett County Transit (GCT) is the transit agency serving Gwinnett County, Georgia, part of the Atlanta metro area with an estimated population of 936,250.12 In 2018, GCT decided to pursue a microtransit pilot project in Snellville, a municipality of around 20,077 people in Gwinnett County. The microtransit service was planned to serve the general public, without any eligibility restrictions, and GCT also had plans to expand into at least one more microtransit service area in the coming years. The idea of having a pilot project, prior to a wider service rollout, was viewed as a logical way to approach a new service type in Gwinnett County—allowing time to work out issues early in the operation. GCT was experienced in providing demand-responsive ADA paratransit service, but starting on-demand microtransit that used advanced software would certainly involve a learning curve.

GCT put in place a series of activities to gain input from key user groups, especially the GCT staff members who would be using the platform daily. Vehicle operators and their supervisors were one key group, managers and administrators of the overall service were another, and customer representatives were included as well. GCT tailored an information-gathering process to ensure the points of view of these groups were incorporated into decisions.
The pilot project ran for 8 months, from September 2018 through April 2019.13 Having the pilot project for 8 months, prior to expanding the service into a wider program, provided GCT with a unique opportunity. The agency could glean information based on real day-to-day operational experience prior to embarking on a procurement process that would commit the agency to a software platform for a year or more. During the third month of pilot project operation, GCT held informal group interviews with the vehicle operators and their supervisors. Since they had already been providing trips for a few months, they had a lot to say about what was going well and not so well, as well as reflect on typical customers and share their general observations.
For example, the vehicle operators mentioned that they wanted the ability to see in advance if an upcoming passenger would require assistance with a mobility device, which was not possible in the pilot platform. This information helped them to mentally prepare for what was coming next. They also wanted the option to provide information when they needed to stop for unplanned maintenance needs or other purposes, so that the reason, precise timing, and location of the unplanned stop could be well documented. Further, the pilot software did not track all the details of the routes, such as the period between departing from the transit headquarters and officially starting the microtransit route, and this functionality was requested. Since asking about the gender, age, and other details of the passengers was deemed too personal to request voluntarily via the public-facing app, the vehicle operators shared insightful stories about the passengers. Passengers often spoke with the operators and told them what they thought about the new service. The operators shared that a number of passengers mentioned appreciating the independence the service afforded them. There were visually impaired passengers who typically did not leave home as often without the service, and older passengers who were going to the movies and other places more often just for fun, for instance.

Managers and administrators of the service had additional ideas about what the platform should include. For example, they wanted the data reporting process to the National Transit Database (NTD) to be more seamless—transmitting the data points from the software to NTD directly with limited involvement on their part. They appreciated the wide range of reporting and data options the pilot platform had, but wanted a better fit for “executive decision-making” purposes, such as a daily dashboard of the top 5-10 indicators that needed to be continually monitored. They wanted more data on where trips were going around Snellville (i.e., daily/weekly/monthly “hotspots”) as well as details on trips that connected with fixed-route options in the GCT service area—to better understand how the microtransit service supported cross-area connectivity.
In addition, they wanted key data points to be compiled in a way to help “diagnose” potential reasons for no-show trips, when a passenger booked a trip but never came to take it.

Gwinnett County Transit bus and driver
Image source: Gwinnett County Transit

Stakeholder findings were integrated into the heart of the software platform selection process, the Request for Proposals (RFP) GCT planned to use to guide the procurement. Unfortunately, GCT was unable to scale up to a microtransit program after the pilot finished, although GCT’s management considered the pilot highly successful and popular with passengers. Nonetheless, the microtransit software platform RFP document, which was drafted during the pilot period, was broken down into the typical software components along with key features and functions that the stakeholders requested—marked as either “required” or “encouraged.” In this way, the information gathered from stakeholders was a direct input into the procurement and decision-making process. Further, GCT planned to have live demonstrations of the software options to verify the features and functions, also planning for the stakeholder groups to play a strong role during the demonstrations by considering more subjective aspects of the software such as ease of use. The various users of the software were put in the driving seat, so that they had a strong voice in which software platform would have been selected.

12 United States Census Bureau. Quick Facts. Available at: as of February 10, 2021.

13 Gwinnett County. Test program for microtransit bus service concluded April 30. Available at: home/stories/viewstory?story=Testprogramformicrotransitbusserv as of February 10, 2021.