A project from hell

We've all had projects of some sort that we've been involved in which didn't turn out all that well, and many of us on have worked on Death Marches (with mixed results). David Isen linked to a middenheap blog entry which terminates at AT&T Wireless Self-Destructs, a CIO Magazine article which examines the cutover of an AT&T Wireless CRM system, the mis-management that surrounded the cutover and some of resulting damage. It's news worthy for a lot more than the out sourcing angle, but that just helped to make it worse.

Among the failures was a lack of vision on the part of the original Siebel CRM migration group. A plan for tomorrow wasn't part of the deal (then again, they might not have been allowed that freedom). As a company with a big investment, AT&T should have realized that it could go either way and planned for it. Everything was a giant hack without regard for where the future might lie (the common deadly middleware assumption... its middleware, so we'll just whip up something there and hide the extension cords).

That initial failure lead to the massive teams needed for integration when Siebel 7 rolled around... there were no abstraction services available to talk to. It's a sad reality that as a group of systems expands and matures, the interfaces fray with remarkable speed. We really suck at creating long term, extensible APIs that allow systems to grow independently of one another.

They also followed the typical performance upgrade boogie man without ever doing any testing to verify vendor claims. Although everyone wasn't specifically outsourced, much of the infrastructure was implemented via one vendor layer on top of another. When things finally went wrong, no one could explain it.

Toss in downsizing, outsourcing and numerous other negative morale factors and you have a pretty good recipe for disaster...