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.
5. Is there value in letting the organization as a whole know how decisions are made and the rationale for killing projects and the reasons for failures?
Yes, in organizations that foster a culture of honest inquiry; no, when the principle follow-up to anything other than success is identifying the most likely scapegoats. As I've mentioned, the point goes beyond changes to procedure -- the point is improved understanding of How Things Work Around Here. Everyone benefits from knowing the answer to that question.
6. Do real organizations actually allow this kind of scrutiny and real accountability to happen?
Some yes, most no, although "accountability" is a red-flag word in this context. Organizations that make use of phrases like "We hold people accountable" are the ones that have turned blamestorming into a core competency. The scrutiny should be about what went wrong and what about the system allowed it to go wrong, not about who made a mistake and what the consequence should be.