Buy, borrow or steal, but in any case read Norm Kerth's book "Project Retrospectives".

A retrospective is a facilitated meeting. The facilitator has responsibility for the logistics of the meeting (preparing the agenda, communicating it to participants, etc.) but also for ensuring that the meeting's structure makes it safe for all participants to voice their contributions.

Failure to do so is quite simply a waste of some participants' time, and the time of knowledge workers is a very expensive thing to waste.

It is quite possible to construct retrospectives which elicit contributions from all involved, even when including developers, PMs, QA folks and product sponsors; I've done so on many occasions. But it can only happen by design, not by lucky accident.

Sticker Notes! Not everyone is comfortable speaking, but most will be willing to write a few words on a sticky pad and place it somewhere on the wall. You usually want to find out what worked, what didn't work and than determine how to improve (but most importantly identify the good and bad first). Combine this with some ad-lib type of tension breaking game and you'll get more participation. Most projects (even successful ones) end up with some tension between teams and/or people that need to be released during the post project meetings...provide food, make interaction open and not focused on individuals and toss in a simple game or something (like pumpkin decoration around Oct)....the results you receive along with the 'decompression' will help the next project immeasurably

In addition to what others have said, bring food to the lessons learned meeting.

Seriously, getting people to the session isn't the hard part. The hard part is truly learning from the past mistakes and convincing people that effort will be applied to make things better. I've been to many lessons learned sessions and some of the best recommendations were not followed in future projects, including the big one: Don't set an arbitrary project deadline before doing some legitimate analysis.

The best way to over come this is to inject it into the culture of the organisation, where in people update the lessons learned document on a regular basis. This will help people to capture more details else as days pass by details and clarity is lost.

PM need to be allocated to the completd project until all the lessons learned and other closure activities are performed completely.

Inorder to encourage more people to attend retrospectives, it is better to schedule the project completion celebrations during the same evening as this event.

Admittedly and unfortunately I've never seen it work. In small companies I've been in, we can recognize problems and fix them right away, so formal lessons learned meetings are not needed. In large corporations you need support of a largely immovable PMO to make changes to process, plus the next project comes along so quickly (already late) that you don't have time to turn your lessons learned into useful actions.

One thing touched on by most of the answers but I don't think stated clearly enough: the importance of the retrospective is not simply to properly document the lessons learned, but to actively modify the company processes and policies that you learned the lessons about.

To get people more involved, you would have to establish a reputation for changing the next project by incorporating lessons from the last project. It doesn't matter if its a process thing (e.g. our scope is never crystal clear when the project is kicked off, so we need an alternative to our current waterfall methodology") or a technical thing (e.g. "our web-app uses too many client-side libraries so we should standardize on one"); if you document the problem, decide on the lesson learned and then make a change so that the next project is better, then surely future retrospectives will have people clamoring to participate.

1. Have a meeting where one person is in charge of recording people's opinions without attribution i.e. without "John said x and Alex said y..."
2. Have the meeting right when the project is completed so people will have a lot of emotions related to it.
3. Don't publish the results for at least 2 days so you can weed out the emotion but keep the ideas. Make sure you tell people this.
4. Show people that they can speak freely without fear of retribution or consequences by not punishing people based on what they say in the retrospective meeting.
5. Have separate retrospectives for the a. internal team and b. for the account managers and clients.
6. Reward people with cash for keep ideas that come out of retrospectives and that turn into process improvements.

Here is a link to a related conversation/question on this site.

As far as not participating goes, there is a nice little psychological trick in the book Agile Retrospective by Esther Derby & Diana Larsen. Which suggests starting a retrospective by getting everyone to answer in one or two words, a simple question at the start of the iteration. The idea being that by having everyone answer it means they no longer have implicit permission to stay silent.

If they are copying, break them into small groups of 2-3 people..

The tough thing about retrospective is people often feel they are 'hokey' and 'american' (at least here in the UK).. getting them comfortable with being honest and open can take time, trust and the right motivation. It's the SM's job to facilitate these session and find whta works for the group. The best advice I can give, is ask the group what works for them, then experiment..

You get them involved by creating an environment where the team members feel safe in critiquing the Project Manager. The PM has to make it clear that they are open to hearing about what they could have done better or differently. And this has to be made clear from the BEGINNING of the project, and carried through to the end. And it has to be genuine. The PM has to genuinely want to know the answers, even if unpleasant. The team will be able to spot the insincerity.

If the team members feel that they are being asked to participate because the PM really wants to know how to improve either their performance or the process, then they will participate. But if they feel that nothing will come of it but bad feelings and ignored suggestions, then there's no incentive for them.

Solicit feedback throughout the project. And start the lessons learned re-cap by first pointing out where you see yourself needing improvement.

Only stakeholders actually care.

Who's the stakeholder in project management? Project managers.

The technical folks have already learned and shared their technical lessons. That's what a software development project is: Learning.

The users don't care about the project, only the final product.

Who's left to learn lessons? Project managers.

Of course no one else participates -- they have nothing to gain.

The problem I experience over and over is that the lessons-learned discussion start at the very end of the project when a) people are already working full-steam on other projects, b) problems and lessons-learned are sometimes already forgotten (months have passed)!

I think these two reasons explain why most people do not get involve in lessons-learned / retros.

I agree with Trevor K Nelson. Opening the "lessons-learned" discussion during the project seem to tackle these problems. Have a place where to log lessons-learned items and start the discussions already while the project is going on, and while everyone has a fresh view of the difficulties.