Search This Blog

Monday, March 12, 2012

Hazards, Vulnerability, Disasters - beyond musings on the meanings of words.

This note is derived from a presentation to the FinPro Conference 2012, Creswick Novotel, Victoria, Australia. A copy of the complete paper is available here as a pdf.

By John Salter, Director Emergency Preparedness Capacity Builders



A fundamental issue - Plans vs. Planning

Standards and Guidelines for disaster and business continuity management focus on two things:
  1. To plan, establish, implement, operate, monitor, review, maintain and continually improve a documented management system; and
  2. To protect against, reduce the likelihood of occurrence, prepare for, respond to and recover from disruptive incidents when they arise.
If our emphasis is on the documentation of yet another “plan, do, check, act” system, then standards will be a burden rather than an enabler – a significant risk in a marketplace already crowded with standards, systems and guidelines.

If standards and guidelines are used to support planning – active collaboration to achieve sound outcomes – with only the minimum necessary documentation – then it is more likely to deliver traction.

If we are mindful and use a strategic approach, we should address the key due diligence issue – or “coroner’s test”: i.e. “what you ought to know and do – about risks and their management”. The set of crucial decision points that should be addressed in every disaster management and business continuity management situation, are about:
(1) what is the risk (detection),
(2) what does the risk mean (recognition and interpretation),
(3) who has an interest (communication to multiple stakeholders), and
(4) who should do what (organization of a collaborative system).

Specific objectives will emerge according to the nature and scope of the particular disaster or crisis.

Key Terms - and their meanings

Words and their meanings – or their different meanings – are important when developing context and establishing shared understandings. This enables communication and avoids the “Tower of Babel” syndrome whereby many languages contribute to project failure.

So in checking some terms, let us start with “disaster”. First, while focused on pain thresholds and capacity to cope, the term disaster is contextual – "your thresholds and capacity to cope may not be the same as mine".

Risk is a function of the interface between hazards and the vulnerabilities of your "care-fors"
Second, it is important to recognize that "hazard events are not necessarily disasters". Yes, hazards contribute to risk, but an extreme event only becomes a disaster when it impacts something we attribute value to (our “care-abouts”).
For the same natural phenomenon - sink holes - different consequences.
Incorporating a focus on vulnerability opens up a rich vein of considerations - about what might be the most appropriate thing(s) to do to “protect against, reduce the likelihood of occurrence, prepare for, respond to and recover from disruptive incidents when they arise” (ISO 22313).

A risk based approach focuses on the likelihood of consequences – not the likelihood of hazard events.

While a risk based approach sits comfortable with an “all hazards” approach, it should be recognized that an “all hazards” approach is a civil defence construct – applying largely to response, relief and recovery arrangements which can benefit from such efficiencies. In a more comprehensive risk based approach there needs to be a recognition that “fire is not water” – and that prevention strategies for each need to be tailored.

The framework within which the risk based approach is applied is often referred to as PPRR – or Prevention, Preparedness, Response and Recovery. This P2R2 heuristic device was introduced in the 1980’s as an instrument of American foreign policy to encourage third world nations away from reliance upon a post disaster “hand up for hand out” approach. It is not a simple linear construct – though it has constrained thinking by being used in that simple, indeed simplistic manner. A more useful display of the relationship between the four words is displayed here.

What does this mean for communities at risk and the businesses upon which they rely?
There is a need to develop - by planning before a disaster - strategies which reduce vulnerability. Line one in the diagram below which reflects the purpose – or business case – of business continuity planning. To mitigate impact before and after a disruption event.

 

Saturday, February 11, 2012

Risk Assessment ≠ Risk Analysis

One distinction between "risk management" in the USA and the rest of the world was - and maybe to a degree still is - the different meanings of "anaysis" and "assessment".

For the United States: "Assessment = Analysis"

For the rest: "Assessment = Identification + Analysis + Evaluation"

Aligned with the Intenational Risk Management Principles and Guidelines (ISO 31000)
  • Context and Identification are about nailing your risk issues by focusing on their consequences in relation to "the things you value" (objectives).
  • Analysis is about premising the likelihood of those consequences (given the effectiveness of current controls).
  • Evaluation involves judgment of acceptability.
