A morale booster for failed projects

Soft advice for a software development project

reviewed by Conrad Weisert, December 2001

The framework

Enlightened system development life-cycle (SDLC) methodologies call for a final "Project Review" phase, in order to learn from mistakes and bad decisions and thereby to do better on future projects. In the review phase, the project team assesses:

  1. The performance of the project.
  2. The quality of the end result.

While Norman Kerth strongly supports doing a project review, he approaches it from the point of view of a so-called "retrospective facilitator". Those two words are our first clue that the book is going to be more about the author's own role than about project performance, more about making the project team feel good than about objective evaluation.

Kerth provides a wealth of references to other books and articles, nearly all of them having a similar strong emphasis on the psychological and the political aspects of project management.

A Death March Companion

Parts of this book mesh nicely with Ed Yourdon's terrific Death March book. Kerth emphasizes failed projects, switching terminology in chapter 7 from "retrospective" to "post mortem". Veterans of such projects will particularly appreciate his list of popular techniques for saving face (pp. 178-179).

Kerth's view of project failure, however, will be too narrow for many organizations. We all agree that a project that spends millions of dollars over several years and produces nothing useful is a failure, but so are many projects that ultimately do deliver a working system.

His three fuzzy reasons (p. 173) why big projects fail lack the concreteness that an impatient manager will seek. For example:

Important decisions were made poorly or weren't made at all.

Quantitative measures

It's hard to tell just what the author regards as positive criteria. There are numerous references to the long-discredited lines of code measurement, as well as number of defects and ratios between the two. On the other hand, I found few references either to such crucial measures of project performance as:

or to such measures of end-product quality as:


A retrospective turns out not to be a kind of project review, but rather something you might do in addition to a normal objective project review. It appears most useful for addressing low-morale among the project team participants. If that's what you need, you'll find some helpful guidance here.

Return to book reviews.
Return to Project Management topics
Return to table of contents.

Last modified December 8, 2001