Monday, 26 October 2015

To Invoke or Not To Invoke

“establishing the parameters for invocation and managing the process”

A Barrier to Effectiveness
Having a plan is one thing. Knowing when to use it, how to get it started, how to adjust the tempo and when it is right to call an end are other things all together. In our experience, and in the findings of official enquiries, these wider aspects of plan employment can go awry[1].  Perhaps the most fundamentally important of all of these relates to when and how to invoke plans and procedures. As obvious as it seems, and despite this being a stock component of every plan, it is often not well thought through, understood or even used. Examples of the failure to trigger and formally invoke procedures and teams are evident in case studies. For example, and at the Operational level, the 1999 Landbrook Grove rail crash inquiry recommended that ‘instructions for signallers should provide a set of options … to send an emergency stop message to a particular train or a general stop message’ and ‘that the type of circumstances in which each option is or may be appropriate’ should be clear[2]. More recently, and at the Strategic Level, concerns have arisen from the Gatwick Airport Limited Terminal Outage on Christmas Eve in 2014; ‘namely airline complaints that GAL refused to move to the Gold level of its contingency planning’ and that this ‘was driven by the terms of GAL’s plans that adopt a definition of Gold which seems not to be well understood outside the company’[3]. This also emphasises the added complexity presented when responding alongside other organisations.

Overcoming Inertia
Perhaps the fist point to note in relation to understanding the inertia to using plans properly is that escalation is often wrongly seen as synonymous with invocation. Escalation is the act of telling others about the situation being faced and is nearly always done. These may be people or teams at the same level or indeed at subordinate or superior levels, meaning escalation can occur sideways, up and down. Telling others that something has, or is potentially about to, happen is of course a vital aspect of any response procedure. However informing others is not the same as formally invoking teams and procedures. Invocation, which is often less well done, is about evaluating a situation and then formally establishing set teams along with associated support and response mechanisms and procedures. The very act of doing so carries meaning for all concerned, both internal and external to the organisation, and allows for a more informed decision making capability to be put in place quickly.

The reasons for the failure to invoke, even when escalation has taken place, are complex and many. They can include a technical fixation by those who discover the original issue meaning that they don’t appreciate the wider implications in time. Others may see the need to invoke as an admission of failure or believe erroneously that they can solve things before they get out of control. Still others don’t want to bother people, especially senior staff and particularly on weekends or holiday time. Part of the solution is to ensure that the plan has a clear invocation process, linked to escalation, which mandates the steps for authorising plan enactment, establishes the response structures and that enables a meaningful operational status to be defined for various teams that respond.

To be able to effectively invoke plans requires the establishment of criteria for doing so[4]. Such triggers need to be clear and measurable and must allow assessments to pick up early warning signals as much as define when a significant incident has taken place[5]. These triggers may usefully be based on the factors the organisation feels best define the impacts it is keen to avoid, rather than the causes themselves, such as service or product quality, safety, finance, resource availability or reputation. The process also needs to reflect existing hierarchal structures. The situation whereby the level below is required to decide to invoke or not invoke the level above, as opposed to simply escalate to that level, should be avoided. Decisions to invoke teams and responses need to be taken at the right level and by appropriately authorised personnel.

Invocation is not always an all or nothing game. There can be states of operation that result from invocation decisions and these may escalate or deescalate as the understanding of the situation clarifies. Such states will have associated levels of response for teams and procedures. For example the invocation process itself requires core people, armed with the right information, to assess the situation as a precursor. The initial call out of key decision makers is therefore not the same as invoking a plan. 

Once the active choice has been taken to invoke then a formal declaration of this decision must be made and promulgated. This should have meaning for others, including those external to the organisation, and act as a ‘trigger’ for known and predefined responses. As such it is important to consider the impact upon others of any invocation decision and the operational state required. It is hard to hold 100% internal readiness for an impending possible crisis for very long and any declaration may mean that other agencies move to a certain enhanced states of operation as well. That is way a graduated system is useful.

The Process
When building an effective invocation process there are a few key concepts to consider. Firstly notification is not a one-way street. It must be able to occur both up and down the chains of command and hierarchal structures. People need to have the confidence they will be listened to when they escalate an issue and that those receiving this information will act appropriately regards plan invocation. Often it is technical knowledge and competency that is key to understanding the implications of a situation and not simply position or rank.

Secondly the physical means of calling out and engaging with staff need to be clear and effective. For senior and middle management teams it may be appropriate to consider virtual methods as people are often distributed across the country or globe. The response must also not be hindered by the failure of any one person to be reached. That is why assigning roles with responsibilities in teams, and not just names, is vital. When a person does not respond their responsibilities can be allocated to others and not missed. Technology can help in this regard but it is important to define the processes first before selecting systems[6].

Thirdly when teams have been notified they need to be able to analyse the situation against the trigger criteria that have been set. To do so they need access to an accurate picture of the situation[7]. Often this means that others responsible for gathering and consolidating information, such as the Incident Control Centre team, must be notified at the same time as, if not before, the decision makers.

