Lessons Learned: Table-top Exercises

As part of the training curiculum at Penn State for departmental Business Continuity Planning, we encourage participants to attend our table-top exercise.  In this exercise, we break the training class into 4 groups.  Three groups are part of the Information Technology (IT) group and one is a business unit that relies on IT.

Throughout the training, the group plays roles in a fictitous college and need to make decisions as a power outage shuts down some of their critical applications that the business unit needs.  Some groups have recovery plans to refer to for decision-making, but some groups do not have plans. This makes it interesting, as the groups need to make decisions ad hoc.

 We have presented this training appoximately 5 times and every time I am fascinated by the different points of view each group brings to the same training.  It makes this table-top exercise enjoyable to run, since every group focuses on different aspects of the scenario, but some of the most notable "lessons learned" are what I wanted to share, since they are universal for any instiution in any event. 

Lessons Learned

• All business units should have plans.  It is important for IT to have disaster recovery plans, but that doesn't mean that the business units do not need to plan to continue their critical services.
• Communication, communication, communication....  it is the first thing that breaks down when an event occurs. Sometimes we forget to keep key areas in the loop as decisions that impact them are being made.
• If your unit cannot make decisions during an event, someone else will.  Sometimes, these decisions are not best for our area because the individuals making them are not familiar with your operations.
• We have the potential to create our own disasters.  By making poor decisions on how the situation is handled, we can escalate the event into a full-blown disaster rather then letting the event play out. The situation needs to be evaluted and the best course of action needs to be determined.
• The recovery strategies for IT and critical services should be realistic with the Recovery Time Objective* (RTO). * The RTO is the length of time critical services/systems must be recovered after an outage.
• Make sure your employees know what to say when approached by a reporter. Make sure they point them to single point of contact for all external communication.
• Sometimes, key indivudals who must make critical decisions will not be available during the event. Have a succession plan that is able to deal with key individuals not being available. 

These are just a few of the lessons learned from our scenario.  It is fun to run both IT and business units through this scenario.  Once these departments who have participated in this training have plans for their own critical services, they will be able to run execrises on their own plans.  Hopefully, they will remember these lessons learned when writing their own plans.