Tag ICS training sucks

Incident Management is a Technical Skill

Tim Riecker, The Contrarian Emergency Manager 1 Comment

Last week I had the pleasure of speaking with Rob Burton on his Tea and Chaos webinar. We talked about the Incident Command System (ICS) and what can make it successful. Since our conversation, I’ve had some continued thoughts about ICS and the complaints people have about it. One of the complaints I hear more often is that it is the system that is flawed because it’s too challenging for people to use. They argue that it should be easier to implement with little training.

I believe I mentioned in the webinar that using ICS is not like riding a bike or tying a shoelace. It’s not something you can be trained on then expect to be able to perform years later (with no interim training and application) with little to no difficulty. ICS, a tool of incident management. Incident management is not only a perishable skill, but also a technical skill.

A technical skill is something you are trained on and hone with practice over time. Technical skills are typically industry specific and require a specialized knowledge set. It could be anything from video editing to surgery. In either of these examples, people learn the knowledge needed and acquire the skills to implement. They learn and perform every detail, becoming proficient in the practice, processes, and associated tools. If they want to stay current and relevant, they take opportunities for continuing education. They learn about new approaches and tools. They maintain proficiency through repetition and application of new knowledge.

Incident management is no different. ICS is just one of the tools we use in incident management, and as such it is something we must learn, practice, hone, and maintain. If you aren’t using it and learning more about it, those skillsets will diminish.

Let’s continue to change our perspective on preparedness for incident management. If you aren’t familiar with my years-long crusade to improve ICS training (ICS Training Sucks), here is some background reading. It’s not only the curriculum we need to change, but also our expectations of learners. What do we want learners to be able to do? Continuing on with one of the examples… not every doctor is a surgeon. So not every responder or emergency manager is an incident manager. They should know the fundamentals, just as most doctors are trained in the fundamentals such as anatomy and physiology, cell biology, etc. We certainly want our responders and emergency managers to have awareness of incident management concepts, as they may certainly be called upon to play a role in a greater organization, though if incident management isn’t their specialization, they likely won’t actually be part of the core ICS or emergency operations center (EOC) staff, even though they will be functioning within the system.

Some will need to learn more, though. Which means they need training – not just on WHAT incident management is, but HOW we manage incidents. Much of our core ICS training is focused on what ICS is, with very little on how to use it. Expecting people to become good incident managers just by taking ICS courses is foolish. It would be like expecting a doctor to become a proficient surgeon because they have learned about the tools in the operating room. So before we even get to the tool (ICS), we need to be teaching about the function (incident management). Incident management is composed of a variety of capabilities and skillsets, such as leadership and project management, which are barely touched upon in existing training. Once those are learned, then we can teach the tools, such as ICS.  

Most who are candidates for incident management should become generalists before they become specialists. General surgeons have a broad knowledge and perform the vast majority of surgeries. Some go on to be specialists. In incident management that specialization could be subject matter expertise in the management of certain hazards or impacts, or performing in a specific function. I see this as being the difference between local incident management capabilities and formal incident management teams. Specialization is supported by position-specific training, among other mechanisms. Yet we don’t really have anything to support incident management generalists.

For all that we’re accomplishing with building incident management capability, we still have a significant gap at the local level across the nation. To expect specialization within most local jurisdictions simply isn’t realistic. We define a lot of the practice through NIMS position descriptions and task books, yet we are skipping some critical steps. We are going right to focusing on the tool instead of the practice, yet at the foundational levels we aren’t teaching enough about how to implement the tool – and in fact spending far too much time on higher level implementations of the tools that most will never see (that’s the ICS 400 course, by the way). We are wasting time and resources by training people in position specific courses when what they really need for their jurisdiction is to become good incident management generalists.

Those complaining that ICS is too difficult, are failing to see the bigger picture the technical skills needed to build professions. Professionals must keep up on the rigors and requirements of their technical skills. If you don’t want to keep up on these things, then I’ll argue that you aren’t dedicated to the profession.

While I feel that what we are doing to build formal incident management teams is great and largely on target, it’s everything that comes before that which needs to be completely reimagined. We need a group of incident management professionals to come together on this. Professionals who understand the gaps that exist and are willing to deviate from current practices and expectations to build what is needed to address those gaps. They can’t be afraid of the traditionalists or those who are only focused on building high-level capability. All disasters begin and end locally, and we are ignoring the incident management needs of most local jurisdictions. We are also building a system focused on high-level capability that doesn’t have a firm foundation, which makes me question sustainability. We can do better. We must do better.

© 2022 Tim Riecker, CEDP

Emergency Preparedness Solutions, LLC®

ICS 400 Training – Who Really Needs It?

Tim Riecker, The Contrarian Emergency Manager 6 Comments

A few days ago I had a bit of discussion with others on Twitter in regard to who actually has a need for ICS 400 training. I think a lot of people are taking the ICS 400 (Advanced ICS for Command and General Staff) course for the wrong reasons. While I’d never dissuade anyone from learning above and beyond what is required, we also, as a general statement, can’t be packing course offerings with people who don’t actually need the training. There is also an organizational expense to sending people to training, and the return on that investment decreases when they don’t need it and won’t apply it. Overall, if you are a new reader, I have a lot of thoughts on why our approach to ICS Training Sucks, which can be found here.

Before we dig any deeper into the topic, let’s have a common understanding of what is covered in the ICS 400 course. The course objectives identified in the National Preparedness Course Catalog for some reason differ from those actually included in the current 2019 version of the course, so instead I’ll list the major topics covered by the two-day course:

  • Incident Complex
  • Dividing into multiple incidents
  • Expanding the Planning Capability
  • Adding a second Operations or Logistics Section
  • Placement options for the Intel/Investigations function
  • Area Command
  • Multi-Agency Coordination
  • Emergency Operations Centers
  • Emergency Support Functions

For this discussion, it’s also important to reference the NIMS Training Program document, released in the summer of 2020. This document states many times over that it includes training recommendations and that the authority having jurisdiction (AHJ) determines which personnel are to take which courses. This document indicates the ICS 400 is recommended for:

  1. ICS personnel in leadership/supervisor roles
  2. IMT command, section, branch, division, or group leaders preparing for complex incidents

Note that while #1 above seems to fully capture anyone in a leadership/supervisor role, the document also says that IMT unit, strike team, resource team, or task force leaders preparing for complex incidents do NOT need the training. I’d say this certainly conflicts with #1 above.

With that information provided, let’s talk about who really needs to take the ICS 400 from a practical, functional perspective. First of all, looking at recommendation #1 above, that’s a ridiculously broad statement, which includes personnel that don’t need to have knowledge of the course topics. The second recommendation, specific to IMTs, I’ll agree is reasonably accurate.

