Some recent social media discussion on EOC management systems has prompted far too many thoughts for me to write in small character quantities…

I’ve been fortunate to have been involved in prospecting several systems for EOC management and other workflow management needs, along with obviously having used a multitude of these systems in EOCs and other capacities. I certainly have my preferences of different systems as well as those I’m really not a fan of, which I’m not going to get into here, though I will say there are some smaller but very successful vendors with great products and excellent track records. I think everyone needs to spec these out for themselves. One note, before I speak a bit about that process, is that you don’t necessarily need a proprietary system. Current technology facilitates file sharing, task management, accessible GIS, and other needs, though full integration and intentional design are just some of the benefits of using a proprietary system. A lot of organizations learned over the past 16 months or so of the pandemic they can get considerable mileage out of applications like Microsoft Teams and Smartsheet. There are also benefits to systems which users may use on a more regular basis than an EOC management platform which may only be used during incidents, events, and exercises.

I’ll say there is no definitive right way to spec out a system, but there are a lot of wrong ways to approach it. My observations below are in no way comprehensive, but they are hitting a lot of the big things that I’ve seen and experienced. Also, my observations aren’t highly techy since that’s not my forte (see my first item below).

Form a Team: (Yeah, we are starting this out like CPG 101.) Bring the right stakeholders together for this. Consider the whole community of your EOC. However you organize your EOC, ensure that elements of the entire organization are represented. Don’t forget agency representatives, finance, GIS, and PIO/JIC. Also include disaster recovery, legal, and obviously IT.

Understand the Situation: (Gosh, CPG 101 has so many uses!) Understand your needs. If you don’t understand your own needs, an outsider certainly won’t. A lot of persons and organizations may think they understand their needs, and very likely do, but there is a big difference between stating it and actually digging into it. Also, this should be done BEFORE you meet with vendors (they will likely suggest against this as they want to influence your perspective on this). It’s important that you do this first so you can establish a standard and see how each vendor/product can meet those needs. NEVER let a vendor define your need.

You may want to take an opportunity to solicit input from other users as well. Talk to them, build a survey, etc. to see what features they might want and what they don’t want. This also helps build buy in for eventual implementation, which can be very important.

There are certain fundamentals to be established and decisions that will need to be made up front by your organization.

• On the IT side, will this solution be self-hosted or vendor hosted?
• How many users would be ‘normal’ for an incident? What would be a surge number of users?
  • Who are these users (generally… your organization, other organizations)
  • Are role-based user profiles preferred?
• Does your organization want to maintain it or will maintenance and updates be part of the contract?
• What legal information retention requirements exist?
• What’s your budget?

Most of the needs to be identified are functional. These are the main things you want to use it for. Start with big items such as the ability to develop collaborative EOC action plans and situation reports, dashboard displays, resource tracking, mission tracking, financial tracking and forecasting, etc. Then examine each one more closely, going to a workflow and task analysis. In this, you break each item into tasks and consider:

• who is responsible for each,
• who contributes to each,
• who needs to be aware of each,
• and who are decision-makers for each;
• as well as what information is needed for each,
• what information is tracked, and
• identifying any outputs or reports (and the key data sets associated with each)

Each task may need to be analyzed deeper as it may have several sub-tasks.

• Does information need to be routed and to who?
• Are there multiple reviews or approvals?
• Is anyone outside the organization involved? (i.e. someone who would not have access to the system but would require information from the system)
• TIP: It’s often helpful to actually run a bit of a simulation with the people who actually do the tasks such that what they do can be observed in real time.
• Be aware of how you are presently limited or influenced by the current technology you use and flag this. It may not be a necessary part of your workflow if it’s dictated by that technology.
• This is also a good time to question why certain processes are conducted the way they are. And remember: ‘Because we’ve always done it that way’ is not a good answer.

Consider how information can/should be displayed, including geocoding information for GIS use.

Keep in mind that the technology you eventually obtain should support these processes and tasks, inputs, outputs, and users. The technology implementation may streamline your workflow, but shouldn’t dictate it.

