Information Technologies Supporting Emergency Management Controllers in New Zealand

Abstract

Emergency management controllers throughout the developed world use various information technologies to help them manage emergencies. These emergencies can evolve rapidly, meaning that efficient information management is needed to minimize a range of uncertainties. Interviews with 12 emergency operation center controllers, from diverse areas of New Zealand, were analyzed using a grounded theory approach. Results of this analysis suggested that each center uses one or more software options to manage response-related information, such as: hazard assessments, task and event logs, and intelligence received in a range of formats. Their use of different software and non-electronic options appears to vary according to the experience of each emergency management controller. The current research has highlighted a range of considerations that need to be considered when developing information technologies for emergency management. As a whole, the current paper provides a rare and tangible look at how information technology is being used by important decision makers facing hard-to-predict emergency conditions in a developed country context.

1. Introduction

Internationally, a range of software has been designed to help coordinate emergency response. Solutions can include proprietary software designed by private companies, in-house solutions developed for government and non-government agencies, and open access solutions developed and used by a wide variety of experts. As outlined by Prasanna, Yang, King and Huggins [1], this software can form part of a wider information systems architecture, including intra- and inter-organizational communications networks, and the integration of electronic data from diverse electronic sources such as building sensors. This is how software embedded as part of these architectures can support a range of demanding emergency management decisions; by extending and facilitating the situational awareness of emergency response teams [1].

Technological efforts to improve situational awareness during emergency response have included traffic forecasting and emergency alert software [2], and layered communication software for supporting emergency management decision making [3]. Other information technologies have been designed to help manage specific types of hazards, such as systems developed by Upadhyay et al. [4] and Nguyen et al. [5], for supporting fire emergency response. There are potential issues with using each of these systems under unpredictable and highly demanding emergency response conditions. These situations can combine with information system characteristics to create a series of situational awareness demons [1,6] which obscure a number of erroneous and potentially catastrophic assumptions.

This view of situational awareness issues led Prasanna et al. [1] to highlight the need for technology development which is focused on emergency management agencies’ end users, rather than being driven by developers’ and development funders’ preferences. However, a genuine focus on diverse end-users is both costly and complicated to develop emergency response software with a genuine focus on end-users. The resulting lack of a structured focus on end-user needs and preferences mean that emergency managers may not use information systems effectively, or they may not use them at all [7]. Many end-users may disregard bespoke solutions in favor of ad hoc or more flexible, proprietary solutions that may or may not be computer-based.

In among a variety of emergency management roles and potential solutions, the information-related needs and preferences of emergency management controllers are particularly important. This is because coordination errors, such as erroneous public communications and resource allocations, can have catastrophic impacts on both responding personnel and the populations they serve. Prior research [8], [9] and relevant academic literature [10] has clearly outlined information-related challenges faced by key emergency management decision makers. Except for some of the literature reviewed by Dorasamy et al. [11], there has been little research into specific information technology challenges and needs experienced by emergency management controllers.

The current case study uses a grounded theory analysis of interview data to illustrate the information needs faced by controllers and their teams responding to New Zealand emergency management scenarios. In this context, the title of controller refers to the head of each emergency operations center (EOC). They are tasked with leading the teams coordinating emergency management response and have an important role in making and approving key decisions made during emergency response. This case study illustrates how controllers’ information needs have been met, or not met, by through using one or more of the following options: Bespoke software developed specifically for New Zealand EOCs; proprietary software from a private sector company; and a relatively ad hoc approach to standard Microsoft Office applications.

New Zealand controllers and their teams appear to have minimized their reliance on their bespoke information system, which does not appear to meet their needs. This has led some offices to continue using ad hoc combinations including whiteboards, pen and paper, and generic Microsoft Office applications. Despite a lack of specific funding, other emergency management offices are adopting a proprietary information system, which they feel meets a range of their information technology needs. Their use of proprietary software and ad hoc solutions resembles dynamics observed in similar contexts. By contrast, specific human capabilities continue to be particularly paramount for many of New Zealand’s EOCs.

The current case illustrates information-related challenges faced while responding to New Zealand emergency management scenarios such as flooding, earthquakes and tsunamis, outlined in the National Civil Defence and Emergency Management Plan (2015) [12], by the Department of Prime Minister and Cabinet (DPMC) [13], and in the United Nations’ 2015 Sendai Framework for Disaster Risk Reduction. At the time of writing, relevant information-related challenges are being met through using particular information technology solutions, or by more ad hoc approaches to using highly dynamic, diverse, and often voluminous information to make pressing emergency management decisions. Controllers’ choices of modern information technology solutions appear largely determined by whether those solutions are more effective and efficient than a relatively ad hoc status quo. This illustrates the enduring importance of ensuring emergency managers have access to a flexible information system which has been designed with their particular needs in mind. It can be assumed that proprietary innovations favored by some New Zealand controllers is helping controllers and their teams adapt to emergency response demands. Aspects of this software, and the limitations of alternative options, illustrate continuing challenges for technology development and relevant research.

