Too Much, Too SoonBy Edward Cone | Posted 2002-08-06 Email Print
Know the Risk: Digital Transformation's Impact on Your Business-Critical Applications REGISTER >
The city of Detroit had a perfectly clear blueprint when it committed $48 million to an Oracle system a few years ago. Then how come it came out like this?
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.