ICS: Problems and Perceptions

Oddly enough, I’ve recently seen a spate of LinkedIn posts espousing the benefits of the Incident Command System (ICS). Those who have been reading my material for a while know that I’m a big proponent of ICS, though I am highly critical of the sub-par curriculum that we have been using for decades to teach ICS. The outcome is an often poorly understood and implemented system resulting in limited effectiveness.

Yes, ICS is a great tool, if implemented properly. Yet most implementations I see aren’t properly conducted. To further muddy these waters, I see emergency plans everywhere that commit our responders and officials to using ICS – this is, after all, part of the National Incident Management System (NIMS) requirement that many have – yet they don’t use it.

So why isn’t ICS being used properly or even at all? Let’s start with plans. Plans get written and put up on a proverbial shelf – physical or digital. They are often not shared with the stakeholders who should have access to them. Even less frequently are personnel trained in their actual roles as identified and defined in plans. Some of those roles are within the scope of ICS while some are not. The bottom line is that many personnel, at best, are only vaguely familiar with what they should be doing in accordance with plans. So, when an incident occurs, most people don’t think to reference the plan, and they flop around like a fish out of water trying to figure out what to do. They make things up. Sure, they often try their best, assessing what’s going on and finding gaps to fill, but without a structured system in place and in the absence (or lack of referencing) of the guidance that a quality plan should offer, efficiency and effectiveness are severely decreased, and some gaps aren’t even recognized or anticipated.

Next, let’s talk about ICS training. Again, those who have been reading my work for a while have at least some familiarity with my criticism of ICS training. To be blunt, it sucks. Not only does the content of courses not even align with course objectives, the curriculum overall doesn’t teach us enough of HOW to actually use ICS. My opinion: We need to burn the current curriculum to the ground and start over. Course updates aren’t enough. Full rewrites, a complete reimagining of the curriculum and what we want to accomplish with it, needs to take place.

Bad curriculum aside… For some reason people think that ICS training will solve all their problems. Why? One reason I believe is that we’ve oversold it. Part of that is most certainly due to NIMS requirements. Not that I think the requirements, conceptually, are a bad thing, but I think they cause people to think that if it’s the standard that we are all required to learn, it MUST be THE thing that we need to successfully manage the incident. I see people proudly boasting that they’ve completed ICS300 or ICS400. OK, that’s great… but what can you actually do with that? You’ve learned about the system, but not so much of how to actually use it. Further, beyond the truth that ICS training sucks, it’s also not enough to manage an incident. ICS is a tool of incident management. It’s just one component of incident management, NOT the entirety of incident management. Yes, we need to teach people how to use ICS, but we also need to teach the other aspects of incident management.

We also don’t use ICS enough. ICS is a contingency system. It’s not something we generally use every day, at least to a reasonably full extent. Even our first responders only use elements of ICS on a regular basis. While I don’t expect everyone to be well practiced in the nuances and specific applications of ICS, we still need more practice at using more of the system. It’s not the smaller incidents where our failure to properly implement ICS is the concern – it’s the larger incidents. It’s easy to be given a scenario and to draw out on paper what the ICS org chart should look like to manage the scenario. It’s a completely different thing to have the confidence and ego in check to make the call for additional resources – not the tactical ones – but for people to serve across a number of ICS positions. Responders tend to have a lot of reluctance to do so. Add to that the fact that most jurisdictions simply don’t have personnel even remotely qualified to serve in most of those positions. So not only are we lacking the experience in using ICS on larger incidents, we also don’t have experience ‘ramping up’ the organization for a large response. An increase in exercises, of course, is the easy answer, but exercises require time, money, and effort to implement.

