Let’s start by looking at how it helps you:
I recently compared a situation I had encountered at a clients’ with the Star Wars movie, as a matter of fact. We didn’t have an inter-galactic battle on our hands but the issues that faced the business were as critical as those that the Rebel Alliance faced against the Evil Empire. When, not if, things go wrong, how do you go about continuing while you fight a mighty struggle to get things back to normal?
Initiating the BCP project is very important, there are some essential activities that must be undertaken:
The next steps are similar to that of any project that is undertaken such as ensuring a clear set of terms of reference, project objectives, scope, deliverables, timetable and milestones. Clarity on scope is essential, and it is important to understand the business wide nature of a BC plan, and at the risk of repeating myself, it should not be limited just to IT.
The first major set of activities in BCP is to assess the business risks and the impact of potential emergency incidents that might occur. Typically, you could categorize the different emergency incidents in to the following categories:
For possible incidents in each of the categories above the project team should look at the potential impact on the business of such an emergency happening. Normally, a ranking and/or scoring system is used to differentiate the extent of impact that each possible incident will have on the business.
The following step is one of the most important and reflects the business risk assessment. In this step, the project team would look at each of the key business processes and assess the risk that is faced and impact of failure of these processes on the business. Having done this, the project team determines time bands for service disruption and again assigning scores to the bands might be useful. The table below is an example of what could be prepared, with a tick in each of the places where a significant impact might happen. The meaning of significant is up to you to define since this varies from one business to another.Table here
For each of the time-bands the financial impact should also be quantified. This should be assessed based on anticipated lost revenue plus projected costs of recovery. Once you have both the estimated revenue impact and cost to recover, it makes prioritizing considerably less difficult.
Now we get to the IT part, as you can see most of the previous activities have focused on the business itself. It is important to be absolutely clear about what is installed, in terms of hard, software and networking components. Therefore, a technology inventory recording the detailed specification of installed components with version, release and any configuration details is essential to get right. Each component then needs to be tied back to which business processes are dependant on it so that the business derived risk for each component can be identified.
The other vital component of the IT environment is people, the internal staff as well as contractors and suppliers. People need to be identified with the system components and where critical, directly with business processes. Contact information and contracted response time information (for suppliers) is important to have available.
The risk assessment is not complete without determining the existing emergency procedures that are implemented. The existing recovery procedures for IT and other functions should be understood prior to developing a BC plan – where these exist they will often have high aspects of authority (and responsibility) showing clearly who has authority for example, for effecting building repairs in emergencies.
Having amassed all of the information that we have gone through above, the project team would start to look at recovery strategies to determine which ones to adopt. The risk assessment that was conducted earlier can be used as a guide for the evaluation of risk versus return when the cost of the different strategies is examined. Typically, recovery strategies need to be determined for:
All of the above are important but as the project team develops alternate strategies for each of the incidents/ risks potentially faced in the different time bands, the project team will then be in a position to determine the cost for each as well as the benefits each brings. Coupled with the risk assessment this allows the project team to short-list and then select strategies to be adopted in a structured manner.
I will go into the IT alternatives on a high level basis because I think it is important to understand, broadly, what is available:
Having determined the various strategies that the BC plan will adopt, the next piece of work is looking at people. An organisation structure for emergencies needs to be drawn up, with clear defined authorities and responsibilities assigned. The BC plan Co-ordinator, emergency contacts for internal staff, suppliers and contractors need to be prepared with links to the roles that each is meant to play.
A specific strategy for manpower recovery needs to be in place. It is likely that if a natural disaster has taken place then employees will have personal emergencies which they will be addressing prior to the business. The recovery strategy needs to take into account the needs of the business, the employees and their families. The co-ordination required to contact and arrange for staff to follow through on a BC plan is significant and therefore often under-estimated.
The document and procedures that are required for recovery and business resumption are important and therefore the project team must look at these as well as aspects of off-site storage, media handling and general supplies.
Having decided on the strategies to be adopted the project team should be in a position to develop a budget from establishing and maintaining a BC plan and one for recovery situations.
Having developed the BC plan the next step is to implement it. This is almost a project in itself – training and communication place a vital part in helping staff understand what is meant to happen and who is meant to be responsible for actions.
Before implementing fully, the BC plan needs to be tested. Testing is absolutely essential to ensure that as many of the problems are caught outside of a real disaster situation. Therefore, testing has to be carefully planned. I know of one large multi-national organisation in the UK, that had separate services from different telecom companies, one a primary and the other as back-up – when they tested (by asking the nice people at the exchange to disconnect the voice and data lines) they found that the back-up went down as well. After a little bit of investigation it was found that the back-up provider had simply rented lines from the primary service provider.
Testing should show the project team where they can improve and refine the BC plan further. In addition, the business operation will continue to change as the business responds to the market – these changes have to be reflected in the BC plan too. It should be a truly living document – if that is not done then the BC plan runs the very serious risk of sitting on the shelf gathering dust and slowing becoming redundant. Let’s be clear, there is a lot that goes into making a BC plan and even more into making it work properly.