Having managed a state training program and taught many dozen deliveries of the ICS 400 course, I’ll tell you that the vast majority of people taking the course don’t need to be in it. I’d suggest that some deliveries may have had absolutely no one that actually needed it, while most had a scant few. Much of this perspective comes from a relative determination of need of personnel that fit within recommendation #1 above. Just because someone may be an incident commander or a member of command and general staff, doesn’t necessarily mean they need to take ICS 400. It’s very likely that through their entire career all of the incidents they respond to and participate in the management of can be organized using standard ICS approaches.

Interface with an EOC does not mean you need to take ICS 400. There is, in fact, a better course for that, aptly named ‘ICS/EOC Interface’. More people need to take this course than the ICS 400. I’m also aware that some jurisdictions require ICS 400 for their EOC staff. The ICS 400 course doesn’t teach you how to function in or manage an EOC. Again, the ICS/EOC Interface course is the better solution, along with whatever custom EOC training is developed (note that none of the FEMA EOC courses will actually teach you how to manage or work in YOUR EOC). If you feel that people in your EOC need to know about some of the concepts within the ICS 400, such as Multi-Agency Coordination or Area Command, simply include the appropriate content in your EOC training. To be honest, I can tell most EOC personnel what they need to know about an Area Command in about three minutes. They don’t need to sit through a two-day course to learn what they need to know.

Cutting to who does need it (aside from IMT personnel), personnel who would be a member of Command and General Staff for a very large and complex incident (certainly a Type I incident, and MAYBE certain Type 2 incidents) are the candidates. Yes, I understand that any jurisdiction can make an argument for their fire chief or police chief, for example, being the IC for an incident of this size and complexity, though let’s consider this in a relative and realistic sense. Most incidents of this size and complexity are likely to span multiple jurisdictions. Particularly in a home rule state, that fire chief or police chief is typically only going to be in charge of that portion of the incident within their legal borders. Although that incident may be a Type I incident taken as a whole, it will likely be managed in large part by a higher AHJ, which may use some of the concepts outlined in the ICS 400. While local government is still responsible for managing the portion of the incident within their borders, they are much less likely to utilize any of the ICS 400 concepts themselves. Along a similar line of thought, most jurisdictions don’t have hazards that, if they become incidents, would be of such size or complexity within their jurisdiction that would require use of these concepts. This leaves larger, more populous jurisdictions generally having a greater need for this level of training.

At some point, every state and UASI was required, as part of their NIMS implementation, to develop a NIMS training plan. Most of the plans I’ve seen further perpetuate the idea that so many people must have ICS 400 training. As part of this, many states require that anyone holding the position of fire chief must have ICS 400. Considering my argument in the paragraphs above, you can see why this is tremendously unnecessary. We must also consider erosion of knowledge over time. As people do not use the knowledge, skills, and abilities they have learned, that knowledge erodes. This is highly likely with the concepts of ICS 400.

A lot of states and other jurisdictions need to take a more realistic look at who really needs ICS 400 training. I’d also like to see some clarification on the matter in FEMA’s NIMS Training Guidance. It’s not about making this training elite or restricting access, but it is about decreasing the perceived and artificially inflated demand for the course.

What’s your jurisdiction’s take on ICS 400 training?

© 2021 Tim Riecker, CEDP

Emergency Preparedness Solutions, LLC®

EOCs and IMTs

Tim Riecker, The Contrarian Emergency Manager 3 Comments

The world of incident management is foggy at best. There are rules, sometimes. There is some valuable training, but it doesn’t necessarily apply to all circumstances or environments. There are national models, a few of them in fact, which makes them models, not standards. Incident management is not as straight forward as some may think. Sure, on Type 4 and 5 incidents the management of the incident is largely taking place from an incident command post. As you add more complexity, however, you add more layers of incident management. Perhaps multiple command posts (a practical truth, regardless of the ‘book answer’), departmental operations centers, emergency operations centers at various levels of government, and an entire alphabet soup of federal operations centers at the regional and national levels with varying (and sometimes overlapping) focus. Add in operational facilities, such as shelters, warehouses, isolation and quarantine facilities, etc. and you have even more complexity. Trying to map out these incident management entities and their relationships is likely more akin to a tangle of yarn than an orderly spiderweb.

Incident Management Teams (IMTs) (of various fashion) are great resources to support the management of incidents, but I often see people confusing the application of an IMT. Most IMTs are adaptable, with well experienced personnel who can pretty much fit into any assignment and make it work. That said, IMTs are (generally) trained in the application of the incident command system (ICS). That is, they are trained in the management of complex, field-level, tactical operations. They (usually) aren’t specifically trained in managing an EOC or other type of operations center. While the principles of ICS can be applied to practically any aspect of incident management, even if ICS isn’t applied in the purest sense, it might not be the system established in a given operations center (in whatever form it may take). While IMTs can work in operations centers, operations centers don’t necessarily need an IMT, and while (formal) IMTs are great resources, they might not be the best solution.  

The issue here certainly isn’t with IMTs, though. Rather it’s with the varying nature of operations centers themselves. IMTs are largely a defined resource. Trying to fit them to your EOC may be a square peg/round hole situation. It’s important to note that there exists no single standard for the organization and management of an EOC. NIMS provides us with some optional models, and in practice much of what I’ve seen often has some similarity to those models, yet have deviations which largely prevent us from labeling what is in practice with any of the NIMS-defined models in the purist sense. The models utilized in EOCs are often practical reflections of the political, bureaucratic, and administrative realities of their host agencies and jurisdictions. They each have internal and external needs that drive how the operations center is organized and implemented. Can these needs be ultimately addressed if a single standard were required? Sure, but when governments, agencies, and organizations have well established systems and organizations, we’ll use finance as an example, it simply doesn’t make sense to reorganize. This is why we are so challenged with establishing a single standard or even adhering to a few models.

The first pathway to success for your operations center is to actually document your organization and processes. It seems simple, yet most EOCs don’t have a documented plan or operating guideline. It’s also not necessarily easy to document how the EOC will work if you haven’t or rarely have activated it at all. This is why we stick to the CPG-101 planning process, engaging a team of people to help determine what will or won’t work, examining each aspect from a different perspective. I also suggest enlisting the help of someone who has a good measure of experience with a variety of EOCs. This may be someone from a neighboring jurisdiction, state emergency management, or a consultant. Either way, start with the existing NIMS models and figure out what will work for you, with modifications as needed. Once you have a plan, you have a standard from which to work.

Once you have that plan, train people in the plan. Figure out who in your agency, organization, or jurisdiction has the knowledge, skills, and abilities to function within key positions. FEMA’s EOC Skillsets can help with this – even if the positions they use don’t totally map to yours, it’s not difficult to line up most of the common functions. Regardless of what model you are using, a foundation of ICS training is usually helpful, but DON’T STOP HERE. ICS training alone, even if your EOC is ICS-based, isn’t enough. I can practically guarantee your EOC uses systems, processes, or implementations unique to your EOC which aren’t part of ICS or the ICS training your personnel received. Plus, well… if you haven’t heard… ICS training sucks. It can be a hard truth for a lot of entities, but to prepare your personnel the best way possible, you will need to develop your own EOC training. And of course to complete the ‘preparedness trifecta’ you should then conduct exercises to validate your plans and support familiarity.

