In the mid 1990's, I was asked to help the Street Light division of the District Department of Public
Works with automation. At the time, the Street Light Division had no software tools in place to monitor daily repairs made by it's contractors. Multiple contractors maintained the 65,000 streetlights in the District. Depending on the location of the streetlight pole, the repairs may have been made by a contractor working for the Federal government on "federal" property. Alternatively, in other parts of the city, repairs were made by a contractor working directly for the District.The District of Columbia is a different beast from most cities. In some ways, the District operates more at a level similar to federal and state governments. In other ways, the District must rely on it's own resources to do tasks other cities take for granted.
So, you can imagine the outcry of public opinion, when crime spiked in different pockets of the city due to streetlights being dark. The finger pointing began. What were the repair records? Who failed to repair the streetlights despite the repeated calls for repairs by the citizens of the District?
At the time, I had been a partner and software consultant with the District of Columbia DPW & Transportation for 5 years. It was 1997, and I had just written and installed DPW's first enterprise call center and work order system. The District was broke at the time, and for pennies on the dollar, I had managed to develop a system that tracked everything from graffiti to potholes, missed trash collection to clean city initiatives. DPW had just begun monitoring and tracking it's response to citizen calls for services, with automation that had been designed on a dime and worked like a charm.
The management folks at the Street Light division were ahead of their time. They realized that they had 65,000 in street poles and fixtures of citywide assets. They needed to know what poles were affected by group re-lamping projects. They needed to see where wattages were insufficient and needed to be upgraded. They needed to be able to track their assets using GPS positioning. Oh, and yes, they also needed to see how well their contractors were responding to requests for repairs.
On top of it all, they realized that their contractors needed incentives to perform to higher standards. At the highest standards, the contractors would be rewarded for their efforts - not only in responding quickly to repairs, but also by proactively maintaining streetlights. Should the contractors fall short on their list of incentives, penalties would be assessed. Meet Performance Based management contracting.
Of course, it was one thing to write all of these incentives into a contract, and another to be able to determine if the contractor was meeting, or falling short of it's performance goals. Typical work order systems would not do the job. These applications did not provide enough detail to match the language of the contracts. Typical work order systems translated calls for service, into work order. If they were GIS-based, you could even see the problem areas easily on a map. Good stuff. But, it would be impossible for the Street Light division to manage it's contract using traditional work order or call center software, because the reporting was not tied to performance criteria.
Instead, the Street Light division needed to be able to track specific motivational factors as it related to street light repairs - and provide a "report card" to the contractor. They needed to be able to score both the quantity of repairs being made, with the quality of these efforts. They needed to be able to determine if incentives that were documented in the contract as "incentive based" - were truly being met. They needed a birds eye view, with all supporting detail available - to justify each and every action. Bottom line - they needed to make sure that automation judging the of repairs and maintenance of streetlights - was a one-to-one match with the language in the contracts.
Good ideas often get put on hold due to politics, and/or changes in leadership. It happens everywhere
. All of the time. The Department of Public Works was reorganized, and the Street Light Division was suddenly a part of the Department of Transportation. Existing contracts were re-evaluated, and new ideas were flowing in from a sudden source of federal funding. A new city-wide call center was implemented in 1999, and everyone was told to use this application, irregardless of the fact that it didn't have a way to create work orders from service requests. Three more years went by, and still, there was no automation that could connect the dots between performance based contracts and work order management.Finally, a light at the end of the tunnel. The Streetlight Division of the Department of Transportation desperately needed a solution. They needed automation to help oversee their performance based contracting needs. And, they needed it yesterday. The feds had finally allocated some much needed funding to the District.
Instead of re-inventing the wheel, we resurrected our existing work order management software, gave it a complete makeover so that it would be web-based, and carefully wove in the performance goals from the contract. The new performance based work order system represented the goals set forth in the repair contract. A scorecard for each performance goal was automated. Quick turnaround repair results were rewarded. Sluggish repair results were subject to penalties. The accuracy of data entry was monitored. Random inspection results became part of the big picture. Trends were evaluated over time. Patrol crews were monitored for effectiveness. Material usage and costs were captured. Utility bills were evaluated.
The city was becoming more energy efficient, and had the documentation to prove it. The contractor was held responsible to the terms of the contract. All of this became a reality - with performance based work order management software - called iSLIMS.
Parking Meters
S
hortly after the the District of Columbia implemented performance based work order management for Street Lights, Parking Meters was getting ready for it's version of performance based contracts. Strangely, their automation needs were both very similar - and yet unique.For many years, the District of Columbia used a contractor called ACS to manage all parking meter repairs. Without having the tools to evaluate the timeliness and quality of it's contractors repairs - the District relied on reports from ACS's own software systems. Of course, you can imagine, that the contractor appeared to be doing an outstanding job! (see "Is your FOX watching the Hen House" ) Without their own set of tools, there was no way for the District to be sure.
When the parking meter repair contract came up for renewal, the District of Columbia decided to try iSLIMS to help it manage the performance criteria for parking meter repairs. With parking meters - two performance measures criteria were key to the contract: Measuring Meter Operability and Liquidated Damages for tardy repairs.
With over 16,000 parking meters in the District of Columbia - it was imperative to have the vast majority of them working - and collecting revenues. Parking meters out of service, could pose a significant loss of revenue to the city.
Thus, the birth of meter operability. Meters were judged daily as either operable, or in-operable. This means, the meter was either working, or it wasnt. And, if the meter wasn't working - then the city wasn't collecting revenue. As an incentive built into the contract, the city cannot have a percentage of NON working meter to be less than 97% for single space meters, and 99% for multi space meters. If the numbers fell below the line of acceptance, then the contractor would be assessed penalties. It didn't matter if the repairs were done on time, or late for meter operability. All that mattered, is the percentage that were NOT working each day. The District needed it's performance based work management software to calculate this for them - automatically.
In addition to meter operability - a second set of contract measures were put into place. This second set of measures strictly evaluated the promptness in making parking meter repairs. If repairs were made on time - all is good. If repairs were made LATE - then penalties were assessed.
Each month, the contractor is evaluated using iSLIMS. The report with the largest dollar value of penalties is used each month - as a bill to the contractor. If the Meter Operability Report showed higher penalties than the Liquidated Damages for Tardy response Report - then the Meter Operability Report was sent to the contractor for payment.
With the aid of iSLIMS, the District of Columbia Parking Meter Division was now able to assess penalties on it's contractor - a feat it had never been able to achieve in the past. With the added incentives to meet higher levels of performance, the contractor now pays far greater attention to repairs.
