Succeeding against the odds: The ‘Apollo 13’ moment in crisis management
In project management, as in life, there are times when things do not go as planned - and occasions when things go completely off the rails. In these moments, we can take a lesson from Apollo 13, the ill-fated 1970 US mission to the moon, and succeed against the odds.
After an explosion in one of their oxygen tanks, the astronauts couldn’t land on the moon as intended, and had to jury rig what working equipment they had left on their spacecraft to make it back to earth alive. To do so they had to think outside the box and to find a way to succeed though the odds were stacked against them.
Over half a century later, admittedly with no lives at stake, my team faced their own Apollo 13 moment, when one of our digital services failed repeatedly to perform to the required level the day it was designed, tested and built to do so. We had extensive backup plans, failsafes and contingencies for all conceivable scenarios but, like the explosion in Apollo 13’s oxygen tank, the situation we faced on that day was something else entirely and taught us to avoid rushing to solutions when we should be focusing on problem solving. Like Ground Control in the Apollo 13 mission, we have a tendency to prioritise saving time and money by focusing on being solution driven and rushing to quick fixes before we even have a chance to fully understand the problem we’re grappling with and the long term impact for the solutions we should be proposing.
To do so, the team went back to basics, starting with answering the high level question of “What problem are we trying to solve here?”. Truly understanding and defining the problem we are trying to solve and ensuring the answers to that question are framed in a way that opens up avenues of discussion and possibilities. Then instead of leaping forward toward a solution for the well defined problem, we went backwards to try and map out how did we got here in the first place. We collected data based on the known facts to help us organise our thoughts, give insights and provide evidence for the diagnosis as it’s take shape.
By doing so, we didn’t just develop, test and iterate a scalable solution for our problem. We have developed and implemented a problem-solving process instead of taking a solution lead approached. So we have learned two valuable lessons from this. First, on the more mundane level, we have found yet another, completely novel way in which the service can fail, and now know to diagnose and fix this problem. But more importantly, we have learned a lesson in solving problems and not solutionizing them.
On our solving problem journey, we went from shock and denial (‘Houston we have a problem here’), to anger and frustration (‘Let’s work the problem, people. Let’s not make things worse by guessing’) to developing a way to identify and address the problem and finally, a viable solution. More than a viable solution, we also had new backups and contingencies in place, risk and decision logs to bulletproof future products and most importantly, the team’s hard-won experience in crisis response will stand them in good stead to see them through any future crisis.
The next day, the solution worked and the service was successful. We had managed to work our unconventional problem with agility, creativity, initiative and a willingness to abandon the usual solution driven approach. Hats off to my team in their finest hour. Failure was not an option.