What’s a Digital Project Pre-Mortem & Why Do They Matter?

Sometimes, software projects fail – whether they’re websites, web applications, mobile apps, or some combination of them all.

They can go over budget. They can be delayed for months. The end product might be frustrating to use, difficult to maintain, or just plain useless. Maybe the product is rife with security issues that were never identified. It’s an unfortunate truth of our industry – I’m sure we’ve all been there, or are at the very least concerned about heading down that path at some point in the future.

But what if I told you there was a way to anticipate project failure? A way to talk about failure that doesn’t throw anyone under the bus? A way that gets everyone on the same team?

I’m talking about a digital project pre-mortem. Let me explain.

Post-Project Reviews Are Reactive

Here’s how a web or mobile app project goes for most agencies, shops & clients right now:

1. Sign a contract
2. Have a kick-off meeting
3. Do the work
4. Review the work
5. Fix the work
6. Launch the work
7. Review the project

If a project fails in some form (over budget, over scope, delayed, etc), those failures are generally discussed at the end of the project. I’m all for reviewing & reflecting on completed projects – and celebrating them with a beer or two – but the problem with discussing failures after project launch is that the project has already launched. It’s strictly reactive. Yes, reflection is valuable and you can learn from / look to avoid failure points in future projects, but that doesn’t really help your just-completed flaming wreckage of a software project.

When we’re doing it this way, we’re running a post-mortem. The project is a patient. The patient is now dead. Oops. Why did it die? If we’re having this post-project conversation with our clients, too, they’re likely frustrated the project didn’t go as planned – not the best time to talk about failure. People don’t want to talk about failure when something has failed; fingers are pointed, people are blamed, and relationships are strained.

The solution then? Let’s talk about failure at the start of a project. Not at the end.

Let’s be proactive about failure.

Understanding Digital Project Pre-Mortems

At the start of a website, web application, or mobile app project, everything’s great. The sun is shining, the budget bucket is full, and everyone is looking forward to a big, splashy, successful project launch in a few months. The mood is positive – at kickoff meetings, everyone is throwing around ideas and getting excited (and rightfully so).

This is the time to talk about failure.

I know, I sound like I’d be fun at parties. But if we have the failure talk at the start of a project, we can:

1. anticipate roadblocks and reasons the project might fail
2. avoid pointing fingers or assigning blame
3. figure out solutions to potential failure points

Try it. Your project team will be much more receptive to talking about failure before it happens than they will after it has happened.

If we apply the same line of thinking as we did above, where we (somewhat morbidly) personify the project as a patient, it makes a lot of sense. Where we used to think The project is a patient. The patient is now dead. Oops. Why did it die?, we can instead be proactive: The project is a patient. It’s a healthy patient – but it might get sick. What might make it sick & how can we prevent that? 

This way, everyone gets to be a part of the solution – a problem solver. That’s a lot more fun.

How to Run a Digital Project Pre-Mortem

Running a project pre-mortem – a concept I first heard about on this Freakonomics podcast – really isn’t that hard. Here’s how to do it.

In your project kickoffs, ask the first big question to the entire room:

“What could cause this project to fail?”

Silence may greet you at first – it’s not an oft-asked question – so you might have to get the ball rolling yourself. You can talk about how authoring content might be difficult and might put the project off schedule; you can talk about how the timeline is tight but the team isn’t big, and that might mean a missed deadline; you could talk about how your users might balk at a big user interface redesign; and so on. Once you get the ball rolling, it’ll be interesting to hear all the potential ways this project might fail.

Make sure to capture all these points in whatever method you prefer: have everyone write their points down on sticky notes or whiteboard – we’re big fans of this type of approach – or take notes yourself; whatever works. Just make sure you capture them. Then ask the follow-up question:

“How can we avoid these potential failure points?”

And go back through them, one by one, and let everyone put on their problem-solving hats. At the end of the session, turn those solutions into actionable tasks that you can add to your meeting notes. All of a sudden you have a list of potential roadblocks generated by the entire team – everybody is aware of the challenges ahead and who is responsible for overcoming those challenges. Each person is empowered to play their role in the success of your digital project. Combine these with KPIs and business outcomes that matter, and you’re in a good place

Sounds a hell of a lot better than hopping on the Blame Train after 400 hours of work, doesn’t it?