You may also want to talk to colleagues to see what systems they are using; what their opinions are of those systems; and lessons learned with the system, vendor, implementation, etc. They might even give you access to poke around in their system a bit.

Determine Goals and Objectives: Here is where you identify your specifications based on your outcomes above. Once you have specifications you can start approaching vendors. Your IT department should know how to put together a technology specifications package.

Talk to Vendors: Get your specifications out to vendors, see who is interested, and meet with them to discuss. Depending on your organization, this may be a formal process or can be informal. If it’s formal, be sure that everyone understands this is not yet the invitation to bid. This is still an information gathering step.

Product demos can be great opportunities for your team (yes, your whole team should participate) to meet with vendors to see how they can address your needs and to learn what options are out there. Every team member should have the spec sheet with them so they can independently assess how the demonstrated solution meets needs. This also allows vendors to identify additional value and features they can provide as well as suggesting different approaches to some of your needs. (Again, your team should keep in mind that the product should never dictate the process, though it’s good to understand that the product may streamline that process, but it shouldn’t sacrifice any essential components you have defined). They may also offer best practices they have experienced in their work with other clients.

Get an understanding of how the system is administered and what help desk support looks like. How much in-house administration is your organization able to do, such as adding new users, creating profiles/roles, and resetting passwords?

This interface with vendors is important. I’ve had vendors simply pitch their off-the-shelf solution with little to no regard for the spec sheet, which is obviously a great reason to ask them to leave. You aren’t likely to get a fully custom-built product (though it’s possible), but in all likelihood what you will be offered is a customized version of their off-the-shelf standard. I generally think this is the best option. Along with being cost effective, you also have reasonable assurances that the foundation of their platform is good since it’s what they are building from.

Speaking of this foundation, ask them who their clients are and ask for references of current users. It’s also totally fair to ask why their solution is better than that of other competitors (name them!), and why some customers may choose to go to another platform.

It’s also good to ask about the future. What does the service contract look like? How are updates done? What time period do you have with the vendor for no-cost adjustments once the system is in place? Is incident support available? How can you be made aware of innovations and how are those prices structured for implementation? Will they put together a training package and will they support the first round of training? How about self-guided training?

Purchase: Based on your vendor demos, you might have some modifications to make to your spec sheet. That’s OK. You’ve seen what’s out there and have had an opportunity to learn. I’d also suggest identifying what you consider to be firm requirements vs features which are desired but not required. Once you’ve gotten all the information you can, conduct your purchasing process as you need to.

Implementation and Maintenance: Implementation can be a considerable challenge, and this is where even the better EOC management platforms fail, either in actual practice or in the opinion of users. I could write an entirely separate post on this alone. The most important things to realize are that:

1. Change is hard
2. The system isn’t (likely) used daily

Some people will be excited about the system, others will be stuck in the mud of change. Get people oriented to it and train them. Remember that since this system isn’t used on a regular basis, their skills (even their recall of their log in credentials) will atrophy. So training should be a recurring thing for all stakeholders. Everyone needs to know how to log in and navigate the main screen, but not everyone needs to know how to build a situation report. You should also have a just in time (JIT) training program since inevitably people will walk into your EOC cold when a disaster occurs. Consider training that is modular.

Get an exercise in early. This is a great way to reinforce familiarity for users but to also work the kinks out of the system. Ideally, a vendor rep should be present for the exercise so they can see potential issues, even if they can’t fix them on the spot.

Moving into the future, exercise regularly to maintain proficiency and always keep an eye out for opportunities to improve. Recognize that processes evolve over time and technology is obsolete after a couple of years, so your platform should be evolving to avoid stagnation. Maintain a relationship with your vendor but keep an eye on what else is out there. Challenge your vendor to rise to the occasion, be innovative, and to continue meeting your needs. If they can’t, it’s time to look elsewhere.

Through the entire process, interfacing with vendors can be challenging if the right people aren’t involved. My preference is to not be working with someone who has never worked in an EOC or someone who is a ‘typical and generic’ salesperson. Ideally, vendor representatives will have some EOC experience so they can relate to your needs. Your own representative, ideally, should also be able to meet the vendor halfway, being an emergency manager with some tech savvy.

