Ever since the dawn of civilization, man has been confronted with the certainty that, at some unpredictable time and place, some sort of unexpected catastrophic event will overtake him. Once this certainty was conceptualized the next step was to consider what action was to be taken if ... thus emergency planning was born.
A contingency plan is like a skeleton: to be a functional organism it must be equipped with muscle, skin, organ systems and a network of nerves. Otherwise it is just a pile of bones that
hang uselessly in a dark closet. To be functional, there must be meat on the bones. The "meat" on the bones of any emergency contingency plan must consist of at least ten essential elements:
-- Definition of objective: What sort of emergency are we planning for? Severe weather? Fire? Flood? Process failure? Power outage? Transportation emergency? Terrorism or industrial
sabotage? We need to define it and plan for as many different scenarios as possible.-- Evaluation: What will be the likely consequences of an incident of this type? What would be the "worst case" scenario?
-- Determination of required resources: What will we need to deal with this situation? Are these resources available? If so, where are they located? If not, what shall we do to obtain them?
Who is responsible for obtaining additional supplies and resources?
-- Staffing: Who will be in charge of the response effort? Where will these people assemble? Will there be someone tasked in advance to start up the fire water pumps or activate the standby
-- Communications: How will the alarm be propagated and who is responsible for doing it? Will the notification be confined to the plant proper or will nearby communities need to be alerted?
Will it be necessary to evacuate nearby residents? How will this be accomplished and by whom?
-- Off site assistance: Who will be responsible for notifying mutual aid groups and, if needed, civilian fire departments, medical facilities and local law enforcement? Who will conduct an
evacuation if one becomes necessary?
-- Financial responsibility: Will there be someone with the authority to write checks or issue purchase orders immediately for urgently required materials such as foam concentrate and
where will these materials be obtained?
-- Liaison with local government: in the event that an evacuation is called for, who is responsible for notifying local authorities and securing their cooperation?
-- Record keeping: Who is responsible for keeping a log of events as well as the financial obligations incurred while responding to the incident? The log especially is most important
as it will document the actions of the company, the government and third parties when, months, or even years, after the event, litigation occurs, as it will almost certainly do.
-- Safety: Who will be responsible for the safety of the responders and for implementing the protocols for emergency medical treatment?
There may be more elements than these but this list covers the salient points.
In actuality, a complete Emergency Response Protocol (ERP) will consist of a master plan and a number of incident specific sub-plans. Thus the XYZ facility will have a master emergency
plan that will outline the chain of command, set out the basics of the plant's response organization and protocols. A series of subplans will account for fire, severe weather, power outage, off-site transportation incident or other scenarios. When an incident occurs, the master plan will be activated along with appropriate sub-plan(s).
These sub-plans will be facility specific; for example the severe weather sub-plan for a plant located in northern Michigan would likely pertain to a winter storm. They will also be product or
process specific. The response protocol appropriate for chlorine, for example, will be vastly different from one designed for gasoline or sulfuric acid. The best place to find the proper "fit" for a plan is within the group that will have to ultimately activate and deploy in the event of an incident. In the case of manufacturers, who would be expected to know more about a product and the ways to safely handle it than the people who actually make it?
To be functional, an ERP must be constantly updated. There is a saying among emergency planners that any plan will be out of date ten minutes after the last page comes out of the copier. In a large organization, this is not entirely fallacious. People change positions, employees come and go, e-mail addresses, telephone numbers and radio call-signs change frequently, and in a very large installation, such changes may occur on a daily basis.
No ERP, no matter how elaborate, has ever saved a life or prevented an injury or averted a single incidence of property damage. Plans do not protect anything; they only empower people to do so. A plan is nothing more or less than a theoretical framework for organizing response capabilities and resources a specific problem.
To be effective, any plan must be known to those who are affected by it and these parties must take ownership in the plan. Far too many ERP's are created, bound in blue leather with gold
lettering and promptly filed away in some remote archive to be forgotten.
Any job description that involves participation in an emergency response protocol, either in the private sector or within government, should have this participation spelled out in detail and it should be one of the first things that a newly hired employee receives as part of his initial orientation; the new-hire should know exactly what would be expected of him/her in the
event of an emergency. As soon as the new employee comes aboard the ERP should be updated to show his/her new position, name, contact number(s) and his responsibility within the
emergency response organization.
To facilitate this, particularly in a large plant site, it is quite convenient to have the ERP on a computer attached to a Local Area Network (LAN). Changes, additions or deletions can be made from a central location (the personnel office, for instance, or the emergency response manager's headquarters) and show up on all computers within the network. An alternate method is to have a notice sent out by e-mail and occasionally to have the whole plan reviewed and re-distributed on computer disks. Such notices and disks should carry some sort of receipt to acknowledge that they have actually been received by those for whom they were intended -- thus ensuring that those persons can be held accountable for the information contained in the notices.
Whatever method is employed the ERP must be kept current. Nothing can "throw a wrench in the works" quicker than to place an urgent call to the fire chief only to hear that, "he retired last week," "He is on vacation" or "That telephone number has been changed." Anything and everything that happens in and around a facility affects the ERP; if the fuel delivery truck is down for repairs, the fire chief needs to know it now, not when he is pumping full bore at a four-alarm barn burner and his fuel gauges are approaching "empty."
ERPs and ERP Updates are like fire bells; they do nothing if there is nobody around to heed them and to act accordingly. Those affected by an ERP must understand its purpose and their part in it.
Those involved or affected by an ERP must understand that an emergency is just that, an emergency, and "business as usual" goes out the window. Administrators, be they local government, or corporate, must be familiar with the ERP and instruct their employees that when "the big bell rings" they are authorized to immediately do whatever is necessary or requested. We can sort out the details and address the finger-pointing later.
It has often been said that frequently activated ERPs are the most effective. People in Tornado
Alley know very well what it means when the sirens start sounding so they act accordingly. They know the emergency is real; it is not a game or a drill that can be ignored. Indeed, ignoring
an alarm as "just a drill" has been the means by which an incident has escalated into a full blown disaster on more than one occasion. People who experience emergencies understand the need for preparedness.
The obvious way to foster understanding and appreciation for the importance of ERP is to have frequent drills, simulations and exercises. Most of these will involve only a segment of the
entire emergency response community. Announced drills involve the entire emergency response organization simulations. These are, or at least should be, about as close to the "real thing" as it
is possible to get without causing undue interruption of normal activities.
The best possible scenario for simulations is one for which the probability is high in the particular venue. Such simulations should occur on an unannounced basis just as real emergencies do. The alarm should be sounded and the ERP actuated. The objective here is to see what actually happens when the bell rings. Do the people know what to do and will they do it without hesitation? In order to determine this, the simulation should be scheduled with as few people actually aware of it as possible. It should not be scheduled to occur at the most opportune or
convenient time; real emergencies never do. Is the boss out of town or the fire chief at a seminar? Fine, let us see how our back up plan works. If we need to make adjustments or modifications,
now is the time to find out about it. Is it raining or snowing? We can see how well our response team functions in adverse weather.
Finally, do not neglect the assessment phase of the simulation. There will be errors and miscalculations to be sure. Determining what these are is the reason for running the simulation in the first place. The critique session(s) should be thorough, perhaps held the day after the simulation when everyone has had a chance for rest. It should be all inclusive and not be rushed.