An emergency plan is a response prepared before a critical problem occurs. It gives the team a clear way to coordinate work, make decisions, and communicate when time is tight. The plan should fit the risks facing the project, such as a system failure, security breach, or data loss. section 10.3.3
Prepare the plan around a few practical questions:
- Who responds? Name roles and responsibilities for developers, system administrators, project managers, and other relevant team members. section 10.3.3
- How will people connect? Set primary and backup channels, keep contact details current, and specify when to report incidents and provide updates. section 10.3.3
- When does a problem escalate, and who decides? State escalation procedures and a decision-making hierarchy. Direct critical errors to a team rather than relying on one available person. section 10.3 section 10.3.3
When an incident occurs, first assess its severity and scope, including effects on systems, users, and stakeholders. Activate the plan, establish a shared communication channel, and keep people informed as the response changes. Gather team input, weigh risks and available options, and make decisions without losing sight of longer-term effects. Updates can be timeboxed according to severity. section 10.3 section 10.3.3
A website goes down
The lead stays calm, assigns recovery tasks, tells the project team the plan step by step, and reports progress. If a fix requires deployment, the Quality Assurance team needs the timing so it can prepare to test. Without coordinated communication, people may duplicate work while the error remains unresolved. section 1.2.1 section 10.3
Make the plan before it is needed, then keep its contacts and responsibilities usable. A clear response can reduce downtime and disruption while helping the team resolve the problem together. section 10.3.3 section 10.6
