The Project Postmortem

You may think you've completed a software project, but you aren't truly finished until you've conducted a project postmortem.


This is a companion discussion topic for the original blog entry at: http://www.codinghorror.com/blog/2006/11/the-project-postmortem.html

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

ā€œ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. :smiley:

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

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. :slight_smile: 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 :confused:

1 Like

My Project Postmortems tend to be: ā€œI should have started this sooner.ā€

2 Likes