Supporting the Design of an Inland Container Terminal through Visualization, Simulation and Gaming

transcript

Procee0-769

Supporting the Design of an Inland Container Terminal throughVisualization, Simulation and Gaming

Wieke Bockstael-Blok*, Igor Mayer**, Edwin Valentin***

Faculty of Technology, Policy and Management, Delft University of Technology, PO BOX5015, 2600 GA Delft, The Netherlands;

* w.bockstael@tbm.tudelft.nl (+31)152786363; ** i.s.mayer@tbm.tudelft.nl (+31)152787185;*** e.valentin@tbm.tudelft.nl , (+31)152783440

AbstractThe planning and design of an inland container ter-

minal is a complex task due to many interrelated designparameters and interdependent stakeholders. Designtools may support the optimization of technical, eco-nomic and logistical values, but this optimization isstrongly inhibited by conflicting interests, political andenvironmental boundaries and strategic stakeholderbehavior. The main research question in this contribu-tion is: how can visualization-simulation tools be used inan early stage of complex inter-organizational decision-making on infrastructures in such a way that it enhancesthe quality and progress of this decision-making? Acollaborative design environment was developed for theearly phase of inter-organizational decision-making. Inthe gaming-simulation 'Containers a drift' a number ofpublic and private stakeholders try to reach initialagreement on an inland container terminal. A team ofprocess-managers facilitate a collaborative design proc-ess and set up a number of ground rules for negotiation.A visualization-simulation tool is used to explore thevarious technical, economic, political and spatial issues.While negotiating on issues such as location and size ofthe terminal, small groups of stakeholders interactivelydraw several terminal layouts. Logistical and economicdata, e.g., on ships, containers and costs are entered in adatabase. The terminal's performance and its dynamicbehavior is simulated and assessed. The game wasplayed in three sessions with a total number of 77 stu-dents. The evaluation results indicate that the varioustools are easy to work with, greatly contribute to thequality and process of negotiation and generate mutualunderstanding.

1. IntroductionThe planning and design of infrastructures, such as

railroads, business parks and utility networks, is a com-plex task due to a large number of interrelated designparameters and mutually dependent public and private

stgiopanas[1liobcahibo

inzasiacshithosinealprdesiguinduco

thsiininth

wreordefo

akeholders. Possible stakeholders such as local, re-onal and national public authorities, infrastructureerators, (potential) customers, logistical, transportationd shipping companies, residents and environmentalsociations, constitute an inter-organizational network.]. The actors are mutually dependent, but will most

kely have different perceptions, interests, values andjectives. As a consequence the optimization of techni-l, economic and logistical values will strongly be in-bited by conflicting interests, political and externalundaries and strategic stakeholder behavior.Visualization and simulation can contribute to the

itial design phase of complex infrastructures. Visuali-tions of a system, such as sketches or layouts, andmulation models, expressing a system’s dynamic char-teristics, communicate the complexity of the system,ow the consequences of options and place a design in

s future environment. Important questions can be raisedwever, on how collaborative visualization and

mulation can be embedded in an inter-organizationaltwork and multi-actor negotiation process. Can visu-ization and simulation contribute to the quality andogress of negotiation for instance by facilitating thevelopment of mutual understanding or a shared vi-

on? In that case, what are the specific requirements andidelines for using visualization-simulation tools in anter-organizational context? What interactive proce-res, programs and ground rules may guide such allaborative vision development?

The main research question in this contributionerefore is formulated as: how can visualization-mulation tools be used in an early stage of complexter-organizational decision-making on infrastructures such a way that it enhances quality and progress ofis decision-making?The structure of this paper is as follows: In section 2,

e discuss the research approach. In section 3, the theo-tical notions on decision-making in inter-ganizational decision-making are discussed in moretail. This leads to a number of general requirementsr visualization-simulation tools used in such a setting.

es (HICSS’03)

Proc0-76

The gaming-simulation Containers a Drift and the visu-alization-simulation tool are detailed in section 4. Insection 5, the results of three gaming experiments arediscussed. The main conclusions are summarized insection 6.

2. Research approachTo answer the aforementioned research question, a

visualization-simulation tool and a gaming-simulation[2] were developed using the planning and design of afictitious but realistic inland container terminal as a case.In the gaming-simulation Containers a Drift the partici-pants play the role of stakeholders. They explore andnegotiate on a container terminal design while using thevisualization-simulation tool.

Three gaming-simulation sessions were held with atotal number of 77 participants. Participants were stu-dents who signed up for a voluntary part of a course inthe faculty's third year curriculum. Students of the fac-ulty of Technology, Policy and Management are rela-tively experienced in using computer software such asExcel and Arena but have much less experience withdrawing in Visio, the drawing package used in the visu-alization tool. Only twelve percent of the students in thegame indicated that they had no experience with simula-tion tools, but forty-three percent was not familiar withdrawing in Visio. Students also follow theoreticalcourses in management and technological decision-making but have very little experience in managementand facilitation combined with simulation.

