PM 761 Technology in Emergency
Management
John Jay college of Criminal
Justice
Murray Turoff
Distinguished Professor Emeritus
Information Systems Department
New Jersey Institute of Technology
http:/is.njit.edu/turoff
turoff@njit.edu
(C) Murray Turoff 2009
1
(C) Murray Turoff 2009
2
Disaster have been with us
for a long time
(C) Murray Turoff 2009
3
Katrina
(C) Murray Turoff 2009
4
Course Objectives
 Cover Requirements for Emergency
Preparedness and Management
Information Systems
 Consider behavior of individuals, groups,
organizations, and the public
 Consider communications and auxiliary
technology
 Extreme Events
 Evaluating Technology and associated
policies
 Underlying philosophies
 Future Concerns
(C) Murray Turoff 2009
5
Other Course Materials
 Online bulletin Board System
 Discussion threads/conferences/lists
 Instructor Instructions, read only
 Syllabus for course
 Using the discussion system
Lecture Materials, read only
Reading Materials, read only
Introductions
Questions on Lectures
Questions on Reading materials
Questions on assignments
Other Questions
Things to do (for learning), required
Bad Examples of Emergency Management,
required
 Jokes in Emergency Management
 Practice
 Café (not on the course topic)









(C) Murray Turoff 2009
6
Emergency Response Systems
First Presentation Content




Nature of an Emergency
OEP Experience & Wisdom
EMISARI at OEP
DERMIS Conceptual Design
 Dynamics Emergency Response Management
Information System
 General Principles
 Auxiliary Supporting Systems




Resource Database Systems
Collaborative Knowledge Systems
Virtual Communities
Social Networks and associated options
 Auditing and decision support
 Topics & Group Communications
 Concluding Remarks
(C) Murray Turoff 2009
7
Nature of an Emergency
(C) Murray Turoff 2009
8
Emergency Management
Characteristics
 Unpredictable:
 Events
 Who will be involved
 What information will be needed
 What resources will be needed
 What actions will be taken, when, where, and by
who
 No time for training, meeting, or planning
 No contingency plan that fits perfectly
 Planning should focus on the process
(C) Murray Turoff 2009
9
Associated Concerns
 Real practitioner team never formed till the
emergency occurs




 Trust
 Conflicting goals
 Hundreds to thousands involved
Planners and executers are different individuals
Insufficient networking experience
Insufficient command and control
Disasters do not obey political, social,
organizational, geographical boundaries
 Many problems occur at interfaces to boundaries –
major errors, mistakes
 Sometimes called “interoperability”
(C) Murray Turoff 2009
10
Emergency Management
Requirements











Obtain data, status, views
Monitor conditions
Fill roles on a 24/7 basis
Obtain expertise, liaison, action takers, reporters
Defer to expertise and experience
 Need trust and shared objectives
Draft contingencies
Validate options
Obtain approvals, delegate authority
Coordinate actions, take actions, evaluate actions,
conduct oversight
Innovate when necessary
Evaluate outcomes
 Modify scenarios and plans
 Modify systems and operations
 Correct CAUSES of prior errors
(C) Murray Turoff 2009
11
Emergency Management
Phases & Activities
 Preparedness (analysis, planning, and
evaluation):
 Analysis of the threats
 Analysis and evaluation of performance (and
errors);
 Planning for mitigation;
 Planning for detection and intelligence;
 Planning for response;
 Planning for recovery and/or normalization
 Continuous correction of operations and plans
 Design of support systems and relationships
 Training
 Mitigation
 Detection
 Warning
 Response
 Recovery/normalization
(C) Murray Turoff 2009
12
Organizational Emergency
Situations
















Strike
Court Case
Cost overrun
Delivery delay
New regulation
Terrorist action
Supply shortage
Natural Disaster
Man Made Disaster
Production delay
Product malfunction
Contract Negotiation
Loss of a key customer
Responding to an RFP
Loss of key employee(s)
New Competitive product
(C) Murray Turoff 2009
13
Positive Emergency Situations
Responding to an RFP
Winning a large contract
Developing a new product
Creating a long term plan
Understanding and responding to new
regulations
 Taking over another company
 Too many orders for a product





 Employee shortage
 Shortage of raw materials
 Production problems
 Creating a time urgent task force or
committee
 Matrix Management
(C) Murray Turoff 2009
14
Business Continuity
and “other”
 Very similar concerns to Emergency
Management
 Most business rely on external resources and
support provided by the community they
reside in
 However utilities, chemical plants, military bases,
etc, must deal with the problems their existence can
create
 Law Enforcement has a unique characteristic
in trying to detect man made threats and
dealing with them beforehand rather than
those produced by nature
 Citizen, medical, community and Private
Organization preparedness and management
 Interoperability is a major concern
 Should be no real professional difference in
EM between public and private sectors
(C) Murray Turoff 2009
15
Lessons of 9/11 for Design
 Vulnerability of a physical command and
control center
 Reductionism applied to
 Dynamic information
 Responder responsibilities
 Responsibilities of Agencies
 Communication systems
 Threat-Rigidity Syndrome
 Clear Exceptions to Plans and innovations
 Ferries as ambulances
 Use of N.J. National Guard telephone network
via guard members
 GIS database critical to recovery (e.g. bathtub)
 Recovery a major undertaking (e.g. response
continued: contamination)
(C) Murray Turoff 2009
16
Katrina Experiences
 Lack of adequate plans for things like evacuation
 Flawed local planning process
 Lack of considering behavioral implications
 Evacuation, civil employees, citizen trust (axes)
 Interrelationships of land management and
change of threat
 Obsolete data (flood prediction maps)
 No overall responsibility for long term
consequences of many actions by different entities
 Loss of local command and control facilities
 Contamination of waters
 Lack of coordination among organizations of all
types
 Ice Fiasco, Citizen boat owners, Coast Guard, Red
Cross, medication
 Lack of initiatives
 Lack of expertise
 National Guard Status
(C) Murray Turoff 2009
17
Evacuation Example
 Evacuation Plans are quite common but usually at