What experiences do you have with EOC management platforms? Any words of wisdom to share about the process?

© 2021 Tim Riecker, CEDP

Emergency Preparedness Solutions, LLC®

Through many of my writings on the Incident Command System (ICS), the training shortfalls we have with ICS, and the fallacy of most local governments relying on incident management teams, I have a different take that I’ve been thinking through.  The concept is similar to that of an Incident Management ‘Short’ Team, but pared down to be even more realistic and focused on support rather than assuming positions.  The training requirements, I expect, would be more palatable to many modestly sized local governments, and even more attainable for regional cooperatives.  For lack of any better terminology, I’m calling this the Incident Support Quick Response Team (ISQRT… because there always needs to be an acronym). 

I’ll note that while some teams call themselves Incident Support Teams, they really are functionally Incident Management Teams, simply softening the nomenclature for political purposes.  What I propose for the ISQRT lies much more firmly in the role of support. 

To give some context, when we look at the requirements for a Type 1 & 2 Wildfire Short Team, they list a team comprised of 20-26 individuals.  A short team is intended to get boots on the ground and begin managing the incident until a full team can arrive in force.  This is certainly appropriate for a Type 1 or 2 incident, which most local jurisdictions certainly aren’t able to manage on their own, though these types of incidents also typically have implications extending beyond just one jurisdiction.  The same reference shows a Type 3 IMT for out-of-area deployments; with this list showing a team of 9-12 personnel.  An in-area deployment team is generally even larger, as more subordinate positions are filled.  Also note that all these numbers are overhead staff for only one operational period.  Bottom line, it’s still far too big of a lift for most local jurisdictions I’ve worked with, even modestly sized cities, who don’t have the capability or capacity to support an IMT.

The consideration of the ISQRT follows a specific line of thinking, and that is that perhaps the most significant thing most local jurisdictions really need help in regard to formal incident management are the processes associated with it.  Come hell or, literally, high water, jurisdictions will have an incident commander and probably an operations section chief and safety officer.  They may even have a public information officer.  The concepts of the Planning Process and proactive incident management, despite dismal efforts of our current ICS training programs, simply become foreign to those who rarely, if ever, use them.  If we don’t use it, we lose it. Responders are largely used to addressing the needs of an incident here and now, when they face it, with only a modicum of (usually routine) tactical planning being performed.  These are the hallmarks of Type 5 and 4 incidents.  But as I’ve referenced so many times, the differences between a Type 4 and Type 3 incident are considerable, with a Type 3 having layers of complexity that most responders rarely, if ever, experience. 

With that understood, the core of the ISQRT needs to be support of the Planning Process.  I think we can agree that, even if not by true ICS definitions of qualification, most jurisdictions have reasonably experienced go-to people to fill the roles of Incident Command, Operations Section Chief, and Safety Officer.  Local jurisdictions also have their own finance people. 

Now wait… I can already hear some of the complaints.  Yes, I fully agree that most of the people we see in these positions certainly don’t have IMT training, nor do they have abundant experience beyond their jurisdiction.  Yet I offer that they still get through most Type 5 and 4 incidents just fine.  An ISQRT may help them fully get through a Type 3 incident, or at the very least help them begin a cycle of proactive incident management much sooner than an IMT can mobilize and arrive.  I’ll also offer that the emergency response chief officers of most jurisdictions simply won’t stand for a delegation of authority of Incident Commander to anyone else; most people who will fill the position of Operations Section Chief have a reasonable handle on tactics, though I acknowledge that it’s not as comprehensive as we would like; and essentially the same statement can be made for Safety Officers.  While local jurisdictions have their own finance people, I’ll accept that most aren’t experienced with working under pressures of an incident or familiar with things like FEMA reimbursement.  These are realistic shortcomings that we can’t ignore, so how can we address these shortcomings?  Good preparedness practices is the answer; such as emergency operations plans that provide solid guidance and are implementation-ready; scenario-based training programs, such as an improved ICS training curriculum; and exercises to test plans and keep people familiar with the roles and responsibilities. 

