TUG Buzz! for Monday December 16, 2019


  1. Plan Testing - article by Garth Tucker
  2. Stay Connected - Confirm your subscription to TUG Buzz

Garth TuckerDon't plan your test, test your plan

There seems to be an unconscious (I hope it's not intentional) tendency on the part of many inexperienced practitioners to plan tests in order to ensure a pass, as opposed to testing the plans that are part of your organization's resilience program to ensure accuracy and familiarity for less seasoned responders.


There are several reasons for this, the most glaring, and the one that we'll use as the basis for this diatribe, being the fear of "failing" the test and having it affect their yearly review. This is a failing of both the practitioner and of management, for not understanding the purpose of testing, especially in the early stages of program development. If you've just started building your program and have not performed any significant testing, it's pretty well a given that you have unidentified obstacles (dark corners) that will only be identified during iterations of testing. Sadly, there always seems to be the one that stays hidden, regardless of how much testing you do, and only appears during an actual crisis, but that's another campfire discussion.


After laying the groundwork for your plans; teams (roles/responsibilities), communications, activation procedures, risk assessment, impact analysis, etc. We begin writing what we hope will be effective responses to the risks we have identified.

This is where an experienced practitioner earns their paycheque.

They know that the Subject Matter Expert (SME), developing the plan's response steps, will likely overlook many things that are extremely important to the recovery process. This is because they, the SME, considers these things insignificant. It's part of what they do every day and seems inconsequential to them.

However...  Those little things that they consider unimportant can make the difference in a successful response vs a complete disaster. It's the practitioner's job to prod, push, aggravate, annoy and otherwise drive the SME up the wall about details, details, details to ensure the plan or plans are as accurate and easily followed in a crisis as possible.

Here's an easy one as an example; in the response plan there's a notation that during a flood, caused by broken pipes, the water must be shut off at the main and no other instructions, maps, or clues. This is because Bob, the building maintenance SME, who wrote the plan instructions, checks the main weekly to ensure it opens and closes easily and knows everything there is to know about that water main. Good for Bob. He's the King of the Water Main and Master of All Valves. Not so good for Dave who works in another building for the same organization and was the only one available to respond to the flooding of 3 floors in Bob's building because Bob and his family are currently riding the Bat at Wonderland as part of their vacation. Dave has no clue that the water main is located in a closet, hidden behind a boiler, and has to spend 2 hours tracing pipes that have been walled in and the flooding has now affected 12 floors See where this is going?


When inexperienced practitioners plan their tests, they ensure Bob is there for the day of testing and has rehearsed his role so well he could challenge De Niro for an Oscar. So, well done Spielberg, you've "passed" your test. Bully for you, you're a superstar.



However... You have not identified the hidden water main dark corner by having Dave's fresh set of eyes follow the plan steps. Had you had Dave take part in a discussion exercise, he would have mentioned that he has no idea where the water main is and you could have included a map, a picture and detailed description of the location in the plan. So instead of stumbling around trying to trace pipes that are hidden inside of walls, the water would be shut off in minutes and would have saved 9 additional floors from being flooded.

Organizations need to take focus off "passing" tests and recognize that identifying, then mitigating obstacles is a real Key Performance Indicator (KPI) in the testing process. Testing is part of an effective plan development program and the only way to ensure any significant measure of resilience. Anything else is simply virtue signalling and if you engage in it, I will use you as a bad joke at some point in a presentation or an article. 


As always, thank you to the folks who provided peer review for this lunchbreak learning module   smiley face
Garth Tucker, CBCP, CORP
Resilience Professional

Skype: garthatucker

GarthGarth is the Principal of Green Apple Resilience Planning (, a member of the DRI Canada ( Board of Directors, and a Certified Business Continuity Professional (CBCP). His career focus is on the development and management of holistic resiliency programs as well as effective management of crisis events.   The path to his current position began with software development, project and program management, and as an IT technology educator worldwide for IBM in the late 1990s and early 2000s. He transitioned to disaster recovery, business continuity, and crisis management beginning in 2002. Significant formal, and self-education throughout his career has ensured he remains relevant and effective.

Back To Top


Stay Connected with TUG

The Toronto Users Group is committed to providing you with communications that are timely, relevant, and insightful. Canada's Anti-Spam Legislation (CAS) requires that we receive your permission to continue sending you emails.

You may have already given us your consent. If you haven't done so yet, or if you're not sure, please click on the following link to indicate that you would like to continue receiving electronic communications from TUG.

Consent button

Should you change your mind, you can unsubscribe at any time, by clicking on "manage your subscription" at the bottom of our messages.

Back To Top

The Toronto Users Group for Power Systems (TUG) is a user group/forum for the exchange of ideas, and specializes in providing affordable education relating to the IBM iSeries, AS/400, System i, and Power Systems platforms. TUG is in its 35th year of operation.

Browse our
Articles & Downloads archives

Browse our
TUG Buzz! archives

Browse our
eZine archives

TUG GOLD Members


Do we have your current e-mail address and other contact information?
Email the TUG office to keep us up-to-date.   

TUG Juggler Copyright 2019 - Toronto Users Group for Power Systems (Power Systems is a trademark of IBM Corporation.) IBM and the IBM logo are trademarks or registered trademarks of International Business Machines Corporation in the United States and are used under license by IBM Canada Ltd. Linux is a registered trademark of Linus Torvalds. Other logos appear in this message for reference purposes only, and are trademarks or registered trademarks of their respective owners.

(Please note that if you forward this email to any third party, they will be able to view your personal data once they click on the link to Manage Your Subscription, unless you remove that line from the message.)

     eNewsletter design by Eclipse Technologies Inc. (