a high level without answering the problem of
exceptions
 How do you get people to evacuate in phases which
some plans called for?
 What happens to first responders that want to
insure there family gets out?
 Does a gas station attendant stay on the job?
 Does a food or grocery worker stay on the job?
 How do locals get last minute supplies?
 Does the bus driver leave his family behind?
 How do you handle accidents in an evacuation?
 Can medical, police, and public works communicate
to be able to keep cars moving?
 Akin to building an information system under the
assumption nothing will go wrong and all
incoming data is perfect.
 No exceptions are allowed
 Accidents, stalled vehicles, traffic jams, lack of gas,
food, water, etc.
(C) Murray Turoff 2009
18
Planning is Critical
 Nothing works without good plans
 Planning is a continuous process
 Planning needs to be done with the
involvement of those that will be
executing them.
 Planning must focus on defining the
process, responsibilities, roles, and the
resources, not the decisions
 Planning has to include recognizing prior
mistakes/shortcomings and correcting
them
 Planning has to be tied to generation of
mitigation options (Long term cost saving
ratio 3-5)
(C) Murray Turoff 2009
19
OEP Experience & Wisdom
Office of Emergency Preparedness
Executive Office of the President
(C) Murray Turoff 2009
20
Office of Emergency
Preparedness (OEP)
 Existed until 1973 in the Executive Offices
 Derivative of OSS (Office of Special Services)
 Centralized civilian command and control in any
crisis situation:
 natural disasters, national strikes, commodity
shortages, wartime situations, industry
priorities, wage price freeze
 Command resources of all federal, state, local and
industrial sources
 Could incorporate personnel as needed from any
source
 Did contingency planning and utilized large
community of experts and professionals on a
national bases
 EMISARI functioned in the GSA until the late 80’s,
manual: http://library.njit.edu/archives/ccccmaterials/ Report ISG-117: The Resource
Interruption Monitoring System, October 1974
GSA
(C) Murray Turoff 2009
21
OEP Wisdom I
 An emergency system must be regularly
used to work in a real emergency
 People are working intense 14-18 hour
days and cannot be interrupted
 Roles rather than person of the moment
 Timely tacking of what is happening is
critical
 Delegation of authority a must and
oversight of delegated actions is critical
 Providing related data and information up,
down, and laterally is critical
 No way to know who will be concerned or
contribute to a particular problem
 Plans are in constant modification
(C) Murray Turoff 2009
22
OEP Wisdom II
Professional observers needed and
trusted
Learning and adaptation of
response plans from training and
real events is a necessity
In a crisis exceptions and
variations to the norm are common
The critical problem of the moment
collects attention and resources
(C) Murray Turoff 2009
23
OEP Wisdom III
 Roles are the constant in an emergency
and who is in a role may vary
unexpectedly
 Training people in multiple roles is very
desirable
 Roles and their privileges must be defined
in the response system (and the software)
 Understanding what is reality as an
objective
 Coordination under unpredictability
 24/7 operation
(C) Murray Turoff 2009
24
OEP Wisdom IV
Supporting confidence in a decision
by the best possible timely
information
Necessary Properties
Free exchange of information
Delegation of authority
Decision accountability
Decision oversight
Information source identification as to
source, date-time, reliability
Information overload reduction
 Important computer design challenge
(C) Murray Turoff 2009
25
OEP Wisdom V
The crux of the coordination
problem for large crisis response
groups is that the exact actions and
responsibilities of each individual
cannot be pre- determined.
Coordination by feedback not by
plan
Realistic information on current
conditions determines actions taken
Paradox of Executive Planning
(C) Murray Turoff 2009
26
Recent Supporting Wisdom
Hale 1997
“. . . the key obstacle to effective
crisis response is the
communication needed to access
relevant data or expertise and to
piece together an accurate
understandable picture of reality”
(C) Murray Turoff 2009
27
Other Supporting Wisdom
Dynes & Quarenteli 1977
“Coordination by feedback viewed as
failure of planning and failure of
coordination by most organizations.
Instead plan should focus on improving
and facilitating feedback”
Plan the process and not the actions. Tie
actions to observable measures and trust
in expertise and experience
The future is too variable to predict what
outcomes should be as part of a plan—a
disaster or a new product
(C) Murray Turoff 2009
28
Other Supporting Wisdom
Horsely & Barker, 2002
 Information Overload is typical
 People perform at higher levels of ability then
usual or expected
 Heterogeneous groups and individuals
 People work together who do not normally
do so
 Quick trust and spontaneous virtual teams
 Cannot predict who will be involved
 Cannot predict who will carry out what role at
what time
 Community and Public relations is
critical (confidence and trust)
 Consider hurricane evacuation in Texas after
Katrina
 People panicking is very rare especially if
authority is trusted
(C) Murray Turoff 2009
29
Threat Rigidity Syndrome
 Stress sets in, possible from:
 Fatigue, long hours, cognitive conflicts, high
uncertainty
 Information Overload and/or uncertainty of
right data being there
 Responsibilities for lives and as lives are lost
based upon decisions made doubt and
uncertainty in abilities set in
 Is better information going to show up in time?
 Golden hour for medical treatment
 Choice of following a formula or engaging
in problem solving, creativity, and/or
improvisation
(C) Murray Turoff 2009
30
COGNITIVE ABSORPTION (Agarwal
and Karahanna, 2000)
 Psychological state of deep involvement
 Temporal dissociation
 Focused immersion
 Heightened enjoyment
 Curiosity or challenge
 Observed for computer game players and
FAA controllers
 May lessen threat rigidity
 It can be a property of EM operators in a
command and control environment
(C) Murray Turoff 2009
31
Mental Questions that Cause
Stress
 Is the information I have a realistic
picture of the situation?
 Should I wait longer to make a decision
and then I will have better information?
 Does someone have the information I need
to make a better decision?
 How many more lives will be lost or saved
if I wait for more information?
 Can I trust the person taking over my role