All that said, you may require help for a very large, long, and/or complex incident. This is where government entities and even some in the private sector request incident management support. Typically this incident management support comes from established IMTs or a collection of individuals providing the support you need. The tricky part is that they aren’t familiar with how you are organized or your way of doing things. There are a few ways to hedge against the obstacles this potentially poses. First, you can establish an agreement or contract with people or an organization that know your system. If this isn’t possible, you can at least (if you’ve followed the guidance above) send your plan to those coming to support your needs, allowing them at least a bit of time in transit to study up. Lastly, a deliberate transition, affording some overlap or shadowing time with the outgoing and incoming personnel will help tremendously, affording the incoming personnel to get a hands-on feel for things (I recommend this last one even if the incoming personnel are familiar with your model as it will give an opportunity to become familiar with how you are managing the incident). Of course all of these options will include formal briefings, sharing of documentation, etc.

Remember, though, that there are certain things your agency, organization, or jurisdiction will always own, especially the ultimate responsibility for your mission. Certain internal processes, such as purchasing, are still best handled by your own people. If your operations are technical and industry-specific, such as for a utility, they should still be managed by your own people. That doesn’t mean, however that your people can’t be supported by outside personnel (Ref my concept of an Incident Support Quick Response Team). The bottom line here is that IMTs or any other external incident support personnel are great resources, but don’t set them up for a slow start, or even failure, by not addressing your own preparedness needs for your EOC. In fact any external personnel supporting your EOC should be provided with a packet of information, including your EOC plan and procedures, your emergency operations plan (EOP), maps, a listing of capabilities, demographics, hazards, org charts for critical day-to-day operations, an internal map of the building they will be working in, and anything else that will help orient them to your jurisdiction and organization – and the earlier you can get it to them the better! Don’t forget to get your security personnel on board (building access cards and parking tags) and your IT personnel (access to your network, printers, and certain software platforms). Gather these packets beforehand or, at the very least, assemble a checklist to help your personnel quickly gather and address what’s needed.

© 2021 Tim Riecker, CEDP

Emergency Preparedness Solutions, LLC®

A Re-Framing of Incident Management Structures

Tim Riecker, The Contrarian Emergency Manager 5 Comments

I recently finished reading Team of Teams by Gen. Stanley McChrystal. The General tells of the new perspective and strategy he needed to employ to better manage the Joint Special Operations Task Force in the 2000s hunting down Al Qaeda insurgents. The Task Force was being out paced by a decentralized organization with all the home team advantages. McChrystal and his team assessed where the Task Force was failing and applied new principles which brought them increased success. The book not only provides examples from the Task Force, but also goes through history and various applications of business and industry to illustrate how different perspectives on organizational management can bring better results. It was fascinating to read this with the constant thought of incident management on my mind and seeing how the early state of the Joint Special Operations Task Force, as well as many of the business and industry examples, had many of the same challenges of incident management today. Highly recommended reading!

Those of you who have been with me for a while know that I’m a big fan of the Incident Command System (ICS), even though I have a lot of issues with how we have been trying to train people to use it (ICS Training Sucks). Similarly, I have a lot of passion for Emergency Operations Centers (EOCs) and the various organizational models which can be used in these facilities, including those which have a lot of similarity to ICS. I’ll collectively refer to these as incident management.

The root of Gen. McChrystal’s book emphasizes the benefits of organizations that are flexible and collaborative, vs the traditional hierarchal organizations. It’s interesting that much of what we espouse as successful implementations in incident management focuses on flexibility and working together, yet the organizational models we use, and sometimes even just the way we depict them, impedes this success. The traditional org charts that we obsessively plaster up on every wall of every command post and EOC emphasize a chain of command, which is so often confused with lines of communication and the continued and necessary close coordination we need to have in an incident management organization. While chain of command is still necessary to understand, that’s really the only value of the hierarchal organization chart.

From Team of Teams, I’d like you to look at two sets of graphics which are found on this site. (these are important to look at… so click the link!) The first identifies complicated vs complex systems (or environments). Complicated systems may be multi-faceted, but largely have a linear progression. Complex systems are unpredictable. I’d offer that incident management can include both, being a complex system until such a point that we can stabilize the incident, then morphing into a more predictable though still complicated system. The primary argument of Team of Teams is to match the organizational structure to the environment, meaning that while a more linear, hierarchal organizational structure is fine for a complicated system, a more dynamic structure is needed for dealing with complex systems.

The second set of graphics depicts three organizational models from Team of Teams. The first is the familiar Command model. This model, as I mentioned earlier, emphasizes chain of command, though clearly also emphasizes stove-piping, which isn’t a reflection of best practices for being dynamic or having coordination across organizational elements. As argued in the book, the separation of organizational elements only works if their functions are not related or connected. We know in ICS that each function is strongly connected to others.  As such, the Command model really doesn’t represent the reality of ICS, even though it’s what we always depict.

The second model, labeled Command of Teams shows collaboration within each team. In consideration of ICS functionality, when I have managed a Planning Section, I expect my team to work together. Yes, they each have different roles and responsibilities, but they all contribute to the primary purpose of the Planning Section. As just a small example, the Demob Unit absolutely must work with the Resources Unit to have knowledge of what resources are on the incident and various data sets about each. They must also collaborate with the Situation Unit Leader who can provide not only information on the current state of things, but hopefully projections of the situation, helping the Demob Unit Leader to develop more accurate timelines for demobilization. This is all well and good, but this model still maintains separation of the major components of the organization (stove-piping).

Next, consider the Team of Teams model, the third in this graphic. At first glance, it looks messy and chaotic, but consider that the principles it tells us are what we should be doing. Again, as a Planning Section Chief, I expect my team members to not just work together, but to coordinate across the entire organization as needed to get their jobs done. Using the Demob Unit as a continued example, their job requires information from and coordination with Logistics, certainly Operations, and even Finance/Admin, and Safety. Their ability to coordinate with others has nothing at all to do with chain of command, and I know my team is more effective when they are interfacing across the organization. My team quickly learns that they don’t need my permission to coordinate with others.

