Is it a Plan, or Just a Document?

When is a business continuity plan not a business continuity plan?

When it’s just a document.

What do I mean by that?

Every so often I bump into a consultant who tells me the same story over again, as if I hadn’t heard it before.  He tells me that some years ago he did some work for a company for which I used to work.

He says he created a plan for a particular risk that the organisation had identified.  Lo and behold, following an act of aggression against the company, the very scenario for which he’d done the piece of work materialised.  It was well handled by the company but, when he rang the head of the department that had taken the lead on managing it, they’d never heard of his plan.

On and on, he’d lament about the waste of his work and how the organisation had squandered resources by not using his “plan”.   I knew he mainly wanted a reaction from me, despite the fact he didn’t seem to realise I’d heard this tale from him before several times, so I’d smile sweetly and disengage quietly from the very public conversation he’d initiated, leaving him regaling his tale to whoever was left to listen.

But if I’d had to respond to him, would I have agreed with him?  Only to an extent.  And as a business continuity planner I’d have had a few wise words to share too.

You see, while I do see the waste of resource that had resulted from the lack of knowledge and use of his “plan”, I’d happily argue that he obviously didn’t deliver a “plan”.  Let me say that again: he didn’t deliver a plan.

He delivered a document.

And that’s not the same thing at all.

I’ve seen plenty of well thought out, beautifully formatted documents containing perfectly fit-for-purpose business continuity arrangements.  But unless the procedures in that document are well known, understood and probably practised by those who actually have to execute them they are not plans.  They are simply documents.

Not all continuity documents are plans.  Some documents are plans.  Some documents are plans that later become only documents.  And documents are things that either gather dust on shelves or get lost in a shared folder somewhere in the ether.  Documents don’t guide people during incidents, they are not plans.

You’re getting my drift?

So, if that consultant happens to be reading this piece, I’d like to suggest the following:

  • A plan is a plan when it has buy-in from those who have to execute it
  • A plan is a plan when those who have to execute it know what they need to do and how to do it
  • A plan is a plan when it’s a living document that’s known, understood, and kept current
  • A document that the right people don’t know about and haven;t practised isn’t a plan

To deliver a “plan” you need to:

  • Bring key stakeholders – including all those with responsibilities in the plan – into the planning process
  • Ensure everyone who needs to know about it knows about it
  • Ensure there is a long-term protocol for keeping the plan appropriately socialised, rehearsed and up-to-date
So did the company squander the resources, or did the consultant fail to deliver anything more than a document?  I think the latter.  If we pay to receive a plan, we should get a plan – rather than a document – right?
Was this useful?
Share it!
Subscribe - weekly news and a free course!

Related Articles

Share

About Author

admin

Leave a Reply

Your email address will not be published. Required fields are marked *

*

48,503 Spam Comments Blocked so far by Spam Free Wordpress

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>

UA-25954186-1
Loading...
Get free weekly newsletter:
No spam guarantee.
UA-26045347-1