I listened to a great podcast the other day on the Freakonomics Radio Podcast, through the NPR One app on my phone. It was about failure, and more specifically, about why things fail, why we consider them a bad thing, and most importantly… how failure can be a good thing. Predictably, the podcast was called “Failure Is Your Friend.”
Now, this is not some “Thomas Edison’s thousand failed lightbulbs”-canned-SAT-essay-kumbaya-bullshit reason that failure can be a good thing (I would know one of these when I see ’em, as I regurgitated one for my SAT exams and predictably (and depressingly), it worked.) What it was about wasn’t experiencing failure – the podcast was about imagining failure, and removing the stigma of it so that in projects you can realistically discuss failure without coming across as a bad teammate.
The climax of the podcast was introducing a concept pushed by Gary Klein, a research psychologist famed for his research in naturalistic decision-making. This concept is of the “premortem.” Postmortems are commonplace, but not so much the “premortem”. I mean, type both “premortem” and “postmortem” into Microsoft Word and see which one has the red squiggly line underneath it.
Wikipedia defines “postmortems” as “a process, usually performed at the conclusion of a project, to determine and analyze elements of the project that were successful or unsuccessful. Project post-mortems are intended to inform process improvements which mitigate future risks and to promote iterative best practices.” Basically, you look at what’s happened and see what went wrong so you don’t make those mistakes again. However, the important part here is the post- prefix – you’re thinking about this after a project has already succeeded or failed. What happens less often is the premortem – where you determine and analyze unsuccessful elements of a project as it is ongoing. Now, that would be an obvious thing to do in a vacuum – you’d be a blithering idiot to not consider the risks of what you’re doing. But projects don’t happen in a vacuum. Human nature adds lots of things to a project environment that make talking about and considering failure a bad thing. Common culture states that talking about failure makes you “a debby downer” and “not a team player.” No one likes the safety/verification officer on the team because his whole job is literally to make sure you did your job right; no one enjoys being questioned on their work. Coupled with overly optimistic and aggressive leaders, actually assessing failure modes prior to actual failure is surprisingly…uncommon.
Gary Klein’s method of administering a premortem follows the following recipe:
- Get everyone in the team in a relaxed state of mind. Don’t dream, but be ready to dream.
- Now tell everyone to imagine that the project has failed. Don’t give details about how – just tell them that goals were not met and ultimately the project was a failure with no way to salvage it, and that it remains a black mark on your record forever.
- For a two minute time period, ask every person present to think about and write down all the reasons, in the hypothetical future, the project has failed. You want to incentivize them using their brains to think about failure, and more importantly, think about what the team has failed to do that could cause the failure of the entire enterprise, and what could the team do that will cause failure.
- Afterwards, compare notes and read aloud every reason that was written down. If possible, make the team members themselves read their concerns aloud.
- Finally, end the meeting by coming up with a solution, or at least a plan to find a solution, for each concern brought up.
It’s a neat solution, and as both detailed in that podcast and in this Harvard Business Review article from September 2007 that I found, been implemented with a lot of success.
“In a session assessing a research project in a different organization, a senior executive suggested that the project’s “failure” occurred because there had been insufficient time to prepare a business case prior to an upcoming corporate review of product initiatives. During the entire 90-minute kickoff meeting, no one had even mentioned any time constraints. The project manager quickly revised the plan to take the corporate decision cycle into account.”
Now, I’m not in business school, I’m a lowly mechanical engineering student. I only know the words Six Sigma because I watched the first season of 30 Rock and Jack Donaghy convinced me Jack Welch was practically the second coming. The role “project manager” is functionally synonymous with “the oldest guy in the team who is willing to take shit from everybody.” But when I listened to this podcast, I realized it was particularly relevant to me because, recently, I had a project that failed, but it failed reasonably and after implementing something like a premortem without even realizing it, to help mitigating losses.
This past year, my first year as a transfer student to my university out of community college, I joined my university’s rocketry club. I myself don’t have a high-power rocketry license because you need to fly your own rocket to get them, and rocketry is an expensive hobby and my wallet probably has more dead flies than dead Presidents in it. But in high school, I still built high power rockets as part of competitions with my high school’s rocketry club, where we built the rockets and those with the licenses did the launching. My senior year I’d participated in a NASA sounding rocket competition, where my team did very well. It was a helluva’n experience. And my university’s rocketry club was participating in a similar sounding rocket competition (this one to an even higher target altitude), so I thought I could replicate our experience. After all, a university team would be even better than a high school on, right?
I won’t get into the gory details, but ultimately, everything went wrong. Our majority-senior team had most of its members busy with their capstone design projects in order to graduate to spend time on the rocket, which left me (a new transfer student to the university who was trying to cope with the change in workload from community college along with juggling part-time work) and two other (mercifully very experienced in rocketry but unfortunately also very busy) underclassmen as the majority contributors. A plan to get a professor to sponsor us monetarily in exchange for launching E.coli samples for him went awry because he realized it would be cheaper to just accelerate the E.coli in a centrifuge (which I don’t blame him for – it is cheaper.) And because we were a small club, we didn’t have dedicated workshops, so we had to find time to work in a freshman design lab which did not have all the equipment we needed. And worst of all – we (including me) were all confident we could make it, that it would all work out and we would make it to the competition launch in Utah. So actually talking about failure? It was, whenever it happened, met with flippancy.
Everything came to a head a week after Spring semester ended. Me and one other team-mate were in my apartment; he had (bless him for making the effort) drove up from two states away and cut short his vacation to help me get the rocket built. The final opportunity for a test launch was on Sunday, and that day, Friday, we found out that the freshman design lab’s head would need to get us permission to work in there since the school year was over. We likely wouldn’t get permission until Monday. At that time, all we had built was the altimetry and vibration sensor systems for our payload. The fins had just been epoxied into the fin canister, and would not be dried for at least 12 hours. We were so broke and out of time we planned to use a large nut driver bit as a deployment charge canister, and skipped out on safer closed-loop forged steel eye bolts because it cost five dollars more than the inferior open loop eye bolts that might rip apart if the rocket’s charges are too large and the Kevlar cables apply too much force to the eye bolts.
At that point, I was basically “in charge” of the team without meaning to be, and my decisions were final. We’d invested a fair amount of money in the project, but we had some money left in the budget that was allocated to a final launch motor reload, a GPS unit, and other items. The final launch was a month away, but we had team members who couldn’t show up because of family obligations or who had left on vacation. It was, basically, just the two of us. And so, while the epoxy dried, we sat down and thought. We basically did a premortem.
We considered we were several months behind schedule, on a schedule where the timeline was only 9 months anyway. We considered that we were running out of money, and we had no lab space for the time being. We considered the likelihood we could make it to test launch in two days, a requirement to get to launch for real. We considered all these, and whether we had the ability to address these problems. And my teammate and I realized we didn’t have the resources and skills to meet these challenges and still produce a rocket we could be proud to present at the final launch in Utah. It was crushing, really, to have to admit “we should give up.” I don’t like giving up.
The phone calls I made that night made me feel very small. Having to apologize to each team member who wasn’t present, and explaining why we couldn’t make it to test or final launch, was one of the most horrid things I’ve done in recent memory. And I had to do it for almost every team member. I thought of an e-mail, but it would not have sufficed; it wouldn’t have felt right to stay something so important over text. It had to be done with my own voice.
I console myself by saying that it could have been worse, that we could have failed at the end and not been aware we were failing. It was the best option – we could preserve our dignity to a degree, and we wouldn’t waste our time and the team’s money on trying to reach a goal we knew that we could not meet. I hope that we don’t mess up next year. Whoever is in charge next year, I am going to convince them of the efficacy of a premortem, and hopefully we can catch possible failures even faster, and take the appropriate action, so that we can get a rocket to Utah that my team and I can be proud of.
Don’t be afraid to imagine and talk about failure; it can help you escape actual failure.