There are several points emphasized in the Team of Teams book that support the Team of Teams model, particularly through the lens of incident management, including:

  1. Efficiency vs Adaptability. Certainly, in incident management we want both, but particularly in the earlier stages of response, adaptability is more important than efficiency. We need to be able to respond to a dynamic, changing environment in the best ways possible. The Team of Teams model maximizes our adaptability.
  2. Procedure vs Purpose. The structure of checklists and other depictions of rigid procedures, which largely serve to strengthen efficiency, can only get us so far in a complex environment. Leaning back into the efficiency vs adaptability argument, rigidity doesn’t serve us well in incident management. When we focus on purpose, we are more adaptable and resilient. When people are focusing exclusively on their own narrow set of tasks, they often lose the big picture that is the overall purpose. In the complexity of incident management, we need to see the forest, not just the trees, in order to understand needs, implications, priorities, dependencies, and options.
  3. Mutually Exclusive and Collectively Exhaustive (MECE) (pronounced mee-see). MECE is used extensively in the business consulting world to depict clear delineation of tasks within one large activity. ICS likes to force us into a MECE environment, which is certainly great for efficiency and eliminating duplication of efforts. While those things are important, the MECE principal eliminates overlap and coordination. The book uses a great example of a sports team to drive this home. Using a sports analogy of my own, consider that in hockey each team has the broad player categories (positions) of forwards, defensemen, and goaltenders. While they each have very distinct purposes and playing strategies, they need to have some overlap to support teamwork, effectiveness, and contingencies. They can’t simply function in a bubble and expect success. ICS loves the rigidity of separating tasks to specific positions, but to be successful there needs to be coordination.
  4. Common Operating Picture. The book uses the term ‘collective intelligence’, but the principal is the same, being that members of the team at large are at least familiar with what is going on, can access more detailed information as needed, and have the information they need to best perform their jobs. The Team of Teams concept promotes this exchange of information and expanded situational awareness.
  5. Leadership at all Levels. While Team of Teams doesn’t explicitly say this, there are several references related to it. We know in any effective organization, especially incident management, the Incident Commander or EOC manager shouldn’t be the only leader. We need leadership practiced at all levels of the organization. We expect Section Chiefs to be leaders; Unit Leaders, Branch Directors, Group Supervisors, etc. Even individual resources can exhibit and practice leadership. This contributes to our adaptability.

After examining these models, I think most will agree that in incident management we really do use the Team of Teams model, but not to the fullest extent. Why is that? I think it’s primarily because we graphically depict our organizations using the Command model and so much of our mindset is fixated on that structure and a perceived rigidity of the positions and flow within that structure. Sure, the Command model is cleaner and less intimidating, but it psychologically predisposes us to silos. In ICS, for example, we do have people coordinating across sections, but aside from the ‘scripted’ activities (i.e. those within the Planning Process), it seems to not come easily.  

We have a lot of room for improvement, and I think we can do so without violating any of the tenets of ICS. We can open ourselves to a more dynamic environment while still maintaining chain of command, unity of command, and span of control. Safety is still emphasized. ICS espouses the free flow of information, but flow of information is different from collaboration – a term rarely found in ICS materials.  In many plans and training that I develop, when I’m referencing certain positions, I often identify the key interactions that position has both within and external to the organization. Interactions are a key to success and need to not just be acknowledged, but emphasized. There is an almost social aspect to the Team of Teams model, but not in the butterfly kind of way. It’s simply a socialization of the system. More people being familiar with what’s going on and what the priorities of others are. This type of environment encourages better communication, more ideas, and an ability to make course corrections on the fly. I think some will push back saying that they want people to ‘stay in their lanes’, but professionals who are well trained should still maintain a primary focus on their job.

Gen. McChrystal emphasizes that a big key to really implementing the Team of Teams model is the mindset of the ranking officer – the Incident Commander or EOC Manager in our case. They need to be willing to let go of what they might have traditionally controlled. They are still absolutely in command, but we need to consider what they should be directly in command of. What decisions REALLY need to be made by the IC or EOC Manager? I’ve seen too many people at that level want to be involved in every decision. I’ve heard all the excuses. Yes, they are the ones ultimately responsible. Yes, they need to justify actions to their boss. But that doesn’t mean they need to have their hands in everything. That’s often less than effective. (Funny enough, I’ve also experienced those who espoused these reasons for micromanaging, yet they were never available to the team to actually make decisions. That puts the team in a difficult position.)

If the ICs or EOC Managers are the ones who set objectives, we could go the extent of saying that any changes of activity within the scope of those objectives should be allowable without needing their approval. That might be a bit extreme for some (yes, I know that they are approving the incident action plan, which identifies things to the tactical level), but if we trust the people who are put in key positions throughout the organization – not only are they all leaders, but armed with a common operating picture and knowing what is called ‘the Commander’s intent’ in military lingo – we should trust that when urgency dictates, they are empowered to make decisions. Pushing decision-making to the lowest practical level can make us more responsive, perhaps saving lives or at least ‘stopping the bleeding’ until a definitive strategy can be developed.

Show the Team of Teams model around a bit. Talk about it. Sure, when people look at that org chart for the first time, I expect there will be some exasperated reactions. But when they read up on it and think it through, they will realize that we already practice it in part. What’s stopping us from full implementation? Two things… a little cultural shift and a varying degree of ego. Silly excuses for not doing things better. We are professionals, after all – right?

There is so much more gold to mine in the Team of Teams book. As mentioned before, I highly recommend this for those interested in organizational development, organizational psychology, incident management, and other related areas. It’s filled full of great examples and will likely prompt a lot of thought as it did for me.  

As always, I’m interested in your thoughts and feedback on this.

© 2021 Timothy Riecker, CEDP

Emergency Preparedness Solutions, LLC®

Incident Management Advisors

Tim Riecker, The Contrarian Emergency Manager 2 Comments

It’s frustrating to see poor incident management practices. For years I’ve reviewed plans that have wild org charts supposedly based on the Incident Command System (ICS); have conducted advanced-level training with seasoned professionals that still don’t grasp the basic concepts; have conducted and evaluated exercises and participated in incident responses in which people clearly don’t understand how to implement the most foundational aspects of ICS. On a regular basis, especially since people know my focus on the subject, I’m told of incident management practices that range from sad to ridiculous.

Certainly not everyone gets it wrong. I’ve seen plans, met people, and witnessed exercises and incidents in which people clearly understand the concepts of ICS and know how to put it into action. ICS is a machine, but it takes deliberate and constant action to make it work. It has no cruise control or auto pilot, either. Sometimes just getting the incident management organization to stay the course is a job unto itself.

If you are new here, I’ve written plenty on the topic. Here’s a few things to get you pointed in the right direction if you want to read more.

ICS Training Sucks. There are a series of related posts that serve as a key stone to so much that I write about.

The Human Factor of Incident Management. This bunch of related articles is about how ICS isn’t the problem, it’s how people try to implement it.  

As I’ve mentioned in other posts, it’s unrealistic for us to expect most local jurisdictions to assemble and maintain anything close to a formal incident management team. We need, instead, to focus on improving implementation of foundational ICS concepts at the local level, which means we need to have better training and related preparedness activities to promote this. Further, we also know that from good management practices as well as long-standing practices of incident management teams, that mentoring is a highly effective means of guiding people down the right path. In many ways, I see that as an underlying responsibility of mine as a consultant. Sometimes clients don’t have the time to get a job done, but often they don’t have the in-house talent. While some consultants may baulk at the mere thought of building capability for a client (they are near sighted enough to think it will put them out of work), the better ones truly have the interests of their clients and the practice of emergency management as a whole in mind.