One last thing I’ll mention on this topic is about perspective. One of the posts I read recently on LinkedIn espoused all the things that ICS did. While I understand the intent of their statements, the truth is that ICS does nothing. ICS is nothing more than a system on paper. It takes people to implement it. ICS doesn’t do things; PEOPLE do these things. The use of ICS to provide structure and processes to the chaos, if properly done, can reap benefits. I think that statements claiming all the things that ICS can do for us, without inserting the critical human factor into the statement, lends to the myth of ICS being our savior. It’s not. It must be implemented – properly – by people to even stand a chance.

Bottom line: we’re not there yet when it comes to incident management, including ICS. I dare say too many people are treating it as a hobby, not a profession. We have a standard, now let’s train people on it PROPERLY and practice it regularly.

©2024 Timothy Riecker, CEDP

Emergency Preparedness Solutions, LLC®

AHIMTA Incident Management Certification

I was very pleased to see last week’s announcement by the All-Hazards Incident Management Team Association (AHIMTA) about their certification services for incident management personnel. From their website, AHIMTA is utilizing the National Incident Management System (NIMS) and the National Qualification System (NQS) as the baseline for their AHIMTA Incident Management Certification System (AIMCS). Information, including trainee application information can be found at https://www.ahimta.org/certification. In many ways, the AIMCS is a continuation of the Interstate Incident Management Qualifications System (IIMQS) Guide that AHMITA developed in 2012.

AHIMTA is providing a much-needed service, filling a vacuum that has always existed in the all-hazards incident management team (IMT) program in the US. While FEMA is responsible for maintaining the NQS, they have not actually provided certification or qualification of IMTs or IMT personnel. Last year it was decided that the US Fire Administration would discontinue their management of the AHIMT program. While the USFA didn’t provide any certification services, the program guidance they provided was valuable. They were also the primary federal agency doing anything with external AHIMTs. While some states have implemented the FEMA NQS standard for IMTs and associated positions, others have not. Even among the states that have, some have only done so, officially, for state-sponsored teams/personnel and not for those affiliated with local governments or other entities. Clearly gaps exist that must be filled. AHIMTA has continued to advocate for quality AHIMTs and personnel across the nation.

AHIMTA’s role as a third-party certification provider presents an interesting use case. While not unique, a third party providing a qualification certification (not a training certificate) based on a federal standard is not necessarily common. AHIMTA doesn’t have any explicit authority to provide this certification from FEMA or others, but as a respected organization in the AHIMT area of practice, I don’t think their qualifications to do so can be denied. Certification demands a certain rigor and even assumes liability. The documentation of the processes associated with their certification are well documented in their AIMCS Guide. While AHIMTA can’t require their certification, states and other jurisdictions may very well adopt it as the standard by which they will operate, and can make it a requirement for their jurisdiction. Aside from some very specific certifications that have existed, such as those for wildfire incident management personnel, much of AHIMT practices has been self-certification, which can vary in quality and rigor. The AIMCS program can provide consistency as well as relieve the pressure from states and other jurisdictions in forming and managing their own qualification systems. There will also be an expected level of consistency and excellence that comes from AHIMTA.

All that said, I continue to have reservations about membership organizations offering professional certifications. While membership organizations arguably have some of the greatest interest in the advancement of their profession and adherence to standards, as well as the pool of knowledge within their practice, the potential for membership influencing the process or injecting bias against non-members can never fully be eliminated. I feel that certifications should be provided by government agencies or fully independent organizations that are not beholden to a membership. Not wishing to stall AHIMTA’s progress or success in this program, I’m hopeful they may be willing to create a separate organization solely for the purposes of certification credentialing. I’d also love to see, be it offered in conjunction with this program or otherwise, an EOC qualification certification program, ideally centered upon FEMA’s EOC Skillsets, but with qualification endorsements for various EOC organizational models, such as the Incident Support Model.

I’m very interested to see the progress to be made by the AIMCS and how states and other jurisdictions adopt it as their standard. This certification should have significant impact on the continued development of quality all-hazard incident management teams.

What are your thoughts on this certification program?

© 2023 Timothy Riecker, CEDP

Emergency Preparedness Solutions, LLC®