Getting back to the ISQRT.  Keep in mind that my philosophy here is not to fill ICS positions, rather it is to support incident management processes and activities.  So what could an ISQRT look like? 

• First, an Incident Management Advisor.  This is someone who can support the Incident Commander directly, as well as evaluate the incident management effort as a whole to identify needs and provide advice to the IC, as well as other command staff, who typically don’t have experience with larger incidents.
• Next, an Incident Planning Specialist.  With the foundation of proactive incident management being the Planning Process, the Incident Planning Specialist will help promote and foster that process, ideally mentoring a Planning Section Chief assigned by the local jurisdiction, but capable of assuming the position should the jurisdiction need and desire it.   
• Joining them would be a Planning Assistant, to support essential Planning Section responsibilities of situational awareness and resource tracking.  This, again, is ideally an advisor, who can help guide local personnel, but who can directly assume these responsibilities if requested. 
• I’m also suggesting an Operations and Logistics Planner.  A big part of proactive incident management is defining future operations, identifying resource needs for those operations, adjudicating those needs with what we have, and sourcing the balance.  The Operations and Logistics Planner is someone to help guide that process, working with the local Operations Section Chief (who is likely VERY focused on ‘now’ and very little on what’s next) and supporting a logistics structure that may or may not exist.   

That’s a total of four personnel per operational period.  That’s much more palatable for most jurisdictions and regions than building and maintaining even a Type 3 IMT.  Certainly there could be arguments for additional personnel to expand support in a variety of capacities. I’ll maintain first that the ISQRT concept is something I’ve only recently ‘formalized’ in my head so I’m sure it could use some refinement; and second that we should always be flexible when it comes to incident management, so having other options and capabilities can certainly be helpful, so long as the underlying premise of the ISQRT remains. 

What would it take to build ISQRTs?  First, deliberate effort rather than something ad-hoc. Jurisdictions and/or regions would need to identify the most experienced/capable/willing personnel for the ISQRT.  In terms of formal training, certainly a lot of the existing IMT training goes a long way, with perhaps a capstone course developed to specifically address the form and function of the ISQRT.  This reduces the burden of training and maintaining the personnel needed for a full IMT, while still ensuring that the ISQRT still has a full handle on the standards and best practices associated with incident management.  If local/regional ISQRTs are supported by states or another formal program, they can keep their direct skills sharp by taking rotating assignments on incidents which may be out of their area; or at the very least participating in regular exercises. 

Before you think the ISQRT is an outlandish thing, consider that many states may already be doing something similar to this, either through an informal program, or allowing jurisdictions to order overhead positions as single resources (i.e. a Planning Section Chief).  In my own experience of supporting preparedness and response for a wide variety of jurisdictions, the activities I identified are those which typically need the most support.  I’ve even served in similar capacities, being tasked as an IMT member, but in practice actually working more in an advisory role supporting local personnel. 

For my conclusion, I still support the concept of incident management teams, and for some large jurisdictions or even more capable regions, these are a realistic goal.  But for most jurisdictions they simply aren’t.  The concept of the ISQRT provides the support needed early in a larger incident to get in a cycle of proactive incident management.  The ISQRT isn’t a replacement for an IMT, but can provide solid support much more quickly than an IMT for most jurisdictions.  I also see the ISQRT as being flexible enough to support an Incident Command Post, an EOC, or a departmental operations center. 

What are your thoughts on this concept?  Do you see potential for application?  What obstacles exist? 

© 2020 – Timothy Riecker, CEDP

Emergency Preparedness Solutions, LLC®

<From FEMA>

On August 9, 2017, the National Oceanic and Atmospheric Administration (NOAA) issued the scheduled update for its 2017 hurricane season outlook. Forecasters are now predicting a higher likelihood of an above-normal season, and they increased the predicted number of named storms and major hurricanes. The season has the potential to be extremely active, and could be the most active since 2010.

Forecasters now say there is a 60 percent chance of an above-normal season (compared to the May prediction of 45 percent chance), with 14-19 named storms (increased from the May predicted range of 11-17) and 2-5 major hurricanes (increased from the May predicted range of 2-4). A prediction for 5-9 hurricanes remains unchanged from the initial May outlook.