To help address this issue and add some value to those who may want to consider it, we have developed a risk assessment tool which is aligned with the International Risk Management Standard, easy to use, inexpensive and works on Excel software as old as 1997 - or the most recent version.

The structure of the tool fully aligns with the structure of the ISO 31000 process.
More information on how the Risk Assessment Tool works is available by downloading this pdf.

We are please to make this immediate download available for the SALE price of only US$14.95

Monday, January 16, 2012

EPCB weekly Risk Management Newsletter launched

To bring together items of common interest and tweets, EPCB will make available a "Paper.li" web-based publication which will provide a collection of (hopefully) interesting items in the one spot -The url for the publication is http://paper.li/risk_reward/1326694527 for those of you who want to consider subscribing to a weekly notification.

Thursday, December 15, 2011

Three steps to developing a sound SIPOC diagram


Overview Handout

Purpose: The purpose of a SIPOC Diagram is to define and document the key elements of an activity. This includes Customers/Requirements, Outputs, Process Steps/Requirements, Inputs and Suppliers.

Materials: SIPOC overview handout, whiteboard, worksheets, flipcharts, PowerPoint (not preferred as it can take away from engagement and participation), Posters, PostIts™ (or my favourite, coloured sticky arrows – which are then placed on a large, blank, laminated SIPOC chart)

Time: Varies. Plan for at least two hours based on the complexity of the process, the knowledge of the participants of the process, and their previous experience creating SIPOCs.

Step ONE: Get everyone on the same “purpose” page
Note 1 to facilitator: Do this step even if working with a knowledgeable group by reviewing the elements critical to conducting a successful SIPOC session.
Use this review as a means of setting a positive tone and developing a “conversational” style of facilitating the session.

The five critical elements to a good SIPOC are:
1.   Provide participants a brief overview of the SIPOC structure and how it important to manage its use in terms of range of purposes.
Apply the Covey principle “begin with the end in mind”– SIPOCs are flexible tools and can be focused on achieving a range of purposes – such as project planning, or vulnerability mapping or organisational restructuring. So be mindful – ask how will you USE this SIPOC?

2.  The challenge for service industries (as distinct from making widgets) is to think beyond the process column (where many SIPOCs start). The challenge for individuals is to think outside of their square.

3.   When recording on the SIPOC use only as much detail as needed to understand/communicate effectively.

4.   Record the agreed purpose of this SIPOC session – make the agreed purpose the label of the “car park”. The “car park” is an area of white space, such as butcher’s paper or a whiteboard on wheels, which is structured to capture – as they relate to the SIPOC element being mapped at the time - (1) assumptions (2) constraints (3) risks and (4) decision criteria

5.  This is not an academic exercise - define how things really get done, not how we might want them to be.

Step TWO: Establish the Framework
Note 2 to facilitator: Groups sometimes prefer to be more “organic” than systematic. Be flexible and accommodate as long as the entire SIPOC form is completed with enough detail to understand the process. Be flexible and use plain language. Write it down, and then ask open-ended, clarifying questions to get it right. Place the “thing” or “issue” on the SIPOC at a place of best agreed fit. Challenge the status quo, test the understanding of the process, and encourage dialogue.

Note 3 to facilitator:  A challenge from here on out in this process is to keep the group at a high level of detail - not allow them to get too granular. The detail can come later in the process flow diagram mapping or you can go back and break each key process step into sub-steps and SIPOC them. (It depends on the purpose of the SIPOC and the complexity of the process.)

Use the SIPOC framework (on the wall chart, computer, whiteboard, worksheet, or flipchart).

1.     Seek permission and agreement from the group to start “backwards from the right” - from the Customer column.
  • Identify customers (some will be stakeholders with specified needs to be met which are contractual, or legally obligatory - others stakeholders may have a more indirect and general interest, needing only to be appropriately informed).
  • “Back into” the customer requirements column by now clearly stating the requirement(s) of each stakeholder. 
(This two set customer column should be reviewed whenever something changes – so that the ripple effects can be mapped and managed.)

