Project Pre-Mortem: Save Your eLearning Project By Killing It

Saving Your eLearning Project With A Project Pre-Mortem

Very early in my career, I developed software training for a government customer. I'm fuzzy on the details now, but I do remember the project going over-budget and way past deadline. The final product —the result of a Mountain Dew-fueled all-nighter— was hot, smelly garbage.

So what happened? For one thing, my Subject Matter Experts kept disappearing when I needed them most. It also didn't help that the customer took approximately forever to complete milestone reviews. The biggest problem, though, was that the software itself kept changing. As soon as I'd nail a decent set of screen recordings, the customer would "tweak" (i.e., completely change) the user interface. I'd struggle to catch up in time for the next milestone review, only to start the cycle all over again with another round of UI changes that the customer promised would be the last one.

Were all these problems "unforseen circumstances?" Yes and no. They were certainly not forseen by me. My colleagues, on the other hand, could forsee them a mile away. Why didn't they warn me? Probably because my enthusiasm and optimism made me hard to warn. We did some perfunctory risk management, but no one felt comfortable telling me straight-up that I would need to pad my schedule due to known issues with the customer.

About a decade ago, a brilliant research psychologist named Gary Klein developed a technique for dealing with this problem. It's called a pre-mortem. Now, you may have heard of a project post-mortem before — it's a meeting held after a project "dies" in which the team talks about the "causes of death" and how to avoid them in future projects. A project pre-mortem runs on the same basic principle, but it's held before the project kicks off.

Here's How A Project Pre-Mortem Works

Step 1

Call your team together (in-person, if possible) and make sure everyone is comfortable. Give everyone a few sheets of clean paper.

Step 2

Set up the exercise with a little show biz. Say something like "I looked into a crystal ball to see where this project was headed and...damn! It's a complete failure. Total dumpster fire! But this cheap crystal ball won't show me why the project failed, so we have to figure it out."

Step 3

Give the team members 3 solid minutes to write down all the reasons they think the project might fail.

Step 4

Have each person share one item from their list, while you, dedicated facilitator that you are, dutifully write down those reasons on a flipchart or whiteboard. Then do another round, where everyone shares another item from their list. Repeat until everyone is out of items. Now you've got a Great Big List O' Failure to work with.

Step 5

Find the top 2 or 3 concerns and come up with a plan to address them. Schedule another meeting to deal with the rest of the list.

Step 6

Keep the Great Big List O' Failure handy. Bring out for a review every few weeks and see if any of the identified possibilities are popping up their ugly heads.

Here's Why A Project Pre-Mortem Works

The project pre-mortem is based on a concept called prospective hindsight, which is just a fancy term for "pretending that something has already happened". Researchers Deborah Mitchell, Jay Russo, and Nancy Pennington found that using prospective hindsight increases our ability to accurately identify reasons for future outcomes by about 30%.

Another reason this technique works so well is that it unleashes the power of negative thinking, which might otherwise be frowned on. Team members feel free to let their cynical, pessimistic flags fly because that's the whole point of the exercise.

A final reason this exercise is so effective is that it draws on multiple sources of information. Everyone on your team has their own experiences, attitudes, and outlooks to draw from, so the Great Big List O' Failure is much more thorough and comprehensive than a list of risks generated by any one person.

Summary

The human imagination is a powerful tool. Put it to work by asking your team to imagine your project has failed and identify the causes of death. A good project pre-mortem might just prevent you from having to conduct a post-mortem.

 

References:

Close