1.4.11 Lack of Common Terminology
Often, response agencies had developed their own terminology, jargon, or vernaculars over a given time. This resulted with words being used that often related to acronyms or the use of words not commonly found in the dictionary. The use of this vernacular, specific term, or acronym not only led to confusion, but in some cases, the term used by one agency would mean the exact opposite to another agency. This would sometimes lead to misinterpretations and miscalculations of how to proceed. In some instances, those undertaking tactics in the operational theater were put in harm's way because of the lack of clear and concise communications.
Another example in regard to common terminology is that some police agencies would use 10 codes, while others would use 11 codes. In one state, they may use alphanumeric codes to describe the reported crime, while in other states, they may use acronyms. If out of state resources were needed, it could be a major fiasco trying to talk to one another unless they all used plain English.
1.4.12 A Lack of Interoperable Communications
Communications incompatibilities were extremely evident. Even when refined and technologically advanced communications systems were in use for more than one agency, they were often mismatched with mutual aid organizations. Interoperability was often nonexistent. This lack of interoperability could be for a multitude of reasons including being on different frequencies, or in some instances, they were on different bandwidths (e.g. low band, UHF, VHF, ultrahigh band). When this occurred, there were no interoperable or interagency communications.
Agencies often purchased communications equipment and secured frequencies that fit their needs. These agencies rarely had any consideration for agencies that might come to their rescue. While there were a multitude of reasons for this, it is important to note that in some instances, agencies had used the same frequencies for years. In some cases, it was tradition over progress. Another factor that may have fed into the lack of consideration for other agencies is that it typically took a long time for the Federal Communications Commission to approve new frequencies, and many agencies did not want to wait. Additionally, radio equipment was expensive and to revamp an entire radio system would come with a large price tag. In all, the problem occurred because the systems that differing agencies used were technologically incompatible.
While operating at an incident, the agency might be able to literally see the other agency, but they did not have the capacity to (verbally) speak to each other over a communications device. The distance might only be a few hundred yards, but it might as well have been a couple of hundred miles. Lack of interoperability between communication devices was a major problem then, and it still is now.
1.4.13 A Lack of Logistics
Logistics is a critical issue that was often overlooked. It was common to see that as an incident expanded, so would the demand for additional resources. As large‐scale or multifaceted incidents became more involved, more resources were needed to support operations. Unfortunately, the logistics to obtain the resources required to mitigate the incident were sometimes overlooked. Prior to the implementation of IMS methods, it was commonplace to commit all resources to operations. When all resources were committed to the operations, it often led to shortages in the availability of resources in the operating theater.
Postincident critiques, now commonly referred to as After‐Action Reports (AARs), would regularly identify that a specific resource was needed but was not requested because it was thought it was inaccessible. In the AAR, they would find that the resource needed was not only available but that it was involved in the theater of operations, but operating in a different capacity (or not being utilized at all). The agency that had a need for that resource unnecessarily operated without it due to a lack of communication and collaboration, and a lack of logistical support.
Due to the lack of tracking and logistical planning, the needed resources were either not identified, or they were not ordered. This often led to more potential for injury and/or death as personnel attempted to adapt by using the resources they had on hand, rather what they really needed.
1.5 California's Solution
During the 1960s and 1970s, California was a state that regularly required multiagency responses, and these responses were (usually) substantially larger in scope than anywhere else in the United States. With large areas of underbrush, towering trees, vegetation covered hills, and dry winds, the fire load in the wildland areas of California was exorbitant. Following the wildfires, there were often torrential rains that often‐caused mudslides on the bare hillsides that was stripped of vegetation by a fire. Beyond the major disaster of wildland fires, California would suffer the occasional earthquake and other disasters that affected that geographical region.
Whenever a major incident occurred, a multiagency response was needed. In these multiagency responses, many were seeing the same complications that seemed to plague other multiagency responses. The State of California began to investigate how to mitigate the negative effects of multiagency responses by promoting the positives and mitigating the negatives. California's answer to these, and other problems, was an experimental project named “Firefighting Resources of California Organized for Potential Emergencies.” The project used the acronym FIRESCOPE.
The FIRESCOPE project began designing a basic standard for all personnel and response agencies. The idea was to help lessen the problems that were ongoing and apparent whenever it was required to manage these major emergency incidents. Those working on the FIRESCOPE project felt they had to come up with a way to better organize response efforts. Recommendations were made that addressed each issue individually. They then combined the mitigation measures for each individual problem and created an all‐encompassing system that addressed all these issues.
After working out all the issues, and coming up with a basic design, they committed to undertaking a comprehensive field test of this new management system. When most people think of a field test, they often imagine a one‐time test on a single day, but this was not the case with FIRESCOPE. The FIRESCOPE field test lasted multiple years. Each time a problem was identified, adjustments were made to the overall system so that it could become finely honed. This extensive field testing of the FIRESCOPE management system led to an extremely robust method of managing emergencies.
FIRESCOPE was the initial concept that, over a period of time, developed into the common procedure that we now know as Incident Command System (ICS). The information provided in this book is essentially just the tip of the iceberg, and those studying incident management would be wise to further their knowledge about FIRESCOPE. For a more complete historical review of FIRESCOPE and the transformation into ICS, you can visit www.firescope.org.
1.6 Creating the Incident Command System
Because the FIRESCOPE program began to show an amazing amount of promise in managing emergency incidents, it began to gain ground in various parts of the nation. Soon, an interagency task force of local, state, and federal agencies used the basic principles of FIRESCOPE and developed the Incident Command System (ICS). This creation of ICS was based on the FIRESCOPE structure and while not exact, it closely mimicked it. FIRESCOPE's success provided the platform for the ICS structure, and the ICS program was developed and is still widely in use in the United States today.
While the initial development of FIRESCOPE started in 1973, one year after the America Burning Report, it is important to realize that it took seven years of research and development to remedy complications found during the extensive field testing. Although a broad range of field testing was employed, it was realized that ICS would need to change as the