CHAPTER 5

Post-Solicitation Phase

Overview

This chapter focuses on post-solicitation activities that occur once the selected vendor has been contracted to provide their technology to the DOT. The chapter is organized into several major sections, which are:

• Using procurement to prepare for the technology implementation process.
• Using procurement to prepare for the technology adoption process.
• Preparing for effective training.

Detailed information on technology implementation and adoption of organizational change is beyond the scope of this study; therefore, the subsections of this chapter primarily emphasize how the procurement process can be leveraged to improve outcomes during the post-solicitation phase. Finally, the chapter concludes with a summary guide to help DOTs plan for an effective technology transformation from a change management perspective.

Using Procurement to Prepare for the Technology Implementation Process

The technology implementation activities typically comprise several items, such as:

• Discovery. Activities related to initiating the technology implementation, including validation of requirements, the gathering of documentation related to workflows and data sources, and definition of project team roles for the implementation process.
• Configuration. Initial setup of the technology within the DOT’s environment, including startup data in the case of software implementation. In many cases, the provider will also establish a “sandbox” environment for the DOT to use and will spend time configuring integrations, data usage, and other dashboards or displays. There are typically a series of configuration workshops to gather input from key work groups and end users.
• Go live. Activities used to ensure the technology is ready for cutover to the go live deadline and minimize any need for a “stabilization period.” Typically, there will be train-the-trainer activities in close proximity to the go live event. There is also a user acceptance testing (UAT) process before a new technology is rolled out across work groups. Multiple DOTs cautioned that the “go live” or “cutover” milestone can be messy. DOT project teams should be prepared for multiple rounds of edits and updates after the initial go live milestone. This is often called a “stabilization period” in which the vendor actively responds to issues and “bugs” that are not recognized until the go live event has happened. An approach for moving between testing and going live is to pilot in part of the system, such as in one district or for a limited function, before expanding to full capabilities.

Interviews with DOTs found multiple procedures to leverage the procurement process in a way that improves downstream technology implementation activities.

• Evaluate the vendor’s implementation experience. Before the implementation phase, particularly for complex software implementations, request concrete examples from the vendor demonstrating how they track and communicate adjustments in the software’s functional requirements. Consider this akin to the vendor providing “as-built” documentation that reflects the actual requirements and functionalities delivered in the new technology system. Additionally, it is crucial to establish robust change control processes to document, account for, and manage changes to requirements. Recognize that changes are inevitable during deployment; few technology implementations proceed without issues. Therefore, ensure that both the client and vendor have an agreed-upon plan for managing these changes effectively.
• Request an implementation schedule. Ensure the vendor provides a baseline schedule, defining key milestones and deliverables. Some technology vendors may argue that their agile or dynamic delivery methods make scheduling unnecessary or difficult to define due to the evolving nature of the implementation activities. However, every contract requires clear start and end dates along with a general SOW. This baseline is not a detailed construction schedule but a framework to set expectations and measure progress to help the client know if the deployment is on track.
• Pre-establish the client-side implementation team among DOT staff. DOTs should realistically assess the resources needed for a technology deployment. Often, client teams may feel overwhelmed by the technical details and defer excessively to the vendor, thereby neglecting their usual project management practices. Avoid this trap; all standard project management approaches still apply. If the schedule falls behind or resources shift, ask the vendor about the impact. Do not accept vague assurances like “We are hoping for the best” or “We should be able to make up the pace.” These responses are inadequate for any project, especially complex technology rollouts.

  From a governance perspective, DOTs should carefully consider who is responsible for coordinating with the vendor during the implementation stage. One DOT reported that vendors should include a point of contact within the DOT’s IT department, where applicable, and that all communication with the end users should include IT representation. This is important because IT needs to fully understand how the technology will interface with other systems in the broader technology environment, how data are being utilized, and so forth. However, there will be instances where new technologies may have limited interaction with IT, for example, a sensor system on a structure.

• Effective demonstrations can avoid surprises in implementation. One DOT reported an unfortunate realization from their software demonstration phase that they did not realize until the middle of software implementation. When the DOT’s project team asked the vendor during demos: “Have you done X before?” the vendor often answered with “Yes, we can do that.” The DOT’s team eventually learned that this answer meant the vendor had not done the requested functionality before and was simply hoping they would be able to overcome their lack of experience during the implementation phase.

  Another DOT team reported that they will never procure another software product without each vendor showing the DOT’s data within the software demo. This was because the vendor hit many roadblocks and challenges during the eventual implementation stage. In this case, the DOT interviewees reported many compatibility issues that were not recognized until the selected vendor was working with actual data inputs during implementation.

