Contingency plan example: what to do if a fix fails

A good contingency plan example starts with one honest assumption: the fix you picked might not work. If you decide that before you start, a failure is a planned event, not a surprise. This post walks through one worked case, a ten-line template you can copy, and a way to keep the record so the next attempt is smarter.

What a contingency plan is for a single fix

Here it means a short note you write before you try a fix. It answers four questions. How will I know it worked? How will I know it failed? What do I do next? Who needs to hear about it?

It is not a big risk register. It is a few lines for one problem and one fix, written while you are calm, so you do not have to invent a plan when you are annoyed that the fix did nothing.

The Lean Enterprise Institute's page on problem solving gives the idea behind it. It says a plan is viewed as a theory of both what will address the problem's cause and what it will take to implement a countermeasure to that cause, and that problem solving is never-ending, beginning rather than ending when implementation starts. A theory can be wrong. A contingency plan is what you do when it is.

Why fixes fail

These are common reasons, from the kinds of fixes you probably have tried yourself:

• The fix hit a symptom, not the cause. The post on quick fix or deep fix is about when each one is enough.
• The fix helped a little, and you called it done.
• Something else changed at the same time, so you cannot tell what helped.
• The fix needed something you did not have, such as time, money or someone's agreement.

Contingency plan example: late invoices, step by step

This example is made up. You run a small business, and customers keep paying invoices late. You write the problem as one line: Invoices are paid too late. Your first fix is a reminder email three days before each due date.

Without a plan, you send the reminders, wait a month and feel unsure what happened. With a plan, you decide four things first. They are below.

Step 1: write down what success looks like

"Get paid faster" can be argued either way. Pick something you can check in your own records.

For the example: the average number of days from invoice to payment goes from 30 to 21 within six weeks. Write down the starting number now. In a month you will not remember it.

Also decide what "partly" means. If the average lands at 27, that is not a failure and not a win. Give it a name and a next step in advance.

Step 2: set a trigger that says the fix has failed

A trigger is a date or a number that forces a decision. Without one, a weak fix drags on because nobody wants to call it.

Good triggers are simple:

• A date and a number: "If the average is not below 25 days at the end of week four, switch."
• A count: "If three invoices in a row go more than 10 days past due after a reminder, switch."
• A side effect: "If a customer complains about the reminders, stop and look."

Pick one or two. If you write six, you will not check them.

Step 3: choose a fallback and a rollback

These are two different things, and they are working terms of this post, not a standard.

• Fallback: the next fix you try if this one fails. For the invoices, ask for a deposit up front.
• Rollback: how you undo the fix if it makes things worse. For the reminders, switch them off and go back to how you invoiced before.

Check that the rollback is cheap. If undoing the fix takes a week, the fix is riskier than it looks, and you may want to try it on one customer first.

Write a second fallback too, because the first can fail. For the invoices, the second could be changing payment terms from 30 days to 14.

Step 4: name an owner and who to tell

A plan nobody owns will not run. Name one person for each of these:

• Who looks at the number on the check date?
• Who decides to switch to the fallback?
• Who has to be told, and what will you say? For example, the person who sends the invoices, or a customer who will see a change.

If you work alone, you still do this. Put the check date in your calendar as a meeting with yourself, or tell one person your date so they can ask you about it.

What happens at week four

Back to the example. At the end of week four you look at your records: the average is 27 days. Your trigger was 25, so the plan says switch. You did not have to argue with yourself.

The reminders did help, from 30 to 27, so you mark that solution as partly and keep it. The rollback is not needed. You start fallback 1, asking for a deposit up front on new invoices, and you set a new check date four weeks on. Fallback 2 stays on the map as an idea.

The example as a map: the first fix is partly, fallback 1 is being tried and fallback 2 is an idea.

A contingency plan template you can copy

Copy these ten lines into any notes app and fill them in.

1. Problem: one line, in plain words.
2. Fix I am trying: what it is and when it starts.
3. Success looks like: a number or a clear yes or no, plus the starting value.
4. Check date: when you will look.
5. Failure trigger: the date or count that means switch.
6. Rollback: how to undo this fix, and how long that takes.
7. Fallback 1: the next fix.
8. Fallback 2: the one after that.
9. Owner: who decides.
10. Who to tell: names, and what you will say.

For the example, it fits in a few short lines. That is the point. A plan you will read beats a thorough one you will not. If you want to find the weak spots before you start, the pre-mortem post lists what could go wrong first, and how to know when a solution has really worked helps you pick the success line in step 1.

Learn from the failure and update the plan

When a trigger fires, spend ten minutes on the record before you move on.

1. Mark the outcome honestly: worked, partly or failed.
2. Write why you think it went that way. One or two lines is enough.
3. Check your assumption about the cause. Late invoices might come from unclear invoices, not forgetful customers.
4. Update the plan before you start the fallback, with a new trigger and a new check date.

If a fix has failed more than once and you keep trying it anyway, the stop doing list post is about dropping it.

Keeping the record on a map in Problem Graph

A list of failed fixes gets long and flat. A map keeps the links visible. In Problem Graph you write the problem as one line, put it in a lane (personal, work, expert or scientific), attach each solution you try and mark the outcome as worked, partly or failed. You can add a fallback as an idea first and mark it as trying when you start it. A solution that failed stays on the map as a failed solution, which is what you want to see next time.

You can also link problems that belong together, even across lanes. Late invoices could link to a cash flow worry in your work lane and a budget problem in your personal lane.

If you are short of fallbacks, Problem Graph shows similar problems other people have shared and which of their solutions worked. You can borrow one into your own graph with one tap, and it keeps a link back to where it came from. You can also ask for suggestions. The AI's answers are proposals to test, not advice to trust. The public network is new, so do not count on finding a match today.

Frequently asked questions

What is a simple contingency plan example for a failed fix?

You try reminder emails for late invoices, set a target of 21 days average payment and set a trigger of 25 days at week four. If the trigger fires, you switch to a fallback such as a deposit up front, and you can roll back the reminders if customers dislike them.

What is the difference between a rollback and a contingency plan?

A rollback undoes the fix and returns you to where you started. A contingency plan is wider: it holds the rollback, the next fix to try, the trigger that starts them and who is responsible.

How many fallbacks do I need?

Two is a sensible limit. One covers the likely failure and a second covers the case where the first fallback fails too. A third is hard to keep up for one fix.

What if the fix only partly worked?

Record it as partly, keep the part that helped and decide whether to add a second fix or move to the fallback. The success line and trigger you wrote at the start make that call easier.

Get started

Pick one problem you are working on now. Write it as one line, attach the fix you are trying and add one fallback as an idea. When the check date comes, mark the outcome.

Try Problem Graph: it is free, and you can look around the public network without an account. It runs in your browser and works on your phone.