Federal Coordination of All-Hazard Incident Management Teams

A few months ago the FEMA administration decided that the US Fire Administration (USFA) would discontinue their management of the All-Hazards Incident Management Team (AHIMT) program, which they have developed and managed for years. While I was never in favor of the USFA managing the program (AHIMTs are not fire-service specific), the staff assigned to the program did an admirable job of growing the AHIMT concept to what we have today.

The All-Hazards Incident Management Team Association (AHIMTA), which has been a vocal proponent of the development of AHIMTs, has thankfully been working to make people aware of this change. As part of their advocacy, they also wrote to FEMA Administrator Deanne Criswell regarding their concerns with the dissolution of this formal program. Administrator Criswell responded to AHIMTA, indicating that despite successes, the AHIMT program has “not been able to establish a sustainable or robust AHIMT program with long-term viability.” She did indicate that the USFA will continue providing related training to state, local, tribal, and territorial (SLTT) partners (though she specified that USFA training efforts will apply to fire and EMS agencies) and that she has directed the USFA to collaborate with the FEMA Field Operations Directorate to continue support to AHIMTs.

This change and some of the wording in the Administrator’s response is obviously very concerning for the future of AHIMTs. I first question the Administrator’s statement about the AHIMT program not being sustainable long-term. Not that I’m doubting her, but I’m curious as to what measures of sustainability she is referring. I’m guessing most of the issue is that of funding, along with this never having fully been part of the USFA’s mission. Everything really does boil down to funding, but how much funding can a small program office really need? I’m also concerned about the USFA continuing with the AHIMT training mission (as I always have been), and even more so with the Administrator’s specification of fire and EMS (only?) being supported. While I have no issue at all with the USFA, and think they have done a great job with IMT and related training, their primary focus on fire and EMS (even absent the Administrator’s statement) can be a barrier (real or perceived) to other disciplines obtaining or even being aware of the training.

I firmly believe that a federal-level program office to continue managing, promoting, and administering a national AHIMT program is necessary. I do not think it should be in the USFA, however, as it has been, as their mission is not comprehensive in nature. It’s a program that should be managed properly within FEMA, though not by the FEMA Field Operations Directorate, which is primarily charged with FEMA’s own field operations. While this does include FEMA’s own IMATs, their focus is internal and with a very different purpose. My biggest inclination is for the program to be placed within the NIMS Integration Center, which already does a great deal of work that intersects with AHIMTs. On the training side of things, I’d like to see AHIMT training moved to FEMA’s Emergency Management Institute (EMI), to emphasize the inclusion of SLTT participants regardless of discipline. Incident management, as a comprehensive response function, is inclusive of all hazards and all disciplines and practices, just like emergency management.

The dissolution of the AHIMT program at the federal level makes no sense to me at all. The absence of a program office not only degrades the importance of incident management teams, but of incident management as a concept and a skillset – which I think also needs some vision beyond the current IMT model to support local incident management capabilities. I’m appreciative of the AHIMTA and their advocacy for a federal AHIMT program office, and I’m hopeful that they will be able to convince FEMA of this need and that a program office is properly restored.

© 2022 Timothy Riecker, CEDP

Emergency Preparedness Solutions, LLC®

Incident Management is a Technical Skill

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®

EOCs and IMTs

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®

An Update of Ontario’s Incident Management System

Just yesterday, the Canadian province of Ontario released an update of its Incident Management System (IMS) document. I gave it a read and have some observations, which I’ve provided below. I will say that it is frustrating that there is no Canadian national model for incident management, rather the provinces determine their own. Having a number of friends and colleagues from across Canada, they have long espoused this frustration as well. That said, this document warrants an examination.

