Designing a Mobile Parking App (#2)
Introduction
Like many other municipalities, we are looking at investing in a digital parking payment application, which would help modernize our current and antiquated metering system. While such a system would provide some immediate benefits, there are numerous questions surrounding the opportunities and risk involved, how we implement and manage the system, and what role it should play in a larger platform strategy.
Evaluating Our Options
In looking at our options for this funding, it is important to look at other potential efforts that this funding could be directed towards. For this case, the most obvious alternative investment to the proposed digital parking meters would be investments in other transportation-related areas (both digital and non-digital), such as bike-share programs, digital bus schedule systems, and even curb and street redesigns to facilitate better integration between public and private transportation options.
When looking at the potential digital parking solutions, we need to outline the potential benefits of risk in moving forward with such an option. Primarily, the value of an application would be in making it easier for customers to pay for parking, check on their remaining time, and add time to their meters — all remotely and without the need for change. Additionally, by making parking easier for consumers, we expect this innovation to increase safety by reducing the frequency of illegal parking, boost city revenues by streamlining fee collection, and build a technological base upon which to launch future innovations.
However, we also need to balance these against some negative consequences of the proposed innovation. By investing in a new technology, we may be invariably stymieing future efforts to advance beyond a car-focused transportation system, as this becomes a “sunk cost” that psychologically stalls other worthy initiatives like expanding public transit or micro-mobility options. In addition, digitizing parking may have the more practical effect of preventing other uses for this valuable curb space such as bus or bike lanes. Finally, we also need to understand whether this has any unintended effects on the communities in which it is launched — such as increasing traffic, driving up property values (and thus contributing to gentrification) or put up a barrier for citizens without smartphones to be able to use parking.
However, given these potential drawbacks, a mobile application for parking in the city, if designed and deployed well, could create a lot of value in terms of convenience for our townspeople, revenue for our city, and opportunities to test and refine an implementation plan for future digital innovation in our city.
Who needs what?
That being said, its paramount to identify clearly what exactly the user needs (vs what they want) and how such an application could deliver that. Using a value proposition framework, we can identify our customers jobs, “pains” and potential “gains,” and then map our service to alleviate each of those.
Primarily, our customers would be using an application like this to fulfill three basic functions: paying for parking, checking on parking time remaining for a paid spot, and adding time to a paid spot, all over a smartphone. Such functions would alleviate common “pains” that most users of municipal parking would have. For starters, most residents today do not have spare change on them, and thus a parking system that requires change to use means time spent either finding inconvenient but free parking, getting change, or risking parking illegally. Additionally, it is impossible to check on time remaining or add time without physically returning to a spot, but risking it and potentially getting a ticket can be a huge financial burden for many people.
As far as gains go, these range from the required (which must be present for an application to work) to the unexpected (things that our customers did not even know they wanted). The application needs to be able to simply pay for parking, either though a credit or debit card or directly from a banking account, and work on iOS and Android at a minimum. Beyond that, consumers would expect the application to enable customers to check on existing reservations and prolong them, as well as save their payment information. Desired gains for consumers would include things like including information on the price of parking (especially if we look to a dynamic pricing model) or enabling consumers to identify what spaces are available. Finally, unexpected gains may include things like integration with other city public transportation applications, integration with other digital payment services (i.e., Venmo), or features that enable users to find other transportation-related resources, like electric charging stations.
Thus, such an application should be judged primarily as to how well it accomplishes these jobs, alleviates these pains, and enables these gains (with required gains being the most important). Beyond that, we would also want to identify how stakeholders may be affected, further opportunities and potential risks, and what implementation and management of the system may look like.
And who cares?
We’ve identified various stakeholders that may be affected by such a system: resident users, commuters (non-resident users), resident non-users, police/parking enforcement, city government, business owners and users of adjacent transportation systems (busing, micromobility, etc.)
Resident Users
These are town constituents who will also be suing this application for parking. Primarily, they want convenience — our system needs to be reliable and facilitate re-use. Additionally, these customers may be more price-sensitive, as they probably know where to find free parking and thus less willing to compromise on value and convenience. We also want to understand any barriers that our constituents may have to using the system, including lack of a smartphone or a bank account.
Commuters
For these stakeholders, convenience and functionality is key. Additionally, since they will be coming from neighboring communities, platform compatibility with existing systems will be key. That does not necessarily mean using the same applications as nearby cities will be necessary, but something we should factor in when deciding.
Resident Non-Users
While the actually utility of the application will be less important here, locals who won; use the application will still be concerned with two things: its effect on their neighborhood, and the direction of the funding derived form it. Additionally, in either of these two considerations, we need to be sure we bring them along throughout the process.
Police/Parking enforcement
For these stakeholders, while the application may enable some additional information gathering and enforcement possibilities that may be useful, there are two potential drawbacks: less revenue from decreased ticket issuances and a corresponding lack of personnel needed for parking enforcement (if we integrate “smart enforcement” options like some municipalities, in which sensors can alert authorities to illegally parked cars or cameras which can scan license plates and issue tickets automatically)
City Government
For the government, this has the potential to both boost city revenues and potential reduce traffic accidents or other safety incidents by encouraging legal parking. The government will have to be wary of negative backlash from affected residents, as well as increased scrutiny on that potential revenue increase.
Local business owners
They would probably support such an endeavor, as it has the potential to drive traffic, they would also probably look for a validation provision that would enable them to offer free parking to shoppers
Clear Opportunities, but not without Risks
While a project has many direct benefits (in terms of saved time, convenience, and money), there are also many indirect benefits for this kind of technological advancement. These opportunities, however, also carry risks.
Data
The most important opportunities here surround the ability to gather data from this program. While the needs of the program in and of itself are basic, the amount of data generated could be significant. The data generated from this program could be used to help understand traffic patterns in the city, contributing to a more efficient allocation of transportation funds and development of public transportation options. Additionally, the data from such a system could support advances like demand-based pricing, which could help cities maximize revenue while encouraging other transportation options in crowded areas.
That being said, the data can also be used for more coercive methods — some cities have already begun experimenting with systems that use sensors and cameras to automatically tickets customers (after a short grace period) who don’t pay for parking, and the information contained in this application (such as drivers license number and license plate) could be used to support surveillance more generally. In addition, having a large amount of financial information stored in a single place (as it almost certainly would be here) presents significant security concerns that we need to consider. Thus, before any application is developed, we need to develop a strict framework guiding the use of the data it produces and outlining how we will keep data secure.
Equity
While the application has the potential to provide a lot of value to consumers, we need to understand concerns around access. To use an application, a customer needs two primary things: a smartphone and a bank account (or credit card). We would need to understand potential customers for this service, and whether it would be a reasonable assumption that most people would have access to these. If not, we should look at other solutions that provide the same convenience and savings, but without the upfront barriers (this could also influence our decision as to where to deploy the system within the city as well).
Springboard for future innovation
Parking digitization, in some ways, is an ideal first foray into digital innovation at the city level. It has been done before in many municipalities, so we have some case studies to easily reference. The technology demands are relatively light, and the barriers needed to participate are in the hands of most potential users. Additionally, a simple digitization system can avoid many of the ethical dilemmas surrounding more advanced technologies (like facial recognition), most systems will give people the option to use change if they so choose, and such a system is easy to contain to only certain geographic areas (for both equity concerns and to assist in management and rollout). Beyond these, the impact to many constituents is tangible — they can experience the difference immediately. Thus, this type of project is a lower-risk opportunity to test internal project management and development capabilities before rolling out more robust innovations. However, we need to make sure we are creating a system of implementation and enables and prioritizes the incorporation of feedback into future development cycles.
Challenges we may face
While creating a digital parking payment application is less risky than other efforts that cities could make, there are some universal challenges that affect any projects like this. The first involves how to design the development of this programs — either though procurement or making such a program in house. For most municipalities, developing such a program in house is simply a non-starter: there is a lack of technical know-how, and there is no need for a tailored product to resolve a problem faced by many municipalities. However, procuring a technology has its own implications. Chief among these are the bureaucratic restrictions surrounding procurement in the government. In the case of both CalFRESH and California’s child welfare services, the existing procurement strategy would simply take too long, especially considering every evolving technology, to bring to bear. Thus, each procurement process had to operate outside established practices (such as favoring a more iterative approach than a complete solution delivered only once) to be successful. Beyond that, we also need to look at targeting specific aspects of a solution and then building a process that incorporates feedback into future cycles as opposed to tackling an entire bureaucratic system at once (in this way, parking systems is advantageous as it is already well sized to help with this).
A related challenge is the tensions between developing a quick, one-off solution or looking to developing a holistic government platform. Both strategies have costs and benefits — a one-off solution would be quicker and cheaper but may hamstring us in the long-run (forcing us to create an army of systems integrators to make everything talk). Looking for a platform solution will enable future innovation across many different government services but can increase costs and development time strategically. Thus, we need to make a choice, from the outset, as to what digital innovation will look like in our city.
Meeting the Implementation Challenge
In looking to implement such an application our city to look, we should look to best practices of technology development more broadly. First off, from a political perspective, we should prioritize community involvement and clear communication throughout. As previously discussed, there are development and equity concerns here that may affect people beyond just those who use the service. Thus, to generate buy-in, we need to bring in community leaders from the beginning to ensure they feel heard and supported throughout the practice.
Beyond political considerations, it would be paramount to adopt an alpha-beta-live approach, which would enable the incorporation of feedback into future development cycles. While testing in the alpha phase may be less critical (as there are already solutions to this relatively narrow problem), it becomes critical in the beta phase, especially in ensuring the capture of accurate qualitative and quantitative feedback. Simultaneously, development of one or a few features, or sequestering a beta phase to a small geographic area, would help facilitate the incorporation of this feedback into a final solution.
Finally, in terms of managing and scaling such a venture, we need to understand whether taking a waterfall or agile approach makes most sense. In this venture, an agile approach would make more sense, especially if we believe we may develop a more holistic transportation-focused application rather than just a parking application. Ideally, a waterfall approach may work for the initial development of the applications (especially since there is already a lot of knowledge and commercial off-the-shelf solutions we can look to). That being said, taking an agile approach when looking at testing and implementing our application may yield the most tangible benefits, especially since such a project can be easily segmented into sprints on distinct features (such as digital payment application integration or spot reservations) or in geographical areas. Finally, an agile approach would allow feedback that could inform development of adjacent technological projects, like a public transit application.
Alignment with Government as a Platform
As we mentioned earlier, this is not only a question of how to tackle this specific problem — but of envisioning the role that technology should play in administering the functions of the government. But in envisioning how this application can fit in a government as a platform strategy, we must keep a user-focused design and determine what creates value for our constituents. And while using this parking meter application as a mechanism to develop a platform may have uses in the future, it would prolong the effort as we develop and entire platform strategy.
Thus, it makes the most sense that such an effort may be a part of a larger platform of related initiatives, but not of an entire government as a platform strategy. Given that this is designed to facilitate meter parking, it may be worthwhile to envision this as a part of a transportation-focused platform — for example, integrating service with other paid transportation services (paying for a city bus fare or utilizing a city bikeshare). In that way, we could deliver a small, tailored, and related set of services in a much quicker timeframe than trying to create a platform for every government service. Additionally, the further away we get from the core service we are providing them — which is simply facilitating their movement — the less value we give them. Thus, a transportation focused platform would find the right balance between functionality and value on one end, and cost and timing on the other.