15 minutes Author: Shared-Use Mobility Center Date Launched/Enacted: Apr 12, 2022 Date Published: April 12, 2022
This is the second phase of the five-phase lessons learned module about the CPACS Ride microtransit service. The first phase was on learning and building trust. This is the second phase of the project that deals with planning and executing the procurement of a software as a service vendor. In 2020, CPACS procured a two-year contract with a technology vendor to implement and administer demand response technology services and associated hardware supporting a fleet of 12 vehicles, three of which are wheelchair accessible. The lessons learned from the procurement phase are:
In 2019, CPACS transportation services provided close to 38,000 low cost or fare free trips with over 15,000 Revenue Hours. Before COVID-19, there was typically one CPACS bus operating at any given time in Clarkston, GA. Key destinations include the non-emergency medical trips to the hospital or doctor’s offices, pharmacy, shopping centers such as the grocery store or a flea market, CPACS offices, government offices, social services agencies, or employment related appointments (interviews, orientation, job training).
Our RFP went through several iterations. The team was intentional with our request to attract and select the right partner for this project and its goals. Prior to this project, CPACS’ dispatching and scheduling system was a pen and paper operation that offered highly personalized customer service, so there were opportunities to introduce technology and a more automated system. However, the challenge was, improving efficiency while catering to the user group’s needs. For example, an app that did not support multiple languages would not be acceptable. Continuing to provide a highly personal customer service while going digital became a new priority and challenge. Because of this, we outlined the specific details of the on-demand operation that the project team was seeking and then focused on this project’s unique project priorities.
The three project priorities and goals in the RFP included community engagement, multi-lingual support, and a trip data exchange between providers. These priorities had a dedicated section of the RFP and were given their own section in the scoring guidelines, which helped us understand the vendor’s willingness to meet the project’s needs. This emphasis helped vendors understand what was important to the project, which in turn, resulted in proposals that were rich in the areas most important to the work and allowed for innovative solutions. Prior to taking on an RFP, especially one that is seeking innovative solutions, it is important to do the research up-front and speak to other city agencies to build your knowledge base. Another approach, and although this project did not utilize it, is to issue an RFI to collect information from the industry you hope to work with to understand.
We added more opportunities for face-to-face (or Zoom to Zoom) discussions with vendors during the proposal process. For example, we held an open information session before the submission date where we reviewed the key components of the RFP and answered questions. We also extended interviews to four of the six companies that submitted proposals so we could hear from them personally. While this took more time and coordination, these conversations enabled us to ensure the vendor understood the service, answer any outstanding questions, and learn about the product more deeply.
While we believe this was a helpful approach for this project, we do recognize that priorities like community engagement or multi-lingual support may be considered outside of the scope of a typical software provider. This may deter some providers from submitting a proposal. However, we encourage projects to vocalize their community’s needs and look for partnerships that will meet those needs. We found each company that submitted a proposal was excited and willing to work on these additional deliverables and that the multi-lingual support priority of the project was not a barrier for any of the technology vendors.
Our commitment to and advocacy for the project’s needs continued throughout this project. It was important to have the priorities clearly outlined in the contract so deliverables and expectations were set early.
One example of how we expanded on a priority in the contract was co-creating a memo with the technology vendor that outlined the details of trip sharing. The memo served as an example of our intentions to work together as a team with our new procured vendor. Because we clearly outlined the goals and needs of the project in the RFP, RFP responses were used to build a strong contract. It is important that the contract be specific and outline such elements as, data sharing, data reporting requirements, having direct access to a project team member, performance metrics, payment schedule, service requirements, project goals.
While including this information in the contract is important, it does not mean that the mobility operator has provided these services before or knows how to do it, so asking for a demonstration of the software, service simulations if that is an option, and checking references is critical.
For more information on procurement see the FTA published resources.
To prepare for the RFP process, the team discussed who should be on the RFP scoring committee to bring diverse perspectives, knowledge and expertise. We identified gaps in the stakeholders and skills required to successfully vet the providers. Through this discussion, we decided to invite Loammi Aviles, Transit Operations Analyst at Gwinnett County Transit (GCT) and Ryan Walker, Compliance Program Coordinator from Atlanta-Region Transit Link Authority (ATL) to join the team and be on the RFP scoring committee. Loammi could represent GCT and the goals for a data trip exchange between them and CPACS and Ryan’s insights were particularly important during the contracting process. Through this collaborative process, Atlanta is in a better position to realize its goal of being a regionally integrated mobility system. In retrospect, we could have more deeply understood our scoring committee members’ backgrounds to strategically leverage people’s strengths and know-how.
Establishing clear goals and outcomes early in the project life cycle is important to the success of a project. This should be coupled with a thorough understanding of the current and planned services to have a better understanding of the software and how it can meet those needs. Through our community engagement process, our goals evolved as we learned more about the community’s needs, so conducting this community engagement early and throughout the project is important as it will inform the mobility solutions.
Because CPACS does not currently have a system in place for tracking large quantities of data, the team communicated the need for a vendor to work from a zero baseline when it came to reporting and performance metrics. Additionally, since CPACS offers social benefits and personalized services, we want to be sure to use qualitative data as a metric for success.
The procurement and contracting process required time and care to communicate the project effectively, accurately and sufficiently. One action that we did not take was to put out a Request for Information. While we did not do this, it could be helpful and should be considered when implementing a technology solution. An RFI is a call to the industry to put forth ideas and explore solutions to a particular need or mobility pilot idea.
The information provided in this lessons learned is for general information purposes only. Consult your local compliance officer and guidelines when procuring services through an RFP.