How to fix problems before they happen?

What’s the idea behind a premortem?

The idea behind premortem is to find problems before they occur.

In software development, whether you have a formal launch of a big release or an informal one of a small feature, there is a point in time where you can stop and imagine what would happen if.

The premortem concept encourages the team to assume the patient has died, or in the software world — the project has failed. The project can fail after it has been released due to several reasons.

Maybe the code quality was low.

Maybe some key features were not implemented, causing market adoption to be slow.

Maybe, the market adoption was faster than we’ve anticipated, thus, the number of people using it was so large that it caused scale issues for the infrastructure service that is running the project.

Maybe there would be a lot of customers calling the support center to ask questions on the new shiny functionality, but the support division is not staffed to answer them, or maybe they even don’t know we have delivered a new project.

Maybe the project will introduce privacy issues, and our legal department is not even in the loop or maybe a white hacker will find security penetration flaws.

Maybe someone will tweet a negative feedback on the feature and it would become viral.

Maybe we won’t know if the project is a success or a failure.

There are a lot of reasons a project can fail.

Usually, when we kick off a new project and start implementing it, our mind is set to a specific state.

We are targeted to complete all the requirements of the feature on time, meeting some quality bar. In a more mature organization, maybe we’ve also set for ourselves some success metrics.

Well, that is actually great.

If we have a plan, and requirements, and quality bar, and metrics to measure, we are good.

But, shit happens. That is a fact.

Bugs are revealed after projects have been released.

Circumstances are not known at best or are changing at worst.

Projects fail.

Shit happens.

But, and this is the main idea behind premortem, what-if we can bring ourselves to a state of mind where we think the project has indeed failed after we’ve released it.

Can we be in the state of mind that shit actually happened?

If we can, If we are under the assumption that all hell broke loose, then we need to understand why? Why that has happened? What have we done wrong? What should we have done differently?

According to the research (a good referral to it can be found in HBR post from Sep 2007), and according to my experience as well from the past year, we would be able to prevent at least some of the most critical problems that may fail a project. Awesome!

Is premortem the same as threat modeling?

Though there are some similarities, it’s not the same.

Threat modeling is usually a pre-defined set of questions that you need to answer to make sure you have covered your basis. This is a similar part.

The difference is that in premortem you don’t answer templated questions. On the contrary. You are trying to get into the mood, of a failure. The patient has died. The project has failed. The world is collapsing, What the hell have we done wrong? This is more of an imagination drill than an interrogation one.

How to do premortem right? Gamification, Gamification, and Gamification

Getting into the required state of mind for a premortem is hard. Very hard.

Why? First of all, you need to jump into the future, and if you don’t have the automobile….

“gray coupe on road” by Franck V. on Unsplash

Second, the patient didn’t die. The project didn’t fail. Assuming it has failed, requires some pretty creative imagination!

Third, people are skeptical. Software developers are cynical.

They would not buy into the all premortem thing.

In their mind, the stuff that they could have thought on has been thought on, and stuff that hasn’t…well, no imagination exercise would help.

This is the place where gamification and atmosphere come to play.

Create a calendar meeting invite: Project “someProjName” — premortem”.

Invite the entire team.

Developers, QA, product managers, ux designers.

If you can, you should invite a few more people that are not as familiar with this project.

Maybe some people from another team, or folks from the customer support group. It doesn’t really matter. The good thing about bringing people that are not a part team is that they are the closest thing you have to a real customer.

Prior to the meeting itself, send to all the invitees a few words on premortem, or better yet, send them this article (-:

In the meeting itself, you will get skeptic looks.

Now, you need to set the scene.

Be dramatic. Show them pictures.

“wrecked white airline on ground at daytime” by Hao Zhang on Unsplash

Tell them a story.

Provide as many details as you can on the scene.

Choose a specific date in the future. For example, 3 and half months after the launch.

Find out the exact date. Let’s assume this is March 14, 2019.

Find out some interesting unrelated detail about that day, that would put people in the mood.

For example, March, 14 is pi day. Let the team know about it.

Tell them, that at March, 14th, at exactly 17:12, 3 minutes before you’ve inserted your laptop to your backpack, getting ready to close the day, you got an email from the company’s CEO with the following subject: URGENT! project “someprojname” — fix X immediately.

Our job is to find X.

Now, they are starting to get in the mood.

Explain to them that in order to spice things up a bit, you are dividing them into 2 groups.

Reds and Blues.

Before the meeting, prepare in advance notes, with the following titles:

Security officer

Chief of Business

Chief of quality

Legal officer

Chief of Marketing

Create one set of blue notes and one set of red notes.

If you don’t have enough people just strike through some of the titles (it’s not critical).

Now, pass a hat with the notes inside, and let each one pick a random note. This will divide the room into 2 groups (red & blue), each person with a specific title.

At that point, you would be able to feel the tension in the air, since people sense a competition is coming.

They are right.

Explain to them the rules of the games.

Each group will go to a dedicated meeting room.

Each group will have 45 minutes to come up with the most serious issues that caused the project to fail.

Each person in the group can contribute an issue in whatever domain but should remember they are specifically in charge of a certain one. This creates for individuals a sense of ownership. No chief of marketing would like that during their shift, some missed marketing materials/campaigns caused lack of awareness to a new functionality.

After 45 minutes the teams will rejoin and will go over the problems.

The team with the most serious problems (you can rank it according to their severity or not) will win ice cream, or a cupcake, or bragging rights.

You can spice the above with your own creative ideas — I love to hear about them!

That’s it. You are done. My recommendation is not to continue, but to halt the meeting. The goal of the meeting was achieved. The goal was to creatively think on what caused the project to fail. That’s it.

Offline you should go over the list of items the team has found, and strikethrough stuff that is duplicated or not relevant (since they were tested and validated, or with 0 likelihood, or already handled).

An important disclaimer here is that you are not forced to fix or handle all the issues that were brought up during the premortem session. It is up to the team to decide the ROI (Return of Investment) for each of the tasks. If the ROI is low, close them as “won’t fix”.

For the issues that are relevant, the team needs to assign owners in order for it to be handled in the next few days before the project goes live.

You’ve just saved a project.