Risk registers and meetings are boring - try a project premortem instead ...

What is a premortem?

A premortem is a project postmortem that’s run before a project. During a postmortem people analyse and discuss what went wrong, what went well and what could be improved.

While postmortems are very useful the problem is that by the time we run them the project is usually over and not much can be done about success and failure.

A premortem allows people to think of potential future problems, roadblocks and risks before we start the project and makes it possible to come up with good ideas to prevent them from happening.

When would I run one and why?

Premortems are really useful to get people talking about the fears and concerns for the project they would otherwise keep to themselves.

There are three situations where I find premortems especially useful:

• when we start looking at developing something that feels risky (e.g. a project or feature set)


• when I sense unspoken anxiety, fears and concerns


• when starting with a new team

I run them at the following times:

• during project inception, i.e. at the beginning of a new project/theme


• as a team retrospective

The reason for not just asking people directly about their concerns is that they will usually be reluctant to mention their fears to avoid being seen as pessimistic and not supporting the team.

Let’s face it none of us want to be the spoil sport who sees nothing but problems and risk workshops are just incredibly boring. (There’s also a great article in the Harvard Business review showing the research behind this).

How do I run a premortem?

Here’s one way that worked for us (it is heavily based on this presentation on slideshare):

1. Set the context (1 min)

Ask people to do some time travel with you and explain that you have finished the project and have failed. I tell a story like this:

“It is now December 2014. It’s a hot summer in Wellington but that’s about the only good thing that’s going on right now. Because we failed.

With the xxx product redesign we’re on the front page of the NZ Herald and things are not good. The CEO is shouting at us and this whole project has been a major disaster all along the way. In short we failed: you failed, you failed, and you failed, I failed - we all failed.”

2. Ask “What happened”? (5-10 mins)

• Next ask people what happened. Ask them to imagine all the events and issues that happened during the project and to write them on sticky notes. Give people five minutes to write stickies.

• Then ask them to put the stickies onto a project timeline.

3. Find themes (5-10 mins)

• Next ask people to silently move stickies into clusters that they feel “belong together”. They have five minutes to do so.

• After five minutes ask them to label the clusters. People can talk during this part.

• Have a quick dot vote to identify the most important clusters

The two most voted for clusters that came up in our premortem were:

• Team dynamics (UX and development running in parallel tracks, design not integrated part of the team, ...)

• Commitment (build the wrong thing, didn’t know who our stakeholders were, had no mission statement, ...)

4. Generate ideas (5 - 10 mins)

• Ask people to come up with ideas for how to prevent problems from happening. Focus on the top two or three clusters and and ask people “If you could go back in time, if you could run this project again ... what would you do differently?” Have them write one idea per sticky note.

• After five minutes ask people to read up their ideas.

5. Decide what to do (5 mins)

Dot vote on which ideas to implement. You can’t do everything at the same time so pick the top six to eight ideas and focus on them.

6. Make sure it will get done

Make sure everyone agrees what actions should be taken. We decided to put our actions visibly into the team area and to track them on the team improvement board (a Kanban board for improvements on the back of our story wall).

7. Close the premortem

Ask people how much they got out of the meeting and how happy they were with it.

8. Document

Last but not least don’t forget to document ...

New Teams

For new teams, especially if they are facing a particularly risky project, I recommend taking the time to work through all clusters rather than just the top priority ones.

In a recent team kick-off we spent 3 hours of our project inception discussing potential risks and found the time was very well spent. It gave us a great start on making ground rules and agreements for how to work together for the future.