2. Materials and Methods

A series of emergency management controllers from around New Zealand were interviewed, using an iterative theoretical approach to sampling. Participants were interviewed using a semi-structured interview guide to ask them about their professional emergency management background, and about information-related challenges and needs faced at different stages of emergency response. They were asked how each of these challenges is approached within their emergency operations center (EOC), including questions about how certain information challenges are met by using technological tools.

Sampling incorporated the concept of theoretical saturation, by continuing analysis until the point where no more themes or insights were being developed [14]. At this stage, 12 out of a total 16 controllers working for New Zealand Civil Defence and Emergency Management had been interviewed, and no new concepts were being identified. Controllers from a wide range of geographical contexts, and with a wide range of professional experience had already been interviewed. Their recorded interviews ran to an average of 90 min. They were transcribed and real names were replaced with pseudonyms, to respect interviewees’ rights to anonymity.

We took a grounded theory approach to analyzing the resulting interview transcripts. For information technology research, the grounded theory approach aims to systematically develop a structured understanding of how particular technology-related phenomena are experienced in a particular setting [15,16,17,18]. As outlined by Urquhart [18], this method avoids erroneously assuming that engineers and other researchers conducting the analysis are free from pre-conceptions. The grounded approach to interview data acknowledges that researchers make their own interpretations of interviewees’ accounts, in a way that is relevant to their own professional domain, and with a focus on how practical problems can be resolved [19]. Analysis nonetheless focuses on how interviewees have structured their own experience [20]. This is how useful theory is generated at the interface between interviewee and researcher knowledge.

For the current case study, the phenomena of interest were information-related challenges and needs, faced by emergency management controllers while responding to emergencies in New Zealand. A grounded approach to these phenomena meant noting the themes emerging from interview data. This was carried out without imposing an initial analytical framework [20]. Our analysis also incorporated other aspects of grounded theory analyses outlined by Moghaddam [21], including comparative analysis between interviewees with different levels of experience as an emergency management controller. This comparison was aided by heuristic graphics from NVivo 11 software, to help identify major differences between groups. Following Moghaddam [21], we also compared emerging themes with theory from surrounding research literature.

3. Results

Interview analysis concluded with the analysis of the 12th interview transcript, because no further themes or sub-themes were being identified. As outlined in Section 2, this meant the research data had reached a point of saturation, where a rich sum of knowledge had already been accounted for. Going beyond this point of sampling was not likely to improve the detailed analysis of this particular knowledge domain. Analysis identified five distinct themes and several sub-themes concerning the information challenges faced by participating EOC management controllers. Five themes and several sub-themes were also identified, concerning the controllers’ information needs. All themes are outlined below. The prevalence of many themes varied according to the experience of the participating controllers. A summary of relevant variations in theme prevalence is provided at the end of this section.

A number of information challenges were identified as a result of analyzing the controllers’ transcripts. These challenges are summarized in

Table 1. Information Challenges Faced by Emergency Response Controllers.

Theme	Sub-Theme	Example
Event Characteristics	Dynamic Complexity	In addition to that the flood plain itself, when it gets rained on, a lot of ponding, and that’s aggravated by the fact that we’re now seeing increasing levels of urbanisation. These flood events generally have happened sporadically…
	Extending Timeframes	…you’re moving from the, when people are rocking in, and I guess people will want a safe environment to begin with, they’re going to want to go home, so there’s challenges in terms of that housing being available, they’ve got kids, what’s the impact on schools, there’s kind of psycho-social aspects that you’ll be grappling with, or other agencies will be grappling with.
Information Characteristics	Quantity	…the log was okay, cos you know, it was still kind of manageable but what we’re finding now is, especially in those twenty four hours plus time events the log was getting huge, and it is really hard to actually go back and use the log to say well, okay, we need to make priorities here and there…
	Scarcity	…and then you find out that there was a school camp with two hundred kids but it just went completely off the radar cos it wasn’t anything that anybody was aware of.
	Quality	I need to get somebody out there to confirm that for us, so that’s where the Police might come in and say, do you have a unit in this area that can go and check those out.
Communications	Between Organizations	…just get those lines of communication established, whether it be via cell phone, radio, whatever it is, so that we’re very clear on who and how we’re communicating. And that’s across a range of stakeholders.
	Within Organizations	I’ll tell the Duty Officer to initiate a roll call to get our permanent staff in first, so they’ll be called up and told to come in for duty if they’re fit for duty.
	Public Communications	…we’d want to start getting some public messaging out, so again how we would do that through a variety of different channels, whether they’re accessible or not, we would need to start that very early on in the piece.
	Communications Infrastructure Failure	…we do have a radio link as well as phones, but if the towers have gone down then, you know…
