ParkEasy — Parking made effortless

Developing and deploying a mobile application for municipal parking meters

Bbhavyabishnoi
12 min readDec 12, 2021

As chief technology advisor to the mayor of the fourth largest city in my county, part of a larger metropolitan region, I argue that the mayor should develop and deploy a mobile application — ParkEasy — for municipal parking meters. I evaluate its development using a stakeholder map and the Value Proposition Design (VPD) model, and its deployment using an agile digital procurement framework. I also present a case for agile (versus waterfall) implementation of the mobile app, a process that is incremental and iterative, and places user needs at the centre. Then, i assess security and privacy concerns that may arise for users of the app. Finally, I make a case for how the mobile app should be embedded within the municipality’s Government-as-a-Platform (GaaP) efforts, in particular in line with its smart cities and mobility infrastructure.

Rationale for Developing and Deploying ParkEasy

Using anecdotal evidence from 10 different users of mobile parking apps in the cities of Boston, New York, Washington, D.C., San Francisco, Los Angeles, and Philadelphia, I received an overwhelming response in favor of the respective parking apps they used, in terms of convenience, time saving, and service delivery. They also suggested that these apps reduce the stress on coin collectors and credit card machines, as well as decrease the amount of pay meters that require constant access to the internet for payment processing — a win-win outcome for users, municipalities, and parking operators.

Even though the sample I interviewed is not sizable by any measure, it is arguably representative of a typical user of parking meters in a metropolitan city. One may critique my position citing equity concerns, but most — if not all — car owners are likely to own smartphones. Indeed, it is estimated that, as of 2021, 72.7% of people living in the US use smartphones while 91% own a vehicle (personal, company’s, or another family member’s). There are likely to be significant overlaps across these statistics, and the discrepancy (merely 18.3%) is paltry, and justifies the deployment of the parking meter mobile application. For vehicle owners who do not own smartphones (who are likely to be socially and/or economically disadvantaged groups, the elderly, people with mobility challenges, etc.), alternative solutions can be made available, including:

  • Issuing parking permits to these groups (based on need), freeing them from parking fees;
  • Providing designated parking spots to members of these groups;
  • Issuing account-based parking permits to these individuals using regular cellphone service;
  • Deploying low-cost Bluetooth beacons that automatically deduct parking fees; and
  • Issuing on-demand parking permits to visitors, tourists, and other casual users.

Furthermore, preliminary research into existing parking apps revealed that car owners fervently and frequently use them. For instance, Passport Parking used in Boston, Chicago, Austin, Portland, Detroit, etc. is highly rated (4.8 stars) on AppStore by 77,000 users. Similarly, ParkMobile that offers contactless payment in 350 US cities, including New York, San Francisco, Washington, D.C., Atlanta, Miami, etc. has over 20 million users, and is also rated highly (4.8 stars) on AppStore by 1.2 million users. PayByPhone Parking is another popular municipal parking mobile app that is used in more than 1,000 cities worldwide, and is available in 12 languages. The app is rated highly (4.9 stars) on AppStore by 366,000 users. These case studies suggest that mobile apps are offering lucrative benefits to all stakeholders involved; this is evaluated in the next section.

Stakeholder Map for ParkEasy

Figure 1 below illustrates the various stakeholders that will be engaged by deploying ParkEasy. Below, I briefly describe how each stands to gain from the mobile app.

Figure 1: Stakeholder map for ParkEasy
  • Vehicle owners: convenience, cost and time savings, and better parking experience;
  • Municipality: better governance through partnerships and real-time mobility data, keep pace with innovation, efficiency gains through streamlined operations, reduced hardware costs on meters and kiosks, greater parking compliance and therefore higher revenues, and increased political support among citizens;
  • Parking Operators: more customers, higher revenues, decreased costs, improved efficiency of parking operations, and better analysis through reporting and analytics;
  • App developers: higher revenues through a steady stream of sales, and potential for further business through political buy-in; and
  • Payment providers: increased contactless payments and revenues.

Another stakeholder group are automotive original equipment manufacturers (OEMs) that can also gain from leveraging the app’s APIs to provide a better parking experience to vehicle owners.

Making a Case for ParkEasy using the VPD Framework

Next, I use Osterwalder and Pigneur’s (1999) Value Proposition Design (VPD) framework to justify how vehicle owners may stand to gain from the mobile parking app through “gain creators” and “pain relievers.” The VPD exercise can be conducted for other users as well, but in the interest of brevity, I use the framework for vehicle owners. My analysis is informed by my interviews with 10 vehicle owners; certainly, there may be blind spots that I have missed, and a larger sample size is likely to strengthen this analysis.

Figure 2: VPD for ParkEasy