The document cites the Elliot Lake Inquiry from 2014 as a prompt for several of the changes in their system from the previous iteration of their IMS document. One statement from the Inquiry recommended changes to ‘put in place strategies that will increase the acceptance and actual use of the Incident Management System – including simplifying language’. Oddly enough, this document doesn’t seem to overtly identify any strategies to increase acceptance or use; in fact there is scant mention of preparedness activities to support the IMS or incident management as a whole. I think they missed the mark with this, but I will say the recommendation from the Inquiry absolutely falls in line with what we see in the US regarding acceptance and use.

The authors reinforce that ICS is part of their IMS (similar to ICS being a component of NIMS) and that their ICS model is compatible with ICS Canada and the US NIMS. I’ll note that there are some differences (many of which are identified below) that impact that compatibility, though don’t outright break it. They also indicate that this document isn’t complete and that they already identified future additions to the document including site-specific roles and responsibilities, EOC roles and responsibilities, and guidance on resource management. In regard to the roles and responsibilities, there is virtually no content in this document on organizations below the Section Chief level, other than general descriptions of priority activity. I’m not sure why they held off of including this information, especially since the ICS-specific info is reasonably universal.

I greatly appreciate some statements they make on the application of Unified Command, saying that it should only be used when single command cannot be established. They give some clarifying points within the document with some specific considerations, but make the statement that “Single command is generally the preferred form of incident management except in rare circumstances where unified command is more effective” and reinforce that regular assessment of Unified Command should be performed if implemented. It’s quite a refreshing perspective opposed to what we so often see in the US which practically espouses that Unified Command should be the go-to option. Unified Command is hard, folks. It adds a lot of complexity to incident management. While it can solve some problems, it can also create some.

There are several observations I have on ICS-related organizational matters:

  • They use the term EOC Director. Those who have been reading my stuff for a while know that I’m really averse to this term as facilities have managers. They also suggest that the term EOC Command could be used (this might even be worse than EOC Director!).
  • While they generally stick with the term Incident Commander, they do address a nuance where Incident Manager might be appropriate (they use ‘manager’ here but not for EOCs??). While I’m not sure that I’m sold on the title, they suggest that incidents such as a public health emergency that is wide-reaching and with no fixed site is actually managed and not commanded. So in this example, the person in charge from the Health Department would be the Incident Manager. It’s an interesting nuance that I think warrants more discussion.
  • The document refers several times to the IC developing strategies and tactics. While they certain may have input to this, strategies and tactics are typically reserved for the Operations Section.
  • There is an interesting mention in the document that no organization has tactical command authority over any other organization’s personnel or assets unless such authority is transferred. This is a really nuanced statement. When an organization responds to an incident and acknowledges that the IC is from another organization, the new organization’s resources are taking tactical direction from the IC. Perhaps this is the implied transfer of authority? This statement needs a lot of clarification.
  • Their system formally creates the position of Scribe to support the Incident Commander, while the EOC Director may have a Scribe as well as an Executive Assistant. All in all, I’m OK with this. Especially in an EOC, it’s a reflection of reality – especially the Executive Assistant – which is not granted the authority of a Deputy, but is more than a Scribe. I often see this position filled by a Chief of Staff.
  • The EOC Command Staff (? – they don’t make a distinction for what this group is called in an EOC) includes a Legal Advisor. This is another realistic inclusion.
  • They provide an option for an EOC to be managed under Unified Command. While the concept is maybe OK, ‘command’ is the wrong term to use here.
  • The title of Emergency Information Officer is used, which I don’t have any particular issue with. What’s notable here is that while the EIO is a member of the Command Staff (usually), the document suggests that if the EIO is to have any staff, particularly for a Joint Information Center, that they are moved to the General Staff and placed in charge of a new section named the Public Information Management Section. (a frustration here that they are calling the position the EIO, but the section is named Public Information). Regardless of what it’s called or if there is or is not a JIC, I don’t see a reason to move this function to the General Staff.
  • Aside from the notes above, they offer three organizational models for EOCs, similar to those identified in NIMS
  • More than once, the document tasks the Operations Section only with managing current operations with no mention of their key role in the planning process to develop tactics for the next operational period.
  • They suggest other functions being included in the organization, such as Social Services, COOP, Intelligence, Investigations, and Scientific/Technical. It’s an interesting call out whereas they don’t specify how these functions would be included. I note this because they refer to Operations, Planning, Logistics, and Finance/Admin as functions (which is fine) but then also calling these activities ‘functions’ leads me to think they intend for new sections to be created for these. Yes, NIMS has evolved to make allowances for some flexibility in the organization of Intel and Investigations, something like Social Services (for victims) is clearly a function of Operations. While I appreciate their mention of COOP, COOP is generally a very department-centric function. While a continuity plan could certainly be activated while the broader impacts of the incident are being managed, COOP is really a separate line of effort, which should certainly be coordinated with the incident management structure, but I’m not sure it should be part of it – though I’m open to discussion on this one.
  • I GREATLY appreciate their suggestion of EOC personnel being involved in planning meetings of incident responders (ICP). This is a practice that can pay significant dividends. What’s interesting is that this is a measure of detail the document goes into, yet is very vague or lacking detail in other areas.

