The PreMortem: Preventing Failure Before You Fail

People sure seem to love themselves a good postmortem. A time as an individual or team to look back on what went wrong and learn from mistakes. To then share these learnings so that others can avoid your missteps. But what if failure could be addressed not by looking backward but by looking forward? What if the premortem was more common?

When kicking off a project, how often do you really honestly have a discussion about what could go wrong? Not in the context of the pros and cons of various scenarios or strategies but once a path is decided, what would prevent you from accomplishing these intended tasks?

Components of a Good Premortem
1) Defined project goal and scope: it does no good to discuss a moving target.

2) Core team members present/participating: it doesn’t need to be the full team (although it could be), but you need to get beyond just the one or two project leads and down to all the people who have responsibility for meaningful work items. Also be sure to include people from other teams who are major dependencies.

3) Trust: You’re basically asking people at the start of a project to suggest “why they’d fail” — if your culture is one of puffed chests, you need to ensure people understand this is meant to be productive and open. And should involve both professional and personal concerns. For example, if a key team member has a sick parent or is expecting a child, these are very real needs that may impact their ability to contribute during certain stretches.

4) Buddy system solutions: Getting someone to identify an potential issue is a first step, but then you need to make sure to track the concern through the life of the project. Even potential “failure points” that have been resolved should be periodically reviewed — the dead sometimes don’t stay buried. Also helps to have folks look after issues which aren’t always in their core area – this way they’re more objective and can help the functional owner get out of the weeds.

By avoiding traps of overconfidence at the start of projects and creating an environment where team members can productively agree on the strategy, but express concerns about execution, perhaps organizations can reduce the number of failures.