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:
- Change is hard
- 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®