Last July in this column, we wrote that communications, interoperability, and—in the end—public safety operations are not improved by the same old design and implementation processes used since the days of Morse, Marconi, and de Forest. The reasons include increasing technological complexity, shortened system lifecycles, and greater expectations of both performance and availability. Interest in the topic leads us into further discussion and interesting happenings in Canada. 2006 National Interoperability Summit
In 2005 and 2006, the U.S. Departments of Justice and Homeland Security sponsored the National Interoperability Summits, which brought together leading experts from around the United States to focus on the subject of communications interoperability for public safety. SEARCH had the honor of hosting the 2006 Summit held in Austin, TX.
More than 135 people gathered to attack this persistent problem. The two days they spent together were largely in focus group sessions on successes and failures in managing communications interoperability projects.
The project lifecycle was broken into five areas:
• establishing governance structures and agreements;
• analyzing and documenting operational needs;
• project planning and management;
• procurement, contracting, and vendor management;
• and implementation, operations, and performance measurement.
Participants were divided into groups, asked to create problem statements, identify lessons learned and best practices, and determine what resources are needed in addressing these issues during projects. The groups were subsequently shuffled and new participants asked to consider what the first had come up with. Each topical area was then presented in a plenary session of all participants for further peer evaluation.
Because the technological pinnacle of interoperability is shared systems, discussion of interagency communications and multi-agency systems was thoroughly intertwined. The results were eye-opening.
Analyzing and Documenting Operational Needs
The session on analyzing and documenting operational needs provided great insight into how the very real needs for communications are best met.
When asked to state what the problems are in managing this aspect of projects, they came up with the following answers.
1. Communications is a function of operations—not the other way around, which leads to problems with understanding, prioritizing, and communicating needs.
2. Technical solutions are often sold to agencies before needs are defined. Vendors distort them.
3. The goal of interoperability is ill-defined and situationally determined, making needs analysis difficult. Varying needs across jurisdictions and disciplines require compromise on needs.
4. Interoperability needs have been defined in technical terms, not operational ones.
The most succinct quote from one of the participants may have been:
“Communication is a tool that we use to exercise command and control over an event. What we have to do first is decide what elements of command and control we need to address when we bring different agencies together. How do they work together, who’s in charge, who needs to talk to one another, and how does information flow up and down?”
When asked to summarize lessons learned with their own projects, the participants—who represented agencies large and small—responded directly to the point.
Lesson learned in analyzing and documenting operational needs:
• Use operational commanders to identify operational needs.
• Agency command staff members often don’t understand end-user requirements.
• A “marketing” plan sets a strategy for needs and documents priorities.
• We can be blinded by the past through tunnel vision or see current needs through past solutions.
• How we do it on the little ones determines how we perform on the big ones.
Best practices recommended by the focus group in addressing those lessons:
• Use ICS incident action planning and management principles in needs statements.
Use end-user scenario statements to describe operational needs.
• Use a “marketing” plan to obtain funding.
• Consider alternatives—and alternative means of presenting needs. • Train, exercise, and perform on a daily basis as we would on the big one. Finally, the group recommended tools and resources for interagency communications projects based on their own experiences.
• Provide funding that can be used for front-end and continuing needs analysis.
• Fund projects based upon a showing of documented operational needs.
• Create a portal with tools for understanding and documenting needs—online, Web-based, Turbo Tax® approach. Make a portal that shows how other agencies have met needs, helping others to further understand their own needs.
• Don’t let vendors define your operational needs—Do it yourself! (DIY)
Using the Findings
At SEARCH, we have the opportunity to work with public safety agencies around the country, literally from Guam to Puerto Rico, in just the past couple of years alone. Findings from the 2006 National Interoperability Summit have provided a rich source of advice from individuals directed to their peers in other agencies. Through conferences, workshops, publications, and direct assistance in individual projects, we have shared advice from all the focus groups, including this on operational needs.
We find that real end users often wake up during these presentations and conversations, having been previously too often subjected to endless techno-babble parading as the solution to their problems. When they hear that true measures of success in communications systems are their operational benefits, users regain a voice in stating what the real outcomes of needs analysis and requirements statements are all about.
In our work, we recommend that the alpha and the omega of system design are user requirements. We emphasize that while the technological environment in which solutions evolve shape such details as frequency bands and modulation techniques, users don’t need 700 MHz or digital radios. Those are just means to more important ends that must be kept in sight, defined upfront, and assessed in the end.
This approach to systems design and implementation is nothing new, at least in the broader world of information technology. In “Con-textual Design, Defining Customer-Centered Systems,” Hugh Beyer and Karen Holtzblatt describe in detail the practical process of seeing into the work of end users. It is beyond the scope of a column such as this to explain the methodology fully, but a few details may demonstrate trends in modern systems analysis that are finding their way into the world of public safety communications.
“Contextual Design” opens with an aptly titled section candidly describing “the rocky partnership between IT and its clients.” The authors stress the need for individuals serving in the role of information technology systems analysts, whether so named or not, to master the art of communicating with end users of systems—particularly the listening aspect of communicating. By extension and perhaps not so ironically, the design and implementation of communications systems depends heavily on the quality of face-to-face communications between analysts and end users.
In what would now be considered classic IT design methodology, a systems analyst with a significant understanding of the business being automated employs that knowledge to extract details of how end users actually work and what the real end products or services are. A skilled systems analyst is not necessarily adept at the users’ work or even necessarily knowledgeable of potential enabling technologies, but is particularly capable of drilling into work process and products. A good systems analyst is insightful at a level that the average user or business manager rarely even thinks about. The best not only get the whole picture but see where changes in processes, technology, and even organizational structure most effectively achieve the desired results.
Common Language in System Design
Within the practice of contextual design, one early challenge is coming up with a common language to discuss the work being done. As we in the public safety world talk about needs for “plain language” or the importance of “common terminology” as stressed by the National Incident Management System (NIMS), contextual design stresses the need for a vocabulary that is meaningful to the end user, yet suitably exacting to convey ideas consistently and persistently over a design process.
The importance of a common language between system designers and system users in radio systems is evident. For example, the term “coverage” is one that bedevils radio projects from beginning to end. Users understandably judge the value of a radio system by its coverage. Yet, “coverage” is a very complex system measure. Engin-eers talk about time and location variability of a signal. Coverage for the user of a portable radio worn at the hip in a car is different than that for one operating it at mouth-level on the street curb. Further, few users want to understand much of the difference between coverage and capacity, intermingling terms that are distinct in engineering.
This common language may only be established for a single project, but it is the starting point in contextual design for describing work. As with NIMS common terminology, it would have standard terms for resources, facilities, and organizational structures. A “division” in an emergency response managed under the NIMS Incident Command System (ICS), for example, is a geographically based subdivision of operations. Such a geographically deployment of re-sources has a different implication of radio communications needs than, say, an ICS “group,” which is an equivalent subdivision, but by function rather than geography. A system designer without a suitably common language would most certainly miss important distinctions in a user description of how resources are deployed during an incident.
Contextual design uses work models to depict what might otherwise be inadequately described with mere words, alone. Beyer and Holtzblatt talk about the “five faces of work.” Five work models correspond to seeing into those “faces.” I have written briefly elsewhere about the first two of these in describing business processes for interagency communications systems. The publication is called “Communications Interoperability: A Guide for Interagency Communications Projects,” and it was published by the Washington, D.C. U.S. Department of Justice Office of Community Oriented Policing Services in 2006.
• Flow Model—Shows information flow between people, organizations or functions. In an emergency response managed under ICS, the flow of information between dispatch, a staging area manager, the Operations Section chief, and the Communications Unit is important and unique, for example.
• Sequence Model—Shows task sequences of processes and activities. Expanding on the above example, the sequence of tasks in ordering operational resources early in the incident differs from ordering logistical resources further along.
• Artifact Model—Captures things used in work. Again following the example, ICS is famous for nothing if not its forms. The ICS Incident Briefing Form (ICS 201), Incident Radio Communications Plan (ICS 205), and Incident Action Plan capture aspects of communications needs and application.
• Cultural Model—Captures policies, values, expectations, and similarly less tangible aspects of work. Incidents managed under ICS in many jurisdictions still retain remnants of routine chains of command, though a different one is temporarily and situationally in place according to ICS principles.
• Physical Model—Depicts the physical environment in which work takes place. Concluding with the ICS example, the physical relationships between a dispatch center, incident command post, incident communication center, and staging areas have implications for communications system design.
In contextual design, all of these models may ultimately be necessary to clearly see the work being done that the system will support.
As mentioned, participants at the 2006 National Interoperability Summit recommended using ICS incident action planning and management principles in needs statements and end-user scenarios to make operational needs more concrete. These recommendations mesh well with the process of contextual design, which focuses the systems analyst or designer so much on understanding how work gets done. Both clearly put, real operational outcomes as the true needs.
Interesting Happenings in Canada
Thoughts about analyzing and documenting operational needs, the 2006 Summit and contextual design came to mind recently in learning about the Alberta First Responders Radio Communi-cations System, a province-wide system in development under the sponsorship of Alberta’s solicitor general and in cooperation with Service Alberta, a provincial agency responsible for many services to citizens, business, and other governmental entities.
The Alberta project is a story in itself with firm foundations and an interesting business model, but most intriguing was the process being used to determine user needs. As might be recognized in any solid project, a charter, user working group, and discussion papers have been used to progressively detail needs. Before going into a planned procurement this spring, however, the project is establishing service level agreements (SLAs) with users.
User SLAs are essentially unheard of in shared radio systems. Surely, agreements exist between shared system partners that document in more and less detail the commitments that each makes to the others, but an SLA is a different animal. It is not between partners, but between a service provider and a service recipient. That is, an agreement between a provider and a customer. It commits to providing service at a mutually agreed upon level, typically in exchange for some other consideration. In a commercial arrangement, that consideration would be money. In an arrangement between public sector entities, it might be money or it might be something intangible like a commitment to be part of a shared system.
In the commercial telecommunications and information services world, service level agreements are heavily used. They are used to establish contractual arrangements between a provider and its consumer, typically one with definite service quality needs. In the realm of wireless communications systems, those needs may be coverage, capacity, and availability.
The fact that Alberta seeks to establish SLAs with system users before contracting for design and construction of its system shows an intent and abiding interest in meeting real operational needs. One might hope that the service levels established will be stated more in operational terms, the accomplishment of which is recognizable to most users, as opposed to technical terms that would only bring assessment of success back to arbitration between engineers.
And Finally in Canadian News…
Canadian national interoperability efforts are moving ahead with great energy. In the past year, Inspector Lance Valcour of the Ottawa Police Service has been a regular participant in many, if not most, communications interoperability events in the United States. Valcour has taken on national responsibilities for this issue through a body known as the Canadian Interoperability Technol-ogy Interest Group (CITIG), a subdivision of the Canadian Police Research Center.
CITIG has announced its first ever Canadian Voice Interoperabil-ity Workshop that was held in March at the Fairmont Chateau Laurier Hotel in Ottawa, Ontario. The workshop involved officials and experts in the field from North America and Australia. A central theme was planning strategy for cross-border communications interoperability. Further information can be found online at www.cacp.ca/english/conferences/.
Dan Hawkins is the director of Public Safety Programs for SEARCH, The National Consortium for Justice Information and Statistics. He is author of “Communications Interoperability: A Guide for Interagency Communications Projects,” published by the USDOJ Office of Community Oriented Policing Services (COPS) and jointly sponsored by the DHS SAFECOM program.