The document has some considerable content using some different terminology in regard to incidents and incident complexity. First off, they introduce a classification of incidents, using the following terminology:

  • Small
  • Large
  • Major
  • Local, Provincial, and National Emergencies

Among these, Major incidents and Local/Provincial/National Emergencies can be classified as ‘Complex Incidents’. What’s a complex incident? They define that as an incident that involves many factors which cannot be easily analyzed or understood; they may be prolonged, large scale, and/or involve multiple jurisdictions. While I understand that perhaps they wanted to simplify the language associated with Incident Types, but even with the very brief descriptions the document provided on each classification, these are very vague. Then laying the term of ‘complex incident’ over the top of this, it’s considerably confusing.

**Edit – I realized that the differentiator between small incident and large incident is the number of responding organizations. They define a small incident as a single organization response, and a large incident as a multi agency response. So the ‘typical’ two car motor vehicle accident that occurs in communities everywhere, requiring fire, EMS, law enforcement, and tow is a LARGE INCIDENT????? Stop!

Another note on complex incidents… the document states that complex incidents involving multiple response organizations, common objectives will usually be high level, such as ‘save lives’ or ‘preserve property’, with each response organization developing their own objectives, strategies, and tactics.  I can’t buy into this. Life safety and property preservation are priorities, not objectives. And allowing individual organizations to develop their own objectives, strategies, and tactics pretty much breaks the incident management organization and any unity of effort that could possibly exist. You are either part of the response organization or you are not.

Speaking of objectives, the document provides a list of ‘common response objectives’ such as ‘save lives’ and ‘treat the sick and injured’. These are not good objectives by any measure (in fact they can’t be measured) and should not be included in the document as they only serve as very poor examples.

So in the end there was a lot in this document that is consistent with incident management practices, along with some good additions, some things that warrant further consideration, and some things which I strongly recommend against. There are certainly some things in here that I’d like to see recognized as best practices and adopted into NIMS. I recognize the bias I have coming from the NIMS world, and I tried to be fair in my assessment of Ontario’s model, examining it for what it is and on its own merit. Of course anyone who has been reading my posts for a while knows that I’m just as critical of NIMS and related documents out of the US, so please understand that my (hopefully) constructive comments are not intended to create an international incident. I’m a big fan of hockey and poutine – please don’t take those away from me!

I’m always interested in the perspectives of others. And certainly if you were part of the group that developed this document, I’d love to hear about some of your discussions and how you reached certain conclusions, as well as what you envision for the continued evolution for the Provincial IMS.

© 2021 Timothy Riecker, CEDP

Emergency Preparedness Solutions, LLC®

Building Local Incident Management Capability

