EOC Management Platforms

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®

Facing Coronavirus/COVID19 and Implementing Business Continuity

Many organizations are trying to figure out how to sustain in the midst of COVID19.  While we have been advocating business continuity plans for decades, many organizations haven’t seen the necessity.  COVID19 seems to be demonstrating that necessity.  Understanding that many organizations are not familiar with business continuity, I’m offering some considerations in this article and have written on the topic in the past as well.  You may be tempted to short-cut the planning process in a sense of urgency… don’t do it.  This can result in missing important things. 

  1. Don’t do it alone.  The first step in all emergency planning is to build a team.  Get the right people together in a room to talk things through.  It ensures you have multiple perspectives and helps you divide the work. 
  2. Document, document, document.  Documentation is a key to successful planning and implementation. It helps support effective communication and understanding internally and externally. 
  3. Identify your Mission Essential Functions.  Mission Essential Functions are those activities that are absolutely necessary to keep your organization running.  Things like finance, payroll, HR, IT, and critical organizational operations (the activities that make you money or the activities that are part of your core organizational charter) are among your Mission Essential Functions.
  4. What else to think about? What work can or can’t be performed remotely?  Consider how your organization will handle the absence of your own employees if they become ill, must care for an ill family member, or have to care for children if schools are closed.  It’s also important to identify considerations for key partners (shippers, suppliers, etc.) if they are unable to conduct their services for a time.  How will these things impact your organization? 
  5. Engage HR.  Your Human Resources staff are critical cogs in the wheel of business continuity.  They will help identify HR/personnel/labor union policies, contracts, and other matters that may encumber the success of your business continuity.  Once problems are identified, set them to addressing those problems.  Sick leave policies, remote work policies, child care, and worker safety are among the priority discussions we’ve been seeing lately. 
  6. Engage IT.  Information Technology is a big aspect of business continuity.  Most business continuity plans call for many of an organization’s staff to work remotely.  Amazingly, so many organizations still have policies against working remotely, or at least no standard addressing how remote work is to be implemented, conducted, and managed.  HR and IT should be partnering on policies and procedures to address accountability, expectations of the organization, expectations of staff working remotely, and expectations of any staff still working in the office.   
    1. Along with policy matters, there are also matters of hardware, connectivity, and procedures.  What staff will be working remotely?  Has the organization provided them with the tools to do so?  Do they have internet connectivity from their remote location?  What systems and information will be accessed remotely and how?  How will system security be monitored and maintained?  Will a help desk be available to address problems?
    1. Test, test, test.  If you’ve not engaged a number of your staff in remote work before, now is the time.  Have some staff work from home and see how it goes.  Don’t just pick your most tech-savvy staff, either.  Now is the time to identify and address problems. 
  7. Consider the impacts of your changes.  Whatever organizational operations you are changing will have some impact on how you do business.  Where will your phones be directed to?  How will you conduct meetings?  How will signatures be handled?  How will you accept deliveries?  How will staff send mail from their remote work location?  Will you still meet face to face with clients/customers?  Does the office still need to be staffed? 
  8. Staff Communication.  Ensure that staff know what’s going on. Don’t leave them in the dark on this. Keep safety as the central point of your messaging.  Listen to their questions and concerns, and be timely and honest in your responses.  Keep open lines of communication.
  9. Stakeholder Communication.  Vendors, clients/customers, shippers, boards of directors, even the public at large… they all need to know what’s going on and how the continuity event will impact them and their interests.  Just as with your staff, listen to their questions and concerns, and be timely and honest in your responses.  Keep open lines of communication.

The items I listed here are some of the more common concerns and considerations I’ve seen as of recent.  There are a lot of other aspects to business continuity and business continuity planning.  Pressure may be on, but move with urgency, not reckless haste.  If your plan and systems aren’t properly in place, your organization will suffer from poor preparations. 

© 2020 Timothy Riecker, CEDP

Emergency Preparedness Solutions, LLC®

An Alternate Concept of Incident Management Support

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®

NOAA Issues Updated 2017 Hurricane Season Outlook

<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. 

