You can read more and follow David Bethoney’s newsletter at The Revive.
Premortems help envision what could go wrong.
Have you ever worked on a successful project and wondered months later, what made it such a success?
A project team that seemed to handle effortlessly all of the roadblocks and left turns that most projects come with. The team felt low stress to be on. The arc of the project roughly followed the plan outlined, even if it had some hiccups along the way.
It just seemed to all click and you find yourself constantly telling this story to others as an experience you’re super proud of.
At this point in my career, I’ve been part of hundreds of projects. Over the past 20 years, I’ve used that time to understand patterns, understand what commonalities existed across the successful projects and what was missing in the ones that failed. Of course every project is different but there was one commonality that I keep coming back to: excellent premortems were executed. And the good news is, premortems don’t take long, they cost close to nothing and they allow the team to get on the same page.
The method of a premortem was created by Gary Klein in 2007. He wrote about premortems in an HBR article published in 2007. The idea of a premortem is this:
The entire project team comes together at the start of a project with a goal of identifying project risks before they occur. The team lead brings everyone together, she informs the team to imagine it is one year from now and the project has failed spectacularly. The team talks through why. What happened?
It’s a simple idea (maybe deceptively so) that gives the team the ability to surface what they are thinking but haven’t said out loud just yet.
Let’s talk through this.
Most projects fail in slow motion, through a series of small moments. These moments were entirely predictable and so before we talk more about premortems, let's talk about some of the biggest reasons projects fail.
Here are the three patterns I’ve seen most consistently in order of frequency.
Issue 1: Timelines Are Often Unrealistic
Timelines are often built assuming everything goes right the first time. This is extremely human. Someone estimated based on best-case conditions, nobody pushed back in the planning meeting because the energy was good and by week three the schedule is already off. The team isn’t behind because they’re slow. They’re behind because the plan didn’t account for reality.
Issue 2: Other Teams Were an Afterthought
Project planning in a silo happens all of the time. I see it constantly. Your team knew what it needed, built a plan and assumed the other teams it depended on would be available, aligned, and ready when the time came.
They weren’t. The engineering team had a competing priority. Legal had a two week review cycle nobody budgeted for. Nobody said it in the kickoff because the energy was good and nobody wanted to be the one who pumped the brakes. You had a fear it would make you look difficult. When those dependencies surface, they don’t just delay one workstream. They knock everything else sideways too.
Issue 3: The Team Had Different Definitions of Success
Two stakeholders with fundamentally different definitions of what this project is supposed to accomplish smiled and nodded through the planning phase and only surfaced their disagreement in week seven, when reversing course was costly.
Finance wanted cost reduction. Product wanted feature parity. Nobody resolved the conflict because nobody called it out. The team spent months executing toward a finish line that two of the most important people in the room had never actually agreed on.
The Premortem Process
In 1989, researchers Deborah Mitchell (Wharton School), Jay Russo (Cornell), and Nancy Pennington (University of Colorado) published a finding: when people are told an outcome has already happened, even a future one, they generate about 30% more reasons to explain it than when they’re asked to generically predict risks. The brain is simply wired to explain the past, not anticipate the future.
As the researchers put it: “One does not have to be a mad scientist to travel in time. By simulating different situational perspectives, decision makers may gain new insights about the causes of events in their environment.”
The premortem exploits exactly this. You tell your team the project has already failed, and then you ask them why. What you get back is not a polished list of theoretical risks. It’s the stuff people actually believe, the things they’ve been thinking since the project was first described to them.
Here’s how to run one.
Set the frame (5 minutes)
Before any thinking starts, establish the premise clearly. Tell the group: we are going to assume this project has already failed. Not that it might fail. It did. Our job today is to figure out why.
This framing matters more than it sounds. Without it, most people will hedge. “This could potentially be a concern if...” is a lot less useful than “this is going to be a problem because...” People need explicit permission to be pessimistic. For the premortem to be successful, you need to give this permission.
Individual brainstorm (10 minutes)
Have everyone write their failure reasons down independently before anything gets shared with the group. This step is the one most teams skip, and it’s the most important one.
The moment you open it up to discussion, you lose the benefit of diverse thinking. People anchor on the first idea raised. They defer to whoever speaks most confidently. Granting ten minutes of silent, individual thinking will surface more honest and varied risks than thirty minutes of open discussion.
Ask for specifics. “We run out of time” is not useful. “The design review always takes three weeks and we’ve only budgeted one” is.
Share and capture (15 minutes)
Go around the room and collect one risk at a time from each person, rotating until everything is on the board. No discussion yet. The goal at this stage is to get everything out without evaluating it. Duplicate ideas are fine. Contradictions are fine.
Your job is to keep the pace and resist the urge to comment on what you’re hearing. You want the candor.
Prioritize (15 minutes)
Now you discuss. Go through the list and pressure-test each item against two questions:
Question 1: How likely is this to happen
Question 2: How bad would it be if it did?
You’re looking for risks that score high on either dimension.
Aim to identify the five to eight risks worth actively planning around. Not every risk on the board makes the cut, and that’s OK. The goal isn’t to eliminate all uncertainty. It’s to eliminate the preventable failures.
Assign and close (10 minutes)
For each high-priority risk, someone needs to own it. Not a vague commitment to “keep an eye on it,” but a specific person who is responsible for monitoring that risk and flagging it if it starts to materialize.
Then close the session with a commitment to updating the project plan. Sometimes that means adjusting the timeline, or maybe it means resetting budget assumptions.
The premortem only works if it changes something.
Here’s What Good Risk Identification Sounds Like
The difference between a useful premortem and a performative one usually comes down to how specific the risks are.
Vague: “The timeline might slip.”
Useful: “We’re dependent on the data team finishing their analysis before we can start, and their workload is enormous right now.”
Vague: “Stakeholders might not be aligned.”
Useful: “Finance and Product have different definitions of success for this project and we’ve never resolved it. Finance wants cost reduction. Product wants feature parity.”
Vague: “There could be technical issues.”
Useful: “We’ve never integrated with this vendor’s API before and there’s no sandbox environment to test in. Our estimates assume it works the first time.”
If your premortem is producing mostly vague risks, push harder. Ask what specifically makes that happen. Ask who specifically isn’t aligned. You’re not doing the premortem for vague risks.
Who Should Be Included In A Premortem?
Keep it to people who are close to the work: your core team, a cross-functional partner or two whose work intersects with the project, and anyone who carries domain expertise the team doesn’t fully have itself.
One thing worth being deliberate about: be careful about inviting senior leaders who aren’t involved in day-to-day execution. I’ve seen premortems where senior leaders tend to shape or heavily influence what people say. The goal is honest thinking, and that’s harder when someone’s worried about how they sound in front of their skip-level. The whole point of the premortem is to create a space where people say the uncomfortable thing. Design the meeting to make that easy.
The Premortem Doesn’t Fix Everything
Premortems don’t help if the culture punishes people for raising problems, if the session becomes performative, or if the participants don’t feel psychologically safe.
For teams that are genuinely trying to do good work, a premortem is one of the highest-leverage hours you can spend at the start of a project. It turns the knowledge your team already has into a plan you can actually use. I haven’t been part of one premortem process where someone on the team says this wasn’t insanely valuable.
Try it out and would love to hear any comments back.
If you want to read more on premortems, here are some helpful sources:
- Performing a Project Premortem, by Gary Klein
- The Knowledge Project, Episode 18. This is a podcast episode where Naval Ravikant (Founder of AngelList) talks about his mental models for making decisions and making fewer mistakes. He doesn’t call out premortems directly but he talks about the underlying principals that surround premortems.
- Originals, by Adam Grant
Hope you have a great long weekend.
Dave