Just over a year ago I wrote An Alternate Concept of Incident Management Support, identifying the gap that exists in most local communities and areas for improved incident management capability. While I still think that formal Incident Management Teams (IMTs) are the gold standard, not every community or even multi-county region can support a formal IMT, which requires dozens of personnel and rigorous qualification and maintenance. Over the past year, we’ve seen a lot of use of IMTs across the nation, supporting the COVID-19 response and myriad other incidents. Sitting in over the last few days on the All Hazard Incident Management Team Association (AHIMTA) virtual symposium, there is a lot of exciting evolution happening with IMTs as they continue to enhance their capabilities. And while this is great, I feel we are leaving a lot of areas behind. This isn’t on the AHIMTA, but rather on the emergency management community as a whole. That said, there are certainly some intersections, as a lot of the training available to IMT personnel may need to be made more accessible to those who would be part of the Incident Support Quick Response Teams (ISQRTs) as I came to call them in the article I mentioned from last year, and addressing a fundamental need I’ve been espousing for a long time.

As I’ve soaked in a lot of great information from the AHIMTA symposium about IMTs, the need to build local capability in the absence of IMTs is even more apparent. Some may argue that IMTs are available to deploy to any area if requested. Possibly. Obviously there are a lot of conditions… what are other teams dealing with? What’s the relative priority of the requesting area? EMAC is certainly an option, but States need to approve the local request if they are to put the request into the EMAC system. The state may not agree with the need, may not want to spend the funds for an incoming team for an incident that may not receive a federal declaration, or it may not be practical to wait a couple of days to get an IMT on the ground when the response phase of the incident may be resolved or near resolved by then.   

Fundamentally, every area should have its own organic incident management capability. As mentioned, most areas simply can’t support or sustain the rigors of a formal IMT, but they can support a short roster of people who are interested, able, and capable. This is a situation where a little help can go a long way in making a difference in a local response for a more complex Type 4 incident or the onset of a Type 3 incident – or simply to do what they can for a larger incident where additional help simply isn’t available. I mentioned in last year’s article that the focus should really be on incident planning support, with an Incident Management Advisor to support the IC and local elected officials, an Incident Planning Specialist to help the local response organization harness the Planning Process, a Planning Assistant to support the detailed activities involved in a Planning Section such as situational awareness and resource tracking, and an Operations and Logistics Planner to support local responders who may have great tactical knowledge, but not much experience on operational planning much less forecasting logistical needs associated with this. Largely these are all advisors, who are likely to integrate into the incident management organization, so we aren’t creating new ICS positions, though I still encourage some deeper and deliberate application of incident management advisors.

My big thought today is how do we make something like this happen? First, I think we need to sell FEMA and State IMT programs and or State Training Officers on the concept. That comes first from recognizing and agreeing on the gap that exists and that we must support the organic incident management capability of local jurisdictions with fewer resources, through something that is more than the ICS courses, but less than what is required for an IMT. Part of this is also the recognition that these ISQRTs are not IMTs and not intended to be IMTs but fill an important role in addressing this gap. This will go a long way toward getting this past ICS and IMT purists who might feel threatened by this or for some reason disagree with the premise.

Next is establishing standards, which first is defined by general expectations of activity for each of these roles, pre-requisites for credentialing, then training support. The existing position-specific training is likely not fully appropriate for these positions, but a lot can be drawn upon from the existing courses, especially those for Incident Commander and the Planning Section positions, but there are also some valuable pieces of information that would come from Operations Section and Logistics Section Courses. I’d suggest that we work toward a curriculum to address these specific ISQRT roles. There are then some administrative details to be developed in terms of local formation, protocols for notification and activation, etc. State recognition is important, but perhaps approval isn’t necessarily needed, though coordination and support from States may be critical to the success of ISQRTs, again considering that these are most likely to be serving areas with fewer resources. ISQRTs will also need to work with local emergency managers and local responders to gain support, to be included in local preparedness activities, and to be called upon when they should be. A lot of success can be gained from things such as local/county/regional/state meetings of fire chiefs and police chiefs.