Each gaming-simulation session was evaluated exten-sively. Empirical data were gathered through: (1) obser-vation of the group work during the game; (2) plenarydebriefing after each game; (3) a written questionnairefilled out by the participants shortly after the game; (4) awritten response by the participants to a few open ques-tions. The participants were told that the experiences andresults of the three pilot sessions are going to be used forfurther improvement of the game and tools. The students'positive or negative opinions about the game did notdetermine their grade. The response rate was 95%.

The evaluation of the tool and the gaming-simulationsessions focuses on three main aspects: (1) the role of thevisualization-simulation tool in an inter-organizationaldecision-making process; (2) the generation of somespecific requirements for using such a tool; (3) somesuggestions for refining the game and the visualization-simulation tool for real life cases. The evaluation criteriaregarding the visualization tool and the gaming-simulation were generally derived from notions on infra-structure design in inter-organizational settings (seebelow). In this contribution we will concentrate mainlyon the requirements and performance of the tool in aninter-organizational setting.

tiodedeMinstrnofausle

wThthththchdeanop

cragitsInincaorfoopdicocoreananatan

tuthprmdepagr

ci(1prm

Infrastructure design in inter-ganizational networks

1 A process-oriented approachFrom a decision-making perspective, design situa-ns can be characterized on two dimensions: (1) thegree of consensus on norms and values and (2) thegree of consensus on facts and causal relations [3].ost commonly, the design and planning of complexfrastructures will score low on both dimensions, i.e., aong disagreement between stakeholders on values andrms in combination with a great many uncertainties oncts and causal relations. These design situations areually characterized as wicked or messy design prob-ms [4].The decision-making process under such conditions

ill most likely have a number of characteristics: (1)e planning and design process will be pluricentric in

e sense that not one actor can dominate or monopolizee decision-making. (2) It will be dynamic in the senseat the perceptions of problems and solutions willange over time. Stakeholders will enter and exit thecision-making arena and the process will go by fitsd starts. (3) Actors will behave strategically in order totimize their own interests and values [1].Whereas stringent project-management may become

ucial in later stages of infrastructure design, the man-ement of actor-relations and the negotiation procesself, is essential during the initial stages of the project. order to avoid impasses and breach stalemates, anter-organizational decision-making process must berefully designed and managed. Such a process-iented approach to infrastructure design is based onur main design principles: (1) the process should been for (participation by) the key stakeholders and thefferent perspectives on problems and solutions; (2) there-values of these stakeholders, such as autonomy ormmercial property rights, should be safeguarded andspected; (3) the design process should show progressd produce timely results; (4) the level of understandingd knowledge of the various stakeholders on the subject hand should be raised by feeding information andalysis into the negotiation process [5].In other words, during the early stages of infrastruc-

re design an intricate balance is required between (1)e content of decision-making, for instance byoviding the relevant factual information and assess-ents through analysis, and (2) the inter-organizationalcision-making process, that can be characterized asrticipatory and safe, that shows progression, and inte-ates different sources of knowledge.An independent process-manager may design and fa-

litate the decision-making process, among others, by:) drawing up, in consultation with the stakeholders, aogram with the various steps and rounds of decision-aking; (2) drawing up, in consultation with the

(HICSS’03)

stakeholders, a number of ground rules, e.g., on conflictsettlement or exiting the process, that will guide andcontrol the interaction between the participants; (3) fa-cilitating the process through constantly shifting fromcontent to process and vice versa. Controversial issuescan be put on an agenda via process rules that may for-mulate who, when and how the stakeholders are going toaddress these issues. When controversial issues are ne-gotiated too early in the process it may easily lead to animpasse. It may turn out that when the issue is discussedlater in the process, stakeholders have become moresensitive to the positions of other stakeholders, that theprocess provided interesting opportunities to make trade-offs or even that the issue is no longer relevant. Theprocess design and ground rules of course have to bemanaged continuously by the process-manager while thestakeholders negotiate and design [6]. But how couldvisualization-simulation play a part in such a process?

3.2 Coupling of decision-making process andvisualization

In our view, process-management and visualization-simulation can be highly complementary. Visualizationand simulation techniques can feedback information andanalysis into an inter-organizational decision-makingprocess. Process-management can provide guidelinesand rules for a collaborative visualization and simulationsetting. Collaborative visualization and simulation maycontribute to openness among stakeholders for differentperspectives and alternative solutions. At the same time,the simulation of alternative visions can constitute a'reality check' and forces stakeholders to be explicitabout their design choices and assumptions on causesand effects.

