SEPAM Master Project: Report

Flooding Calamity Control
Research on communication, coordination and

cooperation during a flood
SPM4910 – SEPAM Design

Project
Final Report
Faculty of TPM – TU Delft
Delft, June 9, 2006
Supervisors
Prof. dr. R.W. Wagenaar
Mr. A.J. Barendse
Mw.dr.ir. W. Blok
Dr. J.F.M. Koppenjan
ICT group
Thieme Hennis 1052381
Susan Lagerweij 1150243
Hidde Schipper 1024329
Sebastiaan Surie 1014617
Sebastiaan Tiemens 1102400
Preface
This report is put together as the main product of the SEPAM Design Project. It focuses on
ICT-related solutions addressing the lack of communication and need for inter-organizational
cooperation during calamities. Within this broad subject, the scope will be on the
communication, cooperation and coordination between relief services during water
calamities, and the possibilities to improve this through ICT. Attention does not solely go out
to technological aspects, it also considers institutional and process matters, for in multi-
disciplinary problem situations analysis regarding these aspects is indispensable.
In our analysis we were helped significantly by a number of persons. First of all many thanks
go out to Mr. R.W. Wagenaar for his insight in technical issues. For feedback and additions on
our preliminary report we would like to thank Mrs. W. Bockstael-Blok. Regarding institutional
matters gratitude goes out to Mr. A.J. Barendse and Mr. J.P.M. Groenewegen. Furthermore, we
would like to express our thanks to Mr. J.F.M. Koppenjan for the help on process issues.
Finally, we would like to thank Mr. J.H. Appelman for his assistance in the technical and
communication domain, and are grateful that he made it possible to experience a real life
calamity exercise, which was of great help.
We hope the report helps create the essential understanding of the technical, institutional,
and process issues that play an important role in information exchange during a water
calamity. The system designed in this paper should form the necessary step in water
calamity information management.
Thieme Hennis
Susanne Lagerweij
Hidde Schippers
Sebastiaan Surie
Sebastiaan Tiemens
SPM4910 – SEPAM Design Project (ICT) – Final Report 2

Index
Preface............................................................................................................. 2
Executive summary...........................................................................................6
1. Introduction................................................................................................ ...8
2. Problem analysis..........................................................................................10
2.1 Objectives............................................................................................ ........................11
2.1.1 Communication....................................................................................... ...............11
2.1.2 Coordination....................................................................................................... ....11
2.1.3 Cooperation............................................................................................................ 11
2.2 Paper structure....................................................................................................... ......12
Part I – Gaining insights in current water calamity control ................................13
3. Actor and Network Analysis..........................................................................14
3.1 Dedicated and non dedicated critical Actors......................................... .......................14
3.2 Calamity Plans............................................................................................................ ..15
3.2.1 Municipal- and District Calamity Plans....................................... ............................15
3.2.2 Operational Plans................................................................................... ................18
3.2.3 Calamity Relief Plans..................................................................................... .........20
3.3 Responsibilities and hierarchy........................................................................ ..............23
4. Technical analysis: the C2000 system............................................................24
4.1 Five ways to communicate........................................................................ ...................24
4.1.1 TETRA................................................................................................................. ....25
4.1.2 Equipment.......................................................................................................... ....25
4.1.3 C2000 from a user perspective........................................................ ......................26
4.1.4 Project progress....................................................................... ..............................26
4.2 SWOT analysis.......................................................................................................... ....27
5. Information streams and resources...............................................................28
5.1 Processes during a water calamity ............................................................. .................28
5.2 Main focus: the evacuation process.............................................. ...............................32
5.2.1 Analyzing relevant information .............................................. ...............................32
5.2.2 Draw up evacuation plan........................................................ ...............................33
5.2.3 Getting Personnel and Resources ready................................................. ................33
5.2.4 Use of Personnel and Resources....................................................................... ......33
5.2.5 Return people to their homes......................................................................... ........34
5.3 Other important processes................................................................................ ...........34
5.4 Current developments........................................................................................... .......34
5.4.1 FLIWAS................................................................................................ ...................34
6. Institutional situation...................................................................................36
6.1 Theories covering crisis situations.............................................................................. ..36
6.2 Theories covering the differences between governmental (emergency) organizations 36
6.2.1 Applying the four-layer model to the case......................................................... .....37
6.2.2 Highlighted problems resulting from the applied theory........................................38
7. Problem specification...................................................................................39
7.1 Sub researches....................................................................................................... ......39
7.1.1 Sub research 1 – Actor and network situation................................ ........................39
7.1.2 Sub research 2 – Current technical situation....................................... ...................40
7.1.3 Sub research 3 – Information situation..................................................... ..............40
7.1.4 Sub research 4 – Institutional situation..................................... .............................42
7.2 Reflection................................................................................................ .....................43
8. Design Proposal...........................................................................................44
8.1 Technological design aspects............................................................. ..........................44
8.2 Institutional design aspects................................................................................... .......44
8.3 Process design aspects................................................................. ...............................45
8.4 Program of requirements.......................................................................................... ....45

8.4.1 Classes of requirements........................................................................... ..............45
8.4.2 Methodology............................................................................... ...........................45
8.4.3 List of requirements........................................................................ .......................46
Part II – Designing the Web GMS......................................................................49
9. Process design.............................................................................................50
9.1 Actors.............................................................................................................. ............50
9.2 Process design............................................................................ ................................50
9.3 Round 1; Generic process rules................................................................... ................51
9.4 Round 2; Requirements.............................................................................. ..................53
9.5 Round 3; Design issues..................................................................... ...........................55
9.6 Round 4; Costs and responsibilities............................................................... ...............59
9.7 Round 5; start project............................................................................................. ......62
9.8 Process design reflection.................................................................................... .........62
10. Technical Design......................................................................................... 63
10.1 Current situation GMS....................................................................... .........................63
10.1.1 Problems arising due to the centralized nature of GMS .......................................64
10.1.2 Necessary technical modifications................................................ .......................65
10.1.3 Method proposal: Service Oriented Architecture..................................................65
10.2 Service-Oriented Paradigm...................................................................................... ...66
10.2.1 Actor dimension............................................................................ .......................66
10.2.2 Service layer dimension..................................................................... ..................67
10.2.3 Service functionalities dimension.............................................................. ...........71
10.3 Proposed technical design: the WebGMS............................................................ .......71
10.3.1 Improvements....................................................................................... ...............72
10.3.2 User interaction................................................................................................. ...74
10.4 Interface.............................................................................................................. .......76
11. Institutional design....................................................................................78
11.1 Theory on institutional design.................................................................. ..................78
11.1.1 Design principles........................................................................................... .......78
11.1.2 Implementation challenges in institutional design...............................................78
11.2 Institutional arrangements...................................................................... ...................79
11.2.1 Compatibility with other systems.......................................................... ...............79
11.2.2 Standards and Semantics................................................................................. ....80
11.2.3 External systems and security................................................ .............................80
11.2.4 Responsibilities and authorization............................................................. ...........81
11.2.5 Costs and responsibilities........................................................................... ..........83
12. Conclusions and Recommendations.............................................................86
References.....................................................................................................87
Books....................................................................................................... .........................87
Papers and articles............................................................................................... .............87
Websites......................................................................................................................... ...88
Governmental documents................................................................................. ................89
Appendices.....................................................................................................91
Appendix I - Goal oriented analysis..................................................................91
Appendix II - Actor analysis.............................................................................92
II.1 Inventory of the actors............................................................................ ....................92
II.2 Actor analysis ............................................................................................. ................93
II.3 Dependency analysis................................................................................................ .102
II.4 Corresponding and contrasting problem perceptions, interests and goals................104
Appendix III – Operational plans.....................................................................105
Appendix V – Organisational structure............................................................106
Appendix VI - SWOT analysis.........................................................................107
Appendix VII – Processes during a water calamity...........................................109
VII.1 Monitoring............................................................................................... ................109
VII.2 Scale up....................................................................................... ...........................109

VII.3 Evacuate.......................................................................................... .......................110
VII.4 Flood............................................................................................... ........................110
VII.5 Take care of damage...................................................................... .........................110
Appendix VIII – Evacuation processes.............................................................111
Appendix IX – Information systems.................................................................120
IX.1 Information about FLIWAS....................................................................... .................120
IX.2 Information about Infraweb.......................................................................... ............121
Appendix X – Group Decision Room session report..........................................122
Appendix XI - design issues...........................................................................127
XI.1 General design issues.................................................................... ..........................127
12.1 XI.2 Costs design issues........................................................................ ...................128
XI.3 Defining actor groups...................................................................................... .........129
XI.4 Overview of the process design................................................. ..............................129
Appendix XII – Technical design......................................................................130
Appendix XIII - Division of costs.....................................................................134
Appendix XIV - Institutional design WebGMS..................................................135
Appendix XV - Additions on the GMS template for the used interface...............137

Executive summary
Various exercises on flooding calamity control pointed out that there the level of efficient
cooperation and coordination is alarmingly low. These exercises showed various interaction
problems between and within stakeholders, causing inefficiency and lack of control during
calamities. Outdated or even wrong information, slow and insufficient communication, and
little or no cooperation and coordination between actors are elements that can cause the
impact large water calamities to be disastrous.
Flood calamities require a highly multidisciplinary approach, with an enormous amount of

information being communicated between actors involved in water calamity control. Control
on this is very difficult, and more than often relief assistance fails on this point. With new
ICT-technologies the controlling of relief services, the cooperation between them, and the
vertical and horizontal communication, can be, and has to be improved. The control on flood
calamities situates itself in the domains of many different actors, with each their own
responsibilities, their own goals, ways of working, culture, influences and relations,
knowledge, and importance. Numerous documents describe the scripts on how to act, the
rules to follow, and the responsibilities to guard, which sometimes results in redundancy, no
actions being undertaken, bad resource management, and slowness.
The new communication network for relief services, C2000, has just become operational in
combination with a collective alarm system (GMS). C2000 has created a communication
infrastructure for all actors involved in water calamity control to work on. However, there still
is no efficient information management system to ensure coordination and cooperation on
this infrastructure. In the past few years programs have been developed to improve this. An
example of this is the FLIWAS program, which is especially designed for water calamities,
and helps develop solutions for resource management, evacuation plans, information plans,
and more. The void in this picture, and also the goal of this project, lays in the connection
between C2000 and relief assisting programs, such as FLIWAS.
A technical design on itself will not be enough to solve the mentioned problems, because of
the strong dependency on institutional factors and the broad range of actors involved in
water calamity control. Thus, it is essential that the technical design is implemented in
combination with a process- and institutional design in order to create a broad social basis.
The combination of analyses on the different stakeholders, technical aspects, information

streams, and the current institutional situation has led to the formulation of a series of
requirements. These requirements have formed the input for the new systems design.
Before the new system can be designed, it is necessary to set a number of process rules, to
create a certain level of commitment to all the actors involved. The process design deals
with these issues.
The proposed technical system, called the WebGMS, is based on the introduction of an extra
layer in the system for the emergency rooms (the GMS). This web-based system makes it
possible to digitalize several information streams that do not need human interference.
Examples of such information streams are weather reports, GIS maps, and emergency plans.
Another advantage of WebGMS is that makes both push- and pull-based information
possible; i.e. the relief worker can directly request (personalized) digital information from
information systems connected to WebGMS. A last advantage of WebGMS is that it relieves
the emergency rooms of a considerable amount of information demand and -load, for
currently most communication in the GMS takes place through voice, which can be
particularly slow and inefficient.

Finally, the institutional design makes an attempt to fill in the gap between the process- and
the technical design. Several institutional arrangements have been drawn up with regard to
compatibility with other systems, standards and semantics, external systems and security,
responsibilities and authorization, costs and responsibilities, and designer’s choice. The
latter has brought in a breakthrough in information management; the introduction of
calamity specific templates. This implies that the emergency room sends all relief workers a
specific template, adapted to the stage the calamity is in. This clearly demarcates the
amount of information a relief worker can acquire digitally and offers the emergency room
the opportunity to remain in control. Moreover, such templates create opportunities to
extend the application of WebGMS to other calamities, even on an international level.
Most of the identified problems are solved by implementing WebGMS. Although WebGMS
covers most of the technical problems and can be seen as a technical optimal solution, it
must be said that some institutional problems arose. In order to cope with these institutional
problems in the future some recommendations are made. When the Ministry of BZK and the
regions start with the implementation of WebGMS, they should consider taking the following
recommendations into account:
- The Web GMS should be coupled to the existing Fliwas system

- The Web GMS could form the basis for a general calamity control and information system
- The Web GMS could be coupled to international systems
- BZK should set up a central database on semantics

- BZK should secure cooperation, coordination and communication among the relief
services
- Security issues should be subject of a follow-up research

- Once the system is implemented a second cost calculation should be executed

1. Introduction
On the 6th of April 2005, the Bonfire crisis control exercise took place on different locations
in the Netherlands. Bonfire was a special happening as it proceeded on certain issues much
further than regular exercises had done until then. The exercise covered all involved
authorities and institutions, which are involved in case of a real calamity situation. The
purpose of this exercise was to train the decision making process in the full operational and
governmental line in case of a terrorist impact on a soft target in the Netherlands (Project
team ‘Borging Leerervaringen’ Bonfire, 2006). The exercise turned out to be a complete
chaos and the levels of communication, coordination and cooperation were unacceptable.
Strikingly, the authors of this paper encountered similar problems while participating in the
Helga flood calamity exercise (May, 2006). Reflecting on these exercises and various critical
evaluation reports (NRC, 2005b and Project team ‘Borging Leerervaringen’ Bonfire, 2006), it
is understandable that both ministries of Transport, Public Works and Water Management
(from now on VWS) and of Interior and Kingdom relations (from now on BZK) are questioning
the impact of a large scale calamity.
In this paper, one specific type of calamities will be treated, namely water calamities.
Although the nature of terrorist attacks obviously is quite different from water calamities, in
both cases it concerns an impact on a large scale in which a large amount of the same
actors are involved. In the Netherlands, protection against floods of the rivers running
throughout the country has always been an important issue. There are plans to widen the
riverbeds of these rivers, including the Rijn and the Maas, in the upcoming years, with the
objective to establish a safer situation. The town-planning decisions in “Ruimte voor de
Rivier en de Maaswerken” form the fundament for this decision (Kabinet, 2005).
Nevertheless, the risk of a flood should always be taken into account. Nature is capricious
and therefore an accurate prediction of the water level for over a longer period is rather
difficult. Consequently, the government of the Netherlands has recently expressed her
intentions to determine a strategy for risk control during floods of rivers, in addition to the
existing protection measures. Accordingly, the cabinet has ordered to analyze different
measures based on so-called Calamity Flooding Areas (Noodoverloopgebieden) and land
compartments, along with possible improvements by taking measures of foreign countries
into account. Moreover, there is a need for a high standard concentrating on risk control
organizations and higher safety standards (Directoraat Generaal Water, 2005).
The Ministry of VWS carries the end responsibility over the protection of the Netherlands
against possible flooding and therefore proactively performs research into flooding
possibilities and prevention (Ministry of VWS, 2006). However, in case of a flood, the Ministry
of BZK is responsible for the coordination, supervision and providence of a situation in which
emergency or relief services can perform in an optimal way (Ministry of BZK, 2006). In case
of a possible flood in the Netherlands, these two ministries are thus very dependent and
interrelated with each other.
The above makes clear that the organization of the involved authorities and institutions
during a water calamity is very complex. Moreover, the existing strategies for calamity
control seem to be far from optimal. Maintaining sufficient overview in such complex
calamity situations has thus become considerably problematic. It seems that adequate
solutions can be found through ICT support. Although many ICT systems are already active
or currently being developed, the experiences described above have pointed out that there
is a need for a doming ICT system that ensures the required overview and provides
possibilities for systems integration. The objective of this paper is to design an ICT model
that meets this need and makes calamity control in water flooding more effective and
efficient. This will be done by executing a substantial analysis on all technical-, institutional-
and process aspects that characterize a water calamity, identifying functional requirements
of such a system, and incorporating these findings in a new covering systems design.

2. Problem analysis
In the organization of calamity control, three topics stand central, namely communication,
coordination and cooperation between the parties involved. The actor which stands central
in this research is the ministry of BZK, who carries the end responsibility in calamity control.
The ministry has recently performed a research on the status of calamity control
preparation, and the conclusions are quite alarming. The main conclusion states that new
organizational measures are necessary to protect the risk of floods in situations with over-
normative drainage. These measures vary from a more clear structuring and demarcation of
responsibilities to the improvement of several essential processes during calamity control
(De organisatorische voorbereiding op overstromingen van Rijn en Maas, 2005). To give
more insight into these conclusions, a three layer ICT model has been designed as exposed
in Figure 1.
cooperation I (Information)
coordination I (Information)
communication C (Communication)
Figure 1 – The three layer ICT model (developed in cooperation with Prof. R. Wagenaar,
2006)
The “C” aspect in the figure indicates the communication part, which among others is
supported by a technical component, filled in by the C2000 communication system (which
will be discussed in chapter 4). The “I” is the abbreviation for information and consists of
coordination of the information among involved parties and the lead up to cooperation
between these parties by means of that information. This indicates that the information
provision is a fundamental function of the communication level. In this context, coordination
concerns the way the information is communicated, what the contents are, to whom it is
directed and in which form it is communicated. Cooperation indicates how the information is
processed and how this leads to certain decisions and actions of the different involved
parties.
Specifying the situation in case of a water calamity will provide the information necessary to
fill in the designed three layer ICT model. Taking the conclusions of Bonfire and several
evaluation reports into account, it is to be assumed that problems will arise during a water
calamity. The three layer ICT model can indicate where gaps or niches exist and where
problems and weaknesses occur in the merging of communication, coordination and
cooperation. Accordingly, a broad and general problem definition has been determined,
which will provide the fundament of the research that will be performed in this paper:
“In case of a water calamity, how can the present problems with regard to communication,
coordination and cooperation between the different parties involved be solved through the
support of ICT?”
In order to provide a sound answer to the above question a division into sub questions has
been made. Subsequently, these sub questions has been ordered in sub researches. An
overview of this is given in the table below.

Table 1 - Overview of sub researches.
Sub research Questions
1. Actor and Network -Which actors are involved?
situation -What is the role of each actor?
-What are the responsibilities of each actor?
-How are the actors hierarchically structured?
-Are there any calamity plans, scripts, or guidelines?
2. Current technical -What is the current technical status of the communication
situation system?
-Does the used technology create a bottleneck in the
communication process?
3. Information situation -What information resources can be identified?
-Which information is important to whom?
-Which information streams can be identified?
4. Institutional situation -What institutional arrangements are valid concentrating on
standards and protocols?
-How are the institutional arrangements of different actors
connected?
-Are there any conflicts among the institutional levels?
-Do the institutional arrangements provide the possibility of
control?
Answering these sub questions will help to specify the goal and focus of this report. To obtain
a good foundation for the goal and focus of the analysis, the objectives of the problem
owner, the ministry of BZK, should be identified. These objectives will therefore be treated
next paragraph.
2.1 Objectives
To get insight in the objectives of the ministry of BZK, a goal oriented analysis has been
performed. For this analysis, all objectives of the ministry have been identified and
hierarchically structured. The analysis considers the objectives of the ministry of BZK during
a water calamity. The complete results can be found in Appendix 1; the most relevant
objectives will be discussed below.
For this research the central objective that requires further analysis is repression of a
calamity. To realize this objective, the objectives on the lowest level of the model in
Appendix 1 need to be reached. To keep a clear overview, these bottom level objectives will
be shortly discussed in accordance with the three layer ICT model topics.
2.1.1 Communication
Good communication can be obtained by a high level of technical performance on the one
hand, and maximum approachability of the relief workers on the other. Obviously, a
thorough understanding of the underlying communication system (C2000) is needed for this.
Features that need to be analyzed here are coverage, availability, number of calls, etc.
2.1.2 Coordination
For coordinating the process of calamity control, it is of utmost importance that the different
parties involved are able to reach and moreover understand each other. In other words, all
information streams, -types, and -semantics need to be tuned towards each other. All parties
involved will have to reach a consensus on how information is stored and mutually
exchanged. Identification and further research of these actors will thus be essential.
2.1.3 Cooperation
The last aspect of the ICT three-layer-model can only be achieved if the other two are well
defined. To reach a good level of cooperation differences in cultures, norms and values of the

different parties involved should be taken into account. Another, and maybe the most
important requirement of all, is to get the whole system to take the same attitude and
orientation in calamity control. All parties must really be willing to reach mutual agreements
and work together in an effective and efficient way.
2.2 Paper structure

The research in this paper will elaborate on the three layer ICT model. The previous section
has made clear what the further research areas within this model are. The research structure
will thus be executed as follows.
The paper will consist of two parts. Part I will concern the analysis on all sub researches as
described in table 1. The objective of this part is to provide a complete overview of the
different design aspects of the system to be developed. In chapter 3, an Actor and Network
analysis will treat the involved actors, their interrelations, dependencies and responsibilities
during a flood and will indicate what is known about information streams between the
involved parties. The technical communication system, C2000, will undergo a more in depth
analysis in chapter 4. Subsequently, In Chapter 5, the particular information streams and
-allocation will be analysed, followed by the application of theory regarding the institutional
situation (chapter 6). With the conclusions of these analyses, which are drawn up in the
problem specification (chapter 7), an attempt will be made to identify all functional
requirements of the ICT system to be designed. Finally a system design proposal will be
worked out in chapter 8.
In Part II, the requirements and design aspects identified in Part I will be translated into a
system design. In chapter 9, the conditions to effectively and efficiently be develop the
system will be identified through the process design. Then, the technical design will be
drawn up in chapter 10, providing the structure, characteristics and specific features of the
new ICT system. The institutional challenges will be taken into account in chapter 11, to
create a broad social basis for the systems design. Lastly, an overview of conclusions and
recommendations will be given in chapter 12.

Part I – Gaining insights in current water
calamity control

3. Actor and Network Analysis
In this chapter, an actor analysis will be carried out, to make clear who the ministry of BZK
should take into account. The objective of this analysis is to clarify how involved parties will
act and what their interests are during a water calamity. In Appendix II.1, all actors relevant
to a calamity scenario are listed. As could be expected, the number of actors is very high.
Therefore, it is important to make a selection out of the actors that are critical for calamity
relief, which will result in a focus on governmental organisations instead of socials and
private organisations. The results of this selection can be found in Appendix II.2. In this
chapter, a more in depth analysis will be done on these results.
3.1 Dedicated and non dedicated critical Actors

The actors who are most relevant for the analysis are the ones that are critical to the
problem area. The reason for this is that these actors will play a central role during a
calamity and can not be left out in the design process. In this section, it will be determined
which actors play a crucial role in calamity control and should thus be taken into account by
the problem owner, the ministry of BZK, in the development of a new ICT system. To achieve
this, the attitudes, resources and degree of influence of these actors will need a further
analysis. The dedicated and non-dedicated and critical actors identified in Appendix II.3 and
II.4 are listed below:
Government Institutions
- Ministry of VWS
- Provinces
- District Water Boards
- Municipalities
Relief services
- Police Department
- First Aid Services
- Fire Department
It immediately catches the eye that these seven actors can be divided into two covering
groups, namely Government Institutions on the one hand and Relief Services on the other.
Government Institutions (Ministry of VWS, Provinces, District Water Boards and
Municipalities) play a role in the policy and decision making process. This means that,
among others, they will have to decide on responsibilities, ensure an effective and efficient
information flow, and manage and coordinate teams in the field. One could say that the
main objective of these bodies is managing coordination and cooperation. The Ministry of
VWS is currently positioned as a non dedicated actor. This implicates that its policy is not
actively aimed at calamity relief. However, its participation is critical for the ministry of BZK,
for they form an important connection with other organizations that are involved in a
calamity. Therefore, it is of importance that this actor is well informed and can be counted
upon at all times.
Relief Services (Police Department, First Aid Services and Fire Department) are the actors
actually active and present at the location of the calamity; they will have to execute the
policy drawn up by the Government Institutions. Obviously, communication within and
between the Relief Services plays a central role. After having received information on the
calamity, they will have to act and communicate with each other in order to do their job.
It now becomes clear that the three layer ICT model, described in chapter 2, is directly
related to the dedicated and critical actors. The division in roles described above makes
clear that the governmental organisations execute tasks on the cooperation (decision

making) and coordination level, the communication and coordination level are more
important for relief services.
But how do the different bodies cooperate, coordinate and communicate? And in what way
should the ministry of BZK position itself to adequately deal with them? Although the
particular roles are now mapped out, this question can still not easily be answered, but
remains important to get a complete overview of the actor network. Therefore, the
preceding analysis will be compared with the calamity plans that have been drawn up by
these actors.
3.2 Calamity Plans

Calamity plans are hierarchically structured, according to the scope they cover. An overview
of the different types of calamity plans can be found in Figure 2. The bottom layer represents
the municipal- and district Calamity Plans; describing structures of organization,
management, coordination, tasks and responsibilities. The second layer focuses on the
Operational Plan, the communal databank for relief services with information on assistance,
logistics, demography, risk inventory, procedures, etc. The third layer contains the Calamity
Relief Plans, meant to prepare for specific risk objects and activities and coordination plans
for treating specific incidents. The last layer is formed by cooperation agreements, aimed at
realizing an effective coordination and execution of calamity relief. In the sections below,
these layers will be further analyzed.
Other Cooperation Arrangements
Calamity Relief Plan
Operational Plan
Municipal - and District Calamity Plans
Figure 2 – House of plans existing in the Netherlands (Handboek Voorbereiding

Rampenbestrijding, 2002).
3.2.1 Municipal- and District Calamity Plans

The Dutch law obligates all municipalities to draw up a calamity plan every four years. As
mentioned above, a calamity plan contains an overview of the risks that are present within a
municipality. This indicates that these calamity plans should also be applied during a water
calamity. However, as municipalities often lack sufficient knowledge about waterworks, close
cooperation is needed with the local water district board(s).
In the Netherlands, 27 district water boards (Waterschappen) have been established. These
bodies are decentralised governments, carrying the responsibility for all public works
departments within the country. Every district water board has drawn up its own District
Calamity Plan. These plans describe the responsibilities and information flows during a water
calamity. In this section, a broad outline will be given of these District Calamity Plans

(Calamity Plans used for research: Waterschap Zuiderzeeland, 2005; Waterschap Zeeuwse
Eilanden, 2004 and Waterschap Groot Salland, 2002).
It is important that a water board’s District Calamity Plan is geared to calamity plans of other
organizations, including those of municipalities and provinces. To achieve this, several
arrangements have been drawn up in the Dutch legislation (Waterstaatswet, 1900).
Responsibilities
The overall responsibility for coordination during a calamity is assigned to the Dijkgraaf, as
fixed in Article 96 of the law for Water Boards. He also holds the end responsibility. However,
in case of an escalation, certain responsibilities can be assigned to the mayor. If this occurs,
the Calamity Law comes into force. It is to be expected that several communities or even
provinces will be involved in larger calamities. The responsibilities are distributed depending
on the magnitude of the calamity.
• The Dijkgraaf has the command over the Communal Policy Team. Furthermore, he will
determine the informing policy, being responsible for the contact with the communities
and province(s). He may change the constitution of this team permanently or ad-hoc.
The centre of command will be located in a specially assigned Calamity Room
• In case of the enforcement of the Calamity Law, the mayor will instruct and coordinate
the Calamity Policy Team and the Management Team. If several communities are
affected, all mayors will assign a coordinating mayor. The Royal Commissioner may bring
out advice.
• The province has a coordinating task. The Royal Commissioner is supported by the
province’s calamity staff and the Provincial Coordination Centre (PCC). He may request
the Dijkgraaf to adjourn to province staff meetings.
• A community or province can request for military aid. This may only occur after Royal
Consent.
• In case of involvement of more than one province, the Minister of the Interior will be
assigned the coordinating role, supported by the National Coordination Centre (NCC).
Regardless of a calamity being qualified under the Water Board Law or the Calamity Law, the
district water board always maintains the power to act. The Dijkgraaf is strongly advised to
only do this if consultation with other bodies is impossible. Apart from that, he will be
obliged to justify these self made decisions afterwards. Central in the decision making
process stands an effective and an efficient cooperation between the bodies involved. In
case of a dispute, the mayor in command has the decisive vote.
The scheme of the calamity organization has been drawn up in the form of a three layer
structure. Every layer involves a team with specific tasks, shortly treated below:
• Calamity Policy Team
This team has the responsibility for internal and external coordination of all Water District
Board actions, as well as the communication to the media. Furthermore, the team should
document all data. The team is constituted of the Dijkgraaf (Chairman), the Calamity
Coordinator, a secretary, a secretary assistant, the heads of sectors, an instructor, and
an IT expert. The IT Expert is responsible for all information and communication (ICT)
flows. He will advise on telecommunication connections and ensure the continuity of ICT
support.
• Operational Team
The involved head of sector is the Operational Team Leader (LOT). All activities executed
by the Operational Team are coordinated by the Calamity Policy Team. The LOT manages
and guards this process. He is also responsible for bringing out situational reports to the
Calamity Policy Team. Other team members are: the involved department chiefs, the