Do you agree with the gap that exists for most communities? What do you think we need to get the ball rolling on such a concept?

© 2021 Timothy Riecker, CEDP

Emergency Preparedness Solutions, LLC®

Experience Bias

I recently read an interesting piece in Psychology Today by Dr. Christopher Dwyer titled ‘How Experience Can Hinder Critical Thinking’. Do check it out. There is application to pretty much everything, but of course I tend to think of things in the context of emergency management.

The article starts with the age long argument of education vs experience, but with a particular slant toward critical thinking. My personal take is that the education vs experience argument, in its totality, can’t have a blanket resolution. I think a lot of it is dependent on the topic at hand, and obviously it’s rarely a dichotomy, rather a blending of education and experience is often best. In regard to education, certainly the actual education received holds value, but there are tasks intrinsic to academia which also hold value, perhaps even more than what was learned in the classroom; the rigors of research in an academic environment often being most valuable among them. With that, in many regards, we often see employment announcements with a range of degree majors, or just simply a stated minimum of education, regardless of major. This is in recognition of the intrinsic value of education. And while some professions absolutely require a specific degree, those which don’t, can and should hold less rigidly to those requirements.

While I certainly advocate a minimum extent of education for most positions, I’ve also worked with a considerable number of people with a high school diploma or associate’s degree that can intellectually run circles around those with advanced degrees, at least in certain applications of work and life. Experience is often indicative of exposure to certain situations, often with repetition. The comparing and contrasting of those experiences with what is being experienced in the moment is what supports the argument for the value of experience. It’s also why many advanced degree programs actually require some term of actual work experience before they will accept applicants into their programs. Consider academic programs such as criminal justice. Sure, there are a lot of philosophical topics that are taught, but any courses that speak to practical application should probably be taught by those with actual experience doing those things. Though Dr. Dwyer gives wise advice, stating that we shouldn’t confuse experience with expertise.

All that said, Dr. Dwyer’s article focuses on the application of critical thinking in this argument. He cites some insightful data and studies, but most interesting to me is his mention of experience being personalized. While several people may have ‘been there, done that, got the t-shirt’, they each may have experienced the event differently or left with different impressions, even if exposed to some of the same situations. We all bring a bias with us, and this bias in the lens through which we view the events of our lives. That bias is then influenced by our perception of each event, fundamentally snowballing and compounding with the more experiences we have. This shows how our experiences can bias our own critical thinking skills. Dr. Dwyer states that critical thinking stemming from someone with more education than experience is likely to be more objective and based on knowledge, which certainly makes sense. That said, individuals basing their critical thinking solely on education may miss insight provided experiences, which can provide considerable context to the thought exercise.

I think the conclusion to be drawn in all this is that critical thinking, in most regards, is optimized by those with a blend of education and experience. It’s also extremely important for us to recognize our own limitations and biases when we approach a decision or other relevant situation. Specific to emergency management, we can leverage a lot from our experiences, but we also know that no two incidents are the same. Therefore, while our experiences can support us in a new event, they can also derail us if not applied thoughtfully and in recognition of our own biases.

This all comes around to my advocacy for emergency management broadly, and incident management in particular, being team sports. Even the first step of the CPG 101 planning process is to form a planning team. We each bring different approaches and perspectives. We also need to advocate for diversity in our teams, regardless of what tasks those teams are charged with. This should be diversity in the broadest sense – diversity of experience, diversity of discipline, diversity in education, diversity in gender, diversity in race, creed, culture, etc. The broader the better. We must do better opening ourselves to the perspectives of others. We all have bias – every one of us. Some bias, obviously depending on the focus, is OK, but it is best for us to balance our individual bias with those of a diverse group. A diverse team approach will bring us better results time and again.

How does experience bias impact you?

© 2021 Timothy Riecker, CEDP

Emergency Preparedness Solutions, LLC®

A Re-Framing of Incident Management Structures

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®