So what and how do we mentor in this capacity? First of all, relative to incident management, I’d encourage FEMA to develop a position in the National Qualification System for Incident Management Advisors. Not only should these people be knowledgeable in implementations of ICS and EOC management, but also practiced in broader incident management issues. Perhaps an incident doesn’t need a full incident management team, but instead just one or two people to help the local team get a system and battle rhythm established and maintained. One responsibility I had when recently supporting a jurisdiction for the pandemic was mentoring staff in their roles and advising the organization on incident management in a broader sense. They had some people who handled things quite well, but there was a lot of agreement in having someone focus on implementation. I also did this remotely, demonstrating that it doesn’t have to be in person.

In preparedness, I think there is similar room for an incident management advisor. Aside from training issues, which I’ve written at length about over the years (of course there will be more!), I think a lot of support is needed in the realm of planning. Perhaps a consultant isn’t needed to write an entire plan, but rather an advisor to ensure that the incident management practices identified in planning documents are sound and consistent with best practices, meet expectations, and can be actually implemented. So much of what I see in planning in regard to incident management has one or more of these errors:

  1. Little mention of incident management beyond the obligatory statement of using NIMS/ICS.
  2. No identification of how the system is activated and/or maintained.
  3. As an extension of #2, no inclusion of guidance or job aids on establishing a battle rhythm, incident management priorities, etc.
  4. An obvious mis-understanding or mis-application of incident management concepts/ICS, such as creating unnecessary or redundant organizational elements or titles, or trying to force concepts that simply don’t apply or make sense.
  5. No thought toward implementation and how the plan will actually be operationalized, not only in practice, but also the training and guidance needed to support it.

In addition to planning, we need to do better at identifying incident management issues during exercises, formulating remedies to address areas for improvement, and actually implementing and following up on those actions. I see far too many After Action Reports (AARs) that softball incident management shortfalls or don’t go into enough detail to actually identify the problem and root cause. The same can be said for many incident AARs.

When it comes to emergency management, and specifically incident management, we can’t expect to improve without being more direct about what needs to be addressed and committing to corrective actions. We can do better. We MUST do better.

New polling function in WordPress… Let’s give it a try.

©2020 Timothy Riecker, CEDP

Emergency Preparedness Solutions, LLC®

ICS Training Sucks: A Revival

Tim Riecker, The Contrarian Emergency Manager Leave a comment

It’s sad to say that in the past four and a half years of stumping for changes in ICS training, we have seen little progress.  I was recently sent a response org chart developed by an agency that completely tore apart ICS and rebuilt it in a fundamentally different image.  ICS is a standard.  It shouldn’t be changed.  Once you change it, especially at fundamental levels, you no longer have a standard.  It has innate flexibility, but those are applied without changing the fundamentals.  I vented some of my frustration about this last night on Twitter, to a mix of celebration and naysayers, as expected.  Some of those naysayers think the system simply doesn’t work. Others think the system simply can’t accommodate their type of agency.

(note that I’m using the word ‘agency’ here to mean any type of government, non-government, or private sector organization.  I decided to use it since I’m also heavily using the term ‘organization’ in regard to the structure we apply for a response)

So let’s back up a bit.  Why is this happening?  It starts with people having some knowledge of ICS and, with good intentions, wanting to adapt it to their agency and their circumstances.  But there is simply no reason to do any adaptation.  The functions outlined in ICS are all you need in a field-level response.  I’ve heard all the excuses – “We need to make it work for us.”  “FEMA needs to build an ICS for our type of agency.”  “It’s not you, it’s me.” I’ve worked with a lot of stakeholders across a lot of sectors across the whole country, and I have yet to find a field-level response that I can’t organize without violating the fundamentals of ICS.

I’m sure I’ve said this before, but adhering to the standard is important because if we don’t adhere to a standard, we are out of the loop.  If enough people don’t adhere to a standard, it’s no longer a standard.  Either way, the benefits of having a standard are crumpled up and thrown away.

One problem is that a lot of entities, particularly large agencies with multiple components, like to ensure that every function or department within their static structure is represented in an ICS model.  This isn’t what ICS is built for.  If you are seeking specific representation, you can assign agency representatives to the ICP or the EOC, or use a department-based EOC model, but the foundational ICS structure itself isn’t intended to reflect your static organization.  You have an animal control officer.  Do they need to be represented in your pre-planned ICS org chart?  No, they are brought in as a resource if needed, likely in Operations.  You have an IT department.  Do they need to be represented in your pre-planned ICS org chart?  Not as a department. But their capability is identified, likely for assignment within Logistics.  It’s not about recreating ICS to fit your static organization.  It’s about knowing the capabilities of your static organization and applying them within the established ICS structure when and how they are needed. 

Let’s put this out there… ICS isn’t just for you, it’s for everyone.  What I mean is that the greatest benefit of ICS (the prime reason it was actually devised) is for multi-agency operations.  In a local incident of any significance, your agency is likely to be part of a multi-agency response.  Depending on the type of incident, scope, location, and other factors, certain positions will be staffed with personnel selected from the agencies with primary responsibility and, hopefully, with qualified staff.  So that carefully crafted org chart you have developed for your agency’s response is largely irrelevant in a multi-agency operation.  Yes, your agency certainly should have a go-to model for single-agency responses, but consider that a single-agency response probably isn’t going to need a full-blown org chart.

There is a difference, though… and that’s for EOCs, or more specifically departmental emergency operations centers.  These are, by definition, not multi-agency, and established to support your own agency’s needs for deployment, sustainment, internal coordination, and matters that may not be addressed at the field-level.  EOCs have a variety of organizational models available to them, which don’t necessarily need to be ICS.   A problem I often see is agencies trying to accomplish everything in one org chart.  They are trying to fit executive level positions in with field response.  Stop.  Take a breath and figure out what you are trying to accomplish.  It’s OK (and perhaps necessary) for your agency to have two organizational models to accomplish what you need, depending, of course, on your agency’s role, responsibilities, and capabilities.  You may need a field-level organization that addresses a tactical response (this is ICS-based) and an EOC organization that supports that response and the needs of your agency as a whole in regard to the incident (again, lots of options for the EOC organization).  Also consider, depending on your agency, that a policy group may be necessary to guide things.  A policy group is non-operational and they essentially exist to make the broad-reaching decisions on behalf of the organization.

Why are we seeing such extensive mis-applications of ICS?  First, people still don’t understand ICS.  Second, they aren’t truly considering the needs of their agencies.  The irony is that many of the people doing this DO think they understand ICS and that they are making changes to it to better serve the needs of their agencies.  So… we’re still maintaining that ICS Training Sucks.  Do I have a total solution to that problem?  No. But in the articles you find in that link, I certainly have some ideas.  I’ve also found a great many kindred spirits in this whole crusade that agree with the need for change in how we train people in ICS.

What I do know is that the solution isn’t as straight forward as we would like it to be.  Considerations:

First, we are considerably tainted by our knowledge of current and past ICS curricula.  When talking with people about how to fix ICS training, I have to regularly remind myself to push that knowledge aside and look at the problem with fresh eyes.  Lessons learned aside; we can’t move forward when we are still planting ourselves in what is in use now.

