Industry
Internet Service Provision
Customer Relationship Manglement
CIO Magazine has a brief article on the failure of a Siebel upgrade at AT&T Wireless (AWE). [AT&T Wireless Self-Destructs, CIO Magazine, April 15, 2004] It is not directly helpful, so I have some more pertinent observations, based on what little data is in the article.
There were three kinds of failures, each aggravating the others.
Morale: Reduce Stress
The article directly addresses morale problems, and attributes them to a lack of job security because of direct evidence that AWE was planning a resource action: outsourcing to India. That's one part of it. Many aspects of the work environment will contribute to a lack of morale, but improving it is mostly a matter of stress reduction. Inflexible deadlines increase stress. And the staff aren't stupid: they can see that there is no contingency plan. This too increases stress. Add management chair shuffling and outsourcing rumors are just the straw which broke morale's back.
Communication: Empty Those Silos
Lines of communication among staff, between staff and consultants, between vendors (TSI and NeuStar) and the industry (WICIS) broke down — if they even existed at all.
"Everything was siloed among the different groups, and we all worked independently of each other," says a project team member.
Communication problems, which is essentially what integration problems are, were addressed by throwing more man-months at them.
The back-end systems-integration work was so complex that it wasn't unusual to see teams of 20 or more people assigned to write connections for a single system, says a former employee. Coordination between the teams-the responsibility of the lead integrator on the project, Deloitte and Touche-quickly got out of hand.
Technique: Limit Externalities
But the project was set up to fail by it's technical practices. It would have succeeded only if morale were high and communication excellent.
First, the decision to use a commercial product, particularly one which required extensive customization, limited AWE's ability to address problems. Extensive customization is always a problem in upgrades: you are merging two branches of a code fork. If a problem were found in Siebel's software, would Siebel be able to fix it? Would AWE be able to work around around it effectively? This is not to say that all commercial CRM products are lousy — an allowance I make only because of Rick Klau — but that if you need to customize the product that much, you need control of the source code.
Technique: Continuous Integration
Secondly, the environment was not stable. Too many cooks were in the kitchen, adding too many pieces of baling wire and duct tape to the batter. The mix was in constant flux, so tests were unable to identify failures.
Teams would work on a revision to their piece of Odyssey, for example, only to find that when they finished testing, code had changed elsewhere in the system, rendering the testing meaningless.
Later, after successive failures,
Deloitte and Touche project managers relaxed testing requirements for various pieces of the system. Rather than freeze the code for the system once problems began, teams continued to add new pieces to the project in an attempt to get it all working. But the new pieces simply added more errors to an already bug-ridden system, which complicated the process of finding root problems and fixing them.
Testing, whether for code functionality or for performance, needs predictability.
- It worked.
- Now it doesn't.
- What changed?
No one knows. They don't integrate often. They don't talk outside of their silos. They're under immense pressure. Maybe this will fix it.
And so the project spirals downward into oblivion.
12:31:58 PM # Google It!
categories: Industry