Let me start off by saying I prefer using the term Retrospective rather than Post-mortem. The latter is too negative and implies the project is dead and we're looking to find the cause of death.
You'd usually like to get out of a retrospective session with a list of lessons learned containing changes to existing processes as well as things that went well and that you'd like to maintain and nurture in the existing processes going forward.
I like to prepare for the retrospective by defining a short list of items the team would like to analyze and discuss. This involves sending out in advance a request to the team for topics for discussion. You should review the topics and choose the ones that are more frequently raised. Publish the final prioritized list of topics ahead of the session so people can come prepared with facts, opinions and suggestions.
The session itself
It's important to set some ground rules for the session itself. You should maintain a positive atmosphere and avoid finger pointing. The main focus is to come up with lessons learned and optimizations for the processes rather than finding who's to blame for whatever happened in the project.
When analyzing a topic, first get to an agreement on the facts, i.e. what really happened. You'll soon find out that different people remember different things (and also percept the reality in a different way). Once you have the facts straight, analyze what was good about it and what can be improved. Put focus on the process rather on a specific example or incident. Then you should try to generalize the analyzed scenario and try to figure out what changes can be introduced to the existing processes to deal with situations like the one you're analyzing.
After the session
It's important to send out the list of insights, decisions, and lessons learned after the session is over. It's even more important to take action and actually adapt your processes according to the lessons learned. This way the team will soon learn that the retrospective is really a great tool and a means for them to affect the processes. If you're working in an Agile environment, the retrospective is something you're doing regularly. I found out that when we adapt our processes as a result of good retrospective sessions, in the subsequent retrospectives the team is much more engaged and people come up with really good ideas for improvements.