Second, we need to consider that there may not be a single solution that fits all needs.  I still think we may need a curriculum structure similar to that used for HazMat training, which addresses the needs of different user groups (i.e. Awareness, Operations, Technician, Planner, Commander).

Third, we need to actually teach people how to apply ICS.  At present, with only a bit of exception, true application of ICS isn’t deliberately instructed until someone takes position-specific and incident management team training.  This in no way meets the needs of most agencies, many of which are volunteer, and have limited availability to go away for several weeks to get the training they need.

Fourth, recognize that if you aren’t using ICS regularly (and I mean at a large scale), your knowledge and skill degrades.  Refresher training should be required and scenario-based learning should be incorporated across the curriculum.

Fifth, stop trying to re-develop ICS.  Trust me, all the needed capabilities of your agency for a field-level response fit within an ICS org chart.  It’s not about your static organization, it’s about capabilities.  Identify and assign capabilities.

I love the continued dialog and attention this topic gets.  The only way we will see positive change is by continuing that dialog.  Please share these blogs and your ideas with colleagues.  Let’s keep spreading this and striving for change.

© 2020 Timothy Riecker, CEPD

Emergency Preparedness Solutions, LLC

~~

In memoriam: I humbly dedicate this post to a friend and colleague who recently lost a battle with cancer.  Phil Politano is known by many for his good nature, his gregarious laugh, and his incredible knowledge as a Public Information Officer.  I’ve known Phil since about 2002, and had worked with him on incidents, taught classes with him, and learned a lot from him.  Phil eventually left Central NY and moved his family a bit south, taking a job with FEMA’s Emergency Management Institute.  There, his talents were applied to their greatest extent.  He reshaped PIO training, spread that gospel to people from all around the world, and supported large scale responses with his knowledge, skills, and abilities.  He was a master in his craft and shared his mastery with anyone who wanted to learn.  He was an incredible practitioner, a great friend, and a wonderful person.  He made us all better simply by knowing him.   He is missed by so many.  Rest well.

 

 

An Updated Community Lifelines Toolkit and Relationships to Incident Management

Tim Riecker, The Contrarian Emergency Manager 4 Comments

Earlier this year, FEMA released guidance on the Community Lifelines.  I wrote a piece in the spring about integrating the concept into our preparedness and response activities.  Last month, FEMA issued updated guidance for Community Lifeline Implementation through Toolkit 2.0.  In this update, FEMA cites some lessons learned in actually applying the Lifeline concept in multiple exercises across the nation, as well as from feedback received by stakeholders. Based on these lessons learned and feedback, they have made some adjustments to their toolkit to reflect how they understand, prioritize, and communicate incident impacts; the structure and format for decision-making support products. And planning for these impacts and stabilization prior to and during incidents.  They have also made some changes based upon the updated National Response Framework.  The documents associated with the updated Community Lifelines all seem to reflect an inclusion in the efforts of the National Response Framework.  It’s great to see FEMA actually tying various efforts together and seeking to provide grounded guidance on application of concepts mentioned in doctrine-level documents.

The biggest addition to the Community Lifelines update is the inclusion of the FEMA Incident Stabilization Guide.  The ‘operational draft’ is intended to serve as a reference to FEMA staff and a resource to state, local, and tribal governments on how “FEMA approaches and conducts response operations”.  It’s a 77-page document the obviously leans heavily into the Community Lifelines as a standard for assessing the impacts to critical infrastructure and progress toward restoration, not only in response, but also into recovery operations.  It even reflects on bolstering Community Lifelines in resilience efforts, and ties in the THIRA and capability analysis efforts that states, UASIs, and other governments conduct.  I’m not sure the document is really a review of how FEMA conducts operations, as they say, but it does review the ideology of a portion of those operations.  Overall, there is some very useful information and references contained in the document, but this brings me to a couple of important thoughts:

  1. The utility of this document, as with the entire Community Lifelines concept, at the state and local level is only realized through integration of these concepts at the state and local levels.
  2. We finally have guidance on what ‘incident stabilization’ really entails.

To address the first item… In my first piece on Community Lifelines, I had already mentioned that if states or communities are interested in adopting the concept of Community Lifelines, that all starts with planning.  An important early step of planning is conducting assessments, and the most pertinent assessment relative to this initiative would be to identify and catalog the lifelines in your community.  From there the assessment furthers to examine their present condition, vulnerabilities, and align standards for determining their operational condition aligned with the Community Lifelines guidelines.  I would also suggest identifying resiliency efforts (hopefully these are already identified in your hazard mitigation plan) which can help prevent damages or limit impacts.  As part of your response and short-term recovery lexicon, procedures should be developed to outline how lifeline assessments will be performed, when, and by who, as well as where that information will be collected during an incident.

As for my second item, the concept of incident stabilization has an interesting intersection with a meeting I was invited to last week.  I was afforded the opportunity to provide input to an ICS curriculum update (not in the US – more on this at a later time), and as part of this we discussed the standard three incident priorities (Life Safety, Incident Stabilization, and Property Conservation).  We identified in our discussions that incident stabilization is incredibly broad and can ultimately mean different things to different communities, even though the fundamental premise of it is to prevent further impacts.  This Incident Stabilization Guide is focused exclusively on that topic.  In our endeavor to make ICS training better, more grounded, less conceptual, and more applicable; there is a great deal of foundational information that could be distilled from this new document for inclusion in ICS training to discuss HOW we actually accomplish incident stabilization instead of making a one-off mention of it.

Going a bit into my continued crusade against the current state of ICS training… I acknowledge that any inclusion of this subject matter in ICS training would still be generally brief, and really more of a framework, as implementation still needs to be grounded in community-level plans, but this document is a great resource.  This also underscores that “learning ICS” isn’t just about taking classes.  It’s about being a professional and studying up on how to be a more effective incident manager.  ICS is simply a tool we use to organize our response… ICS is NOT inclusive of incident management.  Not only are we teaching ICS poorly, we are barely teaching incident management.

While I’ve been away for a while working on some large client projects, I’m looking forward to ending the year with a bang, and getting in a few more posts.  It’s great that in my travels and interactions with colleagues, they regularly mention my articles, which often bring about some great discussion.  I’m always interested in hearing the thoughts of other professionals on these topics.

© 2019 Timothy Riecker, CEDP

Emergency Preparedness Solutions, LLC®

A New Vision for ICS Training

Tim Riecker, The Contrarian Emergency Manager 2 Comments

Yep, I’m still at it.  It seems with every post about the condition of Incident Command System training as we know it, I’m able to draw more people into our cause (aka the Crusade).  While I’ve never espoused there to be an easy solution, the training that we currently provide for ICS falls well short of doing us any favors.  People walk out of each subsequent training course with a marginally increased understanding of the system and how to use it.  And that’s really the fundamental problem, isn’t it?