As we can see in Figure 2 above, a VPD exercise for ParkEasy unveils significant gain creators and pain relievers that are offered by mobile applications for parking meters to a typical vehicle owner. A mobile app has the potential to bring about significant savings in time and money for the user, as well as eliminate stresses involved with finding a parking spot, locating a car once parked, and having to change parking session times. Based on the above, I suggest the following functionalities that the app should include to ensure an optimal user experience. These features include (but are not limited to):

  • Be operational on Android, iOS, and mobile web platforms;
  • Reserve parking ahead of time, possibly at a discounted rate;
  • Pay for parking using a contactless payment interface;
  • Extend parking time remotely from the app;
  • Receive alerts to know when a parking session is about to expire;
  • Show real-time data on availability of parking spots;
  • Store multiple cars in a single account;
  • Conduct reporting and analytics for business users;
  • Avail “find my car” feature to direct user to parking location;
  • Be allowed multiple payment methods within the app;
  • Be integrated with complementary apps like Maps and payment wallets;
  • Observe changes in parking rates; and
  • Have effective functionality for parking operators, both public and private.
Figure 3: Sample User Interfaces for Mobile Parking Apps (Passport Parking and ParkMobile)

Many mobile apps that currently exist in the market (including the ones highlighted earlier) possess a lot of these features and functionalities. Samples of user interfaces of 2 existing apps are shown in Figure 3 above. Therefore, it may be judicious to borrow existing best practices — and adapting them to the needs of our city — instead of reinventing the wheel. That said, municipality applications are not immune to risks and challenges. Some of these are discussed in the next section, including alternate investment avenues for the mayor.

Security and Privacy Risks Associated with Deploying ParkEasy

Data, including personal information, is fundamental to the success of city applications. Once collected, the data is shared and often stored by different IoT devices, with multiple connecting points between software and physical infrastructure, and between publicly and privately owned assets. This creates privacy and data security risks for users; some of these are discussed below.

The following questions are pertinent — who owns the data? Users? Software developers? The municipality? Should this be considered public data? How can consent to utilize user data be obtained? Would data thus collected be used for state-sponsored surveillance? These questions are at the cutting edge of citizen-government interaction in an era of increasingly powerful technology.Furthermore, with an increased reliance on technology, software malfunctions, hacking, data theft, and phishing scams have a greater potential to cause serious inconvenience, financial damage, and personal injury.

Government agencies including municipalities handle sensitive citizen data, which is susceptible to attack by cybercriminals. Municipalities can also be targets for ransomware. For example, a simple software bug or a malicious hacker can potentially shut down utilities for an entire community, misdirect traffic, or disrupt emergency services. Using Denning et al.’s (2013) security cards, one can gain an insight into a potential adversary’s motivation, resources, and methods. A cyber criminal may be motivated by money in staging a cyber attack, and may sell user data to third parties or sabotage a competitor’s system. S/he may do so by exploiting the apps technical processes, and take control of the system’s data. As the Mayor’s chief technological advisor, I would effectively examine the security cards, and prepare for likely scenarios that may occur in the event of a cyber attack.

One way to mitigate such risks is for the municipality to partner with a technology provider that is familiar with the challenges that government agencies face, including budgeting, prioritizing user needs, and protecting against cybercrime. Once a technology partner is on-boarded, it will be important for the municipality to work closely with the vendor to ensure transparency in citizen data that is collected. For instance, the app could explicitly state that certain data will be collected and linked to user identity — for instance, financial information, location, contact information, usage data, purchases, etc.. It could also state the type of data that may be collected but not be linked to user identity — for example, location, user content, diagnostics, identifiers, etc. All data submission can also be made optional, and users can be reassured that data is used only for app functionality, personalization, and/or analytics, and not to track the user or show her/him advertisements. These strategies have been deployed in the past.

Furthermore, in terms of data privacy, anonymizing and aggregating data to, for example, tackle air pollution or curb traffic congestion could justify the collection of data, but this may also mask important underlying patterns. In the absence of a North Star, city governments will need to continue managing the trade-off between technological innovation and data privacy risks, and will need to develop rules and guidelines on what data can be shared, when, and with whom. The benefits and challenges of data sharing will continuously need to be weighed and evaluated.

This is especially pertinent in the modern day, where third-party technology vendors have become key partners in the collection, hosting, and management of data. Beta Blocks (in Boston), Sidewalk Labs (in Toronto), and Smart and Connected City project (in Kansas city) are examples of cities that have partnered with private companies to nurture innovation and encourage civic participation. I believe that government transparency in the processes and rules around data sharing as well as using open-data platforms and open-source methods will help build trust among citizens for such partnerships and initiatives, and drive up citizen participation in city governance. For example, Singapore, Dubai, and Barcelona have developed APIs and developer support to enable citizens to build solutions seamlessly on top of government data.

Are there Alternative Investment Strategies for the Mayor?

To my best understanding, mobile apps offer the best solution to ensuring time and cost savings for parking to all stakeholders involved. The question, then, to be answered is whether or not a mobile parking app remains a policy priority in the city relative to other issues like public sanitation, cyber security, healthcare, and so on. Anecdotal evidence suggests that it costs $30,000–$40,000 to develop a city parking app; an understanding of budgetary priorities would be required before justifying the implementation of the app. That said, on the face of it, this amount fare little compared to a municipality’s overall budget, and therefore, I propose developing and deploying it using an agile approach in the next section.

Implementing ParkEasy Using an Agile Approach

