Have I got a treat for you! Gary Oldham, an expert in many things response-related, including ICS, who has been doing work in this field for almost as long as I’ve been alive has contributed a comment to our ongoing discussion on the role of public information in the ICS structure. See below for the full post:
Let me start out with some full disclosure. I was pretty heavily involved in the fairly early days of ICS’s evolution as part of Project FIRESCOPE in California. I’ve served in a lot of ICS roles, including that of PIO (and initially when I filled that role – long, long ago – it was called FIO, for Fire Information Officer. And back then, Operations was called “Suppression and Rescue.” This was back before we recognized the “all-hazards” value of ICS.) Because of that, perhaps, I tend to be protective, perhaps over-protective of ICS.
The ideas presented here merit a lot of thought and sole searching. I tend to initially reject out of hand ideas that involve major overhauling of ICS. The beauty of ICS is its scalability and indeed its all-hazards nature and applicability. But we need to be open to the idea that we may need to do some revamping at some point.
I’m not sure this is it, though. I continue to believe the fundamentals, the underpinnings, of ICS are as solid today as they were in 1980. We’re better at using it than we were then. But we need to do some things differently, and information dissemination is certainly one of those. I’m a big proponent of social media in emergency management and public safety, and SM can certainly be a tool in the Information Officer’s toolkit within ICS. If there are things that impede information flow and release, they need to be fixed. Systemically if that’s where the problem resides, or on an individual incident or incident commander basis where appropriately. If IC approval is unduly slowing information release, then that incident needs some standing orders about how/when/and by whom information is going to be released so that routine releases don’t need specific IC approval. If there’s a trust issue there between the IC and PIO, that needs rectifying – through some candid dialog, through some accelerated approval processes that let each person get a feel for the others abilities and sensibilities, and a mutual effort. Items that are more sensitive – names of injured or killed, for but one example – may need specific approval, and working protocols can easily allow for that. None of these things require that ICS change; its framework certainly allows for protocols like these to be quickly implemented.
I watched the Deepwater Horizon debacle often in agony at how ICS had been bastardized and then criticized for its inadequacies. ICS was fine. NIMS added some useful things – like the Multi-Agency Coordination Center function, which is tremendous when done properly (as it was back in the 80s and 90s in California, where hard resource allocation decisions were made quickly, judiciously, and fairly by involved stakeholders). The Joint Information is another NIMS aspect that can be a good thing – or not, when done improperly. But the real bastardization of ICS came from the “oil spill version” that gives the violator, the causal agent, the “responsible party” (in law enforcement, we usually called them “the suspect”) a seat at the command table. In my mind, that’s where the Deepwater Horizon management effort reached the “success is impossible” threshhold. You can’t have parties with diametrically opposed agendas and goals sitting at the table with equal authority and reach a result that satisfies both parties. We really don’t need, in my mind, “versions” of ICS for oil spills, hospitals, schools, etc. ICS lets an incident or an organization fill roles as needed for their particular situation; it doesn’t require a separate “version.” And in no case, should “responsible parties” OR “suspects” get an equal say in how an incident is managed, OR how/what information is disseminated.
I think the closing sentence in this essay really hits the crux of the issues: “I see certain enlightened ICs perceiving as using it as tool (i.e. radio, shovel, dosimeter, etc.) , versus an independent function.” I completely agree – and I believe “enlightened” is the operative word. An enlightened IC working with a savvy PIO doesn’t need ICS’ framework to be altered, he or she just needs to recognize that ICS is a tool, too, and it is a flexible tool that allows these goals to be achieved within its existing framework. I don’t think ICS needs modernization – I think many of US do.
Thanks for this thought-provoking essay, and for the opportunity to weigh in on it.
Truly thought-provoking. Thanks so much for your contribution, Gary.