I've conducted some "Lessons Learned" sessions in the past. Some have been very useful, some less so.
When I've written Lessons Learned documents in the past, the purpose was to compile feedback from the entire project team regarding what worked well, and what didn't, and pass that information along to all the relevant parties. It was a learning exercise - intended to help us grow as a team.
Generally, I'd call a meeting in a large conference room and invite pretty much everyone who participated in the release - Managers, Developers, QAers, Product Managers, Documentation, Support, etc, etc.
I would "host" the meeting, and try to act as a facilitator. I'd ask a few simple questions to keep the ideas flowing, ask for clarification when needed, try to keep people on track, and note all the responses.
When the meeting was over, I'd gather and organize all the thoughts. copyrightjoestrazzere
For me, I usually just had two main categories - What Worked Well, and What Didn't Work Well.
Underneath each, I'd try to group similar feedback into project-specific categories, such as "Build Process", "Documentation", "Meetings", etc, etc.
We usually learned a few things. Often (not always) we learned things we could actually change for the better.
BTW - Unless someone actually died, I prefer not to call such a meeting/document a "Post Mortem".
