Premortem is one of those common sense tools, that as soon as you understand what it is, the response is generally, "but, of course", and while it sounds a bit morbid, it is definitely useful.  Premortem, to put it simply, is the act of assuming the project is dead (before that awful event occurs) and them determining what killed it, all prior to execution.

The failure rate of projects is high, unseemly so, and one of the key reasons is that people are often reluctant to share their concerns.  So in a premortem, the leader gathers the team, and announces the unthinkable - the project has fail miserably, and they must determine the plausible reasons for why the project "failed".  This sort of thinking, called "prospective hindsight"  - imaging that an event has already occurred increases the opportunity of correctly identify reasons for future outcomes by a whopping 30%.

The leader starts the exercise by informing everyone that the project has failed spectacularly. Next, everyone takes a few minutes to write down every reason they can think of for the failure—every off the wall idea is encouraged, no holding back for PC reasons, just a dump of ideas.  Some examples include lack of support with the sponsor retires, another identified failure when the government agency revised its politics as a result of a resent election.

Next the leader asks each team member, starting with the project manager, to read one reason from her list; everyone states a different reason until all suggestions are recorded. After the session is over, the project manager reviews the list, looking for ways to strengthen the risk management plan.

Examples included:

In a session regarding a project to make state-of-the-art computer algorithms available to military air-campaign planners, a team member who had been silent during the previous lengthy kickoff meeting volunteered that one of the algorithms wouldn’t easily fit on certain laptop computers used in the field. Accordingly, the software would take hours to run when users needed quick results. Unless the team could find a workaround, he argued, the project was impractical. It turned out that the algorithm developers had already created a powerful shortcut, which they had not mentioned. Their shortcut was substituted, and the project went on to be highly successful.

In a session assessing a research project in a different organization, a senior executive suggested that the project’s “failure” occurred because insufficient time had been given to prepare a business case prior to an upcoming corporate review of project initiatives. During the entire 90-minute kickoff meeting, no one had even mentioned any time constraints. The project manager quickly revised the plan to include the corporate decision cycle.

While most project teams engage in preparatory risk analysis, the prospective hindsight approach offers superior benefits in that it doesn’t just help teams to identify potential problems early on, it also reduces the "full speed ahead" attitude of an emotionally invested team.

Guy Kawasaki also mentions premortems in his book Enchantment, where he identifies six benefits of this approach, which I agree with, but I'd suggest a seventh be added.

1. Identification of a problem in advance, rather than after they occur
2. Reduction of the likelihood of premature embarkation
3. More creative and organized approaches to the challenges faced by the teams
4. Heightened sensitivity to early warning signs
5. Participation by more team members because of the less political environment
6. Team members feel valued for their intelligence and experience, and others learn from them
7. Greater acceptance of the project as the nay sayers have had the opportunity to voice their objections - lack of buy-in can be a risk in itself.

I've used this approach and found it valuable.  An example involved an enterprise system integration, and I supported the change management efforts. I noticed the project team lacked motivation, morale was bad and after interviewing several key members, I met with the Sponsor to say the project could not go live on the target date. The project team had been pulled in multiple directions and were not happy with the product they received from the vendor and equally reluctant to voice their concerns, hence their low morale. They were braced for failure, not ready for success.

At the pre-moreturm, I asked what could cause us to fail in a variety of ways, the answers from the team gave insights into the concerns they were reluctant to voice.  The project manager took the results back, revised the schedule with the vendor, updated the risk mitigation strategy and secured resources for the duration, a commitment to them was something he did not previously have. The release on the new date went off without a hitch.