Perhaps at some point, someone had the idea of developing ICS 100-400 to be knowledge-based courses, with position-specific training to be more about application.  Unfortunately, that’s a significant disservice to responders and the populations they serve, which was further exacerbated by the NIMS training requirements, creating a type of a false sense of security in which people believed that they have ‘been trained in ICS’, therefore all is well in the world.  Responders, in the broadest sense, at supervisory levels within every community should be trained not only in what ICS is but also how to implement it.  Not every community, for a variety of reasons, has reasonable access to position-specific training, so the core ICS curriculum absolutely MUST do a better job in teaching them how to implement the system.

This also goes further than just training.  ICS, like so many other things, is a knowledgebase that tends to degrade over time.  Without practice, you tend to lose the skills.  This is how people who are on Incident Management Teams or those who work regularly in an ICS-based Emergency Operations Center are so well practiced in the system.  In the absence (hopefully!) of actual incidents, planned events and exercises go a long way to keeping skills sharp.  Even those, however, can get costly and time-consuming to design and conduct.  Enter the hybridization of scenario-based training, which is something I’ve written on in the past.  Not only do we need to include more scenario-based training in everything, we need to include a scenario-based ICS skills refresher course as part of the core ICS curriculum.

While I continue to have various thoughts on what there is to be done with the ICS curriculum as a whole, here is my current vision…

ICS-100: (What is ICS?)  Pretty much keep this as is, with options for on-line and classroom delivery.  The purpose of this course is to serve as an introduction to ICS concepts for those who are likely to come into contact with it and work in lower levels within the system.  This is levels one (knowledge) and two (comprehension) of Bloom’s taxonomy.  It shall serve as a prerequisite to further ICS classes as it provides much of the fundamental terminology.

ICS-200: (How do I work within the system?)  Tear down/burn down/nuke the on-line version and never look back.  Simply making it ‘more accessible’ doesn’t mean that it’s good (it’s not).  The purpose of this course is to expand on knowledge and begin to approach functionality.  I expect content to reach deeper than what is currently within the course.  Without looking at specific content areas, I envision this course to be mostly level two (comprehension) of Bloom’s taxonomy with some touches on level three (application).  Perhaps the only level one content that should be introduced in this course are some fundamentals of emergency management.  Some of the content areas currently in the ICS 300 absolutely need to be moved into the ICS 200 to not only make the ICS 200 more impactful, but to also set up the ICS 300 as being fully focused on implementation of the system.  Expanded content may mean taking this course to a duration of up to three days (it even feels taboo writing it!). ICS 100 (taken within six months) is a prerequisite.

ICS-300: (How do I manage the system?) The most recent update of the ICS 300 course begins to approach the vision for what we need, but more work needs to be done.  This course needs to be much less about the system and more about how to IMPLEMENT and MANAGE the system.  This course is firmly rooted in level three (application) of Bloom’s taxonomy, with perhaps some level four objectives, which gets into analysis (troubleshooting and creative solutions… because that’s what emergency management is really all about!).  Much of this course is scenario-based learning centered on implementation and management of an incident through the use of ICS.  Less instruction, more guidance.  And because, at this point, ICS isn’t the only thing at play in real life, concepts of broader incident management are also applied.  ICS 200 is naturally a prerequisite, and should have been taken within a year.

ICS Implementation Refresher Course: This would be designed as a post- ICS 300 course, taken every year or two.  Reasonably, this can be accomplished in a day of intensive scenario-based training.

ICS-400: (A prerequisite for position-specific training).  Eliminate this from the core curriculum.  Seriously.  Most of the current content of this course is not needed in the core ICS curriculum.  Time is better spent in a more intensive ICS 300 course than teaching people about some (largely) obscure applications of ICS which are usually only ever performed by incident management teams.  The current content is largely fine, it just has such little impact on local implementation of ICS and is really rather awkward within the continuity of the curriculum.

Thoughts and feedback are always appreciated.  If we are to succeed and build a better mouse trap, it will be through dialogue and sharing of ideas.

© 2019 – Timothy Riecker, CEDP

Emergency Preparedness Solutions, LLC®

Conduct of the New ICS 300 and 400 Courses

Tim Riecker, The Contrarian Emergency Manager Leave a comment

Last month a colleague and I delivered the new ICS 300 and 400 courses for a client.  If you’ve missed them, I have some early review notes and overall thoughts posted.  Nothing gets you into the curriculum like teaching it, though.

First, some credit to our course participants, who were extremely supportive in this delivery.  They were patient with our occasional need to double check the instructor guide and even helped to point out some inconsistencies.  While we each have about fifteen years of experience in teaching the courses, the first few times out with a new flow and format, along with new activities takes a bit of getting used to.  The courses also offered some challenges that had to be overcome in our course prep and delivery.

Leading off with the good foot, both courses reflect a positive direction of change.  It’s not the wholesale change that I’ve been stumping for, so expect to continue to see me championing more changes, but we are seeing positive movement in the right direction, at least with the ICS 300 course.  (I still hold out that most of the content of the ICS 400 course isn’t necessary for most who take it.  Time would be far better spent with grounding the concepts of ICS and supporting implementation of the aspects that are most likely to be used.)

Both courses continue a trend of scenario-based learning reinforcement, with the ability to utilize a progressive scenario threaded throughout the ICS 300 course and scenarios within the ICS 400 that help demonstrate when and how these concepts might be used.  While the ICS 300 materials provide several new scenarios for use, we actually didn’t use their progressive scenarios as our client had some specific needs, requiring us to build a localized scenario for them.  That said, the scenarios provided in the ICS 300 are easily adaptable to meet your needs.  Just be aware of the intent of each phase of the scenario and don’t alter the overall concept.

The endeavor to ground ICS as an operational tool is emphasized in Unit 4 of the ICS 300, Implementing an Operational Process.  This unit really seems to pull together the whole reason for being for ICS, especially in an extended operation, and is a good introduction to the Planning Process.  This unit was very well designed and is one of the most progressive changes in the course.

Not a lot was substantially changed in the ICS 400.  Aside from my earlier comment on the questionable necessity for most of the content, the course, as designed, is good enough to address what is intended, even if that intent seems misguided.  Much of the course was kept the same as the previous version, but there were a few tweaks and adjustments throughout.  The activity in Unit 2, the Fundamentals Review is multi-tiered and is very effective.  Unit 5 provides a lot of content on EOCs which wasn’t previously included as much, as well as introducing disaster recovery topics, which at this level incident the leadership of organizations (i.e. those taking this course) need to be aware of.  This is largely ‘bonus content’ which I had provided in the course off script in the past, as it wasn’t included.  I’m very happy to see this as part of the course now. The capstone exercise is the same as the previous version of ICS 400 and is still very well structured and produces great outcomes for participants.

