The maintenance of a Business Continuity Management (BCM) program and keeping everything current is one of the hardest things for an organization to accomplish. Many may be involved and support the initial projects – such as Risk Analysis, Business Impact Analysis (BIA), department Business Continuity Plans (BCP) and other components – but once these are completed it becomes difficult to maintain the original momentum and ensure that things are continuously reviewed and updated on a regular basis. Often, department leads will move on to other more important issues and believe that the BCM program is in good shape because they got it developed. However, it’s only as good as it supported and maintained. What was good last year – when components were originally completed and the enthusiasm was high – won’t be sufficient for the organization any longer because the BCM program hasn’t amended to reflect changes in the organization. As an example, it could be that technology documentation doesn’t incorporate new servers or other technology components, whether updated, replaced or reconfigured items. Or BCP plans that don’t account for new services and processes performed by various departments or how the new services and processes aren’t incorporated and updated in BIAs.
Are there any tricks to keeping some – if not all – of this documentation updated and current? Yes, there are a couple of unique twists that can be incorporated into a BCM program to help it keep current and up to date. Here are just three (3) possibilities to help keep various program components and related documentation up to date.
- First, utilize an organizations IT Change Management process. Let’s face it, change is constant so what better way to stay consistent and current that having a working partnership with the company Change Manager? Now let’s make one thing clear, this works for the components for Technology Recovery Plan (TRP) only and doesn’t work (not very well) for Crisis Communications or Media/PR Spokesperson components. As someone who has been a Change Manager, I’ve seen many Request For Changes (RFC) submitted that announce new servers being installed or reconfigured for an existing service or a new service. So when this occurs, make note of the new server (name etc) and incorporate the information into the TRP plan. Depending on how your plan is developed and set up, will determine what information you need and how best to do it. Still, if the BCM practitioner is part of the Change meeting other IT professionals are telling the BCM practitioner (in a roundabout way) what they should be taking note of it; what’s changing by way of the TRP (whether they know it or not). It makes no sense to go back a year later (or longer) and ask IT professionals for this information when in reality, they sat in front of BCM and told them what was happening. It’s up to BCM to make note of this and capture what they can and include it into the TRP plans (in the appropriate spots). It’s rare that others may think of passing this information on, as they are going to have their own set of activities to worry about. It may not be completely what you’re looking for but it moves you a step closer to keeping the plans current and the entire TRP moving forward reflecting the organization, as it moves forward.
- Second, utilize the Project Management Office. Now, this can be IT specific or organizational wide. Some companies have more than one office related to project management; meaning one could be part of the Finance department and another could be part of the Technology department. So be aware, you may need to approach more than one Project Manager (or Director of Project Management) to get things coordinated. How? Well, each project usually requires some level of documentation; either technical in nature or business process in nature. If the project relates to an existing services (processes, server configurations, services) then instead of creating new TRP documentation, the existing documentation developed only needs to be amended to reflect the changes the project has on the configurations/set-up. That way, new documents don’t need to be created and it allows for IT resources to better utilize their time because – and this is so true – many IT professionals don’t have the luxury of time to document. In this way, the projects are keeping the technology BCM documentation up to date – they are the drivers. This also works for non-technology projects. When a new service is being introduced there are new processes and procedures required to ensure the service can be delivered. Before I go to far, yes, this will include technical documentation but that’s covered in the example earlier in this section. Still, if a new processes is introduced, which involved either one department or multiple departments, the department BIAs and BCPs both need to be updated to incorporate the new service – and related processes. The introduction of the new service may even require updates to “Disaster Teams” and their roles and responsibilities (depending on what the new service is and does of course). It may introduce new external partners and vendors for which contingency strategies will need to be investigated and addresses, especially if there are Service Level Agreements (SLA) in place – on either side.
- Lastly, develop an overall maintenance schedule. It may sound simple but this is to be completed every year – and agreed to – before the following New Year begins. You can use either the business fiscal year as a base or the calendar year as the base. To make things easier on myself, I use the calendar year. If you have a steering committee that helps oversee the BCM Program – its development, maintenance, exercising and testing and other aspects – meet with them and discuss a workable timetable as to when specific components of the program will be reviewed and updated or exercised. This helps everyone involved with these initiatives understand when their resources – either their own or their direct reports – will be needed to participate in these projects. Knowing ahead of time helps everyone schedule accordingly and because the steering committee developed and agreed to the time frames, they are more in line to ensure it is completed. This also allows senior management to know that their investment is well-placed, as departments are ensuring their plans and processes are kept current. What would be on this schedule? There will need to be a timeframe for when BIAs are reviewed; BCPs reviewed and updated; TRP plans to be amended to reflect changes that were identified in the BIAs; exercise and test schedule time frames (with sufficient pre- and post- execution activities included). As well as the steering committee meeting schedule and when updates are provided to the senior executive. You can also include any special projects (BCM of course) that need to be completed over the coming year as well as reviewing Crisis Management processes and anything else you might need to review to ensure the program stays current. An added bonus is that you can add timeframes or blocks of time, that simply can’t be utilized due to some resource restrictions. For example, no one will be working on any BCM initiatives during June because of the implementation of a massive corporate-wide project that will utilize a majority of resources. So in this case, the BCM practitioner can do some internal (internal to him or her) projects or items related to BCM that don’t require additional resources.
This is by no means a complete and consolidated list; there are many other instances, which over time will probably make it into a blog in one form or another. Still, these areas are vastly under-utilized and can greatly assist with keeping various components of the BCM program relevant and current. It might take some time to settle into these areas and I don’t suggest trying to do all three (3) of them at the same time. As one slowly comes into line and people begin to see the benefits of one, they will eventually come to see the benefits of others and be more willing to assist in maintaining the BCM program.