When Was the Last Time You Conducted a Project Premortem?
Don’t wait for the postmortem to learn from your mistakes
We all know that planning is important. Those who fail to plan are planning to fail. Or so the saying goes.
There’s just one problem. Even if we plan, we plan while implicitly assuming the “happy flow.” We ignore our innate biases, the environment in which we operate, and our not-so-helpful habits that might get in the way.
That’s how a “perfect” plan often produces a not-so-perfect result.
It’s all about our implicit assumptions.
If you want to make more effective plans, you need to consider conducting a
premortem.
What Is a Premortem?
It’s quite similar to a postmortem actually (not the medical kind, though the principles are quite the same), except that you’re doing it before starting the project.
The cool thing about it is that we’re using our imagination and fear of screwing up to our advantage. The project doesn’t have to fail for us to learn from our mistakes. We can simply imagine it did and then work back from there to think what could have made it fail.
One of the most important parts of a premortem is figuring out how we might screw up the project. Yup, many other things can get in your way — other people, other projects, circumstances, COVID-19, you name it. The thing is, we’ve got limited control of these things.
Spending a lot of time trying to mitigate their risks will violate the 80/20 rule. That’s not to say that we should ignore outside circumstances. Far from it, however, we need to focus on the 20% that will cause 80% of the trouble.
What is that 20%?
The right question would be, “who is the 20%?”.
And the answer is — the people that will actually work on the project.
That means if we assume the project had failed, the prime suspects are the people who worked on it.
Now that might sound painfully trivial, but it’s not. Our default psychological tendency is to blame outside circumstances, even in cases where it’s clearly our fault.
How Do We Conduct a Good Premortem
The first part is ensuring we know exactly what our project entails.
This part is crucial. Without it, we wouldn’t be able to anticipate all the things that could go wrong.
Then we get to the main part — using our collective imagination to foresee what ills may befall our project.
First — Focus on the People Involved
As mentioned above, we should focus on how we might screw things up. There are a few common themes:
Other projects
Taking on another project while you’re already struggling to keep up with your existing ones is a surefire way to fail. You’ve got to balance things out; you’re not a machine — yet. You either need to give up an existing project or postpone the one you were about to take.
Common innate biases
That’s a big one. We all have innate biases that might derail our projects. These include:
- Positivity bias — We anticipate things will go smoothly. Software engineers routinely undershoot time estimates by at least a factor of 2. Yours truly included.
- Overconfidence bias — Somewhat related to the positivity bias, except here it’s more about our tendency to take shortcuts and spend less time planning (jumping to the first solution that came to mind).
- Confirmation bias — Looking mostly at data that supports our previous beliefs. This might make us spend less time looking for opinions that might contradict our own — potentially missing serious flaws in our plan.
Personal biases/Habits
These are somewhat trickier. It’s easier to admit a bias that “everybody” has, like the ones mentioned above. But we often have our own unique set of biases and habits.
For example, you might plan to build an internal app for your organization. You didn’t get approval to work on it during your “working hours,” but you’re the world’s best employee, so you decided to wake up one hour earlier and get some work done.
If you’re already an early riser, that’s pretty simple to do. But if you barely wake up in time for work and you’ve had a habit of waking up late, there will be a lot of friction. You might have the perfect plan for your app, but if you’re not going to actually work on it, it’s not going anywhere.
In that case, scheduling time to work on the project in the evening might be a better strategy that fits your night owl nature.
Second — Focus on the Environment
After we’ve covered the main ways we might destroy our projects, we should concentrate on the environment we operate it. Again, as mentioned before, we have limited control here, but it’s good to be aware of everything that might make us fail. A few good questions to ask:
What are the project’s dependencies?
Your plan might be stellar, but things will get much more complicated if your project depends on other teams’ approval/work.
We need to map out these dependencies, and for each one, consider if there’s something we can do to facilitate a smooth process.
Other dependencies might be more implicit. For example, its success might depend on your family’s habits if it's a personal project.
For example, you might have a plan to train for a marathon. It requires you to get up at 6 a.m. sharp; otherwise, you won’t have time to work out.
The only problem is that your kids routinely stay up till 1 a.am., and you’re a shallow sleeper. Five hours of sleep a night is not a good recipe for success. If you don’t fix your kids’ bedtime routine, you’re not going to run a marathon any time soon.
What is your project’s perimeter?
If your project involves working on 20-year-old legacy code, you should be expecting trouble. If you usually take a time buffer of 50%, you should consider increasing it considerably.
If you work on a domain outside your circle of competence, you should anticipate unexpected delays/issues. You might know all there is to know about cyber, but if you’re working on a healthcare project, you’re going to deal with a different set of problems than you’re used to.
Are there any upcoming changes in resources?
- Budget — your department might be short on budget, so if your project is planned to take a year with no tangible value until it’s done, it’s likely to fail unless you create more concrete value-oriented milestones.
- People — Are you recruiting a lot of new people? that might mean your team will be busy onboarding them and getting them up to speed. This might change the timeline of your project considerably.
Many other more mundane issues might arise, like executing a project right before the holiday season.
The Bottom Line
Don’t wait for the postmortem to learn from your mistakes.
Conduct a premortem, assume your project has already failed, and then work back from there to make it a success.
To conduct a good premortem, consider how you, the people responsible for the project, might screw it up. You are the 20% that causes 80% of the issues. Only then, consider how to mitigate issues caused by other people, the environment, and unfavorable circumstances.
