Training header

back to Training for the Mission-Critical Projects

Project Retrospectives

A Kinder, Gentler, More Productive Way to Learn from Past Mistakes

Most every organization, at one time or another, has experienced the pain of a Project post-mortem. The story goes something like this:

From the beginning, the Project Team knew that not only was the schedule unrealistic, but the requirements were ill-defined, the resources were far less than what was needed, and commitments were being made to key customers without consulting R&D.

Everyone worked as hard as they could on the project, often spending 60-80 hours per week. In the end, the product was eventually delivered several months later than planned, had fewer features than were promised, and had far too many bugs.

Customers were not happy with what they received since it was months late, didn't have all the promised features, and crashed or locked up frequently.

Management asked for a post-mortem to review what had happened. The Project Manager scheduled a meeting about a month after the software was released. People were given the usual short notice that this was happening.

At the post-mortem, the Project Manager tried to control the discussion by asking for examples of things that worked well and things that didn't work well. After about a half-hour of tense discussion, the blaming and finger pointing started. QA blamed Development for being 6 weeks late and for delivering buggy code. Development blamed Project Management for not spending enough time clarifying requirements up front and for allowing requirements to change right up to the last weeks of the project. By the end of the meeting, everyone was angry and nothing of value was recorded.

On the next project, the same mistakes were made again.

This "story" unfortunately happens far too often. Often, when post-mortems are held, people tend to either say very little or not show up. As a result, nothing is learned and nothing changes.

The term "post-mortem" has some negative connotations to it. People have come to expect that "post-mortems" are nothing more than forums for exacting retribution and venting frustration. In terms of return on investment (ROI), "post-mortems" usually rank low since little of value is learned. While Management may be satisfied that a post-mortem was held, the organization continues to make the same mistakes on the next project because nothing was learned and nothing was changed.

Here then is the first thing to learn about project post-mortems:


Thankfully, there is a better way.

Project Retrospectives

The better way is called Project Retrospectives and was developed and refined by Norman Kerth. Norm developed a much more effective way to glean "wisdom" from projects.

Post-mortems are meetings that typically occur with no planning, no preparation, are led by a project team member who may or may not have good facilitation skills, and may take only a few hours at most."

Project Retrospectives on the other hand, are "events." Here are some key attributes:

  • They are planned
  • People come prepared—learn how to prepareā€¦
  • An experienced facilitator plans the event and leads the discussion
  • Retrospectives typically take 2 -3 days (yes, days)

By making an investment in learning from the past, organizations can significantly reduce the likelihood that they will repeat the same mistakes on the next project.

This workshop is based on Norm Kerth's book Project Retrospectives—A Handbook for Team Reviews, Dorset House. The workshop includes discussions of the key exercises identified by Norm Kerth in his book.


This workshop can be tailored to meet your specific project needs and development process.

Project Retrospectives