|
Server : Apache/2.4.62 System : FreeBSD fbsdweb2.web.rcn.net 14.1-RELEASE FreeBSD 14.1-RELEASE releng/14.1-n267679-10e31f0946d8 GENERIC amd64 User : www ( 80) PHP Version : 8.3.8 Disable Function : NONE Directory : /domains/srakitin/OLD/training/ |
Upload File : |
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">
<HTML>
<HEAD>
<TITLE>Project Retrospectives</TITLE>
</HEAD>
<BODY>
<body bgcolor="#FFFFFF">
<!--- Logo and Page Title ---->
<p align="center">
<img src="../gif/logo2008.gif" width=348 height=64 border=0 alt="logo2008">
</p>
<p align="center">
<font color=black size=5 face=Verdana>
<b>Training</b> </font>
</p>
<p align="center">
<img src="../gif/topline.gif" width=915 height=6 border=0>
<br>
<font color="purple" size="3" face="Verdana">
<p align="center"><b>Project Retrospectives</b>
<p align="center"><b>A Kinder, Gentler, More Productive Way to Learn from Past Mistakes</b>
</font>
<br></p>
<center>
<table width=550>
<tr align=left>
<font size="2" face="Verdana">
<p> Most every organization, at one time or another, has experienced the pain of a Project Post-
Mortem. The story goes something like this:
<p>
</tr>
</table>
<table width=500>
<tr align=left>
<td>
<font size="2" face="Verdana">
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.
<p>
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.
<p>
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.
<p>
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.
</td>
</tr>
</table>
<table width=500>
<tr align=left>
<td width=30%>
<img src="../gif/anger.jpg" width=145 height=100 border=0 align="left" alt="anger">
</td>
<td width=70%>
<font size="2" face="Verdana">
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.
<p>
On the next project, the same mistakes were made again.
<p>
</td>
</tr>
</table>
<table width=500>
<tr align=left>
<td>
<font size="2" face="Verdana">
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.
<p>
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.
<p>
Here then is the first thing to learn about project post-mortems:
<p><p>
<font size="3" face="Verdana" color="red">
<b>
<center>If you always do what you've always done,<br><p>
you'll always get what you've always gotten.</center></b>
</font><p>
<font size="2" face="Verdana" color="Black">
Thankfully, there is a better way. </font>
</td>
</tr>
</table>
<p>
<table width=500>
<tr align=left>
<td>
<font size="2" face="Verdana">
<b>Project Retrospectives�</b>
<p>
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.
<p>
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.
<p>
Project Retrospectives on the other hand, are "events". Here are some key attributes:
</font>
</td>
</tr>
</table>
<p>
<table width=500>
<tr align=left>
<td width=70%>
<ul>
<font size="2" face="Verdana">
<li>They are planned<p>
<li>People come prepared - <a href="http://www.swqual.com/newsletter/Retrospective.pdf">
learn how to prepare�</a> <p>
<li>An experienced facilitator plans the event and leads the discussion <p>
<li>Retrospectives typically take 2 -3 days (yes, days)<p>
</font>
</ul>
</td>
<td width=30%>
<img src="../gif/ProjectRetrospectivesCover.jpg" width=100 height=152 border=0 align="right">
</td>
</tr>
</table>
<table width=550>
<tr align=left>
<td>
<font size="2" face="Verdana">
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. </font>
</td>
</tr>
</table>
<table width=550>
<tr align=left>
<td>
<font size="2" face="Verdana">
This workshop is based on Norm Kerth's book <u>Project Retrospectives � A Handbook for Team
Reviews</u>, Dorset House. The workshop includes discussions of the key exercises identified by
Norm Kerth in his book... </font>
</td>
</tr>
</table>
</center>
<p>
<br>
<center>
<table width=600>
<tr>
<td>
<p><p>
<font size=3 face=Verdana Color=Red>
<b>Intended Audience</b></font>
<p>
<font size=2 face="Verdana" color=Black>
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.
</td>
</tr>
</table>
<br>
<table width=600>
<tr>
<td>
<font size=3 face="Verdana" color=Red>
<b>Tailoring</b>
<p>
</td>
</tr>
<tr>
<td width=20%>
<img src="../gif/tailor.JPG" width=101 height=97 hspace=0 vspace=0 border=0
align="center" alt="tailor">
</td>
<td width=80%>
<font size=2 face=Verdana font color=black>
This workshop can be tailored to meet your specific project needs and development process.
<p>Call for details...
</TD>
</tr>
</TABLE>
</center>
<!--- bottom line -->
<br>
<p align="center">
<img src="../gif/bottomline.gif" width=915 height=6 border=0>
<br>
<!--- Contact Message -->
<center>
<br>
<p align="center">
<font size="3" color=Black face="Arial">
<b>For further information,
<p>call Steve Rakitin at <font size="3" color=Red face="Arial">508.529.4282</font>
<p><font size="3" color=Black face="Arial">or e-mail him at
<a href="mailto:[email protected]"><b>[email protected]</a></b><p><br>
<!--- Bottom Row of Links -->
<center>
<TABLE BORDER=0 WIDTH=375>
<TR>
<TD VALIGN="TOP" >
<FONT FACE="Verdana" color=black SIZE=1>
<a href="../index.html"><b>Home</b></FONT></a></p>
</TD>
<TD VALIGN="TOP" >
<FONT FACE="Verdana" color=black SIZE=1>
<A HREF="/company/summary.html">
<P ALIGN="CENTER"><b>Company Info</b></FONT></a>
</TD>
<TD VALIGN="TOP" >
<FONT FACE="Verdana" color=black SIZE=1>
<A HREF="/company/contact.html">
<P ALIGN="CENTER"><b>Contact Info</b></FONT></a>
</TD>
</TR>
</TABLE>
</center>
<br>
<!-- Copyright -->
<p align="center"><font size="1" color=black face="Arial">
Food for Thought and Predictable Software Development are trademarks of Software Quality Consulting, Inc.<br>
Copyright �2008 Software Quality Consulting, Inc. All rights reserved.<br>
<p>
Updated September 2008</font></p>
</body>
</html>