Operational Decision Making	Gauging Magnitude	Yeah, I think it might have taken us two days to get the Forces up, declare and get the Forces up, in fact they might have been here on day one or day two, once it was established. It was quite a big event.
	Setting Priorities	I think in this kind of event they’ll always be a decision around priority, as to where you put the effort, so you’re going to want to know lots of information around lots of different aspects.
	Operational Projections	…well there’ll still be the requirement to keep ahead of the situation, understand that impact, I mean that’s going to be…
	Tactical Planning	Is it going to be dark? It’s going to get dark in four to eight hours, so it’s a one. Good access? No access problems. The response is required, things required, actually, we’re going to monitor. So straight away we’ve got a decision.
Limited Operational Capacities	Staffing Constraints	…you’ve got limited resources to achieve what you need to achieve so there’d be decisions that you need to make around where do I best resource in finding that out.
	Ensuring Redundancy	So the Controller at the time was actually caught in town, so there was no one up here to activate the EOC.

, alongside a verbatim example of how each theme was outlined by participating controllers.

The controllers had also experienced a large number of particular information needs. They reported a more succinct number of prevalent needs, as summarized in

Table 2. Information Needs Experienced by Emergency Response Controllers.

Theme	Sub-Theme	Example
Timely Updates	Impact Progression	…forget the hazard, forget whether it’s tsunami, oil, if you focus on consequences, oil spill is around, there’s still understanding the incident, where’s the oil gone, what areas are impacted, so impact assessment again.
	Infrastructure Status	…and can we get access to them. So most critical facilities, they’ve got some kind of arrangement in place, lot of demand on fuels, that’s why accessibility is really important, so yeah, we’d be wanting to, we’ve got that list of sites so we’d be wanting to plan through them, trying to get a status.
	Logistical Status	Yeah, so those would probably be my initial concerns, and then it would be more around about status of resources available. What do we actually have, particularly again… …what actually are we able to do in time frames.
	Welfare & Evacuation Status	…we’d want to understand how many people are displaced, how many people are coming to the welfare centres, we’d want to know that. –
	Health Needs & Services	…multiple unconscious so on and so forth, so then that changes my focus to how do we get either significant medical capabilities in, i.e., field Hospitals…
	Search & Rescue Status	So, I use the initial period as the response, and that whole one is around responding to the immediate needs so it’s kind of that whole rescue type scenario.
	Timeframes	…if we had an information system that enabled us to establish some kind of a time line, you know, like...., and gave us prompts... … it would be quite good to be able to say right-o, from the time we get a flood warning this system, we could start entering in preparedness actions that we’re taking, and we could also enter in points, reminders, as we move forward, prompting us to do certain actions.
	Data Trends	…okay, you’ve got all the messages coming in and all, and that’s managing the internet, but from a larger global picture what I want to do is turn that around and look at metrics, so are the calls for Fire going down or going up?
Detailed Assessments	Infrastructure Assessments	…is it collapsed, is it partially collapsed, is it damaged, until we can get some eyes on it, knowledgeable eyes on it, structural engineers, our information is going to be quite high level.
	Welfare Assessments	…and then there would be what we call welfare, so all those people then I would say, it’s the welfare of those people. So where are we putting them, how many are going – and that becomes part of the welfare process of doing an analysis, the needs analysis of those people.
	Health Needs Assessments	…it’s more those things I was talking about at the beginning which is more about how many people are walking injured? How many can be dealt with through local medical needs, and how many need to be shipped out?
Analytical Guidance	Local Hazards Analysis	Yes, we do, but the only prediction stuff we need is how high is the water going to go? How far up on to land is the water going to go, and the scientific, the tsunami science group, endeavour to give us that, and then we have our local experts who look at that data again and put in, try to put in local variations…
	Early Warnings	So we get two alerts. I’ll get one that says tsunami early warning. We give those, you know, have a cursory look at those and it might say New Zealand may be in threat… …but we’ll see that it’s six to eight hours away to then we’ll just wait for fifty minutes to an hour for [the Ministry of Civil Defence and Emergency Management] to come out and say, yes or no, and then we’ll probably get excited cos we’ve got a lot of time.
Effective & Efficient Information Technology	Shared Systems & Interoperability	It can vary from person to person but in the ideal world the operating picture that the Fire Service communications team are looking at is the same as our one… …The Emergency Control Centre staff can look at our mapping system and look at our operating picture and compare that to Kapiti’s and Wellington’s and the Hutt’s.
	Task & Event Logs	…how well we’ve kept an audit trial of our actions. I would question that it hasn’t been as good as we would like.
	Designed for Diverse Users	…we don’t know who did the user specifications if they were done… …it seemed to address what the national centre needed in Wellington, and they wanted to be able to look to everyone, but they didn’t work with us to understand the different levels below and their needs.
	More Efficient than Ad Hoc Solutions	…and then the information that you might have got if you’d have just written down what, or taken a photo and emailed it to me, I would have had that information. I would have had situational awareness, but because the person has been told, no, you sit down at this computer and spend half an hour trying to log in, and then you write this thing and then you press go and the whole thing disappears on you, I mean, you’ve just stuffed up your whole EOC haven’t you...