involved functionary of Supervision and Maintenance, an Instructor, an IT expert, and
possibly a secretary assistant. The team instructs all Action Teams, steering and
coordinating source- and effect control. Another task of this team is bringing out
technical advice to Action Teams and the Calamity Policy Team.

• Action Team
An Action Team consists of one or more district supervisors. Often there are several
Action Teams established during a large scale calamity. In case of events within one
sector, the functionary of Supervision and Maintenance will be the coordinator of the
action team (CAT). If more sectors are involved, a CAT will be assigned by a supervising
echelon. The CAT and his team are charged with the source- and effect control, as
determined by the Operational Team and/or Calamity Policy Team. Furthermore the CAT
is responsible for the communication with relief services. Finally, the CAT will report the
situation to the Operational Team and/or Calamity Policy Team.
It is essential that every body sticks to its own tasks during a calamity. If this is not the case,
some activities won’t be fulfilled and others will be done twice. A number of conditions
should be met to guarantee this:
• There should be a transparent structure of the calamity organisation and a clear fencing
of tasks
• An optimal cooperation and coordination between the different bodies of the calamity
organisation
• An optimal cooperation and coordination between the calamity organisation and all
external organisations involved in fighting the calamity
• An optimal supply of information for everyone affected by the calamity and/or the
calamity relief.
3.2.2 Operational Plans

The existence of several Municipal- and District Calamity Plans and the desired combination
with the calamity relief plans, gives rise to the need of a coordinating databank. The
databank should be linking these plans, or put them together, and giving aid in a smooth
cooperation between them. This is established in an Operational Plan (OP), which actually
concerns a covering of the earlier mentioned plans. The OP is thus meant to offer support
and can bring aid in making quick decisions. The ministry of BZK formulated guidelines in
order to standardise the form of all these local OPs. Those guidelines resulted in two
different manuals. The first manual is the Leidraad Maatramp (LMR) which concentrates on
the regional preparations considering calamity control (LMR, 2001). The LMR provides an
unambiguous and broad accepted systematic method for indicating the dimension and
effects of the most important calamities which can occur within a region and the expected
corresponding need for relief or aid in that case. The most important calamities are
elaborated and hence include the calamity of a possible flood.
LMR LOP
Relief /
Source / Need for Need for
Effect Support End / Result
Cause Relief / Aid Application
Processes
Figure 3 – The content of the two manuals provided by the Ministry of BZK (LOP, 2001)
The second manual, the Leidraad Operationele Prestaties (LOP) is an extension of the LMR,
as shown in Figure 3, which concentrates more on the operational part of calamity control.
On the basis of the LOP, the region can convert the need for relief into the desired capacity
or need for application within a certain period of time and which ultimately results in the
deployment of the actual relief and support processes. The need and actual capacity
considering the calamity region are expressed in numbers and divided into five groups: fire
department, police, medical assistance, local government and members of multidisciplinary
teams. Each group contains executive and coordinating functions on both operational and

management level. By comparing the need and actual capacity within a region, or with the
support of nearby regions, the manual provides a clear view on the potential bottlenecks
and deficiencies. Because of the detailed and operational profundity the LOP primarily
focuses on operational planning and imaging as well as training the managers of the
different actors involved in a calamity.
With both manuals, mainly technical exercises can be executed. Information concerning the
local and regional situation can be coupled to the information and methods provided by the
LMR and LOP documents. Based on the outcomes of the mentioned exercises it is possible to
decide on the desired policy and measure the performance of the current policy. As
mentioned in the LOP (Save and Van Dijke, 2001) the manual may not be seen as an
organisational plan or script and neither can provide an instruction package for calamity
relief. Furthermore, the LOP does not intend to appoint responsibilities. Although these
responsibilities should be clear and the existence of scripts and organisational plan is a fact.
The LOP solely provides suggestions for operational targets which should be achieved in
case of a calamity.
As for the other seventeen calamities defined in the LMR, in case of a water calamity the
need for relief or aid is specified in detail. Considering this need, the LMR distinguishes five
different sizes of calamities, which are numbered by Latin numbers I up to V. As illustrated in
Figure 4 the size of each calamity can vary. The numbers denote the impact of the calamity
and therefore indicate the importance of preparation for the different levels. With regard to
the mentioned preparation, it is of mayor concern that the expected need for relief or aid is
made concrete, in order to determine the appeal to the relief services in case of a flood.
Indication Car accident