The coupling of process-management and visualiza-tion-simulation for infrastructure design could lead to thefollowing design procedure: (1) Process-managers drawup (in consultation with stakeholders) a program and aset of ground rules for the interactive design process; (2)Interacting groups of stakeholders draw visual represen-tations of possible infrastructure designs; (3) Interactinggroups of stakeholder negotiate on the important pa-rameters for the design; (4) Interacting groups ofstakeholders build and run the simulation model; (5)stakeholders assess the performance of the design; Ifdeemed necessary, the stakeholders can go through thesmall cycle again from step 2 onwards, or go to the nextstage (6) in which they identify the major decision pointsand controversies in the discussion. These issues canthan be put on the common decision agenda. Thestakeholders should further suggest procedural steps andrules for subsequent negotiation on these issues (goingback to (1). If deemed necessary, stakeholders can gothrough the cycle again from step 2, now focusing onspecific details or controversies in the negotiation.

dede(in

MzaThbloersto mareacathesulik

terarereltiathe

easimthrcy

reltesansim

Figure 1 portrays this cyclical decision-making andsign process connecting the long cycle of processsign and the short cycle of visualization-simulation forfrastructure) design.

5. Assess design performance

4. Build and run the simulation model

6. Decision agenda

1. Draw up process structure and rules

3. Negotiate parameters

2. Draw visual representations

gure 1. The cyclical decision-making and de-gn process

3. Requirements for the toolsIn a study on a similar collaborative procedure,

aghnouji et al. [7] conclude that sketching, or visuali-tion is an important element in stakeholder sessions.ere is a high potential for using simulation buildingcks for interactive modeling. However, the research- also concluded that the amount of time that is neededbuild, adjust and run a simulation model constitutes ajor obstacle for collaborative stakeholder sessions. Inl-life cases a short design cycle as sketched above,

n take weeks or longer. The decision-making processn runs the risk of losing momentum. Stakeholders

ch as residents and environmental associations areely to drop out.Specific requirements for the use of such tools in in--organizational networks would therefore be that they fast, easy to work with, can cope with informationevant to various stakeholders and support the nego-tion process by generating mutual understanding about issue.Faced with the challenge of increasing the speed and

se of the design cycle, we developed a visualization-ulation tool that allows the stakeholders to go

ough the long cycle in about a day and several shortcles in half a day (cf. figure 1).A gaming-simulation environment provided us with aatively safe but complex inter-organizational setting tot the workability and effectiveness of the approachd tools. In the next section the details of gaming-

ulation and the tools will be presented.

s (HICSS’03)

Proc0-7

4. Gaming-simulationA gaming-simulation provides a safe environment,

based on reality, in which participants can experimentwith decisions and negotiations [2, 8]. At the heart of thegame is a plot of events, called a scenario. The partici-pants in a gaming-simulation play various ‘roles’ that arederived from existing organizations and individuals. In anumber of rounds, the participants make decisions, formcoalitions and make compromises based on their givenand/or self-constructed goals and interests. One or moregame moderators facilitate the game.

A gaming-simulation is not primarily intended as a‘game’ but rather as a serious, decision-oriented study,and is therefore also designated as a policy exercise [9].Remarkably, gaming-simulation has characteristics ofboth an experimental research-design and interpretative-research and can be used for research as well as inter-vention and learning [8]. As a research design, a gaming-simulation has characteristics of an experiment: (semi)controlled conditions, repeatability of sessions, first handobservation and opportunities for pre-test/post-testmeasurements. In addition, it is an excellent stimulus forevaluative discussions with participants on the subject athand.

To explore and study the way visualization-simulation tools can support the early phase of complexinter-organizational decision-making, we opted for thedesign of an inland container terminal as a case. A quickscan of the matter indicated that the issue of containerterminal planning is high on the political agenda in TheNetherlands and that it has sufficient complexity in termsof interdependent stakeholders and interrelated parame-ters. The characteristics of the important elements for aterminal design such as its location, the quays, roads,ships, trucks, cranes and containers, gave adequate op-portunity to develop a sophisticated but usable visuali-zation-simulation tool.

The game design process largely followed the designsteps as described by Duke [2]. A systems analysis of aninland container terminal was conducted by documentstudies, interviews and visits to existing container termi-nals. Technical, economic, financial and geographicaldata on container terminals were gathered and used forthe game scenario, maps and tools. The gaming-simulation Containers a drift and the visualization-simulation tool in it, are described in the following sub-sections.

4.1 Containers a DriftThe game, Containers a drift, focuses on the early

stage of decision-making about an inland container ter-minal to be located near the fictitious provincial town ofMaaswijk.

The objectives of Containers a drift as a training en-vironment were defined as follows: (1) to provide acomplex technical system design environment in which

pepsapaaado

pthta(MNoloctati

trfeIntimmtetetr

thainGinlonmwee

articipants - either students or real stakeholders - canxperiment with a process-oriented management ap-roach to a collaborative design process; (2) to provide afe but complex social-political environment in which

articipants can learn and experiment with interactivend modular visualization-simulation tools; (3) to learnnd reflect on the combination and integration of insightsnd techniques from process-management and systemsesign, both for academic research, teaching and supportf real life design processes.

Containers a drift can be played with 25-35 partici-ants divided over 10 roles. The various stakeholders ine game are: the Ministry of Transportation, the con-iner terminal operator Mega Container Terminal

CT), the municipality of Maaswijk, the province ofoord-Brabant, a commercial bank, potential customersf the terminal such as Holland Food, an association ofcal residents, a local environmental group and various

ompanies involved in shipping, logistics and transpor-tion. Each role is played as a team by two to four par-cipants.

.1.1 The game scenarioThe game's scenario, or plot of events, describes the

ackground of the case, the characteristics of the mu-icipality of Maaswijk and gives an overview of theles and the tasks and competencies of each role. By

nd large, the plot of the scenario is as follows.In recent years, a strong increase in the demand for

ansportation of goods has led to serious negative ef-cts in terms of congestion and environmental damage. its national freight policy, the Ministry of Transporta-

on therefore enhances the development of inter-modaleans of transportation. In the Netherlands this impliesaking optimal use of innovative combinations of wa-rway, railway and road transportation. Inland containerrminals are an inevitable link in these inter-modalansportation chains.

A policy-scan has shown that it is worth to exploree feasibility of an inland container terminal situated in

neglected harbor area near an important waterway anddustrial zone in the town of Maaswijk. MCT, a largeerman container terminal operator, has showed interest developing the project commercially. However, manycal and regional actors are needed to realize the termi-

al. The terminal will have to be financed, it will have toeet customers demands, the municipality and provinceill have to approve and co-operate, local residents and

nvironmentalists may obstruct and slow down the proj-ct by starting legal procedures.

ask one: design of the decision-making process (theng cycle in figure 1)The Ministry of Transportation and MCT have there-

re set up a joint project group. The process-managersf this project group are made responsible for the initial

es (HICSS’03)

Pro0-7

negotiation and information process with all importantactors in the region. The process-managers are instructedin their role description that the general idea in this earlystage of the project is to have a general and inter-organizational exploration of the political, social, envi-ronmental, economic and logistical feasibility of thecontainer terminal, so that a preliminary agreement - ago /no-go decision- can be reached among all actors forthe next stage of design and decision-making. The proc-ess-managers are reminded that in this stage, the devel-opment of a shared vision of the container terminal andthe identification of the items on the agenda, are crucial.Not all disagreements or problems have to be settled inthis stage. No decisions on the definite design for thecontainer terminal have to be made yet. Most main ob-jectives for the process-managers are that conflictinginterests and disagreements are recognized and put on acommon agenda, that the various conditions forstakeholder cooperation are met, that stakeholders speaka common language and understand the basic implica-tions for the design of a terminal, but, most of all that thenecessary level of trust between stakeholders is reached.

Task two: design and evaluate a terminal supported bythe visualization-simulation tool (the short cycle in fig-ure 1)

The Ministry of Transportation will only subsidize thecontainer terminal if a number of social, financial, eco-nomic and environmental criteria are met. At the end ofthe game therefore, the participants are required to pres-ent to the director-general of the Ministry of Transporta-tion, a (few) design(s) of a container terminal, indicatingits financial, logistical and environmental feasibility, aswell as the level of support by the political and societalstakeholders. The designs of the container terminal arethe result of a collaborative and interactive design proc-ess which takes place during the game using the visuali-zation-simulation tool. In a covenant, the level of supportfor the container terminal and the continuation of theprocess has to be expressed by the stakeholders. Thecovenant specifies the agreements on procedure andproject and sets the agenda for further negotiation.

4.1.2 The steps of playAt the start of the game, the participants are briefed

about the objectives and procedures of the game. Thevisualization-simulation tool they are going to use isdemonstrated. The participants are given some time toread the manuals and role descriptions, prepare their roleand discuss their stakes and interest with fellow teammembers.

uthdcastthqasitouojopaadWligbotiineuo

tovmth

hoto 1: Impression of the game

The process-managers have the difficult task to drawp a process design for the negotiations and planning ofe terminal. In this stage the emphasis lies on the proce-

ure of the design - the how? - and not so much on theontent of the decision - the what? In consultation withll actors the process-managers have to come up with aructure - or program - as well as some ground rules fore interactive design process of the terminal. Important

uestions for the process-managers in this stage are: Arell stakeholders actually going to use the visualization-mulation tool or will only a few stakeholders use theol, while others negotiate on other aspects without

sing it? Are the design teams going to be heterogene-us, i.e., mixing all sort of interests and stakeholders in aint design session, or homogeneous, e.g., private com-

anies in one team, residents and environmentalists innother team et cetera? How will small group sessionslternate with plenary sessions? How are the alternativeesigns of various design teams going to be compared?hat ground rules between the players could be estab-

shed to make sure: (1) that the design process safe-uards important core-values of actors, e.g., confidentialusiness information is protected; (2) that the process ispen and transparent, e.g., that all stakeholders can par-cipate fairly; (3) that the process shows progress, lead-g, for instance, to timely results; and (4) that the proc-

ss is based on good information and knowledge, e.g.,ses the right factual data and integrates various sourcesf information.

In other words, the stakeholders in the game first have agree on how they are going to design and use the

isualization-simulation tools, i.e., design the decision-aking and design process, rather than just start usinge tool without careful deliberation.After initial consultation with all stakeholders, the

rocess-managers present a draft process design. In alenary session, the stakeholders may react and commentn this proposal and suggest adaptations. Only after the

process design has been accorded, the participants pro-ceed with the visualization and simulation of the con-

es (HICSS’03)

Pro0-7

tainer terminal design, following the accorded processstructure and ground rules (see figure 1). The processdesign for this second part of the day varies from sessionto session but will likely be based on three to four designteams - each about eight participants - alternated withplenary discussions and presentations of intermediateresults. In parallel, a covenant with agreements for thenext stage - which will not be simulated during thegaming-simulation - is drafted. The designs and thecovenant supported by the key stakeholders are pre-sented to the director-general of the Ministry of Trans-portation. The game is than brought to an end, more orless at the start of a new decision-making and designcycle (see figure 1). The process and results are evalu-ated with the participants in a plenary discussion.

4.2 The visualization and simulation design toolTwo types of design tools are available during the

game: (1) a Geographical Information System (GIS)containing all sorts of relevant data on the area ofMaaswijk; (2) a visualization-simulation tool that is usedto design and evaluate a design of a container terminal.

4.2.1 The geographical information system (GIS)Geographical maps and a GIS of an existing town

situated along an important waterway in the south of theNetherlands, were used to make up the fictitious town ofMaaswijk. The GIS and maps of Maaswijk can be con-sulted during the game in order to get relevant environ-mental and spatial data, such as on the depth of the har-bor, land property, ecological or noise zones, housingareas, rules and standards, contaminated soils, et cetera.The map of Maaswijk was also used as background inthe Visio drawing tool.

4.2.2 The visualization-simulation toolThe visualization-simulation tool was tailor-made for

the simulation game The tool was available for all roleson common laptops and at four modeling stations withfast computers and beamers. The decision when and howto deploy the tool was left to the players.

The visualization-simulation tool consists of fourparts: (1) a drawing tool for the general layout of theterminal; (2) a database containing information on es-sential building blocks; (3) a discrete event simulationtool for the evaluation of a terminal design on logisticalparameters and (4) a spreadsheet for the presentation ofperformance indicators.

(1) Drawing and sketching in VisioThe participants start the design process by sketching

the terminal lay-out in the computer software programVISIO 2000. The drawing tool contains a geographicalmap of the search-area where the terminal has to belocated. Visio provides the participants with the follow-ing set of drawing blocks for a container terminal: a

quThtranoennugi

ofqucutotypaqutictrainscsizthna

gitenutasto

ay, cranes, storages, roads and parking lots for trucks.rough negotiations the stakeholders have to makede-offs on the exact location of the terminal - in therth, middle of south of the search area - and the differ-t options for all drawing blocks such as the type andmber of cranes and the length of the quay. Figure 2,ves an example of a container terminal drawing.

gure 2. Example of a terminal drawing

) Making design choices in a databaseThe next stage of the design process is the selection

