Despite the fact that the Business Continuity Institute’s (BCI’s) Good Practice Guidelines (GPG) has been around since 2002 and the British Standard, BS 25999, since 2006, there are still many widely different approaches to implementing Business Continuity (BC) to be found. These are not just differences between country or sector or size, or between qualified and non-qualified BC practitioners. They can be between BC practitioners with the same qualification, working in the same country, in the same sector, in organisations of the same size.
I was reminded of this during the past week, when I was giving the BCI’s GPG 5 day training course to a group of people who were going to take the BCI’s certification exam at the end of the week. About half of the delegates had worked in BC for some years, and were now looking to obtain a qualification. The problem that they were having was in trying to forget how their own organisations were implementing BC and to learn the BCI’s GPG. The organisations that they represented all had well established BC programmes, but why were they all different, and why were they significantly different from the BCI’s GPG?
My guess is that the reason lies in two areas. These are, firstly, that because the practice of implementing BC is very difficult, once they have found something that works they have decided to stick with it. Secondly, it is very likely that they first implemented BC back in the 1990s, before the BCI’s GPG, and that they have not had the time, money, or inclination to keep amending their BC processes and methods to keep up with current theory – they are too busy trying to keep up with changes in their own organisation!
I’ve just finished giving a 2 day Business Impact Analysis to some business continuity “champions” (staff who have been given the responsibility for implementing business continuity in their department) from a UK local authority, and it was interesting to see the misconceptions that these non business continuity professionals had about the Maximum Tolerable Period of Disruption (MTPD).
As the local authority had targets for service delivery, their first thought was to set the MTPD as the target. This led to setting very short Recovery Time Objectives (RTOs), and it quickly became obvious that the cost of putting in place the facilities to achieve these RTOs was way beyond what the local authority could afford.
The concept of the viability of a local authority being threatened was something that they struggled to imagine. However, the viability of a service being threatened was all too real as the powers that regulate local authorities might take the responsibility for the service away from the local authority with all the associated threats of disgrace and redundancy, or the local authority itself might simply decide that they need to outsource the service.
Having decided that the targets for service delivery were not appropriate, the course delegates settled on using “what we can get away with” as a working definition of MTPD. So, for example, in considering the Domestic Rubbish Collection service, the MTPD was set as the maximum length of time that the local authority could get away with not emptying the bins before the service was taken away and given to a third-party to undertake. This led to some surprisingly long MTPDs and, as a result, long RTOs that were easy to achieve (in many instances, the appropriate strategy being “Do Nothing”).
It seems that my paper on the definition of MTPD, recently published by Continuity Central, was well read and produced a lot of comment. That’s good, it shows that the debate is alive and well. However, there still seem to be a lot of people out there who still think that MTPD and RTO are one and the same thing – they’re not!
The blog that I posted last week about the MTPD and RTO for crossing the road should have made it clear why the two things are very different. To clear up and doubt, let me use another analogy, that of the amount of fuel carried by an aeroplane.
When an aeroplane flies from one place to another, a calculation is made of the amount of fuel required. This is not the amount of fuel that’s loaded into the aeroplane’s fuel tanks though. Some extra is added as a contingency. Think of the amount of fuel actually put into the tanks as the MTPD – once this has been used up the aeroplane can no longer fly. The calculated amount is like the RTO – this is the amount of fuel that is expected to be used. Nobody in their right mind would load just the amount of fuel that is expected to be used into the fuel tanks, because it leaves no room whatsoever for contingency. A slightly stronger head wind than was expected and the aeroplane crashes!
Analogies go only so far. I’m not suggesting that the RTO is calculated first, and the some time is added to make it the MTPD. The MTPD should be estimated first , and then the RTO should be set in the context of the costs and risks associated with the available recovery strategies, such there is an agreed contingency available between the RTO and the MTPD.
In reality, I’m sure that Business Continuity practitioners all know that there is a difference between the MTPD and the RTO. The problem is getting people to estimate the MTPD, or even being able to think about what it might be. So it’s easier to ask people what they’d like to see as an RTO rather than bothering them with a concept that’s difficult to explain.
Having problems explaining the difference between MTPD and RTO? Try using the following analogy.
You are about to cross the road, and see that there is a bus coming. You estimate that the bus will get to where you will be crossing the road in 5 seconds (this is the MTPD, because you need to have crossed the road by that time or the bus will run you down). So, you now have to decide how quickly you are going to cross the road (the RTO). Do you decide to spend 5 seconds crossing the road (MTPD = RTO) and set off at a speed that enables you to cross in 5 seconds, or do you decide to spend less than 5 seconds crossing the road (RTO < MTPD) and set off at a speed that leaves room for error. I would decide to spend less than 5 seconds crossing the road!
As it’s a new year, I’ve been following up on all those potential clients who said that they were intending to implement a Business Continuity Programme, but not just yet. The idea is to find out which ones might be looking for some assistance in 2011.
Depressingly, most of those that have replied have told me that they understand the value of Business Continuity, but it doesn’t rate highly in the list of things that they need to do in 2011, so they probably won’t be doing anything this year. The most shocking reply has come from a company that hosts websites for their clients, which does not even have a disaster recovery plans for the servers on which their clients website are hosted. How can they decide that having a disaster recovery plan is not a priority? Surely, in their business it’s essential.
So, here we are in 2011, and not a lot has changed. Business Continuity is not seen as a priority. Until, of course, a disruption occurs!
Predictions for 2011 have been rolling off the press over the last few weeks, and as most of these appear to be designed to spread doom and gloom I decided to sit down and think about what my predictions might be.
Essentially, I’m not very good at predicting anything. If I was, I wouldn’t be working in Business Continuity, but would be making a fortune out of my predicting skills, either by managing a successful share portfolio or gambling. So, whatever my predictions are, the chances of me being right are 50% – just like tossing a coin!
Firstly, I don’t think that things will be as bad as many commentators are predicting. Yes, there will be lots of disasters occurring round the world that cause immense amount of destruction and disruption (just look at what’s happened already in Queensland or Northern Ireland, and we’re only just into the new year), but no more than normal. In other words, your organisation will probably stand the same chance of being disrupted in 2011 that it was in 2010.
Secondly, despite the expected publication of the new ISO standard covering Business Continuity, I don’t expect there to be any great advances in either the theory or the practice of Business Continuity Management. The current debates about importance of things such as Business Impact Analysis and Risk Management will continue much as before, with no real consensus being reached. However, you will hear more about Resiliency, and look out for the new job title of Head of Resilience.