Using Procurement to Prepare for the Technology Adoption Process

To truly obtain the full benefits that new technologies can deliver, the adoption among staff is a critical consideration. DOTs will not achieve the desired return on investment without a successful technology adoption across the intended work groups. This section will discuss how the

procurement stage can be used to help improve technology adoption and share suggestions from DOTs for how they approach technology adoption.

Several quotes from participating DOTs illustrate the importance of conceptualizing technology procurements as an organizational change management effort, as follows:

“Every new technology will result in process changes. New technology means new metrics, new reporting, new data, new paperwork, and so on for even basic things that are currently happening in the organization with our end users. We have to start early even before the RFP to get involvement from across end users to build buy-in and momentum. If we don’t have buy-in and champions to support the technology adoption, it will be so much more difficult to be successful when the time comes to use it.”

“Change management is a big deal—the human element. Lots of layers to workplace readiness, implications, culture of the organization, and how these aspects can take a wonderful work product and trash it.”

There are several ways in which the procurement stage can be leveraged to build a foundation for effective technology adoption results later in the implementation stage.

• Engage end users in requirements gathering. One important way to create buy-in is to have all internal users involved in initial scope development and requirements gathering so that it ensures their concerns are captured, which minimizes surprises later which would otherwise be disruptive to the implementation and roll-out. If the DOT does not gather that input early on and later the implementation goes awry, it is expensive to make corrections then. One DOT explained the importance of end-user involvement in scoping as follows: “During implementation, we never wanted end users to ask ‘Why didn’t you talk to me earlier? Why wasn’t my voice included?’”
• Give end users the opportunity to contribute to evaluations. Another way to create buy-in is to involve end users in the technology demonstration stage of the evaluation process. This is hugely beneficial even when these end users are not serving as formal voting members of the evaluation committee. For example, one DOT included additional work groups in the demonstrations for their software procurement, which was an important way for them to see how their use cases would be conducted via the new technology. This was done voluntarily, where end users were invited but not required to participate. Participants were also provided with a feedback form to gather their input and opinions; this was done informally, but the evaluation committee was able to consider the information in their deliberations. The DOT’s procurement group communicated that if end users participated, they would receive the feedback form, and their input was considered valuable to the evaluation team in ensuring the right solution was selected from the perspective of all work groups. This was successful for the DOT because they were able to show the feedback forms had not identified any “showstoppers” from those who participated. This style of “end user demo” and feedback collection resulted in a more successful implementation process. The selected software was viewed by end users as being “our software,” wherein they had a real voice in the evaluation process without needing to be fully involved.
• Keep technology adoption in mind when forming the project team before procurement. Multiple interviewees suggested that DOTs should be mindful of having an internal champion for the adoption of the new technology. One DOT shared that they encountered large challenges when their internal champion left the agency soon after the procurement stage. Even though the technology was ultimately installed successfully, its usage floundered without a champion. In this case, the DOT’s internal IT group took on caretaking of the technology, which is different from being a champion that advocates on behalf of the technology’s use.

The turnover of champions was noted as an important challenge during the implementation of new technologies. Adopting a new technology often hinges on the enthusiasm and support of key champions who advocate for the technology and drive its implementation. However, turnover due to retirements, promotions, or transfers can jeopardize the initiative when champions leave.

To mitigate this risk, organizations can implement several strategies aimed at building resilience into the technology adoption process:

• Build a team of champions. Rather than relying on a single champion, create a coalition of supporters across various levels and departments. This way, the initiative has multiple advocates who can sustain momentum if one or more members leave. While this may not always be feasible, the creation of cross-functional teams (with members from multiple departments or operational groups), when possible, can help spread knowledge and enthusiasm for the technology across a wider group.
• Institutionalize knowledge and processes. Maintain detailed records of the technology’s implementation plans, processes, and lessons learned during implementation to ensure continuity. This requires acknowledgment from leadership that the project champions must be supported with time, resources, and supporting staff to ensure this documentation is completed promptly.
• Leadership engagement and support. Secure commitment from top leadership to champion the technology adoption by providing authority and resources (especially as noted in the prior point). Additionally, identify and prepare potential future champions who can take over if key individuals leave.

Preparing for Effective Training

Several DOTs shared their experiences in improving the training and subsequent adoption process when implementing a new technology.

