Design of Crisis Management Capability and the ‘Crisisinterface’

image

If you are designing a crisis management capability (or any other form of team required to stand up outside of normal operations) for an organisation then the concept of the ‘interface’ is a cornerstone of planning. An interface can be defined as the common boundary between two things – the point of interconnection between entities. Or it could be ‘the place where things happen’. In business and politics (nature as well) the interface is the boundary or zone where interesting things happen.

Discussions with executive management and leaders who have come out of the other side of a major event or crisis say that real reaction and needs of stakeholders were things that surprised them. People who normally were allies/friends of the individual and organisation re-evaluated their positions and acted in different ways. They supported, froze relations or became hostile adversaries depending on the new reality of a changed situation for them caused by the crisis. Is this a real surprise as crises force stakeholders to re-evaluate their positions and relationship with those in trouble? They ask “how does the current situation affects the established deal or arrangement”? For a contemporary illustration of forced change of a stakeholder position, think of the US President’s changing position on ‘British Petroleum’ during the unfolding of Gulf oil spill.

So if the interfaces are critical planning information, then how can the idea of interfaces be illustrated for a crisis team. The clearest illustration I have drawn to explain interfaces are the ‘egg timer’ or ‘Maltese Cross’ diagramme. The benefit of identifying interfaces means that the most of the probable information flows can be defined which enables a clearer understanding of the design (the operating model) to be formed. The team design gained from this sort of thinking contrasts starkly with the “let’s put the management team in a room” type of approach. The team starts to look more like an Incident Command System (ICS) team structure, with more defined roles and responsibilities for various components of the stakeholder map.

Whilst identification of interfaces and outputs is by no means a radical concept, when you review or benchmark most crisis management and business continuity planning it is rare to find a developed map of the necessary interfaces, or even a definition of the stakeholders involved in the business. Certainly, there is a definite absence of identification of other stakeholders that could be pulled in. The organisations that understand and map their interfaces and how they may change under stress in a crisis are the ones that can be placed in the leading practice category. However, it is common for executive management post-crisis, to be uncomfortably aware that positions and relationships shifted and morphed during a crisis, and that they did not sufficiently understand this before the event or have the tools available to manage this dynamic during the crisis.

As a move forward, the new British Standard for crisis management (BS11200) does cover stakeholder management and development of a crisis communications strategy. This says that “a stakeholder engagement plan should be developed and provide guidance about the level of information that is to be transmitted and to whom”. The standard provides guidance for those designing or improving crisis management capabilities. It is a start to ensuring your crisis management design has some defined doctrine.

So What? Here are 5 considerations for design of crisis arrangements:

  1. Ensure the operating model for organisational level crisis management arrangements is not just the ‘management team’ in a room, but that the operating model is designed on a real understanding of the interfaces required. It is very difficult to define strategy and planning for tomorrow and longer term without a clear understanding of the interfaces.
  2. Map the normal business interfaces as a start, and define how these will change in crisis. The basic list comes from the organisations ‘dependencies and dependents’.
  3. Build some planning assumptions on the speed and frequency that outputs are required to satisfy stakeholder demands.
  4. For top tier stakeholders, consider their outcome requirements and who is best placed to communicate from the organisation, this information comes from understanding the interfaces.
  5. Ask the question: do your crisis management arrangements define the key interfaces and specify who the points of contact are? If the answer is ‘no’ then further planning is required.

Guest Post by Gareth Jones. MSC, FICP&DM, MBCI, MEPS, MICM

Bio:

Gareth Jones is an independent crisis management and business resilience professional with over 33 years risk management related experience. He has 13 years of intensive commercial delivery of risk, crisis and BCM/resilience consulting and assurance to a wide range of organisations, including global majors (oil and gas, pharmaceutical, utilities, defence, aviation, financial services, manufacturing, government, technology and mining sectors).

His first career of 21 years was in the RAF Regiment, the Survive to Operate branch of the UK Royal Air Force. In addition to command experience in operations, he gained strategic experience as the lead for nuclear, chemical and biological defence. Gareth holds a masters degree in risks, crisis and disaster management from Leicester University.

Gareth is an experienced exercise designer, director and coach for executive crisis management teams development and experiential learning. Gareth led the first national command and control exercise for the London 2012 Olympics (Exercise Yellow Fortius). He also has experience in ‘uncertainty reduction’ techniques such as design and facilitation of scenario planning, scenario analysis, macro risk contingency planning and business war games. Gareth has also contributed as a co-opted panel member on British standards for exercising and crisis management. Gareth can be found blogging >>HERE<<

All content provided on this blog is for informational purposes only. D4H Technologies Limited makes no representations as to accuracy, completeness, currentness, suitability, or validity of any information on this site and will not be liable for any errors, omissions, or delays in this information or any losses, injuries, or damages arising from its display or use.