Hendon Publishing - Article Archive Details
Technology—it really takes “extraordinary” public safety people to make it work
Technology continues to advance and improve the way we work and live today. For example, just yesterday we were tied to our desks receiving e-mails, and now we can receive them on our wireless phones from any location. Technology continues to be a tool of innovation, providing us with great advancements in the field of computers, communications and networks. In many cases, especially in the business world, to maintain the status quo is to perish and to innovate is to succeed. Public safety information technology is no stranger to innovation—we now have digital radio, communication gateways, mobile data, biometrics and many new technologies at our disposal. With the continuous advancements in technology, many leaders today tend to look to technology to solve their problems; however, we must be careful not to think that technology alone is the answer.
So, if technology alone is not the answer, what else must we consider? The answer is human involvement. American writer and philosopher Elbert Hubbard wrote in the Roycroft Dictionary and Book of Epigrams (published in 1923) that “One machine can do the work of 50 ordinary men. No machine can do the work of one extraordinary man.” We have experienced that the purposeful application of human involvement is a critical factor in the implementation of new communications and interoperability technology projects and leads more directly to their success. There are many technologies that can support sufficient public safety communications and interoperability; however, none of them can work effectively unless the necessary elements are in place to operationalize these systems. This article will explore some of the non-technical human elements that take the efforts of many “extraordinary” public safety people to make technology work.
Governance—human involvement at its finest
Governance is not a means to control but should be a means to provide for sufficient stakeholder involvement, so the technology meets the requirements of the users. With today’s grant programs, a great deal of money has been provided to fund new or upgraded communication and interoperability projects. Governance was initially set up to support the implementation of these projects by having technical liaisons as the project steering body, and user involvement was seen more as an advisory role (see Figure 1). This governance structure can support the implementation of the technology but does little to support the need to operationalize the system for the end user community. It does not benefit the end user to have a technically advanced system installed if no one knows how or when to use it in an emergency.
In order for the project and systems to succeed, the stakeholders need to be able to make a successful transition from technically driven governance to user-based governance (see Figure 2). This transition moves from the discussion about project system design and implementation to one about user agreements, SOPs, exercises, etc. The end user community becomes the lead in the steering body, and the technology should support their needs to operationalize the system.
This governance transition leads us away from the implementation of technology and toward the direction of human factors involved in making the technology operational. Too many projects have failed to adequately involve stakeholders at all levels and at all times throughout the project, thus negatively affecting the project’s chance for success. Stakeholder input is as critical in the design stage as it is in the operational stage of the project—“as many stakeholders as practical and as often as possible” is a good thought to keep in mind as you deal with stakeholders.
Being “Operational” can be defined as the project stage at which you take the technical system from installation to a live state. The many human elements involved at this stage are the subject matter of books, so this article will cover only the high-level understanding of three key areas and provide links to resources for further edification:
• Memorandum of Understanding (MOU) – An agreement of cooperation among organizations defining the roles and responsibilities of each organization in relation to the other or others with respect to an issue over which the organizations have concurrent jurisdiction. (Law Enforcement Tech Guide for Communications Interoperability: A Guide for Interagency Communi-cations Projects, Washington, DC: U.S. Department of Justice, Office of Community Oriented Policing Services, 2006)
• Standard Operating Proce-dures (SOP) – A standard operating procedure consists of a set of instructions having the force of a directive and covering those features of operations that lend themselves to a definite or standardized procedure without loss of effectiveness. (From Wikipedia, the free encyclopedia – www.wikipedia.org)
• Exercises – Exercises assess and validate the speed, effectiveness and efficiency of capabilities, and test the adequacy of policies, plans, procedures and protocols in a risk-free environment. (Federal Emergency Management Associa-tion (FEMA) Web site - http:// www.fema.gov/prepared/exercise.shtm)
Memorandum of Understanding (MOU)—The Players Agree
Public safety response and coordination is now requiring more involved multi-agency, multi-jurisdictional support, and with this comes a need to ensure that the multiple stakeholders involved are on the same page. The development of an MOU among agencies helps establish the rules of engagement as they relate to a particular issue. As technology is implemented, there are many occasions where an MOU is beneficial, such as:
• Shared Radio System – multiple agencies operating on the same system;
• Interoperability Assets – multiple agencies involved in the deployment of gateways, shared channels, interoperability mutual aid frequencies, etc.;
• Data Sharing Application – multiple agencies needing to share data or develop systems to share data;
• Sharing Radios – allowing external agencies to use shared radios to operate on your infrastructure;
• Mutual Aid Response – multiple agencies responding to a predefined emergency incident or event. A lack of agreement among agencies can have a profound impact on the operational success of the system—users needing access could be locked out and the technology benefits will be completely mitigated. For the MOU you need to define the following, at a minimum:
• Purpose – defines why the MOU is needed and when it will be used;
• Scope – defines the reach of the MOU (what agencies are involved and to what extent);
• Terms & Conditions – defines the conditions of use, if any;
• Operational Impact – defines how the MOU will impact the operations of the agencies involved; • Authority & Oversight – defines who has ultimate authority when it comes to administering the MOU; • MOU Update and Maintenance – defines how often and the conditions under which the MOU needs to be reviewed and updated; • Signature – should include the signature of an authorizing agent for each of the agencies and jurisdictions involved.
Standard Operating Procedure (SOP) – The User’s Manual
OK, so now you have the technology, and the users all agree to use it, but how and when do you use it? What are the rules of its use? This is where SOPs will become vital to successful operations of technology. Interoperability has added demand-driven interaction with disparate parties requiring the access and use of the technology supporting a specific locality, region or state. Knowing when to activate a gateway patch, notifying the users of its operation, and the users’ understanding of the proper protocol to use and access the patch is the difference between a usable asset and an unusable asset. This is not about technology; it is about the human utilization of technology. The following is a sample structure for a regional data-sharing SOP:
SOPs provide us with the rules of operation and should be developed before the technical system goes live. The development should include the key end user stakeholders who will be using the system in the field, and once developed, the SOPS should be fully exercised to validate operation.
Exercise – Put It To Practice
The knowledge of how to do something is never as good as the practiced ability to perform as required when it is needed most. During a large-scale emergency is never a good time to find out that some process or system does not work as expected, or in the worst case, at all. Practice, Practice, Practice. Once all of the elements of the technology are worked out, all agreements are in place, and the standard operating procedures are documented, they need to be put to the test. Emergency Exercises have been around for quite some time, but they usually focused on the aspects of handling the incident and interaction relevant to coordination, command and control. Communication is usually an afterthought. For that reason, you should create an exercise that validates the components relevant to communications and interoperability and how they work together during an incident. Do not try to solve the incident, but instead, exercise and discuss how communications would be used at different stages of your scenario. Start with a communications-specific tabletop exercise (TTX) and work your way up to a full-scale exercise (FSE). Take this exercise seriously and take the opportunity to emphasize the importance of communications during an event. In the wise words of Vince Lombardi: “Practice does not make perfect. Only perfect practice makes perfect.” If you are tasked with the responsibility of developing and leading an exercise, it is imperative that you take the time to familiarize yourself with the process. The FEMA IS 120-Course – An Introduction to Exercise includes the following elements in the definition and design of an exercise:
Exercise design includes: Assessing exercise needs; Defining the scope of the exercise; Writing a statement of purpose; Defining exercise objectives; Creating a scenario for the exercise. Exercise development includes: Creating exercise documentation; Arranging logistics, actors and safety; Coordinating participants and media; Other supporting planning tasks (e.g., training controllers, evaluators and exercise staff).
The HSEEP program focuses on the larger picture of emergency exercises and can be a valuable tool; however, it is important to create an exercise focused on the technology you are operationally evaluating. If the system you are evaluating is a regional radio resource, you should create a scenario that requires the use of the regional communication assets, such as:
• Cache Radios – requires a scenario with response from external agencies, i.e., response teams from first responder agencies in the state or other parts of the country.
• System and Console Patches – requires a scenario with response from external agencies within your geographical proximity, i.e., State Agencies, Hospitals, College & Universities, Military Installations, etc.
• Mutual Aid Talk Groups – requires a scenario with response from public safety agencies usually neighboring or within your jurisdiction.
• Gateways – requires a scenario with response from external agencies where they would bring their own radio assets, i.e., FBI, FEMA, etc.
Other regional communication resources unique to your community should be considered as required.
Remember, you need to ask the question, how would I communicate with the State Police if I needed their assistance with perimeter security? Not, how would the State Police set up perimeter security? In this scenario, if you realize during the exercise that you do not have a way to directly communicate with the State Police, this should become a gap documented in the After Action Report (AAR) of the exercise. When you are done with the exercise, and if it was done right, your AAR should be a roadmap of improvements that your agency, jurisdiction, region or state will need to make to improve the technology—in this case, communications interoperability.
Technologies Replace Humans? Not quite yet…
We often hear from public safety practitioners that technology is the easy part—getting first responders to agree to use it, understand how to use it, and practice the use regularly is the hard part. This is the human factor as it relates to technology and should never be overlooked. No matter how far public safety technology advances, it will always require the first responder, the human element, to make it work. So, as you embark on your next technology initiative, remember the human element of the project and that it is really the “extraordinary” public safety people that will make technology work.
Doug Onhaizer is Director of Public Safety Programs for SEARCH, The National Consortium for Justice Information and Statistics (www.search.org).
Published in Public Safety IT, Jan/Feb 2010
Rating : Not Yet Rated