preferences in the database. The database containsantified information about vehicles, trucks, ships andstomers. Through negotiations the stakeholders have decide on important options for the design such as thepe and number of vehicles, trucks and ships. Partici-nts take into account their choices on cranes and theay, made previously in the Visio-drawing. The par-ipants have different preferences and need to makede-offs, for instance, on their choice of ships taking

to account that ships have different ship sizes andhedules. A ship schedule in combination with shipe, the number of cranes and storage capacity influence

e maximum number of customers the container termi-l will be able to handle.

) Developing and running a discrete event simulationThe computational model is based on interrelated lo-

stical and operational processes which determine therminal's performance. To give an example: when thember of trucks is not sufficient to transport the con-

iners to a company, too many containers will stay inrage. New containers can not be moved out of a ship

es (HICSS’03)

Pro0-7

and therefore new ships cannot arrive. The lead time ofriver transport will strongly increase.

The exact relation between decisions and effects ishard to predict, due to the dynamic character of the in-teraction. Discrete event simulation [10] is used to getinsight into a terminal design's performance. Under nor-mal conditions, the development of discrete event simu-lation model will take too much time for a gaming-simulation. Depending on the level of detail it may takeseveral weeks [11].

The simulation building block approach used for thegame should allow the stakeholders to develop a discreteevent simulation model in about fifteen minutes. Thesimulation building blocks approach is based on object-oriented concepts and reusability of small model parts[12]. The simulation design tool for Containers a driftuses fifteen different simulation building blocks, exactlymatching the Visio drawing blocks. Several controlmechanisms organize the simulation process so that asimulation model is generated and executed more or lessautomatically.

