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

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:

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.

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

¹² United States Census Bureau. Quick Facts. Available at: https://www.census.gov/quickfacts/ as of February 10, 2021.

¹³ Gwinnett County. Test program for microtransit bus service concluded April 30. Available at: https://www.gwinnettcounty.com/web/gwinnett/ home/stories/viewstory?story=Testprogramformicrotransitbusserv as of February 10, 2021.