[](Leading.md)]] tags:: #note/thing | #on/projectmanagement | #on/leadership | #on/decisions people:: %% # Premortem Lon Setnik dates:: 2022-04-18 *How teams find failures before they start the project.* This reminds me of pilots doing a checklist before they take off. This also reminds me of [[Design thinking]], and [[Antifragility]], looking for ways to create antifragile projects that can win in any conditions It's kind of like brainstorming, but instead of the groupthink that can occur, it is the opposite. It's in some ways like [[Socratic questioning]], or avoiding [[confirmation bias]]. In a premortem, team members **assume that the project they are planning has just failed** as most do—and then generate plausible reasons for its demise. They write them down independently, then the process is to read them one by one around the room. Those with reservations will speak freely at the outset, so that the project can be improved rather than autopsied. the premortem operates on the assumption that the “patient” has died, and so asks what did go wrong. The team members’ task is to generate plausible reasons for the project’s failure. This matters because teams tend to overlook the risks, and avoid speaking up. This is a specific technique for speaking up. It's similar to my question at the beginning of a trauma, "What could go horribly wrong?" ### What would the opposite argument be? We don't have time to think about risks every time we are starting a project. Many projects are successful without this! If people have concerns they should speak up, it is their responsibility. ## Sources: https://www.gary-klein.com/premortem Klein, G. (2007). Performing a Project Premortem. _Harvard Business Review_, _36_(2), 103–104. [https://doi.org/10.1109/EMR.2008.4534313](https://doi.org/10.1109/EMR.2008.4534313)