Plan Development and Documentation
Structure that survives contact with reality
Plans must be usable under stress. Candidates should know the standard components: purpose and scope, assumptions, roles and responsibilities, activation and escalation criteria, communication procedures, procedures and checklists, resource and dependency lists, contact data, vital records, and appendices. Plans should be written at the level of detail the user needs, with checklists for execution and references for depth.
Know the plan hierarchy: emergency response plan, crisis management/communications plan, business continuity plans for functions and sites, IT disaster recovery plan, supplier contingency plans, and enterprise-level program plan. Plans should be consistent in terminology and reference each other rather than duplicating content.
Good plans are outcome-oriented, assign named roles rather than only individuals, include decision authority, and define success criteria and reconstitution steps. Version control, ownership, review dates, and distribution lists are essential. Avoid over-detailed procedures that become obsolete quickly; put volatile detail in controlled appendices.
Traps
- Writing plans that are too long to use during an incident.
- Naming only individuals, so the plan fails when that person is unavailable.
- Omitting assumptions, which hides the conditions under which the plan breaks.
- Failing to document reconstitution and return-to-normal steps.
- Duplicating content across plans instead of referencing a single source.
Rule of thumb
A plan is complete when a competent person who did not write it can execute the first hour using only the document and reach the designated decision point.
Worked example
A finance continuity plan lists the controller by name. Review replaces this with the role "Controller or delegate," adds a delegation-of-authority appendix, and includes a one-page activation checklist. A peer walkthrough confirms the first hour is executable without the author present.