Embracing the Playbook in Emergency Management

This morning I suggested to a client the possible use of a playbook as a training supplement for their duty officer program.  A playbook is a job aid, but more than just a check list or a chart.  Ideally, a playbook is a structured collection of job aids, broken down by situation for easy reference by whomever needs the information.

Playbooks are best known to be most extensively used in American football.  They contain a variety of strategies for accomplishing certain objectives (short yardage gain, long yardage gain, end zone scoring, kick return, etc.), with each strategy often accompanied by one or more diagrams of Xs (the opposition) and Os (your team), with lines showing movement and action by certain positions.  Playbooks are tested, practiced, and memorized by players before the season begins, but are constantly referenced every game by coaches and players alike.

playbook-diagram

Fundamentally, the play book exists because there are so many situations the team needs to respond to and several different ways in which they can respond.  While some of their plays are fairly routine, others are rarely, if ever, used.  Just like emergency management, however, it’s good to have the plan available if we need it.

Assembling a playbook for emergency management purposes doesn’t have any set standard, but as with any other tool or plan we assemble, we must first identify the purpose and the audience.  Play books can be assembled for elected officials and executives, duty officers and middle management, or dispatchers and first responders – it all depends on what is needed.  One thing that should be stressed, though… playbooks are NOT plans, nor should they be treated as a replacement for training.  Playbooks should be based upon established policy, plans, and procedures; and training still should be conducted on those policies, plans, and procedures.  A playbook is the collection of job aids which will help us to navigate the things people may not routinely do – which makes them excellent for emergency management applications.

Consider that the content of the playbook won’t (and probably shouldn’t) try to map out an incident from inception to completion.  The playbook is intended to address critical actions within an early timeframe of the incident.  Following this, a team should be assembled and striving to manage the incident using the planning process and referencing the foundational plans and policies.  There may be a few nuanced circumstances and activities within the playbook that are still relevant in the extended response, but these should be few.

The organization and content of the playbook should depend on the objectives and audience of the tool.  It should not be heavy in narrative and doesn’t require a lot of background as a plan might.  For emergency management purposes, most playbooks are organized by hazard and/or impact, with topics such as Mass Shooting, Severe Storm, or Power Outage.  For each topic, the essential elements of response can be identified, perhaps in check-list format.  Additional job aids such as decision tables, flow charts, and references can also be incorporated.  While I’m a big fan of keeping things digital, playbooks and similar references are better in hard copy, as this helps to ensure the information is always accessible.  Bind it (a three ring binder is best, so content can be updated as needed) and insert tabs for easy reference.  Be sure to give all users their own copy.

When creating the playbook, consider what information needs to be conveyed.  While some repetition may be necessary from topic to topic, reduce the amount of in-document references (i.e. See page 19 for additional information), as the purpose of the document is to help keep people organized.  Always keep the user in mind, ensuring that they understand each step and that they have the ability, resources, and authority to perform the identified actions.  Ensure that the playbook is a proper reflection of established policy and procedure and be sure to test it for effectiveness.  Train people in its content and use, and be sure to provide regular training and content updates and to incorporate its use into exercises.

I’m interested in hearing your thoughts on playbooks and if you have created and/or used them.  Of course, if your jurisdiction or organization is looking for assistance in developing a playbook for your critical activities, let us know!

© 2016 – Timothy M. Riecker

Emergency Preparedness Solutions, LLCYour Partner in Preparedness

 

Must Read – Evaluating Preparedness at Different Levels of Analysis by Brandon Greenberg

In the past I’ve made references to the DisasterNet blog written by Brandon Greenberg.  If you aren’t reading his blog, you certainly should be, as he routinely posts great material.  Yesterday’s post was no exception.

Brandon has been doing some research on evaluating preparedness, which is a topic I’ve also written about in the past and I feel is of great importance to continued improvements in emergency management.  His article, Evaluating Preparedness at Different Levels of Analysis provides a number of insightful thoughts and information which are certainly going down the right path.  With all hope, Brandon’s continued work may help us find better ways to evaluate preparedness.

