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 