The model simulates about 22 days of the terminal inoperation and subsequently generates information on agreat many performance indicators such as lead times,waiting times, utilization of quays, queue length, but alsoinformation on emissions and noise.

(4) Performance of the design in excelIn the last stage of the visualization and simulation

cycle, the outcomes of the simulation model are pre-sented in a customized Excel-sheet. The indicators aregrouped in financial, logistical and environmental indi-cators. The main financial indicators are costs, revenuesand required investments. The logistical indicators showthe level of utilization of vehicles, parking lots, storages,trucks, ships, quays and cranes. In addition it showsqueue lengths, waiting times and lead times of variouslinks in the inter-modal chain of container movements.

The four different tools described above are con-nected together with the use of Visual Basic for Appli-cations.

The visualization and simulation design environmentwas tested prior to the game. It showed stable perform-ance. In a single user version, it allowed us to go throughthe whole process of drawing, running and evaluating asimple container terminal design in about 5 minutes. Weassumed that during the game, interacting groups ofstakeholders would be able to make and run a simpledesign in a quarter of an hour.

4.3 Expectations about the use of the tool in thegame

It was assumed that the tool would be fast and easy touse and would speed up the early phase of the infra-structure design process. The tool should enable theparticipants to go through the long simulation cycle in

wseofpr

