Getting Organized for Business Continuity Program Implementation
The overall success of your program will likely reflect the actions you take to get organized. This stage is the foundation upon which everything else will be built. It is tempting to jump ahead to show progress quickly. Avoid that temptation. While this is arguably the most important in the entire process, ironically it’s the one that is most frequently overlooked. Big mistake. During this phase, you are trying to accomplish a few basic objectives:
Develop your project mindset. There is no doubt, business continuity presents a huge challenge for many, particularly if this is one of the many hats you wear. Let us propose that there are 2 philosophies that will make this journey both positive and rewarding:
Get executive support. Without that, you are most certainly in for an exercise in frustration. Realistically, your executive team may not be mistaken for business continuity cheerleaders, but they should be willing to do a few things
Scope out the project. You may not take on the entire organization right away, and that’s okay. Remember, be flexible and evolve. But before you start in on the next steps of the project, you want to know have a clear understanding of what’s in, and what’s out. The scope could refer to elements of the organization (business units, departments, etc.), or physical work locations.
Create your project plan. While business continuity is a living, ongoing activity, implementing the program is a project in itself, and should be managed like one. Because business continuity touches on so many areas of an organization, you may find a number of detours and distractions that take you down unforeseen paths. Try to stick to your project plan. We’ve provided a template to get you started.
Remember, don’t jump into the business impact analysis, risk assessment or planning before you lay your foundation!
Expert Tips
Start simple, and build stakeholder support. You will rely on others in your organization to support the program. The last thing you want to do is frustrate them or lose support because they don’t really understand what you are doing. Start simple and basic. People support what they understand.
Don’t over-reach. Better to whittle your scope down to those things that appear to be more critical than to add too Remember, every minute spent on something non-critical is a minute not spent on something that is. When you get to the BIA you’ll validate your assumptions, and you can adjust later.
Identify your needs before buying tools. It’s a common tendency for people to buy BC software as a first step with the idea that the software will make the process easier, faster, and better. Not true, in fact the opposite happens. You have to mold your program around the application. Put a program in place and then see what tools will make it better. Avoid the temptation to purchase software as a first step.
Surround yourself with some support. Ideally you’re organization will create a BC Committee to give you support, feedback, guidance, etc. If that’s not viable, reach out to others you know and trust in the organization. Run some ideas by them: your assumptions, your thoughts on scope, your thoughts on who good department contacts might be, etc. Another set of eyes is typically a good thing.
Getting executive support. Executives are usually concerned with the organizations core mission, so getting support for BC can be elusive. But if you do enough homework to find out what the executives care about the most, you can propose a limited project to make them those things more resilient. Demonstrate value by addressing executive concerns, and you’ll likely get support to continue. You can use the same approach to get the support from the executives in your own department or business unit.
The best program is the one that you use. This speaks to your own views on program implementation. The best program is not the one that is constantly being refined prior to adoption. Create a program that is good, use it, and make it better.
The overall success of your program will likely reflect the actions you take to get organized. This stage is the foundation upon which everything else will be built. It is tempting to jump ahead to show progress quickly. Avoid that temptation. While this is arguably the most important in the entire process, ironically it’s the one that is most frequently overlooked. Big mistake. During this phase, you are trying to accomplish a few basic objectives:
Develop your project mindset. There is no doubt, business continuity presents a huge challenge for many, particularly if this is one of the many hats you wear. Let us propose that there are 2 philosophies that will make this journey both positive and rewarding:
- This project will expose you to all areas of the organization, and people at all levels. Stated otherwise, if you embrace this project you’ll understand the overall workings of the organization, and you’ll be very well connected. Not a bad set of tools to have at your disposal.
- Be flexible and evolve. You will want to be very clear (with yourself and with others) that business continuity is an ongoing process. It is likely that you will change certain components of your program as you for forward. And certainly the first version of any plan you develop won’t be as robust as the plan will be a year from now. This approach is healthy, as over time you’ll become more knowledgeable about the organization and so can make better decisions. Communicate this often to your stakeholders, as they may be seeking perfection right away. It doesn’t happen that way.
Get executive support. Without that, you are most certainly in for an exercise in frustration. Realistically, your executive team may not be mistaken for business continuity cheerleaders, but they should be willing to do a few things
- Assign an executive-level program sponsor
- Support the designation of a program coordinator (if not already complete).
- Support the creation of a business continuity Policy
- Provide input on project scope and objectives
Scope out the project. You may not take on the entire organization right away, and that’s okay. Remember, be flexible and evolve. But before you start in on the next steps of the project, you want to know have a clear understanding of what’s in, and what’s out. The scope could refer to elements of the organization (business units, departments, etc.), or physical work locations.
Create your project plan. While business continuity is a living, ongoing activity, implementing the program is a project in itself, and should be managed like one. Because business continuity touches on so many areas of an organization, you may find a number of detours and distractions that take you down unforeseen paths. Try to stick to your project plan. We’ve provided a template to get you started.
Remember, don’t jump into the business impact analysis, risk assessment or planning before you lay your foundation!
Expert Tips
Start simple, and build stakeholder support. You will rely on others in your organization to support the program. The last thing you want to do is frustrate them or lose support because they don’t really understand what you are doing. Start simple and basic. People support what they understand.
Don’t over-reach. Better to whittle your scope down to those things that appear to be more critical than to add too Remember, every minute spent on something non-critical is a minute not spent on something that is. When you get to the BIA you’ll validate your assumptions, and you can adjust later.
Identify your needs before buying tools. It’s a common tendency for people to buy BC software as a first step with the idea that the software will make the process easier, faster, and better. Not true, in fact the opposite happens. You have to mold your program around the application. Put a program in place and then see what tools will make it better. Avoid the temptation to purchase software as a first step.
Surround yourself with some support. Ideally you’re organization will create a BC Committee to give you support, feedback, guidance, etc. If that’s not viable, reach out to others you know and trust in the organization. Run some ideas by them: your assumptions, your thoughts on scope, your thoughts on who good department contacts might be, etc. Another set of eyes is typically a good thing.
Getting executive support. Executives are usually concerned with the organizations core mission, so getting support for BC can be elusive. But if you do enough homework to find out what the executives care about the most, you can propose a limited project to make them those things more resilient. Demonstrate value by addressing executive concerns, and you’ll likely get support to continue. You can use the same approach to get the support from the executives in your own department or business unit.
The best program is the one that you use. This speaks to your own views on program implementation. The best program is not the one that is constantly being refined prior to adoption. Create a program that is good, use it, and make it better.