The Plan That Lived on One Laptop
A mid-sized manufacturer has a well-written business continuity plan: 180 pages, approved 18 months ago, covering 14 critical processes. It is stored on the BC manager's laptop and on a shared drive that requires VPN access. The BC manager resigned three months ago and the role is vacant. The plan's contact list was last updated 18 months ago. When a flood closed the main plant last month, the operations director could not open the plan because the VPN was down and the laptop was locked in the departed manager's office. Staff improvised. Production resumed at a secondary site after 31 hours, against a plan target of 12 hours. The CEO has demanded a review.
1. What are the root causes of the 31-hour recovery, and how should they be prioritized?
Read the worked answer
The 31-hour recovery is a symptom. The root causes are plan accessibility, plan ownership, and plan currency - in that order of immediacy.
Root causes:
- Accessibility failure. The plan was stored only on a personal device and a VPN-gated drive. In a flood, the VPN and the laptop are both likely unavailable. A plan that cannot be retrieved is not a plan.
- Ownership failure. The role was left vacant for three months with no deputy and no handover. Continuity of the continuity function was never planned.
- Currency failure. An 18-month-old contact list is almost certainly wrong. The plan was approved but not maintained.
- Validation failure. The 12-hour target was never tested against reality; the 31-hour result suggests the target was aspirational.
Prioritization:
- Immediate (days): Make the plan accessible - printed copies at each site, offline copies with named holders, a cloud copy independent of VPN. Update contacts.
- Short term (weeks): Assign an interim owner and a named deputy. Establish a maintenance schedule.
- Medium term (months): Re-validate the 12-hour target through exercise; revise the plan to reflect actual capability.
Judgement: Accessibility and ownership are fixed first because they are cheap, fast, and prevent recurrence. Target re-validation is slower but determines whether the plan is honest.
2. How should the organization design plan maintenance so this does not recur?
Read the worked answer
Maintenance fails when it depends on one person's diligence. The design must make currency a structural property of the plan, not a personal habit.
Design elements:
- Named owner and deputy. Every plan section has an accountable role (not a name) and a deputy. Vacancies trigger a handover checklist.
- Trigger-based review, not just calendar-based. Review on schedule (at least annually) and on trigger events: organizational change, new site, new critical supplier, major system change, post-incident, post-exercise.
- Tiered content. Separate the stable content (strategies, roles, procedures) from the volatile content (contacts, call trees, supplier numbers). Volatile content is reviewed quarterly and stored in a system of record, not in the document.
- Distribution model. Multiple independent access paths: printed site copies, offline encrypted copies with named holders, and a cloud repository not dependent on VPN.
- Verification. Maintenance is verified by exercise, not by signature. If the plan says 12 hours, the exercise must show it.
- Metrics to the board. Plan currency (percentage of sections reviewed on schedule), contact accuracy (percentage verified in last quarter), and exercise-validated RTO versus planned RTO.
Key principle: A plan is a living capability, not a document. The measure of maintenance is whether the plan works when the person who wrote it is gone.