Published here February 2008.

Musings Index

Old Wine in New Bottles?

A gentleman by the name of Gary Klein has recently written an article[1] titled: Performing a Project Premortem. Yes, that's right, PREmortem (as distinct from POSTmortem.) Gary is the chief scientist at Klein Associates, a division of Applied Research Associates, in Fairborn, Ohio.[2] His four-page article is now available through Harvard Business Online for the princely sum of USD$4.50. For this you get to download an electronic copy in PDF format.[3]

According to Gary:

"Projects fail at a spectacular rate and 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."

First up, we do not subscribe to the view that all projects fail at a spectacular rate. We have already questioned the basis on which this conclusion is reached.[4] But even if it is true at all, it appears to be connected to the information technology industry or, more likely, to the software development industry. Second up, if anyone on any project team is not permitted to speak their mind, especially in questioning the wisdom of a particular course of action, then in our opinion there is something wrong with the project culture. Perhaps the problem is with the whole corporate culture. Either way, the project deserves to fail. Further, anyone finding himself or herself in that position might be well advised to find another project, or even another employer.

Apparently, 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", i.e. imagining that an event has already occurred, increases the ability to correctly identify reasons for future outcomes by 30%. This finding is consistent with the intent, and the results, of the technique known as project risk management, and is generally concurrent with around the time that project risk management began to take off.

In the summary of his article, Gary continues to explain that:

"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."

Well, that certainly does make sense - except, of course, for the patient.

"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. 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."

All of that is typical of a project risk management brain storming session held to identify potential risks, as are the following examples also referenced in the article:

"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.

In a project to make state-of-the-art computer algorithms available to military air-campaign planners, a team member had been silent during the lengthy kickoff meeting. "[However, during the premortem session he] volunteered that one of the algorithms wouldn't easily fit on certain laptop computers being used in the field [and] 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."

Why the algorithm developers were reluctant to mention "a powerful shortcut" that they had already developed is not made clear. Could it be that exposure of this innovation might reduce their billable hours? If so, that does not suggest a very favorable project atmosphere at the outset.

"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."

Gary goes on to explain:

"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 over invested 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."

Call it "premortem" if you wish, but a project risk assessment should be conducted at a high level and at the very earliest phase of a potential project, indeed to determine the level of risk when preparing the project's business case. This should more than satisfy the types of examples cited. Moreover, the examples cited appear to be more akin to symptoms as a result of more deep seated organizational causes, as suggested earlier.

If all of that is true, then the expenditure of a little over a $1 per page for the original article hardly seems worth it. But maybe, just maybe, we've got the whole thing wrong. It's not the quality of the wine in the bottle that is important, it's the name on the label on the bottle that's important - to attract the attention of the executive management buyers.

Home | Issacons | PM Glossary | Papers & Books | Max's Musings
Guest Articles | Contact Info | Search My Site | Site Map | Top of Page