Usable Information Formats	Mapping	I need to know the status of where ponding is, so I need to see where..., it would be good to be able to bring up our flood maps and say we’ll overlay that with what we know about the current situation, so that gives us a kind of picture of, okay, we know that that area at a fifty year flood level is highly likely to flood, are we starting to see that happen now, and what road or access routes are likely to be blocked and houses are likely to be affected?
	Highly Visual Displays	…be great to display that visually. As a controller when I walk in I don’t want to be reading reports or words, I want to be able to look at a screen, and actually want colours, if I see green I’m happy, if I start getting, if I see red, that’s my—and somehow all that data must feed in so that it triggers those things, high level, and if I want to know, for example if I looked at a board and it said, lifeline utilities ……in the, [region] and I saw a red flashing, so ok guys, what’s that mean…

. Each need is illustrated with a verbatim example of how controllers described the need in their own words.

The range of information needs outlined in Table 2 were reportedly being addressed to some extent, by the available information technology options. As outlined, these options included a bespoke system developed for use by New Zealand emergency management agencies, a proprietary system that was also available for their use, and ad hoc solutions selected from a range of other non-dedicated software and non-technological alternatives.

Table 3. How Information Needs are Met by Different Software Types and Ad hoc Solutions.

Need	Bespoke Software	Proprietary Software	Ad hoc Solutions
Timely Updates	Focused on task and event logs for accountability.	Updates may require less user input.	Include readily updateable whiteboard formats.
Detailed Assessments	Available information may not meet specific needs.	Available information may not meet specific needs.	Information available from a range of channels and sources.
Analytical Guidance	Includes some applicable analyses.	Some decision-making support available.	Delivered by allied organizations.
Effective & Efficient Information Technology	Needs to match platforms used by other agencies. Can be less efficient than ad hoc solutions.	Can be less efficient than ad hoc solutions.	Selected according to previous effectiveness and efficiency.
Usable Information Formats	Could include better mapping and highly visual formats.	Includes mapping and highly visual formats.	Include a range of familiar and accessible formats which do not require further training.

summarizes how each type of need was being met by each information-technology alternative.

Interviewees had a wide range of specific controller experience. For example, one interviewee had over 30 years of experience as an emergency management controller. These differences led us to divide the controllers into two groups: Those with 10 or more years of controller experience, and those with less than 10 years of controller experience. These groups were respectively labelled More Experienced and Less Experienced and we noticed several differences between each group during the grounded theory analysis. Figure 1 and Figure 2 summarize how particular information challenges and needs were more relevant for one group or the other. Figure 3 summarizes overall differences in the relevance of information challenges, information needs, and Required Team Characteristics.

Figure 3 shows the relative relevance of Required Team Characteristics, information challenges, and information needs. Required team characteristics were plainly much more relevant for more experienced controllers. Information challenges also appear to have been more relevant for this group. Less experienced controllers appeared to be more focused on information needs.

4. Discussion

Many of the challenges faced by the current set of controllers have been documented in surrounding scientific literature. Other challenges are relatively novel and are best described in the controllers’ own terms. Most can be matched with particular information needs because meeting these needs appears to help resolve the challenges outlined. Surrounding literature suggests additional solutions, in terms of specifically information-related needs.

As shown in Figure 1, Figure 2 and Figure 3 above, more experienced controllers appeared to focus on different challenges, needs and Required Team Characteristics, as compared to their less experienced counterparts. It is important to note that the current research has differentiated between role, rather than system use, experience. Differences in emergency managers’ age and experience can relate to different patterns of information technology adoption [7,22,23]. For example, adoption among individuals with more emergency management experience has been particularly dependent on facilitating conditions [7]. The latter, pre-existing, finding is highly relevant to the current research, even though it concerned much smaller differences, of less or more than three years of emergency management. However, the current set of marked, role-specific differences show the importance of facilitating conditions in a different light. More experienced controllers placed their confidence in facilitating conditions such as a highly capable team, with Required Team Characteristics. Most of these team characteristics concerned abilities to overcome the limitations of electronic information systems, rather than the ability to readily adopt those systems.

