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