“Failure is not an option” often means “we haven’t thought about what could go wrong specifically, so we’ve made no plans to be successful despite risk.” Thus, instead of avoiding failure using bravado, the team has actually increased the odds of failure by not discussing how to be adaptable or recognize patterns to anticipate trouble. Build this conversation into the beginning of a project.

Images in this post have had client-identifying details blanked out.

At Four Kitchens, we host a workshop when a project starts. My favorite exercise to lead is the Premortem. When everyone is at their most inspired and engaged in anticipation of an exciting new project, we bring it all crashing down by dropping a bomb:

1. “It’s a year from now. The project has failed.”

Even if a team or client organization is unified in their view of project goals and success criteria (they often aren’t yet), failure can still mean different things to different people. Ideally, this exercise has stakeholders and team members—around 10-20 people. People are more open in smaller groups.

Setup:

• Time: 10 minutes to write, 5-10 minutes to review.
• Materials: Sticky notes, one pad per person. Use Sharpies/markers so results can be photographed.
• Method: Do a Post-Up—participants write ideas on sticky notes, one per note, and keep them until time to review. Then the facilitator collects and reads them aloud, grouping them into common themes on a whiteboard.
• For large groups: Assistants can take a first-pass at grouping duplicates while participants create them, putting them up on the board arranged by theme before the facilitator walks through the high-level themes and consolidates.

Prompt:

Imagine it’s a year from now, and the project has failed (or: ended in disaster).

What does this mean to you?

The facilitator can seed the brainstorm with couple general ideas:

• We’re late/not finished!
• We’re over budget!
• User engagement (pick a specific measure if possible: subscriptions, revenue, pageviews, etc.) is down.

Result:

• Sticky notes on a whiteboard, clustered by similar themes/outcomes.
• Add a title (shorthand is fine) and a count of notes in each group.

2. Sabotage the project to ensure failure.

This one is a head-scratcher at first. Now the group knows the many ways failure might look, but further study into the pathways to these failures helps define patterns and behaviors that team members should watch for.

Setup:

• Time: ~10 minutes.
• Materials: Butcher paper/posterboards, one for each failure outcome to be studied, labeled at the top. Use markers so results can be photographed.
• Method: Split into ~3-4 groups. Assign each group one of the top failure outcomes (either by count or by significance). Participants will write their answers on the paper.
• For tiny groups: Don’t split up; tackle 2 or 3 outcomes as a full group.
• Optionally: I like to dole out two outcomes per group, but it takes longer.

Prompt:

Imagine that you wanted to sabotage the project to ensure it ended in your “assigned” failure outcome.

What would you do, or how should the project be run to ensure that kind of failure?

After getting past the weirdness of openly talking about sabotaging a project, people usually get surprisingly engaged with this part. The facilitator usually doesn’t need to offer input, but should cycle between the groups to join in briefly.

Result:

• Each poster should have methods to drive toward that failure.
• Have one participant from each group present their responses.

In the past, we’ve seen things like:

• Outcome: Late.
  • Pathway: Involve too many people in making decisions.
  • Don’t set deadlines for review/provide input on something.
  • Something that boils down to “scope creep”
• User engagement (purcahses/subscriptions/etc) are down
  • Don’t research what users wanted/needed/actually use
  • Skip QA or UAT
  • Something that boils down to “go faster by cutting corners”

This may surface specific technical requirements. If it’s too “in the weeds” then gloss over those to keep the conversation moving, but make sure to capture the new requirement and prioritize it in the features list later.

If something out of scope is mentioned, that’s an important indicator that expectations aren’t clear around what’s in or out of the project and someone has pinned their idea of success to something that wasn’t planned for implementation.

3. Are you currently doing any of these things?

At this point, we’ve seen what failure looks like, and we know the pathways to get to those outcomes. Now lead a horse to water—end the exercise with a short open discussion that encourages a little introspection and pattern recognition. These lessons are only valuable if they’re put in practice:

Setup:

• Time: 5 minutes
• Materials: Gather the butcher papers closer together on the wall; get a brightly colored marker or dot stickers.
• Method: Full-group open discussion, mark the pathways identified.

Prompt:

Among other projects/day-to-day operations at this organization/on your team, have you noticed any of these things happening already?

Result:

In our experience, the answer is always yes to some. If no one speaks, I would believe that there’s a lack of honesty, trust, or empowerment in the room.

Mark these as they are identified, but the aim is an organic conversation to understand how an organization may have to change in order to realize the vision of success for the project.

Four Kitchens adapted our Pre-Mortem from Gamestorming: A Playbook for Innovators, Rulebreakers, and Changemakers by Gray, Brown, and Macanufo. We added steps 2 and 3—the book closes the exercise with an open discussion on how to avoid the risks exposed after Step 1. That would be a modification to do the exercise faster. Lots of our other workshopping tricks come from this book, too. It’s a great reference.