Monday, 26 October 2015

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.

Triggering

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.

Summary

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.

Wednesday, 2 September 2015

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

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

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:

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.

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.

Reducing Distractions:
Set workstations out so as to minimise distractions from entrances and exists.

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.

Maintenance:
Make sure that technology can be accessed for maintenance while the
workstations are in use. This may require rear workstation access for example.

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.

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.

Fire
Protection: The rules governing fire protection and evacuation must be adhered
to in your layout for the control centre.

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.

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.