This is the 4th article in a series about creating Incident Management System (IMS) software.
You’ve seen the contact binders and you have used them. You’ve seen the problems – people change and even if the same person is there, their contact details have changed.
Face it – the minute that you print out your Contact List it is already stale – it probably had 5-10% stale contacts before you hit print. During a crisis this incorrect information causes a massive amount of lost time. Fixing it is critical to getting a good handle on your ability to respond to incidents. Let’s see what we can do to help out here.
ONLY ONE CONTACT!
The number one rule of managing Contacts in IMS software is that anywhere that a contact is used – in an Incident, linked to a Resource, as a Site owner, in an SOP, etc. – the system MUST point to a single contact record. Keeping different versions of a Contact in different places in your IMS software will result in stale and incorrect information, which will lead to errors, mistakes, and lost time. By keeping a single contact you ensure that when it is updated – by your staff or by the contact person themselves – it will be applied throughout the system.
If for some reason your system needs to keep a history of contact information there are ways to handle this but keeping old contact information linked to anything is a surefire way to have stale data. Applying a history capability will allow you to meet a business need that shows changes in contact information. However, consider the business reason before investing too much time in exposing this kind of complexity. If the data model behind your IMS software already support history (it should) then this may be simple, but your business needs may make it complex and difficult to support.
By referencing to a single contact you ensure that when you need contact information you will have the best chance of it being current and accurate. Failing to do this and having any “hard-coded” contact information puts you in a weak position.
WHAT IS A CONTACT?
The previous rule is important enough that we’ll cover off the definition of what a Contact is after discussing the “only one contact” rule. You already know what a Contact is but there some subtleties that are worth raising. Firstly, there are multiple types of contacts that you will need to handle. Dealing with specific individuals, roles, and organization requires slightly different focus. When you deal with a person the name (first and last) is the critical piece of information while dealing with a role and organization differ. Your IMS Software should allow classification by these roles but if it doesn’t you must be able to search on name, role/position/title, and organization to be able to effectively find your contacts. Secondly, a Contact is not necessarily a Resource, a User, or a Role – it is the contact information for those things. This separation of the Contact data from the “thing” that uses it is crucial to making sure you have the best Contact information possible.
KEY INFORMATION
The information that you will need to capture for a contact is quite well known. You will need to have the following at a minimum: Name (first and last), Position/Role/Title, Organization, telephone numbers, email addresses, mailing addresses, and fax numbers.
Depending on how advanced you get you will want to add location, contact category (i.e. what kind of contact is this?), notes, and more. If you are integrating a notification system you may want to list the Contact’s preferences for notification (e.g. email first, cell next, sat phone, then home phone) so you can use that in your notification system (a future article will cover Notification capabilities). Similarly for an Organization you may have multiple Contacts that have different schedules. It isn’t uncommon for different contact points to be used during business hours and outside of business hours.
WHY A SINGLE SOURCE? ANOTHER BENEFIT
The first rule of Contacts above makes sense from a data accuracy basis, but there is a further benefit that may be even more valuable at times. When you link all “things” to a single Contact you can also see where that Contact is used – by how many SOPs, Resources, Incidents, etc. Given the nature of social connections you may be surprised to see which Contacts are linked to the most – and the least. Occasionally examine where Contacts are linked (and not linked) will allow you to determine which contacts are really key and which ones may not be.
CONTACT UPDATES
In order to have the best (i.e. current and accurate) Contact information available you will want to consider automating the updates that are made to the system. There are three ways that this can be done. In order of the preferred implementation (best at first) these are: automatically from a “source of truth” system; by having the Contact update their own information; and finally manually by your staff.
If your organization has direct access to a system (or systems) that can be considered as a “source of truth” then you should consider automatically synchronizing with that system (or systems). An example of such a system would be a provincial or state registry of emergency management officials that is legislated and actively used to keep emergency official contact information up to date. Assuming that the system is actively used by the community then it can provide the richest and most current information. Such integration should be fully automated and any synchronization errors should be reported to a group that can intervene.
If you have a large number of contacts from a broad basis there may not be an official source that you can use. In this case consider building in a semi-automated manner such as occasionally sending out email to Contacts requesting that they update their contact information directly. These contacts may not be full users of your IMS software so the update procedure may need some kind of one-time-access capabilities to allow a Contact to update their own information.
The least desirable state for managing contacts is to have staff in your organization reaching out on a regular basis to confirm and update contact details. This approach is typically slow, expensive, and onerous so it should be avoided as much as possible.
CONTACT LISTS (GROUPING CONTACTS)
There will always be Contacts that are treated differently and your IMS software should allow you to create Contact Lists that allow you to group your Contacts together for various purposes. Your IMS software should allow Contact Lists to be assigned to various “things” (e.g. Incidents, Resources, SOPs, etc.)
You will want to maintain a number of Contact Lists from day one. For example you may have some of the following groups: Senior Leadership, Key Media, Volunteers, Operations Staff, Logistics, etc. Another key distinction is that any Contact could be in any (or all) Groups. This is another area where keeping a single Contact is key – you don’t want different Contact Lists having different information for the same Contact.
PRINTING CONTACTS
Having opened up with the concept that makes printing of Contacts sound almost anathema there is a simple reality that forces us into printing contacts. In the event that your systems are destroyed or you are not near a computer or device with access to your IMS you will need something. Therefore, your IMS must be able to provide a printout of your Contact data – either all Contacts, all Contacts in a Contact List, or the critical contacts that you need. The system should explicitly indicate the date that it was printed and the expected “stale date” of the information. For each contact you will want to show the date and time that the Contact was last updated to ensure that if you have printed multiple Contact Lists and something has changed.
Handling Contacts can make or break your incident response. Handling them poorly can most certainly doom your response to using stale and incorrect information – resulting in delays and miscommunication. Handling Contacts well can reduce some of the chaos and put your organization in a better position to focus on your response.
