Dear Bob ...
I like the idea of doing postmortems, which you discussed in a recent Keep the Joint Running. Learning from mistakes or even just from events and observations can't be a bad thing. I have a few questions for you about them, if you don't mind.
- Not Quite Dead
Dear NQD ...
I don't mind a bit. Here are your questions, with my answers following.
1. Who should be involved in doing a postmortem?
It should be the project manager, core and extended team, business sponsor, and possibly other major stakeholders if they had significant involvement.
2. What is the appropriate level of resources to spend on doing a postmortem?
Same answer as above; the meeting should last no more than an hour. The PM should be the one to document the results.
3. On what kinds of projects/efforts should postmortems be done? Failures only? Successful projects (postvivum?), killed projects?
All, at least until success is so routine that the organization has reached the point of diminishing returns.
4. To whom should the results be communicated?
It depends on how the company has organized its PMs. If there's a formal PMO, communicate the results to it. It should have a well-established mechanism for updating the company's PMs on new lessons learned and modifications to company standard practice.
Or someone in the company is almost certainly an informal focal point of project management practices (the CIO, head of app dev, and head of organizational development are possibilities). Whoever that is should maintain a distribution list consisting of everyone who has ever managed a formal project in the company. The documentation should then be sent to that list.
If neither of these is the case, the PM should send the results to everyone he/she thinks might be interested -- there's almost certainly an informal network of PM-like employees who know who each other are and help each other out.