Agile Business Continuity

30 Nov, 2009

Tick Box Testing

Posted by: pdjamez In: Agile Continuity|BCM|Embedding|Strategies|Thoughts

proj_assess_2For many of the people I have spoken to regarding the BCM process, the exercising of their plans has a number of expected outcomes. The first is validation and the second is staff training. If you look to the standards then there is a third outcome, that of identifying vulnerabilities within the current response. For my money it is the third outcome that requires more emphasis.

The role of a Business Continuity Co-ordinator is often misunderstood. It is not their job to develop any of the organisation’s responses but to develop and maintain the process by which business resilience is delivered. Please excuse the bluntness but the clue is in the title.

In a single project there are one or more deliverables that need to be tested against a specification. This testing confirms the value delivered by the project. It is often apparent that the co-ordinator feels responsible for the quality of the output of the planning process, but this I would argue is the wrong perspective. Their responsibilities lie with the efficacy of the process and it’s continual improvement. Business continuity is not a project management process with a single output but is infact an iterative process. Testing therefore has a different meaning, especially from the perspective of the co-ordinator. If you are using testing as a validation process then you are creating a tick box culture that will limit your ability to develop a resilient organisation.

Testing is not about validation, it is an opportunity to identify weaknesses in the existing plans and procedures. If you do not find a vulnerability in your response during an exercise then the exercise is at fault and you need better testing. At this point I’ll take the opportunity to point to a recent post by Ken Simpson at Contemplating…. Blog regarding the the High Reliability School of thought. New Zealand’s Resilient Organisations group noted a preoccupation with failure and a need to encourage reporting errors and near misses as a critical success factor. I can’t think of a better more controlled way of identifying vulnerabilities than during an exercise where the resulting impact is close to zero.

Oops, missed this excellent post by Stoneroad on validation. Check out The Six Questions of Validation. Note to self check Google Reader before posting.

Related posts:

  1. The Big Bang Theory
  2. Occam's Razor
  3. Location Location Location
  4. Business Continuity Discontinuity
  5. Business Continuity Is Simple

3 Responses to "Tick Box Testing"

1 | Ken Simpson

December 1st, 2009 at 11:43 am

Avatar

Paul, I cannot agree with your post totally.

Agree wholeheartedly about tick-box and testing as verification. There is far too much of that going on.

Where I take issue is saying that the BC professional, the Coordinator as you call them, is only accountable for the process and not the outcome.

Therein lies part of the problem. If they are just about the process – then they want to justify the quality of their process by showing that the process delivers a working plan.

Perhaps they need to be more accountable for the quality of the output. No entity/silo can be resilient on their own, the BC professional needs to ensure that the various recovery strategies fit together and deliver synergy.

In many ways I suppose it depends if these really are BC Professionals, or just willing amateurs press-ganged into service!

2 | Paul

December 1st, 2009 at 6:28 pm

Avatar

Ken, from last weeks post’s you can see that I am in absolute agreement that we need to measure the quality of the process. However, I don’t consider plan existence to be a valid metric as this leads to the tick box culture we all know and love.

The process exists to build and maintain a resilient organisation. It is the affect on resilience that we must measure in order to understand the efficacy of the process. For the avoidance of doubt, I don’t discount the need for testing and auditing the plans (something I’m sure I will blog about later), but the very existence of plans does not a resilient organisation make.

Oddly the very area that you seem to disagree with me on, is where I most fervently agree with you. IMHO If a plan when tested is found to have a vulnerability then this is not a failing of the plan but a failing in the process which needs to be resolved by co-ordinator. I don’t mean this in terms of rewriting the plan, but in changing the process to make sure this vulnerability does not occur again. If this isn’t done, then the organisation will not drive out any significant benefit from the lessons learned. If you want a better plan, get a better process.

3 | Ken Simpson

December 2nd, 2009 at 7:11 am

Avatar

Sounds like we are in violent agreement Paul. :)

Let me re-phrase, and perhaps explore these issues in more detail later.

“Plans are nothing, planning is everything”, and old adage but true.

We must also understand motivation. The existence of a documented plan
meets the needs of a compliance auditor. If a test has been done conducted
and a report written, all the better. We need a better BC Audit process
too.

We need to measure both the process and the outcome, and each requires
different measurement and assessment tools and techniques.

Perhaps I understated my key issue. If you want a better plan, get a better
planner. (Although I concede that the planning process would also be
applicable).

Comment Form

About

The main purpose of this site is to capture business continuity issues and share the ways in which practitioners are overcoming them.