This post is part of a series (maybe) on applying the lessons of Stoicism in the corporate world. This post focuses on the Stoic practice of Premeditatio Malorum or “the pre-meditation of evils”, whereby you think or visualize all bad things that can happen to you, perhaps something you are particularly afraid of. Then you imagine how you would deal with and recover from it. The idea being that this exercise acts as a sort of inoculation for if the dreaded thing does happen and helps strengthen you against the trials of life, and perhaps help you realize that it isn’t all that bad either.
This practice can be applied to any business initiative, product launch, or project using a technique called the pre-mortem. This is an exercise I have use myself on several projects and at the very least is a good way to generate your initial set of risks to track and manage. However, it is also a way to get a temperature check on your team in a way that creates space for them to think about failure without being negative or being worried about being perceived as a Chicken Little. Unlike their managers, project teams often know long beforehand that a project is in trouble, perhaps even at the beginning when their estimates have been slashed without changing scope (hmmm).
Far too often in the corporate world we only present and evaluate a highly optimized and ambitious plan without accounting for the inherent risks. This is in direct contradiction to Project and Program Management best practices, but unless we as leaders create the psychological safety for the team to engage in which is basically negative thinking, it is highly unlikely someone is going to speak up about risks they see as the hype train for the project gathers steam.
Typically, a pre-mortem is run in the following fashion, I would keep this to 50-60 minutes in duration:
- Gather the team members together. Intentionally exclude senior executives and others who will stifle discussion at the team level.
- Level set with the team that you are about to facilitate an exercise meant to identify key risks to the project/program/product, and you’re looking for them to start with a brainstorming activity in which you need everyone’s participation.
- Announce to the team that the project/program/product has just failed and they have been brought together to identify the reasons why. [30 mins]
- You must facilitate this discussion – don’t let people interrupt, talk over each other, debate the merits of the idea, etc. The goal of this portion is just to capture the things the team is already worried about but unwilling to bring up.
- Do not end this earlier than planned, especially the first time you run this exercise. Let the team sit in silence or call on people. I also have 2-3 risks ready as part of my prep to help prime the conversation if needed.
- Next, ask the team if any of the items are the same, or so related as to be combined. [5 mins]
- Next, ask the team to assess how likely the risk is to come to actually occur. You could use a simple High/Medium/Low scale or whatever risk probability rating your organization currently uses (ask one of your Project Managers.) [5-10 mins]
- Depending on the culture of your team you can either debate this openly, use a form of Planning Poker, or have everyone vote with colored stickies.
- Lastly, look at the high likelihood risks, and ask the team two questions: [10-15 mins]
- Are there any leading indicators that will warn us that this risk is about to occur?
- Are there any pro-active mitigations we should consider to actively prevent this risk from occurring? (An example might be a risk to product quality that our entire QA team is inexperienced, when our estimate included 2 leads to run QA. A mitigation might be to overstaff that team, or to staff a junior project manager, etc.)
- That’s plenty for one session thank the team and let them know you will take some additional time to assess the other risks and discuss with management or the client.
Now the question comes as to what do we do with this information.
- First, spend additional time with this list. Put it into a risk register, clean up the way you wrote the risks and mitigations, and identify the impact of the risk occurring (for this you may need to consult specific team members and the project manager if this isn’t you.) After these additional deliberations and discussions you may want to adjust some of the risks, just be sure to communicate to the team along with your rationale or you’ll demand the trust the team has in you.
- Present the risks to your management/client and, at least for the high likelihood risks, ask “are you willing to accept the risk of the documented impact, or should we include the proposed mitigation in our estimate” – do not waffle on this. They might proposed a different mitigation, and be open to that being a better option, but don’t frame the discussion in a way where they can refuse the mitigation AND avoid there being clear documentation what the dollar and time impact would be if the risk occurs. (Far too often I have seen clients and management act surprised and demand how we didn’t know about a risk when it was in the project documentation or even the contract from the beginning. This is just a tactic to get the team to eat it, don’t be a sucker.)
- Regardless of the outcome of the discussions, document the meeting, the items discussed and the decisions made. Again, use the language “decisions made”, not some inconclusive discussion about hypothetical risks, but decisions made by management or the client on how THEY want to manage the project / program / product risk.
- Ideally the risk register is part of your public team documentation, and you can just publish it and let the team know they key points in your next meeting. If not, specifically review the outcome of the discussions with ma
From here you or your Project Manager should manage the risks in accordance with your organization’s risk management practices.
For a robust description of project risk management see this PMI article: Project risk management–another success-boosting tool in a PM’s toolkit
If you have used this technique or something similar in the past, what was your experience? What did you learn?
Photo by Christina @ wocintechchat.com on Unsplash
One thought on “Stoic Business – The Pre-Mortem”