Pre-Mortem at Work: Find Project Risks Before They Find You

A pre-mortem at work is a short team exercise where you imagine your project has already failed, then work backward to explain why. It takes about 30 minutes, costs nothing, and gives quieter team members permission to name risks that would otherwise stay unspoken. It is one of the most practical habits I recommend for any team that wants fewer expensive surprises.

Key Takeaways

• A pre-mortem at work asks the team to assume the project failed and explain why, which makes it easier to voice doubts early.
• Gary Klein introduced the technique in Harvard Business Review in 2007, and the core idea is to improve a plan before it starts rather than analyze it after it fails.
• Research on project bias suggests optimism and the planning fallacy are two of the ten biases that matter most for projects, and a pre-mortem directly counters both.
• The exercise works best when it is timed, anonymous at first, and ends with two or three concrete changes to the plan.
• Catching problems early also cuts wasted effort, materials, and energy, which is a quiet sustainability win.

What Is a Pre-Mortem at Work?

Most of us know the post-mortem: the meeting after a project goes wrong, where everyone explains what happened. By then the budget is spent and the lessons arrive too late to help.

A pre-mortem flips the timeline. In his 2007 Harvard Business Review article “Performing a Project Premortem,” psychologist Gary Klein describes how team members assume the project they are planning has just failed, then generate plausible reasons for the failure. The point, in the article’s framing, is that people with reservations can speak freely at the outset, so the project can be improved rather than autopsied.

I like the plain logic of it. Planning meetings reward confidence. A pre-mortem rewards honesty, and it does so by changing the question from “Will this work?” to “Why didn’t it?”

Why Does the Pre-Mortem Work?

Projects fail for predictable human reasons, not only technical ones. In a 2022 paper in the Project Management Journal (open version on arXiv), Bent Flyvbjerg identified the ten most important behavioral biases for project management, building on a base-rate dataset of 2,062 projects. He lists optimism bias, the planning fallacy, overconfidence, hindsight bias, and escalation of commitment among them, and names base rate neglect as a primary reason projects underperform.

In plain terms, we assume our project will be the exception. A pre-mortem punctures that assumption without making anyone the bad guy, because everyone is playing the same imaginary game.

The psychological safety link

Raising a concern takes social courage. Amy Edmondson’s 1999 study in Administrative Science Quarterly, a field study of 51 work teams at a manufacturing company, defined team psychological safety as a shared belief that interpersonal risk-taking is acceptable. She found that safety, rather than team efficacy, was associated with learning behavior, and that learning behavior linked safety to team performance.

A pre-mortem is a cheap, repeatable way to practice that safety. The prompt itself tells people that naming a problem is the assignment, not a betrayal.

How to Run a Pre-Mortem at Work in 30 Minutes

Here is the version I use with small teams, from three to ten people. It needs a whiteboard or shared document and a timer.

Step 1: Set the scene (3 minutes)

State the plan in two or three sentences. Then say: “It is six months from now. The project has failed badly. Write down every reason you can think of.”

Step 2: Write silently (7 minutes)

Everyone writes reasons on their own, without talking. Silent writing stops the loudest voice from setting the agenda and gives every person the same amount of airtime.

Step 3: Share and cluster (10 minutes)

Go around the room and read one reason each, round after round, until the list is exhausted. Group similar items. You will usually see three or four themes emerge, such as unclear ownership, an unrealistic deadline, or a dependency nobody is tracking.

Step 4: Pick the top risks (5 minutes)

Ask each person to mark the two risks they find both likely and damaging. The top few become your focus.

Step 5: Change the plan (5 minutes)

For each top risk, agree on one change: an earlier checkpoint, a named owner, a smaller first release, or a decision about what you will stop if things slip. A pre-mortem with no plan changes is just a gloomy meeting.

A Worked Example: A Small Content Migration

Picture a small team planning a website content migration with a deadline the manager guessed at. In a pre-mortem, the failure reasons that surface are rarely the technical ones. More often they sound like this: two people each assumed the other was checking links, the review step had no owner, and the date was set without asking anyone who would do the work.

All three can be fixed in ten minutes: one named reviewer, a link check run from a checklist, and a deadline that comes from the people doing the job. It pairs well with the habits in my post on checklists at work, and with the realism I discuss in time estimation at work.

What Do Big Project Failures Teach Us?

High-profile failures often start as small, unspoken doubts. Flyvbjerg and Budzier’s 2011 Harvard Business Review article on IT project risk opens with the story of Levi Strauss, whose failed SAP migration led to a reported $192.5 million charge. I cannot say a pre-mortem would have saved that project, and no technique guarantees success. But the story shows how costly it is when concerns stay private until it is too late.

The same pattern shows up in everyday work. People stay on doomed efforts because they have already invested so much, a trap I cover in sunk cost fallacy at work.

The Sustainability Angle: Fewer Do-Overs, Less Waste

Rework is a hidden environmental cost. A redone print run, a re-shipped order, a rebuilt prototype, or a duplicated analysis all consume materials, energy, and people’s time a second time. Catching a flaw on a whiteboard is far greener than catching it in production.

I treat the pre-mortem as part of a low-waste workflow: a few minutes of imagined failure up front to avoid real, wasteful failure later.

Common Mistakes to Avoid

• Running it too late. Hold the session before commitments harden, not the week before launch.
• Letting the boss go first. Seniority silences people, so use silent writing before any discussion.
• Treating it as a negativity contest. The goal is a better plan, not a longer list of fears.
• Skipping the follow-through. If no changes reach the plan, people stop taking the exercise seriously.

Summary

A pre-mortem at work asks your team to imagine the project has failed and explain why. It counters the optimism and planning biases that research on projects, including Flyvbjerg’s work on 2,062 projects, flags as common causes of underperformance, and it supports the psychological safety Edmondson linked to team learning. Run it in 30 minutes, write silently first, and leave with two or three real changes to the plan. It will not guarantee success, but it reliably makes the plan better and the waste smaller.

Frequently Asked Questions

What is the difference between a pre-mortem and a post-mortem?

A post-mortem looks back at a project that has already ended to learn what went wrong. A pre-mortem happens before the work begins and assumes failure in advance, so the team can change the plan while changes are still cheap.

How long should a pre-mortem take?

For most team projects, 30 minutes is enough. Large or high-stakes projects may justify an hour, but a short, focused session beats a long one that drifts.

Who should attend a pre-mortem?

Include the people who will do the work, anyone who depends on the result, and at least one person who was not involved in the planning. Fresh eyes tend to spot assumptions the planners no longer notice.

Can I run a pre-mortem on my own?

Yes. Write down why your solo project failed, then revise your plan. You lose the diversity of viewpoints, so consider asking a colleague to read your list and add what you missed.

Does a pre-mortem work for remote teams?

It works well remotely. Use a shared document for the silent writing step, then read items aloud on a call. The written format helps quieter people contribute equally.

Where can I read the original idea?

Gary Klein’s article “Performing a Project Premortem” in the September 2007 issue of Harvard Business Review is the best starting point.