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