It was otherwise an unmemorable day in 1998. Oren Jacob, the associate technical director of Toy Story 2 was sitting next to a co-worker talking about making a change to a character in the upcoming movie. They happened to glance at the screen mid-sentence and saw the number of files in the directory rapidly decreasing…40…30…20…10…4…
A sense of panic ensued, triggering Oren to call down to the server room, directing the team to yank every cord out of the server. When it was all said and done, 90 percent of the movie had been deleted.
Upon further investigation, someone had likely run a command to clear out unwanted files; however, they mistakenly chose to run it on the core directory where it began to destroy every…single… file. In most places, access to the master directory would have only been to a few users. At Pixar, almost everyone working on a film had both read and write access.
Fortunately, this happened once before at Pixar and they had wisely invested in a backup system. Unfortunately, the backups had not been continuously tested, and only up to version 20 of the files were captured (the team was on version 420). Thanks to the luck of a remote employee who had downloaded the entire file tree, Pixar was able to limit their losses to two weeks’ worth of rework; however, this is still a multi-million dollar loss in productivity.
Pixar’s story is a lesson to us all about the importance of having a contingency plan.
A contingency plan — also known as a “plan B” or “backup plan” — is used by organizations to effectively respond once a risk occurs. The intent is to reduce the impact of the risk. This is not to be confused with a mitigation plan, whose aim is to reduce the probability that a risk occurs or avoid part of its potential impact.
Creating a solid contingency plan and creating a risk mitigation plan actually have the first few steps in common.
First, grab sets of post-its and ask individuals to list risks, however improbable. One idea per post-it. Think about…
Then, share the ideas publically and allow a bit of time for some additional brainstorming (in case someone’s idea sparks another). Begin to cluster like risks together and name each cluster.
Draw a large 2×2 matrix. Name one axis “impact” (low, medium, and high), and the other “likelihood” (low, medium, high). Copy your cluster names on new post-its and place them accordingly. Do your best to not have two clusters with the same position on either axis, debating why one is a higher likelihood or impact than another is a worthwhile exercise.
It’s now a matter of preference on how many risks to focus on. Those ranked as high impact, high likelihood should make the cut. After that, it’s a matter of opinion on the high/medium or medium/high risks. In the case of contingency plans, I would recommend focusing on anything that has a high impact, regardless of the likelihood:
At this point, if you were to branch off to create a mitigation plan, the important question to ask would be “why would this occur?” In the case of a contingency plan, the “why” is immaterial as the presumption is that the risk has already occurred.
In this plan, you’re going to answer a few key questions:
Try this statement starter as a brief synopsis for your plan: In the event of (specific measures),(conditions),(which individuals),(response enacted)__.
An example: In the event of a lightning strike less than five miles away and for planes on the ground, pilots are directed by air traffic control to return their airplane back to the gate and await further instructions.
An important step that’s often missed is the sharing and retesting of the contingency plan. In the case of Pixar, they had a backup system. The flaw was that nobody continuously tested the contingency plan to ensure the backups were complete and usable.
We recommend having regular, dedicated time to review and update your plan, as well as test to ensure your plan is effective.
For decades, Apple has been the model for supply chain professionals. The reason behind this is largely because they built contingency planning into their sourcing strategy. This is a great example for modern businesses and highlights how important contingency planning can be.
For the same component, Apple uses multiple suppliers spread across different geographies. While they are estimated to concentrate over 95 percent of sourcing across their top 200 suppliers, they maintain relationships with another ~600, enabling them to quickly pivot if a disaster or interruption were to occur.
Going back to our list above, you can easily see how this plan specifically ties to identified risk scenarios:
As COVID recedes, Apple is leaning even more into this strategy, asking suppliers to invest in further geographic diversification.
A 2023 study shows that — in the US — 61 percent of customers will walk away from doing business with a brand they love after one bad experience. It’s worth repeating: we are all one bad experience away from potentially losing almost one-fifth of our customers.
The goal of a contingency plan is not necessarily to avoid all service interruptions, but rather to minimize their impacts through a series of documented steps that right your business quickly.
Unsurprisingly, the speed of problem’s resolution correlates highly to:
Start today by gathering a small group of the right people to:
LogRocket identifies friction points in the user experience so you can make informed decisions about product and design changes that must happen to hit your goals.
With LogRocket, you can understand the scope of the issues affecting your product and prioritize the changes that need to be made. LogRocket simplifies workflows by allowing Engineering, Product, UX, and Design teams to work from the same data as you, eliminating any confusion about what needs to be done.
Get your teams on the same page — try LogRocket today.
In this article, we’ll discuss outcome-driven roadmaps and why they can actually be more efficient and productive than feature-driven ones.
MQ Qureshi talks about his experience with “unexpected sparks of brilliance” — solutions get to the core of what you’re trying to do.
A product review is the moment where you evaluate what the team created over the last development cycle and align on the next steps.