logo2008

Training


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.

anger 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:

If you always do what you've always done,

you'll always get what you've always gotten.

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...


Intended Audience

The intended audience for this workshop includes Project Managers and Triage Team members, including QA, Development, and Technical Support. Project Teams should attend this training together as a team, if possible. Once a Triage team has been trained, I frequently facilitate the first few Triage Meetings where Root Cause Analysis is involved.


Tailoring

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

Call for details...




For further information,

call Steve Rakitin at 508.529.4282

or e-mail him at steve@swqual.com


Home

Company Info

Contact Info


Food for Thought and Predictable Software Development are trademarks of Software Quality Consulting, Inc.
Copyright ©2008 Software Quality Consulting, Inc. All rights reserved.

Updated January 2008