Why ICS standardization matters and what baby carrots can show us.

• Disclaimer

  This post was shared from our sister site: ready2respond.ca

To think standardization brought us these.

What do a carrot farmer and ICS have in common? Well, more than you think. You see, back in the late 70s, carrot sales weren't doing so well. Nobody wanted ugly carrots, so much so that the entire industry was suffering. But then came along Mike Yurosek, a carrot farmer who put his sole focus into solving this very problem.

And how did he do that? Well, he invented the baby carrot. Using a green bean machine, Yurosek cut the ugly carrots into uniform 2-inch pieces. By doing this, he was able to create smooth, snack-sized pieces that everyone had come to love and expect. He had found a way to take what were once ugly carrots and standardize them.

And it's that expectation consumers have grown accustomed to. Purchasing a bag of baby carrots anywhere, you are met with the same size and shape of carrot. And why do you love it? Because Yurosek was able to take a free-form carrot and standardize it.

Similarly to the baby carrot is the Incident Command System, or ICS, as it's known. A standardized system that was developed back in the 70s. Developed as a result of a number of different organizations responding to a large-scale wildfire where things went horribly wrong. Clearly there was a problem that needed to be solved. One whereby different organizations could come together to work. That's exactly the focus of a task force set up to solve this problem. The result was the creation of ICS. A system of standardization to be used by all.

What does standardization have to do with emergency response?

Originally ICS was used only for responding to wildfires. Why? Because wildfire had a habit of crossing jurisdictional boundaries and impacting large areas of the public. As a result, its response required involvement from a number of agencies across various municipalities.

Up until that wildfire incident that started it all back in the 70s, most emergency response agencies were able to manage their own "situations." Structural firefighters did their thing, and sometimes they would require assistance from police and EMS. The same was true of police and EMS. Everyone had their lane, their specialization, and when they did interact on an incident, it was somewhat contained and short-lived.

Why is this important?

As incidents started to get larger and larger, resource requirements were needed to cover larger areas and for longer durations. These aspects, along with others, meant that the traditional police, fire, and EMS services were not ideally suited to take on this work.

ICS became this "force multiplier," if you will. Through the standardization of the response, it meant that resources could move about freely from other jurisdictions and agencies and come together under one roof to help with a response.

More importantly, a guiding structure was put in place, meaning that no matter who was heading up the response, the same values and focus were applied equally wherever you were in the country, and now the world.

So, how do we know we've achieved standardization?

That's a complicated one. We know that we have "the system" that everyone uses and is trained on. However, we also know that within this system, sometimes latitude is taken in the approach and implementation of the internal processes that have been developed.

While all attempts have been made to standardize as much of the system as we can, we know through any number of After Action Reports that our use of ICS is still not at 100%. And whether it could be said to be at 60% or 40% or less, that's hard to say.

The whole thing is so restrictive.

Is it? Or is it the fact that we try to stay working within our own system? Relying on the processes and protocols we know well, as opposed to fully adopting ICS.

If that's the case, then yes, ICS would seem restrictive. Not only that, but it's also unfamiliar. Which is more likely the case, whereby unfamiliarity begets restrictiveness?

Let's look at an example, shall we?

There's an incident your organization is responding to. Initially it looks like something that can be dealt with within the next few hours. Great. You have all the processes needed to respond and support that are internal to your organization.

Then things take a turn.

Now the incident is expanding, and more resources are needed from other places. One of two things occurs at this point: a) you scramble to include these resources into your internal "system," thinking the incident won't last much longer, or b) you scramble to move everything over to ICS to be able to integrate with the external resources.

Either way, there's a struggle going on. From using internal systems you know well to shifting to ICS systems you may be less familiar with. This is just one possibility of how existing between the two worlds may make the less familiar one feel restrictive.

So to summarize what we've covered so far:

Throughout the article we discussed the importance of standardization in emergency response. How having a system like ICS can help different organizations come together. One whereby everyone is on the same page and working towards the same outcome.

We also discussed why having a system is important. But also briefly acknowledging the challenges that come with that. How we often straddle two worlds—internal process vs. ICS—and the interaction between the two can make using ICS feel restrictive. Restrictive, or more so, unfamiliar, which is a common thing we often hear.

Ah, if only things were really as simple as a green bean machine and some ugly carrots. ICS was supposed to be that answer. Of taking something ugly and unsellable, like the carrots, and processing it into this beautiful system of response. How incredible would that be?

While we're not fully there yet, we know that we can be.