-TR

 

 

 

Emergency Management: Why Failure is Necessary

One of the many podcasts I listen to is the TED Radio Hour from NPR.  For the uninitiated, the TED Radio Hour is a compilation of highlights from several TED Talks (you know what these are, right?) arranged around certain topics.  I like the topical arrangement and the sampling they do of the presentations, as well as the inclusion of interviews with many of the presenters.  Yesterday I listed to one from July 29, 2016 titled Failure is an Option.  In it, I was most drawn to the points made by Tim Hartford, an economist, and began to think that this guy needs to speak at some emergency management conferences.  What can an economist tell emergency managers?  His TED Talk is titled Trial, Error, and the God ComplexIt’s worth checking out.

How often do you hear someone in public safety proclaim that they don’t know about a certain topic or how to handle a certain situation.  Not very often.  Certainly we have a lot of confident, Type A people (myself included) who will not be stopped by a problem, even if we don’t know right off how we will solve it.  At the extreme end of this are those who refuse to plan.  Why?  Maybe they don’t want to be constrained by a plan, or maybe they don’t want something put in writing.  Maybe they simply don’t know right now what they will do, either a) hoping that it never happens, or b) assuming they will figure it out when it does.  Determination and persistence is good, but we can’t become ignorant despite it.  As I often mention in my posts, this is public safety, not a pick-up game of kick ball.  To me, there is nothing more serious.

Our egos drive us to feel that everything is on the line all the time.  While some may refuse to plan, others do plan, but the approach may not be realistic.  We’ve all seen plans that begin with one, two, maybe even three pages of assumptions.  That’s a lot of assuming for an emergency or disaster situation, which we all know is uncertain and dynamic.  Those long lists make me uncomfortable, as they should you.  Why do we do it?  Sure there are some things we can expect, but otherwise we are trying to dictate terms to the disaster.  Trust me, the disaster doesn’t give a damn about the plan you wrote or the terms and conditions you try to lay out for it.  But it makes us feel better by putting the disaster in a very defined box.  I know I’ve been guilty of this.

Let’s remove the ego.  Let’s proclaim that maybe we have no idea, or we have a few ideas but we aren’t sure which one is best.  Preparedness should be collaborative.  Get lots of ideas from people.  Talk though them and figure out which ones are the most viable.  Get these ideas down on paper, even loosely, and try them out.  We need to take advantage of our preparedness work to figure out the things we don’t know.

A number of years ago, it was identified through feedback and after action reports of incidents that the flow of information and resource requests in a certain EOC simply wasn’t working the way it was intended.  While I’m a big fan of the application of ICS in an EOC, the specific role an EOC plays as a multi-agency coordination center, the cross functions of some staff, and the politics involved aren’t really accounted for in ICS, so the strictest applications of ICS sometimes don’t apply well.  A small group of us were tasked to fix it.  While we each had some theories, none of really knew why the current processes weren’t working.  So we set up a small exercise solely for this purpose.  Our observations helped us identify the root cause of the problem.  The members of our group, all experienced EOC personnel, had different theories on how to solve the problem.  We went again to exercises, this time a series of small ones.  We ushered some people into the EOC, each time giving them a flow chart and some narrative on what each person should be doing relative to the processes we devised.  The injects flowed and we observed the outcomes.  We saw what worked and what didn’t.  We then assembled an amalgamation of the best traits of each methodology into a new process.  Then guess what we did – we exercised that – and it worked.  Not only did we have a great scientific and structured approach, we also had validation of our final product – one that stood up to further exercises and actual incidents.

Does trial and error take time?  Sure it does.  Does it always yield results?  Yes – although not always positive ones – but those are still results.  It’s important to remember to collect data on each of our attempts.  Just like an exercise we want to evaluate and document.  Sometimes our ideas turn out to be epic failures, and that’s OK.  Had we not found this out during our trial and error, just like an exercise, it could have been devastating and costly in a real life application.  A severe mistake during an incident can be career ending for you, and life ending for those you are sworn to protect.