Overall, it is important to note that all identified information challenges relate to particularly challenging operational contexts. According to the controllers, response coordination scenarios are often marked by interactions between two or more dynamic systems. These “interactions between two or more system components create phenomena that is emergent and hard-to-predict” [9] (para 5). Psychological literature, including Diehl and Sterman [24] and Huggins et al. [25], refers to this as Dynamic Complexity, which is the specific concept we used to interpret relevant material from controller interviews. Huggins et al. [25] highlight the challenges which resultingly emergent and hard-to-predict phenomena present for important emergency management decisions. Due to Dynamic Complexity, these decisions are based on information that may be ill-defined and incomplete and, due to highly changeable circumstances, out of date. This can make particularly relevant and crucial decisions, such as assigning a magnitude to actual or incoming emergency events, particularly challenging.

4.1. Gauging and Communicating Magnitude

As outlined in the preceding section, the emergency management controllers appear to face a range of information-related challenges during emergency management response. The first of these challenges concerned Gauging Magnitude. Depending on the perceived magnitude of a particular event, controllers may need to activate EOCs, request additional support, and, in the most severe cases, declare an official emergency. Several controllers suggested that it can be better to over-estimate magnitude, due to the consequences of not responding sufficiently, in good time. However, they also described the way that overestimating magnitude can erode public confidence, meaning that future calls for protective actions such as evacuation could be dismissed.

Communicating with the public appears to be particularly challenging during the onset of an emergency or disaster event. Allen et al. [26] used the 2017 Puebla earthquake to highlight the importance of promoting distinctly simple responses during the onset of emergency and disaster events. These responses need to be relatively habitual and prompted by very simple and unambiguous messaging, whether delivered by public address systems, cell tower broadcasts, radio or other means. For example, Allen et al. [26] highlighted how ambiguous interpretations of earthquake early warnings are best replaced by messaging that simply states that a major earthquake is likely to occur. If the earthquake does not occur, this alert can be treated as an opportunity for practicing appropriate protective actions such as dropping, covering and holding on [26].

4.2. Analytical Guidance

Differences between scientist-to-controller and controller-to-public communications mean that challenges of Gauging Magnitude and Communicating with the Public require particular approaches to Analytical Guidance. Controllers must receive and interpret this guidance before communicating with emergency affected populations. According to the controllers interviewed, this guidance mainly consists of rapid early warnings and the more paced delivery of local hazards analysis. Nonetheless, many relevant, emergency response, decisions are made in very short timeframes, often demanding the kind of rapid thinking outlined by Evans [27] and Kahneman [28]. In the related terms of bounded rationality, outlined by Simon [29] and by Huggins et al. [25], this rapid thinking is highly constrained by certain Information Scarcity and the ability of controllers and their teams to process available information almost instantly. These and other issues outlined by Doyle and Johnston [30] limit the complexity and detail of information than can be processed by controllers tasked with making urgent decisions. Similar issues apply to decisions outlined by the controllers, concerning Operational Projections, Setting Priorities and Tactical Planning.

The controllers discussed how more slow-paced decisions concern early warnings for distant tsunamis and flooding, which can be received several hours before the impending impacts are likely to occur. This gives controllers and their emergency operations teams a lot more time to develop and act on challenging elements of situational awareness outlined by Endsley [31]: current situational awareness, of antecedent implications, and prospective situational awareness, of effective actions. For the challenging decisions made by response controllers, the current aspect of situational awareness relates to themes of Gauging Magnitude and Operational Projections, while the prospective aspect applies to Setting Priorities and Tactical Planning. Slower decisions will still reflect varying degrees of bounded rationality, due to persistent limitations on information availability and timeliness [24]. Likewise, as outlined by Evans (27), slower decision timeframes still include series of rapid decisions. However, it can be useful to look back at generalizations made in decision-making science and practice.

4.3. Information Flow

Even urgent decision making does not occur in a time-limited vacuum. Fast decision making has traditionally been analyzed within the space of 600 milliseconds or less [24]. Relatively more contemporary models of macrocognition, of how human cognition adapts to meet the challenges posed by complex systems and scenarios therein [32], have been developed for tasks as demanding as maritime military operations. One of these models has been applied to emergency management, by Huggins et al. [9], and highlights how rapid thinking at the individual level occurs within a context of much slower information gathering and communications. This means that controllers often have time to take a more strategic approach to emergency management. This approach can incorporate a range of Timely Updates, received from their own personnel, other organizations, and from the wider public.

In theory, extended timeframes also allow for more effective communication between each of these stakeholder groups. When handled effectively, this communication can deliver the more Detailed Assessments required for ongoing response-related decisions. However, the vast amount of information received from these, and other, groups also creates the challenge of Information Quantity. Incoming updates include information about Impact Progression, Infrastructure Status, Logistical Status, Welfare and Evacuation Status, Health Needs and Services, Search and Rescue Status. These updates are received via a number of communication channels, including radio communications, face-to-face communications at an incident site, or in meetings held between responding agencies.

