Business Continuity and Disaster Recovery – Part 3

In my last post I discussed how Business Continuity and Disaster Recovery were part of a much larger business conversation. A process that requires identifying your key workloads and processes. Until you have completed these steps it is near impossible to develop a meaningful BC/DR plan for your business. So what happens when you have finished identifying and prioritising your workloads? You then go to the technical people that can work out how to make it all work.

When your technical team has information on what the priorities of the business are, they can identify all the different tools and technologies that can be implemented within the business to meet those needs. With your budget set out your team can pick the best tools that are available that meet the budget, identify the pros and cons of each solution and then pick the one you want to implement.

Once you’ve identified the products to use and completed your acquisition process it is time to start implementing the tools. This is often where it starts to go wrong! The tools may not actually perform as planned, they may not include features that you were told that they did, or probably the most common problem, when you make changes you increase the risk of outage.

Change breaks things. It is inevitable, and unfortunately, it can’t be avoided. If you don’t make the change now, things may tick along happily for many years to come without ever costing the business any money. But what happens when disaster inevitably strikes? And it will! It’ll wait for the most inopportune moment; your highest trading period, when you have your largest order of the year due, when you’re making the biggest pitch to a client you will this year!

Get the work done on your terms, when you can best plan for the impact that it will have to your business!

Research has shown that the majority of small businesses that lose their business data will fail quite soon after that loss. Your customers lose confidence in your product. Your suppliers may be less willing to sell to you. The most likely scenario is that you will not be able to provide your product to your customer.

If you’re willing to take that risk then please feel free to focus on other parts of your business. If you’d like to understand why the changes will break something, and why you’re still better off read on!

Change will break things!

Making a change in your systems will inevitably break something within the business. It may be the interaction of systems that was setup. It may be that a key tool is offline for a period of time. It may be that your backup system is not functioning for a period of time.

Those that do not make changes, will fail! The world is a changing place, and those that fail to adapt to their changes are doomed to perish!

Here are some of the common reasons why I have seen change cause problems and some ideas on how you can recover.

The product did not do what was sold

The number of times I have seen businesses buy products that don’t do what they wanted is staggering! Often a product will look good from the sales pitch but when it gets implemented in your business it simply doesn’t meet your requirements. In these cases it is useful to have some sort of get-out clause with your contract, if at all possible you should make sure you have some way of getting your money back.

The most common problem with BC/DR solutions will be that it either doesn’t work or doesn’t actually meet your recovery time objectives.

If you aren’t able to get away from the product, it may be that you can change your business processes to make the product do some, if not all of what you need. At least if you do this you will be able to make something from the investment. When thinking about BC/DR it may be that while the product doesn’t get you to your RTO or RPOs, does it get you closer? If so, how much? In these cases the most important part will be to test your recovery process to see if it meets your requirements. If it doesn’t but gets you closer, or significantly closer, then it can still be a net win. It is probable that the product you need to get you to your RPO/RTO is significantly more than you can justify.

Business Processes will need to change too!

Many information workers don’t like to change how they work. Many like to learn their job and then stick with it as long as they can. Unfortunately, when you put in new tools, the business may need to change how it functions too.

Many off the shelf products will include some flexibility in how they function and will be able to somewhat adapt to how the business operates, however, in most cases there are some ways that a product is designed that cannot be changed and instead, you need to change how you work to meet the product’s needs. This is an unfortunate side effect of how software works. Changing how software functions is often quite a difficult process. Many different parts of the code need to be changed to adapt to how a product will need to operate. In some cases it isn’t possible to change the way a product functions without completely re-writing it. Business process, however can change, and in many cases more quickly than the software will. If you can identify what needs to change in your process before you buy the tool then so much the better. But beware, there’ll probably be something else that you need to change too.

You will always have a few people within any business that don’t want to change how they work. They’re good at what they do, confident and happy doing things how they have for years. These are the people to work with the most to try and get them to be your advocates! Often if they can see how the change in a process helps them, saves them time, makes their lives easier it can go a long way to them becoming the new systems biggest champions. I see many businesses try and leave their more stubborn users alone as much as possible. It can be good to actually try and turn them into the advocate.

Often this starts at the top. A business leader needs to actually articulate to the staff why this change is necessary. When the staff understand why the management team want to use a new tool then they are more likely to accept that tool. If the first time that they hear about the tool being put in is when the engineer shows up to install it for them, then you’ve already lost.

In a BC/DR processes will usually need to change for reasons such as; employees need to make sure that they have access to some key documents at all times and depending on circumstances need to use a different tool to access it. They need to know how to use this tool and how to make sure it is up to date. Some products for business continuity need you to log in using a different method when using the BC systems.

You do not meet the pre-requisites for the product.

Almost every product on the market will have some pre-requisites. Most of the time they will be well documented, unfortunately there are times when they’re not and assumptions need to be made. One of my mottos (I have a few depending on the situation) is that “Assumption is mother of all stuff ups!” Alas, there are times that they need to be made, often due to time constraints but many times because the information isn’t available and you need to take a punt, (more so in small business).

The best thing to do in these cases is to try and identify all the assumptions being made, when you have your assumptions identified then you can confirm with your vendor or team that these are reasonable assumptions or not and then take action to mitigate against the risk of the assumption being incorrect.

When talking about BC/DR some key assumptions are:

  • Changing tapes is someone else’s responsibility
  • When using online backup that the internet speed will meet the requirements of the backup product.
  • In products that take incremental “snapshots” not understanding the rate of change within the system and then assuming that there is enough capacity to store or transfer the changes on to/on the destination
  • That the IT Team is the only people that need to be concerned with the BC/DR plan

That’s it for now, come back next week for my next post where, I’ll discuss some of the steps you need to take after your plans have been implemented.

To continue reading the blog on Business Continuity and Disaster Recovery, please view Andrews personal blog here -


TOPICS: An IT Pro Confesses, disaster recovery, online back up

Written By: Jacob

Stay in touch

Enter your email address to subscribe to our newsletter

IT transformation roadmap CTA square

Technology is an incredibly powerful tool that can drive change, enable innovation and accelerate growth. Our blog is here to help you make sense of it with the latest new, advice and insights from Team Doherty.


Related blog posts

Business Continuity and Disaster Recovery – Part 2

In my first post I outlined some of the key terms that are used in most Business Continuity or Disaster Recovery conversations. This post will be focused on how much BC/DR is in fact a function for...

Business Continuity and Disaster Recovery – Part 1

Blog written by Andrew Bogard, IT Professional at Doherty Associates.