Fall World 2014

Conference & Exhibit

Attend The #1 BC/DR Event!

Winter Journal

Volume 27, Issue 1

Full Contents Now Available!

DRJ Blogs

DRJ Community Blogs

Oct 11
2013

12 Things NOT to Include in Your BCM / DR Plan

Posted by: Alex Fullick in DRJ Blogs

Tagged in: dr planning , DR Plan , Documentation , BCP , BCM

Alex Fullick

When disaster – or a crises – strikes, organizations must be able to refer to a plan to help guide them through the tasks they need to consider executing to respond, restore and recover, systems and operations. All to often when a BCM / DR plan is pulled off the shelf or printed from a file, one ends up with a document that is huge in nature and breadth though rather slim and small in usable content.

This is because many organization put everything they can think of into their BCM/DR plans, which more times that naught, overshadows the actual content needed to be followed; the stuff that provides the detail on what to do. A BCM / DR plan should be action oriented not full of irrelevant information; irrelevant at the time of disaster, not irrelevant to the overall program.

I tend to follow a specific rule of thumb that says if there aren’t action items listed by Page 5, then it’s not an action oriented plan. It might address audit concerns, legal arguments and executive expectations but for the user – the one executing activities – it doesn’t address what they need and doesn’t provide it in a clear and concise manner.

So, noted below are a dozen things that shouldn’t be in your BCM / DR plan; the plan needed by users. It doesn’t mean that some of these things aren’t available in another document; an over-arching BCM program document.

1. Distribution Lists (Program Level): You can keep these separate, as names and positions will change constantly. It’s better to keep this separate, as it offers no value to the action plan.

2. Methodology Utilized: Sure you have a documented strategy for how you’re going to develop the program – and plans – but again, there’s no reason to have this in the plans themselves. It just adds more useless information to the plan and isn’t relevant when activities need to be executed.

3. Program Assumptions: You may have some assumptions related to the plan and they should only be those attributed to the plan. Program level assumptions should be kept separate and in a program document – not a plan.

4. Meetings / Schedules / Attendees: Who really needs to know who attended a meeting(s) in the past? No one that’s executing activities needs to know this. You may need to keep track of meeting attendees during the disasters, but not those planning meetings. They can be kept separately.

5. Maintenance Schedule (Program Level): How you monitor and maintain the various plans should be kept in a central location and kept at the program level. Can you imagine the confusion you’d have if you kept this type on information in every single plan? Repetition all over the place and most of it out of sync.

6. Names: The names of individuals change constantly due to new hires, those that leave their position and those that are promoted. Try to use position titles whenever possible – it’ll make it easier.

7. Document Audience: This is like the distribution lists and should be kept separate – if it’s even needed. The audience for an action-oriented plan should be anyone in the organization because you never know who has to pick it up and use it.   Keep in mind, the audience isn’t always the same group that has a copy of the plan.

8. BCM / DR Program Descriptors: You can define the program in a program document but don’t redefine it for a plan.

9. Document Approvals / Signoffs: For audit purposes, it’s always a good idea to keep track of signoffs in a separate document.

10. Project Management / Definition: Just like ‘Methodology’ you don’t need to define how you created the plan. That information can be kept separately in a program document or a document that outlines how plans were to be developed. Incorporating it into the plan itself is unnecessary fluff used only to increase the page count.

11. Reporting Mechanisms: Only those reporting mechanisms that are needed to execute the plan should be in the document. There shouldn’t be the overall reporting strategy in a document that details how to rebuild the mainframe.

12. Program Overview: If you have a plan that details how to vacate the facility due to a fire, do you really need pages and pages that describe how the rest of the program operates and what other functions are part of the program? No. What you do need though is to ensure that there is a link to the next stage of the program – the next plan – that needs to be activated/executed because of the disaster.

13. (BONUS) Test and exercise results and documentation.  This information is still good to have but it’s not relevant when a plan needs to be activated and followed.  it’s just extra fluff that hides the information users really need in their documents.  Keep your test and exercise results in documents related to tests.  Test information isn’t action-oriented and won’t help anyone in a disaster.

The larger the plan (document) the harder it is to follow and the longer it’ll take people to find what steps they need to execute / implement. If the document is kept action-oriented, then the fluff materials aren’t needed. All the fluff can be kept in a separate document at the program level so that its kept for audit and regulatory purposes – where applicable – and the plan can be better followed and utilized during a real disaster. Just remember, the KISS principle (and I don’t mean Gene Simmons here): Keep It Simple Stupid!

© StoneRoad (Stone Road Inc) 2013 - A.Alex Fullick, MBCI, CBCP, CBRA, v3ITIL

1122