U.S. Department of Justice Office of Community Oriented Policing Services Image of DOJ Seal Law Enforcement Tech Guide for Communications Interoperability A Guide for Interagency Communications Projects Image of Police officer talking into walkie-talkie. Image of EMS teams working on a patient. Image of firefighter talking into walkie-talkie. Copyright © 2006 SEARCH Group, Incorporated. The U.S. Department of Justice reserves a royalty-free, nonexclusive, and irrevocable license to reproduce, publish, or otherwise use, and to authorize others to use, this book for Federal Government purposes. This document may be freely distributed and used for noncommercial and educational purposes. No part of this book may be reproduced in any form, by any means (including electronic, photocopying, recording, or otherwise) for commercial purposes without the prior permission of the U.S. Department of Justice or the author(s). U.S. Department of Justice Office of Community Oriented Policing Services Law Enforcement Tech Guide for Communications Interoperability A Guide for Interagency Communications Projects By Dan Hawkins This publication was supported by cooperative agreement #2003CKWXK054 awarded by the U.S. Department of Justice Office of Community Oriented Policing Services to SEARCH Group, Incorporated, 7311 Greenhaven Drive, Suite 145, Sacramento, CA 95831. The opinions or recommendations contained herein are those of the author(s) and do not necessarily represent the official position or policies of the U.S. Department of Justice. References to specific organizations, products, or services should not be considered an endorsement of the product by the author(s) or the U.S. Department of Justice. Rather, the references are illustrations to supplement discussion of the issues. Image of DOJ Seal U.S. Department of Justice Office of Community Oriented Policing Services Office of the Director 1100 Vermont Avenue, NW Washington, D.C. 20005 Dear Colleague: The basis of any successful community policing program is establishing collaborative partnerships that help to reduce crime and enhance public safety. Collaboration is also the key to successful interoperable communications. The same practices that pertain to planning, purchasing, and managing traditional information technology systems apply to interoperable communications systems. What makes interoperability projects inherently more difficult are the various needs, capabilities, and operational practices of the participating agencies. Interagency collaboration is as important to achieving interoperability as developing the appropriate technological infrastructure. Having awarded millions of dollars to help metropolitan regions throughout the nation establish and enhance their interoperable communications systems, the Office of Community Oriented Policing Services (the COPS Office) is keenly aware of the challenges that confront agencies as they work toward interoperability. Therefore, we have developed this publication to share what we have learned and to assist you with the process of planning, procuring, and implementing your new system. This guide, which is one of many resources that the COPS Office offers to law enforcement, is intended to provide you with practical information that supports your effort to successfully establish interagency, interdisciplinary, and interjurisdictional voice and data communications systems. By increasing interoperability and information sharing among the nation’s law enforcement, fire service, and emergency medical service communities, officer safety and the safety of the citizens they serve can be secured. I trust that you will find this guide helpful, and encourage you to visit www.cops.usdoj.gov to learn about the other numerous resources offered by the COPS Office. Carl R. Peed Director Contents Acknowledgments ................................................................. xv About the Author ............................................................... xvi About the Guide About the Guide .................................................................. 3 Assumptions…About You............................................................. 4 Assumptions…About Your Project ................................................... 5 How this Guide Is Organized....................................................... 5 Definition of Icons .............................................................. 6 Where to Go From Here ............................................................ 8 Part I: What Is Communications Interoperability? Chapter 1 Introduction—A Changing Environment .............................................. 13 Public Expectations .............................................................. 13 Evolving Communications Needs .................................................... 14 Developing Technologies........................................................... 15 The Interoperability Equation .................................................... 16 What Will Tomorrow Bring? ........................................................ 18 Chapter 2 Key Challenges and Critical Elements ............................................. 21 Recent Findings: Why Public Safety Can’t Talk .................................... 22 Incompatible and Aging Communications Equipment .................................. 23 Limited and Fragmented Funding ................................................... 24 Limited and Fragmented Planning .................................................. 25 Lack of Coordination and Cooperation.............................................. 25 Limited and Fragmented Radio Spectrum............................................. 26 Critical Elements to Achieving Interoperability................................... 28 Governance ....................................................................... 28 Standard Operating Procedures .................................................... 28 Training and Exercises ........................................................... 29 Frequency of Use ................................................................. 29 Technology ....................................................................... 29 One More Time: It’s the Planning and Coordination ................................ 30 Chapter 3 Operability—Job #1 ............................................................... 35 A Proportional Perspective........................................................ 36 Extreme Operations—9/11 .......................................................... 37 Important Conclusions............................................................. 38 National Incident Management System .............................................. 39 Common Terminology ............................................................... 40 Integrated Communications......................................................... 40 Operational Building Blocks ...................................................... 41 Chapter 4 Interoperability in the Integrated Enterprise .................................... 45 What is the “Enterprise”? ........................................................ 45 A Complex System of Systems ...................................................... 46 The Call Arrives ................................................................. 46 The Call Is Dispatched ........................................................... 46 First Responders Respond ......................................................... 47 Service Is Delivered ............................................................. 47 Enterprise Integration ........................................................... 48 How Did Communicating Get so Complicated?......................................... 48 A Vision of Information Sharing................................................... 49 Information Sharing Concepts: SOA What?........................................... 50 Common Terminology Aids Communication ............................................ 51 Stating Requirements for Information Sharing ..................................... 53 The Good News on Stating Requirements............................................. 54 Leadership Rules ................................................................. 54 See the Big Picture .............................................................. 55 Part II: How Is Interoperability Achieved? Chapter 5 Build an Interagency Foundation......................................... 63 The Heart of It: Partnerships, Planning, and More Partnerships ................... 64 Foundations 101: Decision-Making Structure ....................................... 64 Foundations 102: Project Management .............................................. 73 Foundations 103: Project Charter ................................................. 74 Footings on Bedrock .............................................................. 77 Chapter 6 Conduct a Needs Analysis.......................................................... 81 Needs Analysis 101: Assess Current Business Processes ........................................................................ 83 Needs Analysis 102: Determine Stakeholder Needs .................................. 89 The Goals ........................................................................ 89 Techniques ....................................................................... 90 Needs Analysis 103: Develop General System Requirements ..................................................................... 92 Describing Requirements .......................................................... 92 Needs Analysis 104: Evaluate Buy-Versus-Build Options ............................ 98 Chapter 7 Scope the Work To Be Done ....................................................... 103 Commonly Contracted Services .................................................... 104 Project Management .............................................................. 104 System Design ................................................................... 104 Detailed Engineering Design ..................................................... 104 System Installation and Optimization............................................. 105 System Integration .............................................................. 105 Quality Assurance................................................................ 105 Acceptance Testing .............................................................. 105 Other Work To Be Done ........................................................... 106 Training ........................................................................ 106 Radio Site Development .......................................................... 106 Frequency Coordination and Licensing ............................................ 111 Assessing the Scope of Work To Be Done........................................... 113 What Are the Choices? ........................................................... 113 What Will You Handle Internally? ................................................ 113 Recommendations.................................................................. 114 Develop Your Own Recommendations and Get Approval ........................................................................ 114 Chapter 8 Create a Project Plan ........................................................... 117 Project Planning 101: Set the Scope and Objectives............................... 118 Project Planning 102: Develop the Timeline....................................... 123 Project Planning 103: Estimate and Deliver a Budget ............................. 123 Project Planning 104: Create a Risk Management Plan ............................. 129 Project Planning 105: Communicate Plans and Progress............................. 130 Communicating Across Agencies: The Project Web Site ............................................................ 132 Graphically Communicating Roles: The RACI Matrix................................. 134 Chapter 9 Acquire the System Components.................................................... 137 System Acquisition 101: Groundwork .............................................. 140 System Acquisition 102: The Art of Procurement .................................. 145 System Acquisition 103: Create the Contract(s) .................................. 148 Chapter 10 Implement the System............................................................. 155 Prologue to an Implementation.................................................... 156 Further Define Roles ............................................................ 156 Establish the Implementation Team................................................ 158 Create the Implementation Plan................................................... 158 Implementation Plan Elements .................................................... 158 Sign, Seal, and Deliver! ........................................................ 162 Manage Documentation............................................................. 162 Use Quality Assurance and Acceptance Tests ...................................... 164 Testing ......................................................................... 165 Create Standard Operating Procedures and Train .................................. 172 An Example ...................................................................... 173 Delta River County: As-Is ....................................................... 173 Delta River County: To-Be ....................................................... 175 Delta River County: The Implementation .......................................... 176 Delta River County: Acceptance .................................................. 178 Chapter 11 Transition to Long-Term Governance .............................................. 183 A System of Systems ............................................................. 184 Project Closeout................................................................. 185 Hold a Transition Meeting........................................................ 185 Conduct an Open Review Meeting .................................................. 185 Write a Final Report ............................................................ 186 Govern and Manage ............................................................... 186 Build Long-Term Governance Structures ........................................... 186 Build a Sustainable Financial Structure ......................................... 190 Create a Review Process ......................................................... 193 Chapter 12 Develop Policies and Procedures ................................................. 197 Integrate NIMS into SOPs ........................................................ 198 Focus on Routine and Targeted Capabilities ...................................... 198 Targeted Capabilities ........................................................... 199 Establish and Use a Standard Method ............................................. 200 Shared Systems in the Twin Cities ............................................... 200 Shared Channels Under the Big Sky ............................................... 201 Create Technical Policies and Procedures ........................................ 201 Create Operational Policies and Procedures ...................................... 202 ICS Communications Unit.......................................................... 202 Incident Dispatch Teams ......................................................... 203 Emergency Traffic ............................................................... 203 Channel Span of Control.......................................................... 204 Standard Language................................................................ 205 Communications-Order Model ...................................................... 205 Operational Unit Reporting....................................................... 206 Build Incident Communications Plan Templates .................................... 206 ICS 205 ......................................................................... 207 Tactical Interoperable Communications Plans ..................................... 209 Chapter 13 Train and Exercise .............................................................. 213 Focus on Both Routine and Targeted Capabilities ................................. 213 Train in Context................................................................. 214 Use Standardized Exercise and Evaluation Processes............................... 214 Discussion-Based Exercises....................................................... 215 Operations-Based Exercises ...................................................... 215 Evaluations ..................................................................... 216 Chapter 14 Maintain the Technology ......................................................... 219 Identify Responsibilities ....................................................... 219 Create a Technical Continuity of Operations Plan................................. 220 Do Regular and Preventive Maintenance ........................................... 220 Test at Least Monthly ........................................................... 221 Maintain System Security......................................................... 221 Prepare for System Changes ...................................................... 222 Evaluate Potential System Upgrades .............................................. 222 Prepare for Regulatory Changes .................................................. 222 Chapter 15 Measuring Interoperability....................................................... 227 Why Measure Interoperability?.................................................... 228 Cautious Measures ............................................................... 228 The Interoperability Assessment Scorecard ....................................... 228 SAFECOM Interoperability Baseline Assessment .................................... 229 Conduct a Self-Assessment ....................................................... 230 The Interoperability Self-assessment Scorecard .................................. 230 Using the Self-Assessment Scorecard.............................................. 232 On the Horizon: Performance Measures ............................................ 234 Measuring Effects, Not Capabilities ............................................. 235 Performance Measurement Improves Communications .................................................................. 236 Conclusion....................................................................... 237 Part III: Exploring the Technologies Chapter 16 ...................................................................... 243 Voice Communications Understanding the Technologies .................................................. 245 FCC Classification of Radio Systems ............................................. 245 Analog and Digital Radio Technologies............................................ 246 Conventional and Trunked Radio Systems........................................... 251 Communications in Buildings and Tunnels.......................................... 259 Satellite Communications ........................................................ 261 VoIP in Voice Systems ........................................................... 263 Approaches to Interoperability .................................................. 266 Technology Approach: Swap Radios................................................. 267 Technology Approach: Gateways ................................................... 269 Technology Approach: Shared Channels ............................................ 274 FCC Designation of Shared Channels............................................... 275 Technology Approach: Shared Systems ............................................. 276 Security......................................................................... 278 Advanced Radio Features for Physical Security ................................... 279 Encryption and Key Management ................................................... 279 Chapter 17 Data Communications.............................................................. 285 Common Protocols and Standards................................................... 285 The Internetworking Effect....................................................... 285 XML—Universal Language of the Internet .......................................... 287 Building Blocks for Interoperability ............................................ 292 Wired Data Networks.............................................................. 292 A Whole Lotta *AN Going On!...................................................... 292 Data Networking Evolution ....................................................... 294 Wired Networks Keep On Keeping On ............................................... 296 Wireless Data Networks .......................................................... 296 Common Principles ............................................................... 297 Private Radio Technologies....................................................... 298 Commercial Radio Technologies ................................................... 299 Wireless Local Area Networks .................................................... 302 Rent or Own?..................................................................... 309 Security......................................................................... 312 FBI Criminal Justice Information Systems Security Policy ................................................................. 313 Securing Data Networks .......................................................... 316 On The Horizon................................................................... 319 Wireless Metropolitan Area Networks ............................................. 319 Broadband Wireless Access for Public Safety ..................................... 320 Wideband Wireless Standards for Public Safety ................................... 321 Project MESA .................................................................... 322 Standards: A Necessary, But Insufficient Condition .............................. 323 Epilogue ........................................................................ 324 Appendixes A. Sample Agreements ................................................. 327 B. SOP Example................................................................... 343 C. ICS Communications Position Duties ........................................... 349 D. Interoperability Self-Assessment Scorecard ................................... 359 E. Bibliography and Resources ................................................... 377 F. Glossary ..................................................................... 389 G. SAFECOM Interoperability Continuum............................................ 413 Acknowledgments This publication was prepared by SEARCH, The National Consortium for Justice Information and Statistics, Francis X. (Paco) Aumand III, chair, and Ronald P. Hawley, executive director. The project director was Kelly J. Harris, deputy executive director of programs. Dan Hawkins, director of public safety programs, wrote this publication. Twyla R. Putt, manager, corporate communications, and Linda Townsdin, senior writer/ editor, edited this publication. Jane L. Bassett, publishing specialist, provided layout and design. Chris Roebuck, webmaster, provided web site coordination. The federal project manager was Debra Cohen, Ph.D., of the U.S. Department of Justice Office of Community Oriented Policing Services (COPS). We would especially like to acknowledge the contributions of the U.S. Department of Homeland Security Science and Technology Directorate’s Office for Interoperability and Compatibility’s SAFECOM Program. The presence of the SAFECOM logo on the front cover of this Guide serves to demonstrate its support of the information offered here and use of tools created by the program, including the Interoperability Continuum and baseline assessment. Suggested Citation Dan M. Hawkins, Law Enforcement Tech Guide for Communications Interoperability: A Guide for Interagency Communications Projects, Washington, D.C.: U.S. Department of Justice Office of Community Oriented Policing Services, 2006. About Us SEARCH, The National Consortium for Justice Information and Statistics, is dedicated to improving the quality of justice and public safety through the use, management, and exchange of information; application of new technologies, and responsible law and policy, while safeguarding security and privacy. We assist local, tribal, county, regional, and state agencies and organizations—including law enforcement and public safety; first responders; prosecution; defense; adjudication; detention; corrections and probation; and other disciplines, such as transportation, drivers’ licensing, vehicle registration, public health, and social services—through a broad array of activities, resources, and products. Our focus is on criminal history systems, integrated justice information systems, information technology (planning, purchasing, managing), and cybercrime investigation. Our services include in-house and on-site technical assistance and training, resource development (web sites, publications, white papers, conferences, workshops), public policy assistance, and model development (model legislation, standards and procedures, best practices) in these focus areas. SEARCH online resources provide information on law enforcement IT, integrated justice, justice software solutions, and IT acquisition at www.search.org. About the Author Dan M. Hawkins leads Public Safety Programs for SEARCH, The National Consortium for Justice Information and Statistics, where he directs technical assistance to public safety agencies nationwide in automated systems development, planning, and integration of justice information systems, and communications interoperability. Dan has 25 years of experience in the public safety field, most recently as communications technology manager for the state of Montana, where he managed the development of a statewide radio system. Prior to that, he served in several positions for the state, including Information Technology Operations bureau chief for its Department of Justice, manager of the state’s Public Safety Communications Program, and training officer for its Criminal Justice Information Network. He served as the FBI information security officer for Montana and as adjunct faculty for both the Montana Law Enforcement Academy and Fire Services Training School. Dan began his public safety career as a deputy sheriff in a rural Montana county. Dan is a life member of the Association of Public-Safety Communications Officials– International (APCO) and associate member of the International Association of Chiefs of Police (IACP). He has served in various roles within APCO over the years, including chapter president, member of its International Executive Council, chair of the Advisory Committee overseeing its frequency coordination subsidiary, and as a member of several task forces. He represents APCO on Project MESA, an international partnership developing digital mobile broadband standards worldwide. He also serves on IACP’s Communications and Technology Committee and on the Advisory Group to the Department of Homeland Security SAFECOM Program. As a U.S. Forest Service-trained incident command system (ICS) communications unit leader, Dan has served during several large law enforcement operations, wildfires and disasters, including two large train derailments resulting in serious hazmat incidents. He worked as a lead geographic information systems specialist in Colorado during the 2002 wildfire season. Dan holds a bachelor’s degree in criminal justice from Montana State University and has completed advanced management programs with the state of Montana and IBM’s Advanced Business Institute. He has held basic and intermediate Peace Officer Standards and Training certificates, as well as several other certifications from the Montana Law Enforcement Academy. Review Committee SEARCH extends its deepest thanks and appreciation to the following members of the Communications Interoperability Tech Guide Review Committee, who participated in an advisory capacity during the preparation of this Guide. Steve Proctor, Executive Director Utah Communications Agency Network John Powell, Sr., Consulting Engineer Advanced Communications Technologies and Interoperability U.S. Department of Homeland Security Harlin McEwen, Chairman Communications & Technology Committee International Association of Chiefs of Police Marilyn Ward, Executive Director National Public Safety Telecommunications Council Joe Noce, 800 MHz Project Manager Mesa (Arizona) Police Department (Retired) We would also like to thank members of the following agencies for contributing their time and expertise to a review of this Guide: the Bureau of Justice Assistance and U.S. Department of Justice’s (DOJ) Global Justice Information Sharing Initiative; the DOJ’s Office of the Chief Information Officer; the U.S. Department of Homeland Security’s (DHS) Office of Grants and Training, Preparedness Directorate; and the DHS Science and Technology Directorate’s Office for Interoperability and Compatibility’s SAFECOM Program. We are grateful to their efforts toward providing a unified federal voice to agencies across the country seeking guidance on interoperability. About the Guide A Library of Tech Guide Resources This Tech Guide on interoperable communications projects is intended to serve as a companion guide to Law Enforcement Tech Guide: How to plan, purchase and manage technology (successfully!). The original Tech Guide was published in 2002 by the U.S. Department of Justice Office of Community Oriented Policing Services (COPS) and was developed as a step-by-step guide to help law enforcement agencies as they implement new technologies. This Communications Interoperability Tech Guide is intended to complement and be used along with the original Tech Guide. As such, this Guide makes frequent references to content in the original Tech Guide. It may help to keep the original Tech Guide close at hand so you can refer to particular pages and sections as needed. This Tech Guide is one of a series of four topic-specific Tech Guides funded by the COPS Office. The four companion Tech Guides that will form a comprehensive library of technology resources, along with the original Tech Guide, are: Law Enforcement Tech Guide for Small and Rural Police Agencies: A Guide for Executives, Managers, and Technologists Law Enforcement Tech Guide for Creating Performance Measures that Work: A Guide for Executives and Managers Law Enforcement Tech Guide for Communications Interoperability: A Guide for Interagency Communications Projects Law Enforcement Tech Guide for Information Technology Security: How to Assess Risk and Establish Effective Policies See Page 8 for details on how to download or order your copy of the original Tech Guide. About the Guide Communications interoperability is such a big issue; how do you get your arms around the topic? In recent years the term has been used in a variety of ways to mean different things to different people. Most important, what does it mean to your agency and how do you approach it practically and systematically to best serve the public? Well, whether you’re replacing your entire radio system, replacing bits and pieces, or just looking to improve communications with other agencies without spending money, the basics are the same. Interoperability is built on solid foundations of leadership, cooperation, and care in understanding just what you’re trying to accomplish. No amount of money can build a system allowing police, fire, and emergency medical services agencies across different jurisdictions to talk to each other if operational plans and procedures don’t support it. Usually we end up talking together only as well as we’ve planned to. Communications projects can be big and costly. Too often, their complexity has forced agencies to focus on internal needs without paying enough attention to how they will communicate with others. It’s easy to fall into the trap of considering your new voice or data system to be an isolated project, unaffected by other systems that your agency and neighbors use. The result is usually a system that is integrated with the agency’s other internal information and communications systems, but incapable of interoperating with cooperating neighbors. This Guide is designed to give you, an agency executive or project manager, background on the subject of communications interoperability and tools to carry out technology initiatives that make this interoperability possible. It is intended as a companion to the Law Enforcement Tech Guide: How to plan, purchase and manage technology (successfully!), A Guide for Executives, Managers and Technologists. Many references are made to the “original Tech Guide”; you may want to have it handy to refer to. Better yet, read it first and get an understanding of how technology projects in general are successfully carried out! HOW TO USE THIS GUIDE strategies, best practices, and recommendations for public safety radio projects. This Guide should not be construed as specific legal advice for any particular factual situation. This publication is meant environments. It does not replace or supersede any policies, procedures, rules, and ordinances This Communications Interoperability Tech Guide is intended to provide background information, to serve as a guideline for situations generally encountered in radio planning and implementation applicable to your jurisdiction’s procurement and contract negotiations. This Guide is not legal counsel and should not be interpreted as a legal service. Assumptions… … About You This Guide is intended for staff of law enforcement or other public safety agencies who are responsible for carrying out a successful radio project. A good team is made of many players doing their own part. If you’re a chief executive of the agency, welcome aboard! Your contribution to the project is going to be critical. If you’re a technical services manager, we’re happy to have your expertise in both the business of your agency and how technology is aligned with its goals. Since your daily responsibility is to ensure that all systems work together, understanding the added complexities of interagency communications is vital. And if you’re a technical expert who gets the calls in the middle of the night to fix the pieces that have taken an unexpected holiday, we empathize! Your interest in these systems over their lifecycles hits right at home, doesn’t it? Maybe you’re the officer or communications manager who has been assigned responsibility within your agency to oversee a new voice or data radio system that must be compatible with other agencies with which you work. Every bit of project management experience you’ve gathered will probably be put to work to make sure these critical and often expensive systems come together on time, within budget, and offering the capabilities everyone expects. You’ll need a broad understanding of how your agency uses radio communications to provide services, how technology is chosen to support them, and why the efforts of a cross section of people in your agency are needed to bring about a successful project. Or maybe you’re the project manager dedicated solely to this effort. If so, congratulations! Not many folks get to concentrate on a single project. More likely, your skills are valued elsewhere in the agency, too, and you have no shortage of projects on your desk. This may be only one of several technology initiatives you’re working on that demands your skills in combination with a decent understanding of the technologies involved, business practices affected, and common pitfalls others have faced. FYI: We tell you how to get your own copy of the original Tech Guide on Page 8. You might think that your agency is too small or your project too tightly funded to have a full-time project manager. That certainly might be the case and if you’re managing projects in such an agency, you’re most likely to have other routine duties—and maybe even other projects. This Guide is especially useful to you because it provides a how-to guide with tips, checklists, and recommendations for your efforts—large or small! This Guide will provide important background for all team members on how interoperability in communications systems is achieved. Its companion Law Enforcement Tech Guide will also be indispensable in your efforts. Get your own copy! … About Your Project We assume that you already have voice radio capabilities in your agency and are either replacing systems nearing the end of their useful lives or carrying out a project to improve communications between existing systems. Maybe you’re implementing a data radio system to augment voice communications and add new field capabilities or provide direct access to important computer systems. While this Guide doesn’t address mobile data or computer systems in depth, it does address important aspects of the radio environment for both voice and data projects. Its central focus is on how to improve interagency communications across your jurisdiction. How this Guide Is Organized This Guide is split into three parts to help you navigate to areas of greatest interest to you. Each part builds on preceding ones, but if you’re in a hurry to get to work improving interagency communications, jump right to the second part. If you’re just interested in how technology is applied to achieve interoperability, the third part may be most useful to you. However you approach it, please take time at some point to read the entire Guide. You will find useful background for current, as well as future, projects. Part I What Is Communications Interoperability? neighbors. Part II How Is Interoperability Achieved? addresses steps to successful projects that were first introduced in the original Law Part III Part I takes a look at what interoperability is and where we are today, as of the printing of this Guide. While we talk briefly about how and why interoperability has become a national issue, our focus is on what it means for local public safety agencies that have to talk with their Part II delves into how to achieve interoperability within your jurisdiction or region. It Enforcement Tech Guide. The original Tech Guide dedicated multiple chapters to each step, so in this Guide we’ll focus on additional aspects of interoperability projects or ones that require a bit more attention. The final chapter of this part takes a look at how we can measure our level of interoperability. Exploring the Technologies Part III examines the different technological approaches to interoperability and specific types of communications equipment used in each. Since security plays an increasingly important role in public safety technology, we’ll examine it with both voice and data systems. About the Guide The Guide concludes with an important appendix and fold-out with the Department of Homeland Security SAFECOM Program’s Interoperability Continuum. This tool provides a standard set of success elements for interoperability. It also provides a snapshot of how progress is made from limited to highly interoperable public safety services. These elements are addressed from a project perspective throughout this Guide. Our hope is to provide tools to help with your project. Icons are used in the margins as they were in the original Law Enforcement Tech Guide, to highlight areas of specific interest to particular project team members. Executive sponsors, for example, should keep an eye out for the shield icon shown below that is used to mark key points for project champions. Elsewhere, you will also find tips, checklists, and definitions along the way that will be useful in your quest to improve communications interoperability. In appendixes at the end of this Guide, we have included a glossary, resource materials, and sample documents. Definition of Icons Executive Sponsors Icon Executive sponsors are the project spokespersons, decision makers, and leaders of the agencies involved in the interoperability effort. Generally, they are the highest ranking decision makers within their organization. This icon is used to highlight recommendations and advice directed particularly at them. Operational Experts Icon Operational experts are those communications users who understand the business processes of their respective agencies and how operations are conducted with others. Typically, these persons are senior line supervisors with experience in interagency operations. They should keep an eye out for this icon in the margins. Technical Experts Icon Technical expertise is critical for analysis of the current communications technology environment and evaluation of the technical aspects of proposed solutions. This icon is used to draw attention to material that will benefit technical experts. Project Manager Icon Since the project manager has such a pivotal role, we could have used this icon on every page of the Guide. We have limited ourselves to using it to highlight aspects most commonly handled by the project manager. About the Guide Stop Sign Icon Every technology project is challenged to navigate in a veritable minefield of obstacles. When you see this icon, carefully read about pitfalls that we are hoping you will avoid. Grant Requirements Icon This icon is used to draw your attention to interoperability aspects that may be affected by requirements of the grants funding your project. Even if your project is funded by other means, one of your neighbors is probably relying on grants for some part of its system and you will want to learn how grant requirements are shaping its interagency communications plans. Regional Icon Multijurisdictional, regional efforts bring the highest level of communications interoperability. This icon is used to draw your attention to advice and recommendations on how to make those efforts most successful. Tips Icon This Guide is full of tips, but some need particular attention. We’ll use this icon for ideas you might find immediately useful. Checklists Icon We all need lists to organize a collection of thoughts or tasks. Part II of this Guide has a number of checklists to help you keep track of the recommendations that we have provided. Interoperability Continuum Icon As mentioned, the SAFECOM Interoperability Continuum is an important and useful tool for understanding how communications systems evolve from minimal to optimal levels of interoperability. It is included in this Guide as a back cover foldout preceded by an appendix describing its elements in depth. This icon is used to highlight those elements as they are addressed throughout the Guide. Original Tech Guide Icon The parent Tech Guide contains many useful tools, charts, and instructions for conducting various tasks. When you see this icon, you will be directed to a specific page, or range of pages, in the original Tech Guide. About the Guide Where to Go From Here Communications interoperability projects are technology projects. If you don’t have a copy of the original Law Enforcement Tech Guide, download or order one. Since this Guide on interoperability is intended to complement the original, we’ll often refer to it rather than repeating advice. There’s a wealth of material in it about planning, purchasing, and managing technology (successfully!) that you will want to use for all sorts of projects. If you’re with a fire, emergency medical services, or other nonpolice agency, don’t get hung up on the “Law Enforcement” part of the Tech Guide’s title. It was produced for that audience, but the principles and practices provided are applicable across public safety technology, generally. It has been used as a textbook by the U.S. Department of Justice and U.S. Department of Homeland Security to train dozens of jurisdictions from around the country in managing their interagency projects. Sources of the “Law Enforcement Tech Guide” The U.S. Department of Justice Office of Community Oriented Policing Services (COPS) published the Law Enforcement Tech Guide in 2002. It is available electronically from the COPS web site: http://www.cops.usdoj.gov/default.asp?Item=512. There it is broken down into its separate parts as Portable Document Format (PDF) files so you can download or read one at a time. If you’re anxious to download the whole document at once—all 14 megabytes—the complete version can be found at SEARCH’s web site: http://www.search.org/files/pdf/TECHGUIDE.pdf. And finally, hard copy versions are distributed by the COPS Office. To request one, contact the COPS Office Response Center at 800.421.6770 or e-mail askCOPSRC@usdoj.gov. Part I: What is Communications Interoperability? Chapter 1 Introduction— A Changing Environment Interoperability is the ability of agencies to work together toward common ends. In recent years, dramatic criminal, terrorist, and natural disasters—and seemingly endless post-incident inquiries—have seared into the public mind the importance of seamless emergency services. Today more than ever, the public expects those services will be delivered regardless of long histories of turf battles between agencies and jurisdictions. Public safety as an entity—the collective of police, fire, emergency medical services (EMS), and supporting agencies—is challenged to integrate services across these boundaries to serve a public that’s not easily separated by administrative lines or simple classifications of calls. Interoperability is the ability of agencies to work together toward common ends. It depends on a common vision of what those “ends” are and how separate capabilities are combined to serve them. As with most government services provided in this day and age, public safety response to emergencies is enabled by technology. Telecommunications and information services, more specifically, are key enablers to effective emergency services. Communications interoperability is changing in an environment with strong public expectations, evolving communications needs, developing technologies, and a growing understanding of how all of these parts work together. Public Expectations What does the public expect? That’s not an easy question, but when Mrs. Smith calls 9-1-1, she doesn’t want to hear about turf issues and technological incompatibilities. She expects that services will be delivered promptly and effectively to address her emergency. No amount of explanation of jurisdictions, policies, or radio failures will matter (or be acceptable) in time of need. The public expects that emergency responders are able to communicate with one another. Expected outcomes of that ability, in management terms, include: • Responder accountability – That those brave souls who “face the elephant” aren’t lost in the fog of battles. • Coordinated incident management – That response to incidents isn’t “sliced and diced” by administrative, operational, or jurisdictional boundaries. Part I: What Is Communications Interoperability? • Shared information – That what is available or known to one is shared, as needed, with others. • Coordinated information management – That the ever-present threat of “TMI” (too much information) doesn’t cause the message to be lost among the noise. • Economies of scale – That public funds are efficiently used for effective systems supporting all emergency response. Communications interoperability is critical for information sharing. Evolving Communications Needs Changes in how we manage resources and expect services to be delivered cooperatively have caused communications needs to evolve internally within organizations and externally between them. This has not occurred without great challenge. For example, decentralized decision making and accountability—key principles in community policing—require that information be readily available to officers who are often widely dispersed throughout jurisdictions. Likewise, community oriented policing requires problem-solving partnerships among police, fire, EMS, and other public safety agencies. Those partnerships are strengthened when first responders have ready access to information from within their own organizations and elsewhere. Most often, that information is delivered to the field wirelessly. One challenge that follows is simply how to provide radio coverage. It’s an unfortunate, but inescapable, fact of today’s public safety environment that the more widely dispersed the responders, the more difficult it is to provide them with reliable, high-quality voice and data network services. Officers in shopping malls, firefighters in large office buildings, and mountain rescuers alike are too often in the unreliable margins of radio networks where any information exchange is difficult. Increasingly, we rely on the lowly handheld radio to connect responders, making coverage an even greater challenge. Public safety agency managers have to work hard to assure that field personnel are reliably connected for safety purposes and for management of operations. While first responders are ideally always connected to the organizational infrastructure that supports their supply of and demand for information, the emergency environment doesn’t always cooperate. Dense urban canyons, tunnels, and ever- rising electronic noise are just a few examples of modern life that increasingly affect the radio environment. Information powers the modern police officer, firefighter, and EMS provider. Whether working individually or in tandem with others during a response, first responders have to receive timely information about the incident, including location, scope, Chapter 1: Introduction—A Changing Environment 15 who else is responding, and tactical plans. Likewise, the information they provide in response can mean the difference between life and death for citizens, not the least of whom are the responders themselves. Integration of information and communications systems—both between agencies and throughout field operations—is an essential part of interoperability today. Developing Technologies Radio communications is a venerable staple in the arsenal of public safety tools. It has only become more so in modern times. Since the earliest systems built more than 80 years ago, radio has been the primary means of getting information to the field. The first Detroit Police Department system was licensed with the Federal Radio Commission in 1922 as KOP, an AM broadcast station required to transmit music between all-points bulletins and administrative messages, with no ability for field units to acknowledge receipt or reply to broadcasts (at times, that might still seem to be an advantage!). By 1928, the radio car was a key part of Detroit’s policing environment. Image of 1928 Picture of Detroit Police Department Station KOP How times have changed! While the melodious sounds of today’s dispatches are hardly entertainment, our radio systems have come far from those one-way days. Gone is the time when radio simply served to connect responders and dispatch. Today, modern police, fire, and EMS agencies around the country rely on voice and data networks that share information wirelessly in all directions: vertically among levels of command, horizontally between functional subdivisions, and further yet across jurisdictional boundaries. Cooperators: Any agency, organization, or person that operates jointly or cooperates with your agency and with which you need to communicate by radio. Science and industry regularly improve our ability to make different technologies work together. Indeed, it’s getting more difficult to distinguish radios from computers and wireless networks from wired pieces strung among them. Technological interoperability first achieved through integration of internal voice and data capabilities now allows us to connect similarly integrated systems with external cooperators. Part I: What Is Communications Interoperability? 16 This advancing technological environment makes it easier to share underlying parts of systems to take advantage of economies of scale, sharing what might otherwise be wasted capacity. Shared coverage and services are possible where completely separate systems were cost-prohibitive. Even though voice and data networks may be separate as they reach into the patrol car, many of the components up to that “last mile” can now be shared between agencies and systems. Both voice and data communications can pass over the same backbone network from dispatch to the transmission site. There they may share power, environmental, and antenna combining subsystems before parting company on separate frequencies destined for different radios in the car. Elsewhere, developing technology has given us the means to get more users on a frequency, more data through channels, and the ability to assign “talkgroups” dynamically based on the needs of the moment. Technology has evolved so that we can now link disparate radio systems, allowing users on one type of network to talk with those on another across their shared operational areas. And it has given us the ability to leverage the capabilities of wireless data to reduce demand for critical voice channels. There’s no doubt that technology advancements have dramatically changed public safety communications, particularly in the past 25 years. They have also challenged us to adapt business practices along the way, sometimes successfully, sometimes not. The growing array of choices we have will further challenge us to manage technology, rather than have it manage us. The Interoperability Equation IMAGE of SAFECOM Icon An electronic government initiative housed within the U.S. Department of Homeland Security (DHS) designated as the umbrella program to coordinate Federal Government efforts to improve communications interoperability. In response to dramatic failures in interagency communications, government entities from Main Street to Pennsylvania Avenue have taken up the challenge of improving the situation. The term “communications interoperability” has come to mean different things to different people, especially following well-publicized breakdowns. In order to bring focus to the subject, the national SAFECOM Program (footnote 1) was initiated. Communications interoperability is defined by SAFECOM as follows: The ability of public safety agencies to talk across disciplines and jurisdictions via radio communications systems, exchanging voice and/or data with one another on demand, in real time, when needed, and as authorized. 1 See http://www.safecomprogram.gov. Chapter 1: Introduction—A Changing Environment 17 This ability to talk is the sum total of interagency operational plans, common procedures, and enabling technologies, multiplied by the effects of training and exercises. The best interagency plans and procedures are a complex function of standardized incident management systems and common terminologies. Funding and other resource limitations are often confounding factors in efforts to solve this equation. Further federal and state efforts are helping with this bit of algebra. The U.S. Department of Justice, through its Office of Community Oriented Policing Services (COPS), and the DHS, through the Federal Emergency Management Agency (FEMA), have cooperatively granted hundreds of millions of dollars to local agencies since the terrorist attacks of September 11, 2001, to improve communications interoperability. In addition, the DHS Office of Grants and Training has distributed billions of dollars to public safety agencies through State Homeland Security and Urban Area Security Initiative (UASI) grants, much going to improve communications in response to terrorist events. Even funds provided through pre-existing federal grant programs are in large share today being used to update and enhance the country’s public safety communications infrastructure. At the state level, statewide interoperability executive committees—generically known as SIECs—have evolved in recent years to focus state and local efforts. First defined by the Federal Communications Commission (FCC) in 2001 for the administration of interoperability channels in the 700 MHz frequency band, SIECs have become increasingly pivotal in steering grant funds and growing multijurisdictional efforts in many states. Efforts in Washington2 and Virginia,3 for example, have provided models for how first responders across disciplines and jurisdictions can work together toward common goals. State homeland security agencies have began to look to SIECs to connect their strategic plans with real-world interagency communications needs. Efforts to solve the interoperability equation are probably affecting your work, whether you’ve been aware of it or not. 2 See Washington’s SIEC web site at http://isb.wa.gov/committees/siec/. 3 See Virginia’s interoperability web site at http://www.interoperability.publicsafety.virginia.gov/. Part I: What Is Communications Interoperability? 18 What Will Tomorrow Bring? This is the environment faced by agency and project managers who are working to improve communications within their own jurisdictions. Perhaps you’re reading this because you’re responsible for making those improvements. How will it change over the period of your projects, the lifecycles of your systems, or your career? Well, it’s easy, if sad, to imagine that emergencies and disasters capturing national attention will continue to occur. Communications needs will evolve as our response capabilities become more complex and sophisticated. Technology will surely continue to offer opportunities for greater interagency communications and challenge our ability to employ it without disrupting what’s already been achieved. And our collective efforts will help solve the interoperability equation. In the chapters ahead, we’ll look further at challenges to achieving interoperability— right after taking a brief look at how information flows in organizations with technology well integrated into services being delivered. Chapter 2: Key Challenges and Critical Elements A changing environment for public safety agencies has brought a range of challenges to achieving the communications interoperability necessary for emergency services. Nationally, the key challenges and critical elements for success have been documented through the collective attention of local, state, and federal officials. This high level of attention arose in concert with a growing public awareness of interoperability problems. Though dramatically highlighted by recent tragic events, communications, particularly interagency communications, have long been a problem. At the heart of public safety communications is first responder radio capabilities. Radio communications—or the lack thereof—can and has contributed directly to first responder deaths. This Guide stresses that integration of voice and data technologies is necessary for interoperability, but we recognize from direct experience the importance of first responder voice communications. Radio is the most critical information technology tool for officers investigating a “hot” burglary, firefighters on interior attack during a structure fire, and paramedics providing basic life support. Given its importance in basic emergency operations, there’s no surprise that first responder radio capabilities are also at the heart of interoperability needs. Part I: What Is Communications Interoperability? 22 Recent Findings: Why Public Safety Can’t Talk Following that fateful September day in 2001, the National Institute of Justice (NIJ), Office of Science and Technology, organized the National Task Force on Interoperability (NTFI). This task force of leaders from 18 national associations representing state and local officials addressed the problem of communications interoperability. NTFI reported out five key reasons why public safety can’t talk.4 From a policy and operation perspectives, they are as follows: • Incompatible and aging communications equipment • Limited and fragmented funding • Limited and fragmented planning • Lack of coordination and cooperation • Limited and fragmented radio spectrum. Image of Front cover of "Why Can't We Talk?" Every effort to improve interagency communications faces these same challenges, though to different degrees. For example, some jurisdictions have long histories of productive planning and coordination, but are desperately short of needed funds for system upgrades to connect responders across agencies. Other jurisdictions face such a severe shortage of radio frequencies that interoperability efforts are stymied, regardless of available funding. Each group of agencies seeking to improve interoperability faces a different combination of these basic challenges. We’ll get into how these challenges can be addressed in Part II of this Guide, How is Interoperability Achieved? Let’s take a look here at how these challenges have developed into national problems. 4 Why Can’t We Talk? Working Together to Bridge the Communications Gap to Save Lives, National Task Force on Interoperability, February 2003. Available at http://www.ojp.usdoj.gov/nij/topics/commtech/ntfi_guide.pdf. Chapter 2: Key Challenges and Critical Elements 23 Incompatible and Aging Communications Equipment The lifecycle for radio systems has traditionally been very long, sometimes exceeding 20 and even 30 years. Equipment used in these systems is customarily expected to have an 8-to-10-year service life, yet more than one-half of agencies currently exceed that. 60 percent of state and local law enforcement agencies report that aging radio communications equipment is a problem. A survey of 1,334 state and local law enforcement agencies conducted in 1998 by the National Law Enforcement and Corrections Technology Center for NIJ showed a direct correlation between the age of systems and respondents’ assessment of their radio communications effectiveness.5 Sixty percent reported aging equipment to be a moderate to major problem. Local law enforcement systems averaged 9 years in service, while state systems averaged even longer—15 years. According to reports issued by Public Safety Wireless Network (PSWN), a joint initiative of the U.S. Departments of Justice and Treasury that is now part of SAFECOM, local fire and emergency medical services (EMS) systems average 10 years.6 When characters Roy Desoto and Johnny Gage showed us (well, at least some of us) just how exciting communications could be during the 1970s hit television show “Emergency!”, radio technology choices were few and compatibility was high. Their call sign, KMG365, was and still is assigned to a VHF (Very High Frequency)-high band, analog FM (frequency modulated) base station. The call sign and station are still in use by Los Angeles County, although probably with equipment of more recent vintage! Options for police, fire, and EmS radio have blossomed in relatively recent history. Unfortunately, some agencies are still using radios purchased new when “Emergency!” debuted. The simple fact that the radios still work is amazing. It says something about the quality of equipment manufactured for lengthy public safety use, but more about historically limited technology choices that lead (or force) agencies to upgrade. Options for police, fire, and EMS radio have blossomed in relatively recent history, much as we’ve seen wireless technologies explode in the consumer sector. 5 Taylor, Mary J., et al., State and Local Law Enforcement Wireless Communications and Interoperability: A Quantitative Analysis, NCJ 168961 (Washington, D.C.: U.S. Department of Justice, Office of Justice Programs, National Institute of Justice, January 1998). Available at http://www.ncjrs.org/pdffiles1/168961.pdf. 6 PSWN Program Analysis of Fire and EMS Communications Interoperability, Public Safety Wireless Network Program Management Office, prepared by Booz, Allen & Hamilton Inc., April 1999. Available at http://permanent.access.gpo.gov/websites/safecomprogramgov/www. safecomprogram.gov/admin/librarydocs9/fireems_interop_study.pdf. Part I: What Is Communications Interoperability? 24 Regional incompatibilities have grown as agencies have upgraded one by one to meet pressing internal needs. Because lifecycle needs vary, separate agencies within a single jurisdiction often end up replacing systems at different times, making needed changes that result in additional interoperability challenges. The costs of supporting old equipment and technologies dropped by manufacturers have led agencies across the country to upgrade systems. In many cases, their partners and neighbors were unable to do likewise. The result today is that we have, for example, rural fire departments using radio technologies pioneered more than half a century ago while larger, neighboring jurisdictions have migrated to higher frequency bands, digital channels, and trunked systems. Incompatibility is the result. Limited and Fragmented Funding Across all levels of government, limited and fragmented funding has contributed to all other interoperability challenges by: • Hindering replacement of aging and incompatible equipment • Restricting human resources available for interagency planning • Forcing agencies to focus on their most pressing internal operational needs • Limiting access to scarce radio spectrum resources. There has never been a national strategy for funding public safety radio costs. Local radio systems for police, fire, and EMS are funded by every means available to government, from general appropriations and bonds to grants and bake sales. Local, tribal, and state systems, alike, are most often funded as one-time projects. Their ongoing costs—including maintenance, licensing, network services, training, replacements, and other operating expenses—are annually shoehorned into tight budgets. By contrast, basic and enhanced 9-1-1 services around the country are funded similarly from state to state. Recent congressional action will standardize 9-1-1 funding further. The value of America’s public safety radio infrastructure is staggering. It’s no wonder such fragmented funding for public safety radio has evolved over time. The value of America’s investment in it is staggering. In 1998, it was estimated to be worth $18.3 billion7—and that’s just for equipment and fixed infrastructure. This 7 LMR Replacement Cost Study Report, Public Safety Wireless Network, prepared by Booz, Allen & Hamilton Inc., June 1998. This report and figure is currently the most comprehensive available for the replacement costs of land mobile radio (LMR) equipment owned by local, state, and federal governments. Available at http://www.safecomprogram.gov/NR/rdonlyres/B69361FA-9AC6- 4126-B971-83DF30FED932/0/lmr_coststudy.pdf. Chapter 2: Key Challenges and Critical Elements 25 commonly cited figure does not include system installation, testing, training, or other implementation costs. Complete replacement of existing public safety radio systems, with all associated costs, would total two or more times this figure. The net effect of limited and fragmented funding for public safety radio systems is great diversity between systems and long replacement cycles across the country. Limited and Fragmented Planning The NTFI report identified historically limited and fragmented planning as a third key reason for interoperability problems. Agencies at all levels of government competing for limited funds have provided few resources for interagency planning efforts. This competition has compounded interoperability problems by discouraging partnerships necessary for joint operating plans that define communications needs. Lack of Coordination and Cooperation Likewise, NTFI identified a lack of coordination and cooperation between agencies in funding and managing systems as an impediment to interoperability. Changing the pattern of isolated spending, and increased sharing of management and control, were noted as necessary steps. While multiple solutions to meet varying needs are inevitable, portions of infrastructure, such as towers, and even full systems can be shared in some cases. We’ll have more to say about the importance of operational planning and coordination shortly. Part I: What Is Communications Interoperability? 26 Limited and Fragmented Radio Spectrum radios on widely separated frequencies are incapable of being tuned from one to the other. Agencies seeking to expand or upgrade their systems are increasingly being forced to move to higher frequency bands to find available channels. Because radio equipment is typically built to operate on a single one of the 10 bands open to public safety, systems using different bands are technologically incompatible at a fundamental level. That is, the radios talk on frequencies widely separated and are incapable of being tuned from one to the other. See Figure 2-1. History and operational needs have crowded users to the lower ends of the spectrum. More than half of all agencies operate in vHF-high band. The vast majority of public safety radio systems—both voice and data—operate in four of the lower bands. More than half of the agencies in the country operate their primary voice systems in a single one: VHF-high band.8 Additional channels in current bands are virtually unattainable in many parts of the country. Image of Radio Spectrum Figure 2-1: Radio Spectrum Source: U.S. Department of Homeland Security, SAFECOM Program 8 VHF-high band for local and state agencies runs from 150 to 174 megahertz (MHz). According to supporting documents for PSWN’s LMR Replacement Cost Study, almost 57 percent of agencies make primary use of it, while fewer than 6 percent used 800 MHz. See footnote 7, page 24. Chapter 2: Key Challenges and Critical Elements 27 When an agency moves its radio communications to a “new” band, the technological divide of operating across bands brings fresh challenges to talking directly with previous cooperators. Other technologies, such as console patches, have been used for years to link agencies on different bands, but these bring their own limitations and require additional planning. Remember the planning challenge? Such approaches to resolving the effects of fragmented spectrum are, to put it simply, just patches. They’re less than ideal, but unfortunately necessary. Interoperability would certainly be an easier nut to crack if all agencies operated in the same range of radio spectrum. Unfortunately, each band offers a limited number of channels—the real estate of wireless communications. Each geographic region (neighborhood) only has a certain number of channels (residential lots). “Location, location, location,” they say in the world of real estate. Location in the wireless world is equally critical, but here we’re not just talking about geography. We are also referring to where a system operates within the radio spectrum! Each of the 10 bands is best suited for different purposes and the highest ones are entirely unsuited for unit-to-unit voice systems as we know them today; they’re used for microwave links. And needs vary across the country. For example, urban areas have great demand for channels in the higher bands offering the best building penetration. By contrast, wide-area systems necessary in rural and statewide jurisdictions are most economical in the lower bands where range is greatest. Remember the funding challenge? The highest frequency bands are unsuited for voice systems as we know them today. The net effect is best described as increasing fragmentation that reduces interoperability. The NTFI report also noted that public safety has a growing need for wireless services beyond traditional voice operations. Mobile data, automatic vehicle location, and other types of systems increase demands on a finite public safety spectrum. Beyond that, growing commercial and private demands for wireless services brings intense competition for limited resources that otherwise might be used for public safety. Limited and fragmented radio spectrum is a fundamental cause of interoperability problems. Part I: What Is Communications Interoperability? 28 Critical Elements to Achieving Interoperability Since 2003, the Department of Homeland Security SAFECOM Program has been working to bring a practitioner’s focus to the problem of interoperability. Through SAFECOM, public safety leaders have identified five critical elements to solving interagency communications problems: 1. Governance. 2. Standard operating procedures. 3. Training and exercises. 4. Frequency of use. 5. Technology. They have also identified stages along each element, recognizing that interoperability isn’t an either/or proposition—it’s a matter of degree. Interoperability improves as agencies progress with each of these elements. SAFECOM’s Interoperability Continuum, found here as the foldout rear cover, depicts these elements and stages. Briefly, these ideas are summarized here and incorporated throughout this Guide. Governance As noted by NTFI, limited coordination and collaboration between agencies is a key reason why we can’t talk. Regular collaboration between key staff members of agencies and across disciplines improves this situation, but formal committees serving regional needs and working with statewide efforts are best. Standard Operating Procedures The level of interoperability between agencies increases as they create joint SOPs, typically first for planned events, then for emergencies. All public safety agencies have established standard operating procedures (SOP)— whether these are verbal or written. The level of interoperability between agencies increases as they create joint SOPs, typically first for planned events, then for emergencies. Interoperability improves as joint planning moves to serve regional needs, producing communications SOPs. Optimal levels are reached as the National Incident Management System (NIMS) is integrated into procedures. We’ll talk further about the NIMS in Chapter 3, Operability – Job #1. The National Incident Management System (NIMS) [A] consistent nationwide approach for Federal, State, and local governments to work effectively and efficiently together to prepare for, respond to, and recover from domestic incidents, regardless of cause, size, or complexity. Homeland Security Presidential Directive (HSPD)-5 February 28, 2003 Chapter 2: Key Challenges and Critical Elements 29 Training and Exercises The importance of training and exercises cannot be overstated. Communications interoperability improves in small amounts through simple internal orientations on communications equipment. Tabletop exercises provide further improvements, but by necessity these limit the number of people involved, typically to key field and support staff. Multiagency tabletop exercises produce a higher level of interoperability than single agency ones, of course. Full functional exercises between agencies involving all staff are optimally second only to regular, comprehensive training and exercises incorporating the regional SOPs described previously. Frequency of Use Interoperability improves as agencies use their adopted techniques, procedures, and technologies more frequently and broadly. A minimal, but important, level is reached as those methods and means are used for planned multiagency events. It is further improved by common use during localized emergencies and further yet as incorporated into regional incident management systems. Optimal levels are reached as they are used on a daily basis throughout the region. Technology There are five identifiable technological means of interagency communications, particularly by radio: 1. Swapping radios. 2. Using gateways between independent systems. 3. Sharing channels. 4. Sharing proprietary systems. 5. Sharing standards-based systems. Higher levels of interoperability are reached as the predominant means progresses toward shared systems. Technological Means to Interoperability Swap radios Use gateways Share channels Share proprietary systems Share standards-based systems A minimal level of interoperability is achieved when agencies resort to providing cooperators one of their radios, and vice versa during incidents. This is what we refer to as “swapping radios.” It’s not ideal for a number of reasons, but has often been relied upon. “Gateways” are electronic, often automated devices for taking the audio from one radio channel and patching it to another—and vice versa. In the past, the most common form of gateway was provided by the dispatch console patch mentioned on Page 27. Since September 11, a great many of these have been purchased to improve interoperability. We’ll delve further into these devices in Part III of this Guide, Exploring the Technologies. Part I: What Is Communications Interoperability? 30 A higher level of interoperability is provided when agencies using compatible technologies designate common channels between them for interagency communications in joint operations. This is referred to as “sharing channels.” The final two technological means of interoperability are more self-explanatory. Interoperability through “shared proprietary systems” occurs when multiple agencies jointly use a common system based on proprietary—or vendor-specific—technology. This is considered to be a less optimal means than shared use of a system built from standards-based—or nonvendor-specific—technology. Again, we’ll go further into detail on these and other technologies in Part III. It’s important to note that the steps from minimal to optimal levels of interoperability along each element in SAFECOM’s Interoperability Continuum are progressive. That is, they build on one another and don’t necessarily exclude preceding steps. For example, individual agency communications SOPs are still important when joint or regional ones are in place. Ideally, the two closely mesh. Likewise, in-service orientations on equipment are still important, even when regular, comprehensive regional training is in place. One More Time: It’s the Planning and Coordination There’s a lot more to be said about planning and coordination for interagency communications. As a matter of fact, that’s what all of Part II is about! Well, it’s mainly about how to achieve interoperability, but we’ll give you a brief preview and let you know that’s what it takes to get from here to there. If it isn’t already apparent, planning and coordination between agencies are basic principles behind the Interoperability Continuum’s critical elements. No communications system can make up for inadequate operational plans. Planning for interagency operations, generally, varies greatly from one part of the country to another and between levels of government. Where inadequate operational plans exist, communications suffer tremendously and interoperability is practically impossible. Poor communications can and unfortunately often do hinder operations, but no communications system or set of interoperable systems can make up for inadequate operational plans. In Part II of this Guide, we’ll show how communications interoperability is achieved through a common incident management system, technologies linking responders, and operational plans brought to life before they’re needed through training and exercises. Chapter 2: Key Challenges and Critical Elements 31 The McKinseyreports were prepared for New York City’s police and fire departments in the year following the World Trade Center attacks on September 11, 2001. They include detailed analyses of response to the disaster and recommendations for improving preparedness in the future. We’ll refer elsewhere to these reports on matters important to agencies of all sizes. McKINSEY REPORT … [T]o be fully prepared to face the threats posed by terrorism and other major incidents, the city or state governments must establish a much broader, detailed and more formalized interagency planning and coordination process. The process would include: – Establishment of common command and control structures and terminology, and agreement on the roles and responsibilities of each agency for managing the response to any incident. – Deployment of interoperable communications infrastructures and protocols to improve response coordination and exchange of information. – Implementation of joint training exercises to ensure that agencies can and will cooperate effectively during incidents, e.g., by operating under a unified command and control structure. “Increasing FDNY’s Preparedness,” McKinsey & Company August 19, 2002, Executive Summary, p. 21. Available at http://www.nyc.gov/html/fdny/html/mck_report/toc.shtml Chapter 3: Operability—Job #1 Image of front cover of the 9/11 Comission Report Command and Control within First Responder Agencies. For a unified incident management system to succeed, each participant must have command and control of its own units and adequate internal communications. — The 9/11 Commission Report (Page 319) Throughout this Guide, we refer to the events of September 11, 2001 and after-action reports to highlight issues of interagency communications. The sheer magnitude of those events provides a powerful microscope for examining not only internal operational demands on agencies under such extraordinary circumstances, but also interoperability needs. We all owe a huge debt of gratitude to the agencies rich with experience and history that hardly volunteered, but valiantly responded, that day and now share their lessons learned. We use those lessons here not critically, but to share the benefit of quality analyses arising from the World Trade Center and Pentagon maelstroms. Though the magnitude of those events and scale of response, we hope, are beyond what any jurisdiction will face in the future, our belief is that lessons highlighted here apply to public safety operations at all scales. Part I: What Is Communications Interoperability? 36 The level of attention brought to the national issue of communications interoperability has, at times, drawn the spotlight from this fact: Day in and day out, radio is critical in delivery of all sorts of public safety services. As “operability” is the root of the word, it’s also what makes interoperability possible. The interoperability puzzle is solved by first resolving operational communications needs. Interagency communications are, at best, a distraction if an agency is unable to provide for its own operations. At worst, they can bring chaos to emergency response if they interfere with internal operational demands. No agency administrator, chief officer, or incident commander wants to worry about how the troops are going to talk to other agencies when their own internal radio communications are inadequate. The interoperability puzzle is solved by first resolving operational communications needs. Before moving on to Part II, which focuses on how interoperability is achieved, we want to emphasize the importance of beginning with an operational perspective. We’ll look at some of the operational lessons learned during the 9/11 attacks and conclude with how standardized incident management systems provide tools to battle both operational and interoperability challenges. A Proportional Perspective In trying to understand what communications interoperability is and how it relates to daily requirements, it’s important to note that radio is first and foremost used for delivering services day-by-day to Mrs. Smith. Her emergency services are primarily provided by local agencies—usually by a single one for any given call. Consequently, the lion’s share of public safety radio communications take place internally between units of individual local agencies. Operations, particularly the intersection of operational responsibilities between agencies, drives interoperability needs. That is, two agencies responsible for providing services at the same place and time need to work together to serve their missions. See Figure 3-1. However, internal agency communications demands overshadow interagency requirements even in large incidents because the bulk of traffic is still tactical within responding units, typically from the same agency. In terms of sheer volume, communications demands across all types of public safety response stack up like this: 1. Internal communications within individual local agencies. 2. Interagency communications between like agencies from adjoining jurisdictions, such as between city police and county sheriff or between neighboring fire companies. 3. Interagency communications between different types of responders, such as police and fire, in the same jurisdiction. Chapter 3: Operability—Job #1 37 4. Interagency communications between different types of responders in neighboring or distant jurisdictions. Image of Operations Drive Interoperability Needs This isn’t to say that any particular type of radio exchange is insignificant or expendable. It is important to note, however, that day-to-day internal communications needs drive requirements for radio systems. After all, there’s no need to interoperate if you can’t operate to begin with! While this might seem obvious, we’ve seen plenty of technology projects where basic needs are forgotten in the rush to find a “silver bullet” for a smaller set of problems. It simply boils down to the fact that internal operational needs are appropriately the central focus of agency radio projects. However, those needs can be defined, satisfied, and incorporated into standard operating procedures (SOP) while assuring interoperability, as we’ll see shortly. Extreme Operations—9/11 A great deal has been written about emergency response in New York City during the World Trade Center attacks of September 11. In the year following the attacks, the New York Police Department (NYPD) and the Fire Department of New York (FDNY) collaborated with McKinsey & Company, business and organizational performance consultants, to produce reports on improving the agencies’ preparedness. Though the reports contain much information on response during the incidents and detailed recommendations, we just want to touch on operational communications aspects they addressed. Part I: What Is Communications Interoperability? 38 At the time of the attacks, the NYPD was operating with a new radio system that offered great capacity and resiliency over its previous systems. The police system also was significantly more modern than the FDNY’s, which had been struggling to implement a new one of its own. According to McKinsey & Company, the police department’s radio infrastructure did not fail on 9/11. Less than 15 percent of responding officers reported experiencing “dead air” failures. On the other hand, radio traffic was “cluttered” early in the incident. Fewer than half of the officers reported being able to clearly decipher traffic early on. Image of 9/11 Ribbon One of six critical recommendations made to the NYPD focused on its radio communications. It recommended adoption of radio procedures that optimized information flow, producing a radio discipline that would minimize demand for channels and provide a capability to push critical information ahead of other traffic.9 FDNY communications were affected directly by the attacks themselves. Overall, their radio system was inadequate for the scale of the incident. McKinsey & Company found that the department urgently needed to improve its communications capabilities and ability to pass critical incident information. Information management improvements were also noted as urgently needed, particularly in tracking responders and patients.10 Important Conclusions Two important conclusions can be drawn from these findings: Conclusion #1: An agency’s internal operational capacity to receive, digest, disseminate, and act on information can be overwhelmed, even if technically its communications systems aren’t. Operability is directly affected by nontechnical pieces of response systems that define, among other things, rules for moving information around and what constitutes a manageable span of control. Technology can deliver information overload as well as it can solve problems. Conclusion #2: The great bulk of information sharing needs between first responders—and thus communications capacity of one form or another—are internal. 9 Improving NYPD Emergency Preparedness and Response, McKinsey & Company, August 19, 2002. Available at http://www.nyc.gov/html/nypd/pdf/nypdemergency.pdf. 10 Increasing FDNY’s Preparedness, Executive Summary, McKinsey & Company, August 19, 2002. Available at http://www.nyc.gov/html/fdny/html/mck_report/toc.shtml. Chapter 3: Operability—Job #1 39 Judging from these reports, communications operability was a greater problem in New York City on 9/11 than interoperability. We believe this would be true in most any jurisdiction under comparably taxing circumstances, mainly because the agencies’ own management needs become critical as they struggle to maintain a manageable span of control and accountability of responders. National Incident Management System Procedures for day-to-day interagency operations are usually well-established. Thankfully, national disasters of this magnitude are rare. Terrorist attacks and weapons of mass destruction have captured the nation’s attention, but natural disasters and large-scale emergencies like wildland fires and hazardous materials incidents are more likely across the country. Communications operability and interoperability needs have to be accommodated to support response to all scales of emergencies. Incident response systems have been built to meet the daily public safety demands, as well as the more predictable emergencies. Incident management systems vary widely across the country, but procedures for day-to-day interagency operations are usually well-established because they’re used relatively often. Similarly, planned events and task force operations, such as political conventions or joint drug interdiction efforts, give incident command teams the opportunity to build solid plans beforehand. This includes plans necessary for interagency communications. But when large-scale emergencies and disasters occur, response and communications systems are stressed. Informal incident management systems dissolve. The National Incident Management System (NIMS) was introduced in March 2004. It is first and foremost a common set of concepts, principles, terminology, and technology to improve emergency response. It also provides standard resource, organizational, and operational definitions. One of its components is an incident command system familiar to many first responders across the country. The NIMS Incident Command System (ICS) is built from 30 years of experience with large-scale emergencies. Based on military models, early incident command systems emerged in the public safety world through efforts of California firefighting and emergency management agencies to deal with devastating wildfires. It broadened and evolved over the years to serve emergencies and disasters of all types. Two key ICS management characteristics are particularly notable when it comes to communications interoperability. NIMS ICS is based on: Part I: What Is Communications Interoperability? 40 Interoperability is built upon common terminology. 1. Common terminology covering organizational structures, operational resources, and facilities. 2. Integrated communications, including development and use of a common communications plan covering processes and technology.11 Common Terminology Common terminology is clearly important in interagency communications since it’s not much use to talk to your cooperating neighbors if you can’t understand them! But the concept goes much further. As mentioned earlier, lack of planning and coordination is a prime cause of communications interoperability failures. Planning and coordination requires a common language to articulate needs, describe processes, establish policies, craft joint SOPs, and command resources during interagency operations. Interagency communications SOPs are particularly unlikely without a means of describing the “who, when, why, where, what, and how” of operations. We deal with practical and important aspects of common terminology in Chapter 12, Develop Policies and Procedures. Integrated Communications How we play at the occasional “big one” will be determined mostly by how we play at the frequent little ones that occur every day in our local place. — Fire Command Chief Alan Brunacini, Phoenix (Arizona) Fire Department Under ICS, communications and incident action plans have to be integrated to capture management goals and operational objectives. This notion of integration is more than just lip service, too. Since responder safety and effectiveness are usually closely related to how well communications supports them, the capacity of the communications systems to support operations is continuously taken into account in action planning. A separate communications unit is often established early in multiagency and large-scale responses managed under ICS to support the integration effort. This is to bring all communications functions close to incident management, rather than having them managed far from pressing operational considerations. Communications plans and technology can be used to reinforce the command structures and operating principles embodied in incident management systems. Use of a NIMS-compliant incident command system is critical in large-scale response. It can be equally important during smaller emergencies that provide the opportunity 11 National Incident Management System, U.S. Department of Homeland Security, March 2004. Available at http://www.fema.gov/pdf/nims/nims_doc_full.pdf. Chapter 3: Operability—Job #1 41 to perfect response. Common terminologies and principles of communications integration take root in routine response. They provide the building blocks of interoperability through better operability. Operational Building Blocks Interoperability is built up from separately operable systems. It’s a defining quality of a system of systems. For example, the modularity and scalability of modern incident command systems mean they are useful from small incidents to large-scale emergencies. Separate command teams can even be folded into one as incidents merge. Components can be mixed and matched as demands ebb and flow. See Figure 3-2. Communications systems meant to serve such command systems have to be equally modular and scalable. Those capable of supporting an agency’s operations have to be built to “plug and play” during multiagency responses, so it pays to build them with NIMS principles in mind. While operations come first, interoperations are inevitable. Building command and communications systems for interoperability across jurisdictions and disciplines is just good business. Image of Flowchart indicating parts to be added with increasing magnitude of event, requiring more complex administration Figure 3-2: Interoperability Built on Separately Operable Systems Source: U.S. Department of Homeland Security, SAFECOM Program Chapter 4: Interoperability in the Integrated Enterprise Readers may be interested in Chicago’s burgeoning enterprise criminal justice information system. See Policing Smarter Through IT: Lessons in Enterprise Implementation, northwestern University, U.S. Department of Justice Office of Community Oriented Policing Services, 2004. See http://www.cops. usdoj.gov/default. asp?Item=1331. Public safety services are provided across all levels of government, through local, tribal, state, and federal agencies. The vast majority of existing communications infrastructure for delivery of these systems, however, is owned by local and state agencies—an ownership level estimated at more than 90 percent.12 Cities, towns, and counties use their systems to provide essential police, fire, and EMS services at all hours of the day, every day of the year. For the most part, it seems that public satisfaction with these services is good, but there is certainly the expectation that agencies can work together when needed—in effect, that they’re interoperable. To understand the demand for interoperability, we have to look at a picture of emergency services greater than individual agencies and their separate responsibilities. In wrapping up our discussion of just what communications interoperability is, we want to describe the public safety enterprise, its complexity across systems, and what integrating it entails. We’ll look at why information sharing is at the heart of communications interoperability, how justice integration efforts laid a foundation for understanding needs, and the importance of stating functional and operational requirements to integrate systems. Your contribution to achieving interoperability is our central focus, so we’ll conclude by looking at the role of leadership in the integrated enterprise. What is the “Enterprise”? An enterprise is a collection of agencies or organizations created to provide related services to a common set of customers. The term “enterprise” is more and more commonly used to describe government and individual agencies organized to deliver particular services. For example, we speak of police, prosecution, courts, and corrections across local, tribal, state, and federal levels of government as the justice enterprise. Recognizing that each level of government and most of its branches are defined in law, it still has been useful to look at justice agencies as a single entity dealing with a related set of services for a common constituency. Integration of services and technologies across the justice enterprise allows each agency to better serve its customers, while minimizing costly redundancies and technological roadblocks. 12 U.S. Government Accountability Office, Homeland Security: Federal Leadership and Intergovernmental Cooperation Required to Achieve First Responder Interoperable Communications, GAO- 04-740 (Washington, D.C.: July 2004) p. 8. 46 Part I: What Is Communications Interoperability? FACTS: • Interoperability is achieved when services are delivered seamlessly across organizational subdivisions and between jurisdictions. • An enterprise view of public safety services—for example, across a city, county, or metropolitan region—uses a citizen-centered, results-focused definition of services provided to define, among other things, necessary interagency information exchanges. • With services and these interagency junction points defined, a technological framework can be built that leverages existing investments and capabilities, reduces redundancies, and establishes de facto standards for future systems. • Both services and supporting systems have to be integrated for the public safety enterprise to have communications interoperability. A Complex System of Systems All the policies, procedures, skills, and technologies that go into delivering effective emergency response need to come together at that moment, at that spot. Modern agencies have a staggering array of systems supporting their services. How complex? Consider a typical call that’s handled thousands of times each day across the country: A landline telephone call reporting a motor vehicle accident with injuries. The Call Arrives From the 9-1-1 call, an automatic call distributor may first direct the connection to an open attendant position, providing automatic number identification (ANI) information from the call. In the background, call-logging recorders track the source, routing, and conversations. An instant playback recorder may begin to capture the conversation for the operator’s subsequent use while an audio logging recorder elsewhere makes a more permanent record. Where enhanced 9-1-1 (E9-1-1) is available, the caller’s address is automatically retrieved and provided to the operator. The call to the public safety answering point (PSAP) is then either dispatched by the operator or transferred to a dispatcher across the room or perhaps even across town. And that’s all before response is initiated. E9-1-1, ANI, ALI, PSAP, MSAG... there’s certainly no shortage of acronyms in the public safety communications business! Wait, there’s more. These acronyms and others are defined in Appendix F. The Call is Dispatched If the call-taker hasn’t already done so, the incident might automatically be queued to a computer-aided dispatch (CAD) system at this point—or maybe even separate CAD systems for fire medical and police response. The CAD system itself is a complex animal. From this point, it may interface through a general purpose console with telephone, alarm, paging, voice radio, mobile data, and logging systems. It might be fed mapping information in the background for geographic display of call source, responder location, and street closure indications. For later use, it might feed incident information to an agency’s records management system (RMS) or simply drive a run card printer in a distant fire station. First Responders Respond From dispatch, let’s imagine that fire medical responders are alerted by a page and police officers by a message sent wirelessly to the squad car’s mobile data computer. Fire paramedics grab the run card, jump in their vehicle, and transmit acknowledgment of the call over a voice radio system. By way of a couple of key presses, the police officer acknowledges receipt of the alert and notifies dispatch of an impending response with lights and siren. En route, automatic vehicle location (AVL) systems in each unit transmit current location information to dispatch from a Global Positioning System (GPS) receiver for display on a geographic information system (GIS)-powered map in dispatch. On scene, the officer quickly transmits an arrival status message and turns to a shared radio channel to direct paramedics in from an alternate direction because the roadway is blocked by backed-up traffic. Service is Delivered Response is well underway, with a great deal of technology enabling it. A transporting ambulance may have been dispatched by this point and street maintenance alerted to divert traffic around the accident. Medical control may have been established through a nearby hospital and its emergency room notified of the impending arrival of patients. More systems are tied in. Eventually patients are delivered, cars towed, accident and run reports filed, and responders returned to routine duties. This complex system of emergency services is linked through an integrated mesh of communications and information systems. The hapless victims of our hypothetical accident don’t know—and probably don’t care at the time—about all that goes into delivering emergency services to them. All they know is that they need help. All the policies, procedures, skills, and technologies that are involved in delivering effective emergency response need to come together at that moment, and at that spot. Part I: What Is Communications Interoperability? 48 Enterprise Integration This example provides a snapshot of the public safety enterprise. It shows the complexity of technologies used to support emergency operations generally, and interagency operations in particular. Information flowing across wired and wireless networks, through computers and voice systems, allows interagency services to be delivered seamlessly. It allows them to be integrated across the public safety enterprise. Information is moved from place to place through different systems and modes of sharing. For example, the location of this hypothetical incident most likely would have initially been reported by voice over the telephone. Nearly simultaneously, the call-taker received an idea of the general vicinity of the accident from the caller’s location information retrieved digitally with the call. That street address was displayed textually and later, perhaps, also graphically for the dispatcher. More and more commonly these days, a precise location may have been automatically transmitted wirelessly via satellite by one of the involved vehicles, and then relayed via telephone to dispatch by a telematics operator, such as OnStar.® In our example, the incident location was subsequently passed wirelessly to the field using both voice and data. When communications break down, who are you going to call? 9-1-1? Perhaps you have already faced the challenge of integrating systems to deliver information so complexly. If so, you’re one step up on the broader challenge of providing communications interoperability. You understand that a lot more than technology goes into making systems talk to one another. And if you’ve been responsible for connecting services across agencies, you probably already recognize that no amount of interoperable technology will bring responders together when their operations are fragmented. All the king’s horses and all the king’s men can’t make one response out of many if procedurally agencies aren’t “interoperational” already. This, quite frankly, has nothing to do with technology. How Did Communicating Get so Complicated? Historically, communications interoperability has diminished as technology has advanced. This might seem counterintuitive, but think about it. When there were few choices for communications technology, the odds of any two agencies having compatible technology were relatively high. Advancing technology, which brought more communications choices, has come up against long radio system lifecycles and widely varying needs. Agencies have built advanced radio systems to solve serious coverage and capacity needs, inadvertently introducing new interoperability challenges. In effect, our technological options have expanded, spotlighting the “disintegrated” enterprise that previously had been able to hang together due to fewer demands and greater technological homogeneity. Chapter 4: Interoperability in the Integrated Enterprise 49 As noted earlier, aging and incompatible equipment is just one of several challenges to achieving interoperability. Suffice it here to say that a lot more than technology is needed for success. Recent events and disasters have highlighted greater needs for sharing information and coordinating incident management across all emergency services. This requires communications interoperability. Ultimately, an enterprise view of services integrated across procedures and technology is necessary to satisfy these needs. A Vision of Information Sharing Information sharing is a measurable outcome of communications interoperability. On a daily basis, critical information most often passes between first responders by voice over radio. It can also originate from CAD, RMS, GIS, disaster management, state motor vehicle, and other systems. From these systems, the information may be transferred to the first responder wirelessly to a mobile computer system or it may make the leap from mere data to true information through the time-proven radioed voice of dispatch. In the public sector, some of the greatest advancements in information sharing have occurred through the U.S. Department of Justice’s Office of Justice Programs and its Global Justice Information Sharing Initiative—generally referred to simply as “Global.” The Global Advisory Committee (GAC) has served as an advisory body to the U.S. Attorney General since 1998. Its mission is to support broad exchange of justice information across jurisdictions and levels of government. It “seeks to improve the administration of justice and protect the nation’s public by promoting practices and technologies for the secure sharing of justice information.” 13 Since September 11, Global’s scope of advice has expanded to the broader public safety enterprise. For example, the Global Justice XML Data Model14 has had a significant impact on how CAD and RMS are being designed for information sharing. Information-sharing concepts have evolved greatly through efforts to integrate justice systems. Global has provided a simple vision of information sharing that is very applicable to communications interoperability. 13 Global Justice Information Sharing Initiative Advisory Committee Charter, October 15, 2002. 14 For further information on the Global Justice XML Data Model, see the U.S. Department of Justice, Office of Justice Programs web site at http://it.ojp.gov/jxdm/. Part I: What Is Communications Interoperability? 50 Sample Vision Statement Emergency responders can access the information they need to do their jobs, at the time they need it, in a form that is useful, regardless of its location.15 Such a vision would be followed by more specific goals laying out how the project will improve procedures and systems to ensure that the needed information is shared. The Global Infrastructure/Standards Working Group has established requirements for justice information sharing16 that are equally applicable to interoperable communications systems: • The architecture must recognize innumerable independent agencies and funding bodies from local, state, tribal, and federal governments. • Information sharing must occur across agencies that represent divergent disciplines, branches of government, and operating assumptions. • The infrastructure must be able to accommodate an infinite range of scales, from small operations with few participants in a rural county to national processes that reach across local, state, tribal, federal, and even international boundaries. • Information sharing must occur among data sources that differ widely in software, hardware, structure, and design. [And uniforms worn, we might add. – Ed.] • Public-sector technology investment must reflect and incorporate the lessons and developments of the private sector. • The infrastructure design must be dynamic, capable of evolving as the information sharing requirements change and the technology is transformed. These are worthy strategic goals for all communications interoperability projects. Information Sharing Concepts: SOA What? For such a simple term, “information sharing” can be a complex subject. Some of the concepts and terms are simply too important to pass up, though. Notions of communications interoperability are being influenced by lessons learned through justice integration efforts, and familiarity with these ideas will help you understand the “big picture.” 15 Adapted from A Framework for Justice Information Sharing: Service-Oriented Architecture (SOA), Global Infrastructure/Standards Working Group, December 9, 2004. Available at http://it.ojp.gov/documents/20041209_SOA_Report.pdf. 16 Ibid., pp. 2–7. Chapter 4: Interoperability in the Integrated Enterprise 51 For example, work conducted by SEARCH in recent years in the field of justice information exchange modeling has produced a conceptual framework for understanding the flow of information between agencies, a methodology for analyzing and reengineering processes, and tools for modeling information exchanges. Work is now underway using these means for characterizing, classifying, and quantifying first responder interagency communications.17 One goal of the modeling methodology is to produce a reference model—a set of exchanges common across most jurisdictions. This has been done for integrated justice information systems, resulting in a significant savings in effort and cost for subsequent users. Such a model can be customized by individual jurisdictions to reflect their operations, as-is, and portray their systems to-be, requiring a fraction of the effort needed to create one from scratch. Common Terminology Aids Communication Shared concepts and terminology have advanced the abilities of researchers and practitioners, alike, to describe dimensions and modes of information exchange.18 In addressing functional components of integration, we now talk about query, push, pull, publish, and subscription/notification modes of communications. In integrated systems, queries make a specific request for information. Information is pushed automatically to other systems following triggering events. Likewise, it may be automatically pulled from others in anticipation of need. Information is published for general authorized consumption as a proactive measure. A subscription/ notification process combines push and pull modes of information sharing on a more ad hoc basis controlled by the eventual user. The importance of these terms and concepts is not so much that they bring some great revelation of how we might share information, but rather in providing a common terminology useful for stating requirements in a standardized manner through which a system of systems can be designed. For example, we may require that 17 SEARCH has undertaken two projects to develop information exchange package documentation for tribal, law enforcement, and other first responders. These projects were funded by the COPS Office under Cooperative Agreements #2002CKWXK006 and #2002CKWXK047. For a description, see http://www.search.org/programs/info/xml-iep.asp. 18 Roberts, David J., Integration in the Context of Justice Information Systems: A Common Understanding (Sacramento, Ca.: SEARCH, The National Consortium for Justice Information and Statistics, updated 2004). Available at http://www.search.org/files/pdf/Integration.pdf. Part I: What Is Communications Interoperability? 52 stolen vehicle information is pushed to an officer whenever a traffic stop is made. That tells a business process analyst or system designer that certain exchanges are required without further, overt action by the officer. However the information is ultimately provided—whether it is wrapped in standard operating procedures by voice from dispatch or encoded in the rules of a mobile data system—is a subsequent matter of design, and is probably influenced by additional requirements. Service-oriented architecture (SOA) is a collection of services that communicate with one another. A final concept of growing importance in justice integration, as well as the larger world of automation, is service-oriented architecture (SOA). Properly speaking, it is simply a collection of services that communicate with one another. Most generally used in the design of web-based information systems, SOA includes the concept that well-defined services are able to find and work with one another using standardized means of communications. For example, Wisconsin is already using an SOA-based message switch to move information from different sources to and between law enforcement agencies across the state. 19 SOA means a great deal more in the design of integrated systems than is addressed here, but its influence on developing enterprise information systems is important. Public safety information and communications systems will increasingly be built upon SOA, as broader governmental systems are today. The integrated enterprise increasingly relies on this architectural framework. These accepted guiding principles of integrated justice information systems influence our conception of what’s possible with communications interoperability: • Information exchange modeling • Functional components of integration • Service-oriented architecture. They can help us understand information sharing needs across a complex enterprise to achieve interoperability. 19 See http://www.doj.state.wi.us/les/TIME/eTIME.htm. Chapter 4: Interoperability in the Integrated Enterprise 53 Stating Requirements for Information Sharing When information sharing works, it is a powerful tool. —The 9/11 Commission report (Page 419) Our success in creating communications interoperability is directly related to our ability to describe operational requirements for interagency exchange of information. Projects to improve interoperability may be well-guided from the start with a broad vision statement, such as that presented above, but they have to develop operational and functional requirements to yield communications systems that meet day-to-day needs. Unfortunately, system procurement documents often focus on technical requirements rather than operational needs, which limits proposed solutions and forces acceptance merely based on technological measures. In seeking to improve interoperability, we talk about police department ‘A’ needing to talk to fire department ‘B’ or something similarly broad. Left with no better description of the processes, events, conditions, and content of the needed communications, system designers get a one-dimensional picture of what’s needed. Interoperable systems design is driven much more by operational requirements when, for example, the need is described as follows: During a barricaded suspect operation, the police tactical team leader notifies the fire interior attack crew leader that suppression efforts are needed within a secured portion of the building. Our success in creating communications interoperability is directly related to our ability to describe the operational requirements for interagency exchange of information. It may seem obvious that the need would be satisfied by a common radio channel or talkgroup readily available for a voice exchange between portable radios. That may be the most common way to carry the exchange today, but it may be equally well accomplished by status and location data burst across a network established just for the incident. Over-specification of how needs are met ends up limiting options and is often used as a substitute for a clear statement of business practices. The point is that the “how” should come long after operational and functional requirements are established. It may also seem that describing interagency communications needs in such detail could be painfully tedious. Frankly, it can be. Unfortunately, the likely alternative is acquiring systems that are designed based on gross and largely unshared assumptions of the “who, what, when, why, and how often” aspects of interoperability. If procedures don’t exist to describe how police operations communicate a need for help when a diversionary device ignites a fire, then the presence of the technological capability to talk is unlikely to be used effectively. Broad statements of need that lack functional and operational requirements often result in technology project failures. Part I: What Is Communications Interoperability? 54 Efforts in information exchange modeling have shown that voice communications are not as neatly describable as data exchanges. But because voice and data are so intimately intertwined in the integrated enterprise, we’re called to do our best in describing all types of exchanges so the boundaries between different modes of communications are clear. As important, voice exchanges may prompt subsequent data exchanges under certain conditions and vice versa. It’s important to recognize these interactions—at least in operational procedures, if not also in technology. The Good News on Stating Requirements A good deal of work in recent years has been done to both define information sharing requirements broadly, and to improve our understanding of them. In March 2004, SAFECOM released a report establishing current and future requirements for public safety wireless communications and interoperability. This “Statement of Requirements” (SOR) established operational requirements for police, fire, and EMS services, as well as their wireless communications functional requirements. An updated version was released in January 2006.20 The SOR is a foundational document describing current and future requirements to the year 2019. We’ll turn to it for more detail in Chapter 6, Conduct a Needs Analysis. Despite the problems that technology creates, Americans’ love affair with it leads them to also regard it as the solution. But technology produces its best results when an organization has the doctrine, structure, and incentives to exploit it. — The 9/11 Commission report (Page 88) Leadership Rules Integrating the enterprise for interoperability sounds daunting, doesn’t it? It can be—and often is. The interoperability landscape is littered with a landfill’s worth of acronyms camouflaging a confusing jumble of bits, bytes, megahertz, and gamma rays. Agency managers looking at the challenge of integrating a larger enterprise for interoperability often exercise the first prerogative of management: Delegation! It’s a mistake, however, to allow a fascination with technology to overrun the agency’s business headlights. Public safety practitioners have enough problems to deal with daily without technology adding new ones. Their collective job is to deliver solutions to people in need, not carry a load of battery-powered problems along for the ride. 20 U.S. Department of Homeland Security, SAFECOM Program, Statement of Requirements for Public Safety Wireless Communications and Interoperability (Washington, D.C.: Version 1.1, January 26, 2006). Available at http://www.safecomprogram.gov/SAFECOM/library/ technology/1258_statementof.htm. Chapter 4: Interoperability in the Integrated Enterprise 55 Corporations and other large organizations with clear visions of their missions have long grappled with the problem of technology growing to be an end in itself. They’ve established the roles of chief information officer (CIO) and chief technology officer (CTO) as upper-management positions with responsibility for ensuring that technology directly and measurably serves the mission. Those positions bear the responsibility of understanding the business so well that no effort is wasted in putting technology to work. It’s rare in public safety to see the CIO or CTO role formally designated by name. Whether so titled or not, the role of the chief officer responsible for information technology, including the inseparable communications that make information sharing possible, is simple. First, it is to be focused on the organization’s mission. If that officer succumbs to the siren songs of technology wizards and vendors, focus is lost. Chapter 15, Measuring Interoperability, delves into performance measures. If only you could spec, buy, and install a system that ran indefinitely with a minimum of care and feeding, life would be simpler. Or at least work would be simpler. By their very nature, complex systems used for sharing information within and between public safety agencies are increasingly evolutionary. That is, they grow, changing over time. Understanding your needs is key to success. See the Big Picture Original Tech Guide Icon, page 67 Chapter 4 of the Law Enforcement Tech Guide is devoted entirely to assessing current business processes for all technology projects. In Chapter 6 of this Communications Interoperability Tech Guide, Conduct a Needs Analysis, we will provide tools specifically targeted for planning communications interoperability projects. If all this business about integration, enterprise, and architecture seems a bit abstract when all you came to do was make sure your police, fire, and EMS agencies can talk together—well, okay, it is a bit. But consider how complex these systems can be, especially when you start lashing them together (see Figure 4-1 on page 58). And consider that many big, well-funded projects have become lost in a forest of technologies because the ultimate requirements were forgotten or never even recorded. Out of respect for our colleagues around the country, we’re not going to name names—and we promise the same to you! Just don’t forget the big picture. In the following chapters, we’ll get into just how this elephant can be eaten one piece at a time . Step by step, interoperability can be achieved if it is built on a solid foundation. Part I: What Is Communications Interoperability? 56 Integrated Systems at Work in 2002 Wildfire Disaster The devastating 2002 wildfire season in the western United States included the largest in Colorado history, a blaze that threatened Denver suburbs and seriously damaged the primary watershed providing its municipal supply. The Hayman Fire* originated in the mountains west of Colorado Springs near lake George. It burned actively for 20 days, involved 138,000 acres, burned 132 homes, cost an estimated $28 million to suppress, and an additional $13.3 million for rehabilitation of the burn area in efforts to save the critical watershed. A U.S. Forest Service employee was implicated and later pled guilty to arson for starting the fire. Geographic information systems (GIS) played an important part in this emergency, as the technology has in many wildland fires of recent years. Managers of these large and often dramatic incidents rely on the graphic and analytic power of GIS for many facets of their work, from pre-incident response planning through initial and sustained attacks, and on to burn area rehabilitation. Image of man with helicopter in background. Caption reads A variety of cooperators were involved in providing operational support to the Hayman Fire. ©2002 Kenneth Wyatt, www.wyattphoto.com Image of portable satellite truck. Caption reads Satellite links to the Internet enabled the wireless transfer of field and planning data. Photo courtesy of netWest Communications Group, Inc. The Hayman Fire was large and threatening enough to bring a well-equipped GIS crew in a camp trailer that operated from 18 to 24 hours a day, every day for more than 2 months. Two analysts typically worked long hours collecting data from and distributing data to field units, the incident command team, and then to outside cooperators who kept the public and key external decision makers informed through web sites and more traditional media. A great deal of time was *Note: The author of this Guide was lead GIS specialist for 2 weeks on the Hayman Fire. Chapter 4: Interoperability in the Integrated Enterprise 57 spent with more uncommon cooperators in wildland fire response, such as arson investigators, public water supply authorities, wildlife management teams, and burn area rehabilitation contractors. The 2002 fire season may have been the first to see bidirectional transfer of GIS data wirelessly for continuous operational purposes. According to Burn Area Evaluation and Rehabilitation (BAER) teams that worked the Hayman Fire, this was the first time that information was transferred back and forth on a daily basis to contractors for management of reseeding efforts. The fire severely damaged Denver’s primary watershed, putting it at great risk from post-fire erosion sedimentation. Consequently, scarification of the incinerated watershed and reseeding was critical. Image of team looking at maps. Caption reads A well-equipped GIS crew supported critical information sharing between field units, the incident command team, and others. ©2002 Kenneth Wyatt, www.wyattphoto.com Aerial reseeding is an intensive and expensive process. The Hayman GIS trailer used its satellite link to the Internet to transfer field and planning information wirelessly to contractors who were immediately able to incorporate it into their own navigational systems for subsequent passes through the area. The power of GIS analysis, combined with an ability to transmit large amounts of information wirelessly over wideband links, allowed BAEr teams to communicate in intricate detail where they needed different types of reseeding. This would not have been possible through traditional means of information sharing from remote locations. Part I: What Is Communications Interoperability? 58 Image of multiple systems coordinating Figure 4-1: Systems Galore Part II: How is Interoperability Achieved? If you have built castles in the air, your work need not be lost; that is where they should be. Now put the foundations under them. — Henry David Thoreau Chapter 5: Build an Interagency Foundation What Communications interoperability projects and initiatives are like houses built for an extended family. They have to be built on a solid foundation. Your foundation will be poured in the form of a decision-making structure, project management, and a charter for shaping partnerships. Why As with building a home, the stability and longevity of your initiative depends on a foundation of leadership, cooperation, management, and consensus, which must be built from the start. Who Agency executives and senior managers build these foundations. Only they can provide the leadership necessary to articulate a vision and carry out the project. They have the responsibility to set agency or jurisdiction goals and the authority to commit human and financial resources. When Immediately, before disaster strikes or money is spent to solve an ill-defined problem. Delaying this strategic step endangers all other parts of the project. Part II of this Guide is intended to provide a step-by-step process and tools for your interoperability project. This and the following five chapters mirror parts of the original Law Enforcement Tech Guide with a specific focus on the special, often challenging, aspects of interagency communications projects. The final chapter of Part II offers ideas and current best practices for measuring communications interoperability that you will find useful in gauging progress toward making sure radio is an enabling, rather than disabling, technology for public safety. This chapter presumes you are starting or managing a communications interoperability initiative focused on improving the delivery of your agency’s services that entail cooperating with other agencies. Your project is probably part of or influenced by larger interoperability initiatives—maybe within your own jurisdiction, but very likely in nearby ones, elsewhere across the state, and even nationally. Build your interoperability project foundation as follows: • Establish a decision-making structure • Hire or assign a project manager • Develop a project charter. We’ll deal with these step-by-step. Part II: How Is Interoperability Achieved? 64 He who has not first laid his foundations may be able with great ability to lay them afterwards, but they will be laid with trouble to the architect and danger to the building. —Niccolo Machiavelli Projects to improve communications interoperability are fundamentally multiagency in nature. Before we get into these pieces of your project’s foundation one by one, consider what’s at the heart of multiagency, regional projects. The Heart of It: Partnerships, Planning, and More Partnerships Consider the analogy of interoperability as the house your extended family chooses to live in for everyone’s mutual benefit. Now, before that scares you off, consider that economic or other necessities make this not only unavoidable, but desirable for all involved. If you were building that house, you would have to start with deciding how you are going to live with each other—setting rules of engagement, some might say. Each party’s private space (jurisdiction, responsibilities) would have to be respected and accommodated. Your common space (interoperations) would have to be carefully planned to meet everyone’s needs to live together without dysfunction (without disabling needed internal command, control, and communications). Regional Icon Before this analogy causes you to run screaming away from your interoperability project, think what a challenge building that house would be. Think about the interagency communications challenges (and successes!) that you have today, how hard it will be to improve interoperability without partnerships and some serious planning, and the level of cooperation necessary to keep that household together long after it’s built. Interoperability is co-operating. Interoperability is the ability to work together. It is conducting effective joint operations. It is co-operating. Men often oppose a thing merely because they have had no agency in planning it, or because it may have been planned by those whom they dislike. —Alexander Hamilton Foundations 101: Decision-Making Structure The decision-making structure for your interoperability project provides leadership and accountability. It defines the joint business of agencies that unite in a project to improve communications between their operations. It ensures that the project is effectively managed, and meets identified goals in a timely and cost-effective manner. When you officially create a structure and announce it to internal and external stakeholders, you’ve drawn an organizational blueprint for building a house that is respectful of individual agencies’ roles and responsibilities, yet allows each agency the communications necessary for cooperation. Chapter 5: Build an Interagency Foundation 65 PROCESS – PROjECT – PROCESS The term “governance” is sometimes used to describe a decision-making structure. Most appropriately, governance is the body or organizational structure guiding a larger interoperability process, as opposed to a specific project. For example, a multijurisdictional region may have an overarching initiative to improve communications interoperability. Or a state may have an interoperability executive committee (SIEC). Within those processes, there may be multiple projects being undertaken by a variety of involved partners. We use the term “decision-making structure” here specifically for projects that have an identifiable beginning and end. Governance bodies generally serve ongoing initiatives or oversee management of multiagency systems after implementation. Processes to improve interoperability lead to projects and back to processes for managing underlying systems—organizational and technical —over their lifecycles. As systems become long in the tooth, processes to improve them arise again. Follow these six steps to create your project decision-making structure: 1. Identify Executive Sponsorship. 2. Identify Stakeholders. 3. Create the Structure. 4. Involve Other Subject Matter Experts. 5. Conduct Effective Meetings. 6. Decide on Project Staffing. We’ll explain later in this chapter how to wrap up all the details of these steps into a document—the project charter—to record everything for posterity and make it easy to share these keys to success with others. Step 1 Identify Executive Sponsorship Start your project by identifying the top champion (or champions) for the initiative. This person(s) defines what the project will achieve. You may be reading this Guide because you will be that champion. Or you may be in a steering function for your own agency, but know the project will need higher leadership to bring other agencies and jurisdictions to the table. Or maybe you’ve already been assigned to manage the project and recognize the importance of building this part of the foundation. Part II: How Is Interoperability Achieved? 66 Executive Sponsors Icon Executive sponsorship is best provided by a single individual ultimately responsible for services provided by core stakeholders. In many cases, that isn’t possible because interoperability projects involve multiple agencies, by definition, and often span legal jurisdictions. There either isn’t a single person with such responsibility or the project has to go on without the active, ongoing support of the single individual in that role (e.g., mayor, chief county executive, chair of a regional board). Tips Icon Identify three or fewer sponsors. Ideally, sponsorship is provided by three or fewer executives. The fewer, the better, from the perspective of leadership and decision-making. With too many sponsors, political factions are more likely to arise: city versus county, police versus fire, etc. There’s always a risk of parochial decision-making, of course, but the more people involved, the easier it is to duck responsibility for decisions. Accountability is key for sponsorship. This begs the question of who, exactly, are the core stakeholders? There’s no easy answer to that. You’ll have to make that decision. Remember this: There’s a difference between sponsorship and the project’s Steering Committee, which will have broader representation. Find sponsors with sufficient stake in the outcome to be able to lead from a position of authority, yet with the skill to draw others together. For example, we’re familiar with one major city whose director of homeland security oversees both the police and fire departments, has responsibility for emergency management, and has considerable interest in EMS. This person is a strong and natural executive sponsor for that city’s interoperability initiatives. Executive sponsors communicate vision. The executive sponsor’s key role is to communicate a vision. For communications interoperability, this vision paints a picture of what success looks like when radio seamlessly connects parts of an emergency response. For every project, there is a nugget, an acorn from which everything else grows. The sponsor’s main job is to regularly impart a succinct vision of success to all stakeholders. This vision is captured in the project charter. We’ll have more to say about the vision statement of your project charter near the end of this chapter. Chapter 5: Build an Interagency Foundation 67 Tips Icon INTEROPERABILITY SUMMIT In early May 2005, the U.S. Department of Justice (DOJ) convened a summit on communications interoperability. representatives from major projects and initiatives around the country came together for 2 days in Seattle to share lessons learned. Through discussion and consensus, some best practices were developed. Sponsorship - Get the right project sponsors by showing the public policy and political impact of problems to be solved. (See http://www.cops.usdoj.gov/Default.asp?Item=1495.) Step 2 Identify Stakeholders The process of identifying executive sponsorship leads directly into the next step: Identify stakeholders in this effort to improve interagency communications. Original Tech Guide Icon, page 24 The Law Enforcement Tech Guide provides a discussion of the internal and external stakeholders common to technology projects of all sorts—law enforcement and otherwise. Take a look in that Guide for some you may not have thought of! Your early efforts to identify stakeholders and consider their role in the project will pay dividends long after switches are flipped to warm the airwaves. Some have a central role in steering the project, some define critical requirements, and others decide whether the initiative thrives or dies on the vine. This is your first step in figuring out how to keep stakeholders informed and engaged from their respective realms of interest. Know thy stakeholders. Typical stakeholders for communications interoperability projects: • Field operations radio users • Field operations command staff • Fire, police, and EMS chief executive officers • Dispatch management • Technical support staff • Emergency management officials • Elected officials • Media • Public. Part II: How Is Interoperability Achieved? 68 Tips Icon We’ve heard from more than one region where organized labor groups were ignored as stakeholders—to the great detriment of the project. By contrast, we’ve also heard success stories where labor has been central in identifying needs and managing expectations—both of which are definite keys to project success! THE RELUCTANT STAKEHOLDER All stakeholders are going to be equally enthusiastic about this initiative to improve their interagency communications, right? Wrong. Most projects of any size “enjoy” a range of buy-in across the wide variety of stakeholders discussed here. From the comfortably noncommunicative to the incurably cynical to the painfully frugal, interoperability projects have their share of stakeholders who won’t wildly embrace change. It’s a big mistake to proceed by simply labeling these folks, pigeonholing them, and stacking committees with cheerleaders. We see this most frequently where a “solution” arises before problems are well understood. By bringing dissenters to the table, issues get aired and the group—as a whole— can make the commitment to move forward. Even those whose ideas or objections were considered and decided against have to acknowledge that a deliberative, consensual process delivered the results. Often enough, these folks understand real challenges that need to be faced. A good project manager can use the art of facilitation to move stakeholders from simply reacting, to problem solving, and on to creative choices. Plan to communicate with the public and media. These last two groups are increasingly identified as stakeholders. The profile and cost of radio projects, in general, has grown dramatically and public attention to interoperability problems is at an all-time high since September 11. Critical media attention is increasingly drawn to costly public technology failures, further influencing public perceptions. Less commonly recognized is growing opposition to new radio towers. The first time you plan to erect a new one in a residential neighborhood, you’ll learn about new stakeholders! If two men agree on everything, you may be sure that one of them is doing the thinking. —Lyndon B. Johnson Including the media and public in plans to honestly communicate the project’s goals, successes, and even failures is important to any high-profile project. Consider including representatives of each as ex officio members of your committees. Chapter 5: Build an Interagency Foundation 69 Step 3 Create the Structure The time has come to formalize your project’s decision-making structure. Doing so and making it widely known ensures all involved will know where responsibility and authority falls. Leadership and accountability roles are made clear, as are reporting roles. Original Tech Guide Icon, page 28 Figure 5-1 on page 70 is a typical structure for multiagency, multijurisdictional efforts. The different elements are discussed in detail in the Law Enforcement Tech Guide, but we’ll cover some twists common to communications interoperability projects. Steering Committee missteps with vendors can be costly—or worse. With executive sponsorship in place, a Steering Committee can begin to take form. Multiagency steering committees are like police interceptors or firefighting helicopters: They are high-performance tools that can lead to trouble if misused. Like any committee, the mix of members and their individual talents determine how well work proceeds. Members must have the authority to commit resources and the ability to work collaboratively. They must be strategic thinkers and comfortable managing the work of others. Ideally, Steering Committee members are adept with large procurements or can be made so through early committee work. Project management is the next piece of your decision-making structure. It is such a critical piece; we’ll talk about it in detail shortly. Original Tech Guide Icon, page 29 The final pieces depicted in the chart are two important working bodies—the User Committee and the Technical Committee—and perhaps several topic-focused work groups that will be created to address particular tasks and dissolved when they’re no longer needed. Users know best. The User (or operational) Committee is made up of stakeholders familiar with the business and operations of the agencies they represent. Some of the most effective committee members are line supervisors and managers of field resources. A shift sergeant or fire company commander is generally better in tune with intra- and interagency radio communications needs of their organization than anyone else. In some cases, individual officers, firefighters, and paramedics may have to translate their own experience to broader operational needs. The Technical Committee is charged with taking the project’s vision, folding in operational needs, and analyzing the current technical environment. Potential solutions may be examined to craft technical requirements for eventual procurement. Here, most of all, “requirements tunnel vision” has to be avoided because it can easily produce restrictive requirements that slip through into procurement documents, leading to bid protests about foregone conclusions. Part II: How Is Interoperability Achieved? 70 Avoid attention creep! We’ll discuss how to focus working committees and further flesh out their roles in Chapter 6, Conduct a Needs Analysis, and Chapter 7, Create a Project Plan. A caveat: Remember that each element of the decision-making structure has its own role, expertise, and responsibilities. Resist the idea that, for example, the Steering Committee collectively knows more about operations and technology than the working committees formed to address those issues. Use the decision-making structure to delegate responsibility and concentrate each group’s attention on its own role. Stop Sign Icon A classic sign of attention creep in radio projects is technology debates in the User Committee—or worse yet, in the Steering Committee. The former body should be focused on defining operational and business needs, and the latter on executing a shared vision, committing resources, and top- down management. Image of Decision-Making Structure flowchart Figure 5-1: Sample Decision-Making Structure Chapter 5: Build an Interagency Foundation 71 Tips Icon INTEROPERABILITY SUMMIT More notes from the U.S. DOJ Interoperability Summit Decision-Making Structure - Ensure committee members have authority to speak for their agencies. - Get buy-in from labor unions and ask them to recommend their own representatives. - Manage competing stakeholder demands between larger and smaller agencies by creating a balanced decision-making structure with documented conflict-resolution processes. Step 4 Involve Other Subject Matter Experts Outside subject matter experts can be involved in your decision-making structure at several levels. Some ideas: • Bring in organizational and strategic management experts early on to sit down with your Steering Committee and get it started on the right foot. • Ask representatives from outside projects or interoperability initiatives to address steering and working committee meetings. • Rely on legal and procurement expertise within your agencies or elsewhere in government to keep your project out of trouble. • Have incident management specialists work with your User Committee to define interagency communications needs in terms consistent with the National Incident Management System and its Incident Command System (ICS). • Use technology experts to help your Technical Committee frame available opportunities to use or extend existing infrastructure. Use free technical assistance resources. Consider the range of expertise that may be brought to bear on your project. You may have to hire new staff in some areas, but will likely find internal staff nearby who are involved in related projects and available to assist with yours. For example, organizational and project management expertise might be available within your stakeholder agencies or others outside of the project, such as other units of government. Help might also be available at no cost through federal assistance programs for public safety agencies. Part II: How Is Interoperability Achieved? 72 Grant requirements icon Nationally, both the U.S. Departments of Justice and Homeland Security maintain assistance programs that can be tapped at no cost. If your project will receive grant funding, talk with your assigned grant specialist for guidance on assistance that may be specifically available under the funding program. Network with peers. Some of these programs bring peers together for training. Whether you’re in a project sponsorship, management, or technical role, recognize that the opportunity to network with your peers can be tremendously valuable. There are others who may have faced and overcome challenges you’re up against right now. Some of the best and least expensive subject-matter expertise available to your project can come from peers in other jurisdictions. Take advantage of this broad and inexpensive resource. Consider asking them to address your committee meetings and share experiences. Step 5 Conduct Effective Meetings Original Tech Guide Icon, page 35 Use a trained facilitator early on. Meetings are inevitable, so you might as well make them effective. “Fun” meetings are something of an oxymoron, but there are ways to make them less dreadful. Food and refreshments always work, as do pleasant surroundings with plenty of space and good acoustics so people don’t struggle or become uncomfortable while helping the project move forward. The key to good meetings is organization and brevity. People resent their time being wasted and know intuitively when it’s happening. Consider using a trained meeting facilitator during initial group meetings to get them started on the right foot. If you’re the project manager, work carefully with the facilitator so he or she knows your goals, process, and group dynamics. Observe carefully and learn what you can do to make future meetings effective. The Law Enforcement Tech Guide provides some great tips for keeping your project on track by making the most of the inevitable meetings that most everyone dreads. These are rules that can be used in projects of all types. Step 6 Decide on Project Staffing Original Tech Guide Icon, page 37 The last step in establishing your project’s decision-making structure is one of the toughest: Decide how the project will be staffed and where resources are going to come from. Once again, the Law Enforcement Tech Guide provides most of what you need to know about staffing your technology project—whether it’s for communications interoperability, voice or data, or even for technology far outside the law enforcement business. Chapter 5: Build an Interagency Foundation 73 The bottom line is this: Don’t handicap your project—or worse—by ignoring the fact that managing an interoperability project of most any size is a lot of work! Multimillion-dollar communications projects are becoming increasingly common. One large, populous western state is considering building a multiagency communications system estimated to cost $5 billion. Project staffing for such a project would be immense! Consider this rule of thumb: Consulting services, including project management, will commonly take 10 to 15 percent of a technology project’s budget. Consider both how much organizational, process, and technical expertise you’ll need for this project and how much you have at hand. If you have all the expertise internally that will be needed, recognize that while you may not be spending that 10 to 15 percent, you will be taking resources worth that much from elsewhere in the agencies. Plan accordingly. Staff the project appropriately. Resist the temptation to save that 10 percent for more radios, sacrificing good management of all resources in the process. Foundations 102: Project Management “Management” means, in the last analysis, the substitution of thought for brawn and muscle, of knowledge for folklore and superstition, and of cooperation for force. . . —Peter F. Drucker Our discussion of project staffing leads to the next key ingredient of the project foundation mixture—project management. The choice is simple: You have to hire, assign, or train somebody to be the project manager. If the project will cost more than a few hundred thousand dollars, your practical choices are reduced to hiring an existing, experienced project manager or assigning one from within participating agencies. Assign inexperienced staff in larger projects at your own risk. No single person or function in a project has the potential to make or break success like the project manager. Because this person is a single point of contact between upper management, all work being done, and vendors, the project manager has great responsibility. The best project managers have an uncommon combination of business process, management, operations, procurement, and technical skills. Combined with distinct project management skills, they have the uncanny ability to assume temporary ownership of results, while delivering permanent ownership of final products to stakeholders. Good project managers make things happen, but don’t usurp the roles of others in the decision-making structure. Original Tech Guide Icon, page 43 The project manager’s responsibilities, skills, and personal attributes are well addressed in the Law Enforcement Tech Guide. Use that Guide as a practical tool regarding all the project manager’s responsibilities in a public safety technology project. Part II: How Is Interoperability Achieved? 74 Smaller jurisdictions, as a group, are slowest to hire or assign full-time project management. While other technology projects are often proportional to the size of the agency, radio projects generally aren’t. For example, a computer-aided dispatch system is simpler for a small agency than larger ones, requiring less project management. radio projects, on the other hand, are generally large and expensive—even for smaller jurisdictions. For specific guidance on small and rural agencies, you may want to refer to the Law Enforcement Tech Guide for Small and Rural Police Agencies (http:// www.cops.usdoj. gov/mime/open. pdf?Item=1619). Communications interoperability projects may be some of the most difficult to manage. They are typically: • Large, expensive projects • Inherently multiagency in nature, bringing inevitable conflict and compromise • Critical to the delivery of core services affecting life and death • Built using a variety of complex technologies • Involve civil construction and permitting • Require environmental, historical, and cultural assessments for sites • Completely dependent on federal licenses and permits for frequencies and towers • At risk of planned (and unplanned!) obsolescence. If you’re in an executive sponsorship or steering role, do yourself a favor and hire or assign someone full-time to manage the project if it’s much more than an effort costing a few hundred thousand dollars. Don’t make the mistake of figuring that project management is a sideline job for someone with other responsibilities. That’s a sure road to failure. A full-time assignment will get the job done better and faster. Foundations 103: Project Charter Okay! You have lined up the designers, architects, foreman, and eventual occupants of this house for an extended, interoperable family. Now it’s time to create an architectural drawing of what it will look like. The project charter is the single most important document you can create for your interoperability project. It is a written document presenting a vision of what is to be accomplished, defining scope, goals, and objectives. It includes a description of the decision-making structure to be used, project management approach, and initial resource requirements. Plan to distribute it widely after approval by the project’s executive sponsors and have it used by all members of the project. Typically, it’s put together by the project manager and Steering Committee with input from working committees, if they’ve been formed. Original Tech Guide Icon, page 51 The Law Enforcement Tech Guide covers development of a charter in detail. We’re not going to re-create that wheel here, but we do want to touch on a couple of high points, with special applicability to interagency and communications projects. Chapter 5: Build an Interagency Foundation 75 The Law Enforcement Tech Guide provides a 12-step program for creating the charter. The steps are: 1. Write the Vision Statement. 2. Give the Project a Name. 3. Get the Big Picture, Conduct an Environmental Scan. 4. Build the Business Case. 5. Include Background or Historical Information, if Relevant. 6. Establish the Project Scope. 7. Establish Preliminary Project Objectives. 8. Note Major Project Assumptions and Constraints. 9. Develop Initial Timelines and Preliminary Budget. 10. Include Project Planning Methodology. 11. Provide Project Team Organizational Chart and Membership Roster. 12. Sign, Seal, and Deliver. Interoperability is all about relationships and working toward a common vision. Perhaps the first step in ‘breaking the ice’ might be to collectively develop a catchy acronym, such as DIRT (Disaster Interoperable Response Techno- communications). —Chief Charles Werner Charlottesville (virginia) Fire Department The vision statement may be crafted entirely from scratch, or it may be provided to the Steering Committee by the executive sponsors or even by some larger planning process outside this project. For example, the vision may come from a homeland security or technology strategic plan describing the need for the project. It may come from legislation, decree, or interoperability coordination bodies at the regional or state level. Adoption of a project name is an opportunity to develop some teamwork within the Steering Committee. A simple, descriptive name provides an easy way to identify the initiative. This provides a “brand” inside and outside the project. Some have even had a bit of fun with it. The environment scan is a process more unfamiliar in name than practice to folks outside of the project management business. We’ve touched on the fact that your project is probably affected by others going on in nearby jurisdictions. Your project will be planned and executed in context with other technology, interoperability, management, and operational changes taking place around you. For example, your jurisdiction may have a related project underway to build a microwave backbone to carry all forms of information for agencies, including audio and control signaling for radio systems. You should be aware of that initiative in your own initial planning. Plan in context. Building the business case is often difficult for public safety practitioners unaccustomed to marketing ideas and products. It’s easy to describe the need for new technology in dire terms of apocalyptic proportions. Or conversely, to promise World Part II: How Is Interoperability Achieved? 76 Explain the operational benefits to be achieved in specific terms. Peace and Eternal Harmony among police, fire, and EMS agencies. That sounds a lot more like a charity pitch than a business case. Resist if you find yourself writing, “If it saves one life, it’s worth the millions of dollars.” While a worthy sentiment, such hyperbole doesn’t help explain why this project and that amount of money will make a difference. Explain the operational benefits to be achieved in specific terms. For example, “A new shared radio system will support consolidated incident action planning necessary during events involving six or more police, fire, and EMS units, as well as avoid estimated replacement costs of $13 million for each of the three separate radio systems over the next 5 years.” Relevant background or historical information is easy to find for most communications projects since radios have been used by generations of responders. There’s usually good background on how the involved agencies ended up with the systems they currently have and how interoperability problems arose. Remember that the goal in this portion of the project charter is to explain how this project came about. Scope: What’s in, what’s out? In creating the charter, the team has its first opportunity to establish the project scope. It’s fairly general at this point, but should clearly define what’s in and what’s out of the project. For radio systems, relevant factors to describe are involved agencies, whether the project replaces existing capabilities and/or provides new ones, and the geographic area to be affected. We’ll have more to say on scope planning in Chapter 7, Create a Project Plan. Focus on operational outcomes, not technology. Project objectives have to be specific and measurable, so take time with the Steering Committee and User Committee, if it’s in place, to identify key objectives that can be quantified and measured for completion. As with the business case, remember these are being written with others in mind—both internal and external stakeholders. Since you’re planning to improve communications interoperability, take time to describe the “who, when, where, and what” of new interagency capabilities. Be specific. Focus on operational outcomes—not technology. For example, “Provide all police officers across the county with a communications channel that is immediately available for coordinating pursuits at all times.” There are many ways to meet this objective, but the “how” is left for later determination. Project assumptions and constraints should be documented to explicitly note for all team members and stakeholders what is expected, not only of them, but conditions under which the project may have to take one turn or another. This is an important part of your charter because it captures conditions participants tend to forget—but which shaped the project. For example, if the project is to create different degrees of interoperability over time or between different partners in phases based on available funding, do the best you can to identify priorities and contingencies. Similarly, your project may move faster, slower, or not at all based on continued funding under special revenue programs. This section is the best place to state assumed contributions by cooperating agencies to ongoing systems operations and maintenance. Everyone wants to know how long it’s going to take and how much it’s going to cost. Initial timelines and preliminary budgets are specific, central assumptions and constraints placed on the project. Unlike the preceding section, these may be mainly a matter of choice between participants. Take the opportunity to put a stake in the sand to describe these key components of project management. Your project planning methodology may still be in development as the charter is developed, but include plans for steps that will be taken along the way to improving interagency communications through this project. How will needs be assessed? How will progress be communicated to stakeholders? When will a project plan be developed? Large and costly interoperability projects will likely require outside expertise in one or more steps along the way. What will be done internally and what will be outsourced? The project organizational chart and roster find their first formal home in this document. Accept that they will change over time and commit to keeping this portion of the charter up-to-date. The final step is to sign, seal, and deliver the charter. Typically, sponsors and Steering Committee members sign the charter. Don’t be shy about distributing the finished charter to stakeholders everywhere. Footings on Bedrock A good home must be made, not bought. —Joyce Maynard Follow these steps and your interagency project will have a foundation with footings on bedrock. You’ll have a decision-making structure that reinforces roles and responsibilities while accommodating the variety of needs brought to the table. Your project manager—maybe you—will have the necessary room to work and resources to accomplish this most important task. A project charter captures all these initial operating details and much more. Altogether, this foundation will provide much more than just the basis for a successful project: It may be the foundation for better interagency communications well beyond. The extended family may not be ready to move in yet, but you know they’re coming! Chapter 6: Conduct a Needs Analysis What A needs analysis is the organized process of collecting information on what’s happening today, the technological environment in which it happens, supported and unsupported needs, and generally what’s required of an interoperable system. Why Since communications interoperability is achieved through a system of systems— both technological and operational—needs are many and varied. Project success pivots on meeting well understood and defined needs. Needs analysis feeds acquisition, implementation, maintenance, and most other system development efforts. Who The project manager is primarily responsible for needs analysis. The User and Technical Committees define operational needs and the current technological environment. When As soon as a decision-making structure and a charter are in place, but before preconceived, often competing, notions of solutions start to build fan clubs. Needs analysis can proceed in parallel with creation of a project plan. Original Tech Guide Icon Needs analysis provides the means to link measurable outcomes to the use of technology. It combines a structured process to define operational requirements with an interactive one to build stakeholder involvement. The products of this phase of your project prove their value in operational terms. Chapters 4 through 7 of the Law Enforcement Tech Guide deal with needs analysis for technology projects in general. Part II: How Is Interoperability Achieved? 82 Your project to improve communications interoperability is well underway. It has the necessary foundation for decision-making and stakeholder ownership. It has the project management in place that’s needed to keep efforts focused. And it has a semi-formal agreement—the charter—to assure a clear strategy for what is to be accomplished. The next step is to delve into the details of what your project will accomplish. Public safety agencies don’t need radios. They need the operational capabilities generally and historically supported through wireless communications. This might seem like a play on words, but too often a focus on the means of meeting a functional need puts requirements, themselves, out of focus. This is a common pitfall in using technology of all sorts, not just radio. The need for interoperability is widely recognized today. Unfortunately, once past the sound bites and impassioned speeches, agency leaders are left with the more difficult task of coming up with more than just interoper-ability: They need interoperations. Needs analysis details what has to be accomplished to achieve interoperability. Since emergency response is the business of public safety, the business case for interoperability today describes why police, fire, EMS, and other agencies have to communicate with one another and what the “costs” are when it’s done poorly. A needs analysis details what is necessary to meet the project charter’s business case. It describes exactly what has to be accomplished for interoperability to be achieved. Conduct your interoperability needs analysis as follows: • Assess current business processes • Determine stakeholder needs • Develop operational requirements • Evaluate build-versus-buy options. Regional Icon Development and design of shared systems follow the same interagency processes described here, though necessarily with collecting their needs, and finding common requirements. User and technical committees for such development efforts should use ad hoc work groups from each participating agency to develop requirements that can be rolled up for systemwide needs analysis. Whether your project is simply to improve interoperability among users of existing systems or to build a broad, new shared system, understanding communications needs between agencies requires the specially focused efforts detailed here. more time spent in understanding each agency’s internal processes, Chapter 6: Conduct a Needs Analysis 83 It is impossible to design a system so perfect that no one needs to be good. —T.S. Eliot Needs Analysis 101: Assess Current Business Processes Needs analysis begins with an assessment of current business processes. Often we work together, but have no formal statements of how that will happen in detail sufficient to plan complex systems. Complexity is managed by breaking the problem down into small pieces (Figure 6-1). This is how a business process assessment is done. Working committees are key to a good assessment. Working committees are key to completing a good assessment. Both User and Technical Committees have reams of information to provide from their respective perspectives that has to be captured. The results of their work feed the next phases of needs analysis—and the project well beyond. Keep the committees focused on their roles. The User Committee represents operational expertise. It must define the business processes that make interoperability so critical. Don’t let it stray into the realm of technology—the Technical Committee’s specific area of expertise. Resist the temptation to see interoperability as primarily a technical problem; it isn’t. The User Committee must have ownership of the operational needs and requirements for interoperability. Project Manager Icon Your business process assessment will be an iterative process. That is, draft reports will generate further important information that should be incorporated. Not only will new bits of information arise step by step, but mistakes will be discovered that need to be corrected. Conduct the assessment accordingly, keeping draft reports, diagrams, charts, and maps in front of the project decision-making structure for the very purpose of getting details accurate and complete. Image of Flowchart with the following steps. 1. Assess Interoperability Baseline 2. Draft Business Process Baseline Report 3. Create Technology Baseline Report 4. Finalize Business Process Baseline Report 5. Fix Obvious Problems! Figure 6-1: Business Process Assessment Steps Part II: How Is Interoperability Achieved? 84 Step 10 Assess the Interoperability Baseline Project Managers Icon As the project manager, you can get started with real needs analysis by assessing the existing state of interoperability among project partners. This interoperability baseline assessment provides a snapshot for future comparison. It’s an entirely optional step that can serve as a useful tool to start subsequent conversations. Use a stake in the sand to draw feedback. Chapter 15, Measuring Interoperability, describes a method for conducting an interoperability baseline assessment. Read and follow the process described there if you choose to kick off your needs analysis with one. It shouldn’t take more than an hour or two to complete, at the most. The objective is not to conduct a scientific study, but to have a stake in the sand to draw feedback about the state of interoperability in your project area. The assessment can be used with the Steering Committee and all working committees to frame issues, elicit feedback, and achieve some consensus on challenges faced. For diplomatic purposes, assess interoperability up to the start of this project; measures of leadership and governance of your current project, among other things, are yet to be proven! Step 1 Define Interagency Business Processes The first formal step in analyzing needs is to define regular, authorized, planned, or otherwise existing interagency response processes that are already in place. Start by collecting interagency standard operating procedures (SOP) that describe how partners plan to or already work together. These describe interagency business processes. Operational Experts Icon With existing SOPs in hand, it’s time to convene the User Committee and have it define processes requiring communications between agencies. If interagency SOP pickings are slim, the User Committee may be the only place you’ll find out just what interoperations are currently being enabled by communications. We’ll talk about techniques for collecting stakeholder needs shortly. Some detective work may be necessary to discover business processes that must be supported by current and future communications systems—particularly undocumented ones. Unwritten business processes are important to document. For example, there may be a general, but unwritten, practice that police units respond to structure fires of a certain size for traffic control. Or, quick response units from two jurisdictions are automatically dispatched to injury accidents on a bridge spanning them. These are interagency processes, perhaps coordinated through a mutual dispatch channel or common tactical talkgroup. Chapter 6: Conduct a Needs Analysis 85 Even if unofficial, existing business processes must be documented. - Product: A Draft Business Process Baseline Report Business processes are documented in a report describing the “who, what, when, why, where, and how much” of interagency communications. This describes work that agencies do together. It’s the “as-is” of your business processes. Leave the “how” for the next report on the technical environment. Make special note of physical, electronic, and procedural security processes. Increasing threats and technological complexity call for attention to the security of communications resources, as well as to information exchanged through them. Use diagrams to make work models clear. The project manager is responsible for producing this report. Plan to release one or more complete drafts and distribute across all stakeholders. Seeing conversations rolled up into a summary report intended to describe all relevant business processes will certainly produce comments and corrections. It’s important to have a draft report complete enough to be readable and understandable, but make sure everyone knows it is a draft. Emphasize that this is an iterative process and feedback will be incorporated. Use diagrams to make work processes more understandable. They are key to depicting work. Two types of diagrams are particularly useful: • Sequence work models show processes, subprocesses, and activities. The Law Enforcement Tech Guide uses sequence work models for report filing and suspect booking processes. • Flow work models show information flows from person to person, organization to organization, or function to function. For example, the Law Enforcement Tech Guide uses such a model to depict information flowing from dispatch to a sergeant and on to several officers. Not only do these work models graphically depict business processes for needs analysis, they will be useful later in your project for describing functional requirements, creating acceptance tests, developing training and exercises, and for assessing the effects of system outages. Design, implementation, operations, and maintenance stages of your project all benefit from accurate assessment and depiction of work models. Part II: How Is Interoperability Achieved? 86 Step 2 Define the Current Technology Environment Technical Experts Icon Draft business process materials will be useful in the next step: Defining the technical radio communications environment that enables interagency work. Typically, the Technical Committee is charged with collecting the variety of information about technology currently in use. The project manager is again responsible for collecting the information and presenting it in a form suitable for distribution. Information collected may include the following: Interoperability Continuum Icon • A matrix showing existing means of interagency communications. List all agencies on both the side and top, with each cell indicating how communications occur. Use the five Interoperability Continuum technology categories to characterize how communications between each pairing of agencies occurs today. The standard categorized approaches are: Swapped Radios, Gateway, Shared Channel, Proprietary or Standards-based Shared System. • General descriptions of radio systems in use by jurisdiction and agency for both voice and data. As a hypothetical example: “Northland County uses an 800 MHz trunked radio system for all police, fire, and EMS voice communications. Information from a common mobile data system is carried by commercial services from Horizon Wireless.” • An inventory of responder radio equipment owned by participating agencies. This information can be detailed. Summarize it in reports, but put details such as make, model, and frequency band into appendixes that can be referenced when needed. • An inventory of supporting infrastructure, including the following: — Detailed descriptions of radio systems in use listed by jurisdiction and agency, for both voice and data — Caches of radios to be swapped between agencies — Gateways that connect voice radio audio or mobile data switches — Shared channels (frequencies) — Established interagency talkgroups — Radio sites (location, ownership, size, current occupants, available space, primary and backup power, receive and transmit frequencies in use, etc.) — Physical and electronic security measures — Wired and wireless backbone interconnecting parts of various systems, with particular emphasis on parts shared between agencies — Commercial services (vendor, capabilities, cost, availability by area) - Radio coverage (footprints of existing systems) — Technician services either available internally or contracted. This collection of information is not only important for your needs analysis, but also will be invaluable in the likely event that your project leads to procurement of additional technology. Project Managers Icon Product: A Technology Baseline Report The technology baseline report is produced by the project manager through heavy contributions from the Technical Committee. It’s important to capture all the detail described above, yet present it in summary at the front of the report. Simple explanations of “how” are indispensable. Remember that “how” questions can be answered in varying levels of detail. Provide the simplest one first. Again, use diagrams and charts to make information more understandable. Because of the geographic nature of radio systems, maps are an effective means of getting much of this information across, too. Step 3 Fix the (Newly) Obvious Problems Take advantage of quick fixes for momentum. As mentioned, developing a better understanding of business processes often suggests immediate fixes that could be made. They may be fixes to processes and procedures or simply to use some existing technology more fully. Take advantage of these opportunities for improvement, but keep up the momentum with your needs analysis. Properly done, quick fixes can actually help generate enthusiasm for the next steps. More often than not, multiple stakeholders will have an interest in even these relatively painless quick fixes. Be sure to include them in a discussion of recommendations. If the Steering Committee expects to approve such changes, be prepared when presenting recommendations to request and justify resources necessary to make the changes. Typical quick-fix examples we’ve seen include changes to dispatch procedures to announce staging area channels during multiagency incidents, new automatic aid agreements or formalization of existing practices, and consolidation of radio system components in shared sites. For the sake of progress, avoid changes that will take more than a week or two to implement, however. Carefully evaluate what constitutes a quick fix, leaving anything more involved for inclusion in your functional requirements and the formal project plan. Part II: How Is Interoperability Achieved? 88 Upon completion of these quick fixes, initiate the practice of celebrating milestones along your path to communications interoperability. This is a great time to start a habit of taking advantage of visible steps of progress. A small ceremony of thanks to key participants and even press releases to claim your project’s success more publicly are good moves that help to boost morale and build momentum. Step 4 Describe How Current Technology Is Used to Accomplish Work With the technology baseline in hand and quick fixes complete, the business process baseline can now be finalized. Get the Technical Committee’s assistance to take descriptions of interagency processes and add simple “how” statements. For example: “Midland City FD and Stillwater RFD have an automatic aid agreement for structure fires in the Norwalk Subdivision. This typically requires one channel of common communications for command coordination and another between the command post and staging areas. VHF-high band shared channels are used directly between responders.” “Midland City PD and State Highway Patrol units are jointly dispatched to injury accidents on I-5 within the city limits. The PD uses a dedicated channel on its UHF conventional system to talk to SHP on its Division 1 operations channel—a 150 MHz conventional repeater—connected by a permanent gateway operated by the city.” Product: A Final Business Process Baseline Report Complete your assessment of current business processes by finalizing the baseline report. This report captures both operational processes and details of the technologies currently supporting them. If you completed one, the interoperability baseline assessment should be included, along with any adjustments due to feedback received along the way. Tips Icon This is your as-is report. This as-is report is very important for needs analysis. As the title states, it is the baseline describing what you have today in the way of interagency operations and how radio communications support them. It’s not uncommon in this process to run across immediate changes that could be made to improve operations. Take advantage of these opportunities by including them as recommendations in the final baseline report. Depending on your governance structure, the Steering Committee may wish to review the report before adopting it as final. It’s great to have that level of support, but make sure to take into account the added time needed for review, changes, and approval when creating the project plan. Chapter 6: Conduct a Needs Analysis 89 A human being has a natural desire to have more of a good thing than he needs. —Mark Twain Needs Analysis 102: Determine Stakeholder Needs You have the as-is. Now you can move on to the to-be. Project buy-in hinges on how well stakeholder needs are determined. The project manager guides this process, meeting with stakeholders at all levels, across all agencies. Start the process of collecting needs shortly after documenting business processes and the technology environment. This takes advantage of any momentum created and captures ideas that arose in discussing things the way they are. While baseline assessments can be conducted relatively quickly through efforts of the working committees, collecting information on stakeholder needs requires that time be spent with a lot more people across essentially all agencies—and probably among various groups within each. The Goals Goal #1: Capture operational needs. There are several goals to be achieved in collecting stakeholder needs. The obvious one is to obtain a better understanding of interagency communications needs. Often these needs are camouflaged behind ideas about how best to resolve them. While the solution to a given problem may revolve around new or innovative uses of technology, technology isn’t ever the need. Work to capture the interagency operational needs to assure success and the ability to accurately recognize those needs. A secondary, but equally important, goal is to open organizational and management lines of communications about needs. Often these needs aren’t new and have had some time to “mature.” Goal #2: Open lines of communications. Can we talk? Many interoperability problems masquerade as technical problems when in reality they’re organizational or management dysfunctions—or originated there and now really are technical problems. More than one agency has built a new radio system without regard to compatibility with neighbors. They reduced interoperability by introducing incompatible technology, not seeing a need for interagency communications at the time. The fact that your project is progressing proves agencies are willing to move beyond organizational dysfunctions, if they ever existed. The best way to pave over those potholes is to focus on the operational or functional needs of participating agencies. Get input not only on how they can communicate better with partners, but also how organizational change will flow from better interagency communications. Part II: How Is Interoperability Achieved? 90 Goal #3: Get invested stakeholders. The final goal is to get all stakeholders involved in the process and invested in creating solutions. This occurs when they’re involved in defining requirements and recognize that the outcomes will address their operational needs. Techniques Checklists Icon As we’re alluding to, the project manager or other facilitator’s challenge in collecting needs often amounts to digging through surface layers to reach underlying needs. It’s really not all that hard to do. What’s tough is doing it without losing stakeholder confidence and buy-in along the way! The project manager’s communications skills— and we don’t mean radio—are going to make or break this share of the project. Objectivity is one of the project manager’s sharpest tools at this point. It yields the credibility necessary to elicit honest statements of need and facilitate discussion. If you’re in that role, recognize that your preconceived notions will be picked up far away. Guard your credibility by remaining objective! Be Prepared: Collect Artifacts Before going to stakeholders to solicit the needs that will shape your interoperability project, search for materials from the involved jurisdictions that may already document what those needs are. Several likely sources may turn up artifacts establishing de facto requirements, stating unmet needs, or otherwise exposing interoperability holes. Formal or anecdotal, these artifacts are invaluable in exposing stakeholder needs. The business process baseline often highlights a number of these and commonly draws attention to neglected or unnecessary ones. Other likely sources include the following: • Existing strategic plans, both business and technology, establishing requirements that agencies have to meet • Debriefings and after-action reports on incidents, particularly multiagency incidents • Evaluations of tabletop and full-scale exercises. Make written or mental notes of needs and requirements apparent in these sources that otherwise may not surface during interviews or focus groups. Use them to elicit discussion, perhaps validating or tempering issues raised. Chapter 6: Conduct a Needs Analysis 91 Be Prepared: Collect Scenarios Emergency response scenarios used in planning, training, and exercises provide a ready-made source of examples that can be presented during interviews and focus group sessions. With any luck, agencies involved in your project already regularly conduct multijurisdictional exercises. Those scenarios can be tapped. Emergency management officials can provide other suitable ones. Other good sources include the SAFECOM Statement of Requirements21 and the Department of Homeland Security’s National Planning Scenarios. Both are rich sources of examples of everything from natural disasters to improvised nuclear devices. Check with your local or state emergency management offices for details of the National Planning Scenarios. A ready supply of scenarios provides fertile ground for eliciting needs while talking with stakeholders. Conduct Interviews and Focus Groups Once prepared with background, you’re ready for direct interviews and focus group sessions with stakeholders to uncover needs related to project goals. Interview and facilitation skills can be learned, but they require practice. If this is your first project, you’re definitely jumping in feet first! Original Tech Guide Icon, page 79 Interagency projects generally bring more stakeholders, many of whom should be interviewed or involved in focus groups for collecting needs. Whether this is your first project or you’re a veteran, read Chapter 5 of the Law Enforcement Tech Guide. It provides a wealth of information on interview and focus group techniques. You’re bound to pick up a few pointers! The Product By the completion of interviews, the needs analysis process will have produced an abundance of information. This Guide has concentrated heavily on data collection so far; next, we’ll turn to distilling all that has been collected into general system requirements to be included in design documents. 21 U.S. Department of Homeland Security, SAFECOM Program, Statement of Requirements for Public Safety Wireless Communications and Interoperability (Washington, D.C.: Version 1.1, January 26, 2006). Available at http://www.safecomprogram.gov/SAFECOM/library/technology/1258_ statementof.htm. Part II: How Is Interoperability Achieved? 92 Life was simple before World War II. After that, we had systems. —Admiral Grace Hopper Needs Analysis 103: Develop General System Requirements Business process baseline development, stakeholder interviews, and focus groups yield three kinds of needs: organizational, operational, and technical. Each will develop into requirements separately. Some will naturally be used for procuring technology to improve interoperability; others will be acted upon by the agencies themselves, individually or collectively. For a complex system of interoperable systems, requirements will span agencies, response disciplines, modes of service delivery, and radio systems. They rightfully describe everything from training and proficiency of users to availability and reliability of radio coverage. These requirements are used in a conceptual design that incorporates action plans for organizational and operational change, as well as in technology procurement and implementation documents. The iterative process of collecting baseline (asis) information, assembling needs across stakeholders, and generating system requirements (to-be) requires repeated participation, review, and comment by working committees—both operational and technical. Describing Requirements Understanding and articulating your requirements is key not only to any successful procurement of technology, but also to organizational and operational changes necessary for improved interoperability. Requirements have to be described in terms directly linked to the interagency business processes to be supported. Operational requirements are best stated in simple terms, avoiding constraining definitions of how requirements will be met. Describe requirements using consistent terms and categories that help make sense of what otherwise might be a confusing jumble of data. Fortunately, common terminology and basic categories have evolved in recent years. SAFECOM’s Statement of Requirements provides some of the most useful standardized descriptions specifying with whom, for what purpose, and under which special conditions a series of typical communications may occur. While forward-looking to future development of technologies, the document uses a complete and consistent style of description. We’ve used elements in business process examples above that would roll into requirements documents. Communications requirements can be described from several different angles. We can look at the type of communications, the technological modes traditionally used to provide them, and the operational modes of response when they’re used. We can also describe them in terms of their scope, scale, and priority. Chapter 6: Conduct a Needs Analysis 93 Use the following categories and terminology shown in Figure 6-2 in stating requirements. Quantification and qualification are both appropriate. Image of Clipboard with the following Information: Categories and Terminology to Use for Stating Requirements Type Dispatch Command Operational Tactical Support or Logistical Scale One-to-One One-to-Many One-to-All One-to-Any System Administration Operational Mode Routine Planned Events Large Emergencies Technological Mode Voice—Interactive Voice—Noninteractive Data—Interactive Data—Noninteractive Priority Extreme Emergency Urgent, Safety of LIfe Urgent, Safety of Property Planned Events Exercises Training Figure 6-2: Categories and Terminology These methods of describing communications—either as they currently are or as they should be—serve to categorize them. Categorization is useful for understanding different requirements and being able to explain them. This is necessary not just for specifications when buying radio systems, but more important, for understanding internally what we’re doing with communications. Simply adopting common terms to describe communications goes a long way in communicating—no pun intended— what’s going on when writing standard operating procedures, training, conducting exercises, and working with other agencies to improve interoperability. Note that these ways of describing communications aren’t mutually exclusive and, in fact, definitions are bound to vary across jurisdictions and disciplines. Part II: How Is Interoperability Achieved? 94 Step 1 Define General Functional Requirements Requirements are next defined in functional terms and compiled into a report presenting them along with a conceptual design that illustrates how they fit together. The first step in pulling together that report is to compile requirements from preceding work. Functional requirements are defined in terms of just how the “system of systems” will work to accomplish your project’s goals and meet its vision. Stop Sign Icon Don’t allow preconceived “solutions” to slip into your requirements. The price to pay in noncompetitive bids that are challenged is just too high—and you may not get the best solution for your operational needs. The project manager bears the responsibility for identifying conclusions that may have slipped in under the guise of requirements. Sort requirements into organizational, operational, and technical categories. Organizational Interoperability needs analysis generally produces a number of requirements for organizational change or development. Some examples include needs to create the following: memoranda of understanding for sharing costs, mutual aid agreements for sharing resources, policies for incident management during multijurisdictional emergencies, and procedures for interagency operations. Requirements may also include standard practices for lifecycle funding of systems, minimum staffing of deployable communications resources, security, and standard training on interagency communications across all partners. The project’s executive sponsors and Steering Committee bear the responsibility for preparing their organizations for changes necessary to improve interoperability. Most organizational requirements that arise will require changes only possible through their leadership. Give some thought to what has been documented through the process up to this point. Separate those requirements that have been expressed that can best be addressed by management. They’ll be used in the conceptual design. Operational Collect the processes and needs that have been expressed in operational terms. If you followed our advice in completing the business process baseline, you’re well on your way. Additional operational requirements arising from interviews and focus groups must be folded in, but they should be obvious if you focused on operational outcomes of interoperability. Chapter 6: Conduct a Needs Analysis 95 Stop Sign Icon Beware of operational needs that extend the scope of your project. The primary reason for establishing scope early in the project under the direction of the Steering Committee is to draw some boundaries around what specifically is to be accomplished. One hopes that you were able to use the project scope to keep the needs analysis focused, but in case some discussions veered off track, now is the time to start paring back. Remember: It’s all about interoperability. Operational outcomes are the whole reason why your project was undertaken. Take the business process descriptions and needs that have been developed and massage them into statements of requirements that describe how the pieces must function together. A good technique is to use scenarios that you collected to facilitate stakeholder interviews and focus groups to describe operational requirements, highlight technology already in place, and state technical constraints. Realistic examples always serve to clarify. Technical Technical aspects of functional requirements address how operational needs are to be met through technology. Don’t confuse them with the technical details of existing systems that went into the baseline reports and will go into requirements for interfacing or integrating those systems with any new technology. Because few agencies maintain communications engineering staff, consultants are often hired in radio projects to examine the technical environment, document technical requirements, and then define interface and integration requirements described in the next step. Communications technical requirements are often expressed as a matter of one or more qualities, such as the following: • Capability – services provided for emergency responders (what, who) • Availability – how well the system covers the area served (where) • Reliability – how well the system delivers its services (when) • Scalability – how well the system accommodates surge conditions • Survivability – how resistant the system is to failure • Restorability – how easily the system is restored upon failure. Use terms of quality to state technical requirements. The Technical Committee may not have defined its needs using these terms, but we’re certain the terms were touched on in principle. Use these qualities to further categorize technical requirements. State them in ways that can be tested and validated by system users. Part II: How Is Interoperability Achieved? 96 Avoid requirements that are essentially technical specifications. When system vendors deliver technology accordingly and it doesn’t meet operational needs, the technology or vendor is usually faulted. In reality, the failure was in not stating requirements so that operational tests could prove whether the solution was acceptable. While a simple idea, stating requirements in functional terms takes work. It’s tempting to adopt specifications as requirements, and then be forced into using technical performance measures for acceptance. Within your project, work to assure you understand operational requirements well enough to decide whether any proposed solution—technological or otherwise—meets needs. Regulatory mandates often spur system upgrades and replacements. The Technical Committee may have expressed needs to meet federal and other regulatory mandates. For example, the Federal Communications Commission (FCC) has recently released rules regarding rebanding (moving existing channels within a band to reduce interference)22 and narrowbanding (reducing the amount of radio spectrum used for a given channel).23 The committee may also have identified limited radio spectrum as constraining expansion of systems to meet other needs. These types of mandates provide the primary impetus for many radio system upgrades and replacements. Note that, properly speaking, they don’t represent requirements for your interoperable systems, but rather are part of the environment in which realistic solutions have to be implemented. For example, there is a difference between a requirement to meet FCC narrowbanding regulations and a conclusion to migrate systems to the 800 MHz frequency band. While that might be the eventual solution, there’s a difference between making it a possibility and making it a requirement. 22 In August 2004, the FCC initiated the process of relocating most public safety 800 MHz users within the band to reduce interference suffered from commercial wireless systems. 23 In December 2004, the FCC released long-awaited rules that will force eventual changes to all radio systems operating below 512 MHz—all the commonly-used public safety bands below 700 and 800 MHz. By January 1, 2013, all radio channels used by these systems must be reduced in width by half or be capable of passing at least two voice conversations in the same amount of radio spectrum. Chapter 6: Conduct a Needs Analysis 97 Step 2 Define General Interface and Integration Requirements All systems have geographic, functional, and technical boundaries that have to be bridged and every interoperability project has internal points of interface between communications systems and subsystems. Very few projects are initiated to uproot all communications components for all agencies—from voice radios, to backbone networks, to consoles and beyond—so integration of the old with the new is generally inevitable. Your own project probably encompasses components that won’t be replaced in this effort to improve interagency communications. Ideally, they can all be integrated to the extent they can honestly be called a “system of systems.” This step in defining requirements establishes what parts of existing systems will stay and which may go. It defines required points of interface between those that stay and any new technology that may be implemented. This is the place to document specifications that will shape proposed technology solutions. Start by describing the core systems and subsystems that exist and will be built upon. Establish provisional requirements for using them in concert with any new interagency communications capabilities. For example, consider the popular gateway devices that connect audio between different radio systems, effectively patching two or more channels together. In some areas of the country, these are critical resources for enabling interagency communications. Many have been placed in fixed locations and have limited capacity for expansion, either because of some inherent limitation on the number of channels that can be interconnected or because the radio site is otherwise congested. Requirements for connecting the gateway into any new means of interagency communications should be spelled out. Or consider that advanced radio systems are connected by sophisticated backbone networks carrying all sorts of voice, data, and other forms of communications. Quietly in the background, the network is probably carrying supervisory control and data acquisition (SCADA) information that’s used to manage the network itself, radio sites it interconnects, and maybe even radio tower lights! (Don’t laugh. The cost of burned-out tower lights can be high—federal fines and worse!) Any new systems added to such a backbone may be required to interface with the SCADA subsystem. Part II: How Is Interoperability Achieved? 98 Now is the time to establish any requirements on integrating other systems through these and other resources. By nature, interface and integration requirements are very technical. Internal or contract engineering expertise can be put to work in defining these requirements. Step 3 Create a Conceptual Design The final step in developing general system requirements is production of a conceptual design. This document illustrates how interoperability goals are to be realized through both technical and nontechnical means. It demonstrates a vision incorporating major assumptions and constraints, highlighting functional outcomes of your project. Create the conceptual design from the requirements statements you’ve assembled. While much of the document will be essentially a narrative of what your needs This is your to-be analysis produced, don’t forsake the pictures! Maps and diagrams are particularly important components to include because they capture a great deal of information in one place and show relations difficult to explain without a lot of verbiage. Use sequence and flow work models from the business process baseline assessment to illustrate what exactly will be supported by any new systems to be implemented. Once again, the project manager is responsible for this product, but don’t feel bad if the whole needs analysis process has left you exhausted! It’s not uncommon for it to be contracted out. Some of the best work we’ve seen in this regard has been done by system integrators strong on business process reengineering and less interested in communications systems engineering. As mentioned, this is a conceptual design for improved interoperability that most likely will require a lot of organizational development, as well as technology. Don’t confuse it with more detailed engineering designs that will come with responses to any significant request for proposals and technology implementation plans. Those come later—if at all—and address technical aspects of interoperability solutions. Needs Analysis 104: Evaluate Buy Versus Build Options We’ve come to a decision point: What share, if any, of your new interoperable system of systems do you want to own and what share are you willing to outsource? Don’t buy the house; buy the neighborhood. —Russian proverb This is a difficult decision that must be made before procuring any services. Traditionally, public safety agencies have built, owned, and operated their own radio systems. Whether for voice or data purposes, police, fire, and EMS agencies Chapter 6: Conduct a Needs Analysis 99 have traditionally chosen to “roll their own” systems to provide known levels of security and services, manage long-term costs, and guarantee priority access during emergencies. However, agencies increasingly use commercial services for data and even some voice traffic. Public safety agencies have traditionally rolled their own radio systems. Voice push-to-talk communications is considered the most sacred technology owned and operated by public safety agencies. While very few have resorted to completely outsourcing radio needs, every day more and more move traffic off traditional voice radio channels to data systems, cellular telephone, and other commercial radio services. Hybrid systems, owned and operated by private companies but leased to public safety, are also increasingly common. Commercial networks are increasingly used in mobile data systems. Some share of this migration is due to the lack of available radio spectrum for new and growing uses, but the trend is also seen in areas where frequencies aren’t so scarce. We expect this trend to be cyclical as the costs of building, operating, and maintaining systems are weighed against the costs of sharing access, opaque commercial capabilities that can’t be examined in detail, and less control over services received. Shared systems bring high levels of technological compatibility. An important choice about joining shared radio systems may also be in your cards. These regional or statewide systems are being built to take advantage of economies of scale, gain strength through numbers with vendors, make use of otherwise duplicated system components, and improve technological compatibility that can lead to better interoperability. In many ways, they offer a good compromise between buying and building new radio systems. If the option is available, use of a shared system may be a partial or possibly a complete solution to your project’s technology needs. This may result in similar deliberations about guaranteed levels of service, long-term costs, and priority access that you would have when using commercial systems. Approach participation in shared systems in a manner similar to procuring a new system or commercial services, recognizing the “added partners” you get at no additional cost! This completes your needs analysis. The products will have been presented in large part to stakeholders and accepted as formal project documents. Now is the time to complete a project plan. Chapter 7: Scope the Work To Be Done What A scoping exercise examines the extent of organizational and technological work to be done through procurement and implementation. It concludes with the decision of what work to contract out and what to complete in house. Why Voice and data communications projects include work that you may wish to undertake directly or contract out. Understanding the work involved allows a choice of what will be included in the procurement process and who will be responsible for different aspects of the system. Who The project manager needs to understand both the work to be done and internal resources available to complete it. The Steering Committee ultimately has to decide what will be done internally and what will be procured externally. When Following the needs analysis, the work to be done should be examined and decisions made on what services and equipment will be procured. We left the needs analysis phase of your project with a conceptual design in hand and a “buy or build” decision on how to improve communications interoperability. The conceptual design described at a high level how the various system components— technological and otherwise—will fit together for interagency operations. In preparing a project plan, look at the scope of work to be accomplished and decide who will accomplish what. The remaining phases of your project are procurement, implementation, and maintaining the systems and processes. Each phase requires a good deal of work from the project team, but you will soon be at the crossroads of deciding what to hand over to contractors and what to do internally. In order to best make that decision, it’s useful to understand what has to be accomplished, particularly tasks that are most commonly contracted out. 104 Part II: How Is Interoperability Achieved? Commonly Contracted Services Radio systems involve a number of specialized services. Those discussed below are broad categories of work commonly contracted out—either separately or together. Project Management Obviously, there has been and remains plenty of project management work yet to be done. This whole book and the original Law Enforcement Tech Guide are dedicated to helping with that work. Project management probably seems like more and more work as you read along! Keeping with prior assumptions, we’ll continue to assume you are reading this as the designated or soon-to-be project manager. In moving toward system implementation, you have to work ahead to create a project plan, develop teams, carry out a procurement, lead contract negotiations, and build an implementation plan. You’ll need help, but we’ll assume the job of project management will be held pretty close to home. System Design Do you need further system design at this point? You may already be facing a conundrum that many others developing complex systems have grappled with: Do you need further system design before proceeding to procurement? Many projects proceed to procurement with little more than a conceptual design, functional specifications, and some boilerplate language. This is done to leave the field open for innovative vendor proposals. Other projects proceed through an engineering design that yields very detailed specifications for bid. Don’t limit your choices by over- designing technical elements. For interoperability projects, our recommendation tends more toward the former approach than the latter. Interoperability projects involve many existing systems and complex needs that may best be addressed by technologies you haven’t anticipated, so it’s best to remain flexible. Alternately, you may choose to hire a system designer before embarking on a general system procurement process. This may become a more common process for interoperability projects as funding becomes predictable, but now is used more often for complete, new radio systems. Detailed Engineering Design Complex systems require a detailed engineering design that is very dependent on the technology chosen. For this reason, the most detailed designs are usually left as an early deliverable for the contracted system vendor. Chapter 7: Scope the Work to Be Done 105 System Installation and Optimization Commonly done by the primary equipment or system vendor, the task of systems installation and optimization occurs during implementation. Projects without a predominant vendor or those using multiple technologies may require independent contractors. Each may install and optimize different parts of the system, such as its voice radio infrastructure and its microwave backbone. In this situation, your project could require system integration services. System Integration The role of a systems integrator is to take the variety of electrical, electronic, and physical system components and (surprise!) integrate them into a coherent whole. Integrators often also serve in system design, acceptance testing, and quality assurance roles. Turnkey procurement: One in which a general system vendor or equipment manufacturer designs and integrates the system, and provides the equipment. This is a role you may choose to handle with project staff, contract independently, or leave up to a system vendor as a turnkey procurement. A turnkey procurement is one in which a general system vendor or equipment manufacturer serves as the system designer, integrator, and equipment provider. We’ll provide recommendations on how to proceed with these particular choices near the end of this chapter. Quality Assurance Often used to refer to a broad range of acceptance testing (see below), quality assurance is defined as a systematic process for assuring that a project meets its objectives. Quality management is formally part of project management and is most commonly seen in large system implementations. Independent quality assurance contractors are occasionally used for radio projects. For example, the Illinois State Police hired a quality assurance consultant to evaluate proposals for a statewide system for the state police and other state and local agencies. Acceptance Testing Acceptance testing is dealt with in more detail in Chapter 10, Implement the System. In implementing technology, acceptance tests are planned and conducted to determine whether specifications and performance requirements are being met. The larger the project, the greater the effort involved in acceptance testing. Complex measures of performance, such as radio coverage, may be included in the acceptance process. While it’s always valuable for the customer to be involved in acceptance testing, part or all of the effort is occasionally contracted out to an independent party due to the work involved. 106 Part II: How Is Interoperability Achieved? Other Work to Be Done There are three additional areas of work involved in implementing radio systems where agencies typically choose to retain greater control: Training, radio site development, and frequency licensing. Each of these areas can be completely outsourced, of course. However, it’s more likely that you would keep a tighter rein on them than you would, for example, on microwave path analysis. Let’s take a look at each of the areas in some depth to provide more background for your choices in delegating or contracting project work. Training Training is the key to your successful system of systems. Training will be the key to your successful system of systems. Anticipate that several types and levels of training will be necessary. Consider what may best be done in house, what can be contracted from your system vendors, or even solicited independently from training companies and organizations. Technical Training Your radio equipment vendors can be expected (under contract!) to provide training on the technical operation and maintenance of equipment. This is appropriately provided to agency radio technicians. Ongoing training should be anticipated for new staff members and to maintain the skills of existing staff. Dispatcher Training Dispatchers are professional systems integrators. Many means of improving communications interoperability will rely on that central resource for most emergency response: the public safety communicator or dispatcher. The dispatcher’s role requires his or her own personal integration of so many communications systems that you shouldn’t underestimate the need for carefully designed and executed dispatcher training. User Training No technology is so simple that training is unnecessary for people who will use it during emergencies. Last, but not least, first responders who will use the system to communicate across agencies and jurisdictions need training. Plan a comprehensive program for all agencies planning to use the system that provides initial training of existing staffs, basic training of new staffs, and coordinated interagency exercises. Consider that such training won’t appropriately come from system vendors, but from your own agencies’ staffs or even specially contracted assistance. Radio Site Development One technical consideration that agencies often maintain some control over is the selection of radio sites for systems. Vendors rarely know as much as your users do about how well sites serve current needs. There’s a good deal of “give and take” Chapter 7: Scope the Work to Be Done 107 between project technical committees and vendors in the process of radio site selection for new and expanding systems. Include staff on the Technical Committee who know what’s in use—and why. If you anticipate much radio site development in your project, make sure to include people on the Technical Committee who have the knowledge and background of what’s currently in use. There’s usually a lot of history behind why a particular site is used and why a better one is unavailable. This sort of “corporate knowledge” is the type that you don’t want to pay a contractor or consultant to rediscover. Basically, radio sites are real estate. The three most important aspects of their selection are location, location, and location (we’re sure you’ve heard this before about residential real estate!). If your project requires site work or development, you’re faced with using current system sites as-is or with improving, buying, or leasing access to other existing sites, or developing entirely new ones. The overriding consideration for sites is the coverage they will provide. The overriding consideration for radio sites is the coverage they will provide. This is affected by physical location relative to the involved jurisdictions, height relative to the area to be covered, surrounding natural or man-made clutter that will block radio waves, and other electromagnetic factors. While there are always compromises to be made, coverage is king. Considerations for existing and new sites differ a bit. Considerations for Existing Radio Sites Public safety radio sites are considered critical infrastructure for homeland security. — Physical access. Is the site constructed for safe, secured access for all tenants? How does the site manager provide for installation of new equipment on towers and in shelter space? Is there a security system to keep out unwanted visitors, yet not impede legitimate maintenance? — Physical space. Is there “prime” tower space available for antenna systems? Does the shelter rack have expected space for radios and antenna system combining equipment? Federal Aviation Administration (FAA) permits often require tower lighting. not only are tower owners liable for lighting inadequacies or failures, but tenants’ leasing space have been fined, as well. — Services. Is commercial and backup power suitably sized for all users? Is an adequate lightning protection system in place? Do the electrical and radio frequency (RF) grounding systems meet electrical codes and industry standards? — Maintenance and monitoring. Is the site well maintained to minimize the tenants’ costs and reduce their liabilities? Does it have an adequate monitoring system for tower lighting, power systems, and security controls? Has the site manager instituted an acceptable plan for minimizing exposure to incidental electromagnetic radiation, as required by the Federal Communications Commission (FCC)? 108 Part II: How Is Interoperability Achieved? — Electromagnetic compatibility. Are there other users of the site whose systems will make it impossible or expensive for your systems to work? Is there a powerful radio paging service operated nearby that may interfere? Considerations for New Radio Sites Grant Requirements Icon Be aware of grant limitations on purchasing sites or permanent construction! many won’t cover them outright, but will accept the costs as an allowable match. For the uninitiated, building a new radio site is an education. Many an initiate has begun the process to develop a seemingly crucial location and ended up regretting getting started in the first place! While not impossible to do and do well, of course, new site development requires a lot of work that you may have not anticipated. Consider all that is involved before insisting on doing it yourself. Here are some initial questions regarding a system design involving new sites: — Property ownership. Do project partners already have suitable locations for new radio sites or access to other publicly owned property? Is there potential private property that can be purchased or leased? — Physical access. Are good roads available nearby for construction and maintenance of standalone sites? Is facility access adequate for those being put up on buildings, water towers, and other existing structures? Is there an adequate road right-of-away to the property? Is it accessible throughout the year or will seasonal conditions affect needed maintenance? — Physical space. Is there sufficient space available to put up a tower and equipment shelter? One jurisdiction had to resort to condemning private property for right- of-way access to an important radio site. — Security. Can the site be adequately secured from vandalism and unauthorized access? What level of access control is possible? Can systems be monitored for damage or failure? — Utilities access. Are commercial power and telecommunications available or economically accessible? — Existing backbone networks access. Will connections to other backbone networks owned by the agencies be practical from the site? Some additional considerations in implementing radio systems with new sites: Buying or leasing real estate. For government agencies, this inevitably requires a lot of legal and financial consideration by staff elsewhere in the affected jurisdictions. If you hadn’t included suitable expertise in an ad hoc working group, you will want to add it if you plan to acquire new site real estate. Zoning and variances. You may run into zoning issues for a given location that require navigating the thorny path of property use variances. Even if a formal Chapter 7: Scope the Work to Be Done 109 variance is unneeded, plan on a careful, measured public hearing and education process if you plan to put up a new tower. There’s a wide and strong current of NIMBY (“Not in my backyard”) running nationwide. Not everyone sees the beauty in radio towers and there’s always concern about the potential health effects of nearby radio transmitters. Plan to use a public relations team to help if you choose to get into the business of building new radio sites. Stop Sign Icon One jurisdiction ran head-first into a “Save Our Mountain” committee when trying to site a new tower. They ended up compromising on the location—going with a marginal bench on the side of the mountain rather than the top to avoid tower lighting requirements—and ended up suffering coverage problems in critical areas for more than 20 years. Construction permits. It should come as no surprise that all the work going into a new site generally requires studious attention to obtaining building permits. As public agencies are often under great scrutiny, your partners will expect that all necessary and appropriate permissions are received before construction begins. This needn’t be a difficult process, but it does take time and often affects site design. Increasing use of “mesh” radio networks for data requires many more sites, though generally simpler ones. Tower size. A tower’s height above ground or above the average terrain surrounding a site dramatically affects the coverage of radios in all frequency bands. While there are technical design trade-offs—too much height, too much coverage, the effects of distant interference aggravated by being in “too good” of a location, and general practical construction considerations—greater height for antennas is generally preferred to maximize the coverage. Building new sites brings up additional engineering considerations before real estate is ever purchased. Tall towers require guy wires that run to ground anchors well away from the towers, necessitating larger sites and additional construction, including security fencing. In 2004, a Florida jurisdiction suffered a dramatic and dangerous tower collapse when a service truck backed into guy wires at one of its sites. Such total loss of a site can have a dramatic effect on system capabilities. FAA permits. Radio towers and antennas can be serious aviation hazards. The FAA has strict regulations regarding their location, size, painting, and lighting. Don’t plan on putting up new towers without scheduling time for the FAA permitting process. Antennas or mounting structures that don’t extend more than 20 feet above existing structures don’t require additional approval, but when it is necessary, plan on 6 to 8 weeks for completion of permitting. Part II: How Is Interoperability Achieved? 110 Environmental and cultural assessments. A common “gotcha” in building new radio sites is the need to conduct assessments of the environmental impacts of new sites. Many potential sites are in environmentally sensitive areas and may be subject to the National Environmental Policy Act (NEPA). Environmental impact statements are time-consuming and can bring public contention. Similarly, potential sites may have historical or other cultural significance that can quickly exclude their consideration or require careful assessment. Rely on expertise in your jurisdictions’ building, construction, and zoning divisions, as well as legal staff, to help decide whether environmental and cultural assessments will be necessary for new sites. Be aware that there are private companies that specialize in doing this work, as well. Other Radio Site Work If you choose to be involved in the selection of any radio sites to be used in your new system, be aware of the additional work this typically involves. Vendors look for adherence to commercial and public safety standards in evaluating existing sites. Site inspections are important and typically required by vendors when existing sites will be used for new or extended systems. Inspections may be conducted by a joint team of your project’s technical members and the vendors, or it may be stipulated in contracts as being done by a third party. Commonly, vendors look for adherence to commercial or public safety standards before accepting sites offered by agencies for use. Conversely, you may have nontechnical requirements for sites identified by vendors, such as access for maintenance and physical security. Tower inspection and validation is related to site inspection, but considered a separate task because of the engineering expertise needed to evaluate the structural integrity of towers and validate their acceptability within the engineering design.24 For new or existing sites, adequate floor space has to be available for expected equipment. Site design is a separate, but important task. For new construction, it starts with layout of the tower, shelter, guy wires, grounding systems, utilities, access, and security. For new or existing sites, floor plans have to be developed and documented to assure adequate space for equipment and its proper identification later on. Similarly, equipment rack layouts are an important part of site design. Radio sites are dependent on adequate, quality electrical service that typically has to be converted from the utility company’s alternating current (AC) to direct current (DC). An electrical design is needed that accounts for AC service to some pieces of equipment, DC to others, and backup power when commercial service is lost. 24 The National Association of Tower Erectors (NATE) works with federal agencies and standards organizations to establish tower safety practices. See http://www.natehome.com. Chapter 7: Scope the Work to Be Done 111 Proper documentation of all these site design elements is a critical deliverable during implementation, too. Antenna system installations are generally part of any implementation of new fixed radio infrastructure. More than likely, this responsibility will be defined in your procurement documents as either your responsibility or the vendor’s. In either event, both parties have an interest in using certified crews for the sake of safety and quality.25 If you require the vendor to use existing antenna systems or ones your agencies provide, expect the vendor to require their own verification of suitability. Frequency Coordination and Licensing Most public safety transmitters have to be licensed with the FCC. The final area we want to address in scoping work to be done is licensing of any required radio frequencies. Not all projects will require additional channels, but licensing is generally required for any addition of new sites, even on existing frequencies. Don’t make the mistake of planning to put in new transmitters of any form without assessing FCC licensing requirements. Spectrum congestion forces agencies to move to new frequency bands to get new capabilities. There are a multitude of considerations about RF spectrum availability. It’s beyond the scope of this Guide, but suffice it to say there are very definite limitations in most areas of the country, using predominant frequency bands, in adding new frequencies to systems for interagency use. Since compatibility with existing systems and surrounding partners is a central issue in communications interoperability, there is rarely the ability to uproot all systems and move to new, typically higher, frequency bands to find “green space.” 26 Projects of the type we’re addressing in this Guide are more incremental in nature, typically not requiring large numbers of new frequencies. Whether new frequencies will be required or existing ones used in new ways, the FCC requires frequency coordination and licensing. The application process itself is alien to most agencies and uncomfortable even for most technicians. Many agencies have technical staff adept at preparing applications and navigating the frequency coordination process. Both activities have become more complex in recent years, however, and agencies are increasingly outsourcing the whole process in systems acquisitions. 25 The Occupational Safety and Health Administration (OSHA) and National Institute for Occupational Safety and Health (NIOSH) have increasingly stringent standards affecting tower construction and antenna system installations. See NIOSH Publication No. 2001-156, http://www.cdc.gov/niosh/2001156.html. 26 SAFECOM has produced a publication addressing the subject, Public Safety Radio Spectrum: A Vital Resource for Saving Lives and Protecting Property. See http://www.safecomprogram.gov/ SAFECOM/library/spectrum/1102_publicsafety.htm. Part II: How Is Interoperability Achieved? 112 For purposes of planning, be aware that the cost of license application preparation can range from a couple hundred dollars to several thousand for larger, more complex systems. The FCC doesn’t charge fees for licensing by public safety agencies of their land mobile radio systems,27 so no cost is to be anticipated there. It does, however, allow certified frequency coordinators to charge for their services. A couple of certified coordinators use local advisors, people within the state or region who typically work in a technical capacity for a public safety agency that volunteers their time. Frequency coordination is the process of selecting appropriate frequencies for the applicant agency, while balancing the needs of other eligible users and minimizing interference between all.28 Since practically all licensing that public safety agencies do requires frequency coordination, you can anticipate using the services of a certified coordinator. The FCC maintains a list of coordinators and contact information on its web site.29 We increasingly see projects where certified frequency coordinators are brought on under contract to help guide this aspect of design, and then subsequently prepare applications, coordinate frequencies, and submit everything to the FCC. Fees are typically based on the number of frequencies and sites used in a system. Again, the cost varies according to the size and complexity of the system. It varies from a couple hundred dollars for a simple modification to an existing license to tens of thousands of dollars for new systems with many sites and frequencies. For planning purposes, contact the certified frequency coordinators for cost estimates. GATEWAYS AND FREqUENCY LICENSING Gateways that interconnect multiple radio systems bring additional licensing requirements when used to directly control transmitters. Requirements vary based on whether the device is used to connect fixed radios or is deployed as a mobile device. Check with the FCC-certified frequency coordinators on what additional licensing will be required for transmitters connected to your gateway. 27 Land mobile radio (LMR) is a particular classification of radio systems that includes common dispatch, car-to-car, and portable communications used by public safety agencies. License fees are required for other types of wireless systems, such as microwave links. 28 The Association of Public-Safety Communications Officials – International, Inc., provides an explanation of frequency coordination on its web site. See: http://www.apcointl.org/ frequency/WhatisFC1.html. 29 See http://wireless.fcc.gov/publicsafety/coord.html. Chapter 7: Scope the Work to Be Done 113 Assessing the Scope of Work to Be Done You have reached a decision point. Just how big is the project and how much of it do you want to take on? That might seem like a philosophical question (particularly if you were, well, assigned to manage the project), but from a more practical and less personal standpoint, there’s a consideration. Do your agencies want to have the fine-grained control over all system acquisition and implementation activities that yields the most customized and highest performance system, or are you comfortable handing off some or all of that responsibility for manageability? What Are the Choices? Don’t rely on vendors’ measures of “interoperability.” It’s not an easy decision and not necessarily black and white. At one end of the scale are agencies that have relied on a single radio vendor for so long that they will buy whatever the vendor offers as an interoperability solution. Not only will they buy it, but they’ll use the vendor’s functional and performance specifications to evaluate “success.” This is an abrogation of responsibility that leaves real needs unsatisfied. Consulting for major systems design and implementation can be expensive because there’s a lot of work involved. At the other end of the scale, some agencies proceed with large systems design and acquisition by being the general contractor, so to speak, themselves. They take on all responsibility for engineering design, construction, acceptance testing, and integration of the diverse subsystems that make up modern communications systems. What they can’t do in house, they contract out piece by piece. The advantage is better needs-based design and project accountability. The disadvantage is that it can be a huge amount of work. In between these extremes is the rest of the world. Few agencies have the internal resources to take on all these duties, so they usually end up contracting out some or all of the tasks that have to be accomplished in a big system implementation. The trade- off is in finding the right contractors to take them on. And, of course, every project is going to have a different combination of the required tasks. What Will You Handle Internally? How do you decide what share to handle internally? Start by looking at the participants’ willingness to define the scope and level of work required. By this point in your project, you should have a pretty good idea of internal resources available for the work ahead. Of course, major system vendors are very willing and usually quite interested in taking care of all your needs. While this comes at a cost, don’t forget there is a good reason for this: Vendors will undertake tasks that you may not have adequate or appropriate resources to do. As you proceed, consider which roles are best managed closely for your project and with your resources. Part II: How Is Interoperability Achieved? 114 Recommendations Our recommendations on proceeding through procurement to implementation are based on the scope of the project as reflected in its anticipated cost. Independent integrators can be more objective in advising you of needed organizational, operational, and management changes. For systems expected to cost less than $500,000, plan to act as your own general contractor. Rely on either internal engineering expertise or contract for it. Little site development is expected for projects this size, so engineering is reduced. For projects of this size and smaller, agencies often rely on regional radio service companies with whom they have existing contracts. For systems up to a few million dollars, consider using a turnkey procurement where the winning vendor will take care of all the system design and implementation work. Projects of this size are generally larger than what agencies can comfortably take on themselves and small enough to make contracting for the parts separately unnecessarily time-consuming and costly. A project management or quality assurance consultant may be a good investment to improve your project’s odds of success. Our recommendation for systems costing more than a few million dollars is to hire a systems integrator separate from the primary technology vendor or vendors. This gives you more direct management control of the project. Good integrators can help not only in moving your project from conceptual design through implementation and on to full operations, but also by bringing a wealth of experience in dealing with technology vendors. Their reputations are built on assuring project quality for their customer—your agencies—by getting the most for your dollars. Develop Your Own Recommendations and Get Approval These recommendations are just rules of thumb, of course. You and your project team are the best judges of what can reasonably be accomplished internally and what can affordably be outsourced. With the consensus of the User and Technical Committees, seek Steering Committee approval to move forward with further project planning and procurement based on the agreed-upon scope of work. With that approval in hand, you’re ready to create the project plan! Chapter 8: Create a Project Plan What The project plan is a document that guides the entire design, procurement, implementation, and future operation of an interoperable system. It provides the detail necessary to manage each phase of the project and the multitude of activities involved in each. It includes components for controlling the critical Scope-Budget-Timeline relationship,30 as well as managing risks and communicating about the project with stakeholders. This document will evolve over the life of your project. Why Project planning—the dynamic process of creating a project plan—dramatically increases the chances for success of interoperability projects. Plans keep both internal and external stakeholders informed in varying levels of detail. They provide the means to control activities, detect problems early on, and respond to changes along the way. Who The project manager and the User and Technical Committees are involved in discussions, decisions, and research. The project manager should be responsible for project plan documentation. The Steering Committee and executive sponsor must endorse and sign the plan. When Following formal development of the decision-making structure (Chapter 5) and in conjunction with the development of the needs analysis (Chapter 6). Original Tech Guide Icon Project planning is the focus of Part III of the Law Enforcement Tech Guide. The topics of scope, timelines, budgets, risk management, and project communications are dealt with in depth through its six chapters. This chapter draws heavily from them, while emphasizing key aspects for interoperability projects. Chapters 8 through 13 of the Law Enforcement Tech Guide deal with project planning for technology projects in general. 30 As mentioned in the original Tech Guide, throughout your project, you will need to constantly balance the constraints of time (length of time the project takes to complete), scope, and cost. Should any one of the three “triangle” components grow, there is a direct effect on the other “corners” of the triangle. Thus, as scope grows, so does the project costs and its scheduled completion time. Part II: How Is Interoperability Achieved? 118 The project plan is a working document. “Planning” is such a painful word in some public safety circles that the thought of creating another plan—or set of plans—may not be particularly appealing in your current quest to improve communications interoperability. On the other hand, few of us would dream of sending carpenters, plumbers, and electricians out to build us a new house without an agreed-upon set of blueprints in the general contractor’s hands. Properly done, your project plan won’t be one of those documents that are quickly shelved—it will be a dynamic, evolving document that is continuously used to manage the project. Before getting started with creating a project plan, recognize that multiagency technology efforts are particularly at risk of failure. Institutionalized barriers to communications across organizations affect our ability to jointly manage projects, requiring careful and practical definition of the scope of projects, timelines, budgets, and how risks typical to technology projects will be managed. Obviously, these barriers contribute to the very “first responder” interoperability issues you’re working to resolve. Project planning improves odds of success. The project planning process, itself, improves the odds of success by bringing stakeholders to a common agreement on details. It produces a detailed, actionable plan to achieve the project’s objectives. A plan developed by the project manager with input from working groups and accepted by the project’s Steering Committee is a powerful tool to manage the complexity of interagency initiatives. Throughout the following, we are assuming you are or will be the project manager. Your project plan will establish the scope of what will be accomplished, set a timeline and budget, and include subplans for managing project risks and communicating project activities and statuses. The cyclical process of creating and maintaining one throughout the life of a project makes assumptions explicit and decisions binding. Project Planning 101: Set the Scope and Objectives With a firm understanding of the interoperability goals to be achieved and a broader understanding of the needs existing across agencies to meet those goals, you can now document and define the project’s detailed scope and objectives. Scope planning fleshes out your charter’s initial scope statement with requirements developed during needs analysis and details from the conceptual design. It provides the most basic elements of the project plan. The three pieces of a good project plan that deal with scope are as follows: 1. Scope statement 2. Project objectives 3. Scope management plan. Chapter 8: Create a Project Plan 119 Executive Sponsors Icon PREPARING FOR CHANGE Technology projects generally accompany and lead to lots of organizational change. Communications interoperability projects can lead to even more upheaval because they affect not only internal processes, but also relations between organizations. Voice and data radio communications are such critical tools for emergency responders that any disruption of current capabilities, in particular, threatens to cause some serious push- back on the project from the field. Executive sponsors: Change management is an integral part of project management. Prepare your organizations for change by requiring a formal plan that controls the project scope, budget, and timeline to achieve the interoperability goals and objectives you have set out. It should include a section on how the risks inherent in large projects, in general, and your project, in particular, will be managed. It should also include a plan for communicating progress realistically to all stakeholders, including line staff, supervisors, management, and any stakeholders beyond your organizations. Manage the expectations of your employees and make sure they have reason to share ownership of the project’s success. Follow these steps to establish your project scope and objectives. Step 1 Draft a Scope Statement Project Managers Icon As project manager, your first scope-planning task is to assemble a draft statement with definitions of what’s in and out of the project, supporting detail for the project’s business case, and the assumptions and constraints that will shape its outcomes. Be sure to include any grant requirements that you already know about. They will have a definite effect on the project. The scope statement serves in this form as an incomplete working document for the next steps. Add an initial work breakdown structure31 to describe the phases and individual activities in sequence that will take the project from conception through design and implementation to ongoing operations (see Figure 8-1). At this point, focus more on what the activities will be, their interdependencies, and how they proceed in sequence than on how much time they will take. Your timeline will be set a bit later on. 31 Work breakdown structure is a “deliverable-oriented grouping of project elements that organizes and defines the total work scope of the project. Each descending level represents an increasingly detailed definition of the project work,” according to the Project Management Institute. It is typically represented as a timeline of related activities, in sequence, and showing visible outcomes (deliverables). A Guide to the Project Management Book of Knowledge, 2000. 120 Part II: How Is Interoperability Achieved? ExAMPLE SCOPE STATEMENT The communications interoperability project will establish one interagency voice channel for all police, fire, and EMS agencies in the county for on- scene command coordination. Interagency command communications are necessary only within a 1-mile radius of an incident command post, which may be established anywhere in the county. Funding limitations suggest that complete replacement of all disparate systems in use will not be possible. Console patching of agency dispatch channels will not be an acceptable means of meeting this need. Use of gateway devices linking existing channels or systems may be acceptable if specifically designated agency tactical channels or talkgroups are used. No new radio frequencies will be licensed. Training and exercises for county communications technicians and all responders will be conducted. Image of Flowchart with the following text: INTEROPERABILITY PROjECT Project Management System Design Equipment Procurement Equipment Installation Communications Technician Training Responder Training Tabletop Exercises Full-function Exercises Figure 8-1: Sample Work Breakdown Structure Chapter 8: Create a Project Plan 121 Step 2 Draft Project Objectives and a Scope Management Plan Operational Experts Icon Bring the User Committee together in a working session to take preliminary project objectives from the charter and adjust them based on the results of your needs analysis, documenting the rationale for later justification to the Steering Committee. This statement of objectives should establish specific, detailed measures of success. Use any objectives implied in the scope statement and provide additional details, if necessary. Original Tech guide Icon, Page 124 The Law Enforcement Tech Guide includes further advice on defining practical, yet measurable project objectives. For the example project above, objectives might include the following: + Communications between responders for command purposes should be possible at any location within the county that is otherwise suitable for an incident command post. + Communications should be possible within a 1-mile radius of an incident command post. + The interagency command channel should be available to responders without requiring the intervention of other personnel. With draft objectives in hand, the project manager and User Committee can draft the final part: A plan for managing the scope. Ultimate approval for scope changes should be left to the project’s executive sponsors to make sure that the original vision isn’t being compromised. Original Tech Guide Icon, Page 125 The Law Enforcement Tech Guide provides details on the issues to be addressed in a scope management plan. Relevant statements for our example above include: + Project scope changes must be approved by the city police and fire chiefs, as well as the county EMS director. + Proposed limitations to the geographic availability of the command channel will be evaluated by the Technical Committee. Recommendations with estimates of cost for overcoming the limitations will be provided to the Steering Committee for consideration and comment before submittal to the police chief, the fire chief, and the EMS director. Scope changes will occur. Project participants learn more as the project proceeds, affecting their ideas about what’s possible. Agency needs may shift, affecting the very real definitions of what has to be made “interoperable”; or market changes may bring new technological options to meeting needs. 122 Part II: How Is Interoperability Achieved? PERFORMANCE MEASURES For interoperability projects, performance measures may include such things as the availability of interagency channels, the speed with which gateways are activated or deployed, the required coverage of systems linked together, and much more. Focus on operational measures of success: The observable effects of good interagency communications. We’ll have more to say about measurable improvements to interoperability in Chapter 15, Measuring Interoperability. Just remember: Performance measures are a key part of your project plan and must be contemplated at the earliest stages of a project. Your ability to identify when the project scope is changing, how it will be dealt with, and who has authority to approve changes is critical to project success. Step 3 Get a Technical Reality Check Technical Experts Icon Your Technical Committee should review the scope statement and project objectives at this point. The committee will have valuable input to assure that technological barriers, such as unachievable levels of radio coverage, haven’t been inadvertently inserted into the project. The purpose of working the draft through the User Committee first is to focus objectives on operational measures of success. This doesn’t mean there aren’t important technical aspects to scoping your project. Because your interoperability project will most likely involve adding new technology, the Technical Committee will have particularly valuable input on the work breakdown structure defining implementation activities and their sequence. Have the committee help establish meaningful milestones in the implementation phase to include as deliverables in vendor contracts that can be used for incremental payments. Step 4 Get it Approved! Regional Icon The final step in scoping the project is getting sign-off from the Steering Committee and, finally, the executive sponsors. Because this key piece of the project plan puts meat on the sponsors’ strategic skeleton and defines what everyone will follow, their formal approval is important. Use the occasion of presenting the scope statement, project objectives, and management plan to the Steering Committee and executive sponsors as an internal milestone to rightfully mark its importance in moving from planning to action. Note Chapter 8: Create a Project Plan 123 the intent to require executive sponsor or designee approval of any scope changes to keep the project focused. Project Planning 102: Develop the Timeline With the scope now defined in detail, a timeline can be built as the next step in project planning. It can usually be drafted by the project manager in near final form based on the definitions of activities and work breakdown structure arising from the scoping process (see Figure 8-2 on page 124). Original Tech Guide Icon, page 129 The Law Enforcement Tech Guide dedicates a chapter to this project-planning step and the material doesn’t need to be duplicated here. Remember that the timeline includes not only the sequence and the amount of time individual tasks will take, but also how they’re grouped into meaningful phases and further demarked by milestones and deliverables. Sound project management practices require clearly identifiable points of progress. This is most practically, often graphically, depicted in a project timeline. Keep in mind that interagency projects of any type are notoriously “delicate,” often depending on the leadership of key individuals and a regular supply of goodwill. Broken schedules and overdue projects strain the tightest project teams. Stakeholder frustration and skepticism can boil over when unrealistic expectations inevitably crash into reality. Manage your project timeline well to maximize tangible resources and—more important—to maintain that intangible cooperative spirit. From the timeline submitted in the first project plan to closing out the project, the project plan revolves around the timeline. Update it regularly and keep it before the project team. Project Planning 103: Estimate and Deliver a Budget It’s inevitable. At some point, it comes down to money. Actually, some project managers are excited by the money aspect of their projects. There’s some vicarious pleasure to be had in spending large amounts of money effectively to help public safety responders. Nevertheless, it can be challenging to be a responsible steward of taxpayers’ hard-earned money. The budget portion of your project plan can be completed once the scope is defined and your timeline in place. Costs are initial and recurring, internal and external. Technology projects of almost any size face initial and recurring costs, incurred both within the participating agencies and through external procurements. Initial costs are 124 Part II: How Is Interoperability Achieved? Take into Account the Following Special Time Aspects for Interoperability Projects: The inherently multiagency character of communications interoperability projects requires that additional time be built into schedules for all aspects that involve formal approvals, such as memoranda of understanding and cost-sharing agreements. Agreements can take an extended amount of time, particularly as more legal review across affected agencies takes place. Manage this time aspect by ensuring that Steering Committee members have delegated decision-making authority. Use a regular meeting scheduling process where issues requiring further internal agency review are announced prior to a meeting, presented for consideration during it, and scheduled for decision at a subsequent one. Regularly used, this structured process will help your project move steadily forward. Image of Alarm Clock Ringing Voice and data communications projects, alike, are often expensive, span multiple budget and grant years, and require time-consuming competitive procurements. Create an ad hoc committee of agency fiscal, grant management, and procurement specialists to make sure your timeline takes into account the cyclical and often time-critical aspects faced by these important partners. Their buy-in to the project can yield benefits long after the timeline is in place! Image of Alarm Clock Ringing radio projects often involve civil construction, public hearings, zoning variances, environmental assessments, permits, and licenses. In many areas of the country, seasonal weather even determines when building can occur. Every one of these aspects can throw a monkey wrench into the gears of a finely tuned timeline. Manage these schedule killers by building in plenty of time for their completion. Start the related tasks early and pad the timeline with contingency activities that can be moved in to take advantage of delays. Carefully analyze and define dependencies between activities in the work breakdown structure to compress the timeline where possible by carrying out tasks in parallel. These techniques are all tools in the project manager’s kit for dealing with such monkey wrenches. Figure 8-2: Special Time Aspects for Interoperability Projects Chapter 8: Create a Project Plan 125 all those that come about before the system is put into operation, while recurring costs arise afterwards. Internal costs are those over which the project participants have most direct control, while external costs generally come in the form of hardware, software, and services. Cost estimation along these two dimensions is key to a sound project budget. You will probably begin by focusing on initial external expenses. As the costs of outsourcing everything from project management to radio installation start to add up, look for costs that may be covered and managed most effectively within the participating agencies. Don’t make the mistake of assuming that internal costs—initial or recurring—will be covered without documenting and quantifying those assumptions. From a project manager’s perspective, that’s a good way to get shortchanged when you turn to project partners and find they have no means of carrying their share of internal costs. Begin by identifying the costs of which you are aware. Use a chart to categorize them according to when they’ll come about and where they arise (see example in Figure 8-3). Image of Cost Identification Chart, broken down into: Initial Internal Costs Project workspace Project management labor Remodeling of central facilities New intranet drops Overtime for training Mobile radio installer labor Acceptance testing costs Internal cost recovery fees Initial External Costs Property Radio Site Infrastructure Network infrastructure electronics User radios Network management software Controller computers and software System engineering Construction services Integration services Recurring Internal Costs Physical Infrastructure Maintenance Itnernal network cost recovery fees Refresher training and exercise costs Technical support labor Radio programming New fleet installation costs Recurring External costs Maintenance contracts and upgrades Radio site and tower leases Software license fees Electrical service to radio sites Backbone network services Tower inspections Infrastructure repair User radio repairs and replacement Figure 8-3: Example Cost Identification Chart 126 Part II: How Is Interoperability Achieved? Grant Requirements Icon Most grant programs being tapped today for communications interoperability projects require that local funds be used for property, towers, and permanent construction. remember that many grant funding programs for technology will pay for up-front start-up costs, but will not pay for recurring costs. Protect your budget by thoroughly understanding all grant limitations! Follow these four steps in developing your budget: Gather Internal and External Cost Data Pull together cost estimates for each of the items you have identified. Often it’s difficult to quantify all these costs because details are embedded in budgets spread across multiple agencies. Still, estimates are important to show contributions by all project participants even if they’re made in the form of costs avoided. For example, significant initial and recurring costs for radio sites and tower space can be avoided at times through sharing of existing facilities owned by one project participant or another. External cost estimation is more art than science. Obviously, you’re in the earliest stages of defining your project at this point and have few ideas of what will ultimately have to be purchased. Most agencies are in regular conversation with their current communications vendors and can get budgetary estimates without running afoul of procurement rules, but check with your own purchasing officials before doing so. Alternately, you can turn to other agencies, issue a formal request for information (RFI), and even hire consultants regularly working in the field to help create budgetary estimates. The original Law Enforcement Tech Guide provides more information on these options. Step 2 Create a Project Budget of Initial Costs Your budget of initial costs will necessarily include many figures, small and large, spread across the project timeline. While detail will be important later on, recognize that estimates are bound to be rough at this point. Don’t create an artificial level of budget detail by including costs down to the last nut and bolt. You may know the average height of antennas above ground level at your radio sites and the going rate of feedline, but there is no sense in detailing that cost when the variance in major cost categories will be orders of magnitude greater than anything spent to connect radios to antennas. Original Tech Guide Icon, page 141 Use a spreadsheet with low and high cost estimates for each of the budget categories you choose to use. Budget detail beyond first and second levels will become important in later, updated versions of the project plan, but this should be sufficient to move forward with your initial version. Common first- and second-level budget categories for initial costs may be categorized as shown in Figure 8-4. Chapter 8: Create a Project Plan 127 Image of clipboard Common first- and second-level budget categories for initial costs Personnel services Project management Personnel services Technical support Training and exercises Professional services Project management Needs analysis Conceptual design and engineering Procurement management Systems integration Construction management Radio license application preparation and coordination Acceptance testing Training Physical infrastructure Real estate Site construction Site heating, ventilation, and air conditioning (HVAC) Primary and emergency power systems Tower erection Backbone network infrastructure Microwave radios Multiplexers and channel banks Gateway systems Leased-line installation Installation and optimization Radio frequency (RF) infrastructure Antenna and combining systems Site voice and/or data radios Supervisory control and monitoring systems Central electronic banks and network hub equipment Control station radios Installation and optimization End-user hardware and software Portable radios Mobile radios Mobile computers Vehicular modems Dispatcher console equipment and software Application software Other Contingency Bonding Figure 8-4: Common First- and Second-Level Budget Categories for Initial Costs 128 Part II: How Is Interoperability Achieved? A BUNDLE OF COSTS Large radio system vendors will prefer to act as your systems integrator, bringing all the complex pieces of a modern radio system together. They’re very capable of doing so and generally can better guarantee that their own products will perform if they do. The downside is that the service doesn’t come free and you’ll probably pay a premium for commodity items that you could buy “off the shelf.” Prepare yourself to be a good consumer. Take the time early in your budgetary planning to break out cost estimates for services and subsystems. This will give you needed detail later on for the procurement process and beyond to contract negotiations. Information is your primary tool in managing vendor relationships. Don’t give away the farm by ignoring costs that can be buried in system integration and implementation services. Step 3 Estimate Recurring Costs Recurring costs for your project will be highly dependent on the amount and cost of new technology implemented. Today, radio systems are priced much more like computer systems, with maintenance packages offered by vendors that cover incremental software upgrades and even remote monitoring. Hardware upgrades may be necessary for certain software upgrades, much as they are with computers. If your system is as successful as you hope, recurring internal and external costs may actually be greater than initial costs. The rule of thumb for estimating annual software and hardware maintenance contracts is 10 percent of the original purchase price. Other recurring costs, such as internal technical support, training, and site leases, can be significant, too. For example, monthly site leases for prime radio tower real estate are $1,000 a month and more. One Virginia county had been quoted $13,000 per month for three commercial radio sites that its vendor had chosen. It’s important to have a sense early in this stage of your project if such recurring costs will be faced. Step 4 Plan for Ongoing Budget Updates Original Tech Guide Icon, page 145 Just like the other part of the project plan, your budget needs to be maintained throughout the project lifecycle. The Law Enforcement Tech Guide points out that the entire project team needs to understand that a budget is a projection. Through regular updates, the project manager communicates this reality while providing current best estimates. As the project proceeds, adjustments will be offered and adopted or altered by the Steering Committee to ensure that its goals are met. Chapter 8: Create a Project Plan 129 Project Planning 104 : Create a Risk Management Plan The term risk management is common enough in modern parlance, but the formal process of a plan to deal with risks in technology projects is unfortunately uncommon. Proactive identification and evaluation of risks is a proven means of keeping projects on track when the inevitable happens. Think of it as an insurance policy to deal with contingencies. Risk management isn’t a one-time effort, though. It starts once the project scope is defined and continues through the life of the project as phases are completed and milestones met. It’s of such importance that the entire decision-making structure should be involved in creating and ultimately accepting the plan. Original Tech Guide Icon, page 150 A four-step process for creating a risk management plan is presented in the Law Enforcement Tech Guide. The process of identifying risks, categorizing and quantifying them, determining your tolerance level, and creating a response plan is the same in communications interoperability projects as it is in others dealing with technology. It comes down to understanding and preparing for problems that may arise. (Figure 8-5) Figure 8-5: Common Risks in Interoperability Projects Image of cartoon figure navigating rocky road Loss of key staff or participants Loss of an executive sponsor or the project manager has the greatest impact on projects. Loss of funding sources usually have to come together to make them possible. Loss of a key funding stream or the inability to match a grant can require huge scope changes. Bid protests In a competitive field for high-stakes contracts, vendors are often willing to play hard for business. Bid protests can result in significant time delays. Construction delays funding at risk. Frequency licensing problems Radio frequency spectrum may be one of the most scarce resources that has to be managed in the project. Licensing delays or disputes can have a serious impact on schedules. Public protests Given the expense of communications projects, several funding Any number of events can delay necessary building. Given narrow funding windows, delays can put There’s nothing like a new radio tower going up in someone’s backyard to cause public protests. 130 Part II: How Is Interoperability Achieved? Stop Sign Icon Examples of risks in radio projects abound. A statewide project in Alaska struggled through the replacement of its entire executive sponsorship council and two project managers over a 2-year period. A large California city experienced a 1-year delay in its interoperability project when it couldn’t come up with the required match for a grant. In New York, a losing vendor protested an award that was several times the agency’s initial estimates, yet still one-third of the cost of its own bid. A Pennsylvania project faced serious delays when its radio tower vendor went bankrupt. Frequency licensing mistakes cost a Nevada agency its entire $14 million system when the FCC forced it off the air and another $10 million for equipment to operate on a pre-existing system of another agency. A Michigan agency spent $200,000 for a study to determine why migratory birds collide with its towers after being challenged by wildlife groups for not doing environmental assessments on the towers. Every project will have a different set of risks, likelihoods, and impact areas, just as every project team will have a different assessment of the severity of the risks and its own tolerance for them. For example, of two jurisdictions facing difficulties obtaining radio channels, one might choose to proceed with work that can still be done, while another might temporarily halt the project to avoid putting more money at risk. Risk evaluation and management decisions should involve the whole team. Project Planning 105 : Communicate Plans and Progress It shouldn’t come as a surprise that any project to improve interagency communications can, itself, benefit by strategies to communicate with stakeholders. The process of documenting everything from initial project meetings to the charter and beyond provides the raw materials for good project communications. It also yields the historical information that should be kept in case of personnel changes, for grant reporting, and for future project planning. The last piece of your project plan is a formal plan for how you as the project manager will report in various directions to all stakeholders—internal and external. Original Tech Guide Icon, page 161 The Law Enforcement Tech Guide provides an example chart showing how the variety of stakeholders can be kept appropriately informed. It describes by team member what information is needed, the amount of detail required, the frequency of communications, and the methods of delivery. Appropriately, you will have been doing a good bit of communicating along these lines by the time this part of your project plan is in place, but now’s the time to formalize it. Chapter 8: Create a Project Plan 131 Focus your communications plan on getting accurate and complete, yet succinct, information to stakeholders at all levels. Each group represented in the project team and outside of it will want different information. Plans and the progress being made to achieve them will be of general interest, but from different angles. For example, upper management is much more interested in budgetary details and personnel assignments than the general public will be. Think like a wise man but communicate in the language of the people. —William Butler Yeats The different messages have to be communicated in the form best suited to the audience, focused on their areas of interest, and in appropriate terminology. Focus general information on the operational outcomes of the project and practical matters of progress, such as phases and milestones, making spare use of technical terms and jargon. We’re convinced that traditional oral and written reports are still invaluable. Well- delivered in person, they persuade and assure like no e-mail or other electronic process can. Make the most out of your opportunities as project manager to present the project in person. Tips Icon INTEROPERABILITY SUMMIT More notes from the U.S. DOJ Interoperability Summit Communications + Establish a communication plan that creates a reporting structure with and between committees and uses graphic depictions to show reporting responsibilities. + Use daily briefings between key project team members to manage information flow. + Keep agency public information officers informed about the project. + Limit who communicates with vendors. 132 Part II: How Is Interoperability Achieved? Communicating Across Agencies: The Project Web Site Communications interoperability projects are challenged by the fact that stakeholders are spread across multiple jurisdictions, often separated greatly by their respective agencies’ information systems. While it’s not impossible to communicate well with team members who are widely dispersed, some common collaboration and office productivity tools aren’t as available as they might be if everyone were in the same building. Because of this, we’ve been encouraged in recent years to see growth in the use of project web sites to communicate with stakeholders, including the general public. One good example that can’t be done justice on the printed page is the Louisville (Kentucky) MetroSafe web site (Figure 8-6). Louisville Metro, the area’s consolidated city and county government, uses the site to provide information on its communications projects.32 Figure 8-6: Louisville (Kentucky) MetroSafe Web Site Image of screen shot of Louisville (Kentucky) MetroSafe Web Site Elsewhere, the state of Hawaii has found that web technologies can be used to create an internal network (“intranet”) portal where employees can collaborate, create their own web pages, and otherwise share information. It’s particularly interesting in that 32 See http://www.louisvilleky.gov/MetroSafe/. Chapter 8: Create a Project Plan 133 it’s built from freely available software components. The Hawaii Information and Communication Services Division offers a short video demonstrating the portal.33 Commercial products drive most project portals that we’ve come across, however. Microsoft SharePoint® web collaboration software is popular in agencies that use the company’s office productivity and server applications. SharePoint is easily integrated with those other applications, intuitive, and well supported by an army of value- added resellers. There are even interagency collaboration tools for incident response built on the platform. Hosted web sites can be cost- effective and simple to manage. As with any open source or commercial software of this complexity, initial setup of web portals and system administration requires trained IT specialists. On the other hand, there are an increasing number of portal hosting services. These online businesses will provide World Wide Web access to your project web site hosted on their computers. Portal-hosting companies typically provide all the services you would have with similar software purchased and installed on your own systems and networks, although they can’t easily take advantage of any internal e-mail, calendaring, and other office productivity services your agency has in place. This isn’t a critical factor in choosing to use hosted portal services for interoperability project participants spread across multiple jurisdictions. Costs are reasonable, too. Hosted SharePoint services, for example, currently run from $20 to $75 and higher per month, depending on the amount of document storage and network bandwidth needed. Freely available web services can help with interagency project communications. Portals of any type still take considerable time to configure and manage—hosted or otherwise. If that’s beyond your interest, skills, or available time, there are still options. At least one agency is using the popular web service Yahoo!® and its “groups” feature for its multijurisdictional project to create a shared e-mail and chat services, file storage space, calendar, and even poll-taking capabilities. If you need a few more project management capabilities, check out the simple hosted services34 at Basecamp™. A single project for an unlimited number of participants can be set up at no cost. Messaging, to-do lists, task assignments, and milestone calendars are available, but you will have to pay a modest fee to get file exchange capabilities, encrypted network access, and multiple project support. 33 See http://www2.hawaii.gov/dags/icsd/content/video/higovdemo_250k.asf. The state of Hawaii portal is built on the freely available open source products COREblog™, Zope®, and ZWiki™. 34 See http://www.basecamphq.com/. 13 Part II: How Is Interoperability Achieved? Graphically Communicating Roles: The RACI Matrix To be prepared is half the victory. —Miguel De Cervantes One final communications technique we would like to share is the use of a RACI Matrix—a matrix of processes and project roles (see example in Figure 8-7). The matrix itself is simply completed by entry of the letters R, A, C, and/or I to further indicate work duties or roles for listed activities. The initials stand for: R Responsible Who does the work or owns the problem? A Accountable Who signs off on or approves the work? C Consulted Who has information needed to do the work? I Informed Who needs to be notified of the results? With these five pieces in place—the scope statement, timeline, budget, risk management, and communications plans—your project plan is complete…for now! While it will surely be a good plan with all these elements, a great plan is the one that is up to date. The work roles may be shared and an individual may have more than one. For example, the Steering Committee is broadly accountable for most project activities, but in some cases also has to be consulted in depth for further information on a subject. Implicit in the chart is that anyone accountable or consulted on work is also informed of results. Image of RACI Matrix Figure 8-7: RACI Matrix Example Courtesy of the 5 Star Team, http://www.5starteam.net Chapter 9: Acquire the System Components What The structured, iterative process for acquiring the services and physical components to create an interagency communications system, whether voice or data. Why Communications interoperability usually requires new or additional systems that have to be designed and procured. Lack of a well-organized process leads to wasted time, money, opportunity, and goodwill between partners who are dependent upon cooperation. Who The project manager is at the center of system acquisition. Members of the Steering Committee serve in additional roles, as do members of the working committees. Special ad hoc teams are often necessary for legal, community relations, and procurement assistance. When Acquisition occurs once needs are defined and the initial project plan is created. It proceeds through design and functional specifications to procurement and contracting. How is communications interoperability different from other types of technology projects? While it’s rarely recommended for agencies to create their own computer-aided dispatch (CAD) systems or records management system (RMS) software from scratch, it’s inevitable that radio projects require lots of detailed design and engineering. As with any kind of technology project, multiagency efforts naturally add layers of complexity through complex interaction of needs, financial abilities, and procurement rules. Original Tech Guide Icon This chapter builds on the Law Enforcement Tech Guide’s Part IV, Acquiring the Technology. Chapters 14 and 15 of the original Tech Guide provide procurement and contracting advice that will serve you well in your project. We won’t rehash those equally applicable details here, but instead will focus on the unique aspects of interoperability systems acquisition. Be sure to read and use the Tech Guide’s advice! 138 Part II: How Is Interoperability Achieved? Public safety technology projects, in general, and communications interoperability projects, in particular, are put at severe risk when they are approached merely as a procurement exercise. The complexity of these projects requires an organized, structured process for proceeding from the needs you’ve collected to a detailed design and on to the often-expensive process of acquiring services and the physical parts of your system. There’s a direct correlation between how rigorously this phase of your interoperability project is approached and its chances of success. Even if a large share of the technology to improve interoperability between agencies will be purchased from a single vendor, a solid process of defining, designing, specifying, and buying the system is needed to manage both the project and the vendor. One key way to manage such complexity is through iterative steps of design, procurement, and implementation. Through a process of decomposing the work to be done, more detail about the “system” is developed. All stakeholders learn more about the components of the system and how they fit together. This progressive process allows the project to be broken down into manageable pieces—some may be executed entirely by the participating agencies and others through the help of communications systems vendors and service providers. Assumptions: We have to make some assumptions about your project. Not all interoperability initiatives require massive system changes or new radio purchases. Your project may be focused on the simple process of swapping radios between agencies during an incident so each may talk to the other. It may be to program channels commonly available between agencies in everyone’s radios. Here we’re looking primarily at projects that eventually require that some additional or new technology infrastructure be put into place. Both voice and data systems follow the processes described here, though with data systems there’s also an additional effort to find and implement software applications. The process diagram (Figure 9-1) depicts the steps that have been recommended that would lead your project up to this point. It shows the progressive process of system development. Chapter 9: Acquire the System Components 139 Figure 9-1: Design and Acquisition Processes Image of flowchart 140 Part II: How Is Interoperability Achieved? If they didn’t seem so before, the processes have to seem daunting now! Don’t worry. We will break down the work needed to get from beginning to end into steps and decisions to be made along the way. It’s tempting to turn the checkbook over to the first vendor who offers big promises to solve your interoperability problems. Don’t do it! As we’ve been saying all along, interoperability isn’t primarily a technology problem. There are many organizational, operational, and technical function changes to be made to improve interagency communications in most regions of the country. A final note before we get down to it: Improved interoperability results from improved communications (in both technical and nontechnical senses) and cooperation. It truly requires a system of related technical and nontechnical systems. The system definition and acquisition phase of your project is one requiring particular attention to managing relationships—not only between your operational partners, but also with the communities being served by and paying for this initiative, as well as the equipment and professional services vendors you’ll need as partners. Manage the relationships. Don’t let the new system of systems ever become a divisive influence, which happens when participants lose sight of the goals. System Acquisition 101: Groundwork Any sufficiently advanced technology is indistinguishable from a rigged demo. —James Klass There is a bit of groundwork to be laid before moving into actual acquisition of system components. Not every project will require all the work we’ll discuss, but large voice or data systems require most, if not all, because of their complexity. Indeed, if your needs analysis discussed in Chapter 6 led to a decision to simply buy services to improve interoperability, as opposed to building new systems, then you’re moving directly to the procurement steps described near the end of this chapter and in added detail in Chapter 14 of the original Law Enforcement Tech Guide. Generally, you move into the acquisition phase of your project by first understanding relevant procurement and contracting rules and how the project teams will be structured and staffed. Through these steps, you’ll move from a conceptual design to procurement and contracting. Step 1 Research the Rules Grant Requirements Icon Moving into any procurement, project decision-makers need to be aware of the rules that govern it. The project manager bears particular responsibility. This can be quite a challenge in large interoperability projects that span organizations, jurisdictions, and Chapter 9: Acquire the System Components 141 sometimes even state boundaries. They are increasingly funded through a complex mix of grants, tax revenues, and fees that bring special challenges to management of the project budget. Not only do funding stipulations limit what can be purchased, under which processes, and in particular timeframes, but they also limit how ownership can be shared across organizations. It’s easy to imagine how difficult agreements between jurisdictions can be when joint or equitable ownership of shared system components for interoperability is impossible. Don’t work yourself into an acquisition corner by failing to understand your agency’s purchasing and contracting rules, as well as those of your partners. There is a way to deal with the complexity: Get help! Today’s competitive procurements are so technologically and administratively complex that they require advice from a multiplicity of sources, including legal counsel and financial advisors. There are very real costs for this, too—as much as five percent of the procurement, in our experience. —Steve Proctor Executive Director Utah Communications Agency network We’ll touch on the array of teams that may be needed in a moment, but you can start by creating an ad hoc team of financial advisors from purchasing staff in each of the key involved agencies. With their help, create a broad plan on how to meet all agencies’ rules or, alternately, the project’s goals and objectives through financially discrete procurements. For example, it may be clear that one set of rules applies across the partners or that a couple key participants in the initiative can take on all purchasing responsibility. Before deciding how to proceed with system acquisition, consider that large procurements can rack up significant internal costs—up to 5 percent of the system cost. Step 2 Form the Teams With an idea of the amount of work involved and what share will be accomplished internally, create the teams to carry it out. Consider and select members from across the participating agencies as broadly as you can. This requires knowledge of individuals and their abilities that you, the project manager, may not have. Turn to Steering Committee members to help find talent from among their agencies. Talking with them also provides the opportunity to get their agreement to commit staff time to the project. A suitable proposal evaluation team for a turnkey procurement would comprise the same members, but include fewer of them. All or none of these teams may be necessary, depending on the size and scope of your project. Keep in mind that project participants can wear multiple hats—if they’re not already! Two working teams are particularly useful at this point: The procurement and policies/procedures teams. Procurement Team Presuming there will be some purchase of services or technology for your project, create a procurement team that will take responsibility for shepherding the process 142 Part II: How Is Interoperability Achieved? through selection of a procurement method, specifications development, proposal evaluations, vendor selection, and contracting. The team may bring in expertise for particular tasks—such as additional operational experts for developing functional specifications or legal counsel for contract negotiations. However, they have a central role to provide continuity through the entire process. Select members who have some background with purchasing. The ins and the outs of navigating a significant procurement aren’t skills most people are born with; they come from experience. Ideally, that comes with real operational experience of using radios as emergency responders, too. Policies/Procedures Team How agencies will work together drives many procurement functional specifications. The second team that can be kicked off right away is one to collect and meld policies and procedures between partnering agencies. Start this process early because the learning process involved can well affect functional specifications for any procurement. For example, if the agencies have or want a policy stating that a dispatcher must always be at the control point for connecting agency channels physically or logically through a gateway device, that establishes a functional need to be specified. Alternately, if they would require that a communications technician, as defined under the Incident Command System (ICS),35 be deployed during incidents of a particular size or larger, a transportable gateway may eventually be chosen in response to that functional requirement. Clearly, the procurement and policies/procedures teams overlap. They may share some members, but define them separately and have their work proceed in parallel—both to make the most of available time and because the work does not completely overlap. MAKE A NOTE OF IT! Tips Icon In order to keep your project focused on improvements in operations, limit vendor access to team members. If necessary, use an agreement for individual team members that requires them to direct all vendor inquiries through the project manager or designee. Don’t risk team members becoming advocates for particular technologies! 35 The Incident Command System, a key part of the National Incident Management System (NIMS), will be discussed further in Chapter 12, Develop Policies and Procedures. Chapter 9: Acquire the System Components 143 Tips Icon SELECT TEAM MEMBERS CAREFULLY In our experience, one key quality of a good project manager is the ability to pick the right people for the right teams. Not all potential project participants have the people skills necessary for good teamwork. Be careful with the engineering team; some of the most technically adept technicians struggle in teams. Select members for the engineering team who have no preconceived notions of the “best” technology and who work well with their peers in other agencies. Avoid dogmatic members of the engineering team—or of any team for that matter! Other teams may be necessary through the acquisition process. Set these into motion depending on what work you choose to take on internally and what you intend to contract out. Engineering Team Whether or not you contract for system design engineering, consider establishing an engineering team, typically comprising those involved in the Technical Committee. These people will either be responsible for or guide the engineering necessary for radio projects much larger than a single voice repeater or wireless data access point. Even in projects making new or additional use of existing systems, there is often an engineering and optimization aspect involved that requires technical steering. In the procurement process, the engineering team plays an important role in establishing technical specifications, eliminating those that unnecessarily limit choice, and serving later in the evaluation process. Construction Team Look elsewhere in the participating jurisdictions for civil engineering and construction expertise. As you might guess, a team to deal with the peculiar design, procurement, and implementation aspects of new physical radio facilities isn’t necessary in all projects. When it is, the skills of members are distinct. We’ll touch on the civil engineering aspects of some radio projects in the next section, but not every interior designer is qualified to excavate for a foundation or frame up a house. In addition to Technical Committee members who will have your best institutional knowledge of currently used and other potential radio facilities, look to your jurisdiction’s construction and building divisions for additional expertise. In many cases, the construction team has to oversee the work of contractors selected specifically for radio site development, permitting, and navigating zoning mazes. 144 Part II: How Is Interoperability Achieved? Public Relations Team We looked previously at the importance of communicating with the public about your interagency project to improve critical interagency communications. In the acquisition phase, community relations are critical when you start building new radio facilities. Try to put up a tower near an elementary school and learn a bit about “contract negotiations”! Turn to individuals within participating agencies who already serve this function. It requires another distinct skill set and persons already doing the work no doubt already have contacts and procedures for dealing with a multitude of community relations issues. Your Steering Committee members may also be in management positions suitable to help in this regard. Acceptance Team Use key members of other project teams for the acceptance process. We’re all looking for acceptance, right? Well, maybe so, but in the acquisition and implementation phases, acceptance is the process of using mutually predetermined measures between contracting agencies and contractors to determine when work has been successfully completed. While this is naturally seen as an activity taking place well into the process of building systems, there are at least two reasons for setting an acceptance or quality assurance team into motion early on. First, conditions for acceptance of work, whether services and/or technical implementation, should be spelled out in the procurement process. Your vendors are going to make sure they are spelled out in one form or another. It pays to go into the procurement process with clearly defined measures of what successful completion of an engineering design, construction management, or system optimization will be. Quality management is a distinct responsibility of project managers and is sometimes outsourced in large projects. Second, the acceptance team can be seen as providing a quality assurance function. In the world of technology project management, quality assurance is the recurring process of guaranteeing in each phase that a project’s objectives are being followed and incremental measures of quality are being met. Ultimately, given the tools developed through early project definition, conceptual design, detailed design, and functional specification, the acceptance team also functions in this role. Chapter 9: Acquire the System Components 145 THE HEAD COACH’S CHALLENGE Project Manager Icon If you’re the project manager of a sizeable interagency communications project, you may be looking at this list of potential teams beneath the carefully crafted decision-making structure you’ve already created and think the project might drown in a sea of organization charts. Don’t despair! While formal and ad hoc working teams are brought together to do specific, task-level work, they’re often composed of the same project participants—often most from the project’s standing committees. Your project management challenge here is to help team members understand that they’ll wear different hats while working in separate teams, but the team’s purpose is to take a focused task and carry it to completion. Distinguishing specific teams emphasizes distinct areas of work to be done and helps participants navigate the maze of tasks involved in large technology projects. Manage the project’s timeline by carefully having these teams work in parallel to one another. Clearly, the amount of overlap between members is going to affect how much can be accomplished by them, but good project managers compress timelines by having work done in parallel as much as possible. System Acquisition 102: The Art of Procurement Throughout the previous sections of this chapter, we have been talking about the work to be done to acquire a new system for improved communications interoperability. Understanding what has to be accomplished and how to organize the work will guide how you procure services and equipment. As we’ve mentioned, a detailed examination of what’s involved—to the extent of designing a good share of the system—guides your decisions on what tasks can or should be done internally and what needs to be contracted. The original Law Enforcement Tech Guide provides a veritable tour de force on the subjects of procurement and contracting. Guidance there is entirely applicable to radio systems and interoperability. We will step through its guidance in the following, referencing specific locations for your broader review. If your project is large or complex, you may have already chosen to contract out some services. Systems design, integration and management services, and site development can account for half or more of some systems, but for most projects, the largest procurement effort is for equipment. Costs include its purchase, installation, optimization, training, and initial operations. 146 Part II: How Is Interoperability Achieved? The procurement process proceeds through four steps: Selecting the right procurement tool, developing functional specifications, building criteria for evaluation of expected vendor responses, and executing the process. Step 1 Select the Tool Original Tech Guide Icon, page 176 The most common procurement tool used for radio systems is the request for proposals (RFP). The tool under one name or another is available to all jurisdictions. It allows you to state requirements and functional specifications, and then allows interested parties to propose solutions. The RFP is distinguished from an invitation for bid (IFB) in the flexibility it allows vendors to propose solutions for evaluation and the agency’s ability to negotiate costs based on what they learn. The request for information (RFI) is occasionally used by agencies in radio systems procurement, particularly to learn about technologies that can be considered. The RFI process is less formal and time-consuming than an RFP because they aren’t complete replacements for one another. An RFI may lead into a negotiated procurement, but is most appropriately used to collect information for the more formal process. In the rare cases where the RFI yields enough information to conclude there is a single, suitable approach, your procurement rules may allow you move to actual procurement. Step 2 Develop Functional Specifications We have talked about the need for functional specifications for acquiring interoperable systems. In the procurement phase, these specifications are put to paper in a form that will encourage thoughtful, often innovative proposals, yet allow you to evaluate whether the proposed solutions will meet your needs. Original Tech Guide Icon, page 179 The degree of specification will hinge on how you’ve chosen to proceed with the project. If you’ve chosen to go for a turnkey system, then functional specifications will be limited to operational aspects of how the system will be used and managed. If you’ve chosen to bring in a systems integrator independent of equipment manufacturers, you will have a standard set of specifications from the integrator to work through and select from. Functional specifications naturally flow from the organizational, operational, and technical requirements developed in your needs analysis phase. The Law Enforcement Tech Guide provides further guidance on how specifications for the procurement are chosen and worded. Chapter 9: Acquire the System Components 147 Grant Requirements Icon SOLE-SOURCE PROCUREMENT While it’s often tempting to go straight to a single source based on what you already know about radio systems, recognize that there’s great value in maintaining competition and options in any procurement. Use them to your advantage. Don’t rely on expected goodwill alone to deliver your agencies the best options at the best prices. Recognize that grants place significant additional procurement burdens on any sole-source purchases they are used for. See the original Law Enforcement Tech Guide, Page 178, and/or the Law Enforcement Tech Guide for Small and Rural Police Agencies: A Guide for Executives, Managers, and Technologists, Chapter 5, Understanding Procurement and Contracting http://www.search.org/files/pdf/SmallRuralTechGuide.pdf. Step 3 Build Evaluation Criteria Criteria for evaluating proposals and selecting the winner likewise flow from your specifications. They also arise from the value your agencies place on other factors. For example, your functional specifications may not have anything to say about the vendor’s qualifications, but experience, stability, and record of success are key criteria for evaluating radio system vendors that will provide critical technology for your interagency communications needs. You hope that the operational needs you’ve outlined and the functional specifications you’ve stated will lead to evaluation criteria that are carefully aligned with your agencies’ standard operating procedures (SOP) and incident response plans. For example, your policies/procedures team may have brought requirements to the table as to how the system has to work. They may have brought specific functional requirements for how a piece of equipment works, its electrical characteristics (such as “Intrinsically Safe” portable radios for use in potentially explosive atmospheres), or other physical characteristics. It’s also possible that your agencies have performance standards for particular work, such as the amount of time and effort required of dispatch to set up a patch between two channels. Original Tech Guide Icon, page 181 These SOPs and elements of response plans should guide evaluation criteria. Other examples of appropriate criteria and how they are presented are included in the Law Enforcement Tech Guide. These criteria are carried into a weighted evaluation process where particular, predetermined factors are accorded greater value than others based on your own sense of what is important. 148 Part II: How Is Interoperability Achieved? Step 4 Carry Out the Process Whew! With all this work out of the way, it’s actually time to carry out the procurement! Unless you’ve been involved in similar projects before, the amount of work involved in getting to this point may have come as a surprise. Trust that it’s all important to get you where you want to be: better interagency communications through your voice and data systems. Original tech Guide Icon, page 182 Your jurisdiction’s procurement rules, those of partnering agencies, and those brought as conditions of other funding sources determine the actual steps taken to release the procurement, await responses, collect proposals, step through evaluations, and make a selection. Cost is bound to be one of your greatest considerations, of course, although RFP rules for most jurisdictions don’t require that it is necessarily the predominant factor in making a selection. As a matter of fact, that’s a key reason why you created detailed evaluation criteria. It’s not uncommon for cost to be half of the total points accorded proposals for radio systems. Recognize that prices can be brought down 5 percent, 10 percent, and even more through negotiations, which we will talk about next. Through a formal and detailed procurement process, you will get sufficient information in responses to your RFP to decide how to proceed, even if the total proposed cost is well beyond what you expected. Believe us, it happens! Though you may have to go through a process known as “best and final offers” to further winnow out the selection, eventually you get to the point of identifying an apparently successful proposal. This will lead to negotiation of one or more contracts. System Acquisition 103: Create the Contract(s) You’re almost ready to move to implementation, which is what you have probably been anticipating since being asked to take on this project. However, the contracting process is perhaps the most delicate part of your entire project, so proceed carefully. It’s entirely possible for a poor contract not only to put your whole project at dire risk, but also the money, work, and goodwill that agencies have brought to the project up to this point. Don’t risk everything by either forcing through a bad contract or accepting one out of haste. Chapter 9: Acquire the System Components 149 Original Tech Guide Icon, page 187 The Law Enforcement Tech Guide dedicates an entire chapter to this subject. It is entirely applicable to your interoperability project. We’re not going to repeat its good lessons here, although we do have a few tips to pass on when it comes to dealing with these specific types of projects. Learn to negotiate or use professionals. It surprises us to see law enforcement agencies that are adept at the very serious process of hostage negotiations simply cave in when it comes to negotiating with technology vendors! Take the contract negotiations process seriously and turn to professionals, if necessary, to look out for your best interests. Know your vendor. More than other types of information technology, radio systems are dominated by relatively few vendors. While this limits your options in some cases, it does provide better opportunities for understanding them. This provides for both better management of the project on your part and negotiation of contracts, in general. Know your vendors’ marketing and sales cycles. Find out all you can about their marketing and sales cycles. All have particular strategies for product lifecycles and managing sales. These strategies affect how you will deal with the vendor, one hopes to your advantage. Since they will most certainly affect the cost and capabilities of your system over time, it pays (literally!) to know about them at this point in your project. In real estate, there are “motivated” buyers and sellers. From the contract negotiation standpoint, it’s invaluable to know your vendors’ “motivations.” The sales staff assigned to your procurement will undoubtedly be paid in part on commission. The amount of your contract has a significant impact on what they, personally, take home through the contract. Vendors prefer penalty clauses to bonding requirements that increase costs even for successful projects. A common motivation of all vendors is, of course, maximizing profit and avoiding costs. One they prefer to avoid is the hard cost of bonding. Your agencies’ procurement rules may require it, but vendors would much rather be compelled under contract by penalty clauses than bonding requirements because they can avoid costs by carrying out the contract well—which is in both parties’ interests. Any invocation of penalty clauses typically gets lots of attention through a vendor’s chain of command. Knowing that the vendor’s staff are subject to that level of scrutiny can be useful during implementation. In the process of managing the project, any situation that requires invocation of bonding clauses and collection on the agencies’ part ultimately removes the ability of the respective agency and vendor project managers to negotiate. Do all you can in managing the project to avoid ending up in this circumstance. 150 Part II: How Is Interoperability Achieved? Prepare to transition maintenance of the technology. The larger your project, the more likely it is that you will enter into some form of maintenance agreement with your vendor. If you plan on maintaining some or all the system yourself, recognize that vendors that offer maintenance services have a natural interest in selling those services. Carefully define maintenance responsibilities and any eventual transition of responsibility to your staff. Include specific language in the contract about expected skill levels of staff to maintain the system if the vendor provides that training. The best deals can be negotiated in December. Equipment prices can vary by 5 percent based on the time of year. Use your knowledge of the vendor’s sales cycles to negotiate the best deal. Typically, better deals can be made if you time the proposal release, evaluation, and award cycle to mesh with the calendar year. Contracts signed in December often yield the best prices because vendors and sales people are nearing the end of the tax, corporate reporting, and sales commission year. They are typically more motivated to sell at the end of calendar quarters, especially the end of the year. Recognize that vendors do not want to come back to the bid table multiple times if they can include more under a larger procurement. Some large systems’ vendors pay commissions based on “tonnage”—the total cost of the procurement. They also have more pricing flexibility on soft costs. It may seem odd, but the cost of the system and its profitability to the vendor are only loosely related. The effect is that in negotiation, you may be able to get concessions on more profitable items in exchange for ones with less “markup” as long as the bottom line isn’t greatly affected. Vendor-provided training can be very expensive—check quotes carefully. Recognize how quotes are assembled. Look for costs that are added as extras or that could potentially be done by someone else. An example is training. There is often flexibility built into these cost quotes and the potential for good profitability on the vendor’s part. Consider if you really need their particular training for all proposed aspects and be prepared with the costs of alternatives when you go into negotiations. Similarly, look for costs that are split out separately, but couldn’t possibly be contracted separately. Our favorite example is system installation, configuration, and optimization. While it’s logical to use these as separate milestones for payment, for most radio systems it’s hard to separate them out as independent tasks that could be accepted or rejected in the contract negotiations process. Recognize your vendors’ internal processes. For better or worse, large commercial organizations have a lot of bureaucracy. Sometimes this can work to your advantage. First, so much of contract negotiations has to do with the vendors’ and the agencies’ internal rules of procurement that there’s a lot of work to be done between contracting professionals and legal counsel. Don’t use a lot of your procurement team’s time and energy in that process; break it out as separate work in actual negotiations. Chapter 9: Acquire the System Components 151 Second, recognize that the vendor’s bottom line profitability on your project may not be affected by concessions their project manager is able to make. For example, at least one manufacturer of equipment has a standard markup on portable radios of approximately 10 times. That is, the retail cost will be approximately 10 times the cost of manufacture. During the project, the vendor’s project managers are afforded the ability to bring additional equipment to the customer to compensate for delays, disputes, and the other typically unpleasant details of projects. To avoid invocation of penalty clauses, vendors may provide additional equipment at cost. It’s particularly valuable for you to know if your vendor accounts for this cost in the project’s bottom line at retail or at the cost of manufacture. At least one large manufacturer accounts for it at the cost of manufacture and without significant impact to the project. This provides the vendor’s project manager great flexibility in avoiding penalties that may be built into the contract. With any luck, you will get through negotiations with an agreement that keeps both your project and the vendor’s interests intact. The contract will be the basis for much work yet to come, so make sure it serves your purposes and gives you the project management leverage you need to succeed in successive steps. Chapter 10: Implement the System What System implementation is the process of installing, integrating, testing, and accepting procured technology. Training users and support personnel is key to integrating technology into agency response procedures. Why A formal implementation process provides all project participants, including vendors, a clear blueprint for building an interoperable system of systems. Failure to follow an implementation plan leaves the procurement and entire project at risk of failure through miscommunications and divergent expectations. Who The implementation plan is created by the project manager in cooperation with the vendor’s project team and through further effort from working groups. The Steering Committee reviews, approves, and submits the plan to executive sponsors for final approval before implementation begins. When Formal implementation starts as soon as a contract has been negotiated and project teams are in place. Original Tech Guide Icon Part V of the Law Enforcement Tech Guide addresses implementing technology acquired through the preceding procurement phase. The format and elements of implementation plans are dealt with in depth in its chapters, as is acceptance testing. Here, we will address specific aspects of implementing communications technology for improved interagency communications and its integration into existing systems. Chapters 16 and 17 of the Law Enforcement Tech Guide cover the implementation process in technology projects. Implementation is the most exciting time for project managers. Many plans and much work comes together during implementation to actually improve communications. Up to this point, there has been a lot of envisioning, but few tangible results outside of paper. Implementation is the time when technological and operational pieces come together to create systems. 156 Part II: How Is Interoperability Achieved? Prologue to an Implementation Implementation of the system of systems we have described requires that you, your vendors, and your project teams all work together toward well-defined ends. In the implementation phase, definition of those ends requires clear roles and responsibilities, an implementation plan, detailed documentation, and an acceptance test plan. Because the value of any system is directly related to how well it is used, training according to established or newly created procedures is a critical part of implementation. Further Define Roles The implementation process has two sets of roles: Yours and the vendor’s. This final phase of the project really does entail a partnership. Previously, you managed vendor relationships from a distance to keep the focus on operational outcomes of the project and to protect the integrity of the process. Now is the time for their efforts to bring technology to your interagency communications needs. How you approached procurement drives implementation. If you contracted for a turnkey system, most responsibilities have been left to the vendor. If, on the other hand, you chose to handle system integration yourself, the implementation plan will contain many more tasks for you and the project teams. Your Roles Vendors become stakeholders once contracts are signed. As the project manager, consider yourself the CWO (chief wellness officer). You’re responsible for assuring the project is well-founded, well-defined, well-planned, well- communicated, and now well-implemented. Consider that in this phase you have new stakeholders: Your vendors. Obviously, their stake in the project is clear, but like other stakeholders, they depend on your success in carrying out these responsibilities. You have one primary and three oversight responsibilities in implementation: Creating the implementation plan comes first, followed by oversight of documentation processes, acceptance testing, and training. Of course, you also have the ongoing role of managing the project in its entirety. As we’ve mentioned, that entails continued communications with stakeholders, managing timelines, budgets, and scope, and now contract management. If it seems like a big job, well, it is! Your implementation plan details how the project’s work is going to get done. That requires a number of decisions about who takes care of what. While you may be tired of plans by now, rest assured that most of the work for the implementation plan is already complete. We will talk further about creating the plan in the next section. Chapter 10: Implement the System 157 Documentation should be planned and managed throughout a project. In the implementation phase, documentation created by vendors and your project teams will serve project goals long after the system is up and running. Your added project management role during this phase is to oversee its completion. Acceptance testing is the process of verifying that components and the system, as a whole, function as specified. You may have considered requiring an acceptance test plan as part of the request for and evaluation of proposals. We didn’t recommend it earlier because most procurements for communications systems proceed as requests for proposals (RFP), which implies that a good deal of flexibility in proposed solutions is allowed. Acceptance plans may be very different across solutions offered, making them difficult to comparatively evaluate. We do recommend, however, having vendors develop acceptance plans as an early deliverable. They can be built in parallel to creation of the implementation plan. Details to be considered and some examples are presented later in this chapter. Training is the key to successful implementation. Training is absolutely critical to successful implementation of any technology. Too often technology is bought and left underutilized due to a lack of training on it for users and those who would maintain it. It is the project manager’s role to include training in the implementation plan. This includes training for both technicians who will maintain the systems and for users who will put it to work. Vendor Roles Details of vendor work will be set primarily by your contracts. Your vendor or vendors will appropriately participate in creating the implementation plan. Their roles will have been made very clear through execution of contracts, but further details of work will be left until now to establish. There are further tasks to define, activities to coordinate, and resources to schedule. Of course, the central vendor role is to install, customize, and activate the technology it is providing. Since you may have contracted for other vendor services, such as engineering and quality assurance, roles between vendors are important to define in the implementation plan. Both you and your vendors have roles in implementation planning. 158 Part II: How Is Interoperability Achieved? Establish the Implementation Team Original Tech Guide Icon, page 207 As discussed in the Law Enforcement Tech Guide, the implementation team consists of both your project manager and those of the selected vendors. In effect, they have their own projects that now intersect with yours. Remind the team, if necessary, that there is one central project—yours. Other teams may be needed for different parts of the implementation. Common ones include policies and procedures, construction, training, and acceptance. Depending on your project, these and other working teams may be needed to focus work where specific expertise is needed. There’s no need to create separate teams just for the sake of creating teams. Do so to maintain a reasonable span of control. Management texts stress that, as a rule of thumb, one manager can oversee three to six direct reports. As project manager, you have demanding communications roles in all directions, so don’t make the mistake of failing to delegate work through teams when needed. Your Steering Committee and executive sponsors are ultimately part of the implementation team. The Steering Committee should play an active role in reviewing the implementation plan and evaluating contractor performance. Executive sponsors must approve this very critical plan and make the final acceptance. In most agencies, final signoff on incremental payments for large contracts will be required of agency chief executives. Create the Implementation Plan As you might guess, the implementation plan is central to, well, implementation. You’ll be pleased (relieved?) to know that we suggest using parts of other project documentation completed in previous steps to populate the implementation plan. This plan will mainly be a collection of parts from previous work brought together in a focused format for implementation. Implementation Plan Elements Original Tech Guide Icon, page 207 The Law Enforcement Tech Guide lays out a basic implementation plan that is fully useful for voice and data interoperability projects. It suggests organizing the plan into four chapters that summarize the project, laying out its organization, the implementation management process, and then details of work, schedule, and budgets. The radio aspects of communications interoperability projects bring additional plan elements. Figure 10-1 lists the standard topics of each chapter. Chapter 10: Implement the System 159 Chapter 1 Project Summary Overview Definitions Deliverables Audit Trail Chapter 2 Project Organization Plan approval process Organizational structure Responsibilities Relationships between vendors System management transition Chapter 3 Management Process Project objectives Assumptions/constraints Risk management plan Staffing plan Chapter 4 Work, Schedule, and Budget Tools Select contract exhibits Logisitical considerations Figure 10-1: Implementation Plan Outline Project Summary This first chapter of your implementation plan includes a simple overview paragraph, definitions of key terms that could be misinterpreted, and a list of deliverables taken from your contracts. The overview and definitions could be taken from your procurement documents as well, if you previously fleshed out an RFP or a request for information (RFI) in that level of detail. Include an audit trail block at the beginning of this chapter to log changes to this document over its lifetime. Project Organization The second chapter details the plan approval process. Address how it is approved initially and how changes will be managed through implementation, with a statement of authorities and responsibilities. The approval process can be lifted largely from your project plan. Clearly describe the approval process for change orders! Address how project changes will be requested and approved. Clearly describe the approval process for change orders! Unmanaged, changes can creep into projects, distorting your original plans. One of our favorite project managers refers to change orders as ka-ching orders—as in the sound of a cash register racking up another sale. You’ll want to carefully manage project changes during implementation because they will have an impact on its timeline and/or cost. Remember that you have new players who will also need to know your project structure. Provide them with your organizational structure for this phase, adapted from the project plan. Request and include the vendors’ organizational charts for the project as well. 160 Part II: How Is Interoperability Achieved? Describe implementation team member responsibilities and roles, including those between various contractors, if more than one is used. As mentioned in the original Law Enforcement Tech Guide, carefully lay out relationships between vendors and responsibilities for subcontractors as defined in your contracts. Conclude the project organization chapter by addressing system management transition. Describe how a transition of responsibilities from the vendor(s) to your team will occur. Computer and radio systems of ever increasing complexity go through a cycle of installation, integration, and optimization during which vendors initially take all responsibility for system management. That responsibility is transitioned to your staff or whoever will manage it over time—sometimes another contractor, such as a regional radio service company. The transition process should be documented here. Management Process Use the third chapter to document details of how the project—and this phase—will further be managed. Pull the objectives from your project plan for inclusion here. They serve to inform others in the team about what is being accomplished through this implementation of technology. Also include assumptions and constraints from your project plan with any changes that have arisen through the procurement process. For example, the proposed system design may have required compromises on coverage in order to remain within the project’s budget. This would lead to constraints on original objectives that will change acceptance tests. If you’ve followed our recommendations, you will be able to insert an up-to-date risk management plan in this chapter from your broader project plan. It’s fair to advise all team members, including contractors, what you have considered as potential risks to the project, how serious you consider them, and what your strategy is for dealing with them. Include appropriate information out of your contracts on any penalties clauses and dispute resolution processes. The final piece of this chapter is a staffing plan. Include information consistent with your project organization chart that shows who will be assigned to various tasks during different periods. Because the timing of your personnel resources for meeting with contractors, escorting them to radio sites, conducting acceptance tests, and such will be heavily dependent on vendor timelines, you will need firm ones from them before being able to document your own commitments. Chapter 10: Implement the System 161 Tips Icon Budget Tip: The Final Payment Contractors will appropriately expect to be paid for labor and materials as parts of the system are accepted. Part of your duty during contract negotiations was to arrange fair compensation for work while protecting the agencies from paying for an incomplete product. Payment milestones should be linked to acceptance and at least 10 percent of the contract should be held until after final acceptance. This prevents implementations from dragging on when there is only a bit more work necessary to have a functional system, as specified by the contract. Work, Schedule, and Budget Tools The final chapter of the implementation plan is dedicated to the details of work to be accomplished. If your contract is with an established vendor and the project is of any significant size, this detail will have been negotiated prior to signing contracts. Include here select contract exhibits, such as the initial project schedule, the budget and payment schedules, and an outline of the acceptance testing process. Keep in mind that not all members of the implementation team will have ready reference to actual contracts, so it is useful to include these items in the guide that they’ll be using. Since acceptance testing can be a very detailed process as we discuss in the next section, an outline here will serve to describe it for the general understanding of all team members. Unless you are proceeding with a turnkey implementation, use this opportunity to define the process of handoff of responsibilities between vendors. Add milestones in your project schedule describing these events. For example, a consultant hired to prepare an engineering design will go through a draft, review, and finalization process with you before the design is handed off to contractors to build the systems. Conclude this chapter and the implementation plan by addressing logistical considerations that will be faced. Large voice and data projects can involve a lot of equipment that needs to be shipped to various sites. The logistics of who, when, and where equipment is received, inventoried, stored, and eventually staged for installation are important details for a smooth-running project. Take the time to deal with these details now before you get behind the curve. BudgEt tip: BEnEficial usE Contractors will also appropriately expect to be paid when you put the technology to the work it was intended for. This doctrine—probably a contractual element—of beneficial use is used to trigger payment milestones, as well as to start the warranty and maintenance cycle clocks ticking. The trouble is that it’s rare with complex systems to just “flip a switch” and make everything come live. Implementation more often proceeds in fits and starts. Some functionality exists before the complete system you contracted for is available. Obviously, you don’t want warranty clocks ticking for 100 percent of your equipment when only 10 percent of it is in use. Careful definition of “beneficial use” during contract negotiations will provide leverage during implementation and better value from your equipment. Use of multiple vendors requires additional hand-off milestones in the project timeline. 162 Part II: How Is Interoperability Achieved? Sign, Seal, and Deliver! That’s it for the implementation plan. It should pass to the Steering Committee for review before submittal to the project’s executive sponsors. If you have involved the project’s working committees and built teams to assist with the variety of work discussed, the approval process will be smooth. Once approved, the plan is ready for delivery to all implementation team members. Manage Documentation The volume of documentation that can be generated with technology projects is amazing. You’ve probably already had to buy a new bookshelf just to hold the project planning documents! It’s only just begun, though, because documentation is critical in the implementation phase to assure both its proper management and your agencies’ ability to use the system over its lifecycle. Six sets or categories of documentation are completed through the implementation phase: Project, as-built, system, equipment, procedures, and training. Project It probably comes as no surprise that project documentation would be mentioned here first. The implementation plan is the central piece from this phase. Since you can expect it to change during implementation—that’s inevitable!—anticipate capturing the details of changes proposed, accepted, or rejected in the audit trail of your plan. Other important project documentation to capture is all communications with contractors, particularly those involving decisions by one party or the other. Rely on a disciplined process of capturing all paper and electronic communications for the project record. In larger projects, create a formal communications plan and keep a log. Contractual changes can generate a lot of documentation that’s important—and probably required by your procurement and legal advisors. As-built Depending on your project, as-built documentation includes engineering diagrams, site plans, shelter floor plans, equipment rack layouts, and other depictions of technical aspects of your system. Narrative and other textual information is usually combined with a multitude of diagrams to literally draw pictures of what your system looks like, as built. While much of this information may have been developed during system engineering, its completion during implementation is an important deliverable. Vendors are typically tasked with completion of as-built documentation. Plan to prepare similar documentation if you take on some responsibility in technical Chapter 10: Implement the System 163 implementation. For example, if you have retained responsibility for providing sites that a radio vendor will use, be sure to include up-to-date site and shelter floor plans in your final system documentation. You will thank yourself later for having done so! System System documentation is related to as-built, but focuses on the system’s technical aspects more broadly. It may include the following: — Logical system diagrams and process flow charts — Backbone connectivity diagrams — Disaster recovery procedures — Maps of sites relative to the involved jurisdictions — Documentation of predicted and measured radio coverage — Installation and maintenance standards — Electrical power service procedures and contingencies — Location of and procedures for using spare equipment — Logical mapping of channels and talkgroups — User radio programming and channel assignments — Other hardware and software configuration and tuning parameters — Site permits and frequency licensing information. Equipment Vendor documentation of all equipment procured and used in the system should be collected, cataloged, and distributed as needed. Quick reference materials either available from the vendor or created by the project team fall into this category. Original equipment specifications, warranties, and installation information can be kept as separate pieces of the broader system documentation. Portable and mobile radios often arrive en masse, are unpacked, inspected, inventoried, and prepared for installation or distribution. Collect user guides from end-user equipment to distribute during training. Procedures SOP development and management is covered in Chapter 12. Both technical and operational procedures are included in implementation documentation. On the technical side, equipment installation and programming procedures are important, as are preventative maintenance schedules and procedures. Standard operating procedures (SOP) for both technical and operational use of the technology are an important part of documentation. We will discuss development of operational use of procedures in more detail in Chapter 12, Develop Policies and Procedures. 164 Part II: How Is Interoperability Achieved? Rely on the project working committees for training documentation. Training If training is the key to your successful implementation, then you have to expect to document up front what is to be done and what has been done. Training plans encompassing technician, dispatcher, and field user needs are often outlined in procurement documents and further detailed during implementation. Your training documentation during the implementation phase should also include all materials used by vendors in their contracted training. Rely on your User and Technical Committees to create training plans and organize ongoing documentation. Documentation of who received what training, and when, is important for all emergency services skills, including communications. Use Quality Assurance and Acceptance Tests Original Tech Guide Icon, page 213 The next major step in preparing for implementation is developing acceptance tests. These tests are part of a quality assurance (QA) process that verifies the project is meeting its objectives. They provide a signoff that a vendor has met some term or terms of its contract. The Law Enforcement Tech Guide provides a chapter dealing with developing QA tests that evaluate vendor and product performance. Acceptance testing is the process of assuring that quality measures have been met through discrete tests of hardware, software, subsystems, and ultimately the system as a whole. Make acceptance plans as early vendor deliverables. Establish creation of acceptance plans as early vendor deliverables. While most testing and all acceptance is your responsibility, of course, you may be able to adapt standard test plans that your vendor provides. Adapt canned test plans to your project. Evaluate the standard plan, then take the time to develop these plans further by removing any elements unrelated to your implementation. Add others central to your functional specifications. Through an iterative effort, you will be able to establish an acceptance test plan that meets your needs and provides project QA. A good test plan adequately and accurately tests the technology as proposed by the vendor and as contracted for. In large projects, it makes sense to refine acceptance tests through multiple phases. For example, an early phase of a wireless local area network (WLAN) implementation may target the central facilities of the involved agencies, while leaving outlying stations for later. Development and use of the acceptance plan in the first phase will likely lead to changes for subsequent phases. If you choose that option, make note of it in your implementation plan. Remember: the more money involved, the more is riding on the acceptance process, and the more planning that is needed. Chapter 10: Implement the System 1 Testing In conducting the acceptance tests, user involvement is important for successful implementation—and a successful project. Your acceptance team will probably be composed of some project participants who have been involved from the beginning. It should include members of the User and Technical Committees who will be responsible for verifying that the project’s requirements are met. Original Tech Guide icon, page 214 As discussed in the Law Enforcement Tech Guide, there are three common benchmarks for testing technology: Functionality, reliability, and performance. Systems implemented for communications interoperability that make use of radio technology also usually include special performance testing for coverage. Functional Testing Staged testing helps minimize costs for large systems. Functional tests are designed to ensure that the equipment and subsystems work as advertised and proposed. It may take place when the system is staged, after it is installed, or both. Large system implementations commonly require that the equipment vendor stage, or assemble, equipment at the vendor’s facilities where it is then tested for functionality. This provides some integrated testing of the vendor’s offerings. Staged testing helps minimize costs for large systems by providing a controlled environment where subsystems are immediately accessible—as opposed to being on a mountaintop somewhere! Final functional testing takes place once equipment is installed. The vendor repeats the tests performed in staging and conducts additional tests arising from the equipment’s integration into its physical location and other systems. For example, radio systems are very much dependent on their antenna subsystems. Functionality of some aspects of the radios can only be adequately tested once the equipment is in place, antenna systems installed in their final locations, and other subsystems integrated. Reliability Testing Reliability testing typically requires some sort of simulation. As discussed in the Law Enforcement Tech Guide, software can be tested for reliability through use of special applications designed for this very purpose. With hardware, including radio equipment, time is the only reliable reliability test. Systems, as we’ve discussed them here, are a complex of software, hardware, and human aspects. The inanimate parts form their own subsystems that can be tested by simulating “faults” between components. For example, a shared mobile data system with a single mobile server, but multiple agency CAD and RMS connections, could be tested for reliability as the connections to the agencies’ information systems are broken. This would show how other parts of the system perform under less-than-ideal conditions. 166 Part II: How Is Interoperability Achieved? Similarly, radio components may be tested as they lose backbone connections between sites, power, or even antenna system connections. Advanced systems use active networking monitoring techniques and devices for detecting faults. Conduct functional testing of these subsystems while forcing system faults to conduct reliability testing elsewhere. Each testing step toward implementation constitutes further integration testing. Performance Testing The third stage of acceptance testing involves getting right down to measuring how well the technology meets the operational requirements driving its procurement. Subsystems, such as backbone networks connecting radio sites and other fixed facilities, can be incrementally tested for performance. On the other hand, final performance testing requires that all subsystems be installed, configured, optimized, and integrated. Performance testing of potentially wide-ranging, multiagency systems for communications interoperability can be challenging. Consider using limited exercises once equipment is installed and training conducted. Appropriately timed, exercises can serve as near-real performance tests leading to acceptance. Full-scale exercises can be the next best (worst?) thing to an actual emergency to stress-test communications systems. Coverage Testing A type of performance testing peculiar to radio systems is coverage testing. Radio coverage testing involves field measurements of signal strength and a healthy dose of science mixed with probability statistics. Without getting into the heavy details,36 radio coverage varies greatly based on distance and intervening obstacles between the transmitter and receiver. Obstacles can be everything from buildings to the human body. It also varies over time at any given spot. Radio system designers work to account for these variations in predicting coverage. 36 The accepted standards for coverage testing are defined in the Telecommunications Industry Association (TIA) Telecommunications Systems Bulletin TSB-88, “Wireless Communications Systems, Performance in Noise- and Interference-Limited Situations, Recommended Methods for Technology-Independent Modeling, Simulation, and Verification.” Note that this is not a formal standard, but an accepted technical methodology. For more information, see http://www.tiaonline.org/. Chapter 10: Implement the System 167 Typically, public safety agencies specify coverage requirement as a percentage of a geographic area under certain conditions and to a certain level of audio quality, such as the following: 95 percent coverage of the city is required for a Delivered Audio Quality (DAQ ) of 3.4 with portable radios carried outdoors at the hip, for both transmit and receive. It’s not a matter of simply driving around saying, “Can you hear me now?” Obviously, coverage testing during implementation to verify this is going to take some technology, statistics, and work. It’s not a matter of simply driving around saying, “Can you hear me now?” If your project requires it, coverage testing is not something to be taken lightly! It’s one of those areas of implementing technology for which you should hire qualified assistance if you don’t have the expertise internally. 168 Part II: How Is Interoperability Achieved? Sample Functional Acceptance Tests While this incremental process of testing should be understandable, there’s nothing like examples to make them real. Figure 10-2 shows a few of the functional acceptance test procedures used by the City of Mesa (Arizona) in implementing its trunked radio system. Many more in each category were used, as were yet more categories of procedures. Each procedure was accompanied with the required setup process to assure that resources needed for the test were prepared. This plan was provided in draft by the vendor and worked out in detail with the agency through implementation planning. As each test was successfully completed, team representatives from the agency and the vendor signed off on it with any additional notes memorializing the test. Site Trunking Site Trunking Talkgroup Call When a site goes into site trunking, radios with talkgroup call capability will be able to communicate with other members of the same talk- group at that same site. Members of the same talkgroup at other sites will not be able to monitor those conversations. Step 1. Place Site 1 into the site trunking mode. Step 2. Initiate a talkgroup call with RADIO-1 on Test TG 1 at Site 1. Step 3. Observe that only RADIO-2 will be able to monitor and respond to the call. Step 4. Initiate a talkgroup call with RADIO-3 on Test TG 1 at Site 2. Step 5. Observe that only RADIO-4 will be able to monitor and respond to the call. Call Alert Call alert is a tone page that allows a user to selectively alert another radio unit. When a site is in site trunking, Radios at the site will only be able to call alert other radios at the same site. The initiating radio will receive notification from the trunked system as to whether or not the page was received by the target radio. Step 1. Place Site 1 into the site trunking mode. Step 2. Using RADIO-1, press the alert button. Step 3. Enter the Unit ID of RADIO-2 with the keypad, or scroll to the location where this ID is stored. Step 4. Press the PTT to initiate the call alert. Step 5. Verify that RADIO-2 received the call alert. Step 6. Exit the call alert mode and return to normal talkgroup mode. Figure 10-2: Excerpts from City of Mesa (Arizona) Acceptance Test Plan Chapter 10: Implement the System 169 Wide Area Trunking Talkgroup Call Radios with talkgroup call capability will be able to communicate with other members of the same talkgroup. This provides the effect of a private channel down to the talkgroup level. This test will demonstrate that a talkgroup transmission initiated by a radio user will only be heard by system users who have the same talkgroup selected. As with other types of calls, talkgroup calls can take place from anywhere in the system. Step 1. Initiate a wide area call with RADIO-1 in Test TG 1. Step 2. Observe that only RADIO-2 will be able to monitor and respond to the call. Step 3. Initiate a wide area call with RADIO-3 in Test TG 2. Step 4. Observe that only RADIO-4 will be able to monitor and respond to the call. Secure Operations Digital encryption is used to scramble a transmission so only properly equipped radios can monitor the conversation. A “Key” is used to encrypt the transmit audio. Only radios with the same “Key” can decrypt the audio and listen to it. Step 1. Initiate a secure wide area call with RADIO-1 on Test TG 1. Keep this call in progress until instructed to end the call. Step 2. Observe that RADIO-2 will be able to monitor and respond to the call. Step 3. Observe that RADIO-3 does not receive the call. Step 4. Observe that RADIO-4 will also receive the call even with the secure switch set to the nonsecure mode of operation. Step 5. End the call from RADIO-1. Step 6. For radios equipped with dual algorithm encryption modules, select a talkgroup using the second algorithm and repeat Steps 1-5. Call Alert Call alert is a tone page that allows a user to selectively alert another radio unit. The initiating radio will receive notification from the trunked system as to whether or not the page was received by the target radio. Units receiving a call alert will sound an alert tone. As with other types of calls, call alerts can take place from anywhere in the system. Step 1. Using RADIO-1, press the page button. Step 2. Enter the unit ID of RADIO-2 with the keypad, or scroll to the location where this ID is stored. Step 3. Press the PTT to initiate the call alert. Verify that the RADIO-1 user receives audible indication that the call alert was sent. Step 4. Verify that RADIO-2 user receives an audible indication of an incoming call alert that was sent but RADIO-3 does not. Step 5. Verify that RADIO-1 gets an audible indication that the call alert was successfully received at the target radio. Step 6. Turn off RADIO-2. Send a call alert from RADIO-1 to RADIO-2. Step 7. Verify that the RADIO-1 user receives audible indication that the call alert was sent. Step 8. Verify that RADIO-1 receives an indication that the call alert was not successfully received at the target radio. Figure 10-2, continued 170 Part II: How Is Interoperability Achieved? Console Talkgroup Selection and Call Dispatchers with talkgroup call capability will be able to communicate with other members of the same talkgroup. This provides the effect of an assigned channel down to the talkgroup level. When a talkgroup call is initiated from a subscriber unit, the call is indicated on each dispatch operator position that has a channel control resource associated with the unit’s channel/talkgroup. Step 1. Initiate a wide area call from any operator position on Test TG 1. Step 2. Observe that RADIO-1 and RADIO-3 will be able to monitor the call. De-key the console and have either radio respond to the call. Step 3. Observe that all consoles with Test TG 1 can monitor both sides of the conversation. Step 4. Initiate a wide area call from any operator position on Test TG 2. Step 5. Observe that RADIO-2 and RADIO-4 will be able to monitor the call. De-key the console and have either radio respond to the call. Step 6. Observe that all consoles with Test TG 2 can monitor both sides of the conversation. Talkgroup Patch Talkgroup patch allows a dispatcher to merge several talkgroups together on one voice channel to participate in a single conversation. This can be used for situations involving two or more channels or talkgroups that need to communicate with each other. Using the patch feature, the console operator can talk and listen to all of the selected talkgroups grouped; in addition, the members of the individual talkgroups can also talk or listen to members of other talkgroups. Patched talkgroups can communicate with the console dispatcher and other members of different talkgroups because of the “supergroup” nature of the patch feature. Step 1. Select an operator position for testing which contains Test TG 1 and Test TG 2. Step 2. At the desired operator position, select the patch tab in the patch window. Step 3. Click the button on the patch that allows an operator to set up and edit a patch (note patch window turns blue). Step 4. Add Test TG 1 and Test TG 2 to the patch by selecting each resource tile. Step 5. Once the talkgroups are added, click the patch setup button again to complete the patch setup. Step 6. Initiate several talkgroup calls between radios. Step 7. Observe that all radios are able to communicate with one another. Also via subsystem viewer screen, observe that only one station is assigned at each of the two sites. Step 8. Initiate a call from the operator position using the patch transmit button and observe that all radios are able to receive the call and only one station is assigned at each of the two sites. Step 9. Remove Test TG 1 and Test TG 2 from the patch. Figure 10-2, continued Chapter 10: Implement the System 171 Report Generation Historical Reports Performance reports can be created automatically for dynamic statistical information about the air traffic activity on the system. These reports provide assistance with system management, resource planning, usage allocation, and monitoring. All reports are preformatted and summarize air traffic activity for a configured time span. Step 1. From the application launcher, select a subsystem. Step 2. From that subsystem’s menu, choose subsystem historical reports. Step 3. From the historical reports window that opens, select a report. Step 4. Using the left mouse button, click on the view button. Step 5. Observe a window opens, allowing a user to enter report parameters. Step 6. Enter all desired data for the report and generate report. Step 7. Observe a window appears showing the requested report. Step 8. Close the report window. Step 9. Run the following reports during testing: Talkgroup at Subsystem Summary; Radio User at Subsystem Summary; Site Summary. System Reliability Simulcast Essential Site Operation This test verifies the essential site operation within a simulcast system. An essential simulcast remote site is one that must have at least one control channel and one traffic channel for the simulcast subsystem to remain in trunking mode. If all control channels or all traffic channels have experienced faults at an essential simulcast remote site, then the entire simulcast subsystem is put into failsoft mode to ensure communication can continue in the area covered by the essential simulcast remote site. When all of the wide area failsoft channels at an essential simulcast remote site have experienced faults, the essential simulcast remote site is malfunctioned. Step 1. Power down one of the control channel capable stations at the non-essential site and note that configuration software shows the channel is disabled at all the other sites. Step 2. Repeat Step 1 for each of the other control channel capable stations or until 50% or more of the stations have been malfunctioned. Step 3. Verify that configuration software shows that the disabled channels have been enabled at all other sites in the simulcast subsystem and that RADIO- 1 can communicate with RADIO-3. Step 4. Repower all of the control channel capable stations at the nonessential site. Step 5. Power down all of the control channel capable stations at the essential site. Step 6. Verify that the simulcast subsystem is now in the failsoft mode. Step 7. Re-power all of the control channel capable stations at the essential site and verify the simulcast subsystem is back in wide-area trunking. Base Station IdentificationThis test verifies that the repeaters programmed for base station identification at every site broadcasts the FCC identifier every 30 minutes. To accomplish this, a service monitor will be set up to monitor the identification channel of a random site and note that the Morse code is heard. Step 1. Choose one site to test for base station identification. Step 2. Set up the service monitor to receive the frequency of the identification channel for the particular site. Step 3. Monitor the service monitor until the system ID is broadcast. Figure 10-2, continued 172 Part II: How Is Interoperability Achieved? Create Standard Operating Procedures and Train More likely than not, your agencies will have a few existing policies and procedures that shaped earlier functional specifications and now have to be incorporated with the new system. We earlier recommended forming the policies/procedures team prior to procurement to start collecting and melding policies and procedures between agencies. If the team has been productive, you should have a core set of standard operating procedures (SOP) around which training can be developed. We recognize that developing operational policies and procedures proceeds more easily when users have real technology up and running. It’s a living process that one hopes will have its start in your system design, procurement, and implementation, then mature as the system moves to full operation. We delve more deeply into SOPs in Chapter 12, Develop Policies and Procedures, in recognition of that ongoing process. Initial training may be contracted out. Your next step is to develop training programs using your own internal operational expertise as to how the system should be used. In large projects, training development and execution is contracted out because it can be a huge undertaking. Again, look for operational expertise, not necessarily technical, in developing training for end users. Vendor training on the equipment and system basics is valuable, particularly for your agencies’ trainers who will then go on to incorporate information about the technology into their own training programs. Don’t rely on the equipment or system vendors to conduct the bulk of training. They typically have good technician programs, but limited expertise on how the technology is best put to work by end users. Use train-the- trainer courses to build self- sustaining expertise. If the system will rely on dispatchers to activate resources or use the technology, include special training for all dispatch agencies involved. Consider building internal expertise within dispatch agencies involved in your project through train-the-trainer courses contracted with either a commercial training company or through peer agencies elsewhere in the country that have been successful with similar projects. Traditional classroom training is of limited use when it comes to interagency communications. Theory and diagrams don’t do enough to instill communications skills needed by first responders. Tabletop exercises are useful to introduce new systems, work out procedural bugs, and establish an understanding of the sequence of tasks in using the new capabilities. In short order, though, you’ll need to move to the field. Chapter 10: Implement the System 173 Train in the context of how the technology will actually be used. Train for use of your new system in the context that it will actually be used. Put radios in responders’ hands, show them how the capabilities are used, then practice until their skills are developed to an acceptable standard. Assuming that capabilities will be placed in the hands of all responders, training will need to be further incorporated into their basic training programs, on-the-job training, and exercises so the skills are gained by new recruits and refreshed among old-timers alike. We’ll have more to say about training methods in the next chapter on maintaining your system and processes. With an implementation plan in place, acceptance tests lined out, and training of end users and support personnel planned, your project is well-positioned for a successful implementation. An Example The process of moving from needs analysis through implementation has been described in detail. To finish up this chapter, which is intended to guide you to an operational system, let’s use an example to make the implementation process a bit more tangible. The example is a hypothetical case used to capture a composite mix of activities, but based on very real initiatives going on around the country. It captures the mixture of responsibilities across the project team and your vendor showing how they need to be timed and communications shared. Three small cities and a county have joined in an interoperability initiative to improve communications interoperability. Alphaville, Bravotown, and Charlieport are independent municipalities in Delta River County. Delta River County: As-Is • Alphaville has a conventional voice radio system using separate repeated channels37 in the UHF band for police, fire, and EMS dispatch. The Alphaville Police Department (APD) and the Alphaville Fire Department (AFD) each have direct portable-to-portable channels for their internal tactical needs. Both have two state-designated mutual aid channels installed in their portable and mobile radios for talking directly to other UHF users, but the channels are only useful on scene since they aren’t repeated. APD uses mobile data computers in patrol cars to receive routine dispatches; run wants, warrants, and motor vehicle checks; and for some car-to-car messaging. 37 A repeater is a radio typically permanently fixed with an antenna well situated on a tower or other high spot in the jurisdiction that receives radio communications on one frequency and retransmits them on another frequency within the same band. See Chapter 16, Pages 252-253, for more detail and a diagram. Part II: How Is Interoperability Achieved? 174 • Bravotown shares a conventional voice radio system on VHF-high band with Delta River County. Dispatch of the county sheriff, volunteer fire departments, the Bravotown Police Department (BPD), and the Bravotown Fire Department (BFD) is all handled by a consolidated dispatch center over the same set of four repeaters spread around the county, although there are separate law enforcement and fire channels. The repeaters are linked together so they simultaneously transmit the best received signal on the channel anywhere in the county.38 The volunteer fire departments have a shared tactical channel between them for unit-to-unit communications, as do each of the law enforcement agencies for their intra-agency use. All of the VHF-high band users have five state-designated mutual aid channels installed in their mobile and portable radios that are useful for direct communications. EMS services are provided by fire department quick response units and a commercial ambulance service, which are all dispatched on the same fire channel. • Charlieport has a relatively new 800 MHz trunked radio system39 for voice communications. All municipal users are on the system. Portable and mobile radios are also programmed with five state-designated mutual aid channels, which also happen to be nationally standardized. These are typically used to communicate unit-to-unit with state police and highway maintenance responders that use a similar statewide system. The Charlieport Police Department (CPD) and the Charlieport Fire Department (CFD) use a common mobile computer system with wireless services provided by a commercial carrier. While this is a hypothetical scenario, it is very realistic and exists in similar form all around the country. In our example, all these agencies have joined in a countywide initiative to improve interagency communications for first responders. Let’s take a look at the system of systems they chose and what’s involved in implementing it. 38 This is known as a simulcast system with receiver voting. For practical purposes, the system can be thought of as a single repeater with the wide, composite coverage provided by all the separate sites. The effect is a single channel that covers a wide expanse, which can be good at times and bad at others, depending on whether distant communications are needed or only interfering with more pressing, shorter-range ones. 39 A trunked radio system uses repeaters, too, but computers in the radios and at the heart of the system automatically assign their use to individual conversations between groups of users, or talkgroups. This makes channels defined functionally, rather than defined electronically or geographically. Chapter 10: Implement the System 175 Delta River County: To-Be Through a needs analysis and conceptual design, the agencies decided to use a combination of approaches to improve their interoperability. The Steering Committee concluded early on that both voice and data communications were important. Jointly, the agencies first issued an invitation for bid (IFB) and hired a systems integrator, then followed up with an RFP to procure the technology. Functional specifications were created around their requirements and the conceptual design. They called for the following: • A cache of 16 VHF-high band portable radios programmed for all the county’s channels and five state mutual aid channels in the band. These will be used for a command net during extended interagency incidents. • One new channel added to the county’s conventional system for interagency use and one new site in Charlieport to improve the system’s coverage in the denser downtown area. • A fixed gateway device in Charlieport capable of interconnecting an existing CPD/CFD command talkgroup to the new county interagency repeated channel and Alphaville direct command channels. The gateway will be controlled by Charlieport central dispatch. • A mobile gateway device to be housed, maintained, and fielded by AFD. It will be used to interconnect Charlieport mutual aid responders outside of the range of their system to other responders using direct 800 MHz, county VHF-high band, and Alphaville UHF mutual aid channels. Similarly, it will bring AFD and APD direct channels into interconnected groups outside the range of the Alphaville primary system. In effect, this device will serve as a mobile crossband repeater for linking channels around an incident site. • An intersystem message switch for connecting the Alphaville and Charlieport mobile data systems together to allow car-to-car and dispatch-to-dispatch messaging. The system’s primary use for interagency communications will be for messaging between dispatch centers, incident command posts, emergency operations centers (EOC), and evacuation centers. Fixed terminal access to the Charlieport system will be established in the Delta River Central Dispatch and EOC. Interoperability Continuum Icon This initiative uses a combination of approaches to the technical side of interoperability described in the SAFECOM Interoperability Continuum. In use, there will be swapping of radios from the cache to add capabilities, gateways to patch together existing systems, shared channels designated specifically for interagency communications, and a shared system by some responders. It doesn’t, however, replace all existing radio systems with a single, shared one. Doing so may be a future possibility as Delta River County’s needs expand and agencies become more accustomed to requesting and providing mutual aid outside the coverage of their individual systems, but for now this approach serves their interoperability needs. 176 Part II: How Is Interoperability Achieved? Delta River County: The Implementation With the scenario laid out, let’s take a look at what will be required for implementation. Through the RFP, the partners made multiple awards. The first went to a nearby radio communications service shop for the cache radios, programming, and packaging in a deployable case. The second went to a large radio systems vendor for most of the other work, except for the mobile data system interconnect, which went to a third company. Training of users and technicians was included as a task under all three contracts. Original Tech Guide Icon, page 208 Following the Law Enforcement Tech Guide, The Delta River project manager pulled together a draft implementation plan from materials in the original project plan and new contracts. He had the systems integrator draft an acceptance plan in cooperation with the other contractors while the implementation plan was being put together. Several teams were assembled to work through implementation. Most of the members of the procurement team that guided the IFB and RFP efforts moved on to the acceptance team, which was responsible for conducting the actual tests to assure that the system performed as intended. Initiate changes to policies, procedures, and agreements early on. A policies/procedures team was brought together from key members of the User Committee. It was charged with again reviewing all the agencies’ relevant policies, SOPs, and mutual aid agreements that went into a business process baseline report. The team was further charged with drafting needed new policies and procedures for use of their new capabilities. The earlier needs analysis process had turned up some procedural holes in the countywide emergency operations plan, particularly as it defined the command structure for interagency response. While the Incident Command System (ICS) was commonly expected to be used, few agencies in the county regularly used it. Integrate expected changes to incident response into the new system of systems. With funding being increasingly tied to use of the National Interagency Management System (NIMS), the policies/procedures team found this was a good time to define how agencies in the county would use NIMS-based ICS for interagency operations. Working through their agencies and the project User Committee, the team came up with new draft procedures describing interagency command processes and worked them through the Steering Committee for approval. The project’s executive sponsors carried the new operating procedures and their communications counterparts through the Local Emergency Planning Committee (LEPC) required by state and federal legislation. Chapter 10: Implement the System 177 Use outside resources for help managing project construction. Elsewhere in the project, a construction team was assembled with the Steering Committee’s approval to guide the development of the new Charlieport radio site. The team consisted of the Charlieport facilities director, a county zoning officer, a CFD captain who served on the city’s earlier steering committee for its 800 MHz system, and a CPD technical services manager responsible for daily operations of the system, who also chaired the initiative’s Technical Committee. The team’s charge was to select an appropriate site with the guidance and eventual concurrence of the system vendor that provided adequate coverage, was affordable and acceptable, and ideally was on city- or county-owned property. The acceptance team built a series of tests for each of the system’s technology components that would lead them to acceptance of the pieces and eventually the system as a whole. A previously planned LEPC tabletop exercise provided a good venue for testing the radio cache when it was delivered. Tests turned up needed programming changes and suggestions for additional battery packs, which was outside the contract, but negotiated through a change order with the vendor after the Steering Committee approved doing so. Functional, reliability, and performance tests were conducted. Acceptance testing of the fixed and mobile gateways proceeded through three steps: Functional, reliability, and performance testing. Functional testing was performed by the team with additional help from members of the Technical Committee. It followed a script calling for separate radios from each of the agencies to be brought to Charlieport, activation of the gateway, and then testing transmissions sent back and forth. The mobile gateway was similarly tested in Alphaville. Reliability testing takes time. Adapt existing tests from other agencies and sources. Reliability testing of the gateways was conducted over the period of a month with daily activations of the devices and weekly testing of actual transmissions between agencies. Performance QA tests were conducted during all the functional and reliability tests. They consisted of minimum setup and breakdown times for the devices themselves, as well as individual connections between channels. Audio quality and induced delay tests were also performed to see if the gateways materially affected communications. Most important, functional tests allowed the partners to look for negative tests the gateways had on their existing systems, such as connecting repeated systems in a loop. Original Tech Guide Icon, page 216 The intersystem message switch between Alphaville and Charlieport mobile data systems was similarly tested on all three levels. The acceptance team contacted agency references provided by the radio system vendor and adapted their test plans from a similar implementation. They also made use of sample language provided in the Law Enforcement Tech Guide, further customized to include tests across both jurisdictions’ dispatch points, the new EOC installations, and directly between responders. 178 Part II: How Is Interoperability Achieved? Delta River County: Acceptance Adjust the schedule by shuffling work internally, if possible. Implementation proceeded smoothly. Each of the vendors had good experience with similar projects and worked well with the project manager to build a realistic schedule before starting work, then made adjustments through the Steering Committee concurrence to both lengthen and shorten phases as it proceeded. Only a couple of contractual milestones were at risk of being missed. The project manager, vendor’s managers, and the acceptance team sat down and adjusted work in other parts of the schedule to rebalance the timeline. One deadline was breached, but all parties agreed that it was due to delays in frequency licensing, which was Delta River’s responsibility, and no penalty clause was invoked. Training was designed by the policies/procedures team from materials provided by the vendors under contract. The vendors provided early training to key dispatch, technical, and field supervisors who would be expected to understand parts of the system more thoroughly to conduct further staff training. This “train-the-trainer” approach is commonly used to capture as much knowledge and technique as possible from the vendors in building a cadre of future instructors. Anticipate that training will be a perpetual process. Further training continued as various parts of the system were put into place. It was timed so that, if the schedule went as planned, there would be no more than 6 weeks between hands-on training and final acceptance. Final acceptance was contingent on a full-scale exercise that was planned and scheduled by the acceptance team through the LEPC starting early in the project. The exercise brought out police, fire, EMS, and emergency management personnel from across the county in a tornado scenario. Since the county had regularly used such scenarios for emergency planning in the past, it provided a good opportunity to stress-test the new system of systems—complete through all technology elements, policies and procedures, and training. Use exercises for performance testing. The exercise pointed out needed adjustments in procedures for activation of the fixed gateway and coordination of its use with technicians deploying the mobile gateway in order to reduce any future interference between the two. These adjustments were entirely the responsibility of the project team, so didn’t affect final acceptance and payment to the vendor. A error in the mobile data interconnect configuration that prevented direct messaging between the Charlieport and Alphaville EOCs was identified as out of specifications, though, and that vendor was able to quickly fix the problem. Use successful final tests to congratulate the team and set the stage for future interagency collaboration. A small ceremony and press conference was held the morning following the exercise by the project’s executive sponsors. They used media attention to the exercise—and successful testing—to announce that the project had been successfully completed. Chapter 10: Implement the System 179 The system of systems is the functional collection of people, technology, and business processes. Separately, they met with the vendors’ representatives and formally accepted all the remaining contractual elements, releasing the final 10 percent of payment. The project was completed on time and budget (of course!). Training was a key part of its success, starting with the tabletop exercises for functional testing, to traditional “train-the-trainer” methods, and on to training in the real context of how the system will be used. This focus on training means the collection of technologies, policies, procedures, and people will work as a single system. Chapter 11: Transition to Long-Term Governance What The ongoing work to keep technology and organizational processes working toward interoperability goals over the lifecycle of the system. Why In a word, because of entropy. All systems, natural and manmade, deteriorate over time if left unattended. Communications interoperability isn’t a one-shot proposition. Who A revised governance structure, involving many of the project’s participants, is needed to maintain the system of systems over its lifecycle. The Steering Committee bears the responsibility of creating the ongoing structure before dissolving the project team. When Immediately after implementation, the project has to be closed out and the maintenance phase begun. Original Tech Guide Icon Chapters 18 and 19 of the Law Enforcement Tech Guide cover project closeout, maintenance, and grant management for technology projects in general. If you have followed this Guide in carrying out a communications interoperability project, congratulations are in order. Following implementation of the technology and processes to put it to work, there is cause for celebration as your agencies move into the subsequent and long-term phase of systems maintenance. There are a few final project details to attend to, but we’re going to suggest you do that very thing soon: Celebrate! 184 Part II: How Is Interoperability Achieved? A System of Systems We’ve used the term “system of systems” throughout this Guide. Your communications interoperability system, for better or worse, richer or poorer, is the collection of policies, procedures, and technologies, as well as training and exercises that tie it all together. As we’ve said, all systems have geographic, technical, and functional boundaries. They also have administrative boundaries where jurisdictions participating in your system of systems have to work with “outsiders.” safEcOM twenty-year Vision Established 2003 There is an integrated system-of-systems, in regular use, that allows public safety personnel to communicate (voice, data, and video) with whom they need on demand, in real time, as authorized.40 All communications systems have boundaries. Over time, successful communications interoperability systems have a way of melding with neighbors at the borders. If public safety agencies are able to create an integrated system of systems, nationally, it will be a complex of different technologies and procedures that meet the needs of agencies rural and urban, large and small, paid and volunteer. It will support all who have to respond to emergencies that don’t respect geographic, technical, functional, and administrative boundaries. Systems—in all their animate and inanimate dimensions—have to be maintained over time. Communications interoperability systems are no exception and will, indeed, otherwise deteriorate rapidly because they are dependent on the proper functioning of so many pieces. This lifecycle maintenance encompasses not only the technology that you’ve just implemented, but the governance and management structures that drive the system, the policies and procedures that define it for all practical purposes, and the training and exercises that make it real. 40 U.S. Government Accountability Office, Homeland Security: Federal Leadership and Intergovernmental Cooperation Required to Achieve First Responder Interoperable Communications, GAO- 04-740 (Washington, D.C.: July 2004) p. 54. Chapter 11: Transition to Long-Term Governance 185 Project Closeout Program Managers Icon Before moving on to the long-term, recurring processes of maintenance, we have a few loose ends with the project to wrap up. Through the following steps, the project is completed. Hold a Transition Meeting Hold a meeting to hand over the keys. As mentioned in Chapter 10, complex systems are managed by vendors through installation. At some point, often in a series of steps, system management is handed over for long-term maintenance. You may have chosen to have one or more of your vendors stay on to maintain portions of the technology over time, but typically there are still configuration and monitoring tasks, at least, to transition. A final transition meeting is useful to get everyone in one room to hand over the keys to the technological components of your new system. Proceed involving project management and vendor staff, as well as the technicians and all stakeholders who will be charged with maintaining the hardware, software, and other physical components of the system. Follow the transition meeting with a larger, open meeting for broad attendance. Conduct an Open Review Meeting Executive Sponsors Icon Too often, projects wind down or drag on without a real end point. This has an unfortunate effect on project participants who, naturally, need to see a positive end point that signals success. Recognizing that there are processes that will continue on for weeks and months to come, find a natural breakpoint to hold an open review meeting. Conduct a review where executive sponsors, the Steering Committee, and the rest of the project team can sit down to examine the project from start to finish. Honestly evaluate how well the project’s objectives were met and how the process to achieve them varied from original expectations. Ask the simple question of what participants would do differently if they were to undertake the same project again. Use the opportunity to publicly declare success. Use the open review meeting to celebrate the successful completion of your project. The completion of the meeting is a great time for the executive sponsors to issue press releases and otherwise publicly announce the project’s completion and its success. With large projects, use a public forum afterward to present the project, problems faced, and hurdles overcome. Carefully document all discussions, as they will be useful in your last job as project manager: The final report. 186 Part II: How Is Interoperability Achieved? Grant Requirements Icon Contribute lessons learned in your final report for the benefit of others. Write a Final Report For the sake of those who will come afterward, write a final project report. It may be a requirement if the project was grant-funded, but should be considered necessary in any regard. The report documents the final project timeline and costs. It also documents how the project’s objectives were met and what performance measures were used to assure quality. A final budget and cost accounting is critical for both understanding and justifying costs. Your past work to keep the project and implementation plans up-to- date will simplify this task! The report will be of most use to future readers from your agencies and perhaps others if it includes a succinct statement of lessons learned during the project. These are likely to be organizational, management, and operational lessons as much as they are to be technical ones. In our work with jurisdictions across the country that are striving to improve communications interoperability, we find the most meaningful lessons coming from other agencies that have been down similar paths. Contribute your lessons learned as a special section of your final report. Get Internal Acceptance Wrap up the project by delivering the final report to first the Steering Committee and then the executive sponsors for their review, changes, and eventual approval. Use a simple signing ceremony to officially close the project. Govern and Manage A cardinal principle of Total Quality escapes too many managers: You cannot continuously improve interdependent systems and processes until you progressively perfect interdependent, interpersonal relationships. —Stephen Covey We should be so fortunate that signatures on the final report signal the achievement of communications interoperability. The reality is that the project end marks the beginning of a process of ongoing governance and management. It’s a process necessary for continued interoperability and continuous improvements that will go on as long as agencies need to communicate with one another. The project Steering Committee should create an ongoing governance and management structure to assume the helm upon its own dissolution. Build Long-Term Governance Structures Long-Term and project governance structures vary in at least a couple of ways. For obvious starters, long-term structures are intended to remain in effect indefinitely, which leads to a different dynamic between participants. The need for executive sponsorship separate from steering has disappeared. While processes always need Chapter 11: Transition to Long-Term Governance 187 champions, the most effective champions for ongoing governance are those who can participate in its regular, if less frequent, deliberative meetings. Agency executives who are able and willing to actively participate will lend strength to ongoing governance and management, however. Ongoing processes need champions, but not executive sponsors. In addition, many representatives who would insist on being part of the Steering Committee will now be comfortable stepping back from regular meetings and delegating ongoing oversight to joint representatives. This may be a process that takes a while, but will occur over time. Create the Board or Council Regional Icon The ongoing governance structure doesn’t need to be significantly different from that used for the project. Some of the titles change and reporting responsibilities vary a bit, but otherwise there can be a smooth transition from the project to maintenance phases. See Figure 11-1 for a sample governance structure. Adapt your project governance structure for ongoing needs. Your structure will vary, as did your project governance, based on the scope of your initiative. Whether the project is large or small, ongoing oversight can be provided by a similar, but smaller group. Large initiatives for widely shared systems face difficult choices between models, such as creating independent governmental or quasigovernmental organizations or partnering with private companies. Regional projects, on the other hand, typically act as consortia of independent jurisdictions operating under mutual agreement. Image of Sample Ongoing Governance Structure Figure 11-1: Sample Ongoing Governance Structure 188 Part II: How Is Interoperability Achieved? A typical long-term governance structure for a moderately sized initiative, costing from a few hundred thousand to several million dollars, needs no more than a central board, User and Technical Committees, and one or more hired or designated managers. Seriously consider limiting the size of the board. Any body that has more than 10 members needs an executive committee of fewer people to get work done between meetings. All participating jurisdictions can and should be represented, although they don’t necessarily need a seat on the board. Partner with the Statewide Interoperability Committee SIECs are state or statewide interoperability executive committees. Increasingly, statewide interoperability committees or councils are being created to more broadly guide efforts. Many had their origins as state interoperability executive committees (SIEC) or an equivalent required by the Federal Communications Commission (FCC) of states that chose to manage 700 MHz radio spectrum dedicated to interagency communications. Following September 11 and the greater focus on communications interoperability it brought, these committees have grown in many cases to represent public safety agencies statewide more broadly on the subject. Establish a liaison with the statewide interoperability committee to keep regional efforts aligned with what is going on elsewhere. Regional efforts near borders should participate with adjoining states’ SIECs, as well. Tips Icon STATEWIDE INTEROPERABILITY COMMITTEE RESOURCES Federal Communications Commission (FCC): http://wireless.fcc.gov/publicsafety/700MHz/interop.html National Public Safety Telecommunications Council (NPSTC): http://www.npstc.org/siec/siec.jsp Association of Public-Safety Communications Officials International, Inc. (APCO): http://www.apcointl.org/frequency/siec/documents/documents.htm Chapter 11: Transition to Long-Term Governance 18.9 Formalize Agreements MOUs are suitable for small initiatives. If your project didn’t lead you to formal agreement between agencies, ongoing operations will surely take you there. Formalized agreements are necessary to establish authorities, responsibilities, and mutual expectations. In order of increasing formality, these are familiar to most public safety officials as memoranda of understanding (MOU), memoranda of agreement (MOA), inter-local agreements (ILA), intergovernmental agreements (IGA), or joint powers agreements or authorities (JPA). Study your local and state regulations covering interagency agreements. Each jurisdiction will have a different protocol acceptable for creating and adopting these types of agreements. Those involved in your initiative may each have different requirements, though the greater informality of MOUs lend themselves to simple agreements, particularly for smaller initiatives. Study your local and state regulations covering agreements between agencies and divisions of government. Appendix A includes example agreements for simple and more complex sharing projects. Any agreement covering all aspects of system sharing, including governance, basic use procedures, and maintenance responsibilities, will be an extensive document. Make Use of the Project Communications Plan Your project communications plan is a great resource to be carried to ongoing governance and management. It addressed sharing information between the various stakeholders who now have more of a stake than ever. Agencies, governing bodies, user and support personnel groups, and the public will need information indefinitely about the system or state of communications interoperability. Adapt the project communications plan for the new board or council. Tips Icon Governance Resources To find more information on governance structures for large, shared systems, see the supplemental resources that were produced by the National Task Force on Interoperability (NTFI): http://www.justnet.org/pdffiles/ntfi_supplemental.pdf (~3.0 MB) 190 Part II: How Is Interoperability Achieved? Build a Sustainable Financial Structure Interoperability projects can be very expensive. Agencies regularly ask, “Where do we get the money?” “Where do we get the money?” The sources are many and varied, ranging from the public agency equivalent of passing the hat (asking participants to provide some share of costs out of their own budgets), to grants, and perhaps new forms of recurring review, such as taxes and fees. We’re aware of jurisdictions that have turned to the private sector for grants and donations, although these typically provide only a small share of what are often costly projects. Original Tech Guide Icon, page 235 Grant funding is traditionally sought for technology initiatives. The Law Enforcement Tech Guide provides a whole chapter on grant management and compliance that you will find invaluable if you have received a grant. Homeland security grants have become a new source of interoperability funding in recent years, but are highly sought after for other types of projects as well. As homeland security grant funding has increased, other existing programs have diminished. Interoperability is a national concern and need. Federal grant programs can only fund a share of a small number of needed initiatives across the country. Plan for the Total Cost of Ownership The total cost of system ownership can be double its purchase price. The total cost of ownership (TCO) for radio communications systems can be as much as twice the original system cost. A system, over its lifecycle, may cost as much to operate and maintain as to purchase. Tips Icon Grant Funding Resouces The SAFECOM Program maintains a web page listing potential sources of funding for communications interoperability projects: http://www.safecomprogram.gov/SAFECOM/grant/default.htm Chapter 11: Transition to Long-Term Governance 191 Total costs of ownership for communications interoperability projects consist of: — Development, procurement, and contracting costs — Site development, including real estate and fixed facilities — Hardware and software purchases, installation, configuration, and testing — Frequency coordination and licensing — Extended warranty and upgrade contracts — Maintenance, support, and training costs — Personnel costs for support staff and training overtime Estimate a 10 year lifecycle for modern voice radio technology. — Operations costs, such as electricity and telecommunications circuits. Modern voice radio systems have an expected lifespan of about 10 years. Though user and infrastructure radios have traditionally been kept in service two or three times that long, today’s sophisticated systems are increasingly computer-controlled and become obsolete much more rapidly. Manufacturers establish technology lifecycles, which affect upgrade needs and, eventually, replacement. WLAN lifecycles are estimated as 3 to 5 years. Data communications systems are in an even greater state of flux as more and more agencies move from low-tech systems they owned, operating essentially as did their voice radios, to higher bandwidth systems, both governmental and commercially operated. A major manufacturer of equipment recommends using a 3- to 5-year period for calculating the TCO of wireless local area networks (WLAN).41 Consumer- grade technology tends toward the lower end of that time range, while that built for military and public safety purposes can physically be expected to last much longer, perhaps beyond its useful life. For planning purposes, figure that the technology lifecycle for data communications radio technology is closer to 5 years. Ongoing costs are commonly 10 percent of the original technology cost. Also for planning purposes, estimate that ongoing operations, maintenance, and other support costs will annually cost roughly 10 percent of the initial cost of the technology. Costs for real estate and physical infrastructure, which can safely be estimated to have a life span of 30 years, may be taken from the initial costs for this estimation. However, there are ongoing costs for inspections and maintenance of infrastructure. The good news is that your agencies are probably already paying a portion of that cost in the form of maintenance and support personnel. You’ll have to determine if there will be added staff and training costs in the future based on the scope of your project and the agencies’ willingness to share maintenance responsibilities. 41 “Wireless LANS – Total Cost of Ownership,” Cisco Systems, Inc., 2004. See http://www.cisco. com/application/pdf/en/us/guest/products/ps4076/c1244/cdccont_0900aecd801bb7d4. pdf. 192 Part II: How Is Interoperability Achieved? Create a Long-Term Funding Model Ultimately, taxpayers bear the cost of communications interoperability. Grant funding has provided the impetus for many technology projects, but it isn’t part of a long-term funding model. It’s imperative that the ongoing costs of your system of systems are addressed early and in depth. Sustainable funding structures require dependable, recurring revenues. Ultimately, taxpayers bear the cost of providing public safety communications interoperability. A funding model consists of project costs, funding sources, and policies for cost sharing. Create 5- and 10-year projections of expenses and revenues. A 5-year plan is sufficient to account for budget cycles and the expiration of initial warranties. A 10year plan has to take into account the system lifecycle and the planning costs, at least, for the system’s replacement. Use 5- and 10-year projections. Long-Term funding models are as varied as the initial systems and their funding sources. The simplest are based on a handshake agreement. More complex initiatives, such as those making use of shared systems for both their intra- and interagency communications, often make use of monthly service fees to pay at least ongoing costs. Observed monthly costs range from $20 to $60 per end-user radio. Innovation is on the upswing in funding communications interoperability projects. Fees are being assessed on consumer services, such as telephones, and vehicle registrations. General appropriations and earmarked taxes are often necessary to balance the budget. Bake sales are out. Tips Icon shared System Costs Consider the following costs and responsibilities for shared systems. + Infrastructure purchase – Apportioned to the jurisdiction where located. + Mandatory system upgrades – “Must have” upgrades or system additions are paid for by the jurisdiction whose subsystem must be upgraded to coexist with the larger system; systemwide upgrades are apportioned across all jurisdictions. + Optional system upgrades – “Nice to have” feature costs are shared between jurisdictions desiring the upgrade. + Infrastructure maintenance costs – Apportioned across all jurisdictions. + End-user equipment purchase – Covered individually by jurisdictions. + End-user equipment maintenance – Covered individually by jurisdictions. Adapted from Wake County (North Carolina) Interlocal Agreement for its 800 MHz trunked radio and CAD systems Chapter 11: Transition to Long-Term Governance 193 The pursuit of perfection often impedes improvement. —George Will Create a Review Process As the final piece of setting up governance and management, create a process for periodic review of all aspects of the initiative—from the governance structure and its membership to the financial structure. Focus particularly on the system policies and procedures that fuel communications interoperability. Reviews bring out needed updates and validate those parts that don’t need changes. They provide a means of continuous improvement without participants becoming lost in a pursuit of perfection. Periodically review the governance and financial structures, as well as policies and procedures. Annual reviews are usually sufficient. Stagger individual reviews throughout the year to make them less of a chore, sharing ongoing work across participants. For example, January is a good time for strategic reviews to capture the enthusiasm of the new year during a slower period for most agencies. The financial structure and budgets may be reviewed shortly before the end of the participants’ fiscal year—presuming they are similar—to identify needs that might be met through year-end funding and to prepare a budget, if needed. Have a wish list for surprise year-end opportunities. Policies and procedures should also be reviewed on a rotating schedule throughout the year to spread the work. The User and Technical Committees appropriately bear the bulk of the effort, with the Board, in whole or part, annually reviewing management policies and procedures. Spread reviews through the year and responsibility across the participants. Chapter 12: Develop Policies and Procedures What Formalized interagency agreements on how the system will be maintained and used, integrating the National Incident Management System (NIMS). Why Interagency communications policies and procedures establish how technology is to be used to achieve interoperability. Integration of NIMS ensures an operational focus compatible with incident management systems with other potential cooperators beyond the initiative. Who The system governance board approves acceptable policies and procedures developed by the User and Technical Committees. When Starting early in the project and carried on through a process of continuous improvements after implementation. In Chapter 10, we briefly touched on the creation of policies and standard operating procedures (SOP). We noted that they evolve from SOPs existing within or, potentially, already between partnering agencies that influenced your project needs statements. During implementation, some are ideally further defined and executed through initial system training. The bulk, however, are likely to grow as the system is used more and more. We refer here to policies as proscriptive rules and procedures as practical guidance for how something is done. Policies may make procedures mandatory, but SOPs aren’t necessarily so. 198 Part II: How Is Interoperability Achieved? Integrate NIMS into SOPs Interoperability Continuum Icon SAFECOM’s Interoperability Continuum addresses standard operations procedures (SOPs) as one of its five key dimensions in achieving interoperability. SOPs based on the Naional Incident Management Systems (NIMS)42 are identified as an indicator of advanced communications interoperability. Central to NIMS integration into policies and procedures is the Incident Command System (ICS). Policies and procedures based on ICS, incorporating its structure, conventions, and operational principles, bring commonality to the way different agencies work. NIMS-integrated SOPs lead to interoperability. Create policies and procedures for routine and targeted capabilities using a standard model adopted by the governing body. Address technical and operational aspects of the system, integrating NIMS throughout. This approach assures the greatest communications interoperability, plus compatibility with neighbors far and wide. We will cover communications aspects of NIMS ICS in detail shortly. Focus on Routine and Targeted Capabilities National Priorities: –nImS –Information sharing –Communications interoperability Policies and procedures for communications systems, first and foremost, provide for agencies’ day-to-day operational needs. Procedures that are used regularly become part of a responder’s natural reactions. All emergency response disciplines recognize that, under the stress, people perform as trained—for better and worse. The classic, if tragic, story in law enforcement is of the officer found shot with empty cartridge cases in his pocket, having spent hours on the shooting range practicing “procedures” that had nothing to do with—and were counterproductive to—surviving a shootout. People perform as trained—for better and worse. During the stress of emergencies, responders will most reliably perform the tactics they have learned, exercised, and used daily. Interagency communications procedures are only effective if used. They are most likely to be used if they are part of daily or, at least, very regular practice. Tactics and tools used daily will be most reliable during unusual emergencies. Lay the groundwork for automatic behaviors during emergencies by establishing routine interagency procedures. Make the less common ones memorable by making them simple, by creating “cheat sheets” for easy reference, and by practicing them during exercises. Don’t presume that every proscriptive policy and each procedure established will immediately become part of every responder’s repertoire. 42 See Chapter 3, Operability—Job #1. Chapter 12: Develop Policies and Procedures 199 Targeted Capabilities In late 2003, Homeland Security Presidential Directive 8 (HSPD-8), “National Preparedness,” was released.43 Its purpose was to strengthen preparedness capabilities of all levels of government to terrorist attacks, major disasters, and other emergencies. It required development of a national preparedness goal44 that included readiness metrics and full implementation of a closely coordinated interagency grant process for first responder preparedness assistance by the end of federal Fiscal Year 2005 (September 30, 2005). The directive noted that, “[t]o the extent permitted by law, Federal preparedness assistance will be predicated on adoption of Statewide comprehensive all-hazards preparedness strategies.” Three of the seven national priorities articulated in the National Preparedness Goal (NPG) are particularly relevant here: Implementation of NIMS, strengthening of information sharing and collaboration capabilities, and strengthening communications interoperability. The NPG relies on an approach called Capabilities- based Planning to reach the goal, with 15 standardized National Planning Scenarios, a Universal Task List to reference tasks performed by all levels of government and different disciplines during incidents, and a Target Capabilities List identifying capabilities needed to perform the tasks. Emergency operations plans are to be built upon SOPs consistent with NIMS. The National Response Plan provides a concept of operations to which state and local emergency operations plans are intended to be aligned. Emergency operations plans are supported by or built upon SOPs that are intended to be consistent with NIMS guidelines, standards, and protocols.45 Emergency planners are expected to identify tasks from the Universal Task List that their organizations need to perform based on their assigned roles and mission. The Target Capabilities List (TCL) descriptions are used to determine the capabilities needed to accomplish these tasks, variously by different response elements. Interoperable communications is one of four capabilities common to all mission areas. Currently, there are 36 capabilities in the list, of which 32 are grouped into four mission areas: Prevent, protect, respond, and recover. The remaining four are capabilities common to all mission areas. Interoperable communications is second among the four common capabilities. 43 See http://www.whitehouse.gov/news/releases/2003/12/20031217-6.html. 44 See http://www.ojp.usdoj.gov/odp/assessments/hspd8.htm. 45 The National Response Plan and National Incident Management System were established by Homeland Security Presidential Directive 5: Management of Domestic Incidents (HSPD-5). See http://www.whitehouse.gov/news/releases/2003/02/20030228-9.html. 200 Part II: How Is Interoperability Achieved? Work is under way to define conditions and standards for each task, as well as performance measures and metrics to assess capabilities. Measuring communications interoperability is addressed in Chapter 15, Measuring Interoperability. Throughout this book, we address communications interoperability capabilities generally. They are not listed here for security purposes. Adoption and incorporation of NIMS and capabilities listed in the TCL will lead to advanced interagency communications supporting common response processes. Specific information on the National Response Plan tasks and capabilities can be found in the U.S. Department of Homeland Security’s Lessons Learned Information Sharing web site.46 Establish and Use a Standard Method A standard method for procedures simplifies their creation and maintenance. Policies and procedures governing interagency communications are crucial for interoperability. Agencies that have adopted a standard method for their creation have found them easier to develop and maintain. Two examples come from the northern latitudes: Minneapolis-St. Paul, Minnesota, and the state of Montana. Shared Systems in the Twin Cities The Metropolitan Radio Board (MRB) of the Minneapolis-St. Paul, Minnesota, area oversees a radio system shared between many agencies. It’s the nucleus of what is becoming an even larger system and is in a period of transition as of this writing. The MRB has used a standardized template and approach to create an extensive set of standards, protocols, and procedures. The comprehensive standards document, which is available online,47 includes a template showing and describing seven elements: — A document title, control, and approvals block — A purpose or objective statement — A technical background statement describing capabilities and constraints under which the standard, protocol, or procedure is used 46 The Lessons Learned Information Sharing web site is only available to emergency response providers and homeland security officials. Registration is required and eligibility is verified. See https://www.llis.dhs.gov . 47 System governance is being transferred to the Metropolitan Emergency Services Board and the system is becoming part of the larger, statewide system. The document is currently available through the Statewide Radio Board at http://www.armer.state.mn.us/. Chapter 12: Develop Policies and Procedures 201 — An operational context statement addressing when it is appropriate — A recommended protocol/standard statement addressing related criteria that qualify use of the one being established — The recommended procedure, itself, describing how the task is performed, including individual steps and locations of reference documents — A management statement describing who is responsible for supervising or managing this procedure. Appendix B contains an example from the MRB document that addresses patching of shared channels in the region to the system. Shared Channels Under the Big Sky The Montana shared channels plan includes policies, procedures, and practical use examples. The state of Montana has a comprehensive, shared channels plan widely used by local, state, and federal responders in the state.48 It defines 14 channels available for use across disciplines, incorporates ICS throughout, and provides practical examples of use. The bulk of the plan addresses practical applications, with the formal plans, plus policies and procedures, included as appendixes. The formal plans for each channel are simple, one-page documents describing the purpose of the channel, eligibility for use, and basic usage standards. More detailed policies and procedures documents are provided for each separately, addressing in a standardized form oversight, eligibility, licensing and authorization, operations, requirements, procedures, and channel use discipline. The Montana shared channels plan demonstrates a standardized method for creating policies and procedures, coupled with practical demonstrations of use. Create Technical Policies and Procedures Following a standardized method, you can create policies and procedures that both serve your system of systems and are manageable. Both technical and operational SOPs will be needed. The Technical and User Committees of the governing body are commonly tasked with responsibility to create the SOPs, carry them through approval and adoption, and maintain them over time. 48 Montana Mutual Aid and Common Frequencies, State of Montana, 1990-2005. The most current version is a minor update to the 1994 edition written by this author. See http://itsd.mt.gov/ techmt/publicsafety/mutal_aid_manual/2005_mutual_aid_book_2005_web_final.pdf. 202 Part II: How Is Interoperability Achieved? Many technical SOPs can be developed over time, shaped by your system and needs. Some of the more common ones include: — Equipment management and deployment — Standard equipment configurations — Maintenance of radio caches — Gateway configuration, maintenance, deployment, and use — Outage responsibilities and standards for repairs — Availability of spare equipment — Preventive maintenance — Notification of maintenance activities. Technical maintenance needs are addressed in Chapter 14, Maintain the Technology, which discusses some specific activities where technical SOPs may be necessary. Create Operational Policies and Procedures Operational policies and procedures address how the technology is put to work. Many will arise from existing SOPs, but you will need to develop others that extend the interagency communications capabilities through your new system. The highest levels of interoperability are achieved through integration of the NIMS into procedures used regionally across participating jurisdictions. ICS Communications Unit Under ICS, the Communications Unit is under the logistics Section. Under NIMS ICS, the Communications Unit is established as a logistical service function. It is responsible for establishing the Incident Communications Center (ICC), which is typically part of the Incident Command Post, and creating the Incident Communications Plan.49 The Communications Unit Leader is responsible for participating in incident planning meetings to do the following: — Determine the feasibility of providing the required communications support — Provide operational and technical information on communications equipment available for the incident — Provide operational and technical information on communications equipment capabilities and restrictions.50 49 ICS uses standardized forms. The Incident Communications Plan, described further in this chapter, is based on form ICS 205. See http://www.nimsonline.com/nims_3_04/examples_ of_ics_forms.htm#205. 50 Adapted from current editions of National Wildfire Coordinating Group task books. Available at http://www.nwcg.gov/pms/taskbook/logistics/logistic.htm. Chapter 12: Develop Policies and Procedures 203 The Communications Unit includes a leader, technicians, radio operators, and ICC managers. The Communications Unit is composed of four different positions, as needed: The unit leader, technicians, radio operators, and ICC managers. These positions are only filled when needed. Appendix C provides tasks lists from NIMS-compliant source material for each of these positions. Integrated communications is an original, fundamental tenet of ICS. Policies and procedures for use of the ICS Communications Unit during larger emergencies are important for communications interoperability. Incident Dispatch Teams In the public safety field, incident dispatch teams have grown in popularity over the past few years. In law enforcement, they are more commonly known as tactical dispatch teams for their role in supporting SWAT team operations. By either name, incident dispatchers and their supervisors would staff the ICS radio operator and ICC manager positions, respectively, in a NIMS-based response. During large emergencies, an on-scene communications center is crucial. Consider establishing policies and procedures for incident dispatch teams as part of your Communications Unit. Tips Icon Incident Dispatch Resources At least two organizations exist for the benefit of incident dispatch. The California Tactical Dispatcher Association is focused primarily on police operations: http://www.tacticaldispatch.com/ Incidentdispatch.net, also based in California, is more broadly focused on all-risk incident communications: http://www.incidentdispatch.net/ Almost all aspects of communications continue to be problematic, from initial notification to tactical operations. —Arlington County, virginia 9/11 After-Action report Emergency Traffic From a very practical standpoint, communications procedures continue to be problematic. Improved interagency communications depends on developing some of the most basic emergency procedures. For example, consider how traffic is held or cleared on a channel for other, higher priority emergency traffic. Most agencies have procedures for declaring “emergency traffic only” on a channel. In routine operations, dispatchers are charged with the responsibility on dispatch 204 Part II: How Is Interoperability Achieved? channels of declaring it or accepting an announcement from another user. They are in charge of controlling the network, in effect, and opening it back up for regular traffic. Procedures are also needed for emergency traffic on channels that dispatchers don’t manage. Tactical channels used on scene are in equally high need of procedural definition of who declares “emergency traffic,” who controls the channel, and how it’s cleared. Typically, the highest-ranking ICS position on the channel bears the responsibility. Channel Span of Control Communications often becomes the ‘fall guy’ for organizational problems. An excessive number of responders attempting to talk to the IC* (generally all at once), compressed time, getting behind and chasing the incident problem, playing ‘catch up,’ and general operational confusion can quickly beat up and overwhelm any incident commo [communications] plan/system. … Any part of the system operating beyond their effective span of control (five to six) will almost instantly develop commo problems. The way to fix the commo problem is to fix the span-of- control problem, and (bingo!) the commo settles down and becomes normal. —Fire Command Chief Alan Brunacini, Phoenix (Arizona) Fire Department * Incident Commander Very similar to the ICS principle of maintaining a manageable span of control in supervision, channel span of control procedures are important. The history of emergency response is replete with stories of responders in dire circumstances who couldn’t get access to a channel because of too much traffic. One of the most tragic occurred in Hackensack, New Jersey. In its 135-year history, nine Hackensack firefighters made the ultimate sacrifice. Four have died in motor vehicle accidents. Five perished during one fire on July 1, 1988. Two firefighters—who initially survived the collapse of a bowstring truss ceiling that claimed the lives of the others—were trapped inside where they were unable to communicate their situation due, in part, to the channel being overloaded with other tactical, command, and dispatch traffic. Maintenance of a manageable span of control on a radio channel enforces the more general ICS management principle. Use of tactical channels removes some share of other incident traffic from broader dispatch and response channels. Ideally, only a single supervisor and subordinates would operate on a single channel. Any more than that and responders have to decipher traffic not intended for them, risk mixed orders, and compete for the channel when they have emergency traffic. The volume of traffic on overloaded channels has caused more than one responder to turn the volume down or radio off in order to have a moment to think or converse with others. Operations with extremely compressed timeframes, such as SWAT incidents, advanced life support, and most firefighting require simple, direct, and immediate communications capabilities. This can only be provided by maintaining a manageable channel span of control. Create policies and procedures that move incident traffic from cluttered channels to operational and tactical channels organized in a manner similar to the incident organizational structure. Chapter 12: Develop Policies and Procedures 205 Common terminology, resources definitions, and plain language are crucial for communications interoperability. Standard Language Much of what passes as poor communications is actually miscommunications. NIMS ICS and its predecessors identify as its first management characteristic the use of common terminology for organizational elements, position titles, resources, and facilities. One of the most important policies that can be established for interagency communications is common terminology to be used by responders, further reinforced through procedures. In addition, standard resource definitions improve interoperability. From a communications standpoint, naming conventions for channels and other communications resources are critical to get standardized across jurisdictions. It’s unfortunately common for agencies to be working together with a common radio channel at their disposal that they’re unaware of or that are named so differently that nobody would associate them. Some regions go so far as to establish not only standard names for shared channels or talkgroups, but also standard programmed positions in the radios for interagency resources. Last, the most important language policy that can be adopted to improve interagency communications is the use of plain language—eliminating codes and jargon. This is a simple idea, but every vocation and avocation has its own terminology. When these diverge across agencies and disciplines, responders don’t communicate. Communications-Order Model Another communications best practice that has proven effective is a communications- order model that provides positive message acknowledgement. This is a basic process that can work with any medium, voice or data, but is most clearly seen with first responder push-to-talk radio communications. It’s simple and we do it in our daily lives when we’re communicating best. Five steps are involved: 1. Calling unit gives the name of the called unit, followed by its own. 2. The called unit responds with the reverse. 3. The calling unit transmits its message. 4. The called unit briefly restates the message to show understanding. 5. If the message was received correctly, the calling unit responds with an affirmative acknowledgment, otherwise responds “Negative” and repeats the message. 206 Part II: How Is Interoperability Achieved? Some jurisdictions reverse the order of whose “name” goes first. A standard convention is most important, though there’s bound to be those border issues where one convention butts into the other, confusing everyone who doesn’t recognize the callers’ voices and is trying to figure out what’s going on. While there is no definitive standard, we suggest the sequence above. It’s used by many public safety agencies, the U.S. Army, and air traffic controllers, which is good enough for us! Positive message acknowledgment is good communications. The keys to the communications-order model are convention and positive message acknowledgment. The sender knows the message was received as intended. With practice, it can be done efficiently, with a fraction of the airtime necessary for repeated and missed messages. Operational Unit Reporting The final example of a communications SOP for operational purposes is standardized unit reporting. Beyond the obvious value of clearly communicating who’s talking and what the message is, status information can be transmitted efficiently that provides greater context for all parties involved in the conversation, active or not. Standardized reporting during multiagency response when confusion often reigns can be established through policies and procedures. Development of unit reporting procedures gets operations folks talking about operational needs and uses of the system. A simple example is the transmission of location and status by reporting units— typically those in the field—once during a sequence of transmissions. While modern trunked radio and automatic vehicle location (AVL) systems capture some of this information, nothing is so simple and effective for all participants as a simple voice transmission. Not every one who “needs to know” will be near a CAD display or using AVL-enabled radios (essentially only mobiles). A simple “Available at staging” statement says a lot. Operational unit reporting procedures across agencies are powerful tools to flesh out the system of systems by getting field operations staff talking about what they need to talk about. Build Incident Communications Plan Templates SOPs drive the development of the incident communications plans. Under ICS, the Incident Communications Plan is documented using the ICS 205 form, which is itself part of the formal Incident Action Plan (IAP). The IAP is a collection of forms, starting with the ICS 201 (Incident Briefing), plus supporting material. Chapter 12: Develop Policies and Procedures 207 ICS 205 The Incident Communications Plan—sometimes called the Incident Radio Communications Plan—is specific to an incident due to its unique geographic location and extent, the type of operations supported, and the scale of response. Templates are useful tools in preparing for response.51 Templates are useful, but communications plans have to be customized for large events. Plans do have to be customized by a Communications Unit during larger emergencies, however. What constitutes a large emergency is jurisdiction-dependent. Basically, any response requiring more than a couple dozen responders needs an on-scene, incident communications center of some form—and a communications plan tweaked somewhat to fit the incident. The ICS 205 identifies communications resources, their functional assignments (e.g., “Talkgroup X is assigned to Division A command”), and technical parameters of the resource, such as frequencies and tones for conventional channels. From an operational standpoint, the ICS 205 says a lot about the participating agencies and the incident command structure. A well-done Incident Communications Plan both reflects and reinforces the command structure. Supplemental material may describe such things as usage priorities, procedures, and protocols. The diagram in Figure 12-1 depicts a realistic organization chart identifying responders to a hypothetical event by their function. This is highly preferred to identification by agency, which tells the user nothing about what they’re doing. In this example, each line between functional elements represents a communications path of some sort. During emergencies, these are typically radio channels—whether discrete frequencies in a conventional system, talkgroups in a trunked system, or even composite channels as may occur when multiple frequencies and talkgroups are patched together with a gateway. Branch directors, group supervisors, and team leaders are standard ICS position titles. Consider an example. The “Law Enforcement Branch” director and each of the team leaders and group supervisors are connected by a common line, or channel, of some form. The communications plan has to identify how that connection is made. Typically, some radio channel would be assigned for “Law Enforcement Branch Command,” which is represented by that line. The ICS 205 for this scenario would, figuratively, describe how each of those interconnecting lines is supported with communications. 51 The National Wildfire Coordinating Group, a long-organized group of government agencies with wildland firefighting responsibilities, has standardized the ICS 205 and other ICS forms. See http://www.nwcg.gov. 208 Part II: How Is Interoperability Achieved? The experienced responder will notice that the chart in Figure 12-1 stops at a certain level of detail and doesn’t depict the tactical channels that would be used within many of the indicated operational elements. The diagram is simplified for the sake of discussion, whereas an actual incident response with those operational elements would likely involve more than a hundred responders. The ICS 205 for the scenario— whether as a template or an actual incident plan—would identify all communications resources to be used to support the response. Image of sample Improvised Explosive Device Scenario Organizational Chart Figure 12-1: Sample Improvised Explosive Device (IED) Scenario Organizational Chart Chapter 12: Develop Policies and Procedures 209 Tactical Interoperable Communications Plans Grant Requirements Icon Under the Federal Fiscal Year 2005 Homeland Security Grant Program,52 all designated Urban Area Security Initiative (UASI) regions and one metropolitan area in each state without a UASI region, were required to complete a tactical interoperable communications plan. This plan was intended to identify how the region would support operational response within an hour of an incident occurring. The elements of the required plans may be instructional to all agencies, whether or not they were required to complete them as a condition of homeland security funding. Tactical interoperable communications plans are a requirement of some homeland security grant funding. Federal guidance for these plans suggested including the following elements: — Background, describing the urban area and how tactical interoperable communications would be governed in the region — An equipment and capabilities inventory, including points of contact for activating and supporting resources — Tactical interoperable communications policies and procedures — Incident communications plans matching resource to response structures — NIMS-compliant training planned for Communications Unit leaders — Appendixes that further document details. These topical areas outline well the information needed for incident communications planning. 52 See http://www.ojp.usdoj.gov/odp/docs/fy05hsgp.pdf. Chapter 13: Train and Exercise What The process of instilling skills and improving performance for achieving communications interoperability. Why As part of the system of systems for interoperability, users have to be prepared for routine and targeted capabilities in the context that skills will actually be used. Who The User and Technical Committees are responsible for guiding development of training and exercises for interagency systems. When Start training and doing realistic exercises during implementation, continuing in a process of continuous improvement through the system’s lifecycle. Not every difficult and dangerous thing is suitable for training, but only that which is conducive to success in achieving the object of our effort. —Epictetus All the policies and procedures created to improve interagency communications are useless unless they are put to work. Training and its practical counterpart, exercises, are required for any system of systems to work during routine events, special task force operations, or large-scale emergencies. Focus on Both Routine and Targeted Capabilities As noted previously, the most well-executed tactics are those used and practiced on a daily basis. Communications interoperability is achieved, foremost, through the regular use of interagency capabilities on a routine basis. A good plan today is better than a perfect plan tomorrow. —General George S. Patton Instill the best practices for response during emergencies large and small by building them into basic training and in-service programs, as well as into exercises that give responders even greater ability to use the communications capabilities during realistic circumstances. Meld the target capabilities of the National Response Plan into training for both routine and extraordinary events, to assure agencies involved in your initiative can leverage what they do daily for even larger emergencies. Recognizing that many capabilities will grow over time, use a process of continual improvement to chart progress. 214 Part II: How Is Interoperability Achieved? Train in Context The most effective method of training adults in practical skills is by doing it within the context of how the skills will actually be used. For example, the training mentioned previously that led police officers to pocket empty cartridge cases has given way to realistic, tactical training in which officers are required to seek cover, distinguish threatening from nonthreatening targets, and shoot effectively under added distractions. This training in the context of how skills will be used is very effective and applicable in communications training. I hear and I forget. I see and I remember. I do and I understand. —Confucius In effect, end users aren’t trained to use radios—they’re trained to communicate while doing their jobs. That may seem like a subtle distinction, but in practice it means that communications training is most effective when it is embedded within other training—not conducted in isolation. Building on the above example, realistic police communications training would require an officer to request assistance by radio while engaging targets on the range. Or a firefighter reporting completion after ventilating a roof with a power saw. Use Standardized Exercise and Evaluation Processes Exercises offer the opportunity to train skills in context. The use of a standardized exercise process, coupled with meaningful evaluations, provide the means to train and progressively develop skills. Exercises provide the means to stress-test the entire system of systems. From the perspective of communications interoperability, exercises provide an ideal opportunity to stress test the entire system, including the hardware, the software, and the “liveware.” A standardized exercise program includes a progressive set of exercises that are each appropriately evaluated, with results incorporated back into the program for further training. Grant Requirements Icon The U.S. Department of Homeland Security’s Homeland Security Exercise and Evaluation Program53 (HSEEP) provides extensive guidance for designing, conducting, and evaluating exercises. Discussion- and operations-based exercises are addressed in detail. The program is currently under revision to further incorporate the National Planning Scenarios, Universal Task List, and Target Capabilities List of the National Response Plan. Not only does the program provide useful guidance, its use helps jurisdictions meet requirements for grant funding. 53 See the HSEEP at http://www.ojp.usdoj.gov/odp/docs/hseep.htm. Chapter 13: Train and Exercise 21 Discussion-Based Exercises HSEEP addresses four types of discussion-based exercises: Seminars, workshops, tabletop exercises, and games. Seminars and workshops are familiar to most people, while tabletop exercises and games are less so. According to HSEEP, operational simulation games are an increasingly sophisticated and useful component of exercise programs. They seem to currently offer little in the way of communications training suitable for first responders, however. Tabletop exercises provide the means to master script for operations-based exercises. Tabletop exercises are probably more familiar in emergency training to most than games or other automated simulations. Tabletops offer an opportunity to first introduce new policies and procedures, identify disconnects as they are tested through discussion, and then master scripts that might be further tested operationally. Operations-Based Exercises Operations-based exercises provide training in context. As the name and distinction implies, operations-based exercises take participants to the field for actual training and practice. They provide the means to validate policies and procedures, while testing the technology as well. Three types of operations-based exercises are identified by HSEEP: Drills, functional exercises, and full-scale exercises. Drills are limited exercises. Drills are limited in scope, testing one part of the system in isolation, although as realistically as possible. An example for communications may be a drill of a technician team responsible for deployment of field gateways. Procedures that could only have been discussed during a tabletop exercise can be tested in more realistic circumstances, although still in isolation from a larger response system. This allows system managers and planners an opportunity to evaluate the procedures—as well as the drill design—for subsequent improvements. A functional exercise along the same lines might bring a special operations team and the technicians to the field with a mobile command post to test not only deployment and setup, but also further use. The exercise is still limited in scope and evaluation is key to the process of continuous improvement. HSEEP notes that functional exercises are generally designed to exercise the direction and control of resources, rather than systems. In our example, the gateway would not be thoroughly tested for functionality, capacity, and coverage, but rather for its appropriate deployment and operational command. Full-scale exercises stress-test entire systems. Full-scale exercises are, by definition, multijurisdictional exercises that bring out a full response system. Communications is tested as a part of a larger effort. This provides realism that exercises the communications interoperability system of systems, as a whole, in the context of how it’s used during near-real operations. Full-scale exercises are intended to stress-test systems under realistic circumstance and timeframes. 216 Part II: How Is Interoperability Achieved? Evaluations Exercise evaluations are necessary for a process of continuous improvement. As noted, exercise evaluations are crucial. They are appropriately designed, planned, and carried out with as much attention to detail as the rest of the exercise. HSEEP provides an entire volume addressing the process.54 Key elements include the use of a debriefing for planners, facilitators, controllers, and evaluators and a “hot wash” for all others. The hot wash follows the exercise immediately while multiple debriefings may be necessary to capture observations and document details from multiple sites. Debriefs and hot washes are used in evaluation of both discussion- and operations- based exercises. An After-action Analysis and Report (AAR) captures details more broadly for the record and recommends improvements. Under HSEEP, they are prepared for all exercises except workshops and seminars, where a summary report suffices. Communications is not an independent element of emergency response that can be adequately exercised and evaluated in isolation. It is only through integrated exercises that it can be trained in context, tested, evaluated, and set for continuous improvements. Interagency communications can likewise only be exercised adequately and evaluated critically through multiagency efforts. 54 Homeland Security Exercise and Evaluation Program, Volume II: Exercise Evaluation and Improvement, U.S. Department of Homeland Security. Available at http://www.ojp.usdoj.gov/odp/docs/hseep.htm. Chapter 14 Maintain the Technology What The ongoing work to keep technical components of the system operational over its lifecycle. Why Without maintenance, technology deteriorates over time. Optimal performance of technology is achieved through regular and preventive maintenance, coupled with a proactive process of managing changes to it. Who Ultimately, the system’s governing body is responsible for identifying which agency, agencies, or vendors will maintain different technical components of the system. When Starting from the day the technology is installed, throughout the system’s lifecycle. Maintaining your communications interoperability system of systems involves not only the human components, but also the technology they use. Upon implementation, your system technicians immediately went into maintenance mode. While new technology, once up and running smoothly, requires less initial maintenance, there are aspects that have to be maintained continuously. Identify Responsibilities Start the maintenance process by identifying responsibilities for each technological component of the system and each job that has to be done. Your implementation plan provides a good starting point for this effort. Address the roles and responsibilities of each participating agency’s technical staff, equipment installers (if independent), local radio shops that are to be used, and other network maintainers. This last category includes maintenance functions of leased telecommunications circuits, if you have used them. Use a matrix to chart responsibilities. Use a matrix of responsibilities that is charted by agency or organization. Cooperative systems being built around the country often have a particularly complex set of roles and responsibilities. Make them clear to reduce confusion and potential conflicts, while maintaining the highest level of system performance. 220 Part II: How Is Interoperability Achieved? Create a Technical Continuity of Operations Plan Near the top of the list of things to do in maintaining the technology is to create a continuity of operations plan. Technical staff are in the best position to manage risks naturally faced with the technology. A technical continuity of operations plan addresses the following: • Risks, including their likelihood, severity, areas of impact, and mitigation • Points of contact for managing outages • Procedures for notifying user agencies of outages • Technical adaptations to maintain system performance. During large-scale emergencies and disasters, information about impacts on communications systems is vital. Prepare the continuity of operations plan to inform incident management staff of immediate or imminent effects on this crucial piece of their response system. Do Regular and Preventive Maintenance Equipment built to public safety standards often comes with extended warranties that help underwrite the cost of repairing problems. Unlike consumer electronics, which occasionally find their way into emergency communications systems, public safety equipment is generally built to withstand years of routine use. The equipment still needs maintenance, however. Both electronics and physical structures need to be inspected, tested for proper functioning, and adjusted. As much as modern radios are driven by embedded computers, they still have other internal components that occasionally need to be tuned. Likewise, physical components, such as towers, shelter HVAC (heating, ventilation, air conditioning), and power systems, need to be inspected and maintained. Just one lighting violation notice from the Federal Aviation Administration (FAA) due to a failed tower strobe can ruin a system manager’s day! Testing and maintenance records are important to keep. Prior work on equipment is always useful for technicians to have at hand and may be necessary for documenting equipment failure trends. System infrastructure is tuned for optimal performance. Radio signal and line levels are adjusted for optimum performance, as are data network components. Records establishing a baseline for measurements and allowing tracking over time are invaluable for system maintenance. Some tuning measurements show seasonal shifts, while others show variance due to system load and component aging. Chapter 14: Maintain the Technology 221 One large jurisdiction with a P25 trunked radio system had to replace all of its new portable radios, numbering many thousands, not once, but twice. Technicians first found the radios unacceptably susceptible to other nearby portable transmissions, rendering them effectively deaf to the much weaker system signals from towers. After the portables had been replaced with great effort, another design problem was found in the push-to-talk (PTT) switches, which weakened over time, causing multiple erroneous system requests each time the button was pressed. These problems were discovered through agency testing and documented to prove the problem. Documentation of routine maintenance measurements is necessary for identifying and fixing problems. Test at Least Monthly The los Angeles Tactical radio Communications System (lArTCS) is a joint effort of city, county, and state agencies in los Angeles County. It is tested by user agencies twice a week. lArTCS connects together different radio systems through a gateway. See: http://www.lartcs.org Regular testing is important for assurance that the system will be available when needed. Schedule monthly tests, at least, to verify that system components are functioning as anticipated. The type and degree of testing should be established as a matter of policy and procedure. End-user testing on a regular basis is a good means to assure that the system is operational. Technical testing needs to also be conducted to detect problems before they affect operations. Maintain System Security Unfortunately, system security is often overlooked. Both physical and electronic security of modern communications systems is important. It’s also time-consuming, so agency and system managers need to provide the resources necessary for it to be done. Inspections, monitoring, and proactive measures are involved. Security is necessary for mission-critical systems. Physical security is the first bastion in protecting communications systems. All access control systems—from fences to lock keys to electronic access cards to active detection systems—require their own maintenance procedures. Interagency SOPs should be set up to prevent breaches due to a single weak link. Nobody wants to be the weakest link! Use inspections and active monitoring to secure the systems. Monitoring systems allow system managers to keep track of both physical access 222 Part II: How Is Interoperability Achieved? to communications facilities and logical access by, for example, remote computers for system configurations. Some components of voice radio systems, evermore computerized, can be reactively monitored by intrusion detection systems (IDS) and proactively secured by intrusion prevention systems (IPS). In effect, these systems watch for unusual activity and either provide notification and/or take action to mitigate impacts. Intrusion detection and prevention systems can be used with central parts of digital radio systems. Other proactive measures, such as encryption key management, are necessary to keep systems operating at expected levels of security. Key management is a serious and necessarily rigorous process for agencies using encrypted radio systems. We touch on it for both voice and data technologies, in the Part III – Exploring the Technologies. Prepare for System Changes As another companion to the original Law Enforcement Tech Guide, SEArCH has developed the Law Enforcement Tech Guide on Information Technology Security: How to Assess Risk and Establish Effective Policies funded by the COPS Office. (Publication pending, 2006.) Finally, as much as you don’t want to hear it, it’s never too early to start preparing for system changes. System expansions of scope and depth are inevitable, as is the unending march of technology into the sea of obsolescence. Even harder to prepare for are regulatory changes that force changes to systems. Evaluate Potential System Upgrades You prepared for system upgrades early in your project by documenting needs uncovered during early analysis and left unaddressed during implementation. Every project will have some share of nice-to-have features that went by the wayside as the project’s scope, timeline, and budget were fixed. The oversight board can effectively keep participants actively engaged with a living, evolving system by recognizing these needs and working with participants to meet them over time. Use working committees to actively investigate, analyze, and make recommendations on potential system upgrades. Anticipate that unimplemented features of the chosen technology may become useful over time as well. Vendors will have a natural interest in selling upgrades— initially minor and eventually major—that may address unmet needs. Use working committees actively to investigate upgrades, analyze their impacts, and make recommendations. For example, growing use of commercial wireless data networks subjects the agencies using them to rapid technology transitions—transitions that are uncommon with more slowly evolving public safety technologies. Managers of interagency communications systems that use commercial services have to continuously analyze their vendors’ technology lifecycles. Prepare for Regulatory Changes In closing, regulatory changes face most public safety radio users. Large agencies and consortia are effective in the Federal Communications Commission (FCC) regulatory process that governs the radio world, but it takes a significant commitment of time to stay on top of what, at times, seems to be a torrent of public notices, notices of public rulemaking, notices of inquiry, final reports, orders, and more. Chapter 14: Maintain the Technology 223 Rely on professional organizations to help manage the effects of regulatory change. Most agencies are more effective by working through their professional organizations, such as the International Association of Chiefs of Police (IACP), International Association of Fire Chiefs (IAFC), National Sheriffs’ Association (NSA), National EMS Management Association (NEMSMA), and the Association of Public-Safety Communications Officials – International (APCO). The most significant regulatory issues on the horizon are 800 MHz rebanding, release of 700 MHz spectrum, and narrowbanding of public safety frequencies below 512 MHz. These changes affect pretty much all public safety radio users. Rebanding Rebanding of 800 mHz is expected to cost $2.5 billion. Rebanding of 800 MHz is necessary to move public safety users in that band away from harmful interference they are receiving from commercial radio services. The move offers the opportunity to consolidate public safety spectrum, leading to improved management of systems and technological opportunities. The cost, estimated at $2.5 billion, is being borne by Nextel, whose facilities have interfered most with public safety operations. Rebanding will take place during a 3-year period and is expected to be complete by mid-2008. The United States is split geographically into four zones. Four “waves” of transitions are defined. Licensees in affected portions of the 800 MHz band that have to be relocated will be contacted by a “transition administrator” to plan and schedule the transition. New 00 MHz Spectrum A good deal of new spectrum in the 700 MHz band for public safety will be released in coming years as incumbent television broadcasters are relocated. It is already clear in some areas of the country without broadcasters on the affected UHF television channels (63, 64, 68, and 69). New wider channels capable of higher speed data are being made available in this band. Existing 800 MHz systems in need of additional channels may look to add incremental 700 MHz channels as rebanding proceeds and equipment capable of the spread proliferates. Narrowbanding Narrowbanding will affect the majority of public safety agencies in the country over the next 5 to 7 years. The majority of public safety agencies in the country operate in VHF-high and lower UHF bands. This spectrum, between 150 and 512 MHz, has been the subject of intense debate for years between federal regulatory and public safety agencies. In an effort to make more efficient use of the bands, allowing more channels, the FCC released an order in late 2004. The order sets a deadline of January 1, 2011, for the manufacture and importation of equipment capable of wider band (25 kHz) channels. Applications for wider band 224 Part II: How Is Interoperability Achieved? channels also will be accepted until that 2011 deadline. All public safety voice operations between 150 and 512 MHz are to be moved to narrowband (12.5 kHz) channels by January 1, 2013. REGULATORY RESOURCES The 800 MHz rebanding is addressed in detail on the FCC web site: http://wireless. fcc.gov/publicsafety/800MHz/bandreconfiguration/index2.html. The FCC has designated a “transition administrator” to manage the tremendous change and cost associated with relocating 800 MHz users within the band. The transition administration web site is: http://www.800ta.org/. The FCC’s web site on 700 MHz spectrum contains the most up-to-date information on efforts across the country to put this spectrum to use: http://wireless.fcc.gov/publicsafety/700MHz/. Efforts to “refarm” spectrum use below 512 MHz have been under way since 1992. The most recent regulations require reductions in the amount of spectral space used, referred to as “narrowbanding.” See the FCC web site: http://wireless.fcc.gov/services/plmrs/refarming/. Chapter 15 Measuring Interoperability What A process for subjectively assessing communications interoperability across five accepted dimensions. Why Plot your current position and heading, with midcourse corrections, to verify that you are on track to achieving interoperability. Who The governing body of the interagency initiative or project is in the best position to complete the assessment itself, or to direct a more thorough assessment across participating agencies. When Measure the state of interoperability early and repeat the assessment at least annually. Interoperability is a difficult quality to measure. Forgetting the fact that the term has come to be used in reference to everything from fire hose couplings to web-based software services, it’s an elusive capacity that only truly shows itself in practice, not as some sort of static state of being. It is a necessary capacity allowing public safety agencies to work together to achieve their respective missions in protecting the public. Interoperability isn’t a destination; it’s a waypoint. Interoperability isn’t a destination; it’s a waypoint. Your own agency’s destination may be different from the next, but all rely on an ability to communicate with others. The “ability” isn’t always necessarily used, so the mere capacity to communicate doesn’t tell us whether it’s put to beneficial use. Our measures of current position and course have to take into account not only the technical capacity, but also its practical application to prevent, deter, respond to, and recover from the effects of hazards of all types. The agencies involved in your communications interoperability efforts will have excellent reasons to frequently measure interoperability over time. This chapter offers a subjective assessment process to help those involved in your initiative to show progress on the route that has been charted. Communications interoperability is a complex, but important, issue to measure. It will become more complex over time. 228 Part II: How Is Interoperability Achieved? Why Measure Interoperability? You get what you measure. Any effort to improve the capabilities or performance of organizations needs to establish a baseline to assess progress and regularly reassess it to steer efforts toward the desired destination. Measures of communications interoperability have to be carefully chosen and defined to ensure that what is being assessed is what is desired. You get what you measure. Measures communicate. The process of measuring interoperability offers benefits. It helps to focus effort on the achievable, rather than simplistic ideals, by establishing understandable, observable objectives. It encourages joint ownership of both the objectives and progress in meeting them. It provides a tool for accountability. Most of all, it communicates in a language of objectives that, even if imperfect, can be common among stakeholders. Measures reflect objectives on course to achieving goals. The measures chosen must accurately and adequately reflect the desired goal, being both accepted as relevant and measurable. Recognize that measures, objectives, and goals are progressive. Achieving interoperability between public safety communications systems is only a step to achieving the greater goal of interoperations. Ultimately, the measure of interagency communications is its yeoman service, unobtrusively and effectively supporting public safety responders working across disciplines, jurisdictions, and levels of government to serve the public. Cautious Measures A strong conviction that something must be done is the parent of many bad measures. —Daniel Webster A point of note before proceeding: Interoperability has become an important rallying cry, but has come to mean widely different things to different people. To some, it is the willingness of agencies to work together. To others, it is merely having compatible technologies. To most, it is a term that has grown in importance in the past decade following national tragedies and responder cries for better communications. The basic measures of communications interoperability addressed in this chapter have been carefully crafted by the public safety response community. While basic, they are not simplistic, nor are they particularly simple to achieve. They are, however, the common elements that are broadly recognized as key to this elusive quality called interoperability. The Interoperability Assessment Scorecard Agencies identify the need for a basic, yet relevant, means of assessing their communications interoperability. Drawing on SAFECOM’s work in conducting a national interoperability baseline assessment, a simple process is offered here for marking the current state of your initiative and assessing its progress over time. Chapter 15: Measuring Interoperability 229 SAFECOM Interoperability Baseline Assessment In 2005, SAFECOM initiated a project to define an interoperability baseline assessment process. The multiphase process first sought to define how the level of interoperability in an agency or a region can be assessed. The goal was to provide the means to understand the current state of interoperability. A practitioner working group was established to collaborate with staff and contractors preparing the assessment.55 Previous studies of communications interoperability have been narrowly focused on the issue. The SAFECOM baseline assessment uses the five dimensions of interoperability introduced in the Interoperability Continuum to get more deeply at the root of key interagency communications factors (Figure 15-1). Through development of a straw man measurement tool and its refinement by four focus groups held across the United States, 13 measurable subelements of these dimensions were chosen for assessing interoperability. Governance, broken down into: Leadership Decision-making Groups Agreements Interoperability Funding Strategic Planning Standard Operating Procedures, broken down into Policy, Practices, and Procedures Command and Control Technology, broken down into: Approaches Technology Implementation Maintenance and Support Training and Exercises, broken down into: Operator Training Exercises Usage, broken down into: Frequency of Use and Familiarity Figure 15-1: SAFECOM Baseline Assessment Elements (2005) 55 As this Guide goes to print, the baseline assessment has just been released. The author is a member of the SAFECOM Advisory and the Baseline Working Groups. 230 Part II: How Is Interoperability Achieved? Descriptive measures of each subelement were developed for assessing whether an organization was in an early, moderate, or full stage of development for communications interoperability. Additional measures were developed to identify advanced stages of development as well. This measurement tool arising from the original Interoperability Continuum, consisting of the elements, their subelements, and the descriptive measures for each stage of development, was the basis for the baseline assessment matrix. Conduct a Self-Assessment Understanding that you may have picked up this Guide for a variety of reasons, a baseline is always useful. You may be preparing for a multiagency initiative to improve interoperability, in the midst of a project as we’ve discussed throughout this Guide, or even proceeding to sustain a long-term effort. A baseline—and the earlier, the better—establishes a multidimensional picture of where the agency, project, or initiative is at that point in time. Subsequent self-assessments can be used to determine if progress is being made across the continuum. Annual assessments as part of a continuous improvement program can help link progress with programs. The Interoperability Self-Assessment Scorecard The Interoperability Self-Assessment Scorecard in Appendix D is a simplified form of SAFECOM’s baseline assessment tool (an example of which is provided as Figure 15-2). It is useful with small and large groups alike, and can serve as an icebreaker with new groups or to apply SAFECOM’s assessment process formally to a particular initiative. It’s also easily replicable, meaning that it can be used over time to gauge progress. The SAFECOM baseline assessment presents one or more questions for each of the 13 subelements and asks respondents to indicate separately across disciplines, jurisdictions, and levels of government whether one of four statements— corresponding to early, moderate, full, or advanced stages of development—best describes their situation. The Scorecard uses the assessment tool’s questions and measures, but collects a singular assessment of each subelement across disciplines and jurisdictions in a matrix for presentation. It presents the four statements and asks for a subjective assessment of the current stage of development across cooperators or project participants using further prompts both from the assessment methodology and baseline measurement tool. Chapter 15: Measuring Interoperability 231 Image of Self-Assessment Scorecard Figure 15-2: Interoperability Self-Assessment Scorecard Example This assessment is necessarily subjective. While you may (and should!) strive to be objective in assessing your agency, jurisdiction, or region’s communications interoperability, it’s still based on personal observations and conclusions. Its primary importance is in establishing a baseline against which subsequent, equivalent assessments can be compared and in communicating objective elements of success in achieving communications interoperability. 232 Part II: How Is Interoperability Achieved? Using the Self-assessment Scorecard Even a subjective self-assessment can provide a tangible reference of where you currently are and guidance on where you are headed. Whether conducted as a structured poll or presented interactively to a group, keep in mind that this is a subjective survey of a limited audience, not a scientifically applied survey to a carefully selected sample. The results are useful for putting a stake in the stand and seeking consensus on needed areas of work. Step 1 Find a Suitable Venue Use the Scorecard as either a standalone survey distributed to your project committees, system oversight board, or any other group with a shared interest in communications interoperability. Or during a meeting, present the subelements interactively. Ask the group through a showing of hands or something more imaginative how their organization rates the current state of affairs. Step 2 Collect and Compile Responses Collect and compile the results in some graphic format to depict the distribution of responses for “analysis.” Another Scorecard, as shown in Figure 15-3, serves well to collect all the responses. Whether through a distributed survey or interactive poll, again remember that the results are simply a subjective assessment of a limited audience. In this hypothetical example, a 10-person Steering Committee of a communications interoperability project is asked to evaluate their organizations’ interoperability using the Scorecard. Responses are simply tabulated using check marks. On the Scorecard, the stage of development, early through advanced, is described specifically for each subelement using descriptions taken from the SAFECOM Interoperability Continuum measurement tool. Chapter 15: Measuring Interoperability 233 Image of Interoperability Self-Assessment Scorecard Figure 15-3: Interoperability Self-Assessment Scorecard Example Step 3 Analyze the Results There’s not much “analysis” to do, but watch out for a couple of potentially odd results. First, without getting into statistical theory, any survey or poll of more than just a few people is going to show a distribution of responses. If the audience is at all diverse (most likely so with interoperability initiatives!), there will be a response or two well outside the others. While there’s no wrong answer in this survey, it’s unlikely that a single agency is much more or less interoperable than its neighbors. For example in the Scorecard above, “Approaches” drew one response far from the median. For purposes of finding some consensus measure, it can be ignored. Second, a flat distribution of something as shown under “Command and Control” above indicates there were either multiple interpretations of the question, differences between represented disciplines, or other widely varying perceptions. In any case, it bears further investigation. The discrepancy may indicate a particularly thorny dimension of interoperability between the participants that needs to be addressed. 234 Part II: How Is Interoperability Achieved? Step 4 Present the Results Carefully present the Scorecard results. They can be misinterpreted or misconstrued if presented outside the context of the questions asked and measures used, so explain the results in terms of the stages of development. For example, the “Frequency of Use and Familiarity” results tabulated in Figure 15-3, examined in comparison to development definitions included with the Scorecard (Figure 15-4), are fairly clear. They could be reasonably understood to suggest respondents collectively concluded that the agencies use solutions during planned events and somewhat regularly during emergencies, but rarely for routine communications. Without the context of these definitions, the stages of development may be understood too broadly to be useful. Usage: Frequency of Use and Familiarity Early Development First responders seldom use solutions unless advanced planning is possible (e.g., special event) Moderate Development First responders use solutions regularly for emergency events, and in a limited fashion for day-to-day communications Full Development First responders use solutions regularly and easily for all day-to-day, task force, and mutual aid events Advanced Development Regular use of seamless solutions has expanded to include state, federal, and private responders Figure 15-4: Interoperability Self-Assessment Scorecard Development Definitions On the Horizon: Performance Measures Performance measurement, in simplest terms, is the comparison of actual levels of performance to preestablished target levels of performance. To be effective, performance must be linked to the organizational strategic plan. —The Performance- Based Management Handbook, U.S. Department of Energy Increasingly, effective management of public safety agencies requires the use of a performance measurement program rich in strategy and solid in application. Well implemented, such a program ensures, among other things, that projects undertaken are aligned with organizational goals and objectives, provide tangible improvements, manage factors associated with success and failure, are replicable, and through all demonstrate a fair return on investment. Ultimately, performance measures are the only legitimate means of evaluating organizational goals and objectives.56 56 As another companion to the original Tech Guide, SEARCH has developed the Law Enforcement Tech Guide for Creating Performance Measures that Work: A Guide for Executives and Managers funded by the COPS Office (publication pending, 2006). Chapter 15: Measuring Interoperability 235 While the Scorecard described above can be useful in sketching a baseline for your interoperability initiative and charting its progress, it is neither a fair nor adequate measure of performance. Unfortunately, the absence of performance goals and measures is a national challenge in achieving interoperability. (See “GAO Congressional Testimony” on page 236.) Measuring Effects, Not Capabilities In and of itself, interoperability is unlikely to be a strategic goal of agencies whose missions revolve around protecting public safety. Interagency communications is certainly a key resource in many operations, but it is just part of the interagency processes through which mutual services are delivered. The outcomes and impacts of those processes—not some technical capacity to communicate—are the appropriate subjects of performance indicators. Communications interoperability is more than the mere capability to communicate across agencies. In the most fundamental sense, it is the absence of communications impediments in interagency operations. Inasmuch as too much communications can actually interfere with operations at times, and intra-agency communications needs typically far outweigh those between agencies, interoperability is a low performance indicator for some processes. It’s not hard to imagine that high-performance indicators of some interagency operations may necessarily be very little (or highly controlled) interagency communications. Interoperability performance measures are inseparable from measures of mutual business processes. This is not to say that communications interoperability is unimportant. Hardly! Interoperability performance measures are inseparable from measures of mutual business process performance between agencies. Communications interoperability is the condition, ipso facto, that needed resources were available. What’s needed can only be determined through rigorous definition of business processes (the right things being done) and performance measures for those processes (things being done right). An Example An example may be useful. Radio gateways play an important role in linking separate networks. They are notorious, however, for causing problems when misused—a very real potential with many implementations. By linking two channels, they potentially double the amount of traffic on each, tripling it with three channels, and so on. If the mere presence of a gateway is factored as a measure of interoperability, the measure may neglect the more important factor of how the gateway is used; that is, whether in fact it actually improves or reduces communications capabilities and operational performance. The situation isn’t all dire, however. 236 Part II: How Is Interoperability Achieved? GAO CONGRESSIONAL TESTIMONY In 2003 Congressional testimony, the General Accounting Office (GAO—now Government Accountability Office) identified performance goals and technical standards as the second of three most pressing challenges in achieving interoperability, following definition of what interoperability is and preceding definition of intergovernmental roles. “When the interoperability problem has been sufficiently defined and bounded, the next challenge will be to develop national interoperability performance goals and technical standards that balance consistency with the need for flexibility in adapting them to state and regional needs and circumstances.” —U.S. General Accounting Office, Homeland Security: Challenges in Achieving Interoperable Communications for First Responders, GAO 04-231T (Washington, D.C.: Nov. 6, 2003). See http://www.gao.gov/new.items/d04231t.pdf Image of Front Cover Performance Measurement Improves Communications Given our topic, it’s ironic that a side benefit of a well-implemented performance measurement program is improved communications within organizations, as well as with external stakeholders. It improves communications by clearly relating performance objectives to service goals and explicitly stating indicators of success. A system of systems that improves interagency communications will actually flourish through agency performance management programs that include measures of interagency operations. It will do so because key business processes (and performance indicators) will have been defined, and thus more easily communicated. If this all sounds reminiscent of our discussion of needs analysis in Chapter 6, it should. The first step in analyzing needs for your project was defining interagency business processes and the final product was a business process baseline report. Not only does a thorough understanding of business processes provide the framework for technology projects, it’s also the heart of performance measurement. Chapter 15: Measuring Interoperability 237 Conclusion The bottom line is this: Performance measurement is based on business needs, not technological capabilities. It is impossible to measure the performance of technology independent of the performance of the business processes it supports. The most highly featured system cannot be shown to benefit an agency or multiple agencies that don’t actively manage their own business process performance. Communications interoperability projects will be subjected to required proofs of performance more and more in the coming years. The scope, cost, and intended impact of these projects is just too large to proceed on broad emotional appeals. The public, elected officials, and funding agencies all demand accountability. The choice for agency administrators and project managers will be to show the needed performance benefit of improved interagency communications and why technology is needed to accomplish it. Part III: Exploring the Technologies Any sufficiently advanced technology is indistinguishable from magic. — Arthur C. Clarke Chapter 16: Voice Communications Guideposts: Exploring the Technologies The final part of this Guide introduces basic technologies used for public safety communications, generally, and interagency communications, more specifically. In this chapter, we start with background on the basic technologies used for voice communications and then delve more deeply into their application for interoperability. We’ll cover the following topic: • Understanding the Technologies — Federal Communications Commission (FCC) Classification of Radio Systems — Analog and Digital Radio Technologies — Conventional and Trunked Radio Systems — Communications in Tunnels and Buildings — Satellite Communications — VoIP in Voice Systems. • Approaches to Interoperability — Technology Approach: Swap Radios — Technology Approach: Gateways — Technology Approach: Shared Channels — Technology Approach: Shared Systems. • Security — Advanced Radio Features for Physical Security — Encryption and Key Management. In Chapter 17, we address data communications, as it may be used for everything from simple text to live video. 244 Part III: Exploring the Technologies Have faith. Someone is thinking about the future. Take a look at the diagram in Figure 16-1, which is intended to show a range of user devices, all interacting through several applications, across various technologies. If it looks terribly confusing, take heart. Your responsibilities probably take your time and available attentions elsewhere on a daily basis. Your responsibility to manage an agency, a division, or this particular interoperability project probably leaves little time to delve this deeply into technology. Image of Diagram of Interoperability Needs Figure 16-1: Future Interoperability Needs Between Wireless Devices Source: Public Safety Wireless Network, “Embedded Communications Broker (ECB) Technology,” October 2001 Any radio or mobile data system will only perform as well as it is funded and engineered. —Steve Proctor, Executive Director, Utah Communications Agency network Have faith that there are technologists who understand where we are today and what technologies are likely to enable your operations tomorrow. Your own job more likely entails understanding the public safety business, getting and using funding effectively to improve operations, and figuring out how you’re going to work with partners in response. Chapter 16: Voice Communications 245 Understanding the Technologies Tips Icon SAFECOM Library The SAFECOm online library is a prime source for technical information about voice communications systems. It includes documents from multiple sources, including the past Public Safety Wireless network (PSWn) Program. See http://www. safecomprogram. gov/SAFECOM/ library/technology/. Public safety communications technology parallels consumer and other commercial technologies. As more digital communications are used, voice becomes more indistinguishable as the “payload” over much of the networks connecting senders and receivers of information. It has unique features that shape how it’s moved from the analog world of sound, handled over digital transmission systems, and then converted back to sound. However, in most ways it can be transported and stored in digital form just like more traditional data. While voice and data communications for public safety services have long been conducted over both wired and wireless links, we focus here mostly on the latter. It’s there that the greatest communications interoperability challenges have occurred for first responders. Recognize that advanced radio systems increasingly include many wired components at their cores, just as voice and data are increasingly intertwined in emergency response communications. FCC Classification of Radio Systems Before we look at the primary voice radio technologies, let’s pause to clarify some terminology and look at FCC classifications of radio systems. The FCC uses specific terms to distinguish radio technologies and their uses. The term type is used to distinguish different fundamental technologies, while services distinguish between different applications of the technology. The FCC distinguishes radio types and services. The term type acceptance is commonly used in the radio world. It refers to the FCC’s formal process of evaluating and approving technologies. Individual manufacturer radio models must receive FCC-type acceptance before they can be made commercially available. It’s not uncommon to hear manufacturer representatives speak of new models and note they are awaiting type acceptance before they will be mass-manufactured and sold. Several radio services are used by public safety agencies, including: • Broadcast • Commercial • Specialized mobile • Aeronautic • Maritime • Amateur. • Unlicensed • Land mobile Traditional dispatch, car-to-car, and field communications used by public safety is land mobile radio (LMR). This term is commonly used by industry and in regulations in reference to terrestrial radio services to support mobile users. Portable and car radios are both classified as “mobile” at this level of discussion. 246 Part III: Exploring the Technologies The FCC classifies most public safety radio systems as private radio. While several of the radio services listed above are probably recognizable to readers, others may be confusing. Most public safety radio networks are regulated by the FCC as private radio systems. Where common carrier systems are made commercially available for general public use, those built and operated for private use are considered private systems. In this case, “private” refers to how they’re used, rather than owned. More than 300 agencies in South Carolina use the Palmetto 800 System, an 800 mHz system shared with power utility companies. For further information, see: http://www.cio. sc.gov/cioContent. asp?pageID=756& menuID=411. Many commercial industries have their own private radio systems. A few are actually shared with public safety agencies, but the vast majority of police, fire, and EMS voice radio communications takes place over systems owned and operated by the agencies themselves. Most of these systems require FCC licensing. Unlicensed radio technologies, such as those that might be used for wireless local area networks (WLAN), are regulated separately. Whether licensed or unlicensed, private or common carrier, radio technologies are broadly subject to FCC regulations. Rely on your radio technicians, vendor representatives, frequency coordinators, and professional associations to help you sort out details if you intend to be heavily involved in radio technology. Analog and Digital Radio Technologies For the first century of radio, analog radio technologies predominated. Those technologies include amplitude modulated (AM) and frequency modulated (FM) radios that we’re all familiar with from broadcast radio services. Others exist, but all analog technologies are based on use of audio tones (frequencies) being superimposed on radio frequencies (RF) in a standardized manner. Audio frequencies, such as those delivered electronically by radio microphones, are mixed with RF within analog radio circuitry, further amplified, and then transmitted. At distant receivers, the audio is extracted electronically in more or less the reverse manner. Data can be transmitted much like voice over analog systems by encoding bits using different audio tones and other techniques of shaping the transmitted RF signal. Channel Bandwidth FM is by far the most common analog radio mode today. It is also the compatibility or legacy mode for digital radios. However, transmitters and receivers not only have to use common means of putting information on the RF signal (i.e., modulating it), they also have to use compatible channel widths and operate in the same frequency band, such as VHF, UHF, or 800 MHz. Chapter 16: Voice Communications 247 Public safety frequency bands for voice communications are typically described in megahertz, while channel bandwidths are described in kilohertz. Frequency bands for common public safety voice purposes are typically described in millions of radio wave cycles per second, or megahertz (MHz) (Figure 16-2). They are occupied by channels of a certain bandwidth. That is, they take up a specific amount of the frequency band. Channel bandwidths are described in thousands of cycles per second (kilohertz is abbreviated as kHz). A channel is a slice of some part of the radio frequency spectrum. That is, we talk about a traditional 25 kHz voice channel in the 450 MHz public safety frequency band. A traditional voice channel in that band has been allotted 25 kHz of RF spectrum. Image of UHF Frequency Band Figure 16-2: Public Safety UHF Frequency Band, 450-470 MHz Narrowband Channels Narrowbanding, as discussed in Chapter 14 (Page 223), is an FCC regulatory effort that will affect all analog radio users. Its goal is to reduce the amount of RF spectrum occupied by a single channel to increase the number of channels that can fit in a given band. This is not the first time the FCC has split channels for this purpose and we can expect it to happen again. The FM radio channel has existed for decades as nominally 25 kHz in width. We say “nominally” because channel width is more an absolute under regulations than under the laws of physics. It actually varies in width according to transmitter adjustments and characteristics of the audio being carried. In addition, the transmitted power isn’t all contained within the defined channel; a progressively smaller fraction exists farther and farther away from the channel center. The FCC requires that public safety operations move to 12.5 kHz channels or the equivalent by January 1, 2013. FCC rules will have all public safety voice operations between 150 and 512 MHz moved to narrowband (12.5 kHz) channels by January 1, 2013. Technically, the requirement is that a channel can occupy no more than 12.5 kHz or the effective 248 Part III: Exploring the Technologies equivalent. This last clause can be a bit confusing. There are proprietary techniques to interweave two separate conversations, both using the whole 25 kHz, but splitting use of the channel second by second. Most commonly, the narrowband channel will be used wholly for a single communications path. One net effect of this transition is that narrowband analog transmitters will have less spectral space to put RF energy, thus reducing the power and range of an analog channel relative to the wider band channel. Just how much is the subject of debate, but recognize that the range of a narrowband transmitter will be less than that of its wider band cousin. While digital uses of these radio bands are similarly affected, existing digital technologies already use 12.5 kHz channels or allow multiple voice conversations to occur within a traditional 25 kHz channel. Narrowbanding is thus leading to wider adoption of digital techniques. Digital Radio \A vocoder converts analog sound to digital bits. Digital radios use many of the same components as their analog relatives. For voice radio purposes, microphone audio frequencies are first converted into bits by the voice encoder or vocoder. This is a particularly important part of the digital radio system; not all vocoders are created equally. For public safety purposes, great work has gone into testing and choosing vocoders that efficiently produce a digital stream to make most use of the radio channel, while still faithfully representing it. The P25 vocoder standard carefully balances efficiency, robustness, and fidelity. The process of creating digitized audio, transmitting it over the largely inhospitable airwaves, and decoding it on receivers is fraught with danger for the lowly voice bit. Project 25,57 which produced the national standard for public safety digital voice radio systems, took on the challenge. It undertook a significant effort to find a vocoder sufficiently efficient, yet producing resiliently encoded audio for the most critical missions, in some of the most difficult radio environments. The Project 25 vocoder standard was selected as a careful balance of efficiency, robustness, and fidelity. Digital radio standards for public safety don’t stop at speech encoding, however. As a matter of fact, the vocoder is just a small part of the technology that takes audio, 57 Initiated by the Association of Public-Safety Communications Officials – International (APCO), in cooperation with the National Association of State Telecommunications Directors (NASTD) and with support of other public safety organizations like the International Association of Chiefs of Police (IACP). Project 25 received its name following APCO’s tradition of numbering its broad initiatives to affect the public safety communications world. P25, as it is also commonly known, is the association’s best-known project. The specifications have been codified by standards development organizations. For further information, see http://www.project25.org. Chapter 16: Voice Communications 249 encodes it, packages it up, inserts it aboard the radio channel train, and assures it can be unpackaged successfully on the other end. Radio transmissions are weakened over distance and by the environment. Another key piece of the Project 25 standard is its Common Air Interface (CAI). Without going into depth, the CAI provides the standardized means for receiving radios to recognize what is coming over the airwaves and extract an intelligible signal. Any digital receiver has to know how to decode the audio bit stream once received and passed to internal microprocessors, and then convert it back to audio frequencies that can be heard through speakers. That’s not all, though. Receiving radios also have to know when and where a package of bits begins and ends, how to deal with inevitably missing or erroneous bits, how to recognize other embedded codes, and more. Project 25’s CAI is the standard for how that’s done with public safety digital voice radios. The P25 Common Air Interface is the public safety standard for digital, rF transmissions. Standards are absolutely essential for interoperability of radio systems. The Radio Environment – Analog Once transmitted, radio waves are subjected to the same environmental effects regardless of their payload. The laws of physics aren’t particularly concerned with whether they’re bearing analog or digitally encoded information. It’s a hostile environment. Received radio signals may be millions and millions of times weaker than they were at their source. Not only do signals diminish geometrically as a function of distance, they also are weakened or attenuated by the environment over and through which they pass. Manmade and natural obstructions both tend to absorb radio waves. Similarly, each time a radio wave is reflected or diffracted (which is often!), it scatters and loses a bit more energy. Add to this the additional challenges imposed by relatively rapidly moving transmitters and receivers and it’s nothing short of fundamental magic that any intelligence can be extracted from distant transmissions! Anyone who has listened to an FM broadcast recognizes the sound of a station fading in and out. If you’ve listened carefully in areas where FM broadcast stations overlap on the same frequency, you’ve also heard the effects of two roughly equal signals competing in your receiver. “Roughly” in the radio world is measured in factors of tens and hundreds. A signal that is 100 times or stronger than competing signals will generally be the only one heard on a channel. In the radio environment, signals can vary by a factor of a hundred within the distance of a few feet. Overlapping radio signals cause interference in receivers. FM has something called the capture effect whereby once a receiver is locked on to a given signal, it rejects a competing one up to a point. As the new signal becomes increasingly stronger, the receiver finally gives up on the first and locks onto the 250 Part III: Exploring the Technologies second. In between, distorted and mixed audio is heard. Portable and mobile radio users of two-way FM channels quickly learn to recognize the signs of one user “walking on” another through overlapping transmissions. The Radio Environment – Digital Digital radio technologies designed for public safety use error correction techniques to recover intelligible audio from signals that are battered about by the environment and other radio users. Forward error correction (FEC) techniques are used to allow a receiver to recreate a damaged signal from, in effect, redundant parts of the digital stream. Additional signal information takes up part of the digital channel for FEC purposes. The term bit error rate (BER) is used to describe the percentage of received bits in a digital stream that are “broken.” While public safety radio technologies can recover nearly Audio quality original audio with bit error rates in the vicinity of 2 percent, recovered audio starts to degrade as error rates increase.58 See Figure 16-3, Anyone who has used a cellular telephone in recent years has noticed the effect of weak digital signals on caller voice intelligibility. At some point the BER becomes too high for digital signal processors to recover accurate audio from the digital stream, leading the receiver to shut off digital-to-audio conversion rather than pushing noise to its speaker. Image of Signal Strength Curves Figure 16-3: Recovered Audio Quality by Signal Type While the human ear and brain has a remarkable ability to recover intelligent audio in the presence of relatively high noise levels, digital radio receivers are more limited. At some point they have to stop trying lest they start making up sounds that weren’t originally there. By comparison, intelligible audio can be discerned by the human ear 58 Vanderau, John M., Delivered Audio Quality Measurements on Project 25 Land Mobile Radios, NTIA Report 99-358 (Washington, D.C.: U.S. Department of Commerce, Institute for Telecommunications Science, 1998). A BER of 2 percent corresponds to a Delivered Audio Quality (DAQ ) measure of 3.4. See http://www.its.bldrdoc.gov/pub/ntia-rpt/99-358/. Chapter 16: Voice Communications 251 through an FM or other analog receiver at a lower signal level than a digital receiver can use. On the other hand, a digital receiver can recreate the identical audio signal that was sent, while the received analog signal gains increasing background noise as it gets weaker. Let’s move on to the different types of systems that put analog and digital radio technologies to work. Conventional and Trunked Radio Systems There are two broad categories of radio systems used for voice communications today: Conventional and trunked. In order to understand the difference, it’s useful to first understand a few basic system principles and common building blocks. Building Blocks – Simplex Communications Land mobile radio systems are commonly designed to allow one party in a conversation to talk while others listen. By contrast, telephone systems throughout the years have been designed so both parties may speak simultaneously. Voice radio protocols in public safety have evolved around the fact that only one speaker has access to a channel at a time. The common term for this form of communications is simplex. In radio usage, the term carries further meaning. Simplex radio channels carry conversations conducted on a single frequency where participant radios transmit (Tx) and receive (Rx) on the same frequency. In Figure 16-4, “Frequency 1” (F1) is used for all transmissions. The radio depicted at the tower is referred to as a fixed-base station, whether it is closely or remotely attached to agency facilities. The base station could be placed on a mountaintop far from dispatch facilities, for example, and controlled remotely. Image of Radio Tower broadcasting to walkie-talkies. Figure 16-4: Simplex Radio Example 252 Part III: Exploring the Technologies This approach to radio communications works well and is the simplest, most resilient form of coverage when all radio users are within range of one another. It becomes problematic, though, when radio end users move out of range of each other. In all two-way voice systems, from the simplest to most complex, radio coverage is, well, a two-way street. It’s relatively easy to increase the transmission range of a base station by increasing its power, but that doesn’t help users of mobile and portable radios, which are comparatively weaker, talk back to the base. Radio engineers work to balance the “talk-in” and “talk-out” of systems. Building Blocks – Duplex and Half-duplex Communications When transmissions need to be relayed to include all users on a channel, a different class of radio station is used that can simultaneously receive a transmission from one user and retransmit it to all others. This capability is referred to as duplex communications. User radios typically can transmit or receive, but not do both simultaneously. As a whole, such systems of users and fixed stations are considered to be half-duplex because end users are transmitting or receiving, while stations relaying communications in the middle are doing both, simultaneously. Telephones provide duplex communications. Few radio systems are designed to do so. True duplex communications, as commonly experienced with telephones, allow the most natural forms of conversation. Since land mobile radio has evolved for one-to- many conversations in which at any moment there is one speaker and many more listeners, full duplex systems are unusual. As anyone who has ever been part of a telephone conference call can attest, having simultaneous “transmission” capabilities across all participants can actually impede communications at times. Building Blocks – Repeaters Half-duplex relays are fundamental building blocks of public safety radio systems. “Mobile relay” is the official term for this class of station, but they’re widely known as “repeaters.” Repeaters as described have been used by public safety agencies for decades to automatically relay transmissions for system users who would otherwise be restricted in range by direct, simplex systems. A repeater retransmits on one frequency what it receives on another, well separated from one another to reduce interference. Repeaters are typically placed permanently with a well-situated antenna high up on a tower, building, or hilltop. From this vantage point, a repeater receives transmissions on one frequency and retransmits them on another. This serves to extend the effective range of a lesser powered radio, such as a portable, allowing other users of the channel to hear and talk with others at greater distances. Other fixed radio stations— at dispatch, for example—can also transmit through the repeater. These are known as control stations. Chapter 16: Voice Communications 253 The repeater’s frequencies have to be separated sufficiently from a spectrum point of view to keep the transmitter from overpowering the receiver. If not, the repeater’s transmitter effectively prevents its receiver from “hearing” the relatively much weaker, distant signals. Some of the magic of radio engineering is dedicated to avoidance of these and more complex interference effects. Sophisticated antenna systems are used to isolate a repeater’s transmissions from its receiver so it doesn’t become the radio equivalent of an alligator: All mouth and no ears. Figure 16-5 shows how frequencies are split between the repeater and its users. Note that the repeater’s frequency pairing is the reverse of the other radios. Field users, including those at the station, transmit on Frequency 1 (F1) but receive on Frequency 2 (F2)—the repeater’s transmission frequency. The repeater does the reverse. Image of a tower transmitting to a walkie-talkie and a station house Figure 16-5: Half-duplex (Repeater) Radio Example Building Blocks – Mobile and Portable Radios Public safety agencies use mobile and portable radios to connect field operations with dispatch and other fixed stations, as well as among field users. Though lumped together by the FCC as “mobile” devices, vehicular and portable radios are considered by industry and the public safety community, itself, somewhat differently. As might be imagined, portable radios are relatively handicapped compared to vehicular radios on two-way LMR networks due to limited transmission power and compromised antennas. They operate with much less transmit power than vehicular radios—about 5 to 10 percent of the latter’s output power. Their antennas provide needed portability, often in exchange for efficiency, and are typically situated at 254 Part III: Exploring the Technologies something of an electromagnetic disadvantage compared to those on vehicle roofs. The human body, itself, tends to block radio waves that would otherwise be received or transmitted by the portable. To this, add the fact that portables can be and are often carried into locations far less friendly to radio emissions than the streets where vehicular radios operate. Radio system design is hugely affected by whether primary coverage is sought for portable or mobile radio use. Two-way radio networks, voice and data alike, are built to take into account differences between fixed and mobile devices on the network. System Building Blocks – Simulcast and Receiver Voting Systems Coverage needs lead to use of simulcast systems where multiple sites transmit the same signal simultaneously to cover an area. The technologies discussed so far have been in use for decades. In these conventional radio systems, there is a one-to-one correspondence between each frequency (or pair of frequencies in duplex or half-duplex operations) and a channel. In effect, channels are simply defined by who has and uses the designated frequencies within a given area of operation. Large-scale, wide area systems have been built for years with conventional technologies. Public safety agencies have put up multiple repeaters to provide needed channel capacity for simultaneous operations and to cover wider areas. Capacity and coverage demands call for multiple repeaters at a single site in some cases and multiple sites in others. It’s not uncommon to use multiple sites to provide coverage that can’t be had from a single site. With such systems, users are relied upon to use the appropriate channel (i.e., frequency) depending on their job and location. It’s possible with conventional systems to simultaneously transmit the same signal from multiple locations. This is referred to as simulcasting. It requires careful synchronization of the individual transmitters and a healthy backbone of microwave or some other form of dedicated telecommunications circuit to deliver the outbound signal to all sites simultaneously. In the example shown in Figure 16-6, audio to be transmitted from all sites simultaneously originates from the central facility—a dispatch center, for example. While simulcasting reduces the need for users to manually “steer” their radios by the channel selector knob as they move around a geographic area, it adds system complexity and a reliance on the circuits connecting to remotely operated base stations. It also brings a need for the system to deal with the common situation of two or more sites receiving a transmission from a field user. Just as a field user’s radio will likely receive a transmission simultaneously from multiple sites, it will also likely be heard by multiple ones when it’s transmitting. Chapter 16: Voice Communications 255 Image of Radio tower, transmitting to walkie-talkies, transmitting to other towers, with a connection to a main station house. Figure 16-6: Simulcast Simplex Radio Example Additional electronics are added to the heart of the system to select the best signal received by the sites. In the example shown in Figure 16-6, two sites might receive decent signals from a user, while the third site receives a weak signal. Central electronics pick out the best signal and pass it to users at the fixed facility. This is known as a simulcast system with receiver voting. For practical purposes, the system can be thought of as a single base station with the wide, composite coverage provided by all the separate sites. The effect is a single channel that covers a wide expanse. While useful in low-traffic, routine operations, such wide-area, blanket coverage can be a problem during periods of high demand when the load across all sites can overwhelm a single channel. The final conventional radio example to be presented here combines multiple technologies and adds a new one: Remote receivers. Actually, remote receivers have been depicted in the previous examples, too, but have been paired with their associated transmitters. Figure 16-7 depicts a repeater system with additional remote receivers. Sites labeled “Rx Only” are simply receivers that send back received signals to the central site where a voter can pick out the best received signal. Remote receivers are often used to 256 Part III: Exploring the Technologies accommodate portable radios that can “hear” the more powerful and well-situated fixed transmitter sites, but are unable to “talk” back to them due to the distance or terrain. Image of radio system with three repeating towers and two receiving towers. Figure 16-7: Simulcast Repeaters with Remote Receivers Remote receivers allow weaker signals to get into the system. In this example, some possible receive and transmit paths have been omitted for the sake of clarity. It depicts a circumstance where Repeater A can be heard by User 1, but that user can only be heard by Repeater B. Repeater B can be heard by both users, but User 2 can only be heard by Repeater C and one of the remote receivers. The combinations and permutations of which transmitter can be heard by which receiver—both fixed and mobile—are nearly endless in a large system. Imagine how complex this can become with dozens of fixed sites with multiple channels. It should be no wonder that radio engineers are needed to design and carefully tune all the components that make such an electromagnetic marvel operate! System Building Blocks – Trunking The next major technology used for public safety operations is trunking. Simply put, trunking is the means to share a limited number of frequencies between users, with each set of users having its own virtually private channels. Chapter 16: Voice Communications 257 Trunking is widely used in telecommunications systems. Users of the public switched telephone network serving businesses, residences, and emergency response agencies worldwide are well experienced at using a trunked system—even if they are unaware of it. Complex technology assigns circuits (channels) dynamically upon requests for access, such as occurs when a telephone number is dialed. The newly assigned circuit may have just been used for an entirely different telephone call between different locations, but now is being reassigned. The primary value of trunking is channel efficiency. Radio systems can be constructed to operate the same way. The primary value of trunking is channel efficiency. That is, rather than having sets of users occupy a channel fixed by frequency, leaving the channel empty at times and overloaded at others, the trunked system takes multiple channels and assigns them to sets of users as needed. This also enables groups of users that could never have a separate conventional channel to have a trunked one for private use. Trunking provides multiple virtual channels for separate conversations. With a conventional system, three repeaters at a single site might have served police, fire, and EMS, individually, with all users from one of the disciplines operating on a single channel. With these three repeaters trunked, a nearly limitless number of virtual channels can be assigned and used without interference between users. However, the number of simultaneous conversations is still limited to the total number of talk repeaters at the site. This brings up an important point: Most public safety trunking systems reserve one repeater at each site for the system or control channel. This is the channel o