I have been writing a bunch of articles for my own use lately. A large number of them relate to Incident Management, a domain that I have been in since about 1997. Creating software for incident management has become second nature to me. I’ve done them for civilian and military use and the resulting software and systems (about 5 different major platforms now as direct development and advise on at least that many more) have managed/prosecuted well over 100,000 incidents. Ranging from all forms of Search & Rescue (SARMaster, now a Honeywell product) in the late 1990s (yeah – dating myself), through Military Y2K response (DCOP), to the IMS that was on the high-side of a military network (it’s been turned off – the IT guys got a hold of it and lost the interest of the operational folk – that’s horror story unto itself.). Then there was the Black Coral software – LIVE and SoftRisk. But I digress from my main purpose of this article.
I started creating the articles because I want to see improvements in the industry and I was contemplating jumping in and doing it again – creating a new IMS software suite. However, my professional and business focus is now on information exchange and the deeper identity and access management issue that underly it so the idea of me creating such software won’t fly – not terribly soon anyway. So, instead of squirrelling away my notes and letting them moulder away (digitally – I’m an Evernote fan so it’s all typed up – if you don’t know Evernote – get it and the Evernote Essentials e-book) I figured I would release it for others to read and hopefully benefit from. Hopefully it will help someone in building the system that they really need. Who knows, in the distant future I may revisit this area and take a run at it. For now though I’m having a blast and making a huge difference by working on information exchange and IAM. I’m helping our customers save lives by making information move better – and that wakes me up with a smile every morning and drives massive amounts of energy in me.
So, here’s the plan – I’m going to try to release an article a week about how to go about designing an Incident Management System (IMS) – the software that will allow an organization to get a handle on things. There are many places that I have taught and mentored to do this so I know that the concepts work. The articles will follow a pattern – and over time I will likely revisit some of the content and edit it for clarity, for detail, or just because I feel an article needs a bit of polishing.
Here’s the release plan:
- Part 1 – Levels of Depth. The most important thing to me is that any IMS must (yes – MUST) be very easy to approach (that means easy to start using – training or not) but it must also go deep enough that if things go big the system doesn’t collapse. It needs the depth of information at times. The Levels-of-Depth concept allows for this. I start with this concept because without it I think that the remaining concepts fall down really fast and won’t help many organizations barring the ones that use the systems in-depth each and every day.
- Part 2 – The Incident. Strangely enough this is the first priority – but it is critical as well. The Incident is the concept that ties things together once they have gone sideways (i.e. once you have an incident).
- Part 3 – The Log. Having a usable and comprehensive logging strategy makes it much easier to manage things. If there is a tool to nail totally this is it. With a good logging system you can get an awful lot done.
- Part 4 – Contacts. Managing contacts is critical to ensuring you have the most current information available. Having a binder with phone numbers is basically useless – you can almost guarantee that 10%+ of the contact data has changed by the time that the binders hit your desk.
- Part 5 – Resource Management. Managing your resources, your resource requests (tickets), resource offers, and resource tasking becomes a big job on a medium-sized incident and a huge job on larger incidents.
- Part 6 – GIS & Location Data (Part 1). Integrating a GIS directly into the system is key to being able to grasp the situation. Things are so much more clear when presented on a map. Adding your own organization’s data to a map is key too. This first part article focuses on the GIS (map) basics, leaving the actual integration for the second article.
- Part 7 – GIS & Location Data (Part 2) – The article for GIS integration was getting a tad long so I split it out. We cover the direct IMS integration here.
- Part 8 – Sites. Sites allow you to categorize key infrastructure (e.g. hospitals and health facilities, CI locations), planned use areas (e.g. high school gymnasium as a shelter), temporary locations (e.g. aid tents, and other locations that are key to your plans, response, and mitigation efforts.
- Part 9 – SOPs and Checklists. Having a consistent place to edit and store SOPs ensures that your team and partners are always aware of where to find the information and that the information they hit is the most current. Checklists and basic automation of workflow is key here too.
- Part 10 – Forms & Reports. The various forms (paper ICS, intake, etc.) and reports needed by your team, your leadership, and your partners need management.
- Part 11 – Document Management. Managing plans, received information, and other documents is key to successfully getting a handle on an incident. It also helps during the other stages of emergency management to have all of your key documents on hand.
- Part 12 – Dashboards and Task-Specific Pages. To simplify decisions and to make life easier on your extended team you will want to consider specialized dashboards (for leadership and other decision makers). For the resources that you use in a surge capacity you’ll want areas that basically poke them in the chest to do key things – if the system can guide them through the tasks so you don’t have to train them then you are ahead.
- Part 13 – Information Exchange and Fusion. Sharing with your partners is becoming more and more important so leveraging these capabilities is critical. Additionally, your partners will be sharing with you as will other agencies so you need to be able to fuse the information you are receiving.
- Part 14 – Social Media. Getting a handle on Social Media is important and it is becoming even more critical to handle well. The tools at hand should be able to show you what is happening in Social Media and allow you to respond appropriately.
- Part 15 – Integrated Notification and Alerting. A comprehensive solution will allow you to keep all of your stakeholders current and allow them to react better. Your stakeholder list may be small (small company) or it may be massive (a city with the need to notify the general public) so you will need a robust solution here.
If that list looks daunting don’t worry. If you’re keeping things really simple I’ll put guidelines in to protect you from the deep dive complexity. The reality is that a well run organization can get a lot done – the tools are there to add operational value but you can get by without them if you need to. That being said, I’ll be pointing out some “bare minimum” things that you’ll want to try to keep in mind as they add so much operational value that you will regret not having them.
I’ll be starting with Part 1 this week and Part 2 will follow the week after with a goal of 1 article per week (barring holidays and major deadlines!). As the articles roll out I’ll update the links here to create the index. I am still toying with some of the concepts so I may change the order of the Articles – but I’ll keep this page current.
UPDATES:
This article has really become kind of a table of contents for the article series. I am going to just keep updating as new ones come out and as the series evolves (i.e. I won’t be putting in a list of the explicit changes!).