On the down side… well, there is some substantial down side. I provided a fairly detailed list (of both positives and areas for improvement) to EMI.  Taking the course at face value – that is looking at what we have, not what I think it should be, most of the issues I had with this course have to do with faulty instructional design.  There is no way around saying that it was done very poorly.  There was significant lack of attention to detail… so many mis-spellings (spell check is a free feature included in every word processing program – FYI), inconsistencies between the Student Manual and Instructor Guide, problems with scenarios which are not part of the progressive scenario, graphics so small they are not visible for participants in the student manual, and some issues of course flow and organization.

Unit 3 in the ICS 300 course is titled Initial Actions for Unified Command.  So much of the unit is built on the premise that a unified command is formed in the initial response of an incident, practically exclusive of even the possibility of a single command.  This is insanely misleading and required some significant extended explanation on the part of our instructional team to temper that content.

Earlier I complemented unit 5 of the ICS 400, particularly for the additional material provided on various types of EOCs and extending the discussion into recovery.  While these are great, the unit should be organized earlier in the material, especially with several earlier references to EOCs without explanation of what they are.  Practically speaking, the concept of the EOC has far more actual use than any of the other concepts discussed in the course.  There is also way too much material on federal-level EOCs, most of which are so far removed from incident management that most emergency managers have no interaction at all with them.  I think this content should speak about EOCs in general terms.

I think Central City needs to be erased from all memory, and a new fictional jurisdiction developed.  The maps for Central City, et al, keep getting recycled and are small in print, confusing in design, and clearly dated.

The final exams for both courses were very bad.  They each had questions that our instructional team agreed to throw out, as they were poorly worded or ambiguous and nearly every participant got them wrong.  Even most of the valid questions and answers simply aren’t suitable for short-duration training, and certainly not with a closed book exam.

In all, I provided three pages of comments back to EMI. I’m appreciative of EMI being so receptive to the feedback and candid about certain issues they had in the development of these courses.  In respecting their candor, I’m not going to get into some of the points brought up, but it certainly appears as though they are disappointed with the condition in which these courses went out the door and they have a desire to improve them.  Hopefully it won’t be too long until you see another update of the course materials with most of these issues addressed.

I look forward to hearing from others about their experiences with delivering these updated courses.  As such a central topic to the greater public safety and emergency management community, we need to do better with teaching incident management and ICS as the primary tool we use for incident management.  As a community of practice, we need to get behind this initiative and support the need for significant improvement.  Of course if you aren’t familiar with my crusade on the matter, check out the series of ICS Training Sucks articles I’ve posted over the past few years.

© 2019 – Timothy Riecker, CEDP

Emergency Preparedness Solutions, LLC®

Teaching ICS – We’re not there yet

Tim Riecker, The Contrarian Emergency Manager 1 Comment

Over the past week I’ve been neck deep in the updated ICS-300 and ICS-400 curriculum as I prepare to deliver these courses for a client.  While these courses, especially the ICS-300, have made some significant improvements from past versions, I’ve found what I perceive to be another challenge, perhaps a gap, in our collective approach to teaching incident management.

While ICS training should obviously focus on ICS, it seems we are missing an opportunity to provide some critical knowledge on emergency management (at least the response functions of EM) and incident management as an overall concept, especially when we get to the level of ICS-300.  I’m betting that most people taking the ICS-300 class know very little about emergency management and even less about the overall concepts of incident management.  While the ICS-300 is a good and worthwhile course for a great many supervisors within the ranks of public safety, it seems the requirement for ICS training puts a lot of this out of context.

While this might be fine for the ‘typical’ tactician, or even most unit leaders operating within an ICS organization, knowledge of what emergency management is and does, as well as the underlying concepts of incident management, will improve the ability of the response organization as a whole to function.  I echo this same sentiment for the EOC courses that have been developed.

While we strive to have the growth of many public safety professionals to include ICS position-specific training, we also have to be realistic in recognizing that most jurisdictions simply don’t have the capacity to make this happen.  Instead, they rely on a more ad-hoc incident management approach, which will generally serve them well.  Of course, the most challenging time is transitioning from the more ‘routine’ type 5 and 4 incidents into the larger extended response operations of a type 3 incident.  This is when people need to think beyond the normal approach of a largely tactics-focused response, to a system which still necessarily includes tactics, but builds a response organization meant to support and sustain those tactical operations.  What they learn from the ICS-300 may be the most amount of training they have outside of tactical applications.

In such an ad-hoc system, someone put into Logistics, or even more specifically the Supply Unit Leader, may be left wondering how to obtain resources when the answer to that question has always been dispatch.  It may not readily dawn on them to open the phone book (digitally or physically) or to contact the emergency management office to find the resources they need.  It seems silly, but in the context of incident management, dispatch may be all they know.  Similarly, someone assigned as the Situation Unit Leader may be re-creating the wheel when it comes to identifying what information is needed, where to get it from, what analysis needs to take place, and how to tie it all together.  Why?  Because they may not have been made aware of the greater system they function within. Their mental default is the job they usually do for the agency or department they work for.

On a whim, I did some key word searches within the new ICS-300 course student manual.  The term ‘incident management’ comes up with a few hits, mostly centered around NIMS-oriented content or included in the broader term of ‘incident management team’.  Very little explanation is really given on what incident management is.  Rather, the term is just put out there, seemingly with the expectation that the student knows what it is.   A search for the term ‘emergency management’ only comes up with two hits, one being part of ‘Emergency Management Assistance Compact (EMAC)’ (note: no context is given for what this is), and the other use is a rather throwaway use when discussing demobilization.  Emergency management as a function is actually never discussed.

The Reader’s Digest version of all this is that we aren’t including critical contextual information about the systems ICS functions within when we teach more advanced ICS courses.  This inadvertently can close people’s minds to opportunities to improve incident management by extending their thinking beyond tactics and beyond the scope of their home agency.  A podiatrist must still learn about the systems of the whole body before they focus on the foot.  Teaching people, especially at the threshold of ICS-300, about the system of emergency management and the concepts of incident management are critical before we start teaching them the specifics of a particular tool.  Doing so will make their understanding and use of this tool far more effective.

Some may wonder if I will ever be happy with how we teach ICS (really, incident management as a whole).  That day may yet come, but to get there I think we first need to reassess the actual learning needs of practitioners, and do so with fresh eyes instead of trying to mark up the same materials.  I know over the years of my criticisms of ICS training I’ve stimulated a lot of discussion, not only nationally, but internationally.  Many have been hugely supportive of the ideas I’ve put forward, and some have contributed to the dialogue.  Of course, there are some who have been resistant and defensive.  I’m thankful to those who have been receptive and I’m happy to have contributed to the energy behind changes that have been made, and will continue to do so until we, as a collective, are satisfied that the best possible training is being made available.  Change is often times progressive and incremental. It doesn’t happen overnight.

As usual, I’m happy to receive any comments and feedback you might have on these ideas.  Please spread the word and encourage feedback from those who might not be aware.  Emergency management is an ever-evolving practice.  Though we may not have answers, we must continue asking questions.

©2019 – Timothy Riecker, CEDP

Emergency Preparedness Solutions, LLC℠®