Fourthly active and unambiguous decisions need to be taken in time to enable the tempo of the response to be effective. As we have seen this requires that the level of incident or crisis is defined and declared so that this can trigger appropriate responses[8]. It will also be important at this early stage to decide on any adjustments to the response that may be required. As the situation is unlikely to be static by consistently monitoring the picture the response can be increased or reduced proportionally, through changing the declared crisis level.

Invocation procedures need not be complex but they do need to be well thought through and understood by those who will use them. There must be a clear delineation between the processes for escalation and invocation, although they will also need to be linked as the former influences the latter. A system for calling out and notifying people and teams is required, along with the capacity to provide early invocation decision makers with as comprehensive an understanding of the situation as possible. The authorisation required for invocation at each level should be set and clear triggering criteria must point to defined levels for the crisis or incident. Once declared the crisis or incident level should in turn drive others, both internal and external to the organisation, to achieve set states of readiness in terms of response. Finally graduated invocation processes can be useful in enabling escalation or de-escalation of response as the situation changes.

[1]Bazerman M and Chugh D, Decisions Without Blinders, Harvard Business Review, Jan 2006, pp 94
[2] Landbrook Grove Rail Inquiry Part 1, Rt Hon Lord Cullen, 2001
[3] Disruption at Gatwick Airport, D McMillan Feb 2014
[4] Societal Security – Business Continuity Management Systems – Requirements, ISO 22301, 8.4.2
[5] Boin A and Lagadec Preparing for the Future: Critical Challenges in Crisis Management, Journal of Contingencies and Crisis Management, Vol 8, No. 4, Dec 2000, pp 189.
[6] Husband R, How John Lewis Partnership Connected 200 Business Continuity Plans To An Emergency Notification Database, Journal of Business Continuity and Emergency Planning, Vol 1, No. 3, Jan 2007, pp 261 - 270
[7] Elsubbaugh S, Fildes R and Rose M, Preparation for Crisis Management A Proposed Model and Empirical Evidence, Journal of Contingencies and Crisis Management, Vol 12, No. 3 Sep 2004, pp120 - 123
[8] Good Practice Guidelines 2013 Global Edition, BCI, page 82

Wednesday, 2 September 2015

The Logistics of Running a Control Centre

The focus of the crisis control centre is the processing of information, the taking of decisions and the management of actions. However there are a number of highly important logistical tasks that need to be undertaken, particularly over a prolonged incident. 5 things to think about planning for are:

1.     Access Control: Everyone will want in but not everyone needs access, including senior staff. Make sure you include some form of access control. This needs to restrict access to those who are authorised to enter and record access of those present at any point in time.

2.     Minute Taking: The discussions and decisions within the control centre and by the teams being briefed by the control centre, such as the CMT, must have minutes taken. This requires trained staff as part of the control centre team.

3.     Shift Management: It will be impossible to remain as part of the control centre team indefinitely. People need to be afforded rest whilst on shift and the shifts need to be changed. The pace of replacement will be driven by the tempo of the incident.  Shift changes need to be done in rotation, and not all at once, and require careful planning from the very start. People due to be on shift at a later point may need to be sent home first.

4.     Staff Welfare Support: Staff in the control centre will be under pressure, may be experiencing the results of traumatic events and will have their own worries. They may have dependency issues, medical concerns or know people that have been impacted. It will be important to provide access to welfare provisions for control centre staff, from rest and refreshments to counselling and support.

5.     Maintenance: Things break or get damaged so part of your control centre team structure needs to include technical and maintenance staff. They will be vital in helping to ensure the smooth running of the centre.

Top Tip: Often this will be too much for the same people who are managing the emergency or crisis to cover. Think about appointing a control centre manager whose job it is to cover these aspects.

Wednesday, 22 July 2015

Selecting Technology for Your Control Centre

