Performing a Project Premortem

In a premortem, team members assume that the project they are planning has just failed—as so many do—and then generate plausible reasons for its demise. Those with reservations may speak freely at the outset, so that the project can be improved rather than autopsied.

Projects fail at a spectacular rate. One reason is that too many people are reluctant to speak up about their reservations during the all-important planning phase. By making it safe for dissenters who are knowledgeable about the undertaking and worried about its weaknesses to speak up, you can improve a project’s chances of success.

Research conducted in 1989 by Deborah J. Mitchell, of the Wharton School; Jay Russo, of Cornell; and Nancy Pennington, of the University of Colorado, found that prospective hindsight—imagining that an event has already occurred—increases the ability to correctly identify reasons for future outcomes by 30%. We have used prospective hindsight to devise a method called a premortem, which helps project teams identify risks at the outset.

A premortem is the hypothetical opposite of a postmortem. A postmortem in a medical setting allows health professionals and the family to learn what caused a patient’s death. Everyone benefits except, of course, the patient. A premortem in a business setting comes at the beginning of a project rather than the end, so that the project can be improved rather than autopsied. Unlike a typical critiquing session, in which project team members are asked what might go wrong, the premortem operates on the assumption that the “patient” has died, and so asks what did go wrong. The team members’ task is to generate plausible reasons for the project’s failure.

A typical premortem begins after the team has been briefed on the plan. The leader starts the exercise by informing everyone that the project has failed spectacularly. Over the next few minutes those in the room independently write down every reason they can think of for the failure—especially the kinds of things they ordinarily wouldn’t mention as potential problems, for fear of being impolitic. For example, in a session held at one Fortune 50–size company, an executive suggested that a billion-dollar environmental sustainability project had “failed” because interest waned when the CEO retired. Another pinned the failure on a dilution of the business case after a government agency revised its policies.

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

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 being 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 been reluctant to mention. 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 there had been insufficient time to prepare a business case prior to an upcoming corporate review of product initiatives. During the entire 90-minute kickoff meeting, no one had even mentioned any time constraints. The project manager quickly revised the plan to take the corporate decision cycle into account.

Although many project teams engage in prelaunch risk analysis, the premortem’s prospective hindsight approach offers benefits that other methods don’t. Indeed, the premortem doesn’t just help teams to identify potential problems early on. It also reduces the kind of damn-the-torpedoes attitude often assumed by people who are overinvested in a project. Moreover, in describing weaknesses that no one else has mentioned, team members feel valued for their intelligence and experience, and others learn from them. The exercise also sensitizes the team to pick up early signs of trouble once the project gets under way. In the end, a premortem may be the best way to circumvent any need for a painful postmortem.

A version of this article appeared in the September 2007 issue of Harvard Business Review.