Pre-mortems are a process that help you proactively visualise, identify and mitigate project risk. This deck sets out how and when to conduct a pre-mortem, and provide an example.

1. Policy Lab
Pre-mortem tool

2. • A pre-mortem is a group brainstorming exercise
used to critique plans and projects.
• It brings forward the post-mortem process by
imagining the possible failure state so that a
project can be improved at the start rather
than autopsied at the end.
• It looks back from the imagined future to tell a
story about the causes of failure.
What is a
‘pre-mortem’?

3. • You will need:
• A pre-mortem team. This should ideally
include other people with a stake in the
project, such as the project sponsor,
subject matter experts, and external
critics or sceptics. There is no set number,
but 5 - 10 people is a good number.
• Sticky notes and marker pens.
• A room or space.
• 1 hour.
How to do a
pre-mortem
1. Brief the pre-mortem team on the project.
(5 minutes)
2. The team chooses a date in the future. They
imagine that the project has failed and what
that failure looks like. (5 minutes – group
discussion)
3. Individually, team members write down every
reason they can think of for the failure, as
detailed as possible, without fear of being
impolite (this can be done with sticky notes, or
in a shared document).
(10 minutes)
Steps

4. • The team members’ task is to generate likely
reasons for the project’s failure
• The purpose is to identify vulnerabilities in the
plan, and develop specific actions to mitigate,
avoid, transfer or accept risk before it’s too late.
• The project team can use this process to build in
measures in the project plan to lessen or
eliminate the risk.
Using pre-mortems
to manage risk
4. The team discusses reasons for the project
failure by theme:
• what are the themes?
• what is within the team’s control?
• what are the actions?
• who is responsible for doing what?
(40 minutes)
5. The project team uses the reasons to
strengthen the project plan before it fails.
Steps

5. Benefits of a
pre-mortem
• It overcomes blind spots and optimism bias by reframing the project as a
failure.
• It generates more ideas by focusing on the prospective hindsight of
“what did go wrong” rather than the typical “what could go wrong”.
• It encourages those who are usually quiet to speak-up because ideas
are generated anonymously.
• It can be done early on in a project, and as many times as required.
• It rewards people for being imaginative in finding flaws within a project.
• It helps the team to recognise warning signs quicker and bridges short
and long term thinking.

6. Example: NSW Post
and older people
Project brief: We want to enable postmen and
postwomen check in on older people who live
alone, while they deliver mail. They can note and
report on any changes in their health and living
conditions.
Failure date: 6 months from project start.
Failure state: A digital solution has been developed
and it has impacted negatively on the volume and
timeliness of mail being delivered. Complaints to
local post offices have increased 20%.

7. What went wrong
and why?
People got mad at us – we
didn’t explain to the broader
community what the aim of
the project was
We wrongly thought it
would only take 2 people
and 6 weeks to do the
research, but we needed
3 people and 12 weeks
We assumed
NSW Post
would do it
We didn’t
influence
governance
We
underestimated
travel time
The problem
definition was
developed too
quickly and not all
the stakeholders
agreed on it
We didn’t
engage
enough SMEs
We were not
thorough enough in
scoping the project
We didn’t
have time to
engage with
users in
regional NSW
We thought
the project
would have
minimal
impact
• What went wrong?
• What were the possible
causes?
• Were there warning
signs?

8. Using insights to
manage project risk
Themes Actions Responsibility Due date
Project scope • Describe teams’ responsibilities
• Workshop problem statement with
all stakeholders
Project
manager
Sprint 1
Project
governance
• Propose ideal governance
structure, and rationale
Director Sprint 2
Project planning • Map teams’ skills against project
desired outcomes, and identify
gaps
• Build continency time into project
plan, using contingency matrix
Project
manager
Sprint 2
Communication • Build communication strategy as
part of project plan
• Monitor strategy throughout the
project
Project
manager and
client
Sprint 3
• Using the answers to
'what went wrong and
why':
• Group the reasons
for failure
thematically, and
prioritise.
• Identify mitigating
actions.
• Assign responsibilities
and set timelines.