Ellen Perlman was a GOVERNING staff writer and technology columnist.E-mail: firstname.lastname@example.org
"It's not for the fainthearted." David Otto, an information systems manager for the city of Tacoma, Washington, is talking about his city's experience installing a complex centralized computer system--an enterprise resource planning project or ERP, for short. In the nearly two years it's taken to replace 102 legacy computer processes with the new system for billing, financials and other administrative tasks, he and other city officials have been battered by battles with unhappy employees, the press and the city council, which was not happy when told there would be additional expenses for the $50 million system.
At least Otto can commiserate with several other large cities and states. From Arkansas to Iowa to San Antonio and beyond, ERP implementations have been tripped up and nearly deep-sixed by problems ranging from poor project management to under-trained employees to nasty political infighting.
That hasn't stopped states and localities from taking off down that rocky road. Faced with ailing computer systems, many large governments want to gain the efficiencies and advanced capabilities that can come with centralizing human resources and budgeting data and other technology software. When it is done correctly, employee productivity improves and information is better organized and more accessible to departments and policy makers. "You almost can't imagine running without this kind of software," says Joshua Greenbaum, of Enterprise Applications Consulting, a software analysis and consulting firm.
Governments may be buying a better mousetrap, but as they install it, they have to deal with users' fingers getting snapped and springs popping off here and there. For both human and technical reasons, rolling out an ERP system is an arduous and long-running task--in both the public and private sectors. "These projects are the most complex human endeavors we undertake this side of building a bridge, a canal or the space shuttle," Greenbaum says, adding that large business organizations get it wrong "all day long." Unfortunately for governments, their missteps are scrutinized more closely and publicly. Even so, Greenbaum says, an ERP system "works much more often than it fails."
That said, failure or even its close approximation is messy. Arkansas' ERP experience, which began in 2000, is a case in point. There were technical hiccups: When the payroll piece of the system was rolled out, more than 500 state employees failed to get their paychecks; several vendors were not paid on time. There are legal tangles: Two employees sued the state, claiming the system was not accessible to the blind. Arkansas turned around and sued SAP, the vendor. But the state didn't limit its suit to accessibility. It also claimed that SAP had failed to provide a performance-based budgeting module as contracted and that the regular budgeting module it did provide didn't function up to expectations. SAP disputes the state's contentions. A trial date has not yet been set.
And there's been intra-governmental finger-pointing and fault- finding. Even as the project began, the top legislative leaders in the House and Senate, both Democrats, questioned whether Republican Governor Mike Huckabee gave authority for the project to too many people. Randall Bradford was hired as chief information officer in October 2001 to help fix the already troubled system. After he gave two weeks' notice in June 2002, he was fired, wrongly, he contends, for declaring he was going to publicly reveal problems with the ERP system.
Now that there is a lawsuit involved, most officials in the administration decline to speak about the ERP project on the record. One who will is Arkansas Attorney General Mike Beebe, who is running for governor this year. He questions the integrity of the project, cites lack of performance on the contract and criticizes the implementation as "slow, complicated and labor intensive."
Then there's the secretary of state. More than two years after the $60 million system was put in place, Charlie Daniels is using his own accounting software, which he finds superior to the state's new system.
Most ERP implementations are not as troubled as Arkansas'. But almost all face significant problems and major stumbling blocks. The slip-ups can begin very early in the process. Sometimes specs for the project are written incorrectly, the government isn't really clear about what it wants, or the vendor tries to oversell the product. Or once the project gets underway, officials start suggesting additional tasks for the system, leading to "scope creep," which means additions, changes and more expense. "The software," says Greenbaum, "is almost never at fault."
Projects also falter if there isn't visible leadership, consensus among those who have a stake in the project and good communication and marketing. And even when such pieces are in place, a city or state may not be prepared for change-management issues. "Most leaders do not adequately anticipate the amount of frustration and the change required," says Mollie Anderson, director of the Department of Administrative Services in Iowa, which is putting an ERP project in place.
Inadequate training is the subtext to many failures. Tacoma knew that and thought it had training under control. It had set up a four-month training program that was almost university-like in its approach. Some 1,700 "students" attended courses that were available all day, every day and some nights and weekends. And attendance at key courses was not exactly voluntary: Users could not get access to the system until they went through the training.
And yet, as the city started to implement several functions at once-- a finance system and a billing system, followed quickly by business warehouse and management modules--an employee backlash flared up. City employees complained that they couldn't figure out how to do their jobs under the new system. The local press got wind of the workers' frustrations, investigated the ERP project and found, according to one reporter's story, that the city had designed a project that was too large to succeed, had refused outside oversight and had failed to give employees adequate training.
Otto takes issue with the findings but sees that the training program was not ideal. People were being taught to use the new system even as that system was still being configured.
Iowa, too, ran into employee-based problems. During the first few months on the system, productivity faltered by as much as 40 percent. Vendors who had received payment within 15 days under the old system, for example, were now waiting 45 days. The chief financial officer for the Workforce Development Office complained that his agency's trust and confidence had been "shattered."
Anderson says things have improved since then but that the state learned that it had to go beyond just training employees. It needed to involve users in testing the design of the system to make sure it made sense for how they do their jobs. With the average state worker 44 years old, most people using the old system had settled into a comfortable familiarity with what they did. The new system, however, required employees to do a lot more data entry than they were used to doing. Previously, for instance, a central office took care of accounting. Now individual departments are responsible for it. That's a workload change tied to a new way of doing business, and employees have to be prepared for the change.
While the need for training cannot be underestimated, neither can the importance of project management. Iowa admits it didn't get that right either at first, and only realized it when things started to unravel-- the project slipped in terms of being on time and on budget. Moreover, agencies--the system's customers--started complaining about various functions. Administration department officials couldn't get straight answers when they made inquiries. The number of change orders-- requests to do something different than originally planned--was increasing.
Enough clues emerged for Iowa to realize the project needed an overall manager. There were people managing the technology and others overseeing different modules that were being put in place. But no one was watching out for the entire project--dealing with change orders, making sure things were completed on their due dates and taking action if things started to slip. "You need someone who manages from start to finish," Anderson says.
Denver also began its ERP project without a strong ERP manager or chief information officer. Without such key players in place, the city was not equipped to manage the complexities of the upgrade of its payroll system. Inaccurate balances in accounts and other problems surfaced. "We never missed a payroll," says Mike Locatis, the CIO who came on board after the project was underway. "But confidence in the system went way down."
Ballooning price tags have bedeviled many an ERP project. In San Antonio, the mayor and the council complained that project staff were not updating them on progress or the lack of it. According to an investigation by the local paper, the project director said the project was keeping to its budget, while costs were being tucked into other areas so the overruns didn't look so dramatic.
Tacoma also had a price-tag issue. Early on, Otto explained that there would be additional and ongoing operations and maintenance costs but concedes he presented that aspect of the project to policy makers only once or twice, while the original estimate of $50 million was discussed at every meeting.
Later, the council was unpleasantly surprised when it learned there would be a higher operating budget for the new system than there had been for the old one. Project managers could have kept council members better informed about present and future costs. "It was sticker shock," Otto says. "We didn't do a good job at really hammering home that there were going to be ongoing costs."
Iowa didn't do well anticipating how much staff time would be needed in the construction phase. There is a substantial cost for staff as they work with a contractor. There may be an unconscious don't-want- to-know aspect to the calculations. "The fear is that if you fully articulated all those costs, no one would appropriate the money," says Anderson, adding that no one was purposely deceitful and that it's a lot like calculating the cost of having a family. "When you get into it, it costs more than you thought."
Despite all the ERP tribulations, there's no point for a government to cower in a corner and avoid an overhaul. Change brings angst, but most ERP projects eventually work. Besides, there is a price to pay for waiting until a system falls to pieces and for the inefficiencies that can be the hallmark of clunky old systems. The important mindset for revamping systems with ERP, Denver's Locatis says, is to approach it with "eyes wide open."
Some ERP glitches come from a government being too ambitious, a phenomenon that is akin to trying to boil the ocean. And just as productive. "Doing too much is a recipe for disaster in enterprise software," says Joshua Greenbaum of Enterprise Applications Consulting. Tacoma, Washington, he says, fell into that trap. As he sees it, the city tried to do way too much and all at once by putting into play four applications within a two-month period.
Tacoma officials see it differently. They looked at the choices at hand. They could either go with a big-bang implementation or phase in various ERP applications over time. They went for the cost savings of a comprehensive startup. A phased implementation might have been less risky, says David Otto, the director of Business Information Systems for the city, but it costs money to build and unbuild technology bridges to legacy systems if each piece of the project is done separately.
Another trap is trying to customize the software too much. The less tailoring a city or state does for a particular function or agency, the more likely it is to achieve a positive return on its investment. Tacoma knew this going in but couldn't avoid fine-tuning software for the billing process for five different utilities. But customizing means that software has to be tested separately and that is time- consuming and costly. And then, when the vendor updates its product, modifications have to be made all over again.
Some customizing can't be avoided. But if you do too much of it, says Bev Wheeler, industry principal with SAP, "you end up with a brand-new legacy system." In some cases, governments that do too much tailoring of software might never be able to upgrade the system, either because it becomes too expensive or new software releases come with architectural changes that preclude updates and improvements to customized applications.