To Avoid Failure, Plan for It

About the only saving grace of most startups is that their failure is less-than-spectacular. Even in well-established businesses, projects routinely run over-budget, come in late, and fail to meet the team’s (and management’s) expectations.

There are many ways to avoid this fate, but one of my favorites is the Project Pre-Mortem.

Project post-mortems have been stock in trade for many software development teams for decades, and the bone-cutting and delightfully dry analysis can make for wonderful late-night reading.

Post-Mortems are rarely effective at their stated aim of identifying where a project went wrong so that future errors can be avoided. They are excellent at meeting their unstated aim, which is to assign blame for the failure and perhaps provide the team with a useful way to blow off steam after a frustrating few months (or years). At the very least, everyone gets pizza.

Agile software development has contributed to a decline in the need for comprehensive post-mortem analyses, in part because the short, iterative development cycle prevents large problems from accumulating, and daily stand-ups and Sprint Planning Sessions provide frequent opportunities for team members to raise and resolve issues before they become big problems.

All the more reason to kick off a project with a Pre-Mortem, where the team comes together to identify all of the areas where the project might go wrong before it happens.

The basic premise is simple: gather the main project stakeholders together for 60-90 minutes, and collectively come up with a list of things that could go wrong during the upcoming project, then list out the consequences of each potential problem.

This AirTable workbook makes the process super simple, and includes both pages for tracking the status of potential problems, and a form you can use to asynchronously gather potential pitfalls from stakeholders who can't get to the initial meeting.