or should I work longer?
 Will that person have what I know and did and
will I know what he did easily when I return?
(C) Murray Turoff 2009
32
Model of Threat Rigidity
Quality of
Decisions
Actions
Analysis
_
+
Increased
Innovation
Environment and
Support Systems
Amount of Irrelevant
Information
Recognition of Relevant
Information
Increased Cognitive
Absorption
Increased Information
Overload
Irrelevant
Interruptions
Sensemaking
Experience
Loss of
Cognitive
Attention
Maintenance of
Cognitive Attention
Improved Situation
Awareness
Stronger
Motivation
Positive
Outcomes
Negative
Outcomes
Positive loop
Lower
Stress
Levels
Positive
Sense of
Control
Negative
Sense of
Control
Negative loop
Increased Threat Rigidity
Syndrome
Increased
Fatigue
(C) Murray Turoff 2009
Higher
Stress
Levels
33
Emergency Response
Critical Success Factors
 The priority problem of the moment is the magnet that
gathers the data, information, people, and resources to
deal with it
 The integration of qualitative and quantitative
information with measures of timeliness, confidence and
priority is critical
 Having pre-established existing communities of people
and resources to draw upon
 Knowing who and what is available in real time
 Learning from each experience and modifying lore for
the future
 Allow participants to discover the problems they are
concerned about or can contribute to (open architecture)
 Thousands of users possible but only 5 to 25 focus on
any one problem and is unpredictable beyond basic roles.
Depends on circumstances of surrounding problem.
 Decisions being made on incomplete information in a
time urgent manner
(C) Murray Turoff 2009
34
Open Issues
People can work 36 to 48 hours
continuously in some crisis
situations
How do we really know when stress
and/or fatigue is interfering with their
judgment?
How do we create quick trust in this
environment?
How do we encourage creativity
rather than rigidity?
How do you design an information
system to encourage creativity?
(C) Murray Turoff 2009
35
Emergency communication
design concepts
 Provide signals of a communication process
 Content can be the address
 Address a message to any data item whether
quantitative or qualitative
 Who created or modified text or data and when it
occurred is always tracked
 Status of inputs always visible
 Contribution Attributes: confidence, priority,
source
 Text can be program: active or adaptive text
 Human roles in the software (varied privileges)
Lateral (two way) linkages of material
 Do bookkeeping of communications for user
 Optimize group/team processes rather than
individual processes.
 Associate qualitative and quantitative information
(C) Murray Turoff 2009
36
EMISARI
Emergency Management
Information System And Reference
Index
An “emissary” to those on the front
lines
Created in one week as a derivative of
an existing Delphi Conferencing System
for the 1971 Wage Price Freeze
(C) Murray Turoff 2009
37
EMISARI 1971
 Emergency Management Information System And
Reference Index
 Developed at OEP on a UNIVAC 1108 using EXEC
VIII – early multiprocessor design (48 bit words)
 Sharable database structures with individual word
locking/unlocking in hardware
 First used for Wage Price Freeze in 1971
 Based upon software developed for virtual expert
communities as a Policy Delphi Process
 Used until late 80’s for strikes, commodity
shortages, and some natural disasters.
 Typically 100-400 users, 20-50 government units
(C) Murray Turoff 2009
38
EMISARI Objects
 Administrator (any object can be changed or
created in a few minutes)
 Contacts (people)
 Conferences & Notebooks
 Data elements, tables, & matrix forms
 Authorship & time of data by contacts
 Label, definition, & contact
 Data Status: unavailable now, never, temporary,
funny
 Directory
 Contacts
 Assignments / Responsibilities
 Available objects
 Online real time chat
 Separate message system
 Send messages to any data item or any contact
(C) Murray Turoff 2009
39
Send Message to Data Element
 Reporter contact could explain what was
wrong with it
 Analyst could provide their interpretation
of what it meant
 Contact could indicate he or she needed
something different or complementary
then current reported item
 Any contact could make comment about
what it means to them like suggesting it
needed a detailed discussion in some
conference on the system
 What databases do you use where this might be
a handy feature?
 Still not a standard feature
(C) Murray Turoff 2009
40
EMISARI Functions




Message sent to contact, data element or form
Discussion threads attached to objects
Report formulation
Virtual references between any objects simpler
html form.
 Could include current version of any data element,
