Playing Devil’s Advocate: Use Premortems for Your Project’s Success
Most teams could benefit from having a resident devil’s advocate—someone who would raise critical issues about a project that team members may not have considered. The devil’s advocate would help the team identify weaknesses in their thinking and seek changes that would prevent or minimize adverse outcomes, including abandoning the effort altogether.
A devil’s advocate is, in a sense, a contrarian—not by finding fault with decisions already made, but by asking questions that might raise awareness about overlooked factors, such as “Have you considered . . . ?” or “What could happen if . . . ?”
In an ideal world, we might all benefit, as epidemiologist Dr. Alice Stewart did in the 1950s, by having a partner whose explicit role is to find the errors in our thinking. As described in this TED talk by Margaret Heffernan, Stewart worked with a statistician whose job was to prove her medical findings wrong. His job was to look at her models and data and find flaws in her reasoning and her conclusions. By not being able to prove her extraordinary medical findings wrong, he was able to give her confidence that she was right.
In practical terms, a project team can become its own devil’s advocate by doing premortems. Whereas a postmortem (also known by the much preferred term, retrospective) helps a team draw lessons from a completed project, a premortem is done before the project proceeds. In a premortem, you brainstorm and discuss everything that can possibly go wrong in the project. You actively look for contrarian ideas in the form of potential problems that otherwise would not have surfaced until they caused major damage to the project.
In his book Wait: The Art and Science of Delay, author Frank Partnoy cites research psychologist Gary Klein as pointing out that we need to prepare well in advance if we want to make sound decisions and prevent time-pressured crises. Klein views premortems as a way to imagine that something went wrong in a major undertaking and to examine why it happened. He recommends asking, “Which assumptions were wrong? Were we biased? Were we working with flawed data?”
Klein’s plan for carrying out a premortem advises that you start by looking into a crystal ball and seeing the outcome of your project not just as a failure, but as “a complete, total, embarrassing disaster.” He emphasizes that this process is very different from brainstorming what can go wrong. In brainstorming, he maintains, we unconsciously restrict our thinking because we assume the project will succeed. By starting instead with the assumption that the project will fail—and fail miserably—we become more open to identifying flaws we might otherwise tend to ignore.
Are there projects you’ve worked on that would have benefited from conducting a premortem?
