Sometimes You Have to Bend the Rules for ICS

If you’ve been reading this blog regularly, you know that we love the Incident Command System. OK, love is too strong a word. Let’s just say we really, really believe in it.

The principles and structure of ICS provide an effective roadmap to manage incidents. Following the ICS process is invaluable when you have to coordinate with outside agencies that are accustomed to its application. The use of common terminology, ensuring a manageable span of control, and having a structure that ensures that all important aspects of the response efforts are covered – this is all good stuff. The benefits of ICS are enough to persuade any emergency preparedness operation to adopt the System.

But we have to admit, in certain cases, it’s all a bit much. Following ICS to the letter can defeat the spirit of the process.  For instance, when you already have one or more emergency response plans and tools that follow most, but not every last detail of ICS principles, why worry? Trying to force fit what works for you into such a universal structure can be a recipe for confusion and frustration.

A complex system that works is invariably found to have evolved from a simple system that worked.

– Gall’s Law #15

  For instance, in extreme cases we’ve seen organizations:

• Rename their current company functions to match titles that don’t make sense for them.
• Use forms that weren’t designed for their business.
• Attempt to use processes that are cumbersome and time-consuming while providing marginal benefit for the actual work at hand.

Think about the ICS-201 form (also known as the Incident Briefing form). You are supposed to:

1. Produce a sketch of the incident;
2. Provide a summary of current objectives and actions;
3. Identify the structure of the current organization;
4. Provide a summary of resources either on-scene or en-route.

Utility companies that use an Outage Management System or Resource / Work Management System would have that information at their fingertips and would not need to use a separate form. They already know:

1. The general location of the incident, as they probably have a link to their GIS or mapping system;
2. That the number one priority is to make the situation safe, and the actions that follow are according to well established procedure;
3. Who is already on site and/or who has been dispatched to the location.
4. The “Incident Commander” might have a pretty good idea what the problem is, and the resources needed to do the job.

All this is information that would go into an ICS-201, but there is no point taking the time to fill out a separate form to needlessly document it or determine a course of action. When you have dozens of storms and hazards creating hundreds of mini-incidents each year, you develop the most efficient systems you can in order to cope with them.

Le Chatelier’s Principle: Complex systems tend to oppose their own proper function. As systems grow in complexity, they tend to oppose their stated function.

– Gall’s Law #6

Of course this is an oversimplified example of an everyday occurrence. This all becomes much more complicated in major, wide spread incidents. But is it really so different? Do we need to overcomplicate things by using forms and processes that aren’t specific to our organization and the way we do things?

So what’s the bottom line? Maybe we need to think twice and use common sense in our application of tools and processes that were originally developed for use in the public sector.  Use the parts of the ICS that make sense to you. Focus on the purpose of the forms and the processes, and see if you already have something within your organization that already fits.  And stop trying to fit a square peg into a round hole – it can be a painful process!

If a plan is simple and efficient, bureaucracy will find a way to make it complex and wonderful.

– Markwell’s Corollary