This is a special issue, while I’ve included a link here, it unfortunately does not provide the full text. This is part on an experiment to bring you analysis of things you may not have otherwise seen, especially when the subject matter is so important and applicable.
In “The United States’ Experience with the Incident Command System: What We Think We Know and What We Need
to Know More About” by Jessica Jensen and William Waugh Jr, they examine how ICS has been working in the US and what seems to influence effectiveness and adoption.
I think this is especially important in software because we are not mandated to adopt a certain incident response methodology or process, so its important that if are going to import one, that we understand where and how it can be effective.
When I work with teams to help them with their incident response process, either for the first time or to improve it, clients are often surprised that I don’t teach them ICS. It is very common for folks, especially those new to or trying to improve incident response, to see ICS as a cure all for many different incident woes. Unfortunately this isn’t the case, both for traditional first responder organizations and for technology orgs.
After reading this I hope you understand a bit about why not. It’s not that I don’t believe it can work, I’ve seen it work and the research says it can too. It’s that for many organizations, they don’t need it and it may not be a good fit.
Origins and Evolution of ICS
The common story of ICS is a fairly linear one, it gets kicked off as part of fighting wildfires in California, gets adopted elsewhere, continually gaining popularity until it becomes part of NIMS as we see it today.
This story, while common, is incomplete.
That story glosses over a lot of the controversy (even prior to 9/11) around whether one system could apply to all firefighting. This took place along multiple lines, but especially in the case of urban vs wildland firefighting.
This story is sort of baby ICS is born, begins to grow, everybody loves them, eventually they come into their powers and become superhero ICS, able to handle all incidents of all types in a single bound! Then it gets adopted as the National Incident Management System. But it didn’t really work like that.
The problem with this story is that its not really true and overlooks a lot of the issues in the development. This isn’t just nice to know history, but helps shed light an why it may or may not work for you or your organization.
Pretty much from the beginning, there was controversy, the core question was “how can one system work for all sorts of different incidents and teams?”.
This question was asked across all sorts of lines. Even among disciplines, like firefighting, there was a concern that a system with its origins in wildland firefighting where incidents tend to be longer with more agencies involved, couldn’t fit an urban department that was on its own almost all the time, where incidents rarely ran longer than a day.
FIRESCOPE
FIRESCOPE or the Firefighting Resources of California Organized for Potential Emergencies started in 1972. Ultimately it produced “Wildfire ICS” winch would later be adopted by the US Coast Guard, Occupational Safety and Health Administration, and the Environmental Protection Agency.
It would later be cited as a key part of the response to the Oklahoma City bombing.
Fire Ground Command System
A Chief out of Phoenix FD, Alan Brunacini, believing that the FIRESCOPE system was mostly for large incidents, made a system for the day to day work of urban firefighting, the Fire Ground Command System in the late 70s and early 80s.
This system has been said to be “less formal and more laid back” than that FIRESCOPE approach. It was designed for shorter and smaller scale incidents.
NFPA standardization
Later, in 1990, the National Fire Protection Association made a standard, “NFPA 1561: Standard on Fire Department Incident Management Systems” that despite the name, did not pick a particular method or approach, but instead defined what an incident command system should have or be.
Merging FIRESCOPE and Fire Ground
The same year that NFPA standardization happens, a consortium is formed (the National Fire Service Incident Management Consortium) to help merge the FIRESCOPE ICS and the Fire Ground Command System.
This was the entire issue though! The question of could you merge them effectively? Could you serve the needs of both urban and wildland firefighting, when urban events tended to be shorter, involving a single agency, with wildland spanning days or weeks or even months potentially with multiple agencies?
What about the divide between smaller rural, often volunteer departments and a large, urban department?
At the time, even the police had complaints about this! They said there is a mismatch between the “top-down command structure” and the amount of autonomy that officers have in the field.
So not only do we have these intra-domain or discipline mismatches and concerns but now we have broad ones, like the needs of police vs fire departments.
Eventually, even the, Emergency Management Accreditation Program, who sets standards for various emergency management programs, doesn’t really weigh in either, giving ICS and NIMS as examples of systems, but doesn’t mandate or really recommend one.
Assumptions about ICS
Now that we know some of the real history and problems along the way, we can begin to judge whether or not those will be problems for us and are in a better place to examine some of the assumptions about ICS along with the authors.
There are a number of common assumptions about ICS. Some of them are:
- Everyone uses ICS.
- Everyone uses ICS the same way.
- Using ICS is a way to fix a number of common problems on-scene.
Most of these aren’t true. While is true that ICS works, we can’t really say it doesn’t, especially considering its wide use. It clearly works to some degree.
The first one is pretty easy, despite it being the national standard not everyone uses ICS and for us in software it doesn’t really matter what the national standard is.
While 2 seems like it’d be true, part of the point of a standard after all, as we’ve begun to see, not everyone uses it the same way and based on the FEMA Director’s warning and the concerns throughout ICS history, not everyone should use it the same way.
We’ll dive into 3 a bit more in the next section, but for now I’ll just say that adopting an incident management framework on its own is unlikely to fix anything. Using an incident management framework to guide you during incidents and shape how you train and practice however, can help a lot.
What makes ICS work?
So if this is all sounding a bit negative, you’re probably asking yourself the question “How does ICS work then? What makes it work?”
The short answer here is people. As I’ve covered before, people fill gaps and adapt and are sources of resilience. This is no less true in ICS or any other framework.
- ICS “seems to work best” when the participants are full-time, paid employees in traditional first responder jobs like EMS, fire, or police.
Individuals with this background tend to have clearly defined and accepted response-related value systems wherein the goals of response and task priorities associated with ICS are more likely to be understood and shared by others.
This does not match the way most software organizations work in my experience. Of course we don’t expect that say SRE teams are going to have traditional first responder jobs. But the shared goals of response and task priorities often are not shared either.
- It also is “critical that all participating individuals accept, or buy-into, use of the system”
If people don’t believe in it or don’t use, its unlikely to be effective.
Some research shows that in order to be effective some exposure to the system is needed. This makes sense, but as the authors correctly point out, “exposure” is a really vague notion.
Further research tells us that responders need to understand ICS and ideally have training and experience (even if just in exercises) in order for the system to be effective.
None of this seems especially unique to ICS. Of course for any system, the more people believe in it, understand it, and have experience with it, the more effective it is likely to be. Also, if someone uses it as part of their full time job where they effectively paid to use it and the system matches their goals it’ll also be more effective.
For an organization to be effective with ICS, not just individuals (though organizations are collections of individuals), the entire organization must accept ICS, not just management.
I think most of have seen what happens when directives come from management that aren’t compatible or don’t have the support of the rest of the organization, it just doesn’t really work.
When training does take place, it needs to “be culturally appropriate for the system to be accepted in a meaningful way.”
The research indicates that having pre-existing relationships between leaders prior to the incident helps effectiveness as well.
This is unsurprising as a an incident response plan or framework cannot on its own create trust.
Its also important that everyone (or at least as many people as possible) have an understanding of the state of the incident and that they are able to share and update that understanding when things change. This hinges in part on being able to share information quickly amongst the responders.
Decision making and expertise
As I’ve said elsewhere, a large part of effective incident management is ensuring that decision making power is located near expertise, the authors make a similar point here:
When the system works best, leaders delegate tasks effectively, allow individuals within the system to make operational decisions based on their technical expertise, and allow individuals within the system to improvise solutions to new problems as they are encountered
The need to reset
Part of the point of ICS is the idea that you can grow it up to what you need, but an often overlooked corollary is that you must shrink it what you need as well.
This means monitoring how the different structures are work and fitting (or not) in a response and adjusting, including possibly “resetting” the system if the structure needs large changes.
That’s not to say that this monitoring is easy, especially in complex, fast moving incidents.
Adapting ICS
You may have had the experience of working in a system or framework that used ICS very strictly “by the book”. I’ve seen this be fairly common at organizations the are trying to get a handle on incidents.
Often the thought seems to be that they’ll somehow “solve” incidents by adopting the system. This is similar (and often a version of) the idea that if they just try harder the problem will go away. This can manifest as “if only they keep to the system more exactly,” then the problem will go away.
The funny thing about all this, is that not only does that not work, but its actually the opposite that helps. Instead of rigidly sticking to the system as written, it needs to be adapted to the organization, in multiple ways, at multiple levels.
In a public service response organization, this would present a trade-off. How much do you change versus the other organizations you’ll have work with. But fortunately, this is rarely if ever a concern for us in technology.
This means we have more room to adapt. This adaptation has to take place in not just fitting the system itself, but also in how its taught, trained, and practiced.
This is a huge part of why I don’t teach ICS to clients. Sure, I may use some of the ideas (just as ICS itself did it during its development), but I don’t teach or recommend it directly.
You might think this adaptation gets away from the system purpose, which is sometimes understood as “if everyone uses the exact same system everywhere, then we can work together,” but even the previous head of FEMA warned of “ICS zealots”.
The authors even cite further research that shows that ICS is less useful if an organization sticks strictly to standard operating procedure and works better when “resource use and response tactics” are improvised when the situation calls for it.
Adoption of a method isn’t enough, adaptation must happen as well.
Takeaways:
- A lot of assumptions about ICS are wrong, including that everyone in an incident will be using it the same way or that it will solve certain response problems.
- While ICS is often seen, and even treated as a very rigid structure, implementing it that way is unlikely to be effective.
- The oft told story of ICS’ history being linear and steadily gaining popularity until the wide spread adoption we see today, is largely not true and gloss over concerns about it being a good fit for different types of response.
- Many factors influence the effectiveness of ICS including:
- Previous experience with ICS
- Individual level of buy-in
- Organizational acceptance of the system
- Culturally appropriate training
- Simply saying “we do ICS now,” with minimal training or practice is unlikely to effective.
- Command-and-control arrangements of any sort are unlike to be effective.
- ICS (or any other incident response framework) needs to be adapted to fit the organization.
- Effective use of ICS requires that structures be created, but also removed when they no longer fit the shape or pace of the incident.
Subscribe to Resilience Roundup
Subscribe to the newsletter.