2.     List the outputs from the process which will deliver the requirements of the customer – and collectively, achieve the required outcome of the activity.

3.     Structure a process which will deliver the outputs effectively and efficiently.
  • Clearly identify the START of your process (cue, prompt, trigger that requires you to act).
  • Clearly identify the END of your process (how do you know you are done?).
  • List the 3-5 (NO MORE THAN 7) key steps in the process being mapped.
  • Incorporate feedback loops – how will you, your customer, your supplier communicate?
(Record: Process name; Process owner; Process performance measures/metrics – structured to inform improvement opportunities; any known operational definitions of key process elements; any known assumptions/constraints and immediately apparent risks - record in “car park)

Note 4 to facilitator: Remind the group that the assumptions and operational definitions are ongoing lists and may be added to as needed during the session. The idea is to make sure everyone is working on the same sheet of paper and means the same thing when using a term and those assumptions are made visible, discussed, and validated or challenged as appropriate.

4.     List the inputs into each step of the process
  • List the requirements of each input (your view – the person doing the work)
  • List the supplier of each input of the process

5.     List or highlight the Critical-to-Quality (CTQ) elements for the process

Step THREE: Check your work
Review the completed SIPOC.
Verify all key components are completed/addressed.
Determine Next Steps/Action Plan.
Make sure all assumptions are visible, discussed, validated, and documented.
Document operational definitions of terms, symbols, acronyms, equipment, standards, etc.
Do not forget to identify your information/communication loops and feedback mechanisms.
Document source specifications, standard operating procedures, and/or references for your process.
Review where you need to have Service Level Agreements (SLAs) – between you and supplier, you and customer.

Saturday, December 10, 2011

Friday, December 9, 2011

"I get knocked down ... I get up again"

One of our favourite clients was recently hit by a significant fire (see video below).


The conclusions of the report to their governing body highlighted that: 

"The early initiation of the Business Continuity Plan proved effective. A well managed and strategic approach to decision-making was evident. The Crisis Management Team was engaged at an early stage and managed the situation in a structured and strategic manner. The Business Continuity Plan worked well, and adequate administrative support and equipment was available."
(Reference: Report OCM.109/11 of 20 September 2011 on 'Portable Office Building Fire 15 June 2011', Section 5.3 Page 3).

 The structure invoked and applied is based on EPCB's "Buttress" methodology.
The Buttress Software Package which is available as an immediate download (Database, Instructions, and Planning Template) is currently discounted - for less than $100 - plus another 10% off if you insert the Coupon X147

Thursday, December 8, 2011

EPCB releases heavily discounted Business Continuity and Crisis Management Software

EPCB is pleased to announce the release of the new Beta version of Buttress™
 
Buttress™ will help you understand your risks, evaluate your exposures, and take timely action. It is based on an easy to use Access Database which focuses on the vulnerability of your resources - to ensure you are more resilient to any source of risk – and to enable you to bounce back effectively.

As an integrated business continuity and crisis management package, Buttress™ has three distinguishing features.

First, it focuses on the things you need in order to run your business effectively. That is your resources – the assets, people, skills, information (electronic / non electronic), technology (including plant and equipment), premises and supplies which underpin your critical activities. This ensures an alignment with best practices business continuity standards, which have moved their focus away from hazard events towards business vulnerabilities.

Second, Buttress™ has a significant mitigation component – which empowers you to reduce your vulnerability before an incident – to build resilience into the structures and functions of your business.

Third, Buttress™ supports the decision making processes to manage the consequences of impact after an incident.

In summary, whether it is mitigation before an incident or crisis management after impact, Buttress provides a platform which allows straightforward data entry and the production of tailored reports to meet your decision making needs.

The Buttress™ package is made up of an Access Database, PowerPoint Guidelines (PDF), and a Crisis Management Planning Framework (PDF). It is available for immediate download as a Zip file.

At under $100, this current software offering is a heavily discounted Beta version which has been validated by EPCB clients across both the public and private sectors over the last two years. (Clients who had been significantly impacted by extreme events – fires, floods, and reputation loss. Clients who knew they needed a better approach.) To take advantage of this offer, go to the secure purchasing site.