For Want of a Nail: The Importance of Meticulous Execution in BC and IT/DR

For Want of a Nail: The Importance of Meticulous Execution in BC and IT/DR

We often see companies devise excellent strategies for their business continuity and IT/disaster recovery planning but meet with failure in practice due to small lapses and gaps in their BC execution.

In today’s post, we’ll look at the importance of being meticulous in executing your BC and IT/DR plans and share some tips to help you avoid losing your kingdom for want of a nail.


Related on MHA Consulting: Beginner’s Guide to Recovery Exercises

Do you remember the old proverb about the nail and the kingdom?

  • For want of a nail the shoe was lost.
  • For want of a shoe the horse was lost.
  • For want of a horse the rider was lost.
  • For want of a rider the message was lost.
  • For want of a message the battle was lost.
  • For want of a battle the kingdom was lost.

We see this happen often in the world of BC and IT/DR. Companies fail in their efforts to recover their business processes and IT systems because of small oversights and mistakes.

Ironically, these companies often have perfect strategies for their BC and IT/DR recovery. Their planning is excellent at the big picture level.

However, strategy only gets you so far when it comes to restoring your processes and systems after a disruption. Even a perfect strategy is of limited worth without diligent execution.

BC managers cannot allow themselves to be lulled into complacency by the knowledge that they have a good strategy. They have to press on and make sure that every link in the chain that makes up the execution of the strategy is strong.


Here are examples, one each from BC and IT/DR, of situations where a company had excellent recovery strategies but gaps at the tactical level that would have rendered those strategies useless if they had actually been called on during an outage.

We’ll start with BC. I recently had a consulting engagement at a company that had devised an excellent work from home strategy. The point of the strategy was to enable them to continue their operations remotely should they lose access to the facility. The strategy was well thought out and the company had put a lot of resources into setting it up. Employees had been issued company laptops. The IT department had provided the staff with the capability to access the company’s systems remotely, via web access or VPN. There was only one problem. As I discovered when I stayed late one evening, half or more of the staff left their company laptops in the docking stations at their desks when they went home at night. Suppose something happened overnight and the office was inaccessible the next day? For security reasons, non-corporate devices are not allowed through the VPN. The company’s excellent work-from-home plan would have been severely compromised if not wrecked by the failure of half the employees to take their laptops home in the evening.

It happens in IT/DR as well. For example, we’ve seen many times where the IT team demonstrates a good DR strategy and that they are able to recover the company’s servers. They further show that testing occurs based on the defined scope and what is being protected. But when we look closer, we often discover that only the test environments are used for the testing or the necessary production servers are not being replicated to the DR site. With this approach, only the basic functionality will be available; dependent items may not be. For example, print servers or middleware servers may be missed. The strategy is good but the execution is not complete, with a severe impact on functionality.


What are some things you can do to make sure your company’s excellent recovery strategies are not undermined by poor execution?

  • Look closely at your program and identify areas that may look good but actually have significant functionality gaps.
  • Start looking at how functional you are and not just what boxes have been checked. 
  • Test end to end, taking a function and exercising it all the way through.
  • Do more integration testing, where you test the interactions between systems and processes.
  • Include remote locations in your testing, not just the facility where your data center is.
  • Do more ad hoc testing, where there is no advance notice and special preparations.
  • Use all levels of staff in your exercises, not just the subject matter experts and top technical people (they aren’t the ones who are going to be using the system).


Companies that have developed good BC and IT/DR strategies are to be congratulated for doing so. They should also make every effort to ensure those strategies aren’t undercut by lapses in execution.

For want of a nail, the kingdom was lost. But you can make sure that your company is not lost by being conscientious in how you implement your recovery strategies.


For more information on business continuity execution and other hot topics in business continuity and IT/disaster recovery, check out these recent posts from MHA Consulting and BCMMETRICS:

Richard Long is one of MHA’s practice team leaders for Technology and Disaster Recovery related engagements. He has been responsible for the successful execution of MHA business continuity and disaster recovery engagements in industries such as Energy & Utilities, Government Services, Healthcare, Insurance, Risk Management, Travel & Entertainment, Consumer Products, and Education. Prior to joining MHA, Richard held Senior IT Director positions at PetSmart (NASDAQ: PETM) and Avnet, Inc. (NYSE: AVT) and has been a senior leader across all disciplines of IT. He has successfully led international and domestic disaster recovery, technology assessment, crisis management and risk mitigation engagements.

One thought on “For Want of a Nail: The Importance of Meticulous Execution in BC and IT/DR

Comments are closed.

Business continuity consulting for today’s leading companies.

Follow Us

© 2024 · MHA Consulting. All Rights Reserved.

Learn from the Best

Get insights from almost 30 years of BCM experience straight to your inbox.

We won’t spam or give your email away.

  • Who We Are
  • What We Do
  • Blog