In Part 1 of this series about Incident Management System Software, the concept of Levels of Depth was introduced. The idea is that when you don’t need to go deep, the software should be easy to approach and not force complexity on you. If you need more detail then you can dive deeper into the software you can – and you’ll expose new levels of depth and be able to do more.
In this article we’ll focus on the key set of information that you will need for every incident. This information provides the keystone that will allow you to link the various pieces of the incident puzzle together.
The following key information is needed to ensure that you have an Incident that is basic enough to comprehend but has enough detail to link the key information that is needed and created when an incident grows.
- Incident Name – you will need to name your incident so there is an easy way to refer to it. This name may change as details are better understood and the incident evolves so you will want to have procedures in place to inform your audience if you have changed the Incident Name. Many people will say that an incident will never change but in the chaos of multiple incidents you will need this – names are mangled, locations are incorrectly reported, and maintaining bad information is never good.
- Incident Type – what kind of incident is this? You will need to track the various types of incidents that you may experience. The key here is to keep things simple. Using a fire incident as an example, is it just a fire or is it an urban fire, a wild-fire, or an interface fire? Perhaps you go deeper – but be careful about going to deep. Your author has seen systems with so many similar incident types (e.g. is this a grassland urban interface fire or a brush urban interface fire) that deciding exactly what type of incident was happening became problematic. The key for incident types is to keep it at a “big bucket” level. If you need the amazing detail to know exactly what type of incident, ask yourself a simple question “is knowing this subtle difference right now going to save a life” – if it does, then go for it. If it doesn’t then let it go. You can add statistics about incidents later – perhaps in the fire realm you’ll have fuel types, sources of ignition, weather impacts and more – but the fire was still an interface fire.
- Incident Number – your system should provide a unique, but humanly usable incident number that never changes through the life of an incident. Thought the Incident Name may change this number is, in technical terms, immutable – nobody can change it. This number should be on all printouts, reports, and maps just to make certain that you can keep track of things when the operational tempo gets hot. Consider using some kind of text indicator that can uniquely identify your centre, then the year, a hyphen, and a number (e.g. in many search and rescue systems the nomenclature “TI2013-0023” used – where it is the 23rd incident of 2013 for a centre that starts with T – the I merely means Incident). The use of the text in the beginning will really help if you are part of a multiple site organization. If you are part of a very large organization consider more than one letter.
- Incident Description – depending on what kind of organization you have, you may only need on incident description. This block of text allows you to provide a quick summary of how an incident is unfolding. A good incident description will reduce the number of questions that will need to be asked and answered. One of the biggest time savers that a good incident description provides is at shift-change – the new shift can read through the incident description and begin asking immediately relevant questions to get the detail that they need to take over. They will go deeper into the incident but this grounds them and lets them wrap their head around the situation while you continue to manage the incident.
- Alternate Descriptions – it is quite likely that your organization has groups on the outside that are interested in the incident. However the nature of the outside groups is that they likely don’t understand the terms that your team uses and needs a somewhat massaged and cleansed version that you control a little more. There may be multiple groups that have different needs – senior leadership in your organization and close partners, and then the media and general public. You’ll need to consider how many alternate versions you want and your operational tempo will determine how often you update those descriptions. Going beyond 2 alternate descriptions will likely confuse things so think hard before you go there (e.g. 1 for leadership with confidential information that is updated every 4 hours, and 1 for media/public that is updated every 6 or 8 hours). Having these descriptions helps keep the external groups off of your back and off of your phone lines – they will learn that their description is the best source of information. These alternate descriptions can be used if you automate publishing of updates to your intranet and the internet and social media (for the public-facing description). Applying the levels-of-detail concept from the first part of this article series, the use of Alternate Descriptions should be for advanced users.
- Incident Location Name and Position – Most incidents have a geographical area that they impact so having a named place and the geometry (point, line, or area) where the incident is allows you to integrate your incident into mapping tools. The location also allows people to get an idea of where the incident is – a “5 km NW of Bethesda, WI” tells a story – the exact coordinates drawn on a map tells even more. You’ll want to consider the immediate area of the incident here. Though an incident may be drawing upon resources from the surrounding area (e.g. fire and paramedic crews) keep your location focused on the immediate area. You can add detail on the larger area in your mapping tool (more on that in a future article).
- Severity & Stability – if your organization is more formal in risk and incident management you will want to consider handling Severity (how bad is it?) and Stability (is it getting better? worse? stable?). Think twice about adding these values as they add a level of complexity that may not be warranted. If you only manage one or two incidents at a time it is pretty easy to keep them straight – but if you have a large number of incidents active at once (3 or more) then you may want to consider adding the Severity and Stability fields to ensure that you can focus on the incidents that need your attention.
- Status – You’ll need to track the Open and Closed state of your incidents. Though your organization may use different terms such as “suspended” the system should treat those as closed as they aren’t operationally active. This point has been debated forever and your author recommends sticking to the open/closed approach – reporting and analysis gets tough fast when you have more than 2 states.
- Key Dates – Tracking the date that an incident was created, last updated, and closed will help you in your reporting.
- Parent Incident – If there is a majorly complex incident underway it may be necessary to break out incidents into Parent and Child incidents. The Parent incident is used to provide the high-level and coherent overview of the situation while Child incidents provide extremely focused views of a particular incident. An example would be the creation of a Parent incident to manage all incidents that result from a major event (e.g. a hurricane) with Child incidents that manage key aspects – Debris Removal, Evacuations, Power Outages, and perhaps Flooding incidents. Depending on the size and mandate of your organization you may want to consider allowing multiple levels-of-depth, where Child incidents can have Child incidents. If this approach is taken then there should be a level (depth) where this is no longer allowed or you will never find the great-great-…-great-grandchild incidents that some well-meaning and keen person unintentionally hid on you.
The details on the incident itself can be found in the various other areas of the system – the logs, the incident history, resources, the map, etc. As you go through this series of articles you will see how most items can be linked back to either an Incident or to your organization more generally. This will help you to find information and to understand that information better. Those other areas provide the levels-of-depth that were discussed in Part 1.
In the next article we’ll discuss the single most important piece that an EOC can use – even if it forgoes the whole incident concept, The Log will improve operations immensely.