One may argue that, given the high level of certainty about the terrain and goals in that relatively much is known about deploying mobile parking apps, a waterfall approach may be preferred in this case. However, I argue that, agile may still be better because the actual circumstances and expectations of citizens in the municipality are unknown. As such, risk will be reduced and citizens will become active stakeholders in the app-building process itself as valuable feedback pours in at each stage or iteration of development. Furthermore, as the app catches on, it will make it easier to add on additional features to the app, as requested by vehicle owners, parking operators, or even government officials from within and across departments.

Agile development, however, has implications for digital services are procured and request-for-proposals (RFPs) are published. This will be based on the Agile Manifesto, and will entail moving from contract-centered to project-centered thinking. Under this method, some steps — including needs assessment, procurement plan, RFP issuance, tender evaluation, terms and conditions contracting, and supply chain management — can be combined, and contract negotiations can be entered upon during the sourcing process. This will lead to efficiency gains for the municipality. In the case of the mobile parking app development, this will entail introducing an initial test phase following which the budget, due date, and scope and other aspects of the project can be decided upon.

This will encourage competition among vendors and is likely to drive down price for the municipality. Since I am likely to face some pushback from some government departments, I will embed certain elements of a traditional RFP evaluation criteria matrix using a weighted scoring approach. There are several softwares that execute RFP evaluation, and these can also be adopted. The RFP evaluation criteria (with assigned weighted scores) could include:

  • Technical capabilities
  • Vendor experience
  • Price
  • Project approach
  • Customer success practices
  • Reputation and customer references
  • Data security measures
  • Terms and conditions
  • Diversity, ethics, and sustainability policies
  • Project timelines

However, the above will be adapted to agile methods. For instance, price competition will be based on a vendor’s proposed cost of a standard agile team week or ‘sprint’, and the total number of weeks quoted for project completion. The pricing will also be incremental, and not fixed or lump sum, for instance, by breaking the project down into smaller chunks.

Furthermore, the agile approach will require the municipality to be an active player in the app development process, and therefore, it is important the leadership and lines of command are established explicitly and coherently. Either the Mayor herself or someone appointed by her should take on a purposeful role in heading the project, along with a dedicated team —with stakeholders from across multiple relevant departments. This will help ensure that the mobile app is designed and deployed on time, within budget, and stays focused on meeting the desired objectives. I also echo Carnahal et al.’s (2019) recommendations on modern software development based on the 6 concepts of user-centered design, agile software development, DevOps, building with loosely coupled parts, modular contracting, and product ownership. In the interest of brevity, I will not elaborate on these; but effective recommendations to the Mayor on the mobile app deployment would be informed by a sound understanding of these principles.

Aligning ParkEasy with the Mayor’s GaaP Efforts

I believe that siloed data repositories within municipal departments significantly hinder a city’s ability to develop a comprehensive view of citizen engagement with public services. The deployment of a mobile parking app can easily be situated within an overarching strategy of building smart cities — a focus of many city governments in recent times. For the real potential of smart cities to be realized, it is imperative that both organizational and technological silos need to overcome — and perhaps, city governments need to explore synergies in pursuing collaborative citywide transformations.

Some city governments have begun to build open-data platforms to be used and shared by multiple departments and agencies. For instance, Portland (Oregon) and Soeul (South Korea) are constructing their own internal data repositories — Portland Urban Data Lake and Smart Seoul Data, respectively. In the context of mobile parking apps, Passport is already providing an end-to-end digital mobility platform to enable municipalities to:

  • Carry out parking payment management through scalable mobile and digital solutions;
  • Ensure traffic and parking enforcement on-the-go in order to encourage compliance;
  • Provide vehicle permits to residence in an efficient and timely manner; and
  • Control curbside congestion by regulating the distribution of scooters and fleets.

Therefore, there are opportunities to learn and adopt innovations from Passport’s (and other) ecosystem for our municipality. The digital mobility platform can be embedded within the broader public transportation digital infrastructure, and data analytics and data sharing can provide deep learnings that will enable cost and time savings, and better citizen experience with government services. This can be further integrated into the municipality’s broader smart city goals and programs, once adequate data privacy and security concerns have been identified and addressed.

Conclusion

In this memo, I presented a case for developing and deploying ParkEasy — a mobile parking app for the municipality I serve. The app is likely to benefit vehicle owners through time and cost savings, and greater convenience in general. On the part of the municipality, the app is likely to ensure better governance through partnerships and real-time mobility data, reduce hardware costs on meters and kiosks, generate greater parking compliance and therefore higher revenues, and increase political support among citizens. I suggest that an agile approach is best for this, which will ensure that user needs are prioritized at every stage of development, and bring about further efficiency gains for the municipality.

The mobile app deployment, however, is likely to raise data privacy and security issues, for which the municipality will need to breakdown data silos, ensure data quality and control, balance technological innovation and data ownership rights, and manage tradeoffs between data-sharing benefits and privacy concerns. Moving forward, cities will become both repositories of extensive data as well as drivers of technological and governance innovations; in light of this, policymakers will need to make conscious and intentional decisions about managing the various tradeoffs, all the while keeping the needs of citizens at the forefront.

--

--