The bottom line is that it’s OK to fail – just try to control when and how you fail.  In order to accept that premise, however, we need to let go of the super Type A hero/god/ego thing.  Yes, we can learn from successes, but we learn more from failure, especially with a little root cause analysis.  Sometimes things look great on paper, but unless you actually try them out, you’ll never know.  In your trial and error, also consider different variables which may have influence on the outcomes.  It’s great to plan for a response and practice it on a sunny day, but what about pouring rain, freezing temperatures, or high winds?  How does this impact your plan?  Often we can make assumptions (remember those?), but we’ll never really know unless we try.

Do you buy into this?  Thoughts appreciated.

© 2016 – Timothy Riecker, CEDP

Emergency Preparedness Solutions, LLCYour Partner in Preparedness

An Open Letter to LinkedIn Discussion Group Moderators

For those of you tuning in for your (somewhat) regular fix on emergency management and homeland security commentary, I apologize for this quick detour.  I encourage you, however, to read on and provide your thoughts and feedback on a matter which relates to how you are able to view my posts.  There are a few inconvenient practices out there which I feel a need to address.

While I have a humbling and ever growing number of people who follow my blog directly at www.triecker.wordpress.com, many read my posts through a variety of LinkedIn discussion groups.  Some of these groups were created and simply exist publicly, while others are members-only and diligently maintained by moderators who do great work to keep certain posts out of their group, such as those that are largely irrelevant and those which blatantly serve no other purpose than to market products and services.  As a member of several of these discussion groups, I am greatly appreciative of the time and effort these moderators put in.  I do, however, have some important feedback.

As I have been blogging for a few years now and cross posting to several LinkedIn discussion groups, I’ve encountered some practices with moderators with which I disagree.  Most recently, a discussion thread which originated from one of my blog posts was, inexplicably, shut down and closed to further comment.  The discussion in the thread was lively, with several people contributing to an excellent dialogue.  There didn’t appear to be any nastiness or inappropriate behavior, and all comments were on topic.  The thread was shut down with no notice, publicly or privately.  I’m not aware of there being any automatic limits on replies, but if there are, I don’t see a reason why.  This was an unfortunate occurrence which limited productive dialogue of your members.

Second, there are several of these groups that have an anti-spam feature.  On the surface, this is excellent!  In practice, especially for someone who appreciates active dialogue with those who comment, it’s a royal pain in the ass.  Essentially, after I reach some magic number of replies within a discussion thread, my replies will then go off into the ether, awaiting approval by the moderators before they are posted.  This process severely stalls great dialogue.

Lastly, many of these groups have certain rules which disallow posts which include blatant marketing content.  This is a great rule, as many of us have received notice from open groups with posts which are 100% pure marketing – which is not a reason why most people join these groups.  That said, these rules have been applied a bit too strictly and without common sense.  I’ve had moderators contact me (and some who don’t), refusing to post an article, simply because I include the name of my company and a link to our webpage at the bottom of my blog.  I’ve had others refuse to post an article because I include a sentence or two at the end of my blog about the services my company provides.  Allow me to make a few points with this… 1) The vast majority of my blogs run from 500-800 words.  The inclusion of my company name/web address, or a sentence or two at the end of that post related to the services my company provides does not make my post an advertisement.  I’d like to think there is still plenty of intellectual value to what I’m writing about.  2) This is LinkedIn.  It’s a social media platform for professionals.  That means that a certain amount of professional promotion should be expected.  3) Having given plenty of presentations for trade shows and membership groups, their guidelines regularly allow the ‘soft sell’, which means that while the bulk of your presentation is not directly about marketing your business, they usually allow a minute or two at the end to mention what your company does.  This is a pretty fair courtesy which I think is quite reasonable for discussion groups to apply.

Final words – Moderators, I greatly appreciate the time you put in and what you do.  Seriously.  You help keep a lot of crap and spam away from our inboxes and notifications.  I implore you, however, to remember what the intent of LinkedIn is, and with that in mind apply the rules of your discussion groups to maximize dialogue for the benefit of your members.

  • Thank you.

<no marketing message posted here>

Timothy Riecker, CEDP