Lessons learned from a major failure

21.08.2006
I sometimes learn more from failure than success. When I succeed, it just confirms what I already know -- I'm a genius. When I fail, I have an opportunity to learn, if I can bring myself to take an objective look at what happened. This is hard, but then making the same mistakes over again is even harder. So failure can be a great opportunity to learn.

One of the greatest learning experiences in my career so far happened about 10 years ago. I was a team leader on a systems development project that turned into a multimillion-dollar debacle. It drove home some lessons I hope I never forget. Here's what happened (and what I learned from my experiences on that project.)

The project started out with great fanfare and high expectations. There were no clearly defined goals or performance objectives, but the system was basically supposed to empower the company's sales force to grow revenue by another billion dollars or so. (Be wary of wild enthusiasm and vaguely stated goals. The bandwagon effect can make otherwise sane people do goofy things.)

We spent six months investigating technology and dreaming up all sorts of ideas. Then we put together a slide show and a small demonstration of some of the technology. Senior management liked it and approved major funding into the project. (Coming up with lots of ideas and getting lots of money commits you to meeting unrealistic expectations. You should manage expectations by focusing on only a few ideas and asking for less money.)

There were four teams. Three of them created design specifications, and the fourth team did programming and put together the hardware and software selected for the system. We were all supposed to work together, so there was no single person in charge of the entire project. (Management by committee doesn't really work. Unless there is a single leader in charge of a project, confusion will reign.)

As things progressed, design teams began to duplicate one another's work. Features were specified for one part of the system that overlapped with features another team was creating in its part of the system. Confusion grew; arguments ensued; feelings got hurt. (Unless teams have clear and nonoverlapping objectives, they will get in one another's way. The project leader needs to resolve disputes quickly to keep things moving.)