CHI-WEB Archives

ACM SIGCHI WWW Human Factors (Open Discussion)

CHI-WEB@LISTSERV.ACM.ORG

Options: Use Forum View

Use Monospaced Font
Show Text Part by Default
Show All Mail Headers

Message: [<< First] [< Prev] [Next >] [Last >>]
Topic: [<< First] [< Prev] [Next >] [Last >>]
Author: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Subject:
From:
Tim Salam <[log in to unmask]>
Reply To:
Tim Salam <[log in to unmask]>
Date:
Tue, 9 Jul 2002 10:57:41 -0700
Content-Type:
text/plain
Parts/Attachments:
text/plain (173 lines)
Here is a summary of the repsonses I received based on the following request
I sent:

"A former associate of mine is in search of the following:

"I have been asked to lead a post mortem committee on a project gone bad -
does anyone have framework for something like this? Review points,
identifying critical points that failed and can be improved, etc.?"

If anyone has such information, please send to me and I'll forward."

-------------Responses Follows------------------
From: Thomas Donehower - [log in to unmask]
I've used the "Project Post-Mortem" template in PowerPoint. Just click "New"
and then look under the "Presentations" template. It's pretty comprehensive.
While it's not specific to "projects gone bad" it should still cover the
important points. You might also be able to find something at  Ganthead.com



From: Scott Berkun - [log in to unmask]
I've done many of these, but don't know of many public references (I've seen
very elaborate software engineering postmortem guides, but I don't recall
them being applicable to what I was doing). Debugging the software
development process, By Steve Maguire, has some good tips, but it's not a
complete reference.

My take on this process is to keep it informal, and invest mostly in the
person who's going to drive the postmortem, rather than in some elaborate
process or sequence of steps.

I think the basics come down to 3 things:

1) You have to facilitate the process. Someone has to go and interview,
1-on-1, a representative group of people across the team. This should
include different levels of management as well as different disciplines.
Sometimes partner teams or companies should also contribute to the
postmortem. Whoever drives the process should define a framework for the
interviews (easiest one: refer back to the project goals, and key
milestones, and lead a discussion on how well those goals were met or
approached). Filter that data into a list of issues, and order it by
severity. Sometimes it works best to have two lists:  what went well, what
sucked. The facilitator has to be someone that is seen as objective, and who
is agile enough to talk to people in different level of the organization.
They also have to deal with confidential
information, since typically, postmortems bring up lots of details about
interpersonal relationships or cross team issues that will only be shared
with the facilitator if they will anonymized or protected in some other way.

2) Make it actionable: Avoid making it a documentary. While it is important
to confirm for people on the team that certain things were and were not done
well, that shouldn't be where it ends. Instead build on that foundation and
provide a path towards doing something better next time. The postmortem
should have suggested or implied changes that should be considered for the
next project. Minimally, there should be an owner for each issue that needs
to be addressed for the next release, and a date by which they will report
back to the team. Sometimes, it's the facilitator of the postmortem that
gets this task - other times, it's distributed across the team, or to
management. Either way, there should be names, and dates. Set a meeting 6
weeks out for those folks to present what's being done on their issue.

3) The output should be short and concise: Usually there are big piles of
information generated. Someone should distill it down into a 2 or 3 page
document. What the top 5 issues were, what the prime causes were, and what
will be done about them for next time.  This is all anyone is likely to
read, and if the facilitator is so inclined, they can provide access to more
detailed information. (Typically filtered for names or
job descriptions to protect those that contributed). Often a
presentation to the team, summarizing the postmortem, is more effective than
any written doc. Team leaders should be there, and if you've done #2, the
discussion will lean towards progress, rather than harping or complaining
about the past.

Lastly: Some have told me that a more positive name for the process is
postpartum - since usually what was made lives on, rather than postmortem,
which implies that what was made, has died :)




From: Samantha Bailey - [log in to unmask]
I've routinely done project debriefs on most all the projects I've worked
on.

Generally if the project has gone more or less smoothly, I'll simply gather
the key folks from the project in a room and do some informal affinity
modeling as follows: give everyone a stack of postits and ask them to write
down all the "successes" and "deltas" (things to change/improve/do better
next time). Then group them, putting the like components together so that
people can see where there is agreement and disagreement in the group as to
what was successful and what wasn't in the course of the project.

On projects that haven't gone as smoothly I've often done more mediated
dialogues about the process.

As a project manager, I also always reviewed the  timeline/deadline
successes and failures and the budget or profit/loss statement. I've
attached a flow chart that we used as part of our project lifecycle at Argus
and the
analysis instructions I developed for our operations group (ed. note: email
Samantha for attachments).




From: Simon Wistow - [log in to unmask]
I'm a games programmer and so these are probably more interesting for me
than for a lot of people but ...

http://www.gamasutra.com/php-bin/article_display.php?category=5

You may have to log in but the ubiquitous backdoor cipherpunk/cipherpunk
works :)




From: Richard Weigel - [log in to unmask]
IEEE Software, July 1996
"A Defined Process for Project Postmortem Review"
by Bonnie Collier, Tom Demarco and Peter Fearey

Their website has other resources as well.




From: Chris Johnson - [log in to unmask]
Yep - there is a whole industry doing this.   It's based around `lessons
learned' systems and goes from incident and accident reporting through to
more conventional process improvement techniques.   I deal mostly in the
safety critical end - if you want to see an example of the sorts of
techniques there post mortems use then there is some work I did with NASA on
their Mars Surveyor failures at:

www.dcs.gla.ac.uk/~johnson/Mars




From: Gray Taylor Miller - [log in to unmask]
I would recommend the book "Web Redesign:  Workflow that Works" by Kelly
Goto & Emily Cotler.  While not specifically post-mortem, they have many
process outlines and critique points that I think could be applied to a
post-mortem.


---------end of responses-------------

Thanks to everyone who responded!

Tim Salam
Vice President
Essemble IT Solutions
http://www.essemble.com
+1 480-332-5521 voice
+1 602-795-8622 fax

Tim Salam
Vice President
Essemble IT Solutions
http://www.essemble.com
+1 480-332-5521 voice
+1 602-795-8622 fax

    --------------------------------------------------------------
        Tip of the Day: Forward out-of-office replies to
                    mailto:[log in to unmask]
     CHI-WEB: www.sigchi.org/web POSTINGS: mailto:[log in to unmask]
              MODERATORS: mailto:[log in to unmask]
       SUBSCRIPTION CHANGES & FAQ:  www.sigchi.org/web/faq.html
    --------------------------------------------------------------

ATOM RSS1 RSS2