Premortem Retrospectives

Catch Failure Before It Occurs

Retrospectives are key elements of the Agile approach and are described in a classic book by Esther Derby and Diana Larsen: Agile Retrospectives

They are held periodically, typically at the end of an iteration, to inspect and adapt the process and continuously improve it.

In medicine a postmortem examination is conducted to determine the cause of death. Information collected during the procedure can be used to explain what happened. The problem is that the procedure brings no benefit to the deceased person.

Replace 'person' with 'project' and you see that a retrospective at the end of a failed project is similar to a postmortem: helpful for future projects but useless for the failed one.

To avoid a painful postmortem it can be sometimes helpful to try to prevent project failure upfront.

"You’ve seen your own future, which means you can change it if you want to"

- Chief John Anderton, Minority Report 

A Project Premortem is described in an Harvard Business Review article by Gary Klein:

Performing A Project Premortem

A Premortem Retrospective is an adaptation of that approach based on the 5 typical phases of Agile Retrospectives.

I have used it a number of times with great success and I am going to describe it in this post.

You do a Premortem at the beginning of a (long or complex) project.

The idea is to time-travel to the scheduled deadline and presume that the project has failed miserably.

Note: the Innovation Games book contains an approach named "Remember the Future", while the book GameStorming describes a game named exactly "Pre-mortem". Yet another approach, called futurespective (nice name) is described here: Futurespectives.

While there are some similarities with the approach described here, context, goals and execution are (sometimes significantly) different.

In particular the idea here is not to ask what might go wrong, but to ask what did go wrong.

The meeting should be short. 60 minutes is usually an appropriate length, but big projects could require longer.

After the usual initial phase (Set the Stage, 5') the retrospective starts with an activity to identify key events and feelings as they happened during the project (Gather Info, 10')

Colored sticky notes are positioned on a timeline by each person at the appropriate time. Green notes are for positive events and good feelings, Red are for bad/negative ones, Yellow ones are used for events that were neither good nor bad but were relevant anyway.

Focus is just on what and when things happened and who was involved.

Each person is then asked to write 4 sticky notes describing what worked well (2 green notes) and what didn't work (2 red notes) and put them on a whiteboard. The number of notes could be adjusted based on the number of participants. (Generate Insights (1/3), 5').

This is followed by a silent grouping activity. All participants go to the whiteboard and, without talking to each other, group sticky notes based on their judgment (no predefined categories, no labels, etc. see Jean Tabaka - Collaboration Explained)

Groups are then labeled and finally one or two groups are selected for further action. The idea is obviously to focus on problematic (red) items. (Generate Insights (2/3), 10').

This phase ends with the generation of quick ideas/actions (no constraints, no details, no discussions) to address problems belonging to the selected group(s) (Generate Insights (3/3), 10').

In the following phase (Decide Actions, 15') each person is assigned two dots (red - high priority, 3 points; blue - low priority, 1 point) that are used to vote proposed ideas/actions. The 2 or 3 most voted ideas/actions are then selected and detailed leading to an action plan that includes who will work on the task and when it will be completed.

Next steps are:
- verify agreement on the fact that these actions will significantly lower the chances of a project failure

- verify commitment and energy to achieve goals.

A specific task board is then set up to track the tasks.

The final step (Close, 5') is the standard closing phase of an Agile Retrospective. It typically includes evaluation of ROTI (Return On Time Invested), a follow-up plan and appreciation for everyone.

That's it. It works. Try it.

You can find slides for this post here: slideshare - Premortem Retrospectives

PS1
some of the activities described above could be replaced by other activities like  'Start, Stop, Keep', 'Force Field Analysys', etc. as described in Esther Derby's book.

This specific format works very well for me though

PS2
one could argue that this is just risk management, but actually this is different.
Risk management is in a way implicit in the Agile approach: daily stand-ups, time-boxing, value-based prioritization, WIP limits, standard retrospectives, information radiators such as task boards, burn-up charts, etc. all concur to constantly identify, monitor and reduce risk (business, technical, etc.). Constant process improvement also reduces risk (at least it should).

Traditional risk management is done by only a few people: typically by project managers and selected team members. It usually focus on risks/potential problems in the context of the status quo (and with a change averse attitude).

In a Premortem all the team is involved. We don't identify just problems, we also try to find opportunities that are not necessarily related to traditional risk management and are mostly related to process, tools, teamwork and self-organization improvements.