First, DOTs should be mindful of how they will support the training process. Training is often planned in a train-the-trainer methodology. In many cases, the DOT will nominate internal SMEs who will then train colleagues in the field.

In one example, the internal SMEs were nominated from the DOT’s maintenance teams – a major challenge was the maintenance SMEs were expected to learn the new technology’s terminology, functionality, workflows, and other details in an accelerated 2-week training period, after which they were expected to be experts to train others under field conditions. In this case, the DOT felt that a longer and more supportive train-the-trainer model could have worked, but the abbreviated 2-week period was not enough training to set the organization on the path to success. However, one important “win” was when several maintenance staff started creating small training diagrams; their overviews of how to perform important tasks within the new technology were a big success. The SMEs also started going into the field and asking about shortfalls and questions the field staff had and then provided hands-on training support in the field. This was a big boost to adoption.

Identifying a “point person” or SME to support the adoption and training efforts of each work group was identified as a best practice. Multiple interviewees stressed that the resources required to support the technology adoption and training efforts are often underestimated. For example, one DOT stated that they needed staff to have a dedicated, full-time focus to support the roll-out and adoption efforts for a single work group. This point person sat side-by-side with field staff to answer questions and show relevant workflows in the new technology. This was time-consuming but resulted in success.

In general, the project team individuals who were involved in procuring a technology may transition to other roles before the technology itself is implemented. The long-term nature of technology procurements is often on the timescale of large construction projects that take multiple years to complete. One interviewee described the stakes of properly staffing the technology adoption by sharing, “If implementation does not proceed as quickly as expected, then morale can become low even if the project hasn’t failed.”

The personality of internal SMEs and technology champions can be an important consideration. For example, DOTs reported success when a detail-oriented individual was heavily involved in the project team to thoroughly consider their agency’s procedures and how the new technology would work within them. The following list provides key items to consider when planning for the training process to implement a new technology:

• Preparing for training requirements. The following items serve as a checklist to identify potential training requirements, user support, and related factors for a new system/tool implementation and/or initiative. The following should be collected to inform training requirements:
  • – Identify all potential system/tool users within the DOT, including their levels and types of access.
  • – Document and define the key actions and responsibilities of major user roles within the new system/tool.
  • – Inventory all current systems, tools, or processes that may be affected by this new initiative.
  • – Compile a draft of the current operational procedures from various personnel to ensure a comprehensive understanding of existing processes.
• Additional training considerations. Additional questions to ask when preparing for the training approach include:
  • – Usage analysis
    • Project the DOT’s future workload and frequency of activity within the new system/tool.
    • Determine the update frequency for the system/tool.
    • Identify which functions of the system/tool will be utilized most often by DOT users.
  • – Support structure
    • Decide whether to allocate dedicated support personnel or teams for user assistance.
    • Outline the process for granting new users access to the system/tool.
    • Consider the establishment of a support desk for the system/tool.
    • Estimate the time required for DOT users to become proficient with the new system/tool independently.
  • – Support expectations
    • Evaluate how current systems/tools are supported within the DOT.
    • Gauge user expectations for support compared to current standards.
    • Clarify executive expectations for system/tool support.
    • Assess available financial resources for training and ongoing support.
  • – Prepare proper documentation and guidance for the training process
    • Develop detailed process documentation and flow diagrams with distinct roles for each user role.
    • Conduct reviews of process maps with diverse DOT functions and personnel.
    • Create RACI (Responsible, Accountable, Consulted, Informed) charts to clarify roles and responsibilities.
    • Evaluate current user compliance with existing processes and systems.
    • Assess current user skills in relation to any existing systems or tools.
    • Perform quality checks on data input into current systems.
    • Compare the new system/tool with existing ones to gauge the extent of change.
    • Anticipate any staffing modifications required to support the new system/tool.

Another best practice comes from the interviews with DOT personnel. The more users who can spend time in the system during the configuration activities, the better the eventual training will be. Several users noted that they have experienced vendors (especially in software implementations) who asked the client group to make many decisions “on paper” before truly utilizing the system. This means the client group may be providing information and making

decisions that are not tailored to the realities of the new technology. The vendor would then use these client-provided inputs to configure the system. Then the client would be given training environments, only to determine that they would have made different decisions and provided different information had they known better how the eventual system would function. In short, a best practice gathered from interviews was to iterate early and often around actual use cases and workflows and use this as a mechanism to make more informed decisions on technology configuration.

Table 3 summarizes some of the key activities and team members to ensure a successful organizational change event.

Table 3. Key activities and team members involved in organizational change.