Relevant information received from the public and even some information from response professionals lead to the challenges concerning Information Quality. According to the controllers, Timely Updates that have not been observed, communicated or documented reliably often need to be verified, often through repeated observations by a third party. Some of this information is vital and errors, such as assuming that stable roading infrastructure cannot be used, can be costly. Important decisions continue to rely on the information being received, to the extent that many updates need to be double-checked in person. Perceived Information Quality is also an important factor predicting the adoption of EOC information systems [7]. Fortunately, there are some technological solutions for improving the quality, and therefore the reliability, of event-related information. The controllers already report using standardized forms for conducting more detailed needs assessments and other information collection. As outlined by Jayawardene [33], attention to the ways this information is recorded and entered into an information system can vastly improve the quality of resulting data. This will minimize data quality issues outlined by Eppler [34], including:

• Duplicate entries;
• Missing relationships between data;
• Meaningless entries;
• Spelling errors;
• Obsolete or outdated entries;
• Inconsistent data formats or naming conventions;
• Data saved in the wrong database; and
• Incorrect data coding or tagging.

The current set of controllers reported facing the challenge of Information Scarcity. Much of the information that they require may not be immediately available. Some information may be absolutely unavailable, due to issues with confidentiality and the inability to share that information between different agencies’ information systems. This creates a need for Interoperability and Shared Information Systems, alongside other aspects of Effective and Efficient Information Technology.

4.4. Effective and Efficient Information Technology

Controllers’ accounts of Required Team Characteristics are a reminder that certain human capabilities, such as Training, Professional Experience and Expertise, and the Ability to Improvise are essential for performing critical emergency response roles. It is intuitive to assume that personnel selection and training for such demanding and critical roles are indispensable. Among other characteristics and given the uncertainty created by the Dynamic Complexity of many emergency events, response personnel will also need an Ability to Improvise. However, these abilities are particularly stretched in the absence of Effective and Efficient Information Technology. This situation requires information technology that is More Efficient than Ad Hoc Solutions. In the absence of such technology, many of the controllers continued to prefer paper documents, whiteboards, and meeting in person or via teleconference, instead of using the bespoke information system that is readily available for their use. According to the controllers, relevant ad hoc solutions extend to the use of generic Microsoft Office software, including a generic email application.

The controllers outlined a number of user requirements for a dedicated EOC information system, in terms of their information needs. As outlined in the Results section, these needs included: Flexibility for changing operational circumstances, Intuitive Interfaces, Task and Event Logs, and Interoperability; being Designed for Diverse Users with a number of different roles and capabilities; and being More Efficient than Ad Hoc Solutions. In an ideal world, this set of reported user requirements would have been the focus for developing the bespoke information system developed specifically for New Zealand EOC’s. This would reflect a user’s view of an information system for emergency operations, where all aspects of system design are determined by the needs and preferences of emergency response end-users [1]. The potentials for this approach have been illustrated by Prasanna, Yang and King [35]. The statistical relationships between meeting end-users’ needs and their eventual adoption of emergency management information systems has been identified by Prasanna and Huggins [7].

However, as outlined by Prasanna et al. [1], a user’s view of information systems for emergency management is typically encapsulated within an owner’s view of system development. Although preferable to less responsive approaches, this latter view of system development can be driven by the party that is effectively paying to develop and own the resulting emergency management information system. This appears to be the current case, where controllers implied that development of their bespoke system has been driven by higher-level, organizational drivers. For one example, these drivers appear to have resulted in a particular approach to Task and Event Logs, which will provide for invaluable after-action analysis and accountability at the wider organizational level.

Controllers suggested that these logs have become a time-consuming aspect of the bespoke information system which their operationally focused teams tend to avoid. Research by Prasanna and Huggins [7], conducted with emergency managers from a range of anglophone settings, helps explain the reported relationship between inefficiency and low uptake. According to this research, there is a strong causal relationship between perceived ease of use and intentions to use an information system for emergency management. The relevance of this prior research finding is not surprising because it included several participants from the same contexts as the current participant sample. Other aspects required by the current set of controllers, such as information systems that are Designed for Diverse Users, have also been highlighted in prior research, by Prasanna et al. [1].

The need to design information systems for diverse users led Prasanna et al. [1] to promote an end-user view for developing information systems for supporting emergency response. As taken to the extreme in fire-fighting research by Prasanna et al. [1], regular users of an information system are often located a lot closer to an actual emergency event. By the current controllers’ own admission, their teams are not usually out on the actual incident site, directing fire hoses to hold back an urban inferno. However, wrong decisions made at the EOC level can be just as catastrophic. As outlined in the Results section of the current paper, EOC controllers and their teams need to manage a diverse amount of data relating to infrastructure status, logistical status and a wide range of urgent needs. The failure to almost constantly combine this information into an effective situational awareness can often lead to major injuries at the very least.

