Too Much, Too Soon

By Edward Cone  |  Posted 2002-08-06 Print this article Print

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.

Senior Writer and author of the Know It All blog

Ed Cone has worked as a contributing editor at Wired, a staff writer at Forbes, a senior writer for Ziff Davis with Baseline and Interactive Week, and as a freelancer based in Paris and then North Carolina for a wide variety of magazines and papers including the International Herald Tribune, Texas Monthly, and Playboy. He writes an opinion column in his hometown paper, the Greensboro News & Record, and publishes the semi-popular EdCone.com weblog. He lives in North Carolina with his wife, Lisa, two kids, and a dog.

Submit a Comment

Loading Comments...
eWeek eWeek

Have the latest technology news and resources emailed to you everyday.