Detroit Finance System Sputters after Overhaul
In 1997, the City of Detroit announced a plan to revamp its financial software with a three-year, $47.9 million project called the Detroit Resource Management System, or DRMS, commonly referred to as Dreams. It should have been called “nightmares.”
ZIFFDOWNLOAD id=”1457″ title=”p62-65″>The initial plan called for the integration of 43 departments and 22 computer systems onto a single system that would run financial, human resources, and payroll software from Oracle Corp. Five years and more than $130 million later, DRMS has delivered only the financial applications, and the city has not begun to implement the HR and
payroll applications that were supposed to be the project’s big payoff.
To be sure, the nation’s seventh-largest city has reaped some benefits from the project. It now has functional, modern financial software and a new network of computers to support it. “DRMS is not a boondoggle, it’s just a very high-cost system that still has deficiencies,” says Joe Harris, auditor general of the city of Detroit and a longtime critic of the project.
Detroit’s program fell short for several reasons. For starters, the scope of the project was beyond what could reasonably have been accomplished with the resources allotted. Also, the bureaucracy of the city was resistant to change, forcing the software to be adapted to old business processes instead of the other way around.
Turf wars prevented useful feedback and criticism from reaching the right parties, and training costs for city workers were grievously underestimated. Meanwhile, lead integrator IBM Global Services (in the midst of the Y2K crunch and overheated dot-com economy) was having trouble staffing the project with competent workers, and Oracle’s software—the same used by corporations—couldn’t handle all of the arcana of municipal finance.
Some of the particular problems were specific to Detroit, or to public projects. But in its broad outline, the DRMS fiasco could have taken place in a corporate environment as easily as a public one.
Too Much, Too Soon
From the beginning, the city was trying to do too much, too soon. “If I could redo the project plan, I would go back and figure out how to do it in chunks, in smaller pieces versus the mass distribution as we ultimately did it,” says Carl Bentley, former deputy director of information technology for the city and the man who had day-to-day responsibility for the project for its first two years. “A major issue was the culture, with people going from rotary-dial phones to voice mail and facing a total change in the way they did business.”
Even now, the financial software is not always used efficiently. Take the example of paying vendors more frequently than the old twice-a-week schedule of cutting checks. This was a key objective of the implementation, touted in the original plans as a way of making municipal business run more smoothly.
And indeed, DRMS has let Detroit pay vendors more frequently. But that improvement has had some unintended consequences. For instance, the city is writing too many checks for trivial amounts to some vendors; Ameritech alone gets 100 per month. “They didn’t do anything to the process,” says auditor Harris. “They just put in a system.”
Although Bentley and Harris disagree on many aspects of the DRMS story, they agree on one thing: The substandard job that ended up being done by IBM Global Services, the integrator initially put in charge of the project. “IBM had competent people when we started, but they lost them,” says Harris.
Bentley says the demand for top workers during the Y2K fever and the bubble years made it tough to retain the good people on the project. “I think people were saying, ‘Why should I be in Detroit in December when I can be in sunny California?'” he says.
The staffing problem was severe enough that Detroit’s technology managers resorted to personally interviewing some employees IBM was considering bringing in on the project, in order to make sure the city was getting the people it needed on the job. A spokesman for IBM Global Services, however, denied that IBM had problems in assembling a quality team.
The ultimate decision about that, of course, is always the client’s, and in 1999 Detroit made its decision, firing IBM and replacing it with Solbourne Group, a consulting company in Colorado that specializes in Oracle systems.
“IBM didn’t have a strategy to resolve the glitches in the system, no game plan, no timeline,” Harris says. “The city could not get that out of IBM.” Beyond defending the company’s staffing practices, the IBM spokesman declined to respond to Harris’ allegations.
More than Financials
One thing is clear: Running DRMS involved a lot more for IBM than just an Oracle implementation—it meant putting in a network from scratch, including the first deployment of PCs for many Detroit offices. “This was not just a financials project,” says David Natelson, a vice president in state and local applications in Oracle’s government, education and healthcare division, who has been working with the DRMS steering committee as Detroit has been upgrading to the current 11i release of Oracle’s financial software.
The city was using computer equipment from the early ’70s, and the work processes used by its 17,000 employees were slow to change. City departments still relied on a green-screen mainframe system that could capture information but provided no intelligent functions. So changing the financial software meant changing everything from the tools people used to the comfortable routine of doing their jobs. Still, there was a belief DRMS would not require major reengineering.
“We were going to try to adapt an archaic system to modern-day software,” says Harris. “It was like painting over rust.” People ended up working both systems in parallel and generating just as much paper as ever. Says Bentley, “People were resistant to change. They were doing it the old way and the new way at the same time.”
The adjustment to new technology and new ways of doing business led to a huge and costly bottleneck as Detroit struggled to train its workers. Training costs quickly ballooned to as much as five times the anticipated amount, putting DRMS over budget almost from the start. “There was a gigantic training curve,” says Bentley. “We did an assessment and the numbers that came back were staggering. We had to train people on what a mouse was and how to use it. This was not 10 or 20 people, there were hundreds.” Scheduling that amount of training was hard, and people could only learn so much so fast.
Harris says Oracle promised that it could accommodate a particular type of financial accounting used by cities called grants management, even though its software had no module for this kind of municipal accounting. Apparently, that claim wasn’t entirely true then, and it isn’t true now; one of the major remaining shortfalls on the financials side is that DRMS still cannot handle grants accounting.
Oracle’s Natelson counters that charge by pointing out that the public sector represents Oracle’s largest single vertical market, and adding that the company is now implementing a financials package for the city of Chicago. But some of Oracle’s other public-sector jobs have not gone so well, either. Earlier this year, for example, an Oracle project for the state of California was shown to have cost more than twice its $41 million budget. The project was killed last month.
Without commenting specifically on Detroit, Natelson says that public-sector jobs depend on strong leadership and staffing. And a vendor with first-hand knowledge of the project, who insisted on anonymity, made the point more strongly: He said DRMS unraveled because it was run by Detroit’s technology managers, not the financial users who were to be the system’s ultimate beneficiaries. That all adds up to an indictment of Bentley but also of Nicole Fontayne-Mack, Detroit’s former information technology director, who now holds a similar position in Florida’s Broward County.
There is nothing oblique about the criticism Detroit auditor Harris levels at Fontayne-Mack. He recalls that Fontayne-Mack refused to distribute to her staff some proposals for fine-tuning the performance of IBM Global Services that were prepared by consulting firm KPMG. “They didn’t use the information,” Harris complains. “We gave them copies every month but they weren’t distributed. KPMG let Nicole know how IBM was performing, but she did not accept it because it came from me. We would have saved a lot of money by putting IBM’s feet to the fire.”
Fontayne-Mack did not return several calls to her office in Florida. However, Bentley, who left the city for a private-sector position in 1999, defends his former boss, pointing out that KPMG may not have been an impartial critic of IBM, since it, too, bid on the DRMS project.
“We had the full support of [Detroit] Mayor Dennis Archer,” Bentley adds. “We talked at a senior level every two weeks for a year. Executive management was very flexible and understanding as it set the strategy.”
Plenty of Planning
Although the city would overreach considerably with its goals for DRMS, the planning process seemed to be adequate. “We had white papers up the gazoo, and we took advantage of them,” says Bentley. Oracle’s Natelson says Detroit’s request for proposal was comprehensive and was followed by extensive meetings and an in-depth review of vendor plans and vision. The city spent almost $500,000 to draft its proposal and select IBM and Oracle.
Auditor Harris, however, can’t get it out of his head that the city may have been better off giving the contract to KPMG from the beginning. He thinks Detroit’s technologists may have been swayed by the “bleeding-edge” technology IBM promised—as opposed to the mainframe-based solution KPMG was proposing—and by IBM’s superior presentation skills. “They had the best presentation, very snazzy, strictly high-tech,” Harris remembers. “KPMG was just awful—the guy put his microphone down when he spoke to this huge room. They blew it.”
By April 1999 the financial applications were running, although bugs continued to plague the system for months. “We have about 90% of the financials we expected,” says Harris. Detroit has automated its purchasing and accounts-payable functions, two of the areas identified as important priorities in the original planning documents for the project.
“The improvement in the ability to pay vendors on time, get discounts on payment, and so on, adds up to real dollars,” says Natelson.
But the human resources and payroll software is still not in use and may never be implemented. “That was the catalyst to start the project to begin with,” admits Bentley. Oracle’s payroll software may not be up to the job anyway, with dozens of separate collective-bargaining agreements between the city and different unions putting payroll beyond the capability of an off-the-shelf product. In a city where workers have sometimes not been paid on time and have waited years for promotions and raises, the lack of a new system is frustrating.
A phased implementation plan, built around a better understanding of worker abilities and guided by the political will to change work processes, might have given DRMS a chance at achieving most of its goals. Instead, Detroit spent a lot to get a fractional return and a dream deferred.
City of Detroit Base Case
Headquarters: Coleman A. Young Municipal Center, 2 Woodward Ave., Detroit, MI 48226
Phone: (313) 224-3270
Business: Provide city services to population of nation’s seventh-largest city
Top Technology Executive: Dave Rayford, Chief Information Officer
Financials in 2002-2003: $3.7 billion budget
Challenge: Implement Oracle ERP software to bring city financial and human resources software into the late 20th century
Consolidate 43 agencies and 22 systems onto Oracle financial software
Convert 100% of payroll operations to new system
Copyright © 2004 Ziff Davis Media Inc. All Rights Reserved. Originally appearing in Baseline.