Although the current set of controllers did not outline such grave consequences, they did outline a number of needs that are not fulfilled by their bespoke information system. Their accounts also suggest that the system may have been developed with a distal owner-focus, rather than a focus on the operational needs of end-users. According to the controllers, the resulting software does not constitute Effective and Efficient Information Technology that is More Efficient than Ad Hoc Solutions used by the controllers and their EOC teams. As outlined, this has led many of the controllers to continue using relatively un-sophisticated and ad hoc solutions for managing response-related information. Other controllers have elected to use a proprietary system, provided by a private company. Many controllers report that this system meets a range of their needs for an Effective and Efficient Information System.

According to their accounts, this system also meets needs for Usable Information Formats, including Highly Visual Displays that include symbols and colors rather than being based on text alone. It is unclear whether mapping produced by geographic information system specialists is already integrated within this proprietary software platform. Mapping nonetheless appears to be a preferred format for rich visual data, among the current set of controllers. Reported needs for mapping are likely due to the geographically specific nature of many disaster and emergency events. The value of mapping graphics over a text-based equivalent is even more intuitive. It would take many words to outline the graphics, forms and distribution of even the most basic mapping image in any depth. According to Huggins et al. [9], additional advantages of using richly visual information displays for emergency management can include:

• Engagement with non-linear dynamics, such as inter-dependencies and cycles;
• Sharing diverse information and relevant decisions between team members; and
• Sharing diverse information and relevant decisions between collaborating organizations.

Controllers’ accounts also indicate that it can be costly to continue using the proprietary system beyond its demonstration period. Institutional support is a technology adoption factor identified in prior research by Prasanna and Huggins [7] and is likely to be vital in the current case. This support may need to come from a sub-national level, given that their national level administration appears to have already provided full access to bespoke software developed for all New Zealand EOCs. However, and as outlined in the following section, we are not currently in a position to endorse any one particular information system, especially when there may have been many other drivers for developing and retaining the bespoke information system.

5. Conclusions

The current case study focused on how information has been used to enhance situational awareness, during coordinated responses to New Zealand emergencies. Research data was obtained through interviews about information challenges and needs experienced by emergency management controllers from several different regions of New Zealand. These interviews were analyzed by using a grounded theory approach to focus on the controllers’ own understandings. Those understandings were compared between different groups of controllers and were also compared to pre-existing theory. Analysis also led to the identification of several themes that may have not been addressed by previous research literature.

These themes, alongside surrounding research theory discussed in the previous section, call for some very practical changes to the way information systems are being developed and used for managing emergencies in the New Zealand setting. They also echo issues concerning the development of information systems for other purposes, in many other national settings. The current case study is nonetheless exploratory. This means that the current results and their discussion mainly serve to ask a range of further research questions.

5.1. Human Factors with a Capital H

Among other findings, interview analysis led to the emergence of a surprising analytical category, Required Team Characteristics. Due to differences between interviews with more and less experienced controllers, this category resembled the technology adoption factor of facilitating conditions, previously identified in emergency management research by Prasanna and Huggins [7]. The current case also highlights how certain team characteristics do much more than facilitate the adoption of a particular information system. Team characteristics, such the Ability to Improvise, and Local Community Knowledge, appear to help overcome the limitations of certain information systems available within New Zealand EOCs.

The controllers’ accounts serve as an important reminder about the importance of selecting and training the right personnel, for demanding EOC roles. These roles will vary to a certain extent, especially under the current Coordinated Incident Management System 2 framework being used by emergency managers throughout New Zealand. Among other roles, EOC personnel will include planning and intelligence, welfare, and communications specialists. Among these roles and their distinct information requirements, the current interviews have reminded us that emergencies require controllers to make a range of operational decisions, under highly constrained and pressured conditions.

Even when these decisions are made in the name of a particular controller, they are usually shaped by an EOC team sharing many of the same operational challenges. This means that although EOC team members must be able to implement particular plans and procedures, they also need the Ability to Improvise under event conditions that are likely to change at any moment. This is particularly relevant in the absence of Effective and Efficient Information Systems and certain operational capacities, which appear to be severely limited by Staffing Constraints. These conditions can often lead to large gaps between operational demands and ideal responses. It bears repeating that the selection and training of EOC personnel are crucial for ensuring the success of prioritized emergency management operations.

5.2. The Need for User-Focused Development

As outlined earlier, the controllers discussed several limitations of the bespoke information system developed specifically for New Zealand EOCs. Controllers’ accounts of attempting to use this system may relate to wider problems with an owner’s view of information system development. It is intuitive that costly software development will need to be approved by the owners of that system, namely the people or organizations paying for development. As suggested by the current set of controllers, this approach to information systems for emergency management encompasses reporting functionalities and other features that are mainly required at the headquarters of an emergency management organization. However, this level of system owners is unlikely to use an information system as often, or under as many demands and constraints. Their engagement with system development is not likely to be as visceral and engagement and other system functionalities may end up being under-prioritized. At the same time, software developers’ engagement with other parts of the client organization can become under-resourced or even tokenistic, if this engagement is not the central aspect of completing an owner-focused contract for software development.

