We Aren't Selling or Buying Widgets Anymore
There is no doubt that life has changed dramatically in recent years—some of those changes are positive, and some are not. The same is true for the parking industry. Parking is evolving at a fast pace, bringing with it great customer conveniences. Most new parking technology is not “out of the box,” “plug and play,” or “one size fits all.” They are systems with data inputs and outputs and connectivity to other devices. The procurement and implementation of these new technology systems are large, complicated projects that are difficult to implement with traditional approaches to project management.
Table of Contents
As an industry, parking and mobility agencies are veterans at writing and administering Request for Proposals (RFPs) and contracts that are for predictive, single deliveries. Even incremental delivery projects where the desired outcome is known are well within most organizations’ wheelhouse. But these large, game-changing technology procurements are a different breed entirely and require a different approach. While the process of trying to write a RFP which adequately identifies the processes that exist, what will be needed, and how to implement and train for a new system are intimidating, the consequences of not doing so properly can be disastrous.
What can a municipality do to improve its outcome?
Writing an RFP for new technology is complex. Before the RFP is issued, proper planning is critical. This includes creating a Project Management Plan, as well as a Work Breakdown Structure (WBS). These documents, as well as others, help ensure that all aspects of the project including scope of work, process for implementation, and responsibilities are well defined. Issuing a Request for Information (RFI) in advance may provide some important information to be considered but does not substitute for a Project Management Plan and a comprehensive WBS. A WBS divides the complexity of the project into five phases: initiation, planning, execution, control, and closeout. Part of this information will be necessary to draft the work statement for the RFP. The process of the WBS analysis will result in a more thoughtful approach to the project.
The WBS for a technology contract could topically include:
Project management
System engineering
Software, hardware integration requirements
Deliverables
Testing
Support services
Installation
The specifics will vary based upon the program requirements.
Let’s Give an Example
A municipality intends to replace its ticketing enforcement system. The current contract is expiring, and the incumbent has a contractual requirement to provide access to the system for six months after the expiration of the contract and to cooperate in the data transfer of data.
The incumbent provider was awarded a contract years ago on a fixed fee with a singular go-live or delivery date. The incumbent developed the current technology with upgrades and customization format over that long period of time. Parts of the existing processes are not fully known to the municipal organization as the incumbent performs much of its work in its back office.
The project team meets and begins to update a work statement from the previously issued RFP. The team does not prepare a comprehensive project management plan and did not prepare a WBS or similar analysis, as they did not have the information they needed to do so. Instead, they are relying on the previous work statement and other parts of the RFP to identify the requirements for this new procurement. The work statement contains a description of the processes and requirements of the last project, which they hope will be similar enough to this one that the vendor can fill in the blanks.
Since they have not done their due diligence with their current provider, they do not know how any of the processes are handled, or where any of the current challenges lie. In addition, as the incumbent does know these things, there is a likelihood that the municipality can set themselves up for hitting those same challenges again with the new contract. Instead of an opportunity to improve, they are setting themselves up for more of the same.
Proceeding on this path to RFP is very risky. It increases the likelihood that the project will incur change orders and disruptions to the implementation schedule, as there is no clear plan in place. It is doubtful that the system will be fully functioning on the go-live date. There is no documented contingency plan. Many key elements of managing the project may have been missed and are certainly not easily tracked due to lack of documentation. The stress level during implementation is intense as the team tries to scramble to have all of the modules and reporting functioning as quickly as possible. Training has to be repeated after each of the corrective changes is deployed and because it was a single rollout the changes have broad impact and leave the operational users of the system confused about how to use the new system. The data transfer is difficult to manage because the contractual terms with the incumbent are ambiguous. What do terms such as “cooperation” mean? What does “access to data” mean? The municipal team and the vendor are frustrated, but both work in good faith.
A better approach results from the WBS analysis before issuing the RFP. Here are some potential results of performing the analysis that could improve the development and implementation process:
The team determines that additional time will be necessary and requests that legal obtain a six-month extension with the incumbent that better defines the incumbent’s data responsibilities. This also gives the team more time to understand the back-office processes.
The team recommends that the install of the new ticketing system be divided into segments with identified delivery dates. Training is to be conducted upon acceptance of each module. Each segment of the project has an identified value as a percentage of the total contract price. When a module is delivered, the municipal team begins to utilize and test the system and compares the data to that of the incumbent system. The process is repeated for each module.
The team recommends that the modules that create new functionality follow an agile approach where the agile team meets and guides the process for the release of the new technology. In this instance the RFP would be crafted as a hybrid with several parts being predictive and several agile. The Work Statement for the RFP details the parameters.
The Work Statement defines the data responsibilities of the vendor. The project management plan documents identify the internal responsibilities of the project team including as to data and may identify the need for outside expertise since the loss of historical data has significant risk to the municipality.
These are just some of the potential positive impacts that conducing a WBS analysis before issuing the RFP can have on the outcome of the project.
What can we do as an industry?
Data issues can be complex when transitioning from one system to another. We need to recognize the challenges of moving large amounts of data from an incumbent provider to a new vendor when a contract ends and to ensure fair competition and obtain fair pricing – after all, isn’t that the goal of an RFP?
As an industry, we are adept at writing and administering RFPs and contracts that are predictive, single deliveries. Even incremental delivery projects where the desired outcome is known are well within most organizations’ wheelhouse. More and more our projects are, at least partially, in the agile arena where the outcome needs to be jointly developed through multiple releases designed to address continually evolving needs. An advantage of the agile team is the joint development of a solution to an unknown or complicated problem. Since most of us have careers outside of the IT world, this process is unfamiliar and uncomfortable.
Implementation of large projects will be well served by identifying parts of the project as predictive and parts as agile. This hybrid approach allows those parts that can easily be defined to follow the predictive model and those items that are less clear to follow the agile approach. Critical thinking about the project, its segments, and applicable release dates of segments of the system by the project team prior to drafting the RFP is essential.
The demand for customer convenience and the need to better manage the curb will continue to accelerate the deployment of new technologies. The process to get there should not be feared, as our industry has the professional competencies to move to procurement approaches that respond to these demands and challenges. If municipalities are struggling with the process to put together a comprehensive RFP to ensure their new technology is developed and implemented properly, there are third-party companies with the expertise to guide them through it.
We are definitely not buying widgets anymore! Let’s embrace the opportunities to create RFPs that better serve the innovation we seek.
The post We Aren’t Selling or Buying Widgets Anymore appeared first on Parking & Mobility Magazine.
