The Almanac: Project Management

Computerworld - Failing to Learn From IT Mistakes
Examples of corporate IT project failures are well known, from AMR Corp.'s Confirm reservation system to Hershey Foods Corp.'s ERP meltdown. The reasons are well known, too—from technology and financial shortcomings to a lack of end-user and management support. All of this is cataloged in the book Software Development Failures, by Kweku Ewusi-Mensah (MIT Press, 2003).

What's new is the author's examination of a subset of IT failures: abandoned projects. These are IT projects that were partially or completely abandoned before implementation—often in the coding/testing phase. In other words, they got pretty far along before someone figured out that they needed to pull the plug.

What's especially distressing is that IT organizations continue to make the same mistakes on subsequent projects. Most of them conduct post-mortem reviews to identify what went wrong and why, which is good news. But the author's research shows that half of them don't keep records of the lessons learned, and even those that do keep records don't make good use of them for new projects, so they're doomed to repeat past mistakes.

This book recommends a "triangulation strategy" for postabandonment reviews, using questionnaires, structured interviews and archived records to figure out why a project failed. But the most useful question of all may be, "What are the most important things you would point out to your manager or your staff if you joined a similar project in the future?"

Why Wait Until The Project Ends?
As good and important as retrospective project reviews are, they obviously come too late to do any good for an already completed (or abandoned) project. That's where "project introspectives" come in, says Lynne Nix, a senior consultant at Cutter Consortium in Arlington, Mass.

"The project introspective allows the project team to assess what is and is not working and to make midcourse corrections," Nix wrote in a recent bulletin. The goal is to revisit the original assumptions about features, resources and schedules, which undoubtedly have changed now that you have some real-world experience.