How to Annoy Top Management

The Business Continuity Institute’s Good Practice Guidelines (GPG) states that tactical business continuity options should be presented to top management, who will make decisions on which tactics should be used and approve the resources and funding for any projects that are required to implement the tactics. It then goes on to state that the business continuity practitioner should then consolidate all the resource requirements from the chosen tactical options to make sure that they are consistent, not in conflict, and to determine how best they should be sourced. This consolidation should then be presented to top management for agreement to any changes in tactics that may be required or to the projects that have been agreed.

So, let me get this right. You present the tactical options to the top management so that you can get them to make decisions and authorise expenditure. Then you consolidate the resources required and go back to the top management for any changes that may be required. What do you think the response from top management is going to be when you go back to them? I suggest that they might just say “Why the hell didn’t you do all this consolidation work before asking us to make decisions in the first place? If you want us to make decisions, give us all the facts, not just a few of them!” Or, maybe you’d just have your contract terminated! 

If the theory doesn’t work in practice, then the theory is wrong. My advice is, consolidate the tactical options before going to top management in the first place. It’ll save a lot of time and aggravation, and possibly your contract.

Maximum Tolerable Impact of Disruption (MTID)

As if we didn’t have enough jargon and acronyms in the world of Business Continuity, I’ve met someone recently who has suggested a new one – the Maximum Tolerable Impact of Disruption (MTID). This is largest impact resulting from a disruption that an organisation can tolerate.

Believe it or not, this new jargon did not come from a Business Continuity practitioner – it was suggested to me by someone from outside the profession who had asked me to explain the term Maximum Tolerable Period of Disruption (MTPD). He couldn’t quite understand why there was a term for the point in time at which the disruption became intolerable when there wasn’t an equivalent term for the impact. After all, when you undertake a Business Impact Analysis you are looking at two things – Impact and Time.

If you imagine a graph where the horizontal axis is Time and the vertical axis is Impact, then you can draw a curve to represent the impact on the organisation of a disruption over time. This curve will often start to rise more steeply as time goes on, and for some organisations it might not be continuous but increase in steps when penalties start to kick-in. The MTPD will be identified at some point on the horizontal Time axis, but this has been determined by identifying the impact. In other words, you identify the point on the vertical Impact axis at which the impact becomes intolerable, and then take a horizontal line from that point across the graph until it meets the curve, and then take a vertical line down from the intersection to identify the MTPD.

The person who suggested the idea of the MTID to me actually pointed out that it’s the impact over time that we’re initially identifying, and that if we have a term for time then surely we should have one for impact. I can’t fault his logic really, except that I don’t want to introduce yet more jargon and acronyms.

Mind you, “emptied” has a nice ring to it!

Party Definition of Business Continuity

For some years now I have been looking for a definition of Business Continuity that I can use at a party, when some attractive person that you’d really like to get to know asks you what you do, and when you reply that you work in Business Continuity you need to be ready with a quick and simple response to the inevitable “Oh, that’s interesting, what’s Business Continuity?” If you reply “It’s an holistic management process…….”, as per the Business Continuity Institute’s definition, you’ll soon find that the attractive person that you’d really like to get to know has drifted away to find someone who’s a bit more exciting.

I’ve been doing quite a bit of Business Continuity training recently, and I always ask the students to give me a definition of Business Continuity that I can successfully use at a party. Sadly, no-one has come up with one interesting enough to prevent that attractive person drifting away, but I think that I’m getting closer.

The best one yet is “Business Continuity is keeping things going when things go wrong.” Has anyone out there got a better idea?

BCM Life-Cycle Diagram

The Business Continuity Management (BCM) life-cycle diagram used in BS 25999 and by the Business Continuity Institute (BCI) in their Good Practice Guidelines has always made me a bit uneasy, but it was only the other day that it eventually dawned on me why I was never really comfortable with it.

Embedding Business Continuity in an organisation’s culture is the goal of the BCM process – in other words, it is the target. The BCM life-cycle diagram looks like a target, but instead of being at the centre of the target, Embedding is placed in the outer ring. This is all wrong, Embedding should be at the centre as it’s what the process is trying to achieve.

The BCM process itself consists of four stages, which are correctly shown in the diagram as a  four stage life-cycle, but they should revolve around the target, Embedding, and not around BCM Policy and Programme Management. The Management element is what holds the whole thing together – in other words it is the rim of the life-cycle wheel, not the centre. Also, BCM Policy provides the context within which the required capabilities will be implemented (note the use of within – this implies that it surrounds the process).

So, to my mind, what is wrong is that Embedding and Management are shown in the wrong places. Swap them round, putting Embedding at the centre and Management around the rim, and the diagram becomes self-explanatory.