This is the 5th article in a series about Creating Incident Management System (IMS) Software.
Once you’ve started logging activities, created incidents, and have your contacts in order the next logical thing to build into your IMS software is the ability manage your resources – the Personnel, Equipment, Supplies, and Teams (I call this the PEST mode – I tried STEP but the order felt funny and over the years PEST stuck) that your organization uses to respond to the various events that you need. Whether you own the resources yourself or if you borrow, rent, or buy them you will likely need to maintain a list of some key resources and you will want to use them.
Let’s cover off the PEST model really quickly here:
PERSONNEL:
These are the people that you may actively task (or others task) to respond to various situations. You’ll want to know their Contact information (which is all in one place now in your IMS), organization (that they are part of), skills, certifications, training status, location, last updated, and more. As far as assigning Personnel to an Incident you’ll want to allow a single personnel resource (i.e. a person!) to be assigned to multiple Incidents. It is quite common for one person to be active on multiple active incidents.
EQUIPMENT:
These are the hard and likely mobile assets (some assets shouldn’t move but fall under equipment – e.g. the air purification system at your EOC) that you will task and deploy to meet particular needs. Depending on how detailed your organization is you may need to have a lot of detail (e.g. fuel type, fuel capacity, in-field service time, last certification time, location) or you may be less specific but use an accredited naming system (e.g. US NIMS resource typing would allow a simple “Type 1 Aerial Apparatus” to describe an aerial apparatus, with a 76-100ft or greater aerial platform, with 750-1250 gpm pump, 4 personnel, and is NFPA 1901 compliant). If your system will only every be used by your team you can be less specific but you run the risk of having new operators being unfamiliar if you veer too far from norms and convention.
When you’re assigning Equipment resources to an Incident you should likely only assign that equipment to a single active Incident otherwise resource conflicts will occur. If you find that you need to have a single Equipment resources assigned to more than one Incident you are likely in a scenario where you need to have a Parent Incident.
SUPPLIES:
Consider supplies as things that get consumed. Sand bags, field meals, fire retardant foam, etc. get consumed during training, exercising, and response – or they may simply expire. Tracking the quantity-on-hand, quantity-on-order, and normal quantity levels will be key for keeping your supply situation in hand. NOTE: Under NIMS you may refer to some SUPPLIES as “expendable” resources. Much like Equipment, Supplies should only be assigned to a single Incident. However, Supplies are somewhat unique in that the quantity of a particular supply is what is assigned – the remainder is left in inventory.
TEAMS:
Teams can be quite simple or intricate – they are basically a collection of personnel, equipment, supplies, and teams (sub-teams). Using a NIMS style taxonomy will help manage the complexity. Putting in all the personnel (including their training and certifications), equipment, and supplies needed to describe a Heavy Urban SAR (US&R Task Force under NIMS) Team is daunting – if you rely on a HUSAR team you should list what type they are (1 – 2) and leave the intricacies of managing all the information to the HUSAR Team itself. It’s their job to know their operational state, so when you call for a HUSAR Type 1 team they will know whether they meet the need that you are asking for (and there are only so many HUSAR Type 1 teams around). Much like Equipment and Supplies, Teams should only be assigned to a single Incident.
Once you have begun managing your resources as discrete types (feel free to find a way better acronym than PEST – but the concept works!) you’ll need to track a few things.
CONTACT INFORMATION:
Every resource will need at least one Contact entry to ensure that you are able to reach them. For critical resources you may want to have multiple resources. Remember that your IMS should only have one copy of each Contact so be sure to re-use that one person that seems to control most of the key resources – you don’t ever want to have an old phone number hanging around for him or her.
TASKINGS and ASSIGNMENTS:
Now that you have your resources managed you can begin Assigning them to an Incident and Tasking them – either directly (create a Task – we’ll cover them in a later article) or through a Standard Operating Procedure (SOP – we’ll cover that later as well). The idea here is simple – you assign resources to an Incident and to a Task (or multiple tasks). You will want to be able to view the assignment information when you find a resource that you had planned to assign but found that it was already assigned (that’ll let you know if you need to pull rank, pull in a favour, or look for another resource!).
LOCATION:
Given that resources are likely mobile (or can be moved at least) it is helpful to know exactly where they are. By providing a location you enable a location-based search. For example, if you need a Type 1 Track Dozer that is located within 250km of an incident site, Location information will help save you from flipping through a long list and calling people outside that area.
RESOURCE STATUS:
When it comes to tracking the status of resources there are really three key states that need to be handled: Unassigned (meaning Available for assignment), Assigned to Incident, Out of Service (for equipment and teams), and Unavailable (equipment out of service, personnel on leave, etc.). Going beyond these states gets pretty complicated and should only be done for advanced teams. If your system needs to track the mobilization, demobilization, and other states that relate to Incidents you may want to track those as Incident-centric states.
ACTING AS A RESOURCE:
There is another special capability that you should consider – the case where one of your users is a Personnel resource. We’ll get into the meaty details later, but imagine that you are brand new to an incident and haven’t used the IMS software before. You are told that you have been assigned to an Incident and Tasked – now what? Well, assuming your IMS software is following the levels-of-depth concept you should be able to log in and see exactly what that means immediately – see that Task under an Incident and not a lot more that will confuse the untrained (or low-trained).