agsihialwcothth

ornuthmimthblcastcr

visise

abprou

lothinTvesttireprtaim

e day and several small cycles in half a day (Ctf figure.An important question was whether the participants

ould be able to structure these design cycles them-lves and if so, what this structure would be. What rules interaction would they formulate to facilitate thisocess?It was furthermore assumed that the use of the tool

ould enhance mutual understanding by the stakeholdersout their different interests and perceptions. Thisould contribute to the development of mutual trust.It was further expected that the process structure and

reements in combination with the visualization-mulation tool would lead to a number of tentative butgh quality terminal designs. The evaluation of theseternative designs would lead to new insights abouthat the important decisions and possible impacts of antainer terminal are. These decisions and impacts canan be put on a common decision agenda at the end ofe game.The use of a visualization-simulation tool in inter-

ganizational decision-making however can also have amber of reverse effects. Possible disturbing effects one quality of the decision-making process are: (1) theodel may over-dominate the negotiation process e.g.,portant issues that can not be simulated are pushed off

e agenda; (2) the pre-fixed drawing and buildingocks in the tool may limit creativity and inhibit (radi-l) innovations in the design; (3) actors may use the toolrategically, e.g., they may withhold or manipulateucial information.

. Results and discussion

The most relevant findings regarding the use of thesualization tool in the inter-organizational gaming-mulation setting are presented and discussed in thisction.

.1 The process designIt was expected that the process-managers would be

le to facilitate the stakeholders to an agreement on theogram and rules well before lunch. This proved a seri-s but interesting miscalculation of the game designers.In all three sessions, the process-managers needed a

t of time to reflect on how they were going to designe process. This may have been caused by the students'experience with facilitation and process-management.he process-managers however immediately adopted ary closed attitude towards the stakeholders. They

rongly focused on content and details, instead of put-ng the big issues on the agenda. They seemed veryluctant to go and talk with the stakeholders about theocess. While the process-managers hardly divided anysks within the team and were internally oriented, manyportant stakeholders felt neglected and already started

s (HICSS’03)

to explore their own container terminal design. In somecases, coalitions were about to be formed and dissentingstakeholders were already put aside. These actors startedcomplaining to the process-managers.

In all three sessions, the game moderators were forcedto push the process-managers along. An hour beforelunch, the process-managers were ready to present adraft process design with some rules for interaction.Subsequently, the draft proposals in all three sessions ledto fierce debate and resistance by the stakeholders. In aplenary session they raised many objections to the proc-ess design for instance on the compositions of the designteams, the type of designs they were going to make andhow these design would be assessed. At some times, theprocess-managers were drowning and were struggling tostay in charge.

The plenary session before lunch however greatlycontributed to the understanding of the participants onwhat they were doing and how they could best use thevisualization-simulation tool. In all three games, a work-able and effective process design was accorded. Theprocess designs of the three sessions differ with regard tothe grouping of stakeholders, homogenous groups versusheterogeneous groups, and in the design themes given tothe various groups.

During the afternoon, parallel subgroup sessions wereorganized in which most participants took part, follow-ing the accorded process design. At the end of the day,the various results were presented. Due to time pressure,in none of the three gaming sessions, the stakeholderswere able to draft a covenant. The process-managers instead asked the participants to go back to their 'office'and answer in their team one of the following questions:'Yes, we will support and co-operate in the next phase onthe condition that....!' or: 'No, we will not support andco-operate in the next phase because...'. The process-managers were asked by the game moderators to thinkabout what they could do if one or more stakeholderswould indicate that he/she would not accord with theterminal plans and exit the process. When all participantshad presented their 'conditional yes' or their 'argued no',the process-managers formulated their conclusion to thegroup.

In all three sessions, the participants agreed to supportthe terminal and participate in the next stage of design.

5.2 The use of the toolsDuring the morning part of the gaming sessions,

many participants already started to negotiate and de-sign. Due to ineffective process-management the discus-

siculothteacstthoflotynawanag

teabdesiretisebe

sinerethseevTqu

siprinesla

5Bpobequ

ons in the morning appeared unstructured and unfo-sed. The level of information in these discussions wasw. After the process-managers regained their grip one process, the discussions in the afternoon were cen-red around the visualization-simulation tool in multi-tor teams. Following the order of the tool, theakeholders discussed and negotiated on the location ofe terminal, the length of the quay, the amount and type cranes, the size and height of the container-stacks, thecation of the parking spots, the number of ships, thepe of vehicles and, finally, the customers and the fi-ncial values. Other points of discussion such as theidth of the ships lock, noise-levels, the ecological zoned the yacht harbor were identified and put on theenda.It was expected that the tool would enable the design

ams to make a general design of a container terminal inout a quarter of an hour. In the afternoon session eachsign team would have time to go through several de-

gn cycles (cf. figure 1) thereby enhancing learning. Thespondents afterwards estimated that the design cycleme had been between 60 and 90 minutes for the firstssion, and just below 60 minutes for the later sessionscause more powerful computers were used.Two factors slowed down the short design cycle con-

derably: (1) actors, rightfully, needed much time togotiate and make compromises, but they were also (2)luctant to experiment with the tool by first goingrough a short design cycle, test some assumptions ande what would happen. Most groups tried to optimizeery stage and decision before going to the next stage.

his usually did not contribute to the duration and theality of the discussions.At the end of all three gaming sessions, all design

ams were able to present a container terminal lay-outith detailed assessments of its performance and conse-ences.The final comparison of the container terminal de-

gns was done in a plenary discussion facilitated by theocess-managers. The discussions usually ended interesting and in depth debriefing discussions on proc-s-management and the role of visualization and simu-tion tools.

.3 Findings of the evaluationy and large, the questionnaires confirmed many of oursitive observations on the use of the tool. Table Onelow presents the responses on a number of relevantestions of the evaluation questionnaire.

es (HICSS’03)

Pro0-7

Statement n 1 2 3 4 0 Avg Std1. The Visualization-simulation tool as a whole was a good

support in making a terminal design.72 64 26 8 1 - 1.5. 0.7

2. Working together with persons from other roles onmaking the layouts and entering logistic data with thetool contributed to generating mutual understanding.

65 62 32 3 2 2 1.4 0.6

3. The tool had a positive effect on the quality of the ter-minal design that was the outcome of negotiations at theend of the day.

73 25 43 20 4 7 1.9 0.8

4. The pre-set selections when entering logistic data in thedatabase tool and the limited set of drawing elements inthe drawing tool, limited me in making the design of theterminal the way I wanted.

72 11 26 31 22 10 2.5 0.9

5. The evaluation of terminal performance of various de-signs was well supported by the visualization-simulationtool.

73 51 34 12 1 1 1.6 0.8

6. The use of the visualization-simulation tool sped up thedesign process that took place during the day.

73 41 40 16 3 - 1.8 0.8

7. Making designs (consisting of layout, logistic data andoutput on terminal performance) with the tool went fastenough in relation to the progress of the game.

73 40 34 21 6 - 1.9 0.9

8. It was easy to work with the drawing tool. 50 54 30 12 4 0 1.7 0.79. It was easy to work with the database tool 47 53 34 11 2 1.6 0.610. It was easy to understand how to work with the output

files in the spreadsheet tool.55 40 46 15 0 0 1.8 0.6

11. The presentation of terminal performance in the outputfiles in the spreadsheet tool was clear.

55 36 40 24 0 0 1.9 0.7

Table 1. Responses of participants to statements in the questionnaire

By and large the responses indicate the following (CtfTable 1):

− High participation. Seventy-eight percent of therespondents actively participated in making a de-sign with the tool. The remaining students ac-tively engaged in other activities such as facilita-tion of the process and discussions of external -environmental - aspects of the terminal.

− Easy to work with. Eighty percent or more of therespondents found the drawing, database and theoutput files easy to work with (cf. Table 1).

− Mutual understanding. Eighty-nine percent of therespondents state that they worked together withpeople from other roles with the design tool. Ni-nety-four percent of the participants agreed (alittle) that working together with persons fromother roles contributed to mutual understanding.

− Short design cycle. About eighty percent of therespondents indicated that the tool sped up the de-sign process and that the making of designs withthe tool went fast enough for the game.

altofopadaresiorere(thelm

wcosimhiskmsimde

4 Limitations of the toolA number of expected reverse effects of the tool were

so substantiated. Some respondents indicated that theol had been too detailed and generated too much in-rmation on the terminal performance. Other partici-nts however indicated that they needed more specificta on specific indicators to base their decision. Somespondents stated that the tool dominated the discus-n, that the use of the tool was fun, but in fact less

levant for stakeholders such as environmentalists andsidents. Moreover, a marked number of respondentsirty-eight percent) seemed to indicate that the drawing

ements in the drawing tool somewhat limited theaking of a creative design (Ctf Table 1).

ConclusionThe gaming-simulation Containers a drift proved a

ell balanced research and training environment formbining process-management and visualization andulation. It confirmed that process-management is a

ghly complex activity requiring group facilitationills, academic insights in inter-organizational decision-aking and experience with appropriate visualization-

ulation tools [13]. In the early stage of infrastructuresign, stakeholders easily fall into the trap of focusing

on content before agreeing on process. This is likely to

ces (HICSS’03)

backfire in later stages of the project. Stakeholdersshould be consulted and included in setting the agendaand defining the rules and procedures.

In all three sessions, the highly conflictual and con-fusing discussions of the morning sessions, eased downwhen consensus was reached about how they were goingto design and explore the issues further (just before orafter lunch). Through the conflicts the partcipants inter-nalized the design process and some ground rules wereestablished. The accordance reached on the process andthe opportunity to discuss and visualize their conflictinginterests with respect to the container terminal whileusing the fast and easy to use simulation tool, led to amore constructive exploration of the issues and solu-tions.

In our view, the experiment confirmed that a process-management approach to decision-making processesneeds analytic activities, such as visualization and simu-lation, to reach a higher level of mutual understanding.And vice versa that visualization-simulation needs re-flective activities for instance on why, how, by whomand by what rules the tools are going to be used.

Visualization-simulation tools are useful but shouldbe flexible, robust, fast and open to different perceptionsand interests. The visualization-simulation tools devel-oped for the game Containers a drift was evaluated on anumber of relevant characteristics for process-management. The evaluation results are promising andshow that the tools are fast, easy to work with, contributeto the quality and process of negotiation and generatemutual understanding.

The tools and the gaming-simulation were of course apilot version. Using the many useful suggestions forimprovement, the simulation game will next be used inour faculty's Master of Science course on general designmethodology as well as for academic research and con-sultancy projects.

An important point for discussion of course iswhether a gaming-simulation can be an adequate repre-sentation of the real complexity and politics of inter-organizational decision-making on infrastructures. Thisis a relevant question because the way of working andthe tools used in the gaming-simulation should be trans-ferable to real stakeholders and real design challenges. Asimilar representation question is whether the visualiza-tion-simulation tool can represent or model inland termi-nals in a sufficiently realistic way.

The tool appeared to be sufficiently rich and realisticfor the gaming-simulation when played with students.For future experiments with players that are profession-ally involved with inland container terminals or otherinfrastructures, the tools will have to be validated moreextensively. The experiments of the gaming-simulationhowever provide a promising basis to improve and adaptthe tools and try them out with real stakeholders and realproblems.

JootheThprotheDriinfTe

knowledgementsThe authors want to thank Weiyu Du, Anne Elshout,st van Kempen and Bart van den Berg for the worky have done to make the game and tools a success.e authors are grateful to the IMAGO-Gymnasionject of the Technical University of Delft for funding experiment. More information about Containers aft, a video-demo of the computer model and generalormation on gaming-simulation at Delft University ofchnology can be found at www.gymnasion.tudelft.nl.

ferencesDe Bruijn, H., Heuvelhof, E. ten. (2000) Networks andDecision-making. Utrecht: Lemma.Duke, R (1980). A paradigm for game design. in: Simula-tion and Games, 11, 364-377Hischemöller, M., Hoppe, R. (1996) Coping with intracta-ble controversies: the case of problem structuring in policydesign and analysis. Knowledge and Policy: The Interna-tional Journal of Knowledge Transfer, 8,4: 40-60.Mason, R. & Mitroff, I. (1981) Challenging strategicplanning assumptions. theory, cases and techniques. NewYork: John Wiley & Sons.De Bruijn, H., Heuvelhof, E. ten , In ‘t Veld, R. (2002)Process Management. Why Projectmanagement fails incomplex decision-making processes. Kluwer AcademicPublishers.Bockstael-Blok, W. (2001); Chains and networks in Mul-timodal Passenger Transport; exploring a design ap-proach; PhD-thesis; Delft, DUP Science.Maghnouji, R., et al. (2001) ; Collaborative SimulationModeling : Experiences and Lessons Learned, Proceed-ings HICSS 2001Geurts, J. Joldersma, F. Roelofs, E. (eds.) (1998) Gam-ing/simulation for policy development and organizationalchange. Tilburg: TUP.Toth, F. (1998); Policy exercises, in Simulation andGaming (19), pp235-276.

Law, A.; D.W.Kelton (1999); Simulation Modeling andAnalysis; McGraw-Hill, 3rd edition

Banks, J. (1998); Handbook of simulation, Principles,Methodology, Advances, Applications and Practice; JohnWiley & Sons.

Valentin, E.C.& A.Verbraeck (2002); Simulation usingbuilding blocks in: F.J.Barros, N.Giambiasi Proceedingsconference on AI, Simulation and Planning, pp65-71.

Vennix, J. (1996); Group model building. facilitating teamlearning using system dynamics. Wiley Chichester.

s (HICSS’03)

Supporting the Design of an Inland Container Terminal through Visualization, Simulation and Gaming

Documents