Contingency Plan Example and Template: Keep a Small Project Moving
Use a complete contingency plan example and free template to define a trigger, decision owner, fallback steps, and return conditions for a small work project.
A contingency plan says what you will do if a specific disruption occurs. It needs a clear trigger, someone authorized to activate it, workable fallback steps, and a definition of what the fallback must preserve. “We will figure something out” is an intention, not a plan.
Download the editable contingency plan. It includes a reusable form, the completed workshop example below, and a rehearsal checklist. It is designed for ordinary work projects, such as a delayed review or an unavailable presenter, rather than emergency response or technical disaster recovery.
The most useful backup is often smaller than the original plan. Protect the result people need before trying to reproduce every detail of the original delivery.
What belongs in the backup plan?
Write down the outcome, disruption, trigger, decision owner, fallback steps, resources, communications, and return condition. Each field should answer a question someone would otherwise have to settle while the disruption is already happening.
| Field | Question it answers |
|---|---|
| Essential outcome | What must still become possible? |
| Disruption | What specific event would interrupt the normal plan? |
| Activation trigger | What observable condition tells us to switch? |
| Decision owner and backup | Who can authorize the switch if the first person is unavailable? |
| Fallback steps | What happens, in what order, and who does it? |
| Required resources | Which files, people, access, or approvals must already exist? |
| Communication | Who needs to know what has changed? |
| Return and follow-up | When do we resume, and what unfinished work remains? |
Asana's contingency planning guide describes a backup response to disruption. Keep that distinct from prevention: confirming a presenter early may reduce the chance of cancellation, while preparing an alternate delivery is what you do if cancellation still happens.
Avoid turning the form into a list of every imaginable disaster. Start with a plausible failure that would interrupt a real commitment. If nothing important changes when it occurs, it may not deserve a separate plan.
Connect the fallback to your existing workback schedule. A backup that needs two days of preparation cannot rescue a deadline when you activate it ten minutes before delivery.
What is a complete contingency plan example?
A completed plan names a usable alternative and verifies the resources behind it. The fictional example below concerns an internal workshop; its timings are illustrative choices, not measured best practices.
Normal plan: Morgan runs a 30-minute session on the updated expense process for a new-starter group on Tuesday morning.
Essential outcome: participants can locate the approved instructions, identify the right submission route, and know where to ask a question. The outcome does not require Morgan personally to deliver a live presentation.
Disruption: Morgan becomes unavailable before the session.
Trigger: Morgan reports being unable to present, or availability remains unconfirmed at 3 p.m. on the preceding workday. The team chooses that point because an alternate presenter still needs time to prepare.
Decision owner: Casey activates the fallback. Sam is the authorized backup if Casey is unavailable. Both have agreed to this arrangement.
Fallback A: Sam delivers the existing walkthrough using the approved slides and instructions. Sam has already checked access and agreed to take the session if activated.
Fallback B: if Sam is also unavailable, Casey distributes the approved written walkthrough through the normal internal channel and arranges a question session when an appropriate person is available. Casey confirms that this still meets the group's immediate need before choosing it.
Preparation: the slides, current policy links, and a list of likely questions are stored in the agreed team location. Lee confirms the policy content. Sam opens the files before the event rather than relying on Morgan's laptop.
Communication: participants receive a brief message explaining the changed format, where to find the instructions, and how to submit questions. The communication plan identifies the sender and channel.
Return condition: normal sessions resume when an available presenter and current materials are confirmed. Questions left unanswered are assigned to Lee or the relevant policy owner, with a reply commitment.
This example has two fallback routes, but that is not a universal requirement. Its value is that each route has an owner and a testable dependency. Adding a third vague alternative would not make it stronger.
How do you choose a trigger people can use?
Choose an observable condition early enough for the fallback to work. Avoid triggers such as “when things look bad,” which require a new argument about seriousness at exactly the wrong moment.
Good triggers refer to a confirmed event, a missed commitment, or a defined decision point. Examples include a reviewer declining the booked slot, a required file remaining unavailable at the preparation deadline, or a supplier confirming that delivery cannot meet the agreed date.
Then check three things:
- Who will notice and report the condition?
- Who can authorize the fallback?
- How much preparation time remains after activation?
The Asana guide connects risk identification with response planning. Apply that connection narrowly: each scenario should lead to a specific action, not merely a warning label.
Be careful with triggers that are too early. Switching at the first uncertain message may waste work or confuse participants. Be equally careful with triggers that are too late. Waiting for certainty can remove every useful alternative.
Write a short decision rule: “If the review slot is not confirmed by the point needed to prepare safely, the project owner chooses the reduced release or revises the date.” Make clear which aspects the owner can change and which require someone else's approval.
How do you test a plan without causing disruption?
Walk through the scenario with the responsible people and verify the resources it depends on. For an ordinary small project, you can discover many gaps without switching off a live system or interrupting real work.
In a suggested 15-minute rehearsal, ask the backup person to locate the current files, explain the trigger, identify who authorizes activation, and describe the first action. That duration is simply a starting point; use more time if the exercise exposes missing access or unclear authority.
Microsoft's business continuity guidance emphasizes practicing plans and updating them when exercises reveal wrong assumptions. Borrow the learning principle here, not enterprise fault-injection techniques that your team is not authorized to perform.
Record what you actually checked. “Sam opened the approved slides and located the policy contact” is evidence. “The plan should work” is a prediction.
If the rehearsal fails, assign the repair before calling the backup ready. A substitute who cannot access the materials is not yet a substitute, however confidently their name appears on the form.
What happens after the fallback is activated?
Communicate the changed arrangement, track unfinished work, and confirm when normal delivery can resume. Activating a backup is a decision with consequences, not the end of the coordination work.
Keep a brief record of what triggered the switch, who approved it, which route was used, and what remains incomplete. Avoid restoring the original format automatically if the replacement already meets the need more simply.
Use a lessons learned review afterward. Separate a rare disruption from a recurring dependency problem. If the same backup is used every week, it may be time to redesign the normal process.
Finally, adjust the day around the changed commitment. Do Only 3 Things a Day helps you choose a few meaningful outcomes and protect attention for them. The contingency plan protects the result; the daily reset makes room to deliver it.
Frequently asked questions
Is a contingency plan the same as a risk register?
No. A risk register tracks uncertainties, ownership, and responses across a project. A contingency plan gives the practical fallback for a particular disruption. The two can link to each other.
How many scenarios should a small project cover?
Start with the few plausible disruptions that would seriously affect delivery and for which preparation can help. There is no useful universal number. Add scenarios when their consequences justify maintaining another plan.
Does this replace an emergency or disaster recovery plan?
No. This template is for routine project coordination. Safety incidents, regulated operations, cybersecurity events, and system recovery require the appropriate specialist procedures and authorized response teams.
How often should the plan be reviewed?
Review it when people, access, dependencies, or the intended outcome change, and before the relevant delivery point. A plan can become obsolete immediately after a staffing change, regardless of its scheduled review date.