BY ALAN BRUNACINI
I have been actively involved in some way for most of my life in the process and practice of incident command. I began my career during the initial development of the incident command system (ICS) in our service. I became an early student of the concept that we could create a better system to more effectively command and control tactical operations. Once I got started, I never stopped. I have continued being involved in command system design, development, and refinement since the very beginning. I have done it for so long that now it would be difficult to stop, so I guess I will just keep going until I keel over.
An enormously happy part of my lifelong incident command project has been watching my two firefighter sons (Nick and John) converting the antiquated paper-and-pencil Fire Ground Command material I have developed through the years into a modern online Blue Card electronic training form. I may have influenced them a little (genetics?) on the command stuff, but they had to be struck with some computer lightning, because while I am still completely electronically illiterate, they have somehow become expert media development specialists.
They are both experienced inner-city firefighter “cool heads” who talk plain, simple (very effective) street firefighter talk and skillfully translate that experience (and language) into a snazzy electronic form. It has been my great joy to get to hang out with them since they were small, little B Shift toddlers.
Fire officers of my generation had the interesting and exciting task of learning and applying new command system routines while we unlearned old practices and habits. After I became a chief officer boss, it seemed that a major part of my job was to review and refine how firefighters applied effective and safe command procedures on the fireground.
Injuring and killing responders always has been and still is the most heartbreaking and persistent problem we face. Our service continues to be challenged by routine tactical conditions (i.e., repeat/recurring conditions—not special or unusual) injuring and murdering our firefighters.
A major role of the incident commander (IC) is to protect the firefighters. A lapse in that responsibility is consistently a factor in virtually every such hazard zone injury/death case. We will not be finished with incident management system design and application as long as local incident hazards continue to outperform the ability of the ICS to protect our troops. Protecting firefighters working in the hazard zone has been and will always be a major role of the IC—simply, we can’t effectively save Mrs. Smith while we are desperately trying to save ourselves.
For the past several months of “Unplugged,” we discussed a simple, basic performance management model. That model became the template we used to manage all the initial and ongoing command system pieces and parts; in fact, we mostly chased our tail and really didn’t have much of a positive effect until we learned how to use the model.
The model provides a very practical performance management game plan that includes all the related steps [standard operating procedures (SOPs)/training/application/critique/revision] required to create effective command performance. What the model does not do is indicate what the operational area is that we can (or should) plug into the model. Simply, the model tells us how to manage whatever we put in and then run through the “boxes.”
In the beginning of developing the command system, we quickly discovered that a huge part of the command process involved the personal performance of the IC, particularly in the very beginning of fireground operations. This understanding caused incident command to be the first area we ran through the model, and it has stayed in the model for the past 35 years. Writing ICS SOPs for me seems to be an eternal (lifelong) work in progress.
The IC serves as the conductor of a firefighting “band” where all the “musicians” arrive at high rates of speed; at different times; in vehicles with sirens, red lights, and air horns—and they all want to be the first to play. It is very difficult to get them all to “make music” together if the IC does not show up first and coordinate everyone’s starting to play their part of the same song at the right time.
A major challenge in that period of early command system development was that there was no effective, refined, well-known IC job description then, so we had to develop a simple, basic description of how we wanted the IC to perform when starting at the very beginning of operations. After that, we had to somehow get the IC to do what was in the job description.
In the beginning, when we told initially arriving troops we wanted them to perform as ICs, they really did not know what an IC was supposed to do, so they (logically) asked, “Okay, when I am serving as an IC, what do you want me to do?” This is a very legitimate question for a worker to ask the boss, and the boss should be able to answer it. We had to develop the basic command functions that formed the IC’s job description to answer that timeless (what do you want us to do?) question. We instructed our troops in the concept that being a local IC involves doing the following eight standard command functions. The functions form an understandable, doable answer to their question.
Simply, when you are serving as the IC, do the following:
1. Assume, confirm, and position command.
2. Evaluate the situation.
3. Initiate, continue, and control communications.
4. Manage the deployment process.
5. Create an effective incident organization.
6. Establish/maintain an overall operational strategy and incident action plan (IAP).
7. Review, evaluate, and revise the strategy and IAP as needed.
8. Transfer, support, and terminate command.
We quickly learned that the command and operational action we took at the very beginning of the incident (first five minutes) determined how the whole event would turn out (next five hours). If we made mistakes, were out of position, or skipped necessary steps, it would create a disadvantage we many times could not outperform for the rest of the incident time. A major element in starting out under control, maintaining control, and not losing control was having an effective IC who started performing the command functions from the onset of our arrival.
A basic reality (sledgehammer blow to the cranium) was that we could not initiate the incident command and control process until and unless someone assumed the basic role of the IC and began to do the standard command functions. Part of the lesson was that good beginnings produced good endings. Unfortunately, we learned the opposite was just as true.
Retired Chief ALAN BRUNACINI is a fire service author and speaker. He and his sons own the fire service Web site bshifter.com.
