You may think you've completed a software project, but you aren't truly finished until you've conducted a project postmortem.
I heard that Elvis was recently spotted playing Duke Nukem Forever!!!
=P
Some people prefer the slightly less morbid version, the “retrospective”.
What I’ve seen happen historically is that people get in a room, whine, whine, whine and then consider their job done and forget about it.
The challenge is knowing when a project is complete. Unlike a game, which has a clear definition “When we ship”, some projects seem to drag on indefinitely with change orders, etc…
Sometimes we hardly noticed that a project has transitioned into the maintenance phase.
So consider “MidMortems” along with Post-Mortems. These would be “retrospectives” at significant milestones within a long project.
Some people prefer the slightly less morbid version, the “retrospective”.
Yes. Boring people.
C’mon, where’s the excitement in “retrospective”? Don’t you want to bust out a little CSI action instead?
Your blogposts are too interesting. I was just going to sit down and check the mail, and now I’ve been here for an hour, reading, following links and (almost) ordering books.
Shame on you. 
“Some people prefer the slightly less morbid version, the ‘retrospective’.”
We prefer the much more descriptive term “Afterbirth”, because it’s such a bloody mess. 
Or simply use the term process evaluation. I used to do this during projects at uni, in the real world (as Jeff points out) I have yet to see one performed. Indeed, there’s hardly time to polish off and ensure the quality of the project already. A shame really.
Very interesting. I’m sat here on a bright December morning preparing for a post-motem I’ve organized for tomorrow morning and decided to check my bloglines account when I came across your article.
Good stuff (esp. the links)
Cheers
My employer has recently ended post-mortems. The exec in charge thinks they don’t produce useful results. I’m sort of at a loss to respond to this depth of cluelessness.
I said some people, I didn’t say me.
The way many projects go, perhaps autopsy would be a more appropriate name.
Interesting. Perhaps I’m one of the boring people but I don’t much like the word “post mortem.” I guess that’s 'cause the projects I’ve worked on have been successful.
We tend to hold retrospectives, but don’t do them at the end … we hold them after every release (once a month), and they’re short. It’s amazing how much more productive and cohesive (they don’t always go hand-in-hand – sacrificing a little bit of short-term productivity for long-term inter-relational work is a hard sell, but valuable) a team is when it’s continuously reflecting on its successes and failures.
Here’s a book that will help:
http://www.pragmaticprogrammer.com/titles/dlret/
I generally respect most things out of the Pragmatic Programmers, and this one’s no exception. If you reflect on your project more often, and the team has more of a stake in the way they operate, then the project has a better chance of success, in my opinion.
Oh, and I swear, I am not, nor have I ever been, a consultant. In-the-trenches developer/retrospective facilitator here.
“Our goals were too amitious and our timeline too optimistic.”
I’ve never heard anyone say, “it was a bad design or that that any technical decisions were a mistake.”
The only useful feedback seems to have been, “we didn’t reduce dependancies enough.”
I’m a big fan of the postmortem in making me a better developer, but I’m usually a little nervous to have them since I’m usually the lead programmer, and managed most of the project outside the money issues. I’m the only one to get the blame for failures.
It seems like at the end of every project, the final conclusion is always “we should have had a better statement of work”
Seems like I would have that one figured out by now.
Haacked is completely right though. Most of the projects that I’m working on now don’t have a ship date. They just transition into a new phase of the project - be it maintenance or adding features.
I do have those SOWs down though. You bill by the hour, keep track of every little thing you did. If you spent 15 minutes writing an email to explain how to use the system, you can bill for that later. At the end, just send them your spreadsheet of every hour you worked and bill. I love working like that because timelines and scope-creep are no longer issues. Blissful.
any thing about it
The last link is redirecting to the home page 