Los Angeles CTO Randi Levin talks about implementing enterprise resource planning in the nation's second largest city.
"Glitches in Payroll System Spark Furor" ... "City Fires Vendor Over ERP Implementation Problems" ... "City's Financial System Upgrade Runs Into Problems" ... "County Will Try Again to Modernize Computer System."
What state or local municipal IT executive wants to read these real headlines in the local newspaper?
The fact is they highlight the challenges city executives face when implementing or upgrading technology. There's often a natural resistance among municipal leaders to risk change because when implementations go poorly, there's a good chance they'll receive public criticism. Whether from the employee's or vendor's perspective, failure is a badge no executive wants to wear.
With the economy struggling, technology executives at municipalities across the country are under increasing pressure to cut costs and find ways to operate more efficiently and effectively. Enterprise resource planning (ERP) has long been held up as a primary vehicle to get there, both in the commercial and municipal sectors. But as the aforementioned headlines show, when it comes to municipal ERP implementations, the end results seem hardly guaranteed.
Los Angeles was in a technological hornet's nest in 2005. Government officials were under scrutiny for a PeopleSoft 8.8 upgrade that had gone badly. Beyond the multimillion-dollar price tag for taxpayers, the purchased technology wasn't delivering on its promised capabilities. City staff was working overtime to make the system operational.
Internally the situation was so bad, city personnel couldn't perform routine updates. System glitches and outdated business processes required an ongoing focus on issue resolution rather than software maintenance and financial positioning. Employees were forced to "backdoor" individual transactions into the city's large information database -- this led to a significant backlog of maintenance tasks and problems reconciling contractual obligations due to quality control issues. Additionally several problems with the interface between citywide systems -- including heavily customized software code -- were preventing data from being shared across departments.
Externally vendors weren't being paid, and the first audit of the full fiscal year was approaching. For nine months, the contractor responsible for the upgrade attempted to diagnose the issues, without success. This led, albeit erroneously, to a widely held opinion that the Oracle software was to blame.
Although many factors worked against L.A., there were some strategic points in the city's favor: a centralized approach to solving problems -- rather than letting each functional department manager micromanage projects, city leaders determined the best course of action citywide; good coordination between key agencies; and a strong propensity for seeing the big picture rather than getting caught up in the minutiae of specific problems.
In a rare move, the original software vendor called on Metaformers Inc., a McLean, Va.-based ERP integrator, to help diagnose the problem. During a 72-hour period, Metaformers staff analyzed and diagnosed issues related to the system software, business processes, city databases, specific program settings and more. Metaformers executives then outlined a plan to fix the problems. It was presented to city management, which put the plan into action.
Today L.A. is back on track. In December 2008, the city announced it successfully upgraded and went live with PeopleSoft 9.0 Financials.
Successful ERP is a blend of science and art, so there's no one-size-fits-all formula for success. But as we learned during L.A.'s ERP implementation, just following a few consistent rules will increase the likelihood you'll accomplish your goals.
1. Software won't fix organizational problems.
In the past, city staff saw
the IT department as order takers rather than strategic partners for change. This was evidenced by the "fix-it-now" expectation that surrounded the supply management system, the citywide procurement and payables program. Whenever a problem arose, rather than resolving the fundamental issue via the purchased software, the IT department was expected to create an immediate resolution with software patches and database corrections. But fix upon fix created a maze of system tweaks and changes that only a select few could decipher. This led to information chokepoints across the organization and imbalanced power in the hands of only a few employees. The problem was more than software: Culture, process and organization all played a role in what, on the surface, looked like software problems.
Buying software in hopes of fixing fundamental organizational issues is a mistake. Unless leaders at the top (i.e., the CIO, chief financial officer, commissioner, CEO, mayor or director) are willing to turn over rocks and deal with the problems underneath, they shouldn't bother with a large software investment.
Governments are often years behind the commercial sector in areas like business process and procedure, and organizational management. Political will -- and often, political capital -- is required to take on established cultural and procedural roadblocks to change.
Nothing exempts civic leaders from leadership. Software helps implement change, but it shouldn't be the vanguard of change -- that's the role of executive leadership.
2. The corporate sales model doesn't work for government.
L.A. ran into serious issues beginning in 2005 with an upgrade from PeopleSoft 7.5 to 8.8. The city proved vulnerable to the corporate sales model -- a soothing corporate message that a software solution would make all problems go away. The city's leadership wisely decided to resolve issues with the current software rather than something new. Had it opted for a change in software, the same problems would have inevitably occurred.
It's important to understand that government enterprises have fundamental issues that don't align with the corporate sales model.
Corporations are structured to produce financial and operational results on a short time frame. Consultants need revenue, and software vendors need sales to achieve quarterly results. Consequently there's an ongoing corporate push for quick sales and implementation cycles.
On the other hand, governments have strategic, fundamental issues that limit their ability to achieve short-term returns on investment (ROI), although they're also pressured to deliver short-term results. For example, many governments are willing to accept large, discounted deals today and worry tomorrow about how to get the greatest productivity and ROI from the purchase.
Developing a plan to address these issues before purchasing a high-powered enterprise solution is critical. In government, every significant IT-related decision should focus on long-term results. However, short-term needs, including political considerations, often drive decisions. When it comes to enterprise solutions, this is usually where the problems start. By and large, governments should reject the "we can help you in the short term" response from the corporate world and instead focus on long-term strategic change.
When government leaders think only in the short term, they feed the corporate sales model. Looking in the mirror and telling yourself that you're the problem isn't an easy task -- you only do it if there's a long-term benefit. It's the job of the CIO and other government executives to see, as the bigger picture, a vision for change. They should avoid the pitfalls of the corporate sales cycle that's misaligned with government. They should spend wisely, but not necessarily cheaply, in pursuit of that vision.
3. Know your limits.
L.A. had several issues with its supply management system, beginning with the organization's culture. The city's leaders could have chosen to make sweeping changes, but in this case, executives saw that a smaller but successful effort
with the supply management system would build momentum toward broader challenges.
Government executives need to understand the limitations within their organizations. There may be a political will to change, and even the financial and human resources to support it -- but these are not limitless. It's important to set reasonable expectations for change before allocating funds. Executives should take on manageable, achievable chunks and spend resources with the government's limitations in mind.
Meeting a change initiative if a government is unprepared is a recipe for disaster. It will not account for the ROI, nor will it subsequently achieve it. What's more, it will inevitably lose ground and waste the investment. The risks associated with cramming through change initiatives are broad and many: overloading resources, creating single points of failure and knowledge bottlenecks, creating or exacerbating cultural problems, demoralizing personnel and losing momentum on the change initiatives.
It's important to be up front with your vendors about how you do business, and expect and demand support for that model. You will suffer to some degree on the discounts you can get, but in a highly competitive industry, vendors can't afford to be too pricey -- they'll follow your model.
4. Get out of the software business.
During the failed upgrade from version 7.5 to 8.8, L.A. and the original contractor created invasive customizations. This seemed to be the right thing to do at the time. After all, it's tempting to opt for your own code rather than the code provided by the software vendor. But in this case, it was a failure that caused system glitches and conflicts. The customizations were removed in the upgrade to version 9.0 because it was the correct long-term decision.
Understand that you likely won't be able to maintain the slick solution that's presented on the PowerPoint sales slides. Although the grand vision is politically appealing, the true cost is easily dismissed or overlooked as the contractor, software vendor and project leadership all desperately want it to succeed. In the end, even if the grand vision comes together, few government enterprises can afford to maintain such systems for long.
In a similar vein, many organizations are caught in the trap of meeting their demands by letting contractors overly customize out-of-box software packages. In addition to opening the door for out-of-the-ordinary software and system conflicts, this sort of coding can lock an organization into the need for significant long-term contracts with contractors. This "deadly embrace" can dilute the long-term ROI and autonomy that a system is designed to achieve. Based on these customizations, the deadly embrace gives a contractor a knowledge contractor, which leaves the government no choice but to continue a long-term contracted service arrangement for specialized support, in addition to the government's own support staff.
Software vendors maintain their code and have thousands of customers using it and reporting issues to them. The software vendor's code is constantly improved with millions of dollars of investment. Cities don't have the technical expertise or support structure to maintain customization. A customization should be simple and noninvasive, if it's done at all.
Government executives must not shut down IT investments because they fear failure or a challenging economy. Government leaders have an unprecedented opportunity today to implement change. Software can be used as a catalyst, but not at the expense of sound strategic fundamentals. Leadership is crucial.
Define your vision for change; understand the strategic, fundamental roadblocks to achieving that change; make plans to address each of those roadblocks and incorporate software tools that can enable them. Be bold in your strategy and vision, and be wise spending your resources.
This is rarely the sort of activity that makes for sensational headlines, but it will position your organization for the significant, positive change that is badly needed in today's government.