Even since before the National Incident Management System (NIMS), I’ve seen individuals and organizations have a desire to customize the Incident Command System (ICS). This has always been troubling to me, as customization is fully contradictory to using a standardized system.
ICS offers an abundance of flexibility. If you are familiar enough with the system, its foundational features, and the intent of the roles and responsibilities within the system, you can meet practically every need utilizing these functions and features. Is ICS perfect? No. Is it the best we have? Yep, it sure is. Having many years as a practitioner, trainer, and evaluator of ICS, I’m confident that it can meet 95% of needs that an organization will have.
Generally, I find the argument that many organizations who insist on customization put forward is that the rigidity of ICS does not accommodate their needs, structure, and culture. On the occasion that I’ve had to sit down with the organization’s personnel and ask questions about what they are trying to accomplish, it becomes quite clear that they simply don’t have a good understanding of ICS. Some can be fairly obvious, such as moving the Safety Officer position to Operations. Others require a bit more analysis, such as creating an element in the Operations Section to address security needs of their own facility. Security of your own facility is actually a responsibility of the Facilities Unit within Logistics, not an Operations responsibility.
Foundationally, let’s consider the main purpose of ICS – interagency coordination. ICS is a standardized system which supports integration, cooperation, and unity of effort between and among multiple organizations. One of the main reasons I see organizations struggling to fit elements into an ICS organization chart is because some simply don’t belong there. If you have functions internal to your own agency, even if they are used during emergency operations, but don’t interact with others, I honestly couldn’t care if you organize them within ICS, so long as they are accounted for within your own organization’s own chain of command. There is no doctrine or best practice that requires organizations to account for every internal function within an ICS org chart.
The other reason, which I eluded to earlier, for organizations trying to customize ICS for their purposes, is a lack of understanding of ICS. While I’m aware that some people who have done this might only have taken ICS 100, giving them only a scratched surface of ICS knowledge, which they easily misapply since they don’t have a good understanding of the fundamental concepts of ICS. However, I’m aware of plenty of individuals who have taken ICS 300 and possibly ICS 400 who still fall into this trap. I feel this situation stems from a result of misapplied learning, which ultimately comes from poor ICS curriculum. (If you want to read more on my opinions on how ICS Training Sucks ⇐visit here).
ICS training should not only provide learning to support operational implementation of ICS concepts, but also adequate preparedness activities, such as integrating ICS into plans, policy, and procedures. Current training leaves many people feeling they know enough about ICS to integrate it into these important documents, but they feel compelled to be creative, when not only is creativity generally not required, it flies in the face of a standardized system. ICS has an abundance of flexibility which can accommodate a multitude of functions; one just has to relate these to the fundamental features of ICS to identify where they might go. I’m not opposed to creating a new organizational element, just make sure that it fits appropriately, without duplicating efforts, usurping responsibility from another standard element, or violating span of control.
Consider this: will your organization chart integrate with others? If so, how? Is there operational integration or is it through an agency representative? If the answer is the latter, there is less concern, but if there is an expectation for operational integration or shared functions, such as Planning or Logistics, sticking to the standards is even more important.
I’m interested to hear your thoughts on ICS customization, the reasons behind it, and the ramifications of it. Fire away!
© 2017 – Timothy Riecker, CEDP
The Contrarian Emergency Manager 
Tim:
Would it be worth exploring if we took another look at the functional set up of an EOC. We understand that the EOC is primarily supportive in nature and centers its tasks on coordination, collaboration information sharing, etc. These are all good elements that should remain in place. However, EOCs are also operational entities at times, and actually do manage operations such as general population and special needs sheltering, evacuations, Points of Distribution, Feeding Centers, etc. Should we consider possibly creating and management structure that identifies both the supportive as well as the operational role that EOCs can play. acknowledging that the EOC can be both a support entity as well and an operational one as well. I am a believer in the ICS and would argue that it needs to be the foundation for the new structure. However, I am also aware that when we use the Planning P, the 215 and 215a, that there is a difference between identifying needs to support agencies such as Fire. EMS, Law Enforcement, Public Works and the needs of those functions that are being run out of the EOC. is it time to add another branch to the general staff for the EOC? Just a thought…Thanks for allowing me to share and please keep up your excellent work.
Hi Michael. Sorry for the delayed response. Yes, I think it’s always worth taking another look at something so critical. I totally agree that an EOC can serve both those functions, and for as good as an adapted ICS structure is, maybe we are missing something. I think practitioners need to recognize what the purpose is of every activity and apply the tools we have available where appropriate and in an appropriate manner. Let’s continue thinking on this one…