So you have taken the plunge and developed a crisis control centre to support strategic leadership in a crisis. You’ve got the facility identified long with the people. The last remaining question is about the technology you need to put into the centre to support the  team? When thinking about the selection of technology for your control centre here are 5 things to consider:

  • Processes Come First: The first thing to know is that selecting the technology is not the first thing to think about. You need to make sure that you get the right processes defined before installing the correct technology to support them. If you focus on technology at the start, at the expense of getting the processes correct, you run the risk of finding out that your expensive technology doesn’t help your people do what they need to.
  • Notification and Call Out: It will be important to be able to notify and call out team members quickly and easily.  This can be done over the phone or through call cascade lists but these methods are time consuming and run the risk of error.  Therefore it is useful to consider using automated systems to notify team members using either SMS, email or web based platforms. The widespread use of smart phones has enabled the development of specific applications designed to enable incident notification and call out. These can provide richer levels of information including pictures, audio and videos as well as location and diary details.
  • Situation Management: One of the major functions of the control centre is to develop and maintain the situational picture. Technology can be employed to assist in the following ways:
    • Information Management: Incoming and outgoing information will be required to be managed and separate telephony and email provision will be needed to support this. The accounts used should be able to be handed over as shift changes take place without compromising IT security policies.  The systems used should support the production and sharing of a contextualised situational picture, and not a simple chronological list. This picture must be capable of being added to or consolidated at the various response levels within the organisations, so that raw data is not simply passed up the chain prior to analysis and to ensure that the availability of sensitive data can be controlled. The situational picture must also be able to be shared easily with other teams and organisations.
    • Action Management: The actions that result from the management of the situation need to be tracked and linked to the information and decisions that they resulted from.  This information should be readily available, in an easy to digest form, to control centre staff and to decision makers, both when in the office and when in remote locations.
    • Displays: Displays will be required on desks but also as larger displays off desks so that others can see relevant information, such as the situational picture. It is also useful to be able to display information from the control centre directly into other meeting rooms, such as those used by senior decision makers or multi-agency groups, and to enable remote access by those not physically present.
  • Records Management: All information, incoming and outgoing, forms part of the record of what has gone on.  Therefore the systems used must ensure that information is appropriately recorded such that an audit trail is possible. This could include the names of individuals or roles who have provided and inputted the information, details of times and dates, distribution information and information on changes and revisions that were made. It can also be useful to be able to quickly link information relating to similar dates, locations, themes, authors or sources.
  • Scale and Future Proofing: No mater what technology and systems are installed one eye must always be kept on the future. Although it will be difficult to predict technology changes issues relating to scalability, training needs and replacement should be considered from the start. In doing so it can be helpful to build in a percentage increase in overall capacity above that initially required so as to prepare for future growth requirements.

Monday, 15 June 2015

Ergonomic Factors in Operating Control Centres

In a crisis your staff may have to spend a considerable amount of time operating in the crisis control centre that you have allocated for this purpose. They will be taking difficult decisions in stressful circumstances so how much thought have you given to the environment that they will be working in?

If you haven’t thought these things through then it may just be that you are adding to the crisis that your staff and managers experience. Here are a few top tips for ensuring a positive working environment for the incident or crisis control centre:
  1. Workstation Configuration: Ensure that the workstations are set out in a manner that facilitates communications between team members and line of sight with key off desk information displays.
  2. Workstation Size: People will have to conduct handovers or it may get so busy that more than one person is required at each post. Leave enough space at each workstation position for this to be catered for.
  3. Reducing Distractions: Set workstations out so as to minimise distractions from entrances and exists.
  4. Consoles: Makes sure that the required space for console use is provided, including for keyboards. Ensure that on desk visual displays are properly positioned for line of sight.
  5. Maintenance: Make sure that technology can be accessed for maintenance while the workstations are in use. This may require rear workstation access for example.
  6.  Noise Reduction: Remove the sources of noise that can be distracting. Think about headsets for phones and phones with light indication. Use noise screens if appropriate.
  7. Contingency: Investigate the provision of services to the control room. Ensure that any single points of failure are catered for. Think about power supplies in particular.
  8. Fire Protection: The rules governing fire protection and evacuation must be adhered to in your layout for the control centre.
  9.  Cleaning and Waste: There will be a need to clean the control room and dispose of waste securely. Plan for this and for it to take place whilst the centre is in operation.
  10.  Heat, Light and Air: Allow for temperature control in the facility along with the capability to vary the lighting levels. Reduced lighting may be more appropriate in hours of darkness for example. Make sure that the air is circulated and cleaned.

Monday, 11 May 2015

Designing Control Centres

There is something to the observation that many organisations fail to put in place all the processes and resources required to enable practical crisis management. Plans provide for a crisis team, often with a control centre location, but miss some of the other practical fundamentals around operating that facility. There is much more to overcoming the confusion, fog and resistance experienced when operating through a crisis than a few top people in a room huddled around a spider phone.

If managers are to lead successfully in a crisis they need support. ISO11064 Ergonomic Design of Control Centres defines the steps in designing a control centre. This effectively breaks the process down into the following phases:

Phase A: Understand and clearly document the role or purpose of the control centre and how it is to fit in with other structures. To arrive at this level of understanding requires time to be spent in research. The aim is to discover the user requirements that will make crisis management better and more structured through the control centre.

Phase B: Analyse the results of the research and try to make sense of them by formulating a series of propositions to cover (1) the system performance, (2) the allocation of functions, (3) defining the tasks and (4) designing jobs and organisational structures for the control centre.

Phase C: A conceptual layout design should be developed and include wider aspects such as the physical attributes of the centre, its furnishings and any specific facilities and amenities. 

Phase D: The detailed design phase ensures the conceptual design can be converted into a design sufficient to enable the centre to be built. This includes the development of operating documentation.

Phase E: Once the control centre is up and running and staff have been provided with the opportunity to receive training and to participate in exercises the job is not yet complete. There is a need to review the performance of the facility and the systems within it so as to be able to identify areas for improvement.