Premortem not autopsy

Most projects don't fail overnight; they usually succumb to slow, polite decline, filled with polite meeting minutes. Timelines tend to slip, departments miscommunicate, legal requests extensions, finance offers diverse interpretations of success, data teams become overburdened, and vendor integration proves far more complex than initial presentations suggest.

Somewhere around the seven-week mark, project teams realize their notion of alignment was, in reality, everyone nodding in agreement while imagining disparate outcomes. This scenario led author David Bethoney to appreciate the value of a practice called the premortem, a discipline developed by psychologist Gary Klein in 2007 and popularized in Harvard Business Review.

The premortem is a pre-mortem exercise held at the outset of a project, which enlists the team to imagine the project has already failed spectacularly. The team then asks one simple question: "Why did it fail?" This approach works because most individuals are better at explaining what transpired than predicting what might occur.

Researchers Deborah Mitchell, Jay Russo, and Nancy Pennington discovered that when people are informed an outcome has occurred, even in the future, they generate more explanations for it compared to when they are merely tasked with predicting risks. The human brain, it appears, functions more like a detective arriving late with a set of strong opinions, rather than a futurist.

Instead of posing "What could go wrong?" which typically yields generic and unremarkable answers, the premortem presents the scenario: "It is one year later; this project failed. What happened?" The quiet engineer might respond, "We have never integrated with this vendor's system before." The operations manager could offer, "The timeline presumes everything will function perfectly on the first attempt."

The HR representative might add, "The individuals who will utilize this tool were never consulted." Someone from finance could state, "We are measuring savings, but product management is focusing on feature parity." As the discussion unfolds, the team begins to recognize the pitfalls they should have identified earlier. Bethoney highlights three common reasons projects fail.

First, unrealistic timelines often result from the fantasy that everything will go right from the start. This notion, while charming, can be perilous. The plan assumes immediate approvals, available resources, cooperative vendors, cooperative stakeholders, and technology behaving predictably. Conversely, reality tends to emulate a mischievous cat at the keyboard.

The second reason projects falter is that other teams are often overlooked. A project team devises a plan, assuming legal, finance, engineering, sales, marketing, or operations will be ready precisely when required. However, these teams possess their own priorities, deadlines, and emergencies. Ignored dependencies become delays later.

Lastly, stakeholders frequently have divergent definitions of success. At planning meetings, all parties may smile, but distinct executive preferences emerge – one seeks speed, another seeks savings, another seeks quality, and another seeks customer delight. Although each aspiration is commendable, failing to reconcile these differences can transform the project into a corporate buffet, where everyone contributes different dishes without ensuring shared plates.

To initiate the premortem process, the team should be informed that the project has already failed, not that it might fail; the task at hand is to understand why. This approach provides permission for the team to adopt a respectfully pessimistic stance. Next, each team member individually and silently documents reasons for the project's failure.

This step is crucial, as early discussions often lead to anchoring on the first idea, deference to the loudest individual, or modification of answers to avoid appearing negative. Subsequently, the team collaborates to capture risks, one at a time, without engaging in debate, defending positions, or offering executive speeches disguised as clarifications.

The focus is solely on collecting risks. Afterward, the risks are prioritized by asking two questions: How likely is this to occur? And how detrimental would it be if it did transpire? The objective is not to eradicate all risks, as that is unattainable. Instead, the goal is to identify five to eight risks that necessitate active planning.

Finally, ownership must be assigned for each major risk. Every significant risk requires a designated individual responsible for monitoring it. It is not sufficient for the team to own the risks; a specific person must assume responsibility. A premortem should not merely generate awareness; it should enhance the project plan. If the team identifies risks but fails to implement changes, they have not practiced disciplined foresight.

They have merely held a meeting that appears responsible while leaving original assumptions unaltered. Before embarking on the next significant project, refrain from merely asking, "How do we succeed?" Instead, inquire, "If we fail, why would we fail?" It is far more constructive to conduct a premortem in the conference room than to conduct a postmortem during a crisis.