One of the best tools that an organization can have in-house is an Incident Management System (IMS) solution to help keep track of the various things that happen on a day-to-day and crisis basis. Any organization that has adopted the Incident Command System (ICS) methodology or the Canadian variant — rather problematically, for this article series, called the Incident Management System — will benefit from using IMS software to gather and manage their information. A well-handled IMS can help raise situational awareness levels, reduce confusion, and provide the valuable record-keeping needed by an organization.
This article is the first in a series of articles aimed at providing an understanding of the key aspects that IMS software should have: a logging capability, resource management, contact management, GIS and other mapping information, forms and reports, and more advanced features such as information exchange and fusion, managing social media and perhaps an integrated notification and alerting system. Together these articles will provide a comprehensive description of a world-class IMS.
One of the harder aspects to understand about IMS software is that your team must be able to use it. This seemingly simple statement has caught many organizations out. An organization must be able to use the IMS effectively or it can actually be a detriment to operational effectiveness and situational awareness. Ensuring that an organization is able to use an IMS effectively means that they are able to use it across the spectrum of incidents that the organization will face. Ultimately the IMS needs to address the major factor that will determine the success or failure of its use — its users.
The users of the system will fall into three broad categories:
- The very occasional user — this is the user that takes the required training and participates in the mandatory exercises. These occur once or twice a year so you can’t fault them for forgetting most of the application so it had better be easy to approach and remember. The lack of hands-on experience isn’t the fault of this user, it is simply a consequence of the role that they play.
- The daily, but casual user — these are the users that may use a part of the system every day but they don’t go into any real detail because they don’t need to. When things get hot (e.g., during a crisis) they will have to re-learn the parts of the system that they have forgotten. There is no fault in this user not knowing the minute detail of the whole system. They simply do not have a reason to dive any deeper in the application.
- The power-user — these users are rare and powerful because they understand every feature of the system and they know it like the back of their hand because they are the ones that have touched every part on a regular basis. They can potentially teach a few others how to do various tasks but that likely can’t because when that training is needed, this user will be needed on other things like keeping the system flowing or managing their own portion of the response. An organization will be fortunate if they have 1 or 2 of these users. They keep the system in good condition while things are quiet and they can handle any complexity but in a crisis they don’t scale up. If they are to provide training they need a system that can help them scale out.
The first time a user looks at an IMS they should be guided to doing the tasks that they are allocated. For example, presenting dozens of things that they may do doesn’t help someone who is focused on maintaining Contact information for an organization. Similarly someone in charge of maintaining a particular Duty Log shouldn’t be searching for that log amongst many options.
The best approach for a system to have in this environment is to use a levels-of-depth approach. This is a term that I use a lot, but it may be new to you. The levels-of-depth approach makes an application easy to use for basic capabilities and as more depth/capability is needed it exposes only what the user needs. Levels-of-depth is a design philosophy that only presents the appropriate levels of detail or complexity (the depth) when warranted. If a user needs to go deep they can, but they should be forced to go deep and be exposed to complexity when it isn’t warranted.
The system should present as few options as it can. The advanced user may very well have immediate access to all aspects of the system but they are the exception not the rule. Regardless, a system that applies a levels-of-depth approach will easily accommodate the power-user needs.
Similarly even a user with a very defined role should be able to approach the IMS easily. When a situation is simple there isn’t a need for advanced and deep capabilities.
During day-to-day use, when simple things like shift changes and weather outlooks and similar information are being logged, The Log may be dead simple and provide just a General log. Applying levels-of-depth though allows complexity to be hidden when it isn’t needed like the day-to-day situation. However when a major crisis or even unfolds, there may be a number of levels of depth to the log: the General Log, several Incident Logs, and in each Incident, multiple Duty Logs. We’ll cover the log in more detail but the point is that each level of detail is hidden, removing complexity, at least until it is warranted.
As a user gets deeper the IMS must still maintain a consistent look and feel and as they traverse multiple levels-of-depth they shouldn’t be hunting for data or get lost in the navigation. There is a simple test to see how complex a system is the 3-Click Rule. The 3-Click Rule means that major functions of the system can be reached in a maximum of 3-clicks of a mouse or finger. This take an immense amount of user experience design but it is worth every penny of investment when a team scales up. Many small jurisdictions scale from one (or just a partial) person to dozens and dozens of personnel in a matter of hours to meet a large scale crisis.
Levels-of-depth allows the complexity to be hidden until it is warranted and allows users to gradually scale up to learning the application. The consistency of the application is key here too and all aspects should apply the same concepts — hide complexity until it is warranted.
There are other aspects that can really simplify the system for key users, such as dashboards and task-specific pages. Those will be covered in a later article.
The next article (Part 2 – The Incident) will discuss how managing basic details about an incident and the subsequent article (Part 3 – The Log) can combine be the single most powerful part of an effective IMS solution. Subsequent articles will discuss additional aspects of a full-scale IMS: Resource Management; Contact Management; GIS, Maps, and Location Data; Forms and Reports; Social Media; and Integrated Notification and Alerting.