of the (# car’s)
calamity
size Forrest fire
(# m2)
Flood
(# households)
Calamity type X
(# concerned)
Fire
Size of the department
need for
Police
relief or
aid / Local
process government
Medical
(not operational) Multi-
disciplinairy
Figure 4 – Operational needs considering a certain size of calamity (LOP, 2001)
The need for relief or aid is divided into five main processes, which are also illustrated in
Figure 4. These processes distinguish four monodisciplinary, namely the fire department,
police, medical aid and remaining (non-operational) services provided by the local

government and a multidisciplinary process. Each calamity requires a different mix of these
processes, again five dimensions are distinguished.
As can be concluded from Figure 4, the most important process during a flood is the
multidisciplinary process. The process among others holds the earlier mentioned ‘municipal-
and district calamity plans’ and combines these plans with the ‘calamity relief plans’
adopted by the relief services (Fire department, police department and first aid services).
The combination of these plans implies that the level and performance of cooperation
among all concerned actors is highly important. Accordingly, the importance of cooperation,
coordination and communication during a flood can be deduced from the LOP. Actually,
comparison with other calamities shows that these three factors are more important during
a flood than any other calamity described in the LMR.
With the importance of a fluent connection or combination of the ‘municipal- and district
calamity plans’ and ‘calamity relief plans’ clear, an extensive insight considering the
calamity relief plan is desired.
3.2.3 Calamity Relief Plans

The Municipal and District Calamity Plans are general plans which guide decisions, while a
Calamity Relief Plan more accurately describes the responsibilities of the different relief
services during a calamity. There is no formal national Calamity Relief Plan. However, several
regions within the Netherlands have drawn up models of Calamity Relief Plans based on the
recommendations provided by the LOP. Therefore, most of these models have been
subjected to a more in depth analysis, as to clarify and map out the operational, and to
lesser extend organisational, needs of the relief services during a calamity. The result of
such a standard map is provided by the LMR and an extensive and concrete overview is
reproduced in Appendix III.
Besides these needs, some general requirements which all relief services should suffice are
formulated. Assumptions considering these important requirements are given by the LOP
(LOP, 2001) and hold that following aspects, concentrating on policy and coordination, are
accurately taken into account:
- Adequate level of competence

- Authorisation of competence
- Availability contacts and information third parties
- Crucial decision-making
- Prevent function overlap
With the operational and coordination requirements formulated a more specific contemplate
of the tasks and roles considering the different relief services (Fire department, police and
medical aid) is a logical next step. Afterwards it will be possible to draw conclusions on the
organisation and arrangements considering the repression preparation.
Fire Department
The fire department’s primary task is to contribute to the public security. Executing this task
results in preparation, prevention, suppression and caring after the calamity. In reality the
operational performance by the fire department mainly concentrates on suppression. The
suppression activity can be divided into several phases, which among others hold the
reporting of an incident followed by an alarm and the physical turn out. Subsequently
operational tasks and processes are executed. When the situation is under control the next
phase, the after caring, will follow. In contrast with other operational services the application
of the fire department rarely depends on the other relief services.

In case of large scale calamities the level of scale, local, regional or interregional, the
possibility to scale-up is one of the options. Scaling-up determines the way the firemen are
divided over the different teams considering a particular period. Because of this temporary
redistribution the aspect of command and control becomes highly important. Concentrating
on this aspect the importance of attendance times and organisational structures like
Coordination Team Place (area), Incident (CTPI), Commander Calamity Terrain (Commandant
RampTerrein – CORT), Regional Operational Team (ROT) and policy team (BeleidsTeam – BT)
local government becomes clear. After all the executing of suppression tasks can only take
place when these are allocated to a certain person. The most important processes, executed
by the fire department, in case of a flood calamity are concentrating on the evacuation and
saving of humans and animals apart from that the fire department should also provide
technical support.
Police Department
Concentrating on relief during a calamity the department of police take a leading or direct
role in certain parts of processes carried out by the relief services. These processes and their
priority are illustrated in Table 2 below.
Table 2 – Processes and their priority, executed by the police department (LOP, 2001)
Priority Process(part)
1 Set off / Screen
2 Evacuate
3 Organise traffic
4 Guiding
5 Maintain (public) order
6 Investigation
7 Identify and stow decedents
8 Notify the population
9 Support and caring (organising first support)
10 Registration (data of victims or witnesses)
The process of evacuating is a shared process and therefore not explicitly allocated to the
police department. With a flood the process of evacuation will be one of the most important
processes executed. The notion of several relief services involved in this process should be
taken along in possible conclusions. Concerning the processes, three main types (LOP, 2001)
of support can be determined.
1. Unstructured spontaneous support (individual policemen supporting on own

initiative)
2. Interregional assistance (a limited number of loose surveillance units)
3. Structured assistance (large units under the direction of one commander)
All three assistance types will be available or occur during a flood, although the most
important assistance concerns number three: structured assistance. Putting together such a
large unit will take some time, until that moment the application of the police forces quantity
will remain limited. In order to determine the maximum operational performance of the
police department all available capacity considering the three assistance types is added up.
The availability and applicability strongly depends on quantitative possibilities of the
regional police department and geographical situation of the calamity as well as the
moment.
In case of a calamity a crisis organisation besides the regular police organisation will be set
up. With it capacity has to remain available to the regular police process besides the crisis
organisation will also be allocated capacity concentrating on processes of less priority. The
crisis organisation usually is set up a half-hour after it is determined de relief services are
dealing with a calamity, the crisis organisation from than on will have the lead and the
responsibility regarding further coordination.

Medical (first) Aid Services
As seen with the other relief services the medical services (Geneeskundige Hulpverlening bij
Ongevallen en Rampen - GHOR) are involved in several processes. Like stated in an earlier
stage the focus will be on the suppression phase. The main processes of responsibility
contain physical and psychosocial medical aid and preventive public healthcare. During a
flood namely the first, concentrating on physical medical aid, will be important or at least
most relevant. Besides the GHOR also contributes to the multidisciplinary processes which
among others concern evacuation, care and first necessities of indigent civilians.

Working streams determined by the GHOR are distinguished by two criteria (LOP, 2001)
concerning the process:
• Time-critical, which indicates or a process should (completely or partly) be executed

within a certain period. Concerning non-time-critical processes only the bare workload
needs to be taken into account. For time-critical processes this workload should also be
measured by the time requirements.
• Whether specific expertise is needed or a ‘own’ kind of relief workers
In essence time is determinative concerning calamity control and concentrating on the

GHOR several important time aspects (LOP, 2001) can be distinguished:
• Clock time: the moment of a calamity is equalised with the appearance of injuries
• Treating time: amount of work and workload
• Norm time, time requirements, time window: various kinds of aid become less useful
when not provided to a victim on time. In case of the GHOR, as mentioned above, the aid
for victims is highly time-critical.
• Attendance time, application time, substitution: relief workers ought to make one’s way
to the place of the calamity and should be released from other duties and activities.
The reason for discussing these times, within the calamity relief plan, shows the importance
of these times and besides makes clear that designing a structured plan in the medical case
is complex. The complexity lies in the fact that the GHOR processes are highly diverse and
hard to predict, the different injuries and treating times continuously change the situation.
The constant changes make it hard to formulate a preventive plan. Because of this difficult
formulation in advance the GHOR processes require intensive information and accordingly
unambiguous information streams.
The actual information during a flood is obviously used to support processes of a somatic
basis. The task of the GHOR is the provision of care and aid considering the injured persons.
This is actually a scale-up compared with the normal situation of the first aid department
(Spoedeisende Medische Hulpverlening - SMH). The authorities combined in the GHOR
among others comprise the ambulance services, the ambulance switchboard (Centrale Post
Ambulancevervoer - CPA), medical services (Geneeskundige Combinatie - GNK-C), family
doctors, hospitals and pharmacies. Another complexity is formed by the public and private
nature of these different authorities. Problems caused by this division concern the allocation
of tasks and responsibilities. In order to function optimally, the GHOR obviously holds close
contact with the other relief services.
3.3 Responsibilities and hierarchy

With all processes of the relief services described, the various tasks and responsibilities are
becoming clear. The organisational structure of all different governmental authorities and
the more operational relief services, as mentioned before, is considerably complex. An
illustration of the established responsibilities provides a more vivid overview (Appendix V)
although a real hierarchy remains indistinct. The problem with this distinction is that the
importance of certain information streams is difficult to determine. With this difficulty
recognised a more extensive analysis concentrating on the information resources and
streams is desired. This analysis will therefore indicate the problems or potential
opportunities with regards to the information provision during a flood calamity.

4. Technical analysis: the C2000 system
Before starting to design a new system, it’s good to know which systems already exist in this
field. The technical analysis is carried out for two reasons:
• Identifying the obstacles in the current technical system (in order to avoid or cope with
them in the new technical design)
• Identifying aspects of the current technical system that could be integrated within the
new technical design.
One of the most relevant technical systems to get a closer look on is C2000. The House of
Commons decided in 1996 to construct the C2000 communication system by request of the
Ministry of BZK (De Projectdirectie C2000, 1998). The C2000 network, in full
“Communication 2000”, connects relief services like the police, fire department and medical
aid services as well as the military police. The main objective was to fully replace all relief
services’ existing communication networks, so it would be used with maximum efficiency. In
the upcoming years, C2000 will perform as the system par excellence for communication
purposes between the Dutch emergency services. In order to understand the functioning of
the system, this chapter will elaborate on the technical background of the C2000 system,
starting with the way in which it makes communication possible.
4.1 Five ways to communicate

The fundamental idea of the C2000 system is that all communication is covered through a
central communication point. There are 25 central emergency control rooms that cover up
the “Geintegreerde Meldkamer Systeem” (GMS). Each emergency room covers a safety
region in the Netherlands. In these emergency rooms representatives of each relief service
operate together. Like in a hub-and-spoke network all communication goes through these
central headquarters (De Projectdirectie C2000, 2004). C2000 supports, however, a wide
variety of types of communication. The five different types of communication possibilities
are listed below. The numbers in Figure 5 correspond with the listed descriptions.
1. Direct mode operation

The DMO enables users to communicate directly with each other through mobile devices
without using the C2000 network.
2. Air Interface
Communication between mobile devices can also take place by using masts or mobile
stations which communicate with each other through electromagnetic waves. The used
standard is TETRA. Besides the use of mobile devices, all used emergency vehicles have
built-in C2000 equipment. Air communication is possible up to a height of 1200 meters
(Deloitte, 2005).
3. Inter System Interface

Different TETRA networks can be connected to each other through the Inter System
Interface. This is important for international communication.
4. Gateways
C2000 can also be connected to external networks like the telephone network and data
networks. The gateways of C2000 are responsible for this feature.
5. Peripheral Equipment Interface

The Peripheral Equipment Interface makes communication between a mobile station and
a PC (laptop) possible (Min BZK, 2006b).

Figure 5 - A sketch on the concept of C2000 (Min BZK, 2006b).
4.1.1 TETRA
To enable international communication, a European communication standard is necessary.
The European Telecommunications Standards Institute (ETSI) supported to develop the
Terrestrial Trunk Radio (TETRA) standard, which is now the official standard for
communication between emergency services in Europe. The majority of European countries
are using this standard (Min BZK, 2006a). Some interesting features of TETRA are:
• By making use of Time Division Multiple Access technology with four user channels on
one radio carrier, TETRA uses the frequency spectrum in a very efficient way.
• National and international roaming is supported, so communication with adjoining
countries like Belgium and Germany is possible.
• TETRA supports point-to-point and point-to-multipoint communication.
• TETRA is an open multi-vendor standard. This means that the equipment that is needed
can be produced by any private party (ETSI, 2006). Motorola is the producer of the Dutch
equipment (Regionale brandweer Amsterdam eo, 2004:6).
The digital character of C2000 supports the transmission of voice and data. Another
advantage of digital transmission is a better protection against eavesdropping and the
possibility of encrypting the transmitted data. The construction of the C2000 network is
outsourced to TetraNed. Different parties are participating in TetraNed including Getronics,
KPN Telecom and Motorola. Together this consortium is responsible for the construction of
the network and the equipment. The network consists of 400 communication masts and all
the necessary exchanges (Min BZK, 2004b).
4.1.2 Equipment
The C2000 equipment is produced by Motorola. During the fall of 2004 the first TETRA
terminals were bought, which go under the name of Motorola MTP700. This device enables

voice communication and, into a lesser extent, data communication (Motorola, 2001). In the
mean time a new model is launched by Motorola, which proves to be a great success in the
UK. This device will be available for C2000 soon and Motorola expects it to be used in the
Netherlands on a short term (Motorola, 2004a). One of the advantages of this new model is
an improved colour display. This makes it possible to exchange incident views, digital maps
and specialized graphics such as Force logos. Another advantage is the built-in GPS receiver,
which makes it possible for the emergency rooms to plot the location of the user (Motorola,
2004b).
4.1.3 C2000 from a user perspective

As mentioned, the C2000 network supports voice and data traffic between the different
emergency services. The extent in which data traffic can be used depends, however, on the
used equipment. Next to this there is also the possibility of sending and receiving short text
messages. When a user turns on his device, it automatically logs in into the central system.
In continuation the operator in the emergency room divides the users in groups based on the
situation and authority. These groups can contain emergency workers from different
emergency services. In some cases emergency workers receive less information compared
to the old situation. While using the C2000 system, emergency workers do only receive
messages that are relevant for their own situation, instead of receiving messages that are
relevant to the whole discipline. The relevance of information to a certain user group is
determined by the controllers in the emergency rooms. However, by the coupling of C2000
to the GMS operators from different disciplines can share information with each other, which
can lead to more information generation (Min BZK, 2004a).
4.1.4 Project progress

Many resources concentrating on the C2000 system show a wide variety of information
concerning the status of the C2000 system. The 7th progression report on the C2000 project
performed by Deloitte (2005) states that at the end of 2005 21 out of the 23 safety regions
in the Netherlands were operational. According to the planning that was made in June 2005,
the last two regions should be using C2000 by the end of November. It could therefore be
assumed that C2000 is working properly at this moment. The quality of the technical system
is, however, an issue on which exists less consensus.
An example that illustrates the variety in information providence of different parties is the
already mentioned Bonfire case. Bonfire was crisis control exercise that took place mainly in
the Amsterdam ArenA. The official progression report on the C2000 project mentions the
success of C2000 during this exercise: “During events like the visit of the American president
Bush to the cemetery Margraten, SAIL and Bonfire C2000 is put into action successfully”
(Deloitte, 2005:31).
Different articles from the Dutch newspapers in contrary point out, that according to them,
C2000 failed irrevocable: “The new communication system, C2000, the system every
emergency service should be connected to at the end of this year, seemed to be the
perpetrator in Amsterdam. The technology failed in Amsterdam during the Bonfire
exercise…” (NRC, 2005a). The appointed evaluation team of Bonfire indicates that during
the exercise “The fire department and ambulance services could only make partially use of
the C2000 system as it had to deal with network interruptions” (Projectteam Borging
Leerervaringen Bonfire, 2006).
It seems that the value of the quality level of the C2000 system depends on the stakeholder
or principal, which is making a statement about the functioning. However, deliberated
conclusions about eventual prejudgments and truthfulness of these reports and articles can
not be claimed as fundamental due only by a literature and resources study. An analysis into
the strengths, weaknesses, opportunities and threats of the C2000 system is in this context
a better alternative. A SWOT analysis brings together the internal and external

environmental scanning to identify the projects internal strengths and weaknesses and
external opportunities and threats. In this way a deliberate overview can be created
according to the current status of the C2000 system.
4.2 SWOT analysis

Literature research provided information to execute the SWOT analysis. Appendix VI gives an
impression on the results of this analysis.
The SWOT analysis shows a certain amount of bottlenecks, which the project team
concerning C2000 faces. However, as one of the threats indicates the point of no return has
passed a long time ago. This proposes a large reduction in the opportunities to solve certain
bottlenecks. The path dependency of the implemented C2000 system demarcates the
problem solving concerning technical issues. Adjustments and innovations can only be
performed within the framework of the current C2000 system. The dependency on this
unstable system that still suffers from a variety of problems can be called critical, as the old
systems are being dismantled. Practice will have to show how C2000 will perform in action
and in to what extend the C2000 project team manages to attain that the system becomes a
stable and robust communication infrastructure.

5. Information streams and resources
During a water calamity the availability of information is crucial. In practice, it appears to be
difficult to obtain all relevant information. Moreover, it is important to have the right
information at the right place. This implicates that all actors involved in calamity control are
aware of their own information needs, but also of the information needs of others. In other
words, it is important that during the exchange of information it is clear for who the
information is meant, what is going to happen with the information and if any actions are
expected as a result of this information.
In this chapter, the information streams that arise between involved actors in a flood
situation are thoroughly discussed. This is interesting to consider, because, as said in
previous chapters, within an calamity situation, especially the coordination and cooperation
between actors does not always develop as it should. There are quite a number of issues to
consider when making an overview of all the different information flows during a flood.
To begin with, two different kinds of calamities can be discerned: the so called flash-
calamity, which is an immediate event, and the growth-calamity, on which on beforehand
there is some degree of expectation that it will occur (LMR, 2001). In the case of a water
calamity this distinction can be made as well. In the first case there will be preventive
evacuation of people and cattle. In the second, worse case, a flood happens before an
evacuation can take place. Medical assistance will be of greater importance, and
accessibility will be a key issue.
In this analysis the different steps in a growth flood situation will be discussed, concentrating
on which actors are involved, the roles they play, and how the information exchange takes
place within these parties. The focus will be on the operational level of communication and
coordination, which will be complementary to the responsibilities of the different actors
discussed in previous chapters.
In the past few years, there have been a number of incentives to support the decision-
making process with floods. Software programs, that include monitoring- and warning
systems, have been fully implemented or are currently being developed and tested. In the
next sections these programs will be treated, answering questions on where, when, and by
whom they are used, and with special attention to the support they can bring.
5.1 Processes during a water calamity

To act efficiently during an emergency situation, good information exchange is essential. In
the first place, information can be structured according to the main processes that occur
during a water calamity. These processes are listed below (Quickscan informatiemodellen,
2004). An important remark here is that the processes do not necessarily follow up, but can
occur synchronously as well.
1. Monitoring
2. Scale up
3. Evacuate
4. Flood
5. Take care of damage
A further analysis on the different processes can be found in the Appendix VII, including the
information entities that apply for these processes. Especially during the preparation phase
and the evacuation phase, the degree of multidisciplinary cooperation is rather high. The
picture below gives an overview of the different actors and teams that play a role, with their

interaction. To keep it simple, there are two ways of interaction. One is the hierarchical link,
through which orders are being given. The other is the information relation, which can be
any interaction where information is being shared or requested. Figure 6 provides a sketch
on this situation.
Orders
Information
Royal commissioner/ Mayor
Mayors Consult
Regional / national
Regional Actin Center
Coordination Center
Regional Policy Team
Maps, Calamity
Geo-info, Municipal Policy Team Plans
Resources Municipal Action Center
Management
systems GMS
(FLIWAS,
VIKING, IRIS)
Police Dept.
Regional Action Teams
Operational Commando Calamity
Teams Area
Fire Dept.
Situation
Reports Tacit
Knowledge GHOR
Figure 6 - Overview strategic direction (Based on: Overmars, 2004).
Two important relations involve the ones connecting the Regional Operational Teams (ROT)
with, on the one hand, the Action Teams and Commando Calamity Area, and, on the other
hand, with the Regional and Municipal Policy Teams. Most information flows between these
actors, before the information is being made “operational”, indicating that relief workers at
the lowest levels can operate with it. Problems from lower levels are being solved on a
higher level, and policy decisions from a higher level are put into actions on a lower level.
The information entities on which the different levels depend can in a generic way be
described as follows:
 merely tacit knowledge in combination with orders on a lower level
 situation reports, based on gathered information a level higher
 calamity plans (on the policy level), regulations form the basis of decisions
There is quite some redundancy in the situation reports, which are provided in a
decentralized fashion by different operational teams. Use of computer programs in

supporting decisions does occur, but is not exploited completely by every actor. As can be
seen, any actor can use the systems, only an internet connection is needed.
The communication flows during the scaling up and the evacuation processes, are described
below1. The centre of operations is located at the Regional Operational Teams (ROT). The
ROT is the link between the actually operational teams, and the decision-making institutions.
The ROT exists of delegations of several relief services, and people from the municipality
and government. They collect information from the regional and national coordination
centre. Furthermore, they receive information from the GMS and Commando Calamity Area,
and possibly from the Regional Policy Team. The different relief organizations are involved as
well, along with delegates from the municipality. After the collection and the processing of
data by the different actors into situation reports and discussion points, they come together
in a meeting, in which the information is being discussed. Upon this meeting requests/advice
or orders to respectively the municipality/Regional Policy Team and the Action Teams will
follow. The frequency of these meetings intensifies when scaling up.
This process of collecting and receiving data, conceptualizing the situation, making
decisions, requesting permission, giving advice and orders, all happens constantly, to deal
with the rapidly changing information. The way of decision-making and collecting and
structuring information happens mainly through phone or email, and for a limited amount of
people. When stored in a database, all users with authorization can access the information
and use it. This creates less redundancy and equally shared knowledge.
ROT – Information Gathering

Consultation by phone or email
Support by computer programs (FLIWAS Light , VIKING)
RPT, Municipality, Action Teams, RCC, NCC, GMS
Decisions Questions
Answers Remarks
Information
Information
RPT/ ROT - Action

Municipality Requests
Meeting Teams
Orders
Advice Information
Figure 7 - Information flows ROT (Based on: Overmars, 2004).
Although the specific content of information flows will differ during a water calamity, some
general flows can be identified. Figure 7 provides a broad overview of these flows. An Action
Team, for example, operates on the basis of the orders and responsibilities it receives. When
there is a question, or permission needed from a higher level, a request is sent to the ROT,
which will probably deal with it in their following meeting. The same holds for information,
remarks or decisions. Information sometimes is dealt with separately, but this totally
depends on the kind of information, priority or importance. The process of decision-making
can come out very slow, because information travels at the handling speed of different
1
Based on: Observations during the exercise ‘Helga’ on water calamities in ‘t Harde. May 16th 2006.

actors. Telephone and email are the main modes of transporting information. On the other
hand, because of the human intervention, there is a natural selection of useful information
or concerning cases.

5.2 Main focus: the evacuation process
In the following analysis, the focus will be on the evacuation process, as this process
contains the highest multidisciplinary level. Thus, the most complex form of information
streams can be expected here. Therefore, this paragraph will deal with the different stages
that take place during the evacuation process.
The most important actors involved in the operational level, are the fire department, police
department, the medical services, and the municipalities. The management and
coordination of the operational teams takes place through the following teams, as explained
before in the actor analysis (chapter 3): Calamity Policy Team, Operational Teams and the
Action Team(s).
An important note is that the operational responsibility of evacuation lies in hands of the
police department. Although the final responsibility is still in hands of the mayor, the most
important operational processes, such as escort traffic and evacuate people, fall under the
responsibility of the police (Politiewet 1993). When dealing with an evacuation, there are five
main processes, in chronological order:
1. Analyzing relevant information (nature, dimension, area, etc.)

2. Draw up evacuation plan
3. Getting personnel and resources ready
4. Use of personnel and resources
5. Return people to their homes
One of the most critical success factors has to do with the informing of people, they will only
be willing to leave their place if they assume the water calamity imposes a real threat.
Moreover, informing the people well will prevent chaos. The information has to be complete,
and given at the same time through different types of media. In case of a regional calamity,
like most water calamities, the Royal Commissioner has to give his consent.
The operational preparation is done by the coordinator Conflict- and Crisis management of
the region, and is based on calamity plans and other literature relevant for the specific
calamity. The criteria are set by the police department, and have to be in conformance with
the ‘Leidraad Operationele Prestaties’ (Algemeen Doorlichtingsinstrument, 2003). The core
of the operational staff of an evacuation exists of General Commander (leader), Chief
Operation, Chief Support, and Chief Information (Handboek Rampenbestrijding, 2003). In
Appendix VIII the five main processes of evacuation are elaborated in detail. Below,
conclusions resulting from the appendix (VIII) of every process will be shortly discussed.
5.2.1 Analyzing relevant information

This first activity aims at a better knowledge of the situation, trying to collect as much
information as possible in order to make justified decisions. Decisions are made with regard
to informing and advising the public, the dimension of the evacuation area, judicial
arrangements, the amount and location of involved people, cattle, and buildings/objects,
priorities, and the responsibilities.
Conclusions of activity ‘Analyze relevant information’ (see Appendix VIII)

• This part of the evacuation still regards the planning and preparation phase, where plans
are being made, and discussed between the relief services. There is a large amount of
information being exchanged between the District Water Board and the relief services. It
is not always clear where information regarding population characteristics and location
can be requested.
• After this process it should be clear where the different responsibilities and priorities are,
and there should be enough information to draw an evacuation plan.

• New supporting ICT-initiatives as FLIWAS and Viking can be of great help in this process.
Explanation of these initiatives is in another section of this chapter (Further analysis on
this subject is necessary and will be discussed later on).
5.2.2 Draw up evacuation plan

In this part of the process the actual evacuation plan is being developed and actualized for
the current situation. It consists of addressing practical issues regarding the information and
instruction to the public, gathering data, and transforming this into an evaluation plan.
Important is the connection between probable demand for evacuation measures and the
available resources.
Conclusions of activity ‘Draw up evacuation plan’ (see Appendix VIII)

• Usually when flood situations take place within a relatively small area, the evacuation
plan of the nearest municipality plan can be applied. However, when more municipalities
are involved, the different evacuation plans need to be harmonized and updated. As not
every flood is the same, there should be some fine-tuning according to the flood
characteristics and consequences. Evacuation plans, and data regarding evacuation,
should be easily comparable, so a format is necessary.
• An important aspect regards the time schemes, describing different evacuation steps,
with each step specific informational aspects. Different kinds of information are needed
at different moments during the process. It is not desirable to be confronted with all
information at all times, for this could cause an information overflow which causes delays
and bad decisions. It is much more efficient when the information arrives only at times
when there is a need for that information.
• When designing a format for evacuation plans, and especially the informational part, it
should be translatable to digital systems.
• It is not clear where possible resources as trucks, ships, materials etc. can be obtained,
and how much of it is available. A list should be made per municipality, and in
emergency situations, easily connectable. This list should comply with certain standards.
• There are possibilities to make evacuation plans using computer programs, hence
directly connecting flood characteristics with the local geographic and demographic
data. It also has the flexibility to change it minute by minute and is available for anyone
connected with the internet. More about this in a later section.
5.2.3 Getting Personnel and Resources ready

Personnel and resources are being prepared. People and organizations are called that will or
could be of assistance (e.g. church, military).
Conclusions of activity ‘Getting Personnel and Resources Ready’ (see Appendix VIII)
• A positive aspect of this activity is that it, such as alarming third parties and getting
people into position, clearly demarcates and appoints certain actors.
• Something that could hamper the progress of this activity is the absence of up-to-date
information regarding contact details of personnel and organizations. If there is no clear
list with data about required persons, organizations, companies, delays can occur.
• There should be one database with all important contact details needed during a
calamity.
5.2.4 Use of Personnel and Resources

This activity consists in essence three main processes, which are the instruction of
personnel, the mobilizing of personnel and resources, and the registration of persons,
animals and objects.
Conclusions for activity ‘Use of personnel and resources’ (see Appendix VIII)

• Unclear division of responsibilities; Police involvement is minimal here, and processes
that are clearly part of the Police Department responsibility (such as traffic control and
order maintenance), are stated under the responsibility of the Municipality and without
any interaction with the Police Department.
• It seems that the mobilization and instruction of personnel happens in a considerably
static way. Like plans, scripts for people and instructions can change over time; this
should be corresponded to all personnel in an efficient way.
5.2.5 Return people to their homes

On this process will not be focussed. This process will be considered as out of the scope of
this project.
5.3 Other important processes

Before, during and after the evacuation, there are several other important processes, that
have to make sure that it all happens smoothly. These processes are listed below in Table 3.
Table 3 – Responsibilities of main operational actors.

Source and effect combating (Fire Medical Services (GHOR)
Dept.)
- Rescue and Technical Support - Medical treatment
- Monitor and Measure - Somatic
- Warn Public - Psychological
- Make accessible and clean
Legal order and traffic (Police Dept.) Public Care (Municipality)
- Clear and Evacuate - Inform and Instruct
- Fence and Protect areas - Receive and take care
- Traffic Management - Registration (victims/damage)
- Maintain legal order - Environmental care
- Identification Victims - Follow up care
- Guiding
It should be noted that not one calamity is the same, and unexpected events can occur.
There are still activities and moments which are not described in any book or script, and
could require multidisciplinary cooperation.
5.4 Current developments

Currently, projects focusing on water management are running in the Netherlands, but also
on a larger scale as international projects (Germany). The most comprehensive project,
FLIWAS will be shortly discussed in this section; in Appendix IX a more elaborate description
is given.
5.4.1 FLIWAS
Swift and adequate information exchange at (impending) flood events: that is what the
development of FLIWAS is all about. The FLood Information and WArning System is a system
that integrates (parts of) existing (information) systems, such as monitor and forecast
models, geo-information, high water level scripts, water risk maps, and calamity plans.
FLIWAS is accessible through a web-based interface (web-browser) and is supported by GIS.
In short, FLIWAS is an information- and communication system designed to collect and
process information and propose and manage actions before, during, and after a flood event
and make this information available to various groups of users according to their specific
requirements. Among others, this information will cover:
• Representation of flood risks to be anticipated on the basis of flood protection

installations, failure of flood protection installations, representation of risks and risk

potentials (population, hospitals, old people’s homes, cattle, dangerous substances,
streets, railroads).
• Representation of the resources available to counter and avoid catastrophes (fire
brigade, vehicles, stock of sand sacks, machinery).
• Representation of measures to be taken by way of digital alert plans and action plans
• Evacuation scenario
• Representation of streets serving as escape routes
FLIWAS consists of several modules. General modules provide standardized user

communication, data access and management, and communication with external systems.
FLIWAS will help each user, including policy makers, technical professionals, and civilians to
access the right information. Distinction is made between obtaining and presenting
measurement information (water levels, discharges, precipitation), specification and
operational use of flood scenarios, drafting and effecting evacuation scenarios and resource
management (FLIWAS Newsletter 1, 2006). More information about the technology and the
stakeholders can be found in Appendix IX.

6. Institutional situation
The previous chapters have given a clear overview of the actors, the available technology
and the information streams and resources during a water calamity. It has become clear that
the interconnection between these subjects is far from optimal; calamity control is does still
not function as desired. Before being able to formulate a new design proposal, along with its
requirements, it is of importance to recognize why this interconnection is not functioning
properly. Therefore, an analysis should be performed on the institutional characteristics of
water calamity control. This chapter will treat several theories on institutional design.
6.1 Theories covering crisis situations

This section is guided by theories covering crisis situations, based on Muller (1996). Muller
makes a distinction between routine decisions, complex decisions and crisis decisions. Crisis
decisions are a specific form of complex decisions, with two additional elements: a severe
threat and time-pressure. Because of these two elements other theories on institutional
design are hard to apply on crisis situations. Muller even says there are no real crisis
theories available at the moment. In his article he makes an attempt to select specific parts
of existing theories that can be used for crisis situations. The following theories can be
interesting:
• Garbage can model - Crisis entrepreneurs make use of the situations to implement
changes or gain right to exist. Example: relief services.
• Realism: mixed scanning and satisficing - Satisficing model presumes that only one
criterion exists in decision making, which strokes with crisis situations.
The conclusion which can be drawn here implies that these theories may be of good use in
the design phase, because they explain a lot about decision making in crisis situations. They
are of less use in a descriptive way.
6.2 Theories covering the differences between governmental

(emergency) organizations
This section is guided by theories covering the differences between governmental
(emergency) organizations and is based on Koppenjan & Groenewegen (2005). The
application of the theory to the case is done in a descriptive form, by applying existing
literature and the conclusions of a an interview with mr. Koppenjan. Koppenjan and
Groenewegen developed the four-layer-model. The model specifies four layers (as
mentioned in Figure 8).
1. The level of individual actors

2. The level of institutional arrangements
3. The level which determines the legal positions of the actors from level 2.
4. The level which determines the culture and mindset of the actors from level 1 and 2.
The arrows between the layers (Figure 8) indicate which relations exist between the layers.
The vertical arrows make clear that lower and higher levels influence each other directly.
One important conclusion that can be derived from this model:
“Since institutions are embedded in higher institutions, it is important that institutions are
‘appropriate’: they must be congruent with other institutions at other levels. If this is not the
case, they will not function properly or will be unstable.” (Koppenjan & Groenewegen,
2005:9).

This model is interesting for this case because several institutional environments and levels
can be distinguished in large organizations like the relief organizations and the concerning
governmental bodies.
Layer 4: Informal institutional environment of socio-

technological systems – culture, values, norms and
attitudes
Layer 3: Formal institutional environment of socio-technical

systems – formal legislation (formal rules, laws and
regulations)
Layer 2: formal and informal institutional arrangements of

socio-technological systems – instiutional arrangements
(formal: covenants, contracts, mergers. Informal: rules,
codes, norms, relations).
Layer 1: Actors and games in socio-technological systems

– agents and their interactions aimed at creating and
influencing certain outcomes
Figure 8 - The four-layer model (Koppenjan & Groenewegen, 2005:8).
6.2.1 Applying the four-layer model to the case

Below each layer is applied to the case. To be able to start with the lowest level, the order of
the layers is contrary to the model given in Figure 8.
Level 1: Actors and games

Loyalty to the own organization is very important among emergency workers. This
attitude may result in actions that don’t stimulate cooperation with other
organizations. Sometimes cooperation asks for sacrifices. Particularly in these cases a
relief worker will protect his own organization instead of supporting the cooperation.
During an incident the relief services cooperate, but when the incident is finished the
services return to their old attitude of aloofness. A project group from the SMVP (The
Dutch Society, Security and Police Foundation) concludes: “Sometimes it happens to
be the case that policemen and fireman avoid each other to protect their own
position or culture” (SMVP, 2004).
Level 2: Formal and informal institutional arrangements

Formal: The tasks, responsibilities and structure of the Dutch relief services are
formally described in detail (the Police Act for example). For a long period, the
services were allowed to fill in these responsibilities at their own manner. Due to this
freedom, a lack of supervision and means to intervene, it isn’t easy for policy makers
these days to control and steer the relief services. The Public Order and Safety
Inspection concludes: “The current formal system of supervision is characterized by a
high density of legal supervision relations to be carried out by administrative bodies,
who nevertheless don’t have any well defined criteria or intervention possibilities”
(Helsloot et al, 2004:95).

Informal: Relief services have their own history and developed their own rules, codes
and relations gradually over time. These rules and codes even differ between
different regions of one emergency service (Appelman, 2006).
Level 3: Laws and regulations

Each relief service has its own act which specifies the formal tasks and
responsibilities. Each relief service itself comes under multiple authorities (see
chapter 3). All these authorities provide the relief services with multiple guidelines,
independent of each other. There’s a lack of one central organization that carries the
responsibility for the whole police department on a practical level. The ministry of
BZK has the final responsibility for the police department, but this only counts for
matters on a national level. The ministry doesn’t provide practical rules
The content of these regulations is not unambiguous; most of the time these
documents are guidelines or directives. For the relief services it’s unclear what the
actual status of these documents is and how to interpret them. One region of the fire
department puts this into the following words: “This (harmonization of supervision...)
is necessary in a fire department field that is characterized by many decision
makers, many visions and a large diversity in budgeting, education, exercise and
quality” (Helsloot et al, 2004:55).
Level 4: culture, value, beliefs

This case only concerns Dutch organizations. Among the Dutch (relief) workers, a
difference in culture, value and beliefs is not known. It’s acceptable to say that every
organization involved in the fight against disasters strives for safety and security.
When using a European perspective on this case, some problems might occur when
relief services from different European countries have to cooperate. Small differences
in national values and culture could exist.
6.2.2 Highlighted problems resulting from the applied theory

The following conclusions can be derived from the model applied to the case:
• For relief services it’s hard to communicate with other relief services because they each
developed their own system for communication (layer 2). Nowadays they may use the
same technology (C2000), but that doesn’t mean they use the same communication
protocols and codes.
• Although C2000 stimulates more interaction between the different relief services, the
internal culture sabotages this (layer 1). During an incident the relief services cooperate,
but when the incident is over they all return to their old attitude of aloofness (SMVP,
2004). Formal means and incentives to achieve constant cooperation are missing. Even
when they would exist two difficulties would remain:
- Do the relief services really understand what the aim of these formal means and
incentives are (layer 3)?
- How should it be verified whether the relief services obey to the new rules (layer 2)?

7. Problem specification
In the previous chapters the different facets concerning communication, coordination and
cooperation between the different parties involved in case of a flooding calamity, have been
analysed. The analysis started with the definition of a central problem definition that
provided the fundament for the research outlined in this paper. The central problem
definition was formulated as follows:
“In case of a water calamity, how can the present problems with regard to communication,
coordination and cooperation between the different parties involved be solved through the
support of ICT?”
Crucial for the structure of the performed research was the design of the objective analysis.
This provided the overall picture on the different subjects that needed to be elaborated. The
objective tree (Appendix I) presented the different sub researches that needed to be sorted
out in a structural way, in order to provide a thoroughly determined overall answer on the
research question. The different sections have provided a substantial insight in the relevant
social, technical and institutional aspects of the problem area. In order to clarify the different
analysed parts of information, this chapter will give a summary by briefly discussing the sub
researches identified in chapter 2. Moreover, the most important conclusions of each sub
research have been defined and clarified.
7.1 Sub researches

7.1.1 Sub research 1 – Actor and network situation
In the actor and network analysis two groups of important actors have been identified. The
government institutions (Ministry of VWS, Provinces, District Water Boards and
Municipalities) are important for the policy and decision making processes. The group of
relief services (Police Department, First Aid Services and Fire Department) is active and
present at the location of the calamity. All these actors are dependent on an optimal level of
communication, coordination and cooperation.
To structure this, several calamity plans have been drawn up. These (extensive) plans
contain detailed responsibility schemes and describe the different tasks that need to be
fulfilled by the particular actor(s). Striking is the fact that nearly every actor has his own
calamity plan. Although attempts have been made to integrate the different calamity plans
in order to ensure an efficient calamity control organization, the complexity remains very
high.
The existence of several Municipal- and District Calamity Plans and the desired combination
with the calamity relief plans, gives rise to the need of a coordinating databank. The
databank should be linking these plans, or put them together, and giving aid in a smooth
cooperation between them. This is established in an Operational Plan (OP). The ministry of
BZK formulated guidelines in order to standardise the form of all these local OP’s, resulting
in two different manuals. The Leidraad Maatramp (LMR), which concentrates on the regional
preparations considering calamity control and the Leidraad Operationele Prestaties (LOP),
which concentrates more on the operational part of calamity control. Analyzing the manuals
of the relief services shows that the main processes executed in case of a flood or water
calamity are of a multidisciplinary nature. This indicates that the communication,
coordination and cooperation during such a calamity is of high importance and therefore a
flood calamity provides a considerably interesting case.

Lastly, in designing a solution to the problem of the imperfect communication, coordination
and cooperation certain aspects should be assumed sufficient and accordingly should be
placed outside the design boundaries.
Sub-conclusions 1:
• Difficulties in coordination and cooperation: The decentralisation of the different
calamity plans will cause major problems on the level of coordination and
cooperation once a water calamity occurs.
• Emphasis on multidisciplinary process: The most important process during a flood is
the multidisciplinary process. The multidisciplinary process can be improved by
efficient allocation of information. The information on available resources is sufficient,
but needs to be properly allocated during water calamities. In the current situation, it
is difficult to predict this allocation on beforehand, due to the involvement of many
actors in water calamity control. Thus, it would be desirable to simplify the
structuring of these actors in the first place. This could help create a good overview
on a short notice and, as a result, make improvements on information allocation
possible. Supporting information allocation through ICT could indeed be very useful.
7.1.2 Sub research 2 – Current technical situation

The analysis on the current technical situation concentrates on the C2000 communication
system that needs to be fully operational by now. Different aspects of the system have been
clarified. The TETRA standard concerning the network layer, how the system can be used to
communicate, the equipment used by relief workers and the C2000 project progress are
aspects that are exemplified. The analysis shows the contradictions between different
reports and articles concerning the project progress of C2000. A SWOT analysis was
executed, which created a deliberate overview according to the current technical status of
the C2000 system.
The SWOT analysis shows a certain amount of bottlenecks. However, as one of the threats
indicates the point of no return for the C2000 system has been passed a long time ago,
which indicates the path dependency of the whole C2000 project. This proposes a large
reduction in the opportunities to solve certain bottleneck. The first conclusion due to the
current technical situation can thus be defined as:
Sub-conclusions 2:
• C2000 as principle technology: The path dependency of the implemented C2000
system demarcates the problem design space concerning technical issues. Every
system that will be designed has to take the existence of the current C2000 system
into account.
7.1.3 Sub research 3 – Information situation

In this analysis the processes that can or will occur during a flood situation regarding
information are being analyzed more specifically. The main processes during a water
calamity are monitoring, scaling up, evacuation, the flood itself and taking care of the
damage caused. Especially during the preparation phase and the evacuation phase, the
degree of multidisciplinary cooperation is considerably high. It has become clear that the
information streams between the different actors form a complex web; effective
management would be desirable.
The centre of operations is located at the Regional Operational Teams (ROT). The ROT forms
the link between the teams in the field (e.g. relief services) and the decision-making
institutions. This team is engaged in a process of collecting and receiving data,

conceptualizing the situation, making decisions, requesting permission, and giving advice
and orders.
The evacuation process has been identified as the most important process within the
analysis, because it is the result of a highly multidisciplinary collaboration between relief
services and other actors on operational and policy level. It is shown that the evacuation
activity consists of different processes including analyzing relevant information (nature,
dimension, area, etc.), the drawing up of the evacuation plan, getting personnel and
resources ready, bringing personnel and resources into action and the return of the people.
Currently, several projects focusing on water management are active in the Netherlands.
The most promising project is FLIWAS, a system that integrates (parts of) existing
(information) systems, such as monitor and forecast models, geo-information, high water
level scripts, water risk maps, and calamity plans.
Sub-conclusions 3
• Static procedures: It seems that the whole process of gathering information, drawing
up and executing an evacuation plan, is very much like a script, where one step
follows the other. To put it more clearly; it seems to be very static. When an
evacuation plan is made, there is no indication that, because of new knowledge, this
plan can be altered along the way. This is, especially in case of a flood, where the
situation changes every minute, not desirable. An evacuation plan should be flexible,
and the Policy or Operational Team should have better means to change plans as a
result of new information. This implies that situational changes can not adequately be
communicated in the current situation, due to a lack of cooperation and coordination.
An ICT system that could deal with the dynamic characteristics of a water calamity
would be very useful.
• High dependency on tacit knowledge: An important remark is that there is no
information available that describes in detail the exact steps to be undertaken on a
certain point in time. Of course, in a non-digital environment, this indeed would be
useless, because no person will carry a manual during an emergency situation, and
look up every step in the process. A lot depends on the tacit knowledge and
intelligence of a person and his ability to act deliberate in stress situations. To make
the quality of relief services less dependent on these more personal factors, an
automatic script could be of great support.
• Availability and accessibility: The availability and accessibility of correct and
complete information for an effective execution of tasks are of an insufficient level,
due to the dependency on human interaction. Currently, most information processing
occurs in the policy level (through meetings) and is very time consuming. In other
words, more efficiency in information processing is required. It would be desirable to
directly store (new) information digitally, so that it can be directly structured
according to its type, priority, status, authorization, etc.
• Important tasks not assigned, ambiguous task definition: Not in all documents the
tasks are defined unambiguously, or clearly assigned to actors. A clear task definition
helps to create transparency and less confusion. It is not clear whose task it is to
keep information regarding resources (trucks, sand bags, trains, etc.) available and
up-to-date. The same holds for information regarding required contacts (churches,
military, voluntary police, utility companies, etc.). This kind of information should be
readily available before a flood situation occurs. There should be one database with
all information about resources and contacts. In this case digitalization and the
management of information with computer programs, can help in structuring,
accessing, using the right information, at the right time, by the right person(s).
• Little use of new information systems: As already mentioned in sub conclusion 1, the
allocation of information between the involved parties is performed inefficiently.
Despite new technologies and current developments, there is still no direct

connection between C2000 and the information systems discussed above, such as
FLIWAS. This can have great positive effects, and empower the people working on the
lower, more operational level, significantly. Persons doing the actual relief services,
when supplied with the right information at the right time, can make better decisions
more quickly, without the need of control or management directed from a higher
level. A possible disadvantage of connecting C2000 with external systems could be
an increased security risk.
• Use of information systems on any level: Not only on the operational level new
information systems can be useful, but during every phase and on every level the
information exchange can be enhanced when the right connection takes place
between demand of information and available information. Some of the systems are
already in use on a management level. Combined with the right information
management programs (part of the initiatives), and decision support programs,
emergency activities can be done quicker, better, and on the right time.
• Further analysis about system integration and compatibility: The final remark is that
initiatives for the new information systems are for the greater part in their start-up
phase. Some parts are already implemented and operational, others are in a test
phase, and there are still parts that only exist on paper. The possibilities, especially in
future situations, should be analyzed constantly. When talking about system
development, or system integration, it is indispensable to have knowledge about
content of messages being exchanged, the format, and how this all happens. This
should be part of further analysis.
7.1.4 Sub research 4 – Institutional situation

First of all, sub research 4 included the selection of a formal theory which would be
applicable to the case described in this paper. For this sub research the four-layer model of
Koppenjan & Groenewegen (2005) was chosen because of its diversity of institutional levels.
After the application of the model several bottlenecks and problems became clear.
Concerning the communication layer it became clear that each relief service had the
opportunity to develop its own system for communication. They may use the same
technology (C2000), but that does not mean they will use the same communication
protocols and codes. These things developed gradually over time within the different
organizations. This aspect forms a major obstacle in cross-organizational communication.
With regard to the cooperation layer it is stated that although C2000 stimulates more
interaction between the different relief services, this functionality has been “sabotaged” by
the internal culture. Loyalty to the own organisation remains very important.
The formal means and incentives to achieve constant cooperation are missing. Even when
they would exist there are two difficulties that would remain. Do the relief services really
understand what the aim of these formal means and incentives are? And how to control the
relief services whether they obey to the new rules?
Sub-conclusions 4
• Lack of standards: Although the different relief services can communicate with each
other, the lack of standards and protocols on how to communicate leads to the
development of problems on technical and social levels. This hinders efficient and
effective cross-organizational communication. Arrangements on unambiguous
information provision would be an important improvement to overcome these
difficulties. The system design in Part II should include the capability to integrate
information and make it understandable for all parties involved.
• Cultural differences: The internal culture of relief services negatively affects the
emergence of interaction between the different services. Cross organizational
interaction can cause incomprehension and even give rise to conflicting opinions,

hampering efficient calamity control. A digitalized information system that has taken
up the wishes of different parties involved can eliminate these inequalities.
• Different expectations: The tangle of guidelines and directives makes it in certain
situations unclear what is expected of each relief service in a certain place on a
certain time. An adequate level of information allocation and information flow
management can bring aid here.
• Fragmentation of power; Means for controlling the relief services are spread over
many actors, so real decisiveness is missing.
7.2 Reflection
Earlier in the report it was stated that the central objective of the problem owner (the
Ministry of BZK) is maximum security. To realize this objective, the objectives on the lowest
level of the objective tree need to be obtained.
The conclusions presented in this chapter give a good overview of the problems that occur
in realising these objectives. The identified obstacles show that there is a need for an
improved design that deals with them. The next chapter will present a proposal for a design
that will solve the identified problems.

8. Design Proposal
The preceding chapters have made clear that the activities during a water calamity are
innumerable and often very complex. Various reports and (calamity) plans have made an
attempt to bring structure and order in the maze of responsibilities and information streams.
However, it has become clear that the integration and the translation of all these results to
the real world is the most important pitfall. The three C´s (communication, coordination and
cooperation) are thus not linked in an optimal way. In other words, how can everything
drawn up in the preparation phase are made clear to every particular person during a
calamity? Obviously, it will be impossible to oblige everyone to read all calamity plans and
other relevant literature in advance. Moreover, a fireman doesn’t need to know the specific
tasks of certain government officials; structuring is needed with respect to information
streams. Points of attention here are availability, allocation and information flow
management.
Therefore, the system to be designed should be suitable for a total integration of the
conclusions done in the previous chapters. With the C2000 system as the underlying
technology on the one hand, and the responsibility schemes on the other, the situational
awareness of every single person involved in a calamity should be optimized. This implies
that every actor should immediately be aware of the following:
- his responsibilities
- his tasks
- who his superiors are
- who his subjects are
- where to find information
- what information he should communicate and with whom
- operation of C2000
A new system will have to be designed to satisfy these conditions, for it is clear that the
existing systems are not able to meet these needs. In this chapter, a first draft for the
system’s technological-, institutional- and process characteristics will be drawn up. Then, the
system’s “mandatory”- and “preference” requirements will be identified in section 8.2
8.1 Technological design aspects

The new system will be built on the existing C2000 technology. This provides a clear
demarcation within the technological design. However, the current C2000 infrastructure
seems to fall short, due to a deficient coordination and cooperation. Currently, all
information is centrally controlled by the Emergency Room which is part of GMS as described
in chapter 3. Actors involved can therefore not directly consult information databases.
Moreover, the information provided is mainly push based; the Emergency Room decides
which information is delivered when and to whom.
This centralized way of information provision is inefficient and ineffective. Therefore, the
allocation, integration and translation of information should more decentralized and logically
be organized. It is proposed to implement a Service-oriented Architecture in order to
improve the provision of information during water calamities. Points of attention here are the
current infrastructure, the used systems and databases, the actors involved and their roles
in the proposed design, the organization of the Service-Oriented Architecture, as well as
technical as management and the user interaction.
8.2 Institutional design aspects

The new system will require the many actors involved to set new agreements. This implies
that the system should also obtain a broad social basis in the institutional context. Thus,

new institutional arrangements will be required. It is important to determine how the actors
involved will deal with the system. While respecting the existing responsibilities, it will be
important to determine who will be in charge of the whole process of information
management and how this management should be implemented. People will need to be
ordered into groups, according to the responsibility schemes. These groups will have to be
linked to each other in a hierarchical scheme. Moreover, agreements will have to be made
on the way information is gathered, shared and stored.
8.3 Process design aspects

In order to reach an orderly and structured way of implementing the new system, a process
design is required. The main purpose of the process design is to bring all the different
parties involved together and improve cooperation. The C2000 analysis has already pointed
out that agreements between relief services were probably not well founded; the level of
cooperation between them was far from optimal. Moreover, an important bridge is to be built
between the government institutions and the relief services. In the current situation,
information sharing is very badly organized between and within these two actor groups.
In other words, a process design should be made to create a high level of willingness to
cooperate. Furthermore, the implementation time should be acceptable. All actors involved
should come to accept the new system and incorporate it with their existing calamity plans.
8.4 Program of requirements

8.4.1 Classes of requirements
To discover the design space a program of requirements has to be made. These
requirements can be divided in two ways. A division can be made between mandatory and
preference requirements:
• Mandatory requirements - These requirements indicate the boundaries of the system

that has to be designed. They are never part of a trade-off because it’s necessary the
system suffices these requirements. These requirements could be defined as ‘need-to-
haves’. This type of requirements is often referred to as functional requirements.
• Preference requirements - These requirements could be defined as ‘nice-to-haves’. These
requirements can be part of a trade-off since the system will function without them as
well. This type of requirements is often referred to as non-functional requirements
Since requirements could compete with each other trade-offs might need to be made.
Obviously, it is important to determine which requirements can be involved in these trade-
offs. The division of requirements in preference (nice) and mandatory (need) requirements is
not very easy to explain; defining them is often an arbitrary matter and the result of
negotiations between involved parties.
8.4.2 Methodology
To obtain a complete list of requirements, a Group Decision Room setting was used by the
authors. In a Group Decision Room (GDR) complex questions are carried out with the use of
computers. This can result in a lot of input in a short time, which is of good use during a
brainstorm. The group of participants should be formed in such a way that every relevant
party is represented by one or two participants (dependent on the maximum group size).
This was unfortunately not possible in this amount of time, so the group existed out of four
group members who tried to think outside their role of designer and to come up with as
many requirements as possible. The following questions were discussed during the session:
• Give some examples of possible failures during this exercise (April 12, 2006)
concentrating on desired information (resources / needs).

• Give some examples of possible advantages and disadvantages of full information.
• Identify as many requirements as possible.
The first two questions were used to identify possible pitfalls. The last question was used to
get the list of requirements as presented below. A detailed report of the session can be
found in Appendix X. The categories in which the requirements will be presented emerged
during the session. To keep a good overview these categories themselves were divided into
four classes; general, technical, institutional and process requirements.
8.4.3 List of requirements
General
Input-output
These requirements show which input already exists and in what form they should be
delivered to the users of the system. General, static plans are already available but they
need to be transformed into practical pieces of information specified for each person
(personalization). These requirements indicate that one of the most important functions of
the required system is the translation of information to content made understandable for a
calamity control setting.
- General information → Personalised information (need)

- Stored information / data → Operational data (need)
- Conceptual Information → Useable / operational information (need)
- Static data → Dynamic information (need)
- Analogue voice signals → Digitalised information (need)
- Request for specific information → location / provision of specific information
(need)
- Conceptual information → visualized, clear information (graphs, tables) (need).
Information
The input-output requirements pose a lot of concrete requirements on information. When a
user sends a request for information he should receive a unambiguous answer, so semantics
should be the same. Besides that the user should know how reliable the received
information is to determine what actions to take.
- Limited amount of information a particular user in the field should receive (need)
- Clear and general semantics (need)
- Good quality of information input (content) (need)
- Good quality of information output (content) (need)
- Information should be delivered with a reliability grade (nice)
- Priority ranking in information provided (nice)
Technical
Technological requirements
The technological requirements are important because the required system has to cooperate
with existing systems (often referred to as legacy systems). This poses among other things
requirements on the format in which information is saved and stored (digital). The system
that will be designed also requires some level of technical performance, captured in the
following practical requirements:
- Compatible with C2000 (need)

- Compatible for extension with other (international) information systems and
developments (nice)
- No (unwanted) interference with other systems (need)
- Sufficient available bandwidth (need)

- Web-based (possibly use of Internet applications) (need)
- Ability to couple this system to communication systems that civilians use (nice)
- Voice interaction possible (need)
- Ability of data-communication, including pictures (need)
- Real-time communication (no delays) (need)
- Existence of sufficient back-up systems (need)
- Be able to deal with all sorts of information formats (.doc, .xls, .pdf, .vsd, .jpeg) (need)
- Location based (nice)
- Adequate coverage (determined by C2000) (need)
- Robust (technical) (need)
- All information digitalised (need)
- All information streams digitalised (need)
- Digitalization of responsibilities within the system (nice)
Performance requirements
The output of the system will also have to fulfil some specific requirements. This part deals
with the representation and content of the translated information. To make this information
reliable a certain quality of the input is required. To avoid unnecessary waiting in time-
critical situations minimum process times are very important as well.
- Good representation of information (pixels + sound) (need)

- Personalized representation of information (font size, colours, etc) (nice)
- Minimum process times (need)
- Up-to-date information (need)
Institutional
Responsibilities
During a calamity, a relief worker should not have to think about his responsibilities or tasks.
It should be clear who his superiors are and who has to decide on what matter. These
different responsibilities should have its result in different system access rights.
- specified system accessibility (need)

- decisions should be made on a level as low as possible (nice)
- hierarchy should be very clear (need)
- clear responsibilities (need)
User requirements
The system has to be used by multiple users from several organizations. The system needs
a matching organisation structure and has to deal with this aspect of several users. To fulfil
the specific needs of different users, the system first has to know which user it’s dealing
with. After that, the interface and settings of the system can be adjusted to meet the user’s
preferences. Requirements that deal with the (physical) use of the devices are left out
because the design of these devices lies beyond our scope.
- Selective authorisation (need)

- Maximum security (need)
- Ease of use (nice)
- Clear user interface (nice)
- Familiar appearance to every relief service (nice)
- Database management should be relatively simple (nice)
- Ability to deal with relief service specific things (special features for firemen, policemen)
(nice)
- Support of personalised settings (nice)
- Ability for users to rank information directly (nice)
- Operational flexibility (nice)

Process
Design process requirements
As the system that has to be developed will be developed on the existing C2000 system, it
can not be individually. Paralysing the whole communication system to implement the new
system is not an option; a process should be defined to ensure an agile union between the
two systems.
- Minimum implementation time (nice)

- Step-by-step implementation (need)
- All parties should be satisfied with the system (need)
- Existence of sufficient exercise possibilities (need)
- All relevant parties should be involved (need)
- 1st line users (police, fire, ambulance) should have a stronger position in the design
process than 2nd line users (army) (nice)
- Frequent information updates for the involved parties during the design process (nice)
- No party should have blocking power all by himself (need)
- Protection of core values of all the involved actors (need)
Cost requirements
Apart from delivering good quality the system should also be affordable. The costs should be
kept as low as possible but no hard restrictions are known. The total costs can be divided
into purchase, maintenance and adaptation costs. The new system could require existing
systems to be changed. These costs are called adaptation costs.
- Low Purchase costs (nice)

- Low Maintenance costs (nice)
- Low adaptation costs of existing systems (nice)

Part II – Designing the Web GMS
Part II consists of three parts: the process design, technical design and institutional design.
The process design identifies the different decisions that need to be made and the sequence
of these decisions. The technical and institutional design elaborate on the topics as defined
in the process design. Many institutional decisions, that need to be made, arise out of the
technical design. For this reason the institutional design is placed after the technical design
chapter.

9. Process design
Most of the design issues and decisions in this report are taken by the designer. Although the
designer tried to take all the different demands and requests of different actors into account,
one can imagine that a project with this size needs participation of the actors themselves.
This chapter provides a design of the design process and therefore gives an extensive
description on how to bring the different actors together. Obviously the results of each step
in the process depend on the input of the actors involved. Nonetheless, in order to deliver a
complete process design, some results are already filled in according to the design provided
by this report. This chapter should be seen as a framework to facilitate and support the
actual design.
9.1 Actors
First step is to determine which actors will participate in the design process. The initiator of
the project, the Ministry of BZK, is free to invite actors who seem to be relevant to the
process. For this process design the group of relevant actors earlier defined in chapter 3
(Actor Analysis) is selected.
- Ministry of BZK
- Ministry of VWS
- Provinces
- District Water Boards
- Municipalities
- Police Department
- First Aid Services
- Fire Department
- Project developer
As said these actors will be assimilated in the process design. The next paragraph will
elaborate on how this process is designed.
9.2 Process design

The process is divided into five rounds (see Figure 9). After inviting all relevant actors the
process starts with reaching agreements and formulating generic process rules. These rules
will be valid during the rest of the process. When this part of the process is settled, a list of
requirements can be made by the actors. There is a chance that some of these requirements
collide with one another. These collisions can be seen as design issues. In order to cope with
these design issues it is expected that certain trade-offs need to be made. Next, the type of
design issue determines which actors will be appointed to discuss these design issues. The
discussions or negotiations, in round 3, will be organised in four different clusters. These four
clusters contain four different groups of actors. The distribution of the actors will be
elaborated on further down. Only when the design issues (possible after much iteration) are
solved, actors can start negotiating on the subject of costs and responsibilities. At the same
moment, designers can start with the technical and institutional design.

Round 1:
Round 2: Round 3: Round 4: Round 5:
generic
requirements design issues costs start project
process rules
Start technical / institutional Start technical / institutional

design implementation
time
Figure 9 – The five rounds of the process design.
As can be seen in Figure 9, the costs process round is placed at the end of the total decision-
making process. This is done for several reasons. First of all, the Ministry of BZK strives for a
technological optimal solution; therefore the issue of costs shouldn’t influence the technical
design process. Second, it should be prevented that paying actors hold a disproportional
influence in the design process. For example, user influence remains important even when
the user pays a smaller part. Another advantage is created by the fact that the actors have
the chance to get convinced by the opportunities of this new system along the process. This
way commitment among the actors is created and this is finally expected to result in more
willingness to contribute and pay for the system. Finally, after solving the cost issues, the
project developer can finish the design and start with the implementation of the project. All
rounds will be described in detail within the following paragraphs.
9.3 Round 1; Generic process rules

During this round the generic process rules will be formulated. Determining the generic rules
will be done based on the four core elements of a process design. The core elements, which
are described by De Bruijn, Ten Heuvelhof and In ’t Veld (2002), contain openness,
protection of core values, speed and substance. The generic process rules should provide
guidance in order to guarantee these elements during the process. The following part will
determine the generic rules regarding each core element.
Openness
This project cannot be realised without the resources (funds and knowledge) of the other
parties. In return, they want to influence the process and in order to achieve this goal the
parties need full information on topics of discussion and negotiation. Besides full
information, the parties should be able to defend their decisions towards the people or
organisation they represent. By guaranteeing openness in the process the represented
parties are able to keep an eye on the process and criticize it where needed.
- All parties should agree with the process design of the clusters and the division of actors
over these clusters.
- The minutes of all meetings should be available for all parties.
Protection of core values

The main core values of the involved parties are transparency, objective decision making
(governmental organisations), environmental security (water boards, fire- and police
department) and social security (police department). These actors are only able to
participate in the process when their core values are protected. When some of the core
values are at stake parties may decide to make use of the following process rules in order to
protect their core values.
- The process outcome should be justified in relation to civilians. The process itself does
not have to be transparent at all times (in order to protect classified information).

- Two exit-points are defined:
- After round 1 (current round)
- Before round 5 (costs)
- Parties who decide to use the exit-possibility before cluster 5 should explain their
decision by letter.
Speed
In order to implement the project, within a certain amount of time, the speed of the process
should be sufficient. The term sufficient is determined based on the project planning. Speed
of the process is also important when considering the commitment of the parties. One of the
solutions to maintain speed in the process is the decision of putting the costs discussion at
the end of the process. The choice to discuss on different clusters simultaneously also
enhances the speed of the process. Other solutions lie in the character of the actors. They
should have enough power to make binding decisions or to persuade other actors to
cooperate (command and control). BZK is given the power to appoint side-meetings with
actors. With this option BZK is able to use its power (command and control) towards other
actors without causing embarrassing situations.
- Trade-offs within clusters are allowed.

- All participants should have sufficient commitment power
- During the entire process BZK will have the right to appoint a side-meeting with other
parties involved. There is a maximum of one other party per side meeting.
- After each cluster, results should be justified in relation to the national parliament, the
regional council, and the involved city councils.
Substance
Finally rules on the substance are of evident importance. These rules should support quality
and objectivity of the substance and furthermore protect the position of the participants. By
the obligation to report to the national parliament, regional council and city council a great
(the latter rule of the set of rules regarding speed) part of the desire to deliver sufficient
substantive quality is guaranteed. Other rules to reach this goal are:
- Include system or design experts in certain rounds

- The role of experts and concerned participants during the process should be clear. In this
way objectivity can be added to the process.
Actor commitment
The C2000 project has shown that actors were willing to participate since they wanted to
avoid other disciplines having too much influence in the project. When a region decides to
develop a water-calamity communication system, the same behavior of the emergency
services can be expected.
The actors concerned in this case are part of a clear hierarchy (see Appendix II). In case
actors do not see the benefits of this project for them and are not willing to cooperate,
command and control is left. This works in two ways:
- A higher placed actor might decide to use its power to persuade other actors to
cooperate. The ability to appoint side meetings (mentioned under ‘speed’) enables
actors to do this in a proper way.
- The actors are obliged to report the results to the people they represent. Since only
governmental organizations are involved, all results must be transparent and available
for citizens. Security and calamity control are sensitive topics. One can imagine that non-
cooperative behavior will lead to objections from the citizens-side. They may decide to
use their (electoral) power also to enforce the actors to cooperate.

9.4 Round 2; Requirements
With the generic process rules formulated the next round can commence. This round will
determine most of the important system requirements. The process of formulating these
requirements will be based on (electronic) brainstorming and is supported by a computer
system. In order to guide this particular process round first some specific rules should be
established. With these rules clear the true process design of this round will be discussed.
Result of this round will be general design issues identified during this round.
Specific process rules

Because each round has different topics on the agenda, one can imagine that this influences
the process rules. To obtain a complete set of process rules, per round specific process rules
are added to the generic process rules. The specific process rules, which are determined for
this round, should direct and facilitate the process in order to enlarge the result.
- For this round parties are allowed to send representatives with less commitment power
but holding more operational experience.
- During the brainstorm the following rules should be complied with:
- The initiator (BZK) takes care of the constitution of the group and takes number and
variety of group members into account.
- Don’t criticise other parties’ ideas (not by word, laugh or other signals).
- The brainstorm should be focused on quantity rather than quality. Speed is an
important issue.
- Participants should actively participate, which also includes listening to each other.
- The brainstorm will be closed by a summary, classification and evaluation of the
obtained requirements and the agreement of all participants on that.
Process design
In order to create a complete set of system requirements all the actors should be involved in
this round. There are several ways to obtain a extensive list of requirements within a short
amount of time. One of the options is using an (electronic) brainstorming tool like the Group
Decision Room (GDR). The GDR in general provides support for five basic activities:
1. Diverge
2. Converge
3. Organise
4. Evaluate
5. Building Consensus
As suggested, thinking about requirements can be seen as a brainstorm session (diverge).

For this reason the GDR is introduced during this round, reason is the importance of speed
during the process. The strength of the GDR holds that the ideas of one actor can be an
inspiration to other actors. After acquiring an extensive list of requirements some form of
convergence and organisation (or classification) of the ideas is needed, these activities are
both supported by the GDR as well. The fourth step is evaluating the list of requirements.
The evaluation will be done through deciding whether a requirement is a ‘need-to-have’ or a
‘nice-to-have’. A detailed design of the GDR meeting which was used for this second round
can be found in Appendix X.
Generally, there’s no discussion about ‘need-to-have’ requirements. These requirements

should be included compulsory and can be seen as the boundaries of the design space. An
important characteristic of ‘Nice-to-have’ requirements is that they can be part of trade-offs
and negotiations. Therefore, the nice-to-have requirements should be compared with each
other in order to see which of them collide. These competing requirements are addressed as
design issues which will be dealt with in the next round (round 3). Defining the design issues
is a task of the initiator (BZK) and needs approval or correction from the other actors before
the start of round 3.

General design issues
In order to describe the following rounds, the list of requirements from chapter 8 is taken.
Furthermore design issues were identified according to the method as described above (see
Appendix XI). A division is made between general design issues and costs design issues. It is
assumed that most requirements will collide with the desire to keep the system costs as low
as possible. The group of requirements regarding costs is taken apart and will be discussed
in a separate round (round 4). The other (substantial) design issues are listed below,
accompanied by a short explanation why these requirements may cause conflicts.
1. Clear and general semantics

Every party has different perceptions of the meaning of clear and general semantics
and what these semantics should look like.
2. Clear and general semantics vs. compatible for extension with other (international)
information systems and trends
Involving more diverse parties and various systems will increase the number of different
semantics that are used.
3. Selective authorization
Discussion concerning the authorization rights.
4. Ability to couple this system to communication systems for civilians use vs. maximum
security
Creating an external link to provide civilians with information enlarges the risk of
spreading classified information.
5. Web-based (possible use of Internet applications) vs. maximum security

Creating an external link to another (global) network enlarges the risk of spreading
classified information.
6. Limited amount of information a particular user in the field should receive vs. decisions
should be made on a level as low as possible
To make well thought decisions sufficient information is needed.
7. Selective authorization vs. decisions should be made on a level as low as possible

Discussion on where to draw the line between selective authorization and the necessary
information to make decisions.
8. Compatible for extension with other (international) information systems and trends vs.
clear operational responsibilities
Involving more diverse parties will have consequences for the existing operational
responsibilities during a calamity.
9. Decisions should be made on a level as low as possible vs. clear operational

responsibilities
A more extensive division of responsibilities makes it difficult to keep a clear overview
of the operational responsibilities.

9.5 Round 3; Design issues
The design issues determined in the last round will be main issue of discussion during this
third round. As with the previous round, some specific process rules are added to this round.
Specially added process rules

- The initiator (BZK) will form different groups of actors and assign particular design issues
to them. When actors disagree with these decisions they hold the opportunity to hand in
complaints, which obviously should contain substance-based arguments why the actor
should be involved in that particular cluster. This also concerns actors who were not
earlier involved in the process. BZK takes these complaints into account and decides for
each cluster what actions to undertake.
- Actors have the right to decide not to participate in the clusters.
Process design
Not all actors have to be involved for each design issue. Table XI.3 (Appendix XI) shows the
actors that should be involved for each negotiation. When comparing the groups of actors
that are needed per design issue the same pattern can be distinguished for some design
issues. These issues are put together in a cluster which enlarges the negotiation package
and the possibility for trade-offs. Furthermore discussing several issues at one time might
contribute to the process speed. In round 3 four clusters can be distinguished (see Figure
10).
Round 3: design issues
Cluster 4
(3-6-7-9)
Round 1:
Round 2: Cluster 1 Cluster 2 Round 4: Round 5:
generic
requirements (2-8) (1) costs start project
process rules
Cluster 3
(4-5)
time
Figure 10 – The design issue clusters.
The different clusters can be seen as arenas, as defined by Cohen, March and Olsen (based
on Koppenjan, 2004). The outcomes of particular arenas will form the input of other clusters.
The decision process within the arena is not linear but is more comparable to a game. Since
different actors meet each other again in other arenas multiple games are played within one
arena. This implies trade-offs among the different clusters are possible within each round.
Cluster 1 comes first at the agenda. The decisions made in this cluster might result in the
invitation of other (international) actors to participate in the process. Therefore it’s
necessary to decide upon this point first. In order to prevent misunderstandings it’s also
important to make decisions relating to the used semantics (cluster 2) before starting with
the other clusters. The issues discussed in cluster 3 and 4 don’t relate to each other directly,
so it’s possible to let them take place in parallel.
The content of the clusters will be discussed below. Besides, process rules for each cluster
are made on top of the generic process rules.

Cluster 1 – compatibility with other systems
Design issues: 2-8
Actors involved: BZK, VWS, PRO2
Specific rules:
- No actors may be invited anymore, except on behalf of BZK.
- In this phase commitment to the project, not to the process, may be
postponed.
- The outcome of this cluster must be notified to the other actors who
did not participate in this particular cluster.
- Each (international) system that will be discussed should be illustrated
by an expert.
Cluster 2 – standards and semantics

Design issues: 1
Actors involved all (except PRD)
Specific rules:
- New actors may only be invited to this round when based on
arguments following from round 1 and with approval of BZK.
postponed.
- The police department, fire department, first aid services and BZK
have votes with the weight of two at one’s disposal where the other
parties have votes of the weight of one. This is done because the three
emergency services are the most important operational actors and BZK
is the initiator of the process.
Cluster 3 – external systems and security

Design issues: 4-5
Actors involved: BZK, MUN, PD, PRD
Specific rules:
postponed.
- Security (IT) experts should be involved to guarantee a certain level of
quality in the decisions made.
Cluster 4 – responsibilities and authorization

Design issues: 3-6-7-9
Actors involved: DWB, MUN, PD, FD, FAS
Specific rules:
postponed.
- Decisions may not be in conflict with existing operational plans.
2
The used abbreviations correspond with those used in Appendix 1; a legend is to be found there.

- Because all involved parties should accept the system, responsibilities
and be able to work with the system, an unanimous approval is
required.

9.6 Round 4; Costs and responsibilities
With the design issues solved the next step is the division of the project and system costs.
As seen with the previous two rounds specific rules are formulated in order to support the
process.

- Point of no return, commitment may not be postponed
- Actors have the right to decide not to participate in the project (exit option).
Process design
Costs as earlier explained are placed at the end of the process for several reasons. With the
requirements for the technical design clear, determining and dividing the costs will result in
financial constraints and possibly influence the solution space. Therefore balancing between
on the one side a technological right solution and on the other side financial feasible solution
brings complexity to the process.
The costs, as can be seen in Appendix XI.2, are divided in purchasing, maintenance and
adaptation costs. The purchasing and adaptation costs are expected to be one time
expenditures, the so called investments. This in contrary with the maintenance costs, which
probably will recur each determined period, also known as the exploitation costs. The C2000
project documents use the terms investments costs and exploitation costs, so it may be
useful to hold on to that terminology. Because of their different nature these costs are, like
round 3, placed in separate clusters. The two clusters formed, as illustrated in Figure 11, can
be executed at the same time. This simultaneity is only possible when all parties are able to
delegate more than one person responsible for the decision on funds.
Round 4: costs and

responsibilities
Cluster
(Invest-
ment)
Round 1:
Round 2: Round 3: Round 5:
generic
requirements design issues start project
process rules
Cluster
(exploi-
tation)
time
Figure 11 – The costs clusters.
As seen in round three, trade-offs among the different clusters are possible within this round
as well.
The exact costs of the project should be determined once the technical design is completed.
In order to draw up a cost distribution, an estimation will be sufficient in this phase. The
distribution of the costs will be done based on an analogy. The cost of the project is
computed by comparing the project to the C2000 system. It should be noticed that this
comparison only serves as a guideline for this process round. Yet the analogy is expected to
be rather accurate because there is recent project data available, which includes a
systematically maintained cost sheet. Because division of costs in this phase holds a division

in percentage, the sheet should be converted. In order to create a thorough division of the
costs experts, with their experience to predict project costs, will be used. These experts
should judge and adjust the result. This control is
relatively cheap and
can be quite accurate since experts have direct experience regarding similar projects.
The result of converting the similar C2000 project and subsequent adjustments will form the
base, and guidelines, for the discussion within the two clusters. The parties will discuss and
negotiate on small margins which are determined by operational advantages regarding the
different parties.
Different types of costs and responsibilities were identified based on the C2000 project.
Table 4 shows which actors were responsible for them at the time. Several trends could be
distinguished. The central government was mainly responsible for the investment costs and
took responsibility for central tasks. On the other hand, local governments were responsible
for keeping the system running over time.
Table 4 – The costs and responsibilities regarding Web GMS.

Actors Costs Responsibilities
BZK (including VWS and Investments - Project organisation
Defence) - Infrastructural costs - Equipment purchase
- System coverage costs - Support regions
- Central project - Connection with central
organisation costs systems and GMS
- Central administration - Provide project
organisation costs information
- Pilot projects - Security
Central exploitation
- Infrastructure related
costs (e.g. maintenance
of lines, switches etc)
- Network management
- Pay off loan3
Regions (Emergency Investments - System implementation
Services and local - Equipments costs - Equipment purchase
governments) - Education costs - Local maintenance
- Regional project costs - Security
- Training
Regional exploitation - Education
- Employees salary - Spatial coverage
- Equipment maintenance planning
Project developer - Infrastructure realisation
- Central project
coordination
- Project guidance
- Implementation support
With regards to round 4, this division of costs and responsibilities will function as a
framework for the actors to start with. To make sure the project will succeed some costs are
coloured black. These costs must be paid by that particular actor. This will also provide the
3
As previous projects show it’s not unusual for the central governments to provide loans without
interest to lower governments. Since no interest is brought into account this will result in costs for the
central government.

actors some hold, because starting with a green field might be difficult. The nature of the
grey coloured items doesn’t tell whether this is a typical responsibility for one particular
actor. Therefore they are part of trade-offs. This also means that packages will contain a
mixture between costs and responsibilities.

9.7 Round 5; start project
With the substantial design issues and costs division determined, the start of the project
follows. The start of the project is characterised by negotiating on contracts which are
formally arranged in this phase. The arrangements include the responsibilities and costs as
discussed during previous rounds of the process. In order to keep commitment to the earlier
taken decisions in previous rounds, round 5 should take place directly after finishing round 4.
This avoids misunderstandings and discussions about earlier made decisions. This is
indicated in Figure 12.
Round 1: Round 4:
Round 2: Round 3: Round 5:
Generic Costs and
Requirements Design issues Start project
process rules responsibilities
time
Figure 12 – The clustering of round 4 and 5.
As Figure 9 shows, the design process starts immediately after round 3. Round 5 provides
actors the opportunity to comment on those initial designs (made by professional designers)
and to compare them with the program of requirements (round 2). After approval of the
designs by all the actors the contracts can be signed. This will be the kick-off of the
implementation phase. In order to facilitate this round special process rules were made.

- An independent judicial expert (assigned by BZK) must be present during this round.
- All participants must have sufficient rights to decide on high-level arrangements.
- Each party is allowed to invite his own legal adviser.
The technical design and institutional arrangements will be extensively described in the
following chapters.
9.8 Process design reflection

Appendix XI.4 shows an overview of the process design compared to the process
requirements. Since this design ends with the start of the project it was hard to say anything
about the implementation requirements. The other requirements were fulfilled by one or
more rounds.

10.Technical Design
In this chapter, the technical design will be worked out. First, the “Geintegreerde Meldkamer
Systeem” (GMS) will undergo a more in depth analysis, to get sufficient insight in the current
deficiencies in information exchange during calamity control. Next there are bottlenecks
identified according to the current situation and necessary modifications are proposed to
solve the bottlenecks. In following the Service-Oriented Architecture is presented to obtain
the identified opportunities. Then, a framework will be drawn up for the design of the system
that should cope with these deficiencies. This framework will be based on the Service
Oriented Paradigm, and will be specified on applications in water calamity control. Finally,
the proposed technical design will be presented and the improvements will be described.
10.1Current situation GMS

In this paragraph, a more detailed view on the current technical situation will be generated.
The basic technical design behind the information provision during calamities is covered by
the C2000 communication system. The C2000 network connects relief services like the
police, fire department and ambulance services as well as the military police.
Each emergency room has as main function to divide users in groups based on their
situation and authority during a calamity. The involved emergency workers receive relevant
information, in which the relevancy is determined by the controllers (or centralists) in the
emergency rooms. A positive aspect of this construction is the coupling of relief services by
C2000 to the GMS operators from different disciplines. This provides the opportunity to share
information with each other, which can lead to qualitative better information provision
(Ministry of Interior and Kingdom Relations, 2004).
The most important activity of the centralists, the communication with the relief services via
C2000, is provided by a data communication server (DCS). The DCS is the connection
between the internal network of the emergency room and the outside communication
networks (Ambucom, 2005). In order to work as efficient and effective as possible, the
centralists have sophisticated workplaces, where a lot of telecommunication and automation
systems are installed (Pieters, 2006). This includes a certain amount of terminals and
monitoring devices that connect them with different information systems, databases and the
internet. Lastly, each workplace within the GMS contains an ARBI, which provides the direct
connection with the outside world. This kind of computer telephones create the possibility to
connect every service and authority instantly.

Network GMS Operational Information Systems
Diverse Emergency Room

analogue mobile
networks
CMS System
ARBI’s OMS System
C2000 Data Communication GIS Systems

Server
Terminals
Etc.
Internet
ARBAC
PC’s Monitoring Devices
CCS-Vnet
Figure 13 - Schematic overview of the current situation of GMS.
Figure 13 provides a schematic overview of the operational information systems linked to

the GMS. These systems are, among others: the CMS system, OMS system, GIS system,
ARBAC, and CCS-Vnet. The CMS system is the information system that establishes the
connections between the emergency rooms and the relief services. Another important
system is CCS-Vnet, that functions as the Command and Control System in calamity control.
Furthermore, there are terminals that provide visualization which constantly bring out
reports; and example is the OMS system that, in the case a fire occurs, helps visualize the
location of the incident. Finally, there are terminals that control old analogue mobile
systems, such as ARBAC.
10.1.1Problems arising due to the centralized nature of GMS

The described situation implies a very centralistic approach in which information provision is
fully dependent on the centralists in the emergency room. Information required by relief
workers is provided by the centralists, who attain the desired information from different
systems, databases and the internet (Pieters, 2006). In other words, the information is
provided on a push basis. Although the opportunity for relief workers to pull information
exists, all information flows via the centralists. Except the inefficiency in time of such an
intermediate station, there is a chance that the emergency room employees do not provide
the precise required information, because of misunderstanding and/or misinterpretation.
Another bottleneck is formed by the voice-based nature of the provided information. It is
generally acknowledged that voice has its limitations. For example, a schematic figure can in
one glance provide a lot of information on the structure of an area or location. Accomplishing
the same via voice is almost unrealizable and therefore very inefficient and ineffective.
Therefore, a more decentralized approach seems desirable. Much information could be

provided digitally, not only push-, but also pull based. Moreover, interactive content such as
weather information, GIS maps, emergency plans etc. could better be provided to a relief
worker via some kind of interface instead of voice. In any case, a more decentralised
approach asks for a division in the supply of different types of content. This division will be
discussed in the following sections.

10.1.2Necessary technical modifications
To succeed in applying a decentralized approach, modifications in the technical architecture
of the GMS are necessary. This approach, which will make pulling information by the relief
services possible, asks for a more layered structure. The current voice communication with
the emergency room can be seen as a one layered system. Another layer will have to be
added, which performs the transition and transportation of data information between the
relief services in the field and the operational information systems. Figure 14 sketches this
layered concept by two parallel lines from the network to the information systems.
GMS
Data layer
Operational
Network Information
Emergency Systems
Room
Figure 14 - Schematic overview of the layered proposition of GMS.
To make data communication on this new layer possible, certain technical elements need to
be implemented. The idea was suggested that a relief worker should have access to the
available information systems and databases via some sort of interface. Such an interface
can figure as the entry point to every individual system. To make this technologically
possible there are two general methods available (Kar and Verbraeck, 2005):
• The different systems and databases should all be integrated in one overall system.
• The systems and databases should somehow be placed in an organized way next to each
other, in which only the interfaces are integrated.
If cost efficiency and operationally are taken into account, the first option is far from optimal.
Considering the large amount of operational systems and databases, which are consulted by
the centralists in the emergency rooms and the high percentage of legacy systems (systems
considered not up-to-date regarding the technical architecture) this seems to be an
impossible and costly mission (Kar and Verbraeck, 2005).
The second option seems more viable. As mentioned in section 5.4, The Flood Information
and Warning System (FLIWAS) is the most promising project with regard to supporting
calamity control information streams (International Commission for the Hydrology of the
Rhine Basin, 2006). “FLIWAS is an information- and communication system designed to
collect and process information and proposes and manages actions before, during and after
a flood event and make this information available to various groups of users according to
their specific requirements” (International Commission for the Hydrology of the Rhine Basin,
2006). Efficiently connecting FLIWAS to the GMS can provide a great expansion of the digital
information resources. Moreover, digital information streams could offer better support and
higher quality to the cutting necessity for cooperation and coordination.
10.1.3Method proposal: Service Oriented Architecture

A well-known example of a method that can build the technical architecture in such an
organized structure is the Service-Oriented Architecture (SOA) approach. In its most basic
form, a SOA is a collection of services on a network that communicate with one another.
Apart from being an architecture of services seen from a technology perspective, a SOA also
concerns the policies, practices, and frameworks by which it ensures that the right services
are provided and consumed (Sprott and Wilkes, 2004). The services are loosely coupled,
meaning that an application does not have to know the technical details of another
application in order to communicate with each other. Furthermore, the services have well-

defined, platform-independent interfaces, and are reusable. A SOA makes it easier to
integrate the whole IT environment; therefore it works very well in heterogeneous
environments. Moreover, SOA provides a higher level of application development that, by
focusing on business processes and using standard interfaces, helps to mask the underlying
technical complexity of the IT environment (Datz, 2004).
This mask is usually exposed in the form of a portal. A portal functions in this respect as the
interface or, in other words, as a web-based service that offers a broad array of resources
and services (Datz, 2004). In general, the technical design of the new data layer can be
divided into two components:
− The front office will be formed by a web-based portal (the interface).
− The back office will be organized according to the SOA concept.
10.2Service-Oriented Paradigm4
In order to involve all the important aspects that need to be considered when implementing
a Service-Oriented Architecture, a framework will be used as a guiding principle. Papazoglou
and Georgakopoulos (2003) provide a Service-Oriented Computing paradigm (SOC), which is
perfectly suited to fulfil this task.
Figure 15 - Extended service-oriented computing paradigm (Papazoglou and

Georgakopoulos, 2003).
Figure 15 shows the extended service-oriented computing paradigm (SOC). Three

dimensions can be derived out of this paradigm: the actor dimension, the service layer
dimension, and service functionality dimension. Each of these dimensions will be shortly
explained for the case of developing and maintaining the SOA for GMS. In the following
sections, every dimension will be undergo a more in depth analysis with respect to the case.
10.2.1Actor dimension
This dimension appoints the different actor groups involved and their roles considering the
SOA to be designed. Five main actors can be identified in the SOC paradigm: the Service
provider, the Service aggregator, the Service operator, the Market maker, and the Service
4
Based on Papazoglou, M.P. and Georgakopoulos, D. (2003).

Client. Table XII.1 in Appendix XII gives an overview of the different actor groups and their
specific roles.
In a SOA it is critical to implement processes that ensure that there are at least two different
and separate processes: a process for the service provider and a process for the service
client (Sprott and Wilkes, 2004). The centre of attention for the service provider and the
service client is the interface (or web-based portal). This is the component of the SOA where
both processes will have to meet. For the service client, the process must be organized in
such a way that only the service interface matters, and there must be no dependence upon
knowledge of the service implementation. If this can be achieved, considerable benefits of
flexibility accrue, as it is difficult for the service provider to make well-founded assumptions
about service client behaviours. The service provider concerns are to develop and deliver a
service that can be used by the service client in a completely separate process.
Obviously, the service clients and service provider will have to come to agreements on how
to fit out their processes so that they can be effectively linked to the interface. The content
of this interface will be discussed in the next section. The identification of possible problems
caused by the originated actor arena will be discussed in the institutional analysis, which is
performed in chapter 11.
10.2.2Service layer dimension

In this dimension, the fundament of the SOA will be formed: the new system should exist of
one composite service, which will be disseminated by a portal. According to the SOC
paradigm the structure of SOA can be described according to three service layers:
Management, Composition, and description and Basic operations. Table XII.2 in Appendix
XII.2 provides the theory behind the three layers including their definition and further
details. The most important aspects of the three service layers are treated in the sections
below.
10.2.2.1 Description and basic operations layer

The SOA’s foundation is constituted by the basic services, their descriptions and basic
operations, in the description and basic operations layer. This layer is a description of the
services to be included by SOA and their basic operations. In the first paragraph of this
chapter there were already some systems and databases mentioned which services are
used. In order to get an extended overview, the different systems and databases used by
the emergency rooms to collect information need to be determined. Table XII.3 in Appendix
XII gives an overview of the main systems and databases on this moment used by the
emergency rooms and optional systems to be used in the future. The services are shortly
described and their basic operations are mentioned.
10.2.2.2 Service composition layer

This layer forms the core of the three service layers, as it identifies the different services
that can be offered by GMS and categorize them into service groups. The service
composition layer encompasses necessary roles and functionality for the consolidation of
multiple services into one single composite service.
The resulting composite service may be used by service aggregators as components (basic
services) in further service compositions or may be utilized as applications by service
clients. Service aggregators develop specifications and/or code that permit the composite
service to perform functions that include coordination, monitoring, conformance and quality
of service composition. In a SOA environment service aggregators thus publish the service
descriptions of the composite service they create.
In order to accomplish an efficient aggregation, Sprott and Wilkes (2004) claim that the
structure of a SOA can be divided in three sub-architectures. Based on the division in sub

architectures the different elements that are needed to provide the composite service can
be identified. The three architectural perspectives are listed and shortly elaborated below5.
They are subsequently sketched in Figure 16.
− The Application Architecture

This part provides a business-oriented solution that uses services from the service
provider. Furthermore, it integrates these services into business processes, which will
accordingly be provided to the relief services. Interaction is usually provided by a web-
based interface, such as a portal.
− The Service Architecture

This part provides the bridge between the implementation and the used applications,
creating a logical view of sets of services which are available for use, invoked by a
common interface and management architecture.
− The Component Architecture

This part describes the various environments (systems and databases) supporting the
implemented applications. These elements were defined in the previous paragraph.
Figure 16 shows that other component architectures, such as FLIWAS, can also be
covered in the SOA.
Portal
Application interface
Architecture
Service
Domain
Routing
Service
Architecture
Service
Routing
System
Fliwas
Component Architecture Database
Figure 16 – Architectural backbone of the SOA to be designed (based on Sprott and Wilkes,
2004).
5
Based on Sprott, D. and Wilkes, L (2004).

The decisions made above are all theoretically based. This theory provides the foundations
of a more concrete technical design, which should include the different technical elements
taken up in the proposed architecture as sketched in figure 4. Identification of these
elements can occur through the description of service routing and domain grouping.
Service routing
At the core of the SOA, services should be managed as first order deliverables (Sprott and
Wilkes, 2004). In order for the relief services to be able to send a request at the portal for
any service located in any service domain, the service-oriented architecture must provide
location transparency. At the same time, accessing the service repository before each
invocation of a service can be a time-intensive process (Nadhan, 2003). Therefore, the
service architecture should be able to obtain the following functions:
− Provide location transparency to the systems and databases in the component
architecture.
− Ensuring acceptable system performance levels.
− Contain the possibility to be managed individually and in sets.
To solve this service-routing challenge, the current technique provides two general ways,
namely via intelligent services or via routers (Nadhan, 2003).
• Intelligent services: This technique is the approach by which location information is
built for all services into each individual service.
• Routers: The routers approach makes it possible to move the routing intelligence
from the individual services to a routing component.
The requirements defined in chapter 8 serve as the foundation on which the choice for an
approach is based. Requirements that should be addressed here are high reliability and
minimum process time (need to haves), while low maintaining costs would certainly be
desirable (nice to have). These requirements can not be obtained through the intelligent
services approach, as this approach eliminates some steps. The intelligent services
approach relies on a particular intelligence in the databases and systems to directly
communicate with the application architecture. This will lower the implementation costs, but
results in an overloaded service (Nadhan, 2003). A system as crucial as GMS during
calamities, may never fail and certainly not because of an overload of requests. Next to this
the intelligent services approach is inflexible to changing in services, which would mean for
GMS to be a maintenance intensive system.
In contrast, the routers approach is far more reliable, with faster processing times, while
needing less maintenance. The requirements are met by the leveled structure of this
approach, through which the load per component is reduced. The routing components can
be divided into two levels (Nadhan, 2003):
1. Service domain routing level

A service domain router has intelligence about the location of all service domains. Upon
receiving a request, it determines if it can service the given request by using one of the
services it supports. If so, it processes the request. If not, it passes the request on to the
appropriate domain that can service the request.
2. Service routing level
A service router is used within a service domain to direct the incoming request to the
appropriate service within the domain. Only those requests that can be serviced within a
given service domain are passed on to the service router. The service router reduces the
load of the location information on the individual services.
The two-levelled structure makes it possible for decisions concerning coordination,

cooperation, monitoring, conformance and quality of service composition to be made at the
service routing level, rather than for each individual service (Sprott and Wilkes, 2004).

Therefore, the routers approach will be applied to meet the systems needs and
requirements.
Service domains
Another important that should be clarified when identifying the technical elements of the
system to be designed, is the classifying (or grouping) of services into the different domains.
Classifying services into logical service domains simplifies the architecture by reducing the
number of components to be addressed (Nadhan, 2003). Examples of the service domains
relevant for this case are given in Table XII.4 in Appendix XII. Several approaches exist to
group the identified services into domains. For this analysis, the functional domain approach
will be applied.
Functional domains are based on the business functions being served by a set of services
(Nadhan, 2003). This approach states that the service operators define and segregate the
business functions and, therefore, the service domains. Through such groupings, service
operators can have autonomous control over the services within a particular domain. As
mentioned in the previous section, there will only be one service operator; the technical
management of GMS. This management will thus have the autonomous control on the
service domains of the system to be developed. The process of grouping is treated in the
process design (chapter 9).
Decisions concerning routing and grouping of domains leads us to how the routed and
grouped information becomes available to the service clients by means of visual content in
the application architecture. Firstly, it needs to be determined how this is performed by
means of a web server and subsequently the interface or portal is described, which will
perform as the connection between the service client and the GMS system (including the
service provider).
Service application through a web server

In order to display the information from the different systems and databases through the
routers into content usable for the relief services, the information goes through a transition
process. In this respect, the application of SOA on an interface is manifested by web services
(Papazoglou and Georgakopoulos, 2003). A web service is a specific kind of service that is
identified by a URI, whose service description and transport utilize open internet standards
(Datz, 2004). Interactions between web services typically occur as SOAP calls carrying XML
data content. Interface descriptions of the web services are expressed using Web Services
Definition Language (WSDL). The Universal Description, Discovery, and Integration (UDDI)
standard defines a protocol for directory services that contain web service descriptions
(Papazoglou and Georgakopoulos, 2003). UDDI enables the relief services to locate
candidate services and discover their details. Service clients and service providers utilize
these standards to perform the SOA’s basic operations. Service aggregators may use the
Business Process Execution Language for Web Services (BPEL4WS) to create new Web
services by defining corresponding compositions of the interfaces and internal processes of
existing services (Papazoglou and Georgakopoulos, 2003).
Service portal
The service portal (or interface), which links the service clients to the GMS, will be
implemented on web services, using SOAP calls carrying XML data content. However, the
specific content that will be displayed when a service client enters the portal is dependent
on the negotiation process between the service provider, service aggregator and service
clients. Considering the defined requirements on the information quality and quantity, and
the technical, institutional and process requirements this will be a difficult decision making
process. Solutions for these difficulties should be sought in the process- and institutional
design.

10.2.2.3 Service management layer
To manage the critical composite service and all that it covers, the paradigm provides
managed services in the top layer. The responsible actor, the management of the GMS,
should have different instruments available to manage critical applications and specific
markets (see Table XII.2).
A separate management platform creates a level of flexibility that allows the exposed
service (e.g. the service used by the service clients) to be adjusted without modifying the
underlying components. The key to separation is to define a virtual platform that is equally
relevant to a number of real platforms (Sprott and Wilkes, 2004). The virtual SOA platform
comprises a blueprint which covers the development and implementation platforms. This
blueprint provides guidance on the development and implementation of applications to
ensure that the published services conform to the same set of structural principles that are
relevant to the management and consumer view of the services.
An important actor in the management layer is the market maker, who has the end-
responsibility over the service management layer. Normally, this is a consortium of
organisations that brings the suppliers and vendors together in an open service marketplace
(Papazoglou and Georgakopoulos, 2003). However, in this respect the Ministry of BZK is just
one organisation and there is no open market. The method of appointing providers,
aggregators and clients is a closed process in which BZK will have an exclusive position. This
has large implications for the arena in which the different actors perform and this issue will
therefore be further elaborated in the institutional design (chapter 11).
10.2.3Service functionalities dimension

This layer is strongly related to the service layer dimension. The three layers all define
different services. The description and basic operations layer provide basic services. These
basic services can be divided in the ‘simple’ services, which are services directly translated
from one system or database, and the more ‘complex’ services, which are formed by
combining existing systems and databases to create new services. An example of the latter
is the FLIWAS system.
The service composition layer delivers composite services. These services have as purpose
to perform coordination, conformance, monitoring and/or Quality of Service considering the
basic services. Finally, the service management layer provides managed services. As the
name already implies, these are services that support management activities. Examples of
these activities are certification, design of Service Level Agreements, operational support
and operational assurance.
10.3 Proposed technical design: the WebGMS

The SOC paradigm covers a great part of the facets that are of importance concerning the
implementation of a SOA into the GMS infrastructure. It has become clear which actors are
involved in the technical element of GMS and what their basic roles are. Subsequently, the
different services that need to be covered by a SOA have been defined. Furthermore, the
technical elements required to make the SOA operational have been identified according to
the division in three sub architectures. As a result, a proposition of the technical design for
the new system can be done: WebGMS.
Figure 17 shows the concept developed by means of the sub architectures. In order to
distinguish the differences with the current situation, the idea of Figure 1 has been used as
reference. The figure will be clarified by means of the sub-architectures and the technical
decisions made.

Figure 17 – Schematic overview of the WebGMS.
The component architecture is presented by the diverse operational information systems

and databases. Adjustments have not been made on the systems and databases
themselves. It is the SOA that makes communication between services possible, which is
indicated in the figure by the structure of the connection. The structuring of the services also
indicates the loosely coupled character as being part of a SOA. Furthermore, the figure
shows that new innovative systems as FLIWAS can be integrated into the technical
architecture. To keep sufficient overview, the figure does not identify the grouping into
different domains, as not all the systems and databases are displayed.
The service architecture is composed of the leveled structure, in agreement with the chosen
routers approach. This is represented by the service routers and service domain routers
situated in the GMS. The two-level structure makes it possible that decisions concerning
coordination, cooperation monitoring, conformance and quality of service composition can
be made at the service routing level, rather than for each individual service.
The application architecture is presented by the two layered structure. On the one hand
there is the voice layer, which functions the same as in the present situation. The Data
Communication Server provides the necessary functions for proper operation. The second
layer is the data layer, which is based on the entrance via a web-based portal. The portal is
manifested by web services, using SOAP calls carrying XML data content. The portal is
supported by a Web Server, which provides the necessary content and functions for the
portal to operate.
10.3.1Improvements
The implementation of a SOA approach into the GMS system clearly provides a more
decentralized situation of the information provision. The developed concept gives a relief
worker the opportunity to not only receive core information content via direct contact with
an emergency room operator, but also more interactive content via a data channel. This
decentralized approach concerning the information provision offers two major
improvements:

− A more efficient calamity control, due to saving time by less communication and
workload considering the emergency rooms
− A more effective calamity control, due to less misunderstanding and
misinterpretation concerning the communication of information that is non-
convenient as voice communication.
Another improvement of the WebGMS is that a division can be made in push- and pull based
information. Push based information will be provided in a standardized format by the GMS.
The GMS has the possibility to select the users that will receive a particular message. For
example, medical information on the type of casualties can be directly sent to GHOR-Service
clients and required evacuation capacity to the police department. Pull based information is
demarcated by the options available in the interface’s options menu (see section 10.4). This
information to be collected can thereby be of such a type, which in the current situation is
not possible to obtain. Information in the appearance of figures, plans, pictures and even
streaming video can be possible. Take here in consideration that the technique is able to
deliver the required systems and facilities.

10.3.2User interaction
An element that has been left quite underexposed is the interaction of the service clients
with the portal. In this section, a short analysis with regard to the user interaction will be
performed, by making use of Unified Modelling Language (UML) diagrams.
UML is designed to let service providers and service clients view a software system from a
different perspective and in varying degrees of abstraction (Kar and Verbraeck, 2005). UML
diagrams can be a very helpful in defining the technical part of a service system. UML
provides two sorts of diagrams that are best suited to generate insight on the interaction of
the relief services with the portal. A use case diagram is used to display the relationship
among actors and use cases. A sequence diagram displays the time sequence of the objects
participating in the interaction (Kar and Verbraeck, 2005).
The use case by means of the interaction with the WebGMS is sketched in Figure 18. It
displays an overview on which activities and processes are present. It starts when a relief
worker turns on his device and automatically logs in onto the central system (CMS). The
operators in the emergency rooms divide the logged in relief workers into groups based on
the situation and personal authority level. When the relief worker feels the need for
information, he browses on his device to the GMS portal. As defined earlier, the portal is
supported by a web server, which provides the necessary functions. On the portal the relief
worker selects the required information source and searches for the necessary information.
When the required information has been found the relief worker will use this according to his
personal purpose.

Figure 18 – Use case diagram of the user interaction with the GMS system via the portal.
To see how such a chain of activities is technically accomplished, Figure 19 sketches a

sequence diagram. As stated such a diagram focuses on the time sequence of operations.
The sequence diagram exposes the required involved objects and the communication
between them. The log in to the CMS system is indicated. Furthermore, the interaction of the
relief worker with the GMS portal is indicated for the data streams that are necessary to
display the portal and to search information on the different information systems.

Figure 19 – Sequence diagram of the user interaction with the GMS system via the portal.
10.4Interface
Agreements will have to be made on the design of the interface. Points of attention here are
the type of menu, the method of establishing a connection, a clear listing of the local
responsibility chart, etc. The application should not be too extensive, and should ensure the
device is easy to handle in crisis situations. In other words, the number of questions and
terms in information provision will have to be limited. This is necessary to avoid
ambiguousness and vagueness in information streams. To ensure that the available options
are sufficient and complete, the following arrangements will have to be set:
- The GMS will send a standardized template to all end users involved in the calamity. This
template customized on the basis of the user’s place in the hierarchy, and his tasks and
responsibilities. Every template is specifically constructed for the calamity at hand, and
can even be specified for the stage the calamity is in.
The characteristics of the template makes generic applications possible. In other words, a
template for a water calamity, a terrorist attack, a fire calamity, etc. can be developed. A
distinction in templates will also be made for each phase of the emergency (monitoring,
scale-up, evacuation phase, flood and return). To avoid misunderstandings and delays the
interface will contain an options menu.
There is a limited amount of information/options/domains on the templates to enable

transparency and usability. In Appendix XV a more elaborate list of the information structure
can be found.

Figure 18 provides an example of a possible interface for a police agent during an
evacuation in a water calamity.6 In the figure the following components are visible:
- Main; the user can go to main menu, with an overview of the options and basic things
like placing a reaction, consult his personal to-do list, or notify colleagues, subordinates
or superiors. Also information on working schedules can be read here.
- Tasks, Responsibilities and Law (TRL); there is a list with responsibilities and tasks,
generic and specific for the user, including the time sent and urgency level. The user can
consult this also when there is uncertainty regarding the legal basis of actions, or about
the manner in which to act. By touching a certain task, the user can see the
specifications of that certain task. It can then choose to add the task to his to-do list or
not.
- Map; the user can access a map, on which not only information is put regarding traffic
flows, but also on the evacuation area (numbers of persons left, location, etc.). Through
different buttons the user can let the map show different types of information on the
map, and can choose which information will apply to him or her.
- News bar; a news bar shows current developments on water levels, status of evacuation,
and other interesting subjects.
ns missing --- More rain tomorrow --- Heavy congestion towar
User: 1052381
Main TRL Map Phase: E
12.35, 06/06/06
T R L
Looting shopping centre ‘ de
12.28 !!
Vijfhoek’…
Evacuation of the following
12.04
streets: Handboogstraat, I…
Resistance inhabitants of
11.45 !
Klinkerweg 5: 3 agents ar…
Traffic diversion: In the
11.40
northern part of Oss. P…
Protection of special objects:
11.22
In the centre…
Looting Shopping centre ‘de

Vijfhoek’, location
Sender : Commander Surie
Type: Order /Personal
Specs: Immediate assistance required in order
to restore and maintain peace at
shopping centre . You have to check in
at group 3, Lieutenant Schipper , on the
corner of Lage rweijweg and Klapperdijk
before 13.00
Figure 18 - WebGMS template
6
This example is solely given to give the reader a broad idea of the requirements of a GMS template. It
is recommendable to perform further research on the user-friendliness, flexibility and entities that
should be included in such a template.

11.Institutional design
The institutional design of the WebGMS (WGMS) will elaborate on the four layer model
discussed in chapter 6. The formal tasks and responsibilities will be respected by the new
system as drawn up in the different calamity plans (layer 3). Moreover, no other
organizations will be involved in the new system design than Dutch organizations (layer 4).
Thus, the new system builds upon the top layers of the four layer model and will be
designed to tackle the problems that have arisen in layers 1 and 2. Shortly, there were two
main institutional problems:
• Adaptation of the communication system

Special attention is needed here for a uniform usage of the C2000 system,
along with communication protocols and codes
• Internal cultural differences between relief services (or all actors involved?)
Cultural differences are currently likely to cause vagueness between relief
services, as a result of a different use of terms and standards. The design
proposal seems to be suitable to seize this problem.
11.1Theory on institutional design

Before implementing the institutional design, it is of importance to treat a few relevant
theoretical subjects. Firstly, some important institutional design principles are introduced.
Then, some elaboration is given on the implementation challenges of an institutional design.
11.1.1Design principles
The principles behind a government’s approach to an institutional design are credibility,
flexibility and democratic legitimacy (O’Donnell & Bhundia, 2001). Credibility in institutional
design implies a high degree of transparency. All institutions involved in the process should
be able to have an overview of the events occurring during a calamity. Moreover,
transparency gives structure to accountability, so that possible sanctions can be justly
allotted. Flexibility gives the policy maker the ability to react sensibly to unexpected events.
Obviously, the chance of such events occurring in a water calamity is very high and thus is
very relevant for the institutional design. Finally, democratic legitimacy is important,
because policy should reflect a consensus among all actors involved. This implies a
supportive policy, regulatory, and legal environment. Suberu and Diamond (1999) argue that
important characteristics of legitimacy are fairness, probity, a rule of law and (again)
transparency.
For the development of the WGMS, some case specific design principles should be taken into
account. In the first place, it is essential that the WGMS to function properly at all times.
Therefore, institutional arrangements should be set to insure the reliability of the system. A
second case-specific design principle is scalability. The WGMS should be able to run on a
large scale of different systems, regardless of the magnitude of the water calamity.
11.1.2Implementation challenges in institutional design

The latter leads to another important aspect in the institutional design: norms and values.
Understanding norms and values is part of institutional analysis (Ostrom et al., 1993) and
reaching consensus is very dependent on the way that is dealt with them. It is to be
expected that a fireman uses different terms for a particular situation than a government
official. Moreover, the way actors deal with each other in their own communities can highly
differ from other communities. In any case, it will be essential for all actors using the system
to understand the information provided by each other. Consequentially, conflicts over
changing the way actors should present their information and thus their social norms
(Knight and Ensminger, 1998) could arise, hampering the effectiveness of the institutional

design. Prescribing all actors one single form of presenting their information could be
problematic.
The central point of attention here is to clarify the usefulness of the institutional change in
the process design (chapter 9), and provide the insight that it is crucial to solidify change
over time through efforts of enforcement. Etzioni (1993) stresses that quantifying the
amount of time needed for this change is crucial for bringing the transition into perspective.
The change to the WGMS system will require an enormous amount of effort (and thus time)
from many people, whom all have their own interests. One of the major lessons in the
analysis of institutional change is specifying the details of the situation that is being
analyzed (Feeny, 1993). This should be taken into account when bringing in particular
segments of the institutional design: this implicates the need for a clear overview of the
time sequence of institutional changes.
11.2Institutional arrangements
The design principles described above form a good foundation for the institutional design. It
is now of importance to link these principles to the institutional requirements of the WGMS.
Thus, the requirements identified in chapter 8 should be translated to institutional
arrangements. Institutional arrangements inform decision makers about their standing and
about the consequences of their behaviour (Feeny, 1993).
The theory as discussed above tells us “how” to make an institutional design. When deciding
on “what” to design, the process design could be of good use. To create a clear overview of
these institutional arrangements, they can be categorized according to their characteristics.
The system designer first has to wait until the actors have made their decisions as described
in the five rounds (chapter 9). With that output the designer can make the last design
decisions and start to build some prototypes. The following paragraphs have the same
structure.
Firstly, choices for substantial design issues as discerned in the process design are made, by
filling in the outcome of the four clusters, as identified in round three of the process design
(chapter 9). For every cluster, the most important institutional arrangements are discussed.
After that, the remaining design choices are summed up, along with their necessary
institutional arrangements.
11.2.1Compatibility with other systems

The systems connected to the GMS are described in the previous chapter. Obviously, the
information that should be linked to the system is dependent on the location of the water
calamity. For example, a water calamity that occurs in the Beersche Overlaat will require the
databases or systems of the local water district boards, municipalities such as Cuijk, Den
Bosch, Oss and Grave along with their local relief services.7
- Database and System incorporation

A first important institutional requirement concerned the system accessibility. The
service oriented architecture makes it relatively easy for the local (information)
databases and -systems to connect to the WGMS: the decision on which systems
should be incorporated is dependent on decisions of BZK. A guideline should be
readily available for actors that would like to link their systems or databases to the
WGMS. This implies that all actors should be made aware of these guidelines and can
easily obtain them, through, for example, the internet.
- Information processing system
7
This also occurred in the Helga exercise; all local authorities had connected their information systems
and -databases to the GMS

It is to be expected that during a water calamity the information load varies
considerably. In times of a high information load, effective information management
is essential. Due to the lack of time in calamity situations, it is not desirable to require
a high information load to be processed by the operation teams in the lowest level of
the hierarchy. These teams simply do not possess the capacity to occupy themselves
with processing new information and need operational flexibility. Preferably, they are
provided with short and clear messages, containing all the necessary information
they need.
Thus, the processing of information should be allocated in the emergency room of the
GMS. It is to be expected that information arriving at the emergency room from
external resources (e.g. which are not connected to the WebGMS) will have to
undergo some formatting. This calls for an information filtering system to be attached
to WGMS. Such a system should offer the emergency room the possibility to
effectively filter and translate new information to understandable messages that can
be forwarded to the field.
11.2.2Standards and Semantics

A first important aspect is to agree on the content of the new system. It will be desirable
to develop one universal interface which can be operated as simple as possible.
Institutional arrangements will have to be set on:
- Standards
To ensure a high level of transparency, all ambiguities will have to be eliminated. It
will be important for all relief services to adequately instruct their employees on the
use of the new WGMS. This implies that the information provided to all users of the
WGMS should be in an understandable and preferably unique format. All Service
clients will have to accept on single information standard, protocol and codes, as
described in chapter 9. The standards that will be used for this system are listed
below in Table 5.
Table 5 – Technical standards used for WGMS

Technical standards Network
SOAP C2000 standard

XML IEEE 802.11 (LAN)
UDDI
WSDL
- Semantics: all actors will have to agree on the semantics used. As all possibilities to
ambiguities of vagueness within the system should be prevented, the terms used will
have to be incorporated into the WGMS. An important requirement here is that all
terms should be recognized by everyone involved at all times. Cultural differences
will likely cause a discussion on this subject, as terms used by one actor often differ
from those used by the other. The range of terms that can be taken up in the WGMS
is obviously limited. Thus, agreements should be made on the selection of the terms
used in a water calamity. Preferably, the ministry of BZK will give orders to create a
database for water calamity terms
11.2.3External systems and security

As the overview of the technical design shows (Figure 17, chapter 10), the decision is
made not to couple the WGMS directly to external systems like the internet. By keeping
the WGMS a relatively isolated system, possible problems with security can effectively be
avoided.
Security measures include:

- The control room will be the interconnection point with the outer world. C2000 users
will still be able to receive information from external sources, with the help of the
control room. When a question cannot be answered by the WGMS, the control room
could search the answer through for example the Internet. The connection of the
WGMS with the internet is protected with a firewall. Because these internet
information requests require more time and effort than internal database information
requests do, the number of internet information requests made by relief workers
must be as low as possible. They may only be used when no other way of receiving
this information is available.
- Relief workers have their own personal login name when they are active in the field.
Every message sent is tagged with a personal user ID. Relief workers are obliged to
formulate their questions short and clear. They also need to specify the kind of
answer they want to receive from the control room (numbers, pictures, or
descriptions for example). Within the GMS these internet information requests have
no priority, except for the ones with a high-priority label.
- A link to external systems could also be used to inform civilians. In the current
situation, the Calamity Policy Team is responsible for communication with civilians
through the media (see Chapter 3). A direct information connection between civilians
and the information system might reduce the workload of this team, but also means
an increasing need for security. On top of that, the added value for civilians is
debatable. For this reason, no such link is available in the WGMS.
11.2.4Responsibilities and authorization

- Supervision
The responsibility for the WGMS will be allocated to a specific actor, the Service
operator. This actor, preferably consisting of several specialists, has the main task to
control all information streams during a calamity and to distribute responsibilities.
Furthermore, the Service operator will have to be educated on how to use the
system. All actions that can be undertaken by these supervisors will have to be
identified. As can be derived from the technical design in chapter 10, the service
operator is responsible for:
o Assurance of the system: This implies that the Service operator constantly
monitors the status of all connections and checks the functioning of the
system. To achieve this, the Service operator should be provided with a clear
interface.
- Aggregation
The one responsible for aggregation is the Service aggregator. This actor has four
main tasks:
o Coordination: this concerns controlling the system. General requirements here
are database and external system coordination, management of information
flows, and supervision of the output of the system.
o Conformance: the integrity of the system should be insured. No data may be
lost or accidentally be made available to unauthorized parties.
o Monitoring: this implies the monitoring of the information content itself.
Information data provided by the available databases should be provided at
higher level composite events. In other words, by filtering, summarizing and
correlating information, complexity is reduced and a clear interface can be
ensured.
o Quality of service (QoS): this task includes the leveraging, aggregation, and
bundling of particular database QoS levels to derive the composite QoS of the
WGMS, including performance, privacy, integrity, availability
- Interaction between actors

The service provider will have to guarantee the functioning of the underlying
infrastructure at all times, ensuring a reliable SOA, on top of the C2000 system.
Furthermore, the service clients should be able to rely on the functioning of the
WGMS.
o Support: In case of malfunctioning or failure of the WGMS, immediate support
form the service provider is necessary. Therefore, the Service operator will
have to maintain an active link with the Service provider when the system is
active. Accordingly, support should be offered to the Service Clients if they
encounter problems with WGMS.
o List of contact actions: If any problems occur while using WGMS, the Service
operator is the one responsible for solving the problems. Thus, the Service
client should always be able to contact the Service operator if the system
does not function properly. However, clear rules should be set on when a
Service Client should contact the Service Provider. It will obviously be
undesirable if the Service Provider is contacted for minor issues. This is likely
to cause congestion and inefficient communication, something that the WGMS
is trying to avoid. Thus, a plan of action should be drawn up to avoid this. The
order of contact actions can be fixed as shown in Figure 20.
Relief worker
2. Colleague 3. Direct 4. Coordinating 5. Service

relief worker superior superior operator
Figure 20 - Order of contact actions when encountering problems with WebGMS.
- Authorization level
Another important aspect in the setting of institutional arrangements is the
determination of the authorization levels. It is to be expected that owners of
databases will not want to share all the information they possess. Moreover, not all
information will be relevant to everybody in a crisis situation. Therefore,
arrangements will have to be set in order to obtain some structure in information
sharing. Agreements will have to be made on the following:
o The information that should be directly available to the relief services:
o The allocation of authorities is expected to be the responsibility of the
emergency rooms. Moreover, research will have to be done how this
authorization allocation can be efficiently digitalized, to increase reactivity and
reliability.
- Responsibility allocation
Critical in the implementation of authorization levels is that the decisions and
necessary actions should only be visible for the people that are responsible for them.
The emergency rooms will possess all the necessary calamity plans of the different
actors involved. After linking these plans to each other, an Operation Responsibility
Scheme (ORS) will be drawn up. The emergency room operators send the ORS to all
superiors in a bulk message to the C2000 system, to create an immediate overview

of the operation teams position, required actions and the location of colleague
operation teams (see Figure 21).
GMS Control
room
Authorizations and Responsibilities (ORS)
Chief of Fire Superiors

Police Chief GHOR Superior
Department
Responsibilities Responsibilities Responsibilities
Fireman Medic Medic Relief Workers

Fireman Police officer Police officer
Medic
Fireman Police officer Police officer
Fireman Medic
Figure 21 - Authorization and responsibility allocation.
11.2.5Costs and responsibilities

The divisions in costs and responsibilities for the WGMS project were made using information
from the C2000 project, because both projects show many similarities. The main difference
between the C2000 and WGMS divisions can be derived from the difference in scope of the
projects. Where C2000 concerned a national project, WGMS will be set up as a regional
project (with optional expansion to other regions). This means that only citizens and relief
workers from the concerning regions will profit from the newly implemented system. As a
result, a shift in costs and responsibilities from central to local governments will have to be
made.
Since WGMS is web-based, expansion to other regions or external systems is relatively easy.
When WGMS turns out to be a success, other regions may decide to implement WGMS as
well. One can imagine that in that case it seems a bit unfair that the local governments who
implemented WGMS first have to deal with specific initial problems where the other, second-
phase, local governments don’t have to face these problems and costs. To meet these first-
phase regions, second-phase regions need to pay a certain (pre-determined) share to them
when deciding to use the WGMS technology.
- Project costs
Table 6 gives a short overview (based on Appendix XIII) of the proportions the different
actors had to pay considering the C2000 project. To give a clear overview of the costs
division the choice is made to work with percentages. A cost allocation for the Web GMS
project is made based on the C2000 information. Differences between them can be
found in the following decisions:
o The Web GMS project will only be carried out in one region. For this reason,
the percentage the Ministry of BZK has to pay is smaller in comparison with
the C2000 project, which is available for all regions. BZK will pay 75% of the
investment costs.
o Since Web GMS only deals with water calamities, the project is of less
relevance for the military police (KMAR). They did not participate in the design
process and there is no need for them to share in the costs for this project.

The emphasis on water calamities also implies more needed functionality for
o
the fire department compared to the First Aid Services. In contradiction with
the C2000 division, for WGMS the share the fire department has to pay will be
equal with that of the police department.
A division of exploitation costs is given. This division could change when after some time
a different user pattern can be seen than assumed (based on measurements of the
frequency of use by the different services). This system of “second cost calculation” is
also used by the C2000 project developers.
Table 6 - Cost division C2000 and Web GMS.

C2000 Web GMS
Investment costs Investment costs
BZK 75% BZK 75%
regions 25% regions 25%
100% 100%
Exploitation costs Exploitation costs
BZK 23% BZK 0%
Police dept. 49% Police dept. 40%
Fire dept. 14% Fire dept. 30%
FAS 10% FAS 20%
KMAR 4% KMAR 0%
Water boards 10%
100% 100%
- Project responsibilities
Table 7 - Division of project responsibilities.

Actors Responsibilities
BZK (including VWS and - Project organisation
Defence) - Support regions
- Connection with
central systems and
GMS
- Provide project
information
- Security
Regions (Emergency - System
Services and local implementation
governments) - Equipment purchase
- Local maintenance
- Training
- Education
- Spatial coverage
planning
- Pilot project (optional)
Project developer - Infrastructure
realisation
- Central project
coordination
- Project guidance
- Implementation
support

Table 7 is taken from the process design (chapter 9) and filled in for WebGMS. Choices
were made about the following topics:
o Although WGMS is set up for regional use it is connected with central used
systems also. When security fails, this will be a central problem. For this
reason, expertise from central level will be used to protect WGMS against
external threats.
o BZK might decide to offer local governments loans to realize this project on
time. Contrary to the C2000 project, interest will be brought into account to
keep the principle of equality of regions.
o As pointed out by the costs divisions, Web GMS is set up as a regional project.
The local governments will be responsible for a great deal of the
implementation. Typical tasks like the equipment purchase, training and
education of (local) relief workers are added to their list of responsibilities.
o The local governments may decide whether they want to implement a pilot
project or not. When they choose to do so, they are responsible for the
implementation of it.
Appendix XIV provides a clear overview of the connection between the relevant institutional
theories (identified in section 11.1), and the institutional arrangements defined in section
11.2.

12.Conclusions and Recommendations
The extensive analysis performed on the subject of information management before and
during a flood calamity came up with some interesting conclusions. These conclusions are
mainly covered by the design provided by the second part of the report (see Table 8).
Table 8 - initial problems solved with WebGMS

Current situation WebGMS
Technical
Voice based (no possibility to exchange maps Data- and voice based. Exchange of short
and photo’s) text messages, maps and photos is possible.
Centralised character (all communication via Hybrid between centralised and
GMS causes a heavy workload) decentralised character (communication via
WebGMS spares GMS)
No interconnection standards Web-based
Long (communication) connections Shorter (communication) connections (time-
efficient)
Institutional
No clear semantics Central determined semantics
Minimal involvement of operational services Better involvement of operational services
Push-based provision of information Hybrid between pull- and push based
(including unnecessary information) information (more secure information
provision possible)
Inflexible use of information systems Loosely coupled information systems (higher
flexibility)
Ineffective for non standardised information Ability to deal with non-standardised
information
Static emergency plans Dynamic, interactive emergency plans
No clear information structuring Template based information provision
Information allocation based on groups Information allocation based on individuals
Most of the identified problems are solved by implementing WebGMS. Although WebGMS
covers most of the technical problems and can be seen as a technical optimal solution, it
must be said that some institutional problems were more difficult to solve. The cultural
difference between the different emergency services (as described in the institutional
analysis) is an aspect that needs more attention. The use of generic semantics may be one-
step towards better collaboration, but cannot be solved within the process design of one
project.
Recommendations
When the Ministry of BZK and the regions start with the implementation of WebGMS, they
should consider taking the following recommendations into account:
- The Web GMS should be coupled to the existing Fliwas system

- The Web GMS could form the basis for a general calamity control and information system
- The Web GMS could be coupled to international systems
- BZK should set up a central database on semantics

- BZK should secure cooperation, coordination and communication among the relief
services
- Security issues should be subject of a follow-up research

- Once the system is implemented a second cost calculation should be executed

References
Books
Bruijn, H. de, E. Ten Heuvelhof and R. In ’t Veld, Process Management – Why project
management fails in complex decision making processes. Boston: Kluwer Academic
Publishers, 2002.
Kar, E. and Verbraeck, A., Design of smart mobile service systems. Delft: Delft University of
Technology, Faculty of Technology, Policy and Management, 2005.
O’Donnell, G. & Bhundia, A., Institute for Fiscal Studies, UK Policy Coordination: The
Importance of Institutional Design, 2001.
Suberu, R. and Diamond, L., Institutional design, ethnic conflict-management and

democracy in Nigeria, 1999.
Papers and articles

Datz, T., What You Need to Know About Service-Oriented Architecture. CIO, January 2004.
Etzioni, A., A socio-economic perspective on friction. Institutional change, theory and

empirical findings, Sven-Erik Sjostrand (1993), pp.46-60
Feeney, D., The demand for and supply of institutional arrangements. Rethinking
institutional analysis and development, ICS Press (1993), pp.160-209
International Commission for the Hydrology of the Rhine Basin, Developing the FLIWAS
system and the HNV (HIS/NOAH/Viking) project, 2006. In: CHR workshop; Ensemble
predictions and uncertainties in flood forecasting, Bern, Switzerland, 30 and 31 March,
2006.
Knight, J. and Ensminger, J., Conflict over changing social norms: Bargaining, Ideology and
Enforcement. In: Brinton, M.C. and Nee, V., The new institutionalism in sociology,
pp.105-126. New York: Russell Sage Foundation, 1998.
Koppenjan, J.F.M., Besluitvorming als strategisch spel, internal document, Delft University of
Technology, (2004), pp. 1-24
Koppenjan, J.F.M. and Groenewegen, J., Insitutional design for complex technological
systems. Delft: article for spm4410, 2005.
Meijer, A., Hele regio over op C2000. In: Sitrap, Volume 4. April, 2004.
Muller, E.R., Beslissen van routine naar crisis, in: P. ‘t Hart en U. Rosenthal (redactie), Kritieke
momenten, Arnhem, 1990, pp. 23-41.
Nadhan, E.G., Service Oriented Architecture Implementation Challenges: Ensure success by

building and following a road map that incorporates enterprise-specific standards.
Electronic Data Systems Cooperation. 2003.
NRC, Communicatie nog steeds achilleshiel bij grote ramp. The Hague: NRC, July 30, 2005a,
p.2.

NRC, Eindverslag: Het Nationaal Congres Rampencoordinatie 2005. The Hague: NRC, 2005b.
NRC, Invoering C2000 verloopt moeizaam. The Hague: NRC, June 15, 2004.
Ostrom, V., Feeny, D. and Picht, H., Institutional analysis and development. Rethinking
institutional analysis and development, ICS Press (1993), pp. 439-466
Papazoglou, M.P. and Georgakopoulos, D., Service-Oriented Computing. In: Communications

of the ACM, Vol. 46, No. 10, October 2003.
Parool, Politie verraadt zichzelf. In: Parool, September 2, 2004, p.5.
Scott, W.R., Institutions and Organizations. Sage Publications (1995), pp.66-78
Sprott, D and Wilkes, L., Understanding Service-Oriented Architecture. On: CBDI Forum,
January 2004.
STOWA, Berichtenspecificatie HoogwaterRapport, No.1, (2005), p.11-16, Utrecht.
STOWA, Quickscan informatiemodellen AQUO en IMRA v3, (2004), p.7-10, Utrecht.
Trouw, C2000 werkt niet goed genoeg maar er is geen weg terug. In: Trouw, June 15, 2004a.
Trouw, Veiligheid moet bij C2000 vooropstaan. Trouw, May 19 (2004b), pp. 14.
Websites
Ambucom, Communication with Ambucom. 2005.
June 9 2006.
http://www.prometheus.nl/producten/ambucom/abc_concept_ambucom.htm.
ETSI, TETRA. February, 2006.

March 1, 2006. http://portal.etsi.org/radio/TETRA/tetra.asp.
FLIWAS, FLIWAS Newsletter 1. 2006

June 9, 2006. www.noah-interreg.net
HIS / NOAH gebruikersdag: functionaliteit en implementatie van FLIWAS 16 maart 2005

June 9, 2006. www.hisinfo.nl
Overmars, J.M.S., InformatieStromenAudit, Verbetering Informatievoorziening

Rampenbestrijding bij Hoogwater In Nordrhein-Westfalen en Gelderland. Prov.
Gelderland, Oktober 2004
Ministry of BZK, C2000 Communicatie. January, 2004b.

June 9, 2006. www.c2000.nl
Ministry of BZK, C2000 uw nieuwe communicatiesysteem. June, 2004a.

June 9, 2006. www.c2000.nl
Ministry of BZK, De communicatiestandaard (TETRA). March, 2006a.

June 9, 2006. www.c2000.nl
Ministry of BZK, ministry of BZK website. 2006.

June 9, 2006. www.minbzk.nl.
Ministry of BZK, Stroomschema. March, 2006b.

June 9, 2006. www.c2000.nl
Ministry of VWS, Ministry of VWS Website. 2006.

June 9, 2006. www.verkeerenwaterstaat.nl.
Motorola, Motorola verkoopt meer dan 20.000 TETRA portofoons aan Politie, Brandweer en
Ambulance diensten in Nederland. October, 2004a.
June 9, 2006. www.motorola.com
Motorola, MTP700 brochure. 2001.

Motorola, Scotland Votes for the Motorola MTH800 Terminal. April 2004b.
Pieters, R., Regional Alarmcentrale Utrecht; Onderdeel van de GMU. 2005.

June 9, 2006. http://www.rwpieters.nl/brwutr/gmu.html.
SMVP, De gescheiden werelden van brandweer en politie. 2004.

March 16, 2006. http://www.smvp.nl/main.htm
Governmental documents
ACIR, De Vrijblijvendheid Voorbij. The Hague: Ministry of BZK, 2005.
AVD-SAVE-NIvU-Nibra, Leidraad Operationele Prestaties. The Hague: Ministry of BZK, 2001.
Algemeen Doorlichtingsinstrument, Modelscenario ontruimen en evacueren, conceptversie

2.0
Deloitte Accountants BV, 7e voortgangsrapportage project C2000.. The Hague: Ministry of

BZK, September 2005.
Directoraat Generaal Water, Onderzoek voor rampenbeheersingsstrategie Rijn en Maas. The

Hague: 2005.
Handboek Rampenbestrijding, deel B3 – Processen, p.47, juni 2002
Handboek Voorbereiding Rampenbestrijding, deel C3 – p. 3, juni 2002
Helsloot, I., Schaap, S.D & Bos, J.G.H., Goed toezicht is van iedereen; een onderzoek naar
het toezichtstelsel binnen het domein openbare orde en veiligheid, uitgevoerd door het
COT instituut voor veiligheids- en crisismanagement. The Hague: Ministry of BZK,
Public order and safety inspection and COT institute for Safety and crisis management,
December 2004.
June 9, 2006.
http://www.ioov.nl/contents/pages/10900/2004120605ioovtoezichtbwint.pdf
Ingenieurs/Adviesbureau SAVE & Adviesbureau Van Dijke, Leidraad Maatramp. The Hague:
Ministry of BZK, 2000.

Kabinet, PKB Ruimte voor de Rivier – deel 1. in: Ontwerp Planologische Kernbeslissing. The
Hague: Ministry of VWS, 2005.
Ministry of BZK - De Projectdirectie C2000, C2000 uw nieuwe communicatiesysteem. The

Hague: Ministerie van Binnenlandse Zaken en Koninkrijk relaties, 2004.
Ministry of BZK - De Projectdirectie C2000, Maatwerk in Communicatie. The Hague:

Ministerie van Binnenlandse Zaken en Koninkrijk relaties, 1998.
Ministry of BZK - Inspectie Brandweerzorg en Rampenbestrijding, Melding en opschaling,

informatie en communicatie bij acute rampen. 2001.
Projectteam Borging Leerervaringen Bonfire, Verslag Regionale Bijeenkomsten Borging

Leerervaringen Bonfire. The Hague: Ministerie van Binnenlandse Zaken en
Koninkrijksrelaties, Directoraat-generaal Veiligheid, directie Crisisbeheersing, 2006.
Royal Haskoning, Meulenpas, G.J. & de Klerk, A., Redesign operationeel deel HIS –
Basisontwerp, versie 4.0, RWS Dienst Weg- en Waterbouw. The Hague: September 15,
2004.
Van Dijk, W., Waterschap Zuiderzeeland “Calamiteitenplan 2005” . 2005.
Waterschap Zuiderzeeland, Calamiteitenplan 2005. 2005.
Waterschap Zeeuwse Eilanden,“Calamiteitenplan 2004, 2005” . 2004.
Waterschap Groot Salland, “Calamiteitenzorgsysteem”. 2002.

Appendices
Appendix I - Goal oriented analysis
Maximum
security
Maximum Maximum Maximum care

prevention repression after incident
Maximum
Good repression
application of
preparation
relief services
Unambiguous
Good Good Good Good training Good operational
responsibilities
communication coordination cooperation and excercises planning
and tasks
Maximum Maximum Unambiguous

Unity in culture, Maximum
information Unambiguous
technical approachability norms and willingness to
streams and semantics
performance relief workers resources values cooperate
* coverage (%) * Perception of the Perception of the Perception of the

# of used
* availability # of denied requests / users on a scale from users on a scale from users on a scale from
communication
(breakdown minutes / year 1 to 10 1 to 10 1 to 10
protocols
year) * # of unnecessary
information streams /
year
Figure I.1 – Model tree as formulated considering the current situation.
SPM4910 – SEPAM Design Project (ICT) - Appendix 91

Appendix II - Actor analysis
II.1 Inventory of the actors
Below all actors that are involved in during a flood or water calamity are listed.
The purpose of this list is to get an idea of the different people involved. With this
information, a selection can be made of the most important actors for the problem
area.
Private organizations:
• System builder
• Communication companies
• Agriculture industry (Farmers)
• Industry
• Small and medium sized enterprises
• Logistics companies
• Insurance companies
• Private owners of (large) public areas
Government authorities:
• Ministry of BZK (BZK)
• International Maas Commission (IMC) → consists of following working
groups; Physical-chemical, Ecology, Hydrology/high-water, GIS, Economies,
Taxes, Groundwater, Monitoring en Coordination
• European Union (EU)
• Ministry of VWS (V&W)
• Royal Dutch Meteorological Institute (Koninklijk Nederlands Meteorologisch
Instituut - KNMI)
• Ministry of Housing, Spatial planning and the Environment (VROM)
• Ministry of Agriculture, Nature and Food quality (LNV)
• Provinces
• Water authority (Rijkswaterstaat)
• International authorities (option 1)
• Local governments (f.e.: Beersche Overlaat (BO) protects Den Bosch, Cuijk,
Oss and Grave)
• Local governments (f.e.: Beersche Overlaat (Area BO includes the
municipalities Cuijk, Grave, Landerd, Ravenstein, Oss, Lith and Maasdonk)
Emergency services:
• Police department
• Fire department
• Ambulance department
• Military Police (Marechaussee)
• Army
Social organisations:
• Environmental organisations
• Inhabitant organisations
• Consumer organisations
• Political parties
• Monument organisations
Unorganised stakeholders:
• Animals
• Tourists

II.2 Actor analysis
In this analysis, the actors most important in case of a water calamity have been selected. To make this selection we kept in mind that this
report focuses on the organisation and communication needed to fight water calamities. This results in more relevant actors on the
governments and relief service side and less relevant actors in the private and social organisations part. Although these parties won’t be
taken further into account in this chapter, it’s good to identify them and deal with them in our process design. The selected actors have
been scanned for their interests, goals, and influencing possibilities. Furthermore, their attitude towards the problem area has been
analyzed, as well as the possible causes they ascribe to the problem area.
Table II.1 – Actor analysis.

Actor Interests Goals Core problem Causes Influence
possibilities
Ministry of Responsible for the • Provide a situation in • The current • Preparation for water • Management of
Interior and formulation of policy, which emergency firmed calamities could be governmental
Kingdom preparation of legislation and services perform in agreements do better authorities on a
relations regulations, and the an optimal way. not suffice to • No clear allocation of local level
(BZK) coordination, supervision and • Provide an the standard responsibilities
policy implementation. infrastructure that that’s needed. • Inadequate processes
(Source:http://www.minbzk.nl offers optimal • The during calamities:
/uk/organisation) communication communication namely evacuation,
possibilities. system is not information provision
• Provide an insight in capable in and communication/
how the different providing information exchange
organizations are optimal between all
occupied with cooperation operational services
prevention, between the • Lack of availability of
limitation and different people and material
repression of water emergency
flooding and what services.
improvements can
be made to ensure a
more effective
calamity repression
program. (Source:
De organisatorische
voorbereiding op
overstromingen van
Rijn en Maas, 2005)

possibilities
Police To reduce crime, tackle anti- - to establish a more • The police technical • Boycott of the
department social behavior in public homogeneous department • Insufficient signal existing system
spaces and properly enforce communication cannot function receiving (Parool, (Trouw, 2004a:5)
and implement infrastructure for the optimal during 2004a:5) • Attempts to
anti-crime measures (Blok, police severe • System supply failures avoid the use of
2004:8). – to introduce a set of situations, due (Trouw, 2004b:14) a technical
basic (upgraded) to a bad • Problems with the communication
applications for all performance of software and data system.
police forces” (Blok, existing storage capacity • Relief Support
2004:21) communication (Trouw, 2004b:14)
systems institutional
(C2000). • lack of confidence in
the system by users
(NRC, 2004a:2)
• Insufficient knowledge
how to use the system
(NRC Handelsblad,
2004a:2).
• Responsibilities are
unclear (NRC
Handelsblad, 2004a:2)
First Aid Achieve individual gain of • To be able to contact • Inability to • No or bad coverage in • Power within
Medical health based on the need for emergency room contact covered places, such Ministry of BZK
Services care of the patient; prevent • To be able to contact colleagues and as shopping centres • Feedback
mortality and affect morbidity other emergency emergency • Interference with • Relief Support
positively, possibly refer services and room, bad medical instruments
patients to care institute for colleagues, also coverage
continuation treatment internationally • Medical
(Nota verantwoorde instruments
Ambulancezorg, 2003:6) malfunction

possibilities
Fire Prevent, restrict and fight fire, • To be able to contact • Inability to • Technology on devices • Improve
Department restrict flammability, prevent emergency room contact and system immature communication
and restrict accidents in case • Shared emergency colleagues and • Lacking a central devices
of fire; restrict and fight room system with a emergency information system or • Design a central
danger for humans and up-to-date room, causing point information
animals in general; restrict connection network lack of • Aging responsibility system
and fight calamities considering the information, schemes • Refresh
(brandweerwet 1985, calamity services due to bad • Segmentation of fire responsibility
brandweer.nl) • Improve coverage schemes
departments
communication • Location of • Integrate the
among different information different
(regional) fire unknown segments into
departments • Information on one organization.
• Eventually responsibilities • Relief Support
communicate/ often unknown • Main field
corporate coordinator
international
• Besides verbal
communication also
exchange of images
and computer data
District Water Responsibility for all public • Establishment and • Ineffective • Existence of different • Central position
Boards works departments of the effective execution cooperation Calamity Reports in water calamity
country of the Calamity Plan and • Responsibilities often • Possibility to act
Coordination unclear on own
during a Water authorization
Calamity • Centre of
information on
local water
affairs

possibilities
Municipalities Protection of inhabitants • Assurance of safety • Some towns • Lack of knowledge in • Close
and quality of living are not protecting cooperation with
• Optimal cooperation optimally municipalities against water authorities
and coordination protected water flooding or • Main
during a (water) against pollution responsibility
calamity flooding and with mayor in
water pollution case of
application
Calamity law
Provinces Protection of inhabitants • Assurance of safety • Coordinating • Different Calamity • Royal
and quality of living municipalities plans that are difficult Commissioner
• Optimal cooperation and inter to link taking
and coordination province responsibility
during a (water) coordination
calamity during a
calamity
National Execution of national water • Protection against • The quality of • Water level of the • Management of
Water policy flooding waterways as a Maas alarmingly high Water boards
authority • Assurance of clean transport due to climate change • Broadening and
(Rijkswater- and sufficient water medium should • Increase of deepening water
staat) supply for all users be guaranteed. constructions around beds
• Construction and • Need for the Maas hinder • Implementation
maintenance of protection drainage of rainwater of the
waterways against high (Source:www.maaswe Maaswerken
• Assuring swift and water levels rken.nl) • Further research
safe flow of all water • Need for
traffic guaranteeing
(Source:www.rijkswa natural
terstaat.nl) developments

possibilities
The Royal - to defend Dutch territory • To deliver support • The inability to • Cooperation with • The use of
Netherlands and that of the NATO allies; when government deliver optimal other emergency military exercises
army - to make a worldwide organizations support in case services is very rare and simulations
contribution to peace, request the army’s of an due to the low number to gain some
security and stability. This assistance in emergency of disasters over a experience in
may take the form of crisis situations for which where long time period. It’s cooperating with
management their own equipment cooperation hard to obtain some other emergency
tasks, humanitarian aid or or expertise is with other experience in services.
disaster relief “ (Ministry of inadequate, such as emergency cooperating with each • The lobby for
defense, 1998:6). the floods in services is other. better
Limburg. (Ministry of needed. • The use of different communication
defense, 1998:9). communication standards and
systems adds extra protocols.
complexity to this • Manpower during
cooperation8. calamity support
8
The specific C2000 hardware for the Dutch army is not available at this moment. According to the ministry of BZK this will be the case in one year, but because of the
major delays in the whole C2000 project, there’s a lot of scepticism about this expectation (NRC Handelsblad, 2005a).
possibilities
The Royal Execute its tasks to the best • To be able to contact • Inability to • Bad coverage and • Lobby within the
Marechausse extend, nationally and other emergency reach capacity of relief Ministry of BZK
e internationally: services and colleagues. services for a better
1. Security colleagues on communication
-Object security international terrains system.
-Ceremonial services (Ministry of Defence, • Negative
-Personal security 2003) feedback in
-Security of value transports C2000
-Security civil aviation evaluation.
2. Police tasks • Relief Support
-Civil aviation terrains
-Defence
3. Assistance and cooperation
4. Compliance immigration
legislation
-Frontier guarding
-Mobile supervision
immigrants
-Assistance immigration
procedures
5. Tasks Criminal
Investigation
6. Civil peace and
international tasks
(Koninklijke Marechaussee,
2006)

possibilities
European Guaranteeing the safety of all • Cooperation and • There is no Technical • Investment of
Union European Citizens interoperability of international • EU members use their EUR 7 million on
emergency services standard for own emergency CIWIN and EPCIP
within and between handling large networks, with projects
countries scale different protocols and (Commission of
• To save the lives and calamities. One frequencies. the European
property of people at of the results is Institutional communities,
risk in the EU from an insufficient • Difference in approach 2005)
terrorism, natural cooperation for handling • Bringing different
disasters and between EU calamities. countries
accidents members. together in
(Commission of the implementing
European international
communities, 2005) calamity policy.
• Set-up of a Critical • Stimulating
Infrastructure C2000 network:
Warning Information based on
Network (CIWIN) European Tetra
• Implement European standard,
Programme for harmonizing
Critical international
Infrastructure protocols and
Protection (EPCIP) frequencies (Min
BZK, 2006)

possibilities
Ministry of Protecting the Netherlands • Protect the • Possible Need for: • A good
VWS against the negative Netherlands against malfunctioning • Flooding areas cooperation with
influences of water and possible flooding. of safety • Identifying other
providing it with safe, world- • Proactively research measures, due compartments organizations by
class connections. (Ministry into flooding to insufficient • International Measures taking measures
of VWS, 2006) possibilities and communication to prevent
• Good Calamity Control
prevention. . Organization damage by
flooding.
• Higher safety
Standards
(Tussenbesluit
Rampenbeheersingsstrate
gie overstromingen Rijn
en Maas). These are
measures on the physical
level, which cannot
function optimally without
a good performance at
the other levels of an infra
system; the operation and
service level (Thissen and
Herder)
Ministry of Protection of all agricultural, • Maintenance of a • Well organized • Communication • Representation in
agriculture fishery and nature affairs good and safe food communication between public bodies the
nature and supply and during crises is is inadequate Interdepartmenta
food quality guaranteeing the lacking l Policy Team
veterinary and
sanitary safety
(Handboek
Communicatie bij
Crises LNV)

possibilities
International Guarding the water basin of • Obtaining a • The obligations • Increasing water • Precautionary
Maas the Maas sustainable and with respect to pollution of the Maas measures
Commission integral water the European • Establishing a
management for the Frame guide of homogeneous
international water Water should measuring
basin of the Maas. be clear system
• Formulating a • Need for a • Establishing an
Program of Action centre of operational
(PoA), in which all advice on warning system
sources of pollution subjects of for pollution
in the Maas have prevention and resulting of a
been identified. protection calamity
Furthermore, the against high • Drawing up of an
PoA will list possible water levels inventory of
measures to guard • Need for a drainage
and improve the centre of • Guiding
overall water quality. advice on structures of
(Source:http://www. subjects of international
meuse-maas.be) pollution cooperation

II.3 Dependency analysis
The actor analysis has made clear what attitude the different actors involved have towards the problem area. Now it is of importance to
determine how these actors are related to the ministry of BZK. For every actor, the most important resources, the dependency and
criticality have been listed. Dependency implies to what extent the ministry of BZK is dependent on the cooperation of this particular
actor. Criticality implicates to what extent the resources the actor possesses are critical for an effective calamity repression.
Table II.2 – Dependency analysis considering the various actors.

Actors Important resources Dependency (minor, Critical actor (yes / no)
moderate, high)
Police Department • Relief support high yes
First Aid Medical Services • Relief support high yes
Fire Department • Relief support high yes

• Main field coordinator
The Royal Netherlands army • Manpower during calamity moderate no
support
National Water authority • Management of Water boards low no
(Rijkswaterstaat) • Broadening and deepening
water beds
Municipalities • Coordination and Calamity high yes
Management
Provinces • Royal Commissioner taking high yes
responsibility
The Royal Marechaussee • Relief support moderate no
European Union • Bringing different countries low no

together in implementing
international calamity policy.
Ministry of VWS • A good cooperation with other high yes
organizations by taking
measures to prevent damage by
flooding.
District Water Boards • Central position in water high yes
calamity
• Possibility to act on own
authorization
• Centre of information on local
water affairs
Ministry of agriculture nature and food quality • Representation in the Inter- low no
departmental Policy Team
International Maas Commission • Establishing a homogeneous moderate no
measuring system

II.4 Corresponding and contrasting problem perceptions, interests and goals
The final step of the actor analysis is to place the previous findings in a matrix, providing a clear visualization.
Table II.3 - Corresponding and contrasting problem perceptions, interests and goals.
Dedicated actors Non dedicated actors
Critical actors Non-critical Actors Critical actors Non-critical actors
Corresponding problem -Police Department -International Maas -Ministry of VWS -European Union
perceptions, interests and -First Aid Services Commission -The Royal
goals -Fire Department -National Water Marechaussee
-District Water Boards authority -The Royal Netherlands
-Municipalities (Rijkswaterstaat) army
-Provinces -Ministry of agriculture
nature and food quality
Contrasting problem - - - -
perceptions, interests and
goals
Striking is the fact that, in principal, all (important) actors involved have similar problem perceptions, interests and goals. An explanation
could be that all these actors are public institutions, managed in a considerably hierarchical way. Obviously, it would be rather surprising if
they have different opinions on this subject, as this would make an effective cooperation impossible.
The most important actors are the dedicated and non-dedicated critical actors, for whom a further analysis shall be executed in chapter 3.
These actors should actively participate with the objectives of the ministry of BZK. Of course, the interest of the other actors should be
taken into account, but because they are not critical in the solution area, they will not have to be actively taken along at this time.

Appendix III – Operational plans
Table III.1 – Indication of the need for relief or aid per main process in case of a
flood (LMR, 2001).
Table III.2 – Extensive and concrete overview considering the need of relief
services during a flood.

Appendix V – Organisational structure
National level
Min Defence
Min Justice College

procureurs First aid medical
generaal service (private)
Min of the Interior GHOR
Fire Department National Police Regional Police Fire Department Army / Royal First aid medical
(Regional) Department Department (Municipality ) Marechaussee service (public )
Royal
commisioner , GS
Relief services
Board Regional Regional level
Fire Department
City council
Mayor ZBO College

Authority /
management relation
Municipality level
supervision relation
Figure V.1 – Organisational structure of the relief services and other authorities.
106
Appendix VI - SWOT analysis
Table VI.1 – Results of the executed SWOT analysis.
Strengths Weaknesses
− The C2000 network with the Tetra − Difficult to use (NRC, 2005a).
technique has a nationwide covering. − Bad accessibility inside concrete
 It’s not necessary anymore to switch buildings (NRC, 15 June 2004).
frequency by leaving the region (De − Possibility to localize users of the
Projectdirectie C2000, 2004). system for outsiders (Parool, 2
− When neighbor countries also have September 2004).
implemented the Tetra technique, − C2000 has a limited data capacity,
border crossing communication is whereas real time information
possible (De Projectdirectie C2000, exchange is not possible (Trouw, 15
2004). June 2004).
− C2000 makes better and faster − Trunking does not exclude full
communication possible. Connections occupation (De Projectdirectie, 1998).
can be obtained much faster (De
Projectdirectie, 1998).
− In contrast with current analogue
networks the speech quality is improved
(De Projectdirectie C2000, 2004 and
Meijer, 2004).
− With an emergency button, high priority
can be obtained to the emergency
room.
− C2000 is cryptographically secured,
which makes listening of civilians almost
impossible (De Projectdirectie C2000,
2004).
− The Tetra technique makes trunking
possible, which multiplies the capacity
of the available channels (De
Projectdirectie, 1998).
− The realization of the C2000
infrastructure is almost completed
successfully (Deloitte, 2005).
− The management of the C2000
infrastructure, control rooms and
equipment performs sufficient (Deloitte,
2005).
107
− It’s possible to send and receive short − A lot of introduction failures (NRC,
text messages (De Projectdirectie 2005a).
C2000, 2004). − Border crossing communication asks
− In case of disturbance, there exist not only for technical solutions but also
technical and organizational alternatives for clear procedures and agreements
(De Projectdirectie C2000, 2004). (De Projectdirectie C2000, 2004).
− In the future consultation of data files − Trust in the system (“draagvlak”) (NRC,
becomes an option (De Projectdirectie 2004).
C2000, 2004). − Point of no return is passed a long time
− The necessary equipment is purchased ago (Trouw, 15 June 2004).
and implemented in an early stage − Total dependency on the C2000
(Deloitte, 2005). system, as old networks are being
removed (Deloitte, 2005).
− C2000 is not capable of meeting the
demands and possibilities of today’s
internet capabilities (Trouw, 15 June
2004).
− The poor availability and accessibility
of correct and complete information,
for an effective execution of tasks in
favor of decision making (ACIR, 2005).
− The poor division of this information
between concerned parties (ACIR,
2005).
Opportunities Threats
108
Appendix VII – Processes during a water calamity
VII.1 Monitoring
Monitoring is part of the regular water management, under the responsibility of the district
water board. Monitoring is an activity that takes place during all stages of a flood. Important
issues that are addressed are:
- Water level
- Threatened dike rings
- Ways of assistance (type, amount)
- Special objects
- Water retention possibilities
- Prognoses
Since this is a very specific task, which is done by one actor (District Water Board) and does
not demand any interdisciplinary skills, this part will not be within the focus of further analysis
anymore.
VII.2 Scale up
This process happens when a certain threshold value is being passed, thus a result of the first
process, monitoring (Melding en opschaling, 2001). The way of scaling up is described in
protocols in the manual concentrating on high water: ‘Draaiboek Hoogwater’. The messages
can be divided in three types of generic messages, regarding the state of scaling up and
down, flooding scenarios, and forecasts (Berichtenspecificatie Hoogwater, 2004).
There are different scales of calamities, indicated by the term GRIP, numbered from I until IV
(InformatieStromenAudit, 2004). GRIP I means an emergency situation with limited effect.
GRIP II stands for a more serious situation, and which needs (multidisciplinary) action and
coordination on a municipal level, based on the calamity plan. One scale further, GRIP III, the
problem becomes inter-municipal, and several teams are being set up. The most severe state
is represented by GRIP IV, where different regions are involved, and the coordination falls
under the responsibility of one of the involved mayor or Royal Commissioner (The shifts in
responsibilities for every particular scale can be found in chapter 4).
A flood frequently implies a situation that crosses the municipality border. Because of that, the
situation immediately will be set to a regional scale (GRIP III or IV). The organization set up can
be perceived equal between the stages III and IV. On a regional level, as mentioned in chapter
4, this includes the following teams:
- Calamity Policy Team (CPT)
- Regional Operational Team (ROT)
- Commando Calamity Area
- Regional Action Centers
- Municipal Calamity Management Teams
- National Coordination Centre (stage IV)
Regarding the need of information, the following issues are addressed:

- The current calamity phase
- Current location specific information
- The means of communication to be put into action
- The water routes that will come into existence in the area
- The number and location of emergency pumps
- The content of possible warning messages
- The deployment of barriers or temporary dikes
- Estimation of moment of passing beyond calamity alarm level
- The need of resources
109
- Requests for permission of certain actions
The preparation phase has great implications on the efficiency of possible following relief
services. Hence, already within this part of the process the first interdisciplinary contacts are
made.
VII.3 Evacuate
Evacuation implies the by the government ordered coordinated transport of groups of people
and animals, either forced or voluntary. Furthermore, this holds the registration, escorting,
reception, caring, and preparing for return of groups of people to their homes, and follow-up
treatment. It usually is a matter of temporary clearance of an area, which can be forced
legally. When a flood is imminent, which means that it almost certainly will occur, a decision
has to be made whether to evacuate. With regard to information streams, a number of issues
will have to be addressed in this situation:
- Calamity script (depends on the location)
- The dimension of the evacuation
- Routes and transport modalities (people/animal)
- Temporary facilities
- Guarding of area
- Time of preparation for the availability of the transport modalities
- Time of preparation for special objects like hospitals and schools
- Rules regarding priorities
Besides these rather generic information entities, there are numerous other information flows
coming from and going to the relief services and the more supportive and policy teams. Within
this part of a flood situation, a great number of parties are involved on the policy level, as well
as the operational level. In this process, there is not only information exchange between these
levels, but also within the levels, that exist of different organizations. Manuals and scripts that
clearly state what should happen, and by whom, at certain stages during an evacuation exist
and are analyzed in a separate section in this chapter.
VII.4 Flood
During the actual flood the relief services, in cooperation with the District Water Boards, try to
control the situation. The information exchange addresses the following issues:
- Entry points to the flood area
- Responsibility of making situation reports
- Actions to be undertaken
- Estimations on possible escalations
- Available transport modalities
- Ways of protection for the relief services
- Risk mapping (contamination etc.)
The information is used to inform the public, and to make estimations about further
inundation, and return. In case of an immediate flood, it also can support decisions regarding
evacuation. The content of the messages that can be discerned during a flood, are about
characteristics of the flood itself, about availability infrastructure, the water level/water depth,
and possible contamination (Berichtenspecificatie Hoogwater, 2005).
VII.5 Take care of damage

This process will be left out, as it does not occur during the repression phase.
110
Appendix VIII – Evacuation processes
Within each process there are different actions to be undertaken by different actors. In the tables below the different evacuation
processes are described with involved actors, including the responsible actor per step, which is written in bold.9 Also the
information-related issues are described per activity. The involved actors Police Department, Fire Department, GHOR, and
Municipality, are interacting in a regional level. This means that the management, planning, information requests etc. take place
within the constituted teams, such as Calamity Policy Team, Operational Team, or Action Team. The District Water Board has its own
important tasks, on the operational level (monitoring etc.), and on the policy level (advise etc.). The most important used sources
are: ‘Leidraad Maatramp’, ‘InformatieStromenAudit’, and ‘Handboek Calamity control’. The following abbreviations are used;
- FD - Fire department
- PD - Police Department
- GHOR - Medical Relieve Services
- Mun - Municipality
Table VIII.1 - Activity: Analyzing relevant information.

Activity Involved Information Notes
actors
1. Analyzing relevant information FD, PD, All information that could be of The content of the evacuation plan is made
GHOR, importance in the operational by the municipality, in close relation with
Mun phase of evacuating. other actors. PD (police) executes the
evacuation plan in a later stage.
1.1 Based on information about FD, PD, Nature, dimension of flood; The District Water Board usually holds the
nature, dimension, and GHOR, location; development of information about the characteristics of a
development of calamity Mun flood; information about possible flood, possible future scenarios.
determine whether evacuation is population and public Information about the area is to be found
necessary: buildings. within the different municipalities.
- Determine whether
population needs advise
about securing buildings and
objects;
- Determine whether public
buildings and other properties
need securing.
1.2 Determine dimension of area to FD, PD, Possible flood area; local - Because it is a flood, it automatically
be evacuated and nature of GHOR, maps; flood prognoses. crosses municipal borders, and the Royal
evacuation: Mun Commissioner should be reported. In our
9
Handboek Calamity control, deel B, bijlage 4 p.19-22
111
- Inside and outside case we deal with preventive evacuation.
municipality (report to Royal - FLIWAS helps in making scenarios, and
Commissioner); evacuation maps.
- Preventive or immediate;
- Voluntary or forced.
1.3 Emergency regulation needed? FD, PD, Severe emergency situation? This issue will not be taken into account
- If so, quickly make GHOR, Enforcement necessary?
arrangements with ‘OM’ Mun
about issues regarding
justice.
1.4 Based on (on beforehand) FD, PD, Information about population; This part has close relation with the first sub-
aggregated information Mun pets and cattle; special process of determining the need on
determine: buildings /objects; production evacuation. Most of the information has to
- Number of involved persons, & storage facilities; location, come from the municipalities, or from the
pets, cattle, including the characteristics; priorities; province.
mobility of this; responsibilities.
- Number of vulnerable
buildings/objects and mode of
securing these;
- Idem for production
processes and storage of
dangerous goods (for people
and environment);
- Determine priorities of
different categories;
- Determine which parts belong
to government responsibility.
112
Table VIII.2 - Activity: Draw up evacuation plan.
actors
2. Draw up evacuation plan FD, PD, In most regions in the The content of evacuation plans need to be
GHOR, Netherlands where adaptable, and when new information
Mun evacuations as a result of becomes available, a swift implementation of
floods are a possibility, there that information into the plan is needed. The
are evacuation plans development of an evacuation plan is possible
available. Depending on the within FLIWAS applications. Part of the
dimension of the possible evacuation plan is an information plan,
flood, and the affected areas, regarding the measures to be taken to inform
this process will partly consist and instruct the public.
of harmonizing the already
existent plans.
2.1 Determine whether a separate FD, PD, Dimension flood; scenarios. In the case of a flood, this will always be the
regional action centre should be GHOR, case, in the form of an Action Team.
set up at regional command Mun
centre.
2.2 These data are necessary for the FD, PD, Available and needed modes This process of arranging all the information,
execution of the sub-plans public GHOR, of protection; geography area; into a practical data, is the result of a
information, warning population, Mun needed number of collection/ collaboration between the actors. An
and taking care of traffic: convoy/ boarding points; information plan is made. Information
- Determine modes of possibilities evacuation routes available at municipalities.
protection for ‘relief services’ and demand of traffic (human
and maximum stay in area. and animal); determination An important aspect is that the time schemes,
- Determine collection-, implementing locations and describing different evacuation steps, with
registration-, convoy-, and action centers; urgency level; each step specific informational aspects. It is
boarding points; flood scenarios. The result is much more efficient when the information
- Determine routes evacuation, an information plan, in which arrives only at times when there is a need for
separated for human and directions are stated within that information.
animal; time schedules.
- Determine first implementing
locations or action centers;
- Determine time schemes for
subsequent evacuation steps.
2.3 Determine the needed languages Mun Demography evacuation area. This is the task of the municipality.
to inform evacuees. Determine
content first and later delivery in
113
cooperation with Information
division.
2.4 Determine required resources in FD, PD, Future demand of traffic Here the connection takes place between the
humans and materials. GHOR, (human/animal); available evacuation demand (so the amount of
- Supporting and controlling Mun relieve sources; needed persons, animals) and the available resources.
personnel (police, military); services (registration/medical The municipality makes a list of the required
- Medical personnel (on the etc.); resources, human and material.
road);
- Registration personnel;
- Veterinary service, animal
protection;
- Public information centre
- Ways of transportation (taxis,
public transport, ambulances,
wheelchairs, trucks, cattle
trucks, ships and boats,
helicopters, etc.);
- Protection materials special
buildings/objects/
infrastructure;
- Information cars, connection
material;
- Traffic and information plates,
demarcation resources
2.5 Determine control evacuation PD, Mun Number of evacuation roads; The police department does this in
area, including material for available material. cooperation with the municipality.
sealing area.
2.6 Determine which utility services FD, Mun Number of utility services; The Fire department decides this in
need to be terminated. Criteria is location. cooperation with the municipality. Information
that this should be delayed as available within municipality.
much as possible.
2.7 Determine how area has to be PD, Mun Flood information; evacuation Clearly regards a task that will be executed by
guarded (relation with routes. the Police department, so they are the only
fencing/protection). one involved (next to Municipality)
2.8 Harmonize measures with other Mun --- The whole planning already takes place in a
municipalities, regions, province, regional context, so within the RPT, OT, and
and NCC. other teams.
114
115
Table VIII.3 - Activity: Getting Personnel and Resources ready.
actors
3. Getting personnel and resources FD, PD, List of contacts. In this activity the responsibilities are
ready GHOR, described in a very clear way, which makes
Mun making decisions easier.
3.1 Alarm personnel and take care of FD, PD, Telephone numbers; The literature does not describe that there
required resources. Think of: GHOR, addresses. should be a clear list with data about possible
- Red Cross, family doctors, Mun extra resources, such as Red Cross, family
First Aid relieve workers; doctors, voluntary police, etc. This is essential
- Churches and other similar for a quick reaction on an imminent flood. The
networks; responsibility for this task lays in hands of the
- Social workers; Police Department.
- Voluntary police;
- Military.
Material resources of
- Transport organizations;
- Animal ambulance;
- Cattle transporters;
- Military support.
3.2 Get people in position and Mun Locations for collection and This is a task for the municipality only.
making ready for reception; telephone numbers
- Collection points; people for these points.
- Reception locations.
3.3 Alarm third parties, such as FD List of third parties. This is a task for the Fire Department only.
utility companies.
116
Table VIII.4 - Activity: Use of Personnel and Resources.
actors
4. Use of personnel and resources FD, PD, Many different, result of earlier A clear description of the information (towards
GHOR, activities. population, FD) part is missing. Unclear task
Mun responsibilities.
4.1 Instruct personnel PD, Location; number of people; The police department, and the municipality
GHOR, time schedules; scripts. need to give clear instructions to their
Mun personnel, so their task is plain and
unambiguous. The role of GHOR is not very
clear in this matter. Instructions will focus on
matters like where to stand, what to say, what
to do.
4.2 Mobilize personnel and Mun Location; task descriptions; This is a very unclear sub-process, because at
resources for: evacuation plan; scenarios; least partly it is a matter for the Police
- Reception and collecting time schedules. Department, with processes such as traffic
points; accompanying, escorting, order maintenance,
- Support of evacuation to while the literature (Handboek Calamity
reception centers; control) leaves this party out, and considers it
- Control and guarding a task of the municipality. Uncertainty about
evacuated area, including the different tasks, and responsibilities are
termination of utility services; highly undesirable.
- Order maintenance;
- Traffic accompanying; Further: the actual evacuation takes place
- Reception of people in within this activity, but there is no relation at
reception centers; all with the activity of informing and
- Instruction people (think of instructing people (FD).
medication, medical dossier);
- Medical escort of transports;
- Transport and reception of
pets and cattle;
- Securing special objects;
- Activate sub-plans
information facilities, warn
population and receive/take
care.
4.3 Registration of secured persons, Mun Names; objects. This information handling belongs to the
animals, and special objects, as municipality.
well as the spreading and
117
control of it.
118
Table VIII.5 - Activity: Return.
actors
5. Return FD, PD, Municipality is responsible for this part, and

GHOR, cooperation takes place between all actors.
Mun
5.1 Determine under which FD, PD, There is insufficient This is very context dependent, and there is
circumstances return is possible GHOR, information about criteria and no clear script to be made for these situations.
Mun other issues that play a part in
this situation.
5.2 Take care of return FD, PD, Identical Identical
GHOR,
Mun
119
Appendix IX – Information systems
IX.1 Information about FLIWAS
There are several private and public organizations involved in the development of a general
monitoring and warning System, captured in the program FLIWAS. The most important players
are the (Dutch and some German) District Water Boards, provinces, calamity regions, STOWA,
RIZA, National Water Authority. The initiatives that are bundled in the FLIWAS project are HIS,
NOAH, and Viking, explained below.
HIS10 - HIS exists of an operational component (Monitoring and Logbook Modules),

and a policy component (Flood and Effect Modules). HIS within the project will
address the Quality Insurance. (www.hisinfo.nl)
NOAH - NOAH is the main actor in the FLIWAS project. It was a direct result of the
conclusions drawn in the ‘von Kirchbach-report’ on the floods of the Elbe (2002).
The main focus is on the development of the GDH, explained below. (www.noah-
interreg.net)
VIKING - This project shows overlapping with other initiatives, such as HIS. it is a
cooperation between German and Dutch actors to improve information handling
and communication. The focus of VIKING within FLIWAS will be on
implementation issues. (www.programmaviking.nl)
GDH (www.geautomatiseerddraaiboekhoogwater.nl) freely translated means the Automated

Script for High Water level Situations. It is one of the basic applications of FLIWAS. It consists
of the information about the existing paper scripts on high water level situations, with
according actions when levels are exceeded. GDH processes the introduced water level
information, and advises the user about transition phases, only with relevant information. The
user maintains the status of actions, and if actions are not done within the assigned time, an
automatic warning can be issued on the screen, or by mail or SMS (Redesign operationeel
deel HIS, 2005).
The criteria for the development of the programs and applications are (HIS / NOAH
gebruikersdag, 2005):
- Multilingual
- Web-oriented, but with server and client processes
- Multi platform applications (Windows, Linux, MacOS)
- Access through normal web browsers (PC, palmtop)
- Centralized and decentralized implementation possible
- Centralized and decentralized data storage
- Information exchange between FLIWAS-implementations and other information
systems
- Information and communication system
- Modular building with generic components and autonomous functional modules
- Possibility to add external modules
- Open source
- GIS component
The way new applications are being developed, is through tendering. The organizations that
are involved in developing FLIWAS (HIS, NOAH, and VIKING) set criteria for specific
applications, and issue a tender for each application separately. By mid March 2006, the first
functions will be available. This is followed by the input of area information (water retaining
structures, structures and measuring points, population, road network and evacuation routes),
flood and evacuation scenarios. These are part of the action plans of the district water boards,
provincial authorities, fire brigades and the police. The development of FLIWAS will be
10
Hoogwater Informatie Systeem: High Water level Information System
120
complete after the summer of 2006. At the end of 2006, the application will be available to all
potential users in the European Union. In addition, the organizations for management,
maintenance and support will become operational.
IX.2 Information about Infraweb

Infraweb is a web-based application that supports the communication between organizations
on national level. The system supports the reporting, registration, and information exchange
with incidents and calamities. It is possible to authorize users within the system, so
information can be kept within a certain organization, but can be made available as well for
other users. There is a collaboration going on between the developers of Infraweb and FLIWAS.
In the picture below a clear overview is given of FLIWAS, its programs, and its modules.
Figure IX.1 – The position of FLIWAS.
121
Appendix X – Group Decision Room session report
Introduction (Categorizer)
Participant Instructions
Give some examples of possible failures during this exercise concentrating on desired
information (resources / needs).
semantics
1. People use different terms
2. Information in wrong 'form' (description vs map)
3. ambiguity information
4. reaction is not good on information
5. different persons take information on a different manner
• it is possible that one person reacts differently on a certain situation than
another person...
responsibilities
1. Don't know who is responsible
2. Information classified
• is this a failure?
3. confusion between commanders on the smae level (e.g. police chiefs)
4. not clear who is responsible for whom
5. receiving too much information
• People receive to much information
• receiving too much information in a crisis situation (no time to handle that)
6. not all instances receive the information needed for cooperated action
technical failures
1. information database crashes
2. Information not up to date
3. information stream control insufficient
4. Manageging new information input
5. Information not available in region or country
6. what information should be push based, and what information should be pull based
7. user doesn't realise information has arrived (no alarm?)
8. privileges on databases are not distributed correctly
external failures
1. external problems; civilians don't cooperate, places not reachable
2. Information reaction or receiving is time consuming
• in really stressfull situations, users don't take their time to communicatie and
ask for information
• maybe the input of information will suffer from this aspect
human failures
1. user asks the wrong questions
2. people don't use their equipment well
3. user receives information but doesn't know how to use it in a practical way
4. Don't know what information to ask for
5. different users are looking for the same information simulaneously (no sharing)
6. Don't know where they are (location)
7. too much information at a time
8. priority settings in information streams unclear (should all information be provided
immediately?)
interface
1. interface in which information is presented is not clear
2. diificulties in finding information
3. information not visible on screens in particular situation (darkness, too much sunlight)
4. Don't know where to find information
Brainstorm 2 (Categorizer)
Give some examples of possible advantages and disadvantages of full information.
advantages of full information

1. Situational awareness
• All desired information available
• better estimation of the situation (how severe it is) for all the involved persons
2. evade confusion, particularly on lowest level
3. always possible to know whats your duty
4. reaction very well 'onderbouwd'
• 'Grounded'
5. easy management of groups within the complete calamity relief system
• Increase manageability
6. Up to date information
7. digitalized information helps avoiding misinterpretations
8. possibility of 'looking ahead' instead of 'achter de feiten aanlopen'
9. It is possible for any one to use same information
10. relief workers can take over tasks, or assist in tasks that are not their own (with
information regarding other tasks)
11. better linking different pieces of information te each other and solve the problem as a
whole
• different pieces of information complement each other
12. transparancy
13. improvement in creating log files (archives)
14. speeding up decision making process
15. ability to digitalize coordination and cooperation!!
disadvantages of full information

1. too much information, don't know what to use
2. All nondesired information available
3. relief workers might make their own (strategical) decisions, while these decisions should be
made on a higher level
4. people request information that they do not need
5. relief workers loose the focus on their task, may be intervene with other relief workers,
disciplines
6. big data systems are difficult to keep up to date
7. Large initial costs
8. Large maintainance costs
9. Lots of systems connected
10. keeping an overview of the total information offer very difficult
11. more capacity needed for large information streams
123
12. relief workers don't know how to react in situations without full information (no
improvisation skills)
13. Labourintensive (arbeidsintensief?)
14. setting up and managing priviliges very complex! could this also be digitalized? ex ante?
15. Different languages
16. all information provided by relief workers can not be immediately entered into the system;
how is this managed?
17. Not aware of redundancy
• a lot of redundancy?
18. Information keeps growing
• huge amount of 'old' information
19. no feeling of responsibility when receiving a new piece of information (someone else will
pick it up)
20. inconsistent information -> confusion, what is right?
21. TIME!!! takes quite some time to find the right information, not desirable in emergency
situations
• Searching for information might be rather time consuming
Brainstorm 3 (Categorizer)
Identify as many requirements as possible. Please not only mention the subject but the
direction also ('low costs' for example instead of only 'costs).
Input-output
1. Stored information -> Operational information
2. Full information -> Specific information
3. fully push based -> mixed with pull based
4. general information -> information in the right format (graphs, voice)
Technological requirements
1. clear interface
2. information input not only in th ehighest levels, lower levels as well => better information
3. connection with the Internet and other relevant networks
4. Easily connected to other systems (international)
5. Back-up system
backup systems (for robustness)
6. Easily connected to other databases

7. concurrence in database alignment
8. Easily extended
9. ability of data-communication (including pictures)
10. diversity in representing data (voice, graphs, pics, icons)
11. databases may never crash
12. limit choice in information semantics
13. Web based
14. there should be a direct link between the technological features and the responsibility
requirements
15. there should be a link to civilians as well
16. through internet then
Performance requirements
1. ability to quickly inform management on mission status
2. High robustness
3. Short implementation period
124
4. system should enhance information handling within and between organizations
5. Specified accessability
6. information handling should be place dependent, context dependent, time dependent, and
hierarchy dependent (officer receives other info than agent)
7. clarity in semantics
8. information should be up-to-date
9. Information should be clear to all parties
10. information should be accessable at the right time
11. information should be accessable by the right parties
12. information deliverance in different manners
13. database management should be relatively simple
14. interface as clear as possible (large, quality screen, realtime video etc.)
15. no delays in tranmitting information
16. information should be delivered with a reliability grade
Cost requirements
1. Low maintenance costs
2. Low purchase costs
3. Low initial costs
4. using existing equipment as much as possible
User requirements
1. the system has to deal with relief service specific thing (special features for firemen,
policemen and ambulancepersonel)
2. Support personalised settings
3. limitations to what a particular team in the field should receive
4. personalized information --> the right person, the right information
5. voice communication should be possible without using hands "hands free"
6. system has to deal with user preferences (font size for example)
7. ability to control the volume of sound
8. High ease of use (information within few steps)
9. hierarchy will state the different responsibilities, implemented in system
10. technological features will couple information to this hierarchy
11. so incoming information should be judged accordingly... this judgment cannot take a long
period of time
12. ability for user devices to directly rank information (on time received, rate of importance,
etc.)
13. so maybe some information should be accepted straight away, some information should
be put as standby, and some needs to be checked before input
14. Sufficient ergonomic
15. this implies a hierarchy in information as well, which does not necessarily follow the
institutional hierarchy

1. all parties should be satisfied with the system
2. excercises where relief workers can train how to use their autonomy and learn to improvise
3. abtility to train with the system before accidents take place
4. all relevant parties should be involved
5. 1st line users (police, fire, ambulance) should have a stronger position in the design process
than 2nd line users (army, explosieven opruimings dienst)
6. frequent information updates for the relief services during the design process
7. linking responsibility schemes of the different clamaity plans digitally
8. agreements in database linking and privileges
9. Short implementation of design
10. All actors involved
125
11. no exit option in this case
12. No blocking power
13. protecting core values
• protection of core values
14. working towards a lengthy agreement
responsibilities
1. subsidiarity principle: decision should be made on a level as low as possible
2. hierarchy should be very clear
3. Clear responsibilities
4. decide to what extent relief workers can digitally 'push' information
5. information stream control centre: determine amount of personnel needed
6. digitalization of responsibilities within system
7. provision of local hierarchy structure in user devices
8. direct communication net within groups (e.g. messanger)
9. priority ranking in information provided (a decision can be overruled by someone higher in
the hierarchy
126
Appendix XI - design issues
XI.1 General design issues
All the requirements that could compete with each other are selected from the complete list of
requirements (chapter 8). These requirements were set out against each other in table 12.
Conflicting requirements are coloured and marked with a number. As table 12 shows, nine
design issues were identified.
Table XI.1 - General design issues.

R U U R
I1 I2 T1 T2 T3 R2
eq. 1 2 1
I1 1 2
I2 6
T1 4
T2 5
T3 8
U1 3 7
U2
R1 9
R2
Possible design issues

Information
I1: Clear and general semantics (need)
I2: Limited amount of information a particular user in the field should receive (need)
Technological
T1: Ability to couple this system to communication systems that civilians use (nice)
T2: Web-based (possibly use of Internet applications) (need)
T3: Compatible for extension with other (international) information systems and trends
(nice)
User requirements
U1: Selective authorisation (need)
U2: Maximum security (need)
Responsibilities
R1: decisions should be made on a level as low as possible (nice)
R2: clear operational responsibilities (need)
Process
P1: Minimum implementation time (nice)
P2: Step-by-step implementation (need)
P3: All relevant parties should be involved (need)
P4: 1st line users (police, fire, ambulance) should have a stronger position in the design
process than 2nd line users (army) (nice)
P5: Frequent information updates for the involved parties during the design process (nice)
P6: No exit option (need)
P7: No party should have blocking power all by himself (need)
127
12.1XI.2 Costs design issues
Table XI.2 - Costs design issues.
requirement Purchase Maintenance Adaptation
Costs Costs Costs
(investment) (exploitation (investment)
)
N-I1
N-I2
N-T1
N-T2
N-R1
N-U1
N-U2
N-U3
N-U4
N-U5
N-P1
Costs
- Low Purchase costs (nice)
- Low Maintenance costs (nice)
- Low adaptation costs of existing systems (nice)
Technological
Information
N-I1 Information should be delivered with a reliability grade (nice)
N-I2 Priority ranking of information provided (nice)
Technological
N-T1 Ability to couple this system to communication systems that civilians use (nice)
N-T2 Personalized representation of information (nice)
Institutional
Responsibilities
N-R1 Decisions should be made on a level as low as possible (nice)
User requirements
N-U1 Familiar appearance to every relief service (nice)
N-U2 Database management should be relatively simple (nice)
N-U3 Ability to deal with relief service specific things (special features for firemen,
policemen) (nice)
N-U4 Support of personalized settings (nice)
N-U5 Ability for users to rank information directly (nice)
Process
N-P1 Minimum implementation time (nice)
128
XI.3 Defining actor groups
Not all actors have to be involved for each design issue. Table 3 shows the actors that should
be involved for each negotiation. When comparing the groups of actors needed per design
issue the same pattern can be distinguished for some design issues. These issues are taken
together in a cluster which enlarges the negotiation package and the possibility for trade-offs.
The white numbers per cell indicate which cluster the design issue belongs to.
Table XI.3 - Clusters of actors.

Issue BZK VWS PRO DWB MUN PD FD FAS PRD
1 2 2 2 2 2 2 2 2
2 1 1 1
3 4 4 4 4 4
4 3 3 3 3
5 3 3 3
6 4 4 4 4 4
7 4 4 4 4 4
8 1 1 1
9 4 4 4 4 4
BZK Ministry of BZK

VWS Ministry of VWS
PRO Provinces
DWB District Water Boards
MUN Municipalities
PD Police Department
FD Fire Department
FAS First Aid Services
PRD Project developer
XI.4 Overview of the process design

This chapter provides an overview of which requirements are met by the process design as
described in chapter 9. Since the process design ends with the start of the project, the process
rules concerning implementation are not covered by the process design. Whether the
requirement (“low costs”) is met is totally dependent on round 3 and 4.
Table XI.4 - Process design overview.

Rounds Requirements met
Round 1 (generic process - All relevant parties should be involved (need)
rules) - Frequent information updates for the involved parties
during the design process (nice)
- No party should have blocking power all by himself
(need)
- Protection of core values of all the involved actors (need)
Round 2 (requirements) - 1st line users (police, fire, ambulance) should have a
stronger position in the design process than 2nd line users
(army) (nice)
- All parties should be satisfied with the system (need)
Round 3 (design issues) - Frequent information updates for the involved parties
during the design process (nice)
Round 4 (costs)
Round 5 (start project) - All parties should be satisfied with the system (need)
129
Appendix XII – Technical design
Table XII.1 – Actors involved considering the technical design.
Actor group Roles Actors in this respect
Service provider Organisations that procure the service This should be outsourced on a
implementations, supply their service contract base to (an) external
descriptions and provide related technical party/parties that possess(es)
and business support. the right technical knowledge.
Service client End-user organisations that use the The relief services and the
(consumer) service. emergency rooms.
Service Organizations that consolidate External parties by request of
aggregator multiple services into a new, single the technical management of
service offering. GMS.
Service operator Organization responsible for The technical management of
performing operation management GMS
functions.
Market maker Organization(s) that create and Ministry of Interior and Kingdom
maintain the marketplace. Relations (BZK)
Table XII.2 – Service layers distinguished concerning the paradigm.

Service layer Definition Details
Description and Includes the different services − Service descriptions
Basic Operations (including systems and databases) − Service basic operations
Layer that need to be covered by the
SOA.
Service Encompasses necessary roles Considering coordination, the
Composition Layer and functionality for the service:
consolidation of multiple − Controls the execution of the
services into a single composite component services.
service. The composite service − Manages the dataflow among
can perform functions that them and to the output.
include coordination,
monitoring, conformance and Considering conformance, the service:
quality of service composition. − Ensures the integrity of the
services.
− Imposes constraints on the
services and data fusion
activities.
Considering monitoring, the

service:
− Subscribes to info produced by
services.
− Publishes composite events.
Considering Quality of Service

(QoS) composition, the service:
− Leverages, aggregates and
bundles the QoS to derive the
composite QoS (including
overall costs, performance,
security etc.).
130
Service Manages critical applications and The management:
specific markets.
Management
Layer
− Supports critical applications
that require enterprises to
manage;
o the composite service
o the deployment of
services
o the applications
− Supports open service
marketplaces.
Table XII.3 – Basic services that need to be covered by the SOA.

Service Description Basic operations
CMS system The core information system of the This system makes
emergency rooms, which connects communication between the
the different relieve services to the different relief services and the
GMS. GMS possible.
Overstromingsatlas An atlas on the floods occurred This is a GIS system that shows
in the past in the Netherlands. via a map of the Netherlands all
the floods that have occurred in
the past. For each area different
flood objectives can be shown.
For each calamity a flood model
can be generated and a time
indication all indicated on the
map.
CCS-Vnet A Command and Control System CCS makes it possible to view
supports calamity control maps and to communicate by
especially large happenings. the use of video during
calamities. De user can
determine for itself which map
to be shown, on which scale
and which objects involved.
HIS Scenario Viewer A flooding simulation system HIS presents via a map of a
certain area a scenario on how
an eventual flood can develop.
This simulation is based on a
list of parameters filled in by
the user.
Professionele A GIS system that provides an This can be used to identify
risicokaart overview on the objectives possible critical situations in the
important in case of a calamity. surroundings of an occurred
calamity.
Evacuatiemodule An information system that This system gives the
presents evacuation, opportunity to create, edit and
accommodation and returning execute the indicated plans.
plans. This includes information on
GEO, activities and library.
Nationaal Locatie Within this database all the Each region has access to the
Bestand (NLB) streets and their characteristics part of NLB that is important to
of the Netherlands are them. The database provides
administrated. information on every object.
ISIS A Command and Control System A basic system that makes
131
that supports calamity control. coordination possible during
calamities.
Multiteam A cooperation application This application makes distance
operation in certain teams
possible.
FLIWAS FLIWAS aims for an integrated FLIWAS is a cooperative,

calamity system presentinginternational, and very
information from many different
comprehensive project that
sources. provides simultaneous access
Including: to reliable and comparable
data.
− GIS system An interactive GIS application. The system provides interactive
maps in which the scale and the
level of information of objects
can be adjusted.
− Water level A water level monitoring and The system provides
monitoring and forecasting application. information on the water level
forecast system on a certain place in a river
defined against time. Based on
this data figures can be
created, which make
forecasting possible.
− Communication An internal communication This provides the possibility to
facility application. communicate via text messages
with connected parties.
− Priority notification A priority warning application. This application indicates per
area the warning phase which is
at that moment at hand.
Including indication maps,
information levels and
management plans.
− Navigator A calamity management This application can be used to
application. navigate activities between
actors during a calamity. It
provides the opportunity to
navigate measures,
organisation, location, persons,
resources and documents.
Diverse digital
information on
intranet:
− Static population, To be used as background
transportation and weather information.
data
− Manuals concerning the To be used as background
used systems information.
Diverse digital
information on
internet:
− Real time transport and To be used as background
weather information information.
− Search engines and To be used as background
132
databases information.
E-mail facility An application for digital indirect Used for communication
communication with on another. purposes.
Table XII.4 – Domains

Domains Services included Sub services included
GMS core domain − CMS system
Command and control − CCS-Vnet
domain − ISIS
− Multiteam
Database domain − HIS Scenario Viewer
− Nationaal Locatie Bestand
(NLB)
− Overstromingsatlas
− Professionele risicokaart
− Evacuatiemodule
FLIWAS domain − FLIWAS system − GIS system
− Water level monitoring and
forecast system
− Communication facility
− Priority notification
− Navigator
133
Appendix XIII - Division of costs
By combining information from multiple sources an overview of the costs of the C2000 project
was created (Table XIII.1). As used before, a division is made between investment costs and
exploitation costs.
Table XIII.1 - C2000 cost division.

total costs central regional total central regional
investment costs
equipment € 121.7 19%
project organisation € 28.3 4%
miscellaneous € 13.7 2%
total (mln €) € 653.3 € 489.6 € 163.7 100% 75% 25%
central exploitation costs
FAS (VWS) € 6.4 8%
KMAR (Defence) € 2.7 3%
BZK € 18.8 23%
police € 30.6 37%
fire € 7.3 9%
regional exploitation costs
police € 9.1 11%
fire € 4.5 6%
CPA (FAS?) € 1.4 2%
KMAR € 0.9 1%
total (mln € / yr) € 81.7 € 27.9 € 53.8 100% 34% 66%
The central government paid 75% of the investment costs, whereas the regional governments
took care of a large proportion of the exploitation costs. This table makes also clear how much
the different emergency services had to pay in proportion to each other. The police
department obviously had a larger proportion compared to the First Aid Services. The small
contribution of the Military Police (KMAR) is explainable since they are much smaller in size
compared to the other services.
The division of exploitation costs among the emergency services are estimated at the
beginning of the project. After measuring the user-frequency of all services, an extra
calculation could change the division of exploitation costs.
134
Appendix XIV - Institutional design WebGMS
The table below gives an overview of the institutional arrangements to be made for the design
of the WebGMS. Furthermore, the connection of these arrangements with institutional design
theories is given, along with an estimation of the time needed to implement a certain
arrangement. Finally, a plan of action for every arrangement has been drawn up.
Table XIV.1 – Overview institutional arrangements.

Institutional Requirement Institutional design Norms Time needed Plan of
arrangeme s Satisfied principles and for action
nt values implemen-
? tation(month
s)
Database Specified Flexibility yes 9 Communica
and System system te
incorporatio accessibility standards
n of web
service with
all external
actors
involved in
a water
calamity
Information Operational Reliability, Scalability, 3 Set up
Processing flexibility Credibility/Transparen information
System cy load
manageme
nt system
for filtering
and
translation
Standards Ease of use Democratic yes 6 Implement
legitimacy standards
of WGMS
Semantics Ease of use Credibility/Transparen yes 6 Implement
cy, Democratic semantics
legitimacy of WGMS
Security Maximum Democratic yes 6 Secure
measures security legitimacy WGMS and
C2000 from
external
systems
Supervision Clear Flexibility, Scalability, 3 Update
responsibiliti Reliability interface of
es Service
operator
Aggregatio Clear Reliability, Scalability, yes 3 Ensure
n responsibiliti Credibility/Transparen control and
es cy integrity of
system,
monitoring
information
content,
QoS
135
Institutional Requirement Institutional design Norms Time needed Plan of
arrangemen s Satisfied principles and for action
t values implemen-
? tation(month
s)
Interaction Decisions Reliability, yes 6 Ensure that
between should be Scalability, Flexibility WGMS
actors made on a functions
level as low and
as possible determine
most
desirable +
effective
order of
contact
actions
Authorizatio Selective Democratic 3 Set up
n levels authorizatio legitimacy scheme for
n integrating
authorizatio
n levels
Responsibilit Clear Democratic yes 3 Set up
y allocation responsibiliti legitimacy scheme for
es integrating
and responsibiliti
Hierarchy es
should be
very clear
Project costs Democratic yes - Define costs
legitimacy for total
project
Project Clear Credibility/Transpare yes Define
responsibiliti responsibiliti ncy responsibiliti
es es es for total
project
136
Appendix XV - Additions on the GMS template for
the used interface
Although the information content changes according to calamity type and -stage, the structure
of the information flow is set by the template. In the list below, the most important
information entities, that should be included in the template, have been listed. Depending on
the kind of interaction (reading information, requesting information, or searching information),
the template should have functionalities to enable or disable entities.
1. Time/Date/State/Urgency
2. Sender/Contact person/Receiver/User (group)
a. Executing level: PD/FD/GHOR/Army/Other (District Water Board, Municipality etc.)
b. Policy level: Supervisor/Mayor etc.
3. Subject/Type of message; order/information/request
4. Category; Text/Image/Video
5. Domain; Geographic/Traffic control/Flood information/Current emergencies/Missing
persons/ Legal/Resource management etc.
6. Content/Location
7. Phase; Monitoring/Scale-up/Evacuation phase/Flood/Return
8. Language choice (in case of international cooperation)
137

SEPAM Master Project: Report

Загружено:

Сведения о документе

Оригинальное название

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

SEPAM Master Project: Report

Загружено:

Авторское право:

Доступные форматы

Flooding Calamity Control

Research on communication, coordination and

SPM4910 – SEPAM Design

SPM4910 – SEPAM Design Project (ICT) – Final Report 2

SPM4910 – SEPAM Design Project (ICT) – Final Report 3

SPM4910 – SEPAM Design Project (ICT) – Final Report 4

SPM4910 – SEPAM Design Project (ICT) – Final Report 5

Flood calamities require a highly multidisciplinary approach, with an enormous amount of

The combination of analyses on the different stakeholders, technical aspects, information

SPM4910 – SEPAM Design Project (ICT) – Final Report 6

- The Web GMS should be coupled to the existing Fliwas system

- BZK should set up a central database on semantics

- Security issues should be subject of a follow-up research

SPM4910 – SEPAM Design Project (ICT) – Final Report 7

SPM4910 – SEPAM Design Project (ICT) – Final Report 8

SPM4910 – SEPAM Design Project (ICT) – Final Report 10

SPM4910 – SEPAM Design Project (ICT) – Final Report 11

2.2 Paper structure

SPM4910 – SEPAM Design Project (ICT) – Final Report 12

SPM4910 – SEPAM Design Project (ICT) – Final Report 13

3.1 Dedicated and non dedicated critical Actors

SPM4910 – SEPAM Design Project (ICT) – Final Report 14

3.2 Calamity Plans

Other Cooperation Arrangements

Calamity Relief Plan

Municipal - and District Calamity Plans

Figure 2 – House of plans existing in the Netherlands (Handboek Voorbereiding

3.2.1 Municipal- and District Calamity Plans

SPM4910 – SEPAM Design Project (ICT) – Final Report 15

SPM4910 – SEPAM Design Project (ICT) – Final Report 16

SPM4910 – SEPAM Design Project (ICT) – Final Report 17

3.2.2 Operational Plans

SPM4910 – SEPAM Design Project (ICT) – Final Report 18

Indication Car accident

Figure 4 – Operational needs considering a certain size of calamity (LOP, 2001)

SPM4910 – SEPAM Design Project (ICT) – Final Report 19

3.2.3 Calamity Relief Plans

- Adequate level of competence

SPM4910 – SEPAM Design Project (ICT) – Final Report 20

1. Unstructured spontaneous support (individual policemen supporting on own

SPM4910 – SEPAM Design Project (ICT) – Final Report 21

SPM4910 – SEPAM Design Project (ICT) – Final Report 22

• Time-critical, which indicates or a process should (completely or partly) be executed

In essence time is determinative concerning calamity control and concentrating on the

3.3 Responsibilities and hierarchy

SPM4910 – SEPAM Design Project (ICT) – Final Report 23

4.1 Five ways to communicate

1. Direct mode operation

3. Inter System Interface

5. Peripheral Equipment Interface

SPM4910 – SEPAM Design Project (ICT) – Final Report 24

SPM4910 – SEPAM Design Project (ICT) – Final Report 25

4.1.3 C2000 from a user perspective

4.1.4 Project progress

SPM4910 – SEPAM Design Project (ICT) – Final Report 26

4.2 SWOT analysis

SPM4910 – SEPAM Design Project (ICT) – Final Report 27

5.1 Processes during a water calamity

SPM4910 – SEPAM Design Project (ICT) – Final Report 28

Figure 6 - Overview strategic direction (Based on: Overmars, 2004).

SPM4910 – SEPAM Design Project (ICT) – Final Report 29

ROT – Information Gathering

RPT/ ROT - Action