By Duke Hanson
While a lot of people take parking for granted, the one thing I’ve learned in my 35-year career in the business is that you can never stop learning. And while registering for the 2015 IPI Conference & Expo (my 22nd annual), I was pulled back to the educational sessions I attended or moderated last year in Texas. Session topics included multi-system integration, big data, and the Internet of Things. The overarching theme was the accessibility we now have to program operational and financial data.
Many recent IPI webinars and The Parking Professional articles have also focused on these same topics. While I know I risk sounding like the archetypal granddad with stories of needing to park five miles away in a blizzard when I was your age, these trends make me recall my start in the parking business—the era of Jurassic Parking.
The Beginning
My first day on the job with the District of Columbia Bureau of Parking’s towing program (January 2, 1979—the first day of the late Marion Barry’s first term in office), we towed at least 400 illegally parked cars, all of which were processed and tracked through voice communication and handwritten ledgers. The process worked liked this: One of our 100 parking enforcement officers (PEOs) ticketed a vehicle for a towable violation and then contacted the appropriate dispatcher. The dispatcher filled out a tow request card and forwarded it to another dispatcher who assigned it to the closest tow truck. (In many respects, it was similar to a taxi dispatching operation in which operators field calls from customers and a dispatcher finds the closest available cab.)
After the tow truck impounded the vehicle, the tow driver would radio the dispatcher and provide confirmation of the tow with relevant information, including—most importantly—to which of our three impoundment lots the vehicle was towed. We then used those tow cards to create handwritten ledgers, which were our information resource for responding to the (dude) where’s-my-car phone calls. These lists were copied and sent to the police department so they could be entered into the local law enforcement database and avoid the filing of erroneous stolen car reports.
This was all pretty tedious stuff that is now typically processed through wireless or Ethernet interfaces between handheld ticketing devices and/or mobile data terminals in the field and one or more back-office systems. These near-real-time communications serve double duty to make the process significantly faster for the municipality and easier and faster for motorists to retrieve their vehicles (without the panic of thinking the vehicle was stolen when they returned before the tow information was fully processed).
Technology (So to Speak)
Speaking of handheld ticket issuance devices, they were still a few years—possibly a decade—away, so any ticket-related tabulations or analysis were all done by hand. I credit myself with being way ahead of the techno-curve by convincing the powers-that-were to invest in a bill counter, which greatly reduced the time required to manually tabulate PEO ticket issuance counts from more than an hour to mere minutes; however, any PEO activity gap or geo-based enforcement analysis still had to be done by hand, ticket by ticket. Today, most handheld issuance systems provide this information with keystrokes and mouse clicks, if any intervention is required at all.
The software available to us in those days was housed on mainframe computers, and system development and/or modification was no easy task. Programmers were required to make hard code fixes and enhancements, including management information systems (MIS) reports. With extensive work orders to plow through, report development was usually at the bottom of the priority totem pole for programmers. Delivery expectations were appropriately dampened and, more often than not, once a report was developed, it was obsolete. The reports that were available, including scofflaw hot lists, were generated on voluminous (and wasteful) greenbar paper.
In most municipalities, license plates listed in a boot report were presented in alpha-numeric order by state and then by plate. A notable exception to that was the first iteration of the boot list generated by the San Francisco Municipal Court. In the late 1980s, I provided operational consulting as the City of San Francisco got its booting program off the ground. Plates in that city’s boot report were listed randomly, with no logical order that would make a search possible. With the advent of license plate reader (LPR)-enabled enforcement, boot crews can scan between 700–1,000 plates per hour, which is probably more than 50 plates in the time it took my San Francisco compatriots to check for one plate in their old boot reports.
The Moral
Any grandfatherly parable needs a moral to the story, so I’m obligated to pass one along. Parking managers now have instantaneous data at their fingertips. The number of tickets issued the prior day by officer or by beat, compared to any desired previous timeframe, can be accessed first thing the next day via a dashboard. Revenue retrieved from a meter collection route, contrasted with trend data for that same route, can be viewed using the same tool. Really, almost any key performance indicator (KPI) can be made available to parking managers on their desktops while they enjoy their first cup of coffee, meaning that any performance red flags can be raised so that investigative and corrective strategies can be developed.
If there is a dramatic dip in collection route revenue, is it a product of external or internal theft; a lack of adequate, ongoing enforcement; or a change in the adjacent parking generators? Identifying the cause may require some time in field or analysis of system-generated report data for other program areas.
For those who haven’t experienced how difficult it can be to get this data, it might be easy to overlook tools such as dashboards or dynamic reporting. Or, for those who relate all too well to some of the stories I’ve told, it may be worth assessing whether what you have on hand is being used to its full utility for making your life easier. Business intelligence and the data analysis it entails rely heavily on aggregation, which are readily supported by the open architecture that is now the norm in our industry. Even a technology pterodactyl like me has learned that we have the opportunity to connect devices in the field with enterprise systems and services for the collection and processing of important programmatic data.
I urge you to reach out to your internal IT resources and/or your system vendors to better understand all possible points of connectivity, implement those system linkages, and optimize the flow of this business data through the dynamic reporting tools that should be available to you.
Duke Hanson has 40 years of transportation and parking experience, including positions in both the public and private sectors, and was a member of IPI’s Board of Directors for six years. He can be reached at djhansonjr7@gmail.com.