As the authors of the current case study, we are not in a position to assume that this is exactly what has occurred with the bespoke software in question. As also outlined earlier, there may have been many other drivers for developing this software. The bespoke software may also include functionalities that have not been outlined by the current set of controllers for one reason or another. At the risk of using a very worn-out cliché, further research inquiries would be required before definitively categorizing the dominant view of software development for New Zealand EOCs. In the meantime, we can assume that both research and practice will benefit from marking the difference between an owner’s view and an end-user’s view of system development.

Principles from macrocognitive theory and research, summarized by Huggins et al. [24], suggest that the information management tools shared by EOC teams play a critical role in facilitating effective situational awareness. By contrast, ineffective information systems can lead to a number of erroneous situational awareness outcomes, as outlined by Prasanna et al. [1]. It follows that the demands faced by a particular system user and/or the time spent using that system should ideally determine their status as an end-user. This point is made assuming that the case for an end-user view of system development has already been established, by Prasanna et al. [1] and a large body of software development literature from outside the emergency management domain.

Some user preferences and requirements can cost a lot of time and money to develop. For example, the controllers’ account indicate that they would ideally prefer to have mapped updates on event progression, impacts, needs and the logistical status of various resources. However, current mapping technology is unlikely to deliver such a comprehensive combination of rapid updates. This is because all relevant information would need to be standardized and geocoded with global positioning system coordinates. Even if we disregard related hardware and communication infrastructure difficulties, the importance of software and system interoperability should not be underestimated. Controllers’ accounts indicate that emergency management agencies and their collaborators are using distinct information systems that cannot yet share basic information, let alone manage a diverse flow of reliable, geocoded data. Rather than assuming that real-time situation mapping can be achieved with a few application downloads and the flick of a switch, certain aspects of software development will need to be prioritized. We suggest that these aspects are selected in terms of their potential and proven macrocognitive benefits, combined with the likelihood of end-user uptake.

5.3. Limitations

The current research was shaped by the interests and professional backgrounds of both authors. The first author comes from a psychological research background, complete with a focus on group and organizational dynamics. It can be argued that this led to focusing on human capabilities in particular. However, it can also be said that a more human and social focus was able to balance technological assumptions being made by the other author, who comes from an information engineering background. The second author’s professional background means that the current research has largely focused on requirements gathering, as one step in an end-user view of system development. However, requirements gathering normally follows a very different process, rather than the iterative ground theory approach chosen for the current research. In any case, this author’s background also forms a strength of the current research. Among other benefits, this author was able to elicit highly relevant interview data, for commenting on relatively technical information challenges and needs.

In any case, the current research deals with qualitative data that was collected using non-standardized, semi-structured means. This data was analyzed using a highly iterative process that has been heavily documented but is by no means replicable. This has led the current authors to avoid making any normative, probabilistic or other statistical claims. These, and other attempts to generalize widely from the current research, can wait for further research, including the research outlined below. Likewise, endorsing any particular system would require very different approaches to the current, exploratory research, including a range of quantitative and qualitative data gathering. Specific experimental designs would also be required, to compare the situational awareness resulting from the use of each particular system and their components. Further research, including a wider range of data collection and analysis, is required.

5.4. Implications for Further Research

As outlined above, the current research has taken an iterative and exploratory approach to better understanding information challenges and needs experienced by New Zealand’s EOC controllers. Several assumptions, concerning the importance of certain information management requirements, of an end-user driven development, and of personnel selection and training, have been generated as a result. Each of these assumptions remain tentative until tested in a way that could conceivably falsify specifically relevant hypotheses.

Each of the current authors have been involved in the development of research to guide the development and testing of information systems for the emergency management domain. Situational awareness, at both tactical and strategic levels, has been a strong focus of this research. It forms a key outcome that must be optimized wherever possible, towards saving life, limb and public faith in the rapidly transforming area of emergency management. Relevant research, to compare the way that different information systems support or degrade effective situational awareness, is both costly and time consuming. At the time of writing, we hope that continuing collaborations, with colleagues both in and outside of New Zealand, will bring this kind of more definitive research to fruition.

Speaking of collaborations, we would like to recognize the rich accounts provided by emergency managers who agreed to be interviewed for the current research. Although we have only been able to reference a small portion of their accounts, experiences shared by all interviewees have fundamentally shaped the current paper. Some interview content left us doubting some of our previous assumptions. We take this as a good thing. In all cases, we were also pleasantly surprised by how candid the controllers were, and pleasantly surprised by how willing they were to entrust us with fairly sensitive details. In the same spirit of openness, we hope that the current paper will receive commentary, applications and adaptations within, and even beyond, the growing field of emergency management.