Big failures teach big lessons

Failures frequently teach us more than do successful projects. 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 again and again is even harder. So failure can be a great opportunity to learn.

One of the greatest learning experiences so far in my career 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. Lesson: 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. Lesson: 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. Lesson: 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. Lesson: Unless teams have clear and non overlapping objectives, they will get in one another's way. The project leader needs to resolve disputes quickly to keep things moving.

After six months of designing, there was increasing pressure to start programming. Even though the design was still incomplete, the design teams had produced hundreds of pages of specifications, and these were handed off to the programming team. That team was overwhelmed by the volume and complexity of the specifications. Lesson: The longer you spend designing a system, the more complex and difficult it will be to build. It's best to design and build smaller pieces in quick, iterative steps.

To cope, the programmers changed the specifications and cut out features they didn't understand. Also, new releases of the system hardware and software kept coming out, so people kept reworking programs to take advantage of new features in the new releases. Almost a year was spent programming and reprogramming. Lesson: System specifications have to be complete and easy to understand. People need to stick to them and not redesign the system while building it; new features can be added in future releases.

When the beta-test version of the system was finally presented, it ran very slowly and crashed constantly. Lesson: After all the high expectations and almost two years spent designing and building the system, this performance seriously damaged the credibility of the whole project.

Programmers scrambled to fix bugs, but support for the system faded. Members of senior management became alarmed at the constantly increasing budget. After another six months, they cancelled the project and wrote off millions of dollars. Lesson: Delivering smaller subsystems every few months is better than trying to deliver the whole system in a few years. Smaller subsystems are easier to debug, and people see they are getting something for their money.

Since then, I've successfully delivered many new systems, and much of my success is due to the lessons learned from that failure.

Michael Hugos is a partner in AgiLinks, a speaker and author of books including Essentials of Supply Chain Management, 2nd Edition (John Wiley & Sons, 2006)

• Bookmark this page
• Share this article
  •  
  • facebook
  • slashdot
  • digg
  • Reddit
  • stumbleupon
  • linkedin
  • twitter
• Got more on this story? Email Computerworld
• Follow Computerworld on twitter

• Share
  Share this article

  •  google+
  • facebookfacebook
  • slashdotslashdot
  • diggdigg
  • RedditReddit
  • stumbleuponstumbleupon
  • linkedinlinkedin
  • twittertwitter
• print
• email
• Bookmark