text, message, etc in any other text item (&<m###,
c##C###, n##p### d### v### t###)
 Exception reporting using notifications (new
entries using certain key)
 Indexes
 Adaptive by use, most popular words in a two week
period
 Tracking misses, listing words searched but not found
 Indirect communications (twitter property)
(C) Murray Turoff 2009
41
Data Object Types
For single variable, vector, or table
Administrator
Defines element, label, definition
Assigns it to contact
Only one who can fill it in
Always records date-time, author, and
indicated special status
Any contact can search directory
entries of all data types and
definitions
(C) Murray Turoff 2009
42
EMISARI Case tracking
 Case Template
 Steps in process of a case
 Actions at each step
 Who can take action
 What step is triggered by action
 Person responsible for next step notified
automatically
 Others notified of status changes
 Discussion thread attached to case
 Used for violations of wage price freeze
 Used for shortage violations (oil, natural gas,
chlorine, etc.)
 Originally design for tracking property disposal by
the federal government
 Defining templates (many laws governing process)
turned up some infinite cycles taking 5 to 10 years
 Emergencies need decision tracking software of
this type.
(C) Murray Turoff 2009
43
EMISARI Notebooks
Policies, Objectives, Laws, etc. and
needed Interpretations
News
Actions Taken
Limited Writers, many readers
Adaptive Index
Last 500 words searched
Last 500 words not found by frequency
requested
Indirect communication path to those
creating the information
(C) Murray Turoff 2009
44
Two interesting cases
 Cost of living council
 Meets once a week to make policy rulings
 List of not found words and their frequency supplied
to the staff to set agenda for meeting
 Notebook of interpretations used by people all over
the US to provide a basis for actions
 Lawyers that make interpretations of policy in
specific cases
 Refused to use EMISARI at start (used teletype
messages)
 Had same issue raised by different organizations
and interpretations made by different lawyers.
 Contradictions found by Washington Post and led to
them having to use the system
 Free access by those asking questions to all
questions and all interpretations
 News Stories
(C) Murray Turoff 2009
45
EMISARI Disruption Model
 Commerce Input-Output Model
 Thousands of classifications
 Interrupt sub sector in given locality by
strike or other disaster
 Calculate probable greatest impacts in rest
of country
 Examination and prediction of where
problems are going to happen in strikes,
shortages, disruptions
 Results available in about four hours
 Tape driven system at the time
(C) Murray Turoff 2009
46
Emergency communication
meta processes
Computer Augmentation
Regulation:
 Sequencing, iteration, synchronization,
participation, assignment, tracking
Facilitation:
 Organizing, summarizing, filtering,
exposing, integrating, indexing,
notifying, classifying, motivating
(C) Murray Turoff 2009
47
Group Communications
design concepts I
 Provide signals of a communication
process
 Stored notifications of actions by others or
by system
 Status of members of the group
 Content can be the address
 Who created or modified text or data and
when they did it is always tracked
 What a person has seen or not seen in
database is also always tracked
 Text can be program: active or adaptive
(C) Murray Turoff 2009
48
Group Communications
design concepts II
 Flexibility humans can use in other media
 Varied access privileges between members
and objects
 Human roles in the software
 Lateral two way linkages of material
 Do bookkeeping of communications for
user
 Improve group process by reduction of
process losses
 Relate qualitative and quantitative
information
(C) Murray Turoff 2009
49
Asynchronous opportunities
of Group Communications
 Independence of
 Individual problem solving
 Group problem solving
 Meta process & synchronization
 Backtracking
 Changing views
 Individual control
 Equal participation
 Mixed cognitive styles
 Bottom/up vs. Top/down
 Data vs. Abstraction
(C) Murray Turoff 2009
50
Goals of Group
Communications
 Collective intelligence
 Support for Human Roles
 Tailored communication and process
structures
 Integration with other communication
resources
 Self tailoring by users and groups
 Content as the address
 Design of a social system
 Communications as an interface (people
and resources)
 Asynchronous group problem solving
(C) Murray Turoff 2009
51
Smart Requirements for Emergency
Group Communications
 Determine what individuals are looking
for and not finding
 Guide individuals to those interested in
the same thing at the same time
 Piece relevant data together
 Alert individuals to anything falling in
the cracks
 Provide high confidence of a person
knowing they have the best information
possible at the moment
(C) Murray Turoff 2009
52
Social Needs of intense groups
Rely on one another
Trust the others to do their job
Frank and open viewpoints
Willingness to handover roles and
responsibilities
Creation of a team spirit
Needs to be encouraged through the
system design
Equal access to all by all, since we
cannot predict who might be
involved for a given situation
(C) Murray Turoff 2009
53
HCI Challenges I
 System is a helper not a boss
 System allows variable problem solving
methods
 Reduction of information overload
 Minimization of execution difficulty
 High degree of comprehension
 High degree of tailoring by individual
 Encourage creativity and improvisation
 Support decision confidence
 Monitor performance and effort for
possible fatigue
 Multimodal interfaces
(C) Murray Turoff 2009
54
Integration Requirements
 Fire, Police, Public Works
 Public Health, Hospitals, Clinics, Doctors
 Community resources (e.g. bulldozers,
contractors, boats, generators, etc.)
 Utilities, Contractors, Equipment
 State Agencies, National Guard, State
Police, Other local regional Governments
 Federal Agencies, Civil Defense, FEMA,
Homeland Security
 Non-Profits, Service Organizations,
Professionals, Community Groups
 Citizen volunteers
 Forms of communication
(C) Murray Turoff 2009
55
Superconnectivity
 Number of working communication
relationships multiplied by a factor of five
to ten
 Accurate and large group memories for
both data and lore
 Faster communication process than other
alternatives on the average
 Individuals get to know each other
without physical or status bias
 Tremendous efficiencies possible with
good design (beyond electronic mail)
(C) Murray Turoff 2009
56
Summary I
 An Emergency Response and Management System
is primarily a communication system.
 The only content about the application in a
communication system is that which is created by
the users.
 This requires the ability of users to create
templates for content tailored to the various types
of emergencies they must deal with.
 The source and time of information provided is a
key to information usage by users.
 Quick trust and Virtual dynamic groups/teams are
a key requirement.
 Responsibilities/accountability for current and
potential actions are necessary information
 Crisis require individuals replacing others with
respect to responsibilities as a crisis is a 24/7
occurrence.
(C) Murray Turoff 2009
57
Summary 2
 Relevance of data, information,
knowledge, and wisdom is time
dependent.
 The content of a communication can
determine the address, no other
communication system allows this.
 Indirect communications can be as
important or useful as direct
communications
 Dynamic Group Formulation needs to be
provided as a result of the above
 Need to minimize interruptions for people
involved
 Need to allow a high degree of user
tailoring for roles and associated events
(C) Murray Turoff 2009
58
DERMIS Conceptual Design
Dynamic Emergency Response
Management Information System
(The first layer of defense for the
public body)
(C) Murray Turoff 2009
59
DERMIS Objectives
 Easy to Learn
 High degree of tailoring by users
 Used by trained professionals
 Overcome problem of small screens (PDA)
 Virtual command and control center
 Support use of remote databases in an
integrated manner
 Support planning, evaluation, training,
updating, maintenance, and recovery, as
well as response
 Communication process independent of
content
(C) Murray Turoff 2009
60
Design Premises
 System Training and Simulation
 Information Focus
 Crisis Memory
 Exceptions as Norms
 Scope and Nature of Crisis
 Information Validity and Timeliness
 Free exchange of Information
 Coordination and Integration
(C) Murray Turoff 2009
61
General Design Principles and
Specifications
 System Directory
 Information Source and Timeliness
 Open Multi-directional communications
 Content as the address
 Link Relevant Information and Data
 Support psychological and social needs
(C) Murray Turoff 2009
62
Supporting Design
Considerations
 Associated systems
 Resource Databases
 Community Collaboration systems
 Online Communities of Experts
Important concept:
There is no specific data in DERMIS
system. Everything is created from
templates for the data types that are
defined so it can be tailored to any
locality or region. It is a communication
system just like a phone is. There can be
a library of templates to draw on.
(C) Murray Turoff 2009
63
Six Specific Interaction Design Criteria
Metaphors understood by
professionals
Human roles built in
Notifications integrated into
communications
Context visibility
Application Template is the menu
Choice tailored to role
Semantic Hypertext relationships
Two way linkages created
List processing at user level
Creation of lists tied to roles
Manipulation of items in a list
Eg expansion and contraction
(C) Murray Turoff 2009
64
Context Visibility Example
 Recipe
 Processing instructions
 Steps in the process
 Materials: pots, pans, utensils
 Ingredients
 Amounts, units
 Click on anything to get more information
 To get other menus
Example: ingredient Mayonnaise might bring up
recipe, types, properties, other recipes using it,
etc.
Anything returns a result that could be tailored
to the role of the person doing it.
(C) Murray Turoff 2009
65
Emergency Metaphor
 All emergencies have events
 Time logged and archived
 Serves dispatch function
 Used after emergency to understood what
took place
 Often separate events on different
systems for each agency involved
 Consider dynamic database of events
integrated across all agencies
(C) Murray Turoff 2009
66
Metaphors I
Log of Events
Root Event and Sub-events
Lateral Events
Each decision/action event
triggered by specified role or roles,
or other events
Observations/reports can also be
events
Event Template
A collection of events possible within
the context of a given root event
(C) Murray Turoff 2009
67
Events Associated with an
Ambulance
Request for an ambulance unit
Ambulance, driver, paramedic, medical
supplies, gas.
Response to request
Oversight negation
Road blockage or traffic jam
Lack of supplies
Lack of staff
Other demands for units
(C) Murray Turoff 2009
68
Metaphors II
Events delivered to specified
reactive roles for the event
Events delivered to roles that have
specified the need to track given
parent events
Event status is maintained
Events can be categorized and/or
marked by user
(C) Murray Turoff 2009
69
Metaphors III Resource Roles
 Requester: seeks to obtain resource
 Observer: Predicts need based upon
threat and observations
 Dispatcher/supplier: allocates it
 Oversight reviewer: Might negate it for
fair distribution based upon expectations
 Planner/Analyst: Predict consumption
rate and exhaustion potential of resource
 Maintainer: Insures readiness
 Seeker: Obtains new units of resources
 Distributor: Distribution to dispatchers
 Each type of resource can have the above
8 roles, a single site for use of the
resources may have a unique first 3 roles,
others depend on the nature of the
resource.
(C) Murray Turoff 2009
70
Properties of Roles
 Each role has its own event set it is concerned
with
 Clearly for a given situation roles must know of
actions by other roles
 If request cannot be honored the requester needs
to know how long a delay might be involved
 Each role focuses on a very specific responsibility
for the total task of getting something like an
ambulance sent
 Scope of the disaster influences resulting
complexity
 Roles in very different areas need to know what
each other is doing that affects them
 A mudslide or traffic stoppage on a certain road
may block resources to a given site and time to
correct, if possible, needed
(C) Murray Turoff 2009
71
Metaphors IV
Events have semantic links to all
relevant information and data
Forms for the collection of data
Resources of concern
Maps and Pictures
Appropriate command choices
Appropriate status options
Parent, children, and Lateral events
(C) Murray Turoff 2009
72
Event Log Metaphor
 Encourages the use of both the semantic
memory (relationship structure between
events) and the use of episodic memory
for the temporal sequence of occurrence
of events
 Aids in minimizing information overload
impacts and supporting cognitive
flexibility
 Each event becomes a dynamic
interaction menu – context visibility
 Events for a given role may be from a
variety of activities and from other roles
 Sending of resources needs knowledge of ways
of being sent and any blockage
 The computer can help to determine when a
role needs certain events
 When is the blockage to be cleared
(C) Murray Turoff 2009
73
Example: Resource Request
Event Template Status & Steps
 Resource Request (location, situation)
 Allocation (or deny, delay, partial allocation)
 In transit
 Arrival of resource
 Status change in resource
 Status change in situation
 Recycle action
 Resource maintenance, reassignment
 Return transit
 Tailored information
 Completion action
 Status report
(C) Murray Turoff 2009
74
Sample Event Types













Triggering/root events
Resource requests
Resource allocations
Information requests
Situation reports
Completion announcements
Status change
Warnings/Alerts
Leads/Speculations
Role changes
Interrupted events
Suspended events
Archived events
(C) Murray Turoff 2009
75
Individual Event Processing
 Profile of event types within specified
parameters like location
 Person has list of events of concern
 New events passing profile filter delivered
to list
 Add and remove events
 Mark events for tracking related events
 Events have hierarchy with a root event
and various layers
 May incorporate lateral events that are
needed
 May expand and contract list
(C) Murray Turoff 2009
76
Roles in DERMIS
Characterized by
Events the role can trigger
Required reactions to events
Responsibilities for






Actions, Decisions
Reporting of data
Assessing Information
Oversight, assessment
Resource maintenance
Reporting, Liaison
(C) Murray Turoff 2009
77
Fundamental Roles





Incident local site commander
Resource Requests (people or things)
Resource Allocation
Resource Maintenance
Resource Acquisition
 Finding needed resources (equipment, people)
 Reporting and updating situations
 Edit, organize, and summarize information
 Analysis of Situations
 Expected results, expenditure of resources
 Oversight, consulting, advising






 Negating allocations, alerting for running out
Alerting and scheduling
Assigning and scheduling roles and role changes
Coordination among different areas
Incident wide area commander
Priority and Strategy Setting
Liaison to other organizations
(C) Murray Turoff 2009
78
Privileges for Roles
Creating event log entries of a given
type
Templates to create new event types
or new resources or anything not
now specified in the system.
Responding to specific incidences of
events by type, situation, and
location
Supplying specific information or
data
Producing situational and
interpretive reports
(C) Murray Turoff 2009
79
Event Categories for Role
Filtering
 New/Waiting
 To do “asap”
 Action required
 Response required
 Information required
 Events with tasks for role







Informational
Priority change
Status change
Interrupted event
Suspended event
Finished event
Archived event
 Events tracked for interest/concern
(C) Murray Turoff 2009
80
Role Interaction Objectives
Facilitate
Handover of roles
Sharing of roles
Assignment of roles
Tracking
 Effort and time in role
Performance and errors
Alerting oversight roles
(C) Murray Turoff 2009
81
Notifications
 Minimal messages that contain the
essence of a communication.
 Canned so they can be reactive and
triggered by a click.
 Usually they become part of what they are
reacting to
 Queries that require a response
 Alerting individuals to something that
has occurred due to the actions of others
 Preformed statements like
 I agree, Good idea, I disagree, information X
needed, etc (what ever is wanted)
(C) Murray Turoff 2009
82
Canned Notifications
 I agree/disagree with it
 I am taking care of this
 Delay this action
 Give this a higher/lower priority
 Get us more details on this
 Good point/work/job
 Is there more
 Find related information
 Investigate this
(C) Murray Turoff 2009
83
Query / Fill In notification
Supply an estimate of the injured?
______________
We will have more information by
(time).
We will need (number) more of
(supply item).
Alert for delivery of more involved
forms needing processing
(C) Murray Turoff 2009
84
Context Visibility Example
 A single event can have the following
information with potential multiple links
for each
 Event log ID
 Resource type
 Responsible party or author
 Relevant location or locations
 Next expected event
 Role to take further action
 Status of event
 Situation report
 Lateral Events
 Footnotes, notifications, and comments
(C) Murray Turoff 2009
85
Resource Context Example Menu
 Clicking on a unit resource in an event
 could produce any of the following results
(depends on role that is clicking)
 Current status of the unit in this event
 Status of all units at location of this event
 Status of all units at desired source of resource
 Status of all available units
 Status of all in use units
 Status of all units
 Sources for new units
 These menu “links” dynamically updated
 Concept of general to specific with lateral
linkages at any level
(C) Murray Turoff 2009
86
Link Menu triggered by click on
Resource Type
 Defaults can be set by individual user role
 Dimension of very specific to very general
(examples)
 Status of the unit to be assigned or those which
are assigned (assigned)
 Status of all units in event area (involved)
 Status of all of units currently in assigned to
this emergency (total)
 Estimates of back up units (reserve)
 Other sources of resource
(C) Murray Turoff 2009
87
Nature of Hypertext Linkage
Two way linkages
Semantic meanings to all links
Multiple links from an anchor point
Collection of links becomes a
balloon menu for that anchor point
Links are dynamic
(C) Murray Turoff 2009
88
List Processing Properties
 Event log a very large dynamic list
 Template and incident relationships
 Many alternative orderings
 Internal network type indexing
 Collective view of reality
 Indirect communications, command, and
control
 Primary interface menu
 Communication bookkeeping on the
actions of others
(C) Murray Turoff 2009
89
List Processing Requirements
Tailoring by user roles and dynamic
groups
Expand and contract list
Mark and prioritize
Filter, organize, and reorder
Allow dynamic formation of groups
Alert to significant status changes
Indicate what you want to track
and what you can ignore
(C) Murray Turoff 2009
90
Communication Exercise I
(don’t do unless assigned)
 Simple Morphological Problem
















1. Police and law Enforcement
2. Firemen
3. Public Works
4. Public Health
5. Hospitals and Emergency Medical Services
6. Red Cross (temporary housing)
7. Utility Power Companies
8. Water and Sewage
9. Phone Companies
10. Transportation services (buses, trains, etc.)
11. National Guard
12. State Officials
13. Local Officials
14. Federal Officials
15. Press and the Public
16. Any thing you want to add
(C) Murray Turoff 2009
91
Communication Exercise II
 Assignment: What is a specific example
in any specific emergency where one of
the above 15 listed organizations has to
specifically communicate with one of the
others for any reason that will aid the
emergency management process. There
are n(n-1)/2 possible combinations or
14x15/2 = 105 examples. You are only
asked to come with 25 examples but try
to determine some that are not at all
obvious. Add a 15th if you come up with
another organization you want to
consider.
(C) Murray Turoff 2009
92
Communication Exercise III
 Be specific: (1 and 3) A rainfall has
caused a mud slide and the police, first
on the scene, must get the public works
department to clear the road that has
been blocked; (1 and 5) the police must
also notify hospitals that ambulances can
not use this roadway to reach casualties;
(1 and 13, 15) they must also notify the
public local administrators.
 Therefore, this one occurrence produces
four items.
(C) Murray Turoff 2009
93
DERMIS Directory Structure I
Directory
People





Background & Expertise
Group membership
Conference membership
Bulletin Board Editorship
Roles & Responsibilities
Event Creation
Current Active Events
Notifications
Resource Concerns
 Authorities
(C) Murray Turoff 2009
94
DERMIS Directory Structure II
 Directory
 Contacts
 Events
 Roles
 Groups (informal and formal)
 Conferences
 Bulletin Boards (e.g. policy, plans, etc.)
 Databases
 System Learning and help materials
 Training Materials and Games
 Related Systems
(C) Murray Turoff 2009
95
Design Principle I
System Directory provides a
hierarchical structure, with lateral
links, for all the current data and
information in the system
Complete text searching
Dynamic lateral link examples:
People in roles currently
People qualified for roles
People tracking a given root event to a
template
(C) Murray Turoff 2009
96
Design Principle 2
All information brought into the
system identified by source, time,
and links to related events
All actions (controlled events) taken
by roles also clearly logged and
tracked within the templates they
are linked to and identified by the
role and who had the role
(C) Murray Turoff 2009
97
Design Principle 3
Open communications to all
members of the system and all roles
Being able to start a discussion root
linked to any object of data or
information.
Paste communications anywhere in
the system including multiple
linkages
(C) Murray Turoff 2009
98
Design Principle 4
Links normally made by the system
based upon the relevance of the
data or information to current
events and roles
Links may also be made by specific
roles such as observers
We need subtle ways of keeping
roles aware of what is new and
relevant to them.
(C) Murray Turoff 2009
99
Design Principle 5
Dynamic update of information so
that the user does not have to
concern themselves with what is the
most current situation
Predictions of updates where ever
possible to let roles know if any
relevant information is eminent
(C) Murray Turoff 2009
100
Design Principle 6
Any two items maybe linked
semantically anywhere in the
system
Links are always two way
Links are typed and retrievable
Links have a date-time and source
as they are a data object
(C) Murray Turoff 2009
101
Design Principle 7
Authorities, responsibilities, and
accountability are all explicit
within the context of any role or set
of roles
The same holds for the definition of
events
Higher levels of authority are for
oversight over the lower levels
An action proceeds unless oversight is
executed in a timely manner
(C) Murray Turoff 2009
102
Design Principle 8
Encourage and support the
psychological and social needs of
any crisis response team
Facilitate quick trust and virtual
team spirit
Try to detect and deal with stress
and fatigue
Provide training for multiple role
taking on the fly (e.g. trainees can
observe the role in action)
(C) Murray Turoff 2009
103
Audit Objectives I
Foundations of Auditing
Theory of Inspired Confidence
 Limperg, Netherlands, 70 years ago
 Confidence of the public (citizens and
investors) in organizations
Sarbanes-Oxley Act of 2002
 Protect the interests of public investors
 SARBOX for short
(C) Murray Turoff 2009
104
Audit Objectives II
Audit Implications
Assurance of the Decision Process for
all financial/economic transactions
(not the decision)
Includes determination of VALUE and
RISKS (!!!)
Includes stewardship of the managers
and professionals
Assurance needs of society change over
time
(C) Murray Turoff 2009
105
Audit Questions
 Regular Decision Processes when there are
problems detected
What is the relevant data/information?
Who has the decision authority?
Who will make the decision?
How was authority delegated?
Who advises/consults on the decision?
Who/what is impacted by the decision?
Who needs to know about the decision?
Does everyone concerned have access to the relevant
data/information?
 Who supplies data/information?
 When must the decision be made?
 What is the expectation of additional
data/information and when?








(C) Murray Turoff 2009
106
ER decision making issues
 Complications added by Emergency
Response Decision Processes
 Dynamic delegation of Authority
 Fluid accountability/responsibility
 Dynamic formulation of group concerned with
decision
 Critical time constraints
 Interdependence of transactions/events
 Dynamic role changes
 Conflicts for resources
 Unpredictability of environment
(C) Murray Turoff 2009
107
Create an EPTrust
Emergency Preparedness Trust
Sets of controls to measure the current
degree of emergency Preparedness of
an organization
Natural extension of security and
recovery auditing
Can be developed now and applied to
organizations
A critical first step
(C) Murray Turoff 2009
108
Technology Changes I
Continuous Auditing
Continuous tests of controls
Continuous monitoring of all
organizational decision process
Continuous monitoring, capture,
reporting, and evaluation of data
Development of performance measures
(C) Murray Turoff 2009
109
Technology Change II
Organizational Process Design
Integration of the flow of
data/information across functional
domains
Making decision requirements explicit




Supply Chain Management
Customer Relationship Management
Virtual teams, Outsourcing
Enterprise/Strategic Resource Planning:
ERP, SRP, etc.
(C) Murray Turoff 2009
110
Observations I
 Emergency decisions require the same
assurance process as regular decisions
and then some!
 Technology is moving organizations in the
direction of enterprise wide systems and
ultimately to continuous auditing as well.
 Continuous auditing is the backbone for
any type of decision assurance process.
(C) Murray Turoff 2009
111
Observations II
 CA makes the integration of Emergency Response
Systems relatively easy
 Insures training and use by employees
 It would spread ER systems throughout the society
 It will reduce the costs of such systems
 Adding intelligent tools will be easier
 Confidence in making critical decisions will be
higher
 Stress will be reduced improvisation will be
enhanced
 Easier integration across organizations
(C) Murray Turoff 2009
112
Dangers of Computer Monitoring
of Decision Processes
 Computerization often leads to attempts to
simplify decisions so they can be modeled and
programmed.
 The approach needed is to leave complex
decisions and problem coping to the emergency
response managers and professionals
 Making roles of managers and professionals
explicit in the software and integrating that into
Virtual Team support Systems is a solution to this
problem if it includes:
 Tying of software supported roles to events defining
decision requirements
 Integration with the flow of data and information
(C) Murray Turoff 2009
113
Auxiliary Supporting Systems
 Resource Databases
 Organizational Memory & Collaborative
Knowledge Building Systems for
professional groups
 Virtual Communities
 Local Community participation,
collaboration, and involvement in
providing knowledge, person-power, and
equipment.
(C) Murray Turoff 2009
114
Some Key Research TOPICS in
ER
 Virtual Command and Control Centers
 Stimulating creativity or improvising
 On-line communities: Generate trust, social
networks, cohesiveness, and community
involvement
 Investigations of decision scenarios and possible
audit controls
 Decision Support Tools for all ER phases
 Multimodal & Multimedia Augmentation
 New Training Approaches
 Distributive System Integration
(C) Murray Turoff 2009
115
Key Independent Decision
Support Roles
Roles
Request resource
Take Actions
Allocate resource
Report relevant
data
Determining
implications
Acquire more
resources
Assign resources
Support Functions
Responsibility &
accountability
Specialized authorities
Gathering information
Analysis & oversight
Dynamic “planning” by
feedback!
Command authority
(C) Murray Turoff 2009
116
Planning with DERMIS
Dynamic Emergency Response
Management Information System
 Generating scenarios and evaluating
them as a collaborative exercise is quite
easy to do in ERMIS
 Addition need of voting and scaling aids
to allow determining disagreements and
focus discussion
 Generate new event types and roles to
deal with new risks
(C) Murray Turoff 2009
117
Training with DERMIS
 Easy to establish training exercises based upon
role-event structure
 Simulation driven by a sequence of timed events in
real time tied to the clock or can be speeded up
for some types of training
 Players can easily be simulated with respect to
actions and generated events
 Small teams can participate with a much larger
groups of simulated players
(C) Murray Turoff 2009
118
Evaluating with DERMIS
Examine log file of events and
actions by roles
Develop appropriate analysis tools
to aid this process
Discover and correct problems by
improving system and/or improving
training
(C) Murray Turoff 2009
119
Recovery with DERMIS
Can be used to direct and
coordinate the recovery activity
Can involve any diversity
organizations and agencies
involved
Provides a complete record and
accountability for the recovery
process
(C) Murray Turoff 2009
120
Summary on DERMIS
Can be used for all phases of the
emergency response process
Can be used for “little” emergencies
which are quite common in any type
of organizations
Can be used to support Online
Communities
(C) Murray Turoff 2009
121
Topics & Group Communications
Developed at NJIT on the EIES system
in the late 70’s
Electronic Information Exchange
System (EIES)
(C) Murray Turoff 2009
122
Topics: Unpredictable
information exchange
 Topic is limited sized inquiry
 Broadcast to all
 Selection of ones to track (receive
responses) by reader
 Limited response length
 Types of response: reference, answer, contact
 Data base of results
 Roles in software: Indexer, Briefer
(C) Murray Turoff 2009
123
Topics Example
 State Legislative Science Advisors
 Large groups (50-300)
 Each topic about 15 responses
 Sample topics in 3 weeks
 Computer crime laws, mining of bentonite, legal
definition of death, control of isobutynitrite,
hazardous waste survey, underground hv
transmission, licensing child care centers, child
abuse, prison industries, licensing of midwives,
salt brime disposal, cameras in court, junk foods
in schools, educational vouchers, definition of
antiques, generic drugs, methodone, migrant
education
(C) Murray Turoff 2009
124
Loss of Focus and Interruptions
Early studies of programmers
Interruptions cost complex problem
solving loss of setup time and think
time
Shown to be very significant
Also slow response of systems a
contributory factor
Putting programmers in open bays and
with lost of activity clearly detrimental
(C) Murray Turoff 2009
125
Serious Concern today about instant
messaging and cell phones in business
Help! I’ve lost my focus, Time
magazine, January 16, 2006, by
Stephanie Diani
CrazyBusy, Overstretched,
Overbooked and About to Snap:
Strategies for Coping in a World
Gone ADD by Edward Hallowell,
Ballantine books, 2006.
(C) Murray Turoff 2009
126
Concerns I
 An epidemic of “Attention Deficit
Disorder”
 High Cost of interruptions
 Study of 1,000 office hours found 2.1 hours a
day or 28% loss of the workday
 Employees devote an average to 11 minutes to
project before a ping of an e-mail or the ring of
phone interrupted
 Once interrupted an extra 25 minutes needed
to return to original task
 Average worker juggling about 12 projects
apiece
 Interruptions destroy setup goals
(C) Murray Turoff 2009
127
Concerns II
 Performance declines and stress rises
with the number of tasks juggled
 Most creative and productive people
refuse to subject their brains to excess
data streams
 Some multitasking can stimulate, too
much does the opposite
 Interruptions at the beginning or the end
of a task does the maximum damage
 Interruptions of the problem solving
planning process are considered the
worse
 Interruptions by email and cell phones
maybe addictive
(C) Murray Turoff 2009
128
Results for Emergency IS
 For problem solving we need to design
systems that allow the user to focus on
the tasks
 The system has integrate the work of
others in a manner that allows the user
to concentrate of their work and have the
benefit of what is really relevant to what
the user is doing at the moment
 Context visibility and hypertext as an
associative mechanism
 Event templates as an integration
mechanism
(C) Murray Turoff 2009
129
Not an easy road to take
 Roles in Disaster Cause Rift in City:
Despite Sept. 11, Fire Dept and Police
Lack Accord
 by William Bashbaum and Michelle O’Donnell,
New York Times, 4/3/2004, pages A1 & B4
 “More than two and a half years
later…the city still lacks what many
experts say is the most basic and
essential tool…a formal agreement
governing what city agency will lead the
response at the scene of any catastrophic
accident…”
(C) Murray Turoff 2009
130
Goals of Group
Communications
 Collective intelligence
 Support for Human Roles
 Tailored communication and process
structures
 Integration with other communication
resources
 Self tailoring by users and groups
 Content as the address
 Design of a social system
 Communications as an interface (people
and resources)
 Asynchronous group problem solving
 Information Overload reduction
(C) Murray Turoff 2009
131
The Future
 Smart planning, talented people, and well designed
adaptive communication / information networks
are needed
 Change and disruption is more common than we
think, even in commerce, and getting more
frequent
 The social system technology can be designed to
make dramatic improvements in ER
 However, does the organizational motivation and
understanding exist to do it?
 The issue is designing new virtual organizations and
communities that will change existing organizations
and the way things are done.
(C) Murray Turoff 2009
132
Quotes relevant to EM
The Information needed to understand the
problem depends upon one’s idea for solving
it. -- Rittel & Webber 1973
A Seer upon perceiving a flood should be the
first to climb a tree
– Kahlil Gibran
We, the willing, led by the incompetent to do
the impossible for the ungrateful, have done
so much for so long with so little, we are now
capable of doing practically anything with
nothing.
-- unofficial motto of emergency managers
(C) Murray Turoff 2009
133
The problem of KNOWLEDGE
(C) Murray Turoff 2009
134
The End of the First Set of Slides
(C) Murray Turoff 2009
135