PM Approach

Interface Management in multidisciplinary infrastructure project development
Interface Management in multidisciplinary

infrastructure project development
Diminishing integration issues across contractual boundaries in a Systems
Engineering environment
MSc Thesis | Construction Management and Engineering

Sebastiaan Staats | March, 2014
Colophon
Report
Type:
Title:
Graduation report
Interface Management in multidisciplinary infrastructure project
development
Diminishing integration issues across contractual boundaries in a
Systems Engineering environment
Lexmond
Monday, 3 March 2014
Subtitle:
Place:
Date:
Author
Name:
Study number:
Telephone number:
E-mail address
Course:
Master:
University:
S.A. (Sebastiaan) Staats

1339133
+31(0)6 48 01 88 14
Sebastiaan_staats@hotmail.com
CME2000 Graduation Thesis
Construction Management and Engineering (CME)
Delft University of Technology
Faculty of Civil Engineering and Geosciences
Graduation committee
Chairman:
Prof.dr.ir. M.J.C.M Hertogh
m.j.c.m.hertogh@tudelft.nl
First commissioner:
Dr.ir. G.A. van Nederveen

g.a.vannederveen@tudelft.nl
Second commissioner:
Ir. T.J. van Beek

Faculty of Mechanical, Maritime and Materials Engineering
thomvanbeek@gmail.com
External commissioner:
Ing. S.L. van der Geest

Ballast Nedam BV
Afdeling Proces Informatie Management (PIM)
s.vd.geest@ballast-nedam.nl
Technical University of Delft
Ballast Nedam
2014
II
Ballast Nedam
2014

2014
Preface
By means of this report I finish a period of seven years of studies at the Delft University of Technology. In 2006,
I started with the Bachelor of Civil Engineering mainly due to a keen interest in the realization of large
construction projects. After completing my bachelor, I realised that pure civil engineering was not exactly what
I was interested in, instead it is the management of these large construction projects that has aroused my
interest. Therefore, I made the decision to continue my studies in the field of construction management and
started with the Master program Construction Management and Engineering. During my master studies, I
learned a lot about project and process management, as well as the Systems Engineering methodology. As final
part of my study, I hereby present you my graduation thesis.
I would like to express my gratitude to the people who made this all possible. First of all, I want to thank Ballast
Nedam for giving me the opportunity for conducting this graduation thesis and especially the department of
Project Information Management. Steven van der Geest, who performed the role of external commissioner,
supported me during this period and provided me with information and useful suggestions. I also want to
express my gratitude to Professor M.J.C.M Hertogh and G.A. van Nederveen of the faculty Civil Engineering &
Geosciences and to T.J van Beek of the faculty of Mechanical, Maritime and Materials Engineering for their
constructive feedback.
Last but not least, I want to express my gratitude to my friends and family that have supported me during my
entire period of study allowing me to have an enjoyable time.
The only thing that remains now for me is wishing you much pleasure while reading this report.
Sebastiaan Staats
Lexmond, March 2014
III
Ballast Nedam

2014
IV
Ballast Nedam

2014
Executive Summary
The introduction of integrated contracts led to a shift of responsibility from the client to the contractor.
Contractors are not only responsible for construction, but also for the design of a project. The use of integrated
contracts asks for new approaches and processes. Systems Engineering (SE) has been introduced in order to
organize the processes of integrated projects. SE is a method of organizing complex projects and has become a
standard in the construction industry. Within SE, the design procedure consists of decomposing a complex
system, or project, into a set of sub-systems. These sub-systems may further be divided into components. The
SE approach for product development will ultimately break down the design effort down to a point where an
individual team of engineers are able to design one component. Each component is small portion of the overall
system that is manageable for the given development schedule.
Infrastructure projects have become more complex, and larger in scale, due to the advances in technology and
operations. These projects are usually outsourced to multiple contractors and sub-contractors. These parties
could have different backgrounds and working cultures, and they are usually located at different geographical
locations. Each contactor is responsible for the development of one or more components or sub-systems.
Although these components and sub-systems are being developed separately, many share a common
connection or interface. When these commonalities are not taken into account, integration issues can easily
occur when the components are integrated.
Problem statement
In practice, numerous projects have been delayed and extended their budget because of integration issues.
What is notable about these failed projects is that the most expensive mistakes and delays can be traced back
to integration issues between the different design teams. Design teams usually succeed in the development of
the individual projects components and subsystems within their scope, but do not pay enough attention to the
project as a whole. The lack of Interface Management (IM), between different engineering disciplines, leads to
unnecessary design iterations and rework, causing additional costs and a substantial delay of the project.
Systematic approach for Interface Management
In this thesis, a systematic IM method is proposed to diminish integration issues across contractual boundaries
within infrastructure project development. Analysis has been done through a literature research and a case
study have been conducted.
The case study that was conducted explores and evaluates current IM processes. The main factors leading to
integration issues have also been identified. The main issues mentioned are: overall unawareness of interface
issues, ownership and responsibilities regarding the interfaces are not clear, lack of coordination among
specialties, insufficient and inaccurate interface information, poor information flow, poor ordering of tasks, no
overview of what the crucial interfaces are, and lack of a proper IM organization (IM team and tools). These
main factors could be brought back to two categories which are (1) poor communication among the involved
parties and (2) poor coordination among the involved parties.
The focus of this thesis is to establish a basis for a structured IM process. The IM process has to contain both
technical aspects (tools and software) as well as organizational aspects. Tools and software could be of major
assistance during the management of interfaces. However, without the foundation of a well-structured
process, interfaces simply cannot be managed effectively. Software may assist in detecting physical interfaces,
Ballast Nedam

2014
or manage data in a database, but there must be a systematic process behind it. Therefore, the focus in this
thesis is on the organizational aspects of the IM process. Five main steps for a systematic IM process have been
identified:
1.
2.
3.
4.
5.
Interface Identification
Interface Documentation
Interface Communication
Interface Control
Interface Closing
The IM process requires an IM team which is responsible for the implementation of the process. An interface
manager has to be appointed, and each design team should appoint an interface coordinator who serves as the
single point of contact regarding the interfaces.
Emphasis should be on the early recognition and elaboration of interfaces. Interface meetings have to be
organized in where all involved parties (including people from design, construction and maintenance)
systematically identify the interfaces. The internal and external interfaces could be identified by looking at the
system from three perspectives, namely the Functional, Systems and Requirements Breakdown Structure (FBS,
SBS, RBS). These interfaces are mainly identified based on the experience and common knowledge of the
project members.
Standardized forms, charts and registers have to be used for the purpose of documenting and controlling
interface related information. Standardized forms are, for instance, used to document the agreements which
are made to uncouple an interface, while charts are used to document clearly defined roles and responsibilities
regarding the interfaces.
An interface exists between two components and needs to be uncoupled so that both design teams can finish
their designs individually. Interface Agreements (IAs) are forms used to standardize the exchange of interface
information and deliverables between the participants. In here the required interface information is described,
and deadlines are given when this information is needed. By using these forms, most interfaces can be
uncoupled.
When it is not possible to uncouple an interface with standardized forms, other strategies could be applied.
Design activities can be pulled forward so that both objects are designed at the same point in time. Forming
cross functional teams, using team problem solving and sharing ranges of acceptable solutions can assist in
collaboratively finding the most optimal solution. When this is not possible, and there is no time to wait,
assumptions could be made of the interface information, and/or overdesign could be applied. These are good
strategies to speed up the process but also bring along extra risk to the project. Therefore, before applying
these strategies, the potential consequences should be examined carefully.
Interface Control
Interfaces could carry risk to the project, some more than others. In order to understand what interfaces need
to be monitored and controlled closely, the interfaces have to be prioritized based on an overall risk analysis.
During the frequently held interface meetings, all open and high-risk interfaces will be discussed with all
involved parties. In addition, physical interfaces can also be monitored and controlled by using clash detection
software in 3D design.
VI
Ballast Nedam

2014
In order to further control the interfaces IM can be integrated with other SE disciplines like risk management,
project planning and configuration management.
Interface Closing
As last step of the IM process, the interface solution has to be verified for both objects attached to the
interface, as well as the integrated whole. When the verification is complete, the interface can be formally
closed. However, the closing of an interface does not mean the interface disappears. It means the interface
solution has been verified in the design document. Extra attention could still be required in later project phases
to make sure, for instance, all components are constructed as described.
Conclusions
Interface Management process
It can be concluded that integration issues like unnecessary design iterations and rework are very common in
infrastructure project development. It is proposed to appoint an IM team and implement a systematic process
for IM which focuses on preventing the main factors causing the integration issues. By fulfilling these aspects,
integration issues across contractual boundaries in infrastructure project development can most likely be
diminished. However, it is important to mention that the described solution has not been tested in a real life
case and therefore requires more research before the exact benefits can be described.
Contractual involvement
The type of involvement of the individual parties in the project should not be underestimated and might even
be the most crucial factor leading to integration issues. The type of contract mainly determines the contractors
willingness to coordinate and collaborate with others. Coordination and communication among the parties
becomes much harder when a contractor is not responsible for the projects main objectives (such as the
delivery date) and does not bear the risk of potential fines. Therefore, it is crucial that the project owner
understand the importance of IM, and enforces the involved parties by contract to cooperate regarding the
interfaces (especially the electrical engineer).
Clear scope of work
The scope of each contractor has to be clear before an IM process of identifying and elaborating the interfaces
can be successful. Common problems include confusion about the responsibility of contractors and
disagreements about their scope of work. Before starting with a project, the contractual boundaries for each
contractor have to be clear and all high-level interface responsibilities should be determined. When all parts of
the project are not sufficiently allocated to the involved parties, grey areas could arise between the scopes of
work. These grey areas, of which nobody knows who is responsible, could be a huge risk to the project. Clear
scope packages could be derived by making a clear decomposition, and coupling all breakdown structures to
each other. Each component and each activity should be allocated to the responsible contractor as soon as
possible.
VII
Ballast Nedam

2014
VIII
Ballast Nedam

2014
Samenvatting
De invoering van integrale contracten heeft geleid tot een verschuiving van de verantwoordelijkheden van de
klant naar de opdrachtnemer. Opdrachtnemers zijn niet alleen meer verantwoordelijk voor de uitvoer van een
constructie project, maar ook voor het ontwerp. Het gebruik van integrale contracten vraagt om nieuwe
werkmethodes en processen. Om de processen van gentegreerde projecten te organiseren is Systems
Engineering (SE) gentroduceerd. SE is een methode om complexe projecten te organiseren en is uitgegroeid
tot een standaardmethode in de bouw. Binnen SE begint het ontwerpproces met het ontleden van het
complexe systeem, of project, in een reeks van subsystemen. Deze subsystemen kunnen verder worden
onderverdeeld in componenten. Volgens de SE methodiek wordt een project ontleed tot aan het punt waarop
een individueel ontwerpteam een component kan ontwerpen. Dit component is een klein onderdeel van het
totale project, en is beheersbaar binnen het gegeven tijdschema.
Infrastructurele projecten zijn complexer en grootschaliger geworden als gevolg van de vooruitgang in
technologie en operaties. Deze projecten worden meestal uitbesteed aan verschillende aannemers en
onderaannemers. Deze partijen kunnen verschillende achtergronden en werkculturen hebben, en bevinden
zich meestal op verschillende geografische locaties. Elke aannemer of onderaannemer is verantwoordelijk voor
de ontwikkeling van n of meerdere componenten of subsystemen. Hoewel deze componenten vaak
afzonderlijk ontwikkeld worden, hebben veel van deze componenten en subsystemen een verbinding of
raakvlak met elkaar. Wanneer deze raakvlakken worden verwaarloosd, kunnen er problemen optreden tijdens
het integreren van deze componenten op de werkplaats.
Probleemstelling
In de praktijk hebben integratieproblemen er toe geleid dat veel projecten zijn vertraagd, en het budget
hebben overschreden. Wat opvalt aan deze mislukte projecten is dat de grootste fouten die leiden tot hogere
kosten en vertraging gerelateerd kunnen worden aan integratieproblemen tussen de ontwerpteams.
Ontwerpteams slagen er meestal in de componenten en subsystemen binnen hun werkgebeid te realiseren,
maar besteden niet genoeg aandacht aan het project als geheel. Het gebrek aan raakvlakmanagement tussen
de verschillende ontwerpteams leidt tot onnodige ontwerp iteraties en extra werk, wat uiteindelijk leidt tot
extra kosten en aanzienlijke vertragingen.
Systematische aanpak voor raakvlakmanagement
In dit afstudeerrapport is een systematische aanpak voor raakvlakmanagement voorgesteld om
integratieproblemen te verminderen tussen de contractuele partijen tijdens de ontwikkeling van
infrastructurele projecten. Onderzoek is gedaan door middel van een literatuuronderzoek en het uitvoeren van
een casestudie.
De casestudie die is uitgevoerd onderzoekt en evalueert de huidige raakvlakmanagement processen. Hierin zijn
ook de huidige factoren onderzocht die momenteel leiden tot de integratieproblemen. De belangrijkste
factoren zijn: het onbewust zijn van raakvlakproblemen, rollen en verantwoordelijkheden met betrekking tot
de raakvlakken zijn niet duidelijk, gebrek aan cordinatie tussen de ontwerpspecialismen, onvoldoende en
onjuiste raakvlakinformatie, slechte informatiestroom, onjuiste volgorde van ontwerpactiviteiten, geen inzicht
in wat de cruciale raakvlakken zijn en het gebrek aan een goede raakvlakmanagement organisatie
(raakvlakmanagement team en software). Deze belangrijkste factoren kunnen worden herleid naar een tweetal
categorien, namelijk (1) een slechte communicatie tussen de partijen en (2) een slechte cordinatie tussen de
partijen.
IX
Ballast Nedam

2014
De focus van dit afstudeerrapport ligt op het ontwikkelen van een gestructureerde methode voor
raakvlakmanagement. Het raakvlakmanagement proces dient te bestaan uit zowel technische aspecten
(technische hulpmiddelen en software), alswel uit organisatorische aspecten. De technische aspecten kunnen
van grote waarden zijn tijdens het managen van de raakvlakken. Echter, zonder het fundament van een goed
gestructureerd proces, kunnen raakvlakken ook niet effectief beheerd worden. Software kan helpen bij het
opsporen van fysieke raakvlakken, of bij het managen van data in een database, maar er moet een
systematisch proces achter zitten. Daarom ligt de nadruk van dit onderzoek op de organisatorische kant van
het raakvlakmanagement proces. Vijf stappen voor een systematisch raakvlakmanagement proces zijn
vastgesteld:
1.
2.
3.
4.
5.
Raakvlak identificatie
Raakvlak documentatie
Raakvlak communicatie
Raakvlak controle
Raakvlak sluiting
Een raakvlakmanagement team is vereist dat verantwoordelijk is voor de implementatie van het
raakvlakmanagement proces. Een raakvlakmanager moet worden aangesteld, en binnen elk ontwerp team
dient een raakvlak cordinator te worden benoemd die zal dienen als eerste aanspreekpunt betreffende de
raakvlakken.
Raakvlak identificatie
De nadruk moet liggen op het zo vroeg mogelijk erkennen en uitwerken van de raakvlakken. Raakvlak
overleggen moeten georganiseerd worden waarin alle betrokken partijen (waaronder mensen van ontwerp,
uitvoer en onderhoud) vertegenwoordigd zijn om systematisch de raakvlakken te identificeren. De interne en
externe raakvlakken kunnen gedentificeerd worden door naar het systeem te kijken vanuit drie perspectieven,
namelijk de functie-, objecten-, en eisenboom. Deze raakvlakken zijn hoofdzakelijk gedentificeerd op basis van
ervaring en algemene kennis van de projectleden.
Raakvlak documentatie
Gestandaardiseerde formulieren, matrices en registers dienen gebruikt te worden voor het documenteren en
controleren van raakvlak gerelateerde informatie. Zo kunnen formulieren gebruikt worden voor het
documenteren van afspraken die zijn gemaakt om een raakvlak te ontkoppelen, en kunnen matrices gebruikt
worden om gedefinieerde taken en verantwoordelijkheden vast te leggen.
Raakvlak communicatie
Een raakvlak bestaat tussen twee componenten en dient te worden ontkoppeld zodat beide partijen
individueel hun ontwerp kunnen afronden. Interface Agreement (IA) formulieren worden gebruikt om de
uitwisseling van raakvlakinformatie tussen de partijen te standaardiseren. In deze formulieren is de benodigde
raakvlakinformatie beschreven en is er een deadline gegeven voor het moment dat deze informatie benodigd
is. Door het gebruik van deze formulieren kunnen de meeste raakvlakken ontkoppeld worden.
Wanneer het niet mogelijk is om een raakvlak te ontkoppelen door middel van standaardformulieren kunnen
andere strategien worden toegepast. Ontwerpactiviteiten kunnen naar voren worden getrokken zodat beide
objecten op hetzelfde tijdstip kunnen worden ontworpen. Het vormen van multidisciplinaire teams, het
organiseren van meetings, of het delen van de oplossingsruimtes met elkaar kan ervoor zorgen dat er op een
snelle manier de meest optimale oplossing gevonden wordt. Als dit niet mogelijk is, en er is geen tijd om te
wachten op de andere partij, dan kunnen er ook aannames gedaan worden over de raakvlakinformatie en/of
kan er overdimensionering kan worden toegepast. Dit zijn goede strategien om het proces te versnellen, maar
brengen ook extra risico mee voor het project. Daarom moeten vr de toepassing van deze strategien de
mogelijke consequenties zorgvuldig worden onderzocht.
Ballast Nedam

2014
Raakvlak controle
Raakvlakken kunnen risicos voor het project met zich meedragen, en de een meer dan de ander. Om er voor te
zorgen dat helder is welke raakvlakken de belangrijkste zijn, waarbij dus extra oplettendheid nodig is, moeten
de raakvlakken geprioriteerd worden op basis van een risicoanalyse. Tijdens de frequent gehouden raakvlak
overleggen worden alle openstaande raakvlakken en raakvlakken met een hoog risico besproken met alle
betrokken partijen. Verder kunnen fysieke raakvlakken bewaakt en gecontroleerd worden door het gebruik van
clash detection software in 3D ontwerp modellen.
Om raakvlakken verder te bewaken en te controleren kan raakvlakmanagement gentegreerd worden met
andere SE disciplines zoals risicomanagement, project planning, en configuratiemanagement.
Raakvlak sluiting
De laatste stap van het raakvlakmanagement proces is de verificatie van het ontwerp, voor beide componenten
van het raakvlak. Wanneer het ontwerp is geverifieerd kan het raakvlak formeel gesloten worden. Echter, na
het sluiten verdwijnt het raakvlak niet. Het betekent dat het raakvlak is geverifieerd in de ontwerpdocumenten
en dus aan alle eisen voldoet. Het kan zijn dat er nog extra aandacht nodig is voor dit raakvlak in latere fases
van het project om er bijvoorbeeld voor te zorgen dat er geen fouten worden gemaakt in constructie.
Conclusies
Raakvlakmanagement proces
Geconcludeerd kan worden dat integratieproblemen zoals onnodige ontwerp iteraties en extra werk heel
gebruikelijk zijn tijdens de ontwikkeling van infrastructurele projecten. In dit rapport is voorgesteld een
raakvlakmanagement team te benoemen en een systematisch proces voor raakvlakmanagement te
implementeren dat focust op het voorkomen van de factoren die leiden tot de integratieproblemen. Bij het
voldoen aan deze aspecten zullen integratieproblemen over contractuele grenzen tijdens de ontwikkeling van
infrastructurele projecten zeer waarschijnlijk afnemen. Echter, het is belangrijk te vermelden dat de
beschreven oplossing niet getest is in de praktijk en dat daardoor meer onderzoek vereist is voordat de exacte
voordelen van deze methode kunnen worden beschreven.
Contractuele betrokkenheid
De manier waarop de verschillende partijen zijn betrokken bij het project mag niet onderschat worden en is
misschien wel de meest cruciale factor die leidt tot integratieproblemen. Het type contract van de
verschillende partijen bepaalt grotendeels de bereidheid van de aannemers om samen te werken. De
cordinatie en communicatie tussen deze partijen wordt veel moeilijker wanneer een aannemer niet
verantwoordelijk is voor de belangrijkste doelstellingen van het project (zoals de datum van oplevering), en
niet het risico draagt van mogelijke boetes. Daarom is het cruciaal dat de opdrachtgever het belang van
raakvlakmanagement onderkent, en de betrokken partijen contractueel dwingt om proactief samen te werken
met betrekking tot de raakvlakken (vooral de elektrotechnisch ingenieur).
Duidelijke verdeling van het werk
Voordat een raakvlakmanagement proces van waarde kan zijn is het nodig dat elke partij precies weet wie
verantwoordelijk is voor welk onderdeel van het project. Verwarring over de verantwoordelijkheid van de
aannemers en onenigheid over de verdeling van het werk zijn veel voorkomende problemen. Voordat gestart
kan worden met een project dienen de contractuele grenzen voor elke aannemer helder te zijn en dienen alle
raakvlakken op het hoogste niveau te zijn vastgesteld. Grijze gebieden kunnen ontstaan wanneer bepaalde
onderdelen van het project niet duidelijk verdeeld zijn. Deze grijze gebieden, waarvan niemand zeker weet wie
verantwoordelijk is, kunnen een hoog risico zijn voor het project. Duidelijk afgebakende werkpakketten kunnen
worden gerealiseerd door het maken van een heldere compositie van het project, en door het aan elkaar
koppelen van alle breakdown structures. Alle componenten en activiteiten dienen zo snel mogelijk
toegewezen te worden aan de verantwoordelijke partijen.
XI
Ballast Nedam

2014
XII
Ballast Nedam

2014
Table of Contents
Executive Summary ................................................................................................................................................ V
Samenvatting......................................................................................................................................................... IX
Table of Contents ................................................................................................................................................ XIII
Abbreviations ....................................................................................................................................................... XV
Chapter 1: Introduction .......................................................................................................................................1
1.1
Background .............................................................................................................................................1
1.2
Problem Description ...............................................................................................................................1
1.3
Research goal and objectives .................................................................................................................3
1.4
Research questions.................................................................................................................................4
Chapter 2: Research methodology......................................................................................................................5
2.1
Research design ......................................................................................................................................5
2.2
Research constraints...............................................................................................................................5
2.3
Research approach .................................................................................................................................6
2.4
Report overview .....................................................................................................................................7
Chapter 3: Literature Study .................................................................................................................................9
3.1
From traditional to integrated contracting.............................................................................................9
3.2
Systems Engineering .............................................................................................................................13
3.3
Introduction of Interface Management................................................................................................16
3.4
Introduction of Configuration Management ........................................................................................24
3.5
Introduction to Risk Management........................................................................................................27
3.6
Conclusion ............................................................................................................................................28
Chapter 4: IM Related Research........................................................................................................................30
4.1
Concurrent Engineering ........................................................................................................................30
4.2
Negative design iterations ....................................................................................................................35
4.3
Virtual design ........................................................................................................................................40
4.4
Evaluation methodologies ....................................................................................................................40
Chapter 5: Practical Analysis .............................................................................................................................43
5.1
Case description ...................................................................................................................................43
5.2
Project Organization .............................................................................................................................44
5.3
Interface Management .........................................................................................................................46
5.4
Evaluation Current Practices ................................................................................................................49
5.5
Different Engineering Disciplines:.........................................................................................................52
5.6
Types of Interfaces ...............................................................................................................................55
5.7
Main difficulties regarding IM ..............................................................................................................57
XIII
Ballast Nedam

2014
Chapter 6: Factors causing integration issues ..................................................................................................59
6.1
Interface Management related issues ..................................................................................................59
6.2
Comparing findings case study with literature .....................................................................................60
Chapter 7: Interface Management Framework ................................................................................................65
7.1
Interface Management set-up..............................................................................................................65
7.2
Flowchart ..............................................................................................................................................68
7.3
Interface Identification .........................................................................................................................70
7.4
Interface Documentation .....................................................................................................................72
7.5
Management of high-risk and complex interfaces ...............................................................................79
7.6
Interface Communication .....................................................................................................................80
7.7
Interface Control...................................................................................................................................82
7.8
Interface Management Tools ...............................................................................................................86
7.9
Conclusion ............................................................................................................................................89
Chapter 8: Conclusions and Recommendations ...............................................................................................91
8.1
Answering of the research questions ...................................................................................................91
8.2
General conclusions..............................................................................................................................95
8.3
Recommendations for Ballast Nedam ..................................................................................................98
8.4
Recommendations for further research .............................................................................................100
References ...........................................................................................................................................................101
XIV
Ballast Nedam

2014
Abbreviations
AI
ADEPT
BIM
CE
CM
CMP
CR
DBFM
DC
DIMS
DMS
DSM
EE
E&I
FBS
IA
IBS
ICD
ICP
ID
IDD
IM
IMP
INCOSE
IR
IRD
ME
MEP
OBS
PMP
PPI
RBS
RM
RMT
SE
SBS
VDC
WBS
Action Item
Analytical Design Planning Technique
Building Information Model
Civil Engineering
Configuration Management
Configuration Management Plan
Change Request
Design, Build, Finance and Maintain
Design & Construct
Design Interface Management System
Document Management System
Dependency Structure Matrix
Electrical Engineering
Electrical and Instrumentation
Functional Breakdown Structure
Interface Agreement
Interface Breakdown Structure
Interface Control Document
Interface Control Plan
Identification
Interface Definition Document
Interface Management
Interface Management Plan
International Council on Systems Engineering
Interface Register
Interface Requirements Document
Mechanical Engineering
Mechanical, Electrical and Plumbing
Organizational Breakdown Structure
Project Management Plan
Process Parameter Interface
Requirement Breakdown Structure
Risk Management
Requirements Management Tool
Systems Engineering
System Breakdown Structure
Virtual Design and Construction
Work Breakdown Structure
XV
Ballast Nedam

2014
XVI
Ballast Nedam
Chapter 1: Introduction
This first chapter introduces the subject, in paragraph 1.1, background information is given which is followed by
the problem description (1.2). The problems that have been recognized lead up to the problem definition at
the end of the paragraph. This problem definition led to the research goal and objectives which are stated in
paragraph 1.3. The last paragraph (1.4) defines the research questions which will be answered throughout the
report. The research methodology which will be used to achieve the research goal, and to answer all the
research questions will be discussed in Chapter 2.
1.1
Background
Construction projects are becoming more and more complex and larger in scale due to advance in technology
and operations. At the same time, contractors are under great pressure in a competitive market with respect to
factors such as cost, time-to-market and quality (Tomiyama & Meijer, 2005). This increasing pressure and
complexity of both products and processes made the successful realization of construction projects harder and
harder.
Projects are usually outsourced to several contractors due to the enormous size and the complexity of the
infrastructure projects which all have a part to contribute in the system. Systems Engineering (SE) has been
introduced as an approach to systematically organize these large, complex and multidisciplinary projects.
Within SE, the design procedure consists of decomposing the complex system or project into a set of subsystems, which may be further divided into components. The SE approach for product development will
ultimately decompose the design effort down to a point where individual teams of engineers will have the task
of designing a component, which is a small portion of the overall system that is manageable for the given
development schedule. These individual teams of engineers usually work separately from each other, and have
different backgrounds such as structural, mechanical and electrical engineering (Zummo, 2010).
Unfortunately, most of the components are somehow connected to one another. Interfaces are generally
considered as the links between different construction components, stakeholders and project scopes (Shokri,
Safa, Haas, Maloney and MacGillivray, 2012). Components are clearly defined and understood because they
belong to one small module of the system. However, although each subsystem has a clear definition and it is
supposed to behave as specified, designers can still be surprised by unpredicted problems that deteriorate the
performance of the project as a whole (DAmelio, 2010). The system integration process represents the first
time that fully engineered components and subsystems are linked to one another, and are made to perform as
a unified functional entity. Despite the best plans and efforts, the integration of a system containing newly
developed components is almost certain to reveal unexpected incompatibilities (Kossiakoff, Sweet, Seymour
and Biemer, 2011).
In order to prevent integration issues, all interfaces between the components and sub-systems should be taken
into account in advance. Industry leaders believe that Interface Management (IM) systems improve alignment
between stakeholders and can reduce project issues and conflicts (Shokri, et al. 2012). However, systematically
identifying and managing all interfaces seems to be a continual struggle for owners and contractors. The lack of
IM in projects may results in deficiencies in the project cost, time, and quality aspects, or might even result in
failures after the project had been handed over. Hence, having a sufficient IM program to effectively handle
the interfaces throughout the whole project life cycle is critical to project performance.
Ballast Nedam
2014

2014
1.2
Problem Description
Companies that design complex, highly engineered products all had their failed projects they would rather
forget about. Ford and Bridgestone Firestone lost billions of dollars after their failure to coordinate the vehicle
design of the Ford Explorer with the design of its tires (Sosa, Eppinger and Rowles, 2007). Likewise, the
development of the Airbuss A380 superjumbo suffered major delays and cost overruns because of late
inadequacies in the design of the electrical harnesses of various sections of the planes frame (Sosa, Eppinger
and Rowles, 2007).
In the construction sector similar problems can be recognized. If the interfaces between the components and
subsystems are not properly taken into account, sub-solutions could be derived which do not fully connect to
each other. Consequently, conflicts could occur in the project, leading to unnecessary design iterations, rework
or even failure. Multiple examples exist of projects which have been delayed or have exceeded the budget
because of these integration issues. In fact, up to 20% of total project cost is related to interface management
issues (Nooteboom, 2004).
The Leidsche Rijntunnel A2 and the Roertunnel A73 have been substantial delayed because the complex
technical installations did not match to each other. The technical installations are not installed and coupled
until late in the project. Therefore, functional and physical clashes in the design are not always recognized
before the subsystems are integrated and installed into the project. Clashes identified in this phase of the
project life cycle could easily lead to substantial delays and extra costs. Ir. M. Smitt, director of Strukton Civil,
states that disciplines as Civil Engineering and Electrical Engineering have been separated worlds for a long
time, even on a management level work is not coordinated well (Biesboer, 2010).
L. van Ruijven, Manager technical development at Croon, evaluated the project Sluiskiltunnel. The
Sluiskiltunnel is a tunnel under the canal of Gent. The lesson learned here was that the multidisciplinary design
should have integrated better in regards to the disciplines of Civil and Electra and both these designs were not
fully optimized. It further states that the most important causes of failure costs in projects are the inadequate
exchange of information and communication between the different contractors (van Ruijven, 2007).
Another case is the HSL-Zuid, a 125 km-long high-speed railway line in the Netherlands, which has substantial
integration issues. The project suffered heavily because of the interfaces between the several sub-systems.
Superstructure,transport and sub-systems as the foundation were outsourced to different parties with
different contracts. The project manager had to manage all these interfaces and found himself sandwiched
between the different parties while this was never the intention to do so (Rijsenbrij & van Gelder, 2010).
The Betuweroute, which is a 160 km long freight railway from the Maasvlakte near Rotterdam to the German
border which was completed in 2007 are also known to have similar problems. This project was outsourced in
many regional contracts in order to get the lowest price for each part of the project. However, all these
different parties increased the need for coordination and IM. All sub-systems had to comply to the same
requirements and had to match one another. These issues were heavily underestimated at the early stage of
the project, leading to a substantial delay of the railway (van Klink, et al. 2010).
What notable about these failed projects is that the most expensive mistakes and delays could be traced back
to integration issues between the different design teams. These design teams all succeeded in the
development of the projects components and subsystems within their scope, but did not pay enough attention
to the project as a whole (Sosa, Eppinger and Rowles, 2007). Ballast Nedam acknowledge these problems, and
that the lack of IM between different engineering disciplines leads to unnecessary design iterations and
rework, causing additional costs and a substantial delay of the project.
Ballast Nedam

2014
Problem definition:
The lack of interface management, between several engineering disciplines, during the development of
multidisciplinary infrastructure projects, is causing unnecessary design iterations and rework, ultimately leading
to delays and additional costs.
1.3
Research goal and objectives
In the previous paragraph the problems are described and a problem definition is developed, which form the
motivation for this research. In this paragraph the definitions of the project goal and objectives are formulated,
in order to encounter these problems.
Research goal:
The aim of the research presented is to diminish unnecessary design iterations and rework, in infrastructure
project development, by developing a systematic approach for Interface Management.
Figure 1: Interface management as process to successfully integrate all parts of the project into one integrated system.
Research objectives:
In order to realize the research goal several objectives have been formulated. The goal of this research is to
develop a systematic approach for interface management in order to reduce unnecessary design iterations and
rework. This goal will be reached by the elaboration of three main objectives:
Investigating the main factors causing integration issues

Exploration and evaluation of the current IM processes
Exploration and evaluation of alternative methodologies
This report focuses on the implementation of interface management in point of view of the contractor. A
literature study will be conducted on the design processes in order to get a clear view on the current practices.
The role of interface management in these processes is explored and evaluated through both literature and a
case study. Findings, from both literature and the conducted case study, gain insight in the factors causing
interface issues during infrastructure project development. Evaluation of the current interface management
practices lead to a complete picture of the shortcomings and successes of the applied method. by investigating
literature on interface management related subjects, aspects are explored which could encounter the main
factors causing the integration issues. Additions to the current practices lead to a systematic approach for
Ballast Nedam

2014
interface management, resulting in a reduction of the additional costs and delays due to unnecessary design
iterations and rework. Both the problems highlighted in this thesis, and the proposed solutions aim to
contribute towards a structured and transparent management of interfaces.
1.4
Research questions
The problem description and research model have been used to define the main research question that needs
to be answered for achieving the goal as described in 1.3. In order to support the main question, subquestions have been derived. These sub-questions will be answered throughout the report and will ultimately
lead to an answer on the main question.
1.4.1
Main question
How to improve the interface management practices in infrastructure project development, in order to reduce
unnecessary design iterations and rework?
1.4.2
Sub-questions
In line with the main question several sub questions have been derived. The sub questions will serve as the
basis of the research and will lead, ultimately, to an answer on the main question:
1)
Why is interface management becoming more important nowadays? (3.1.3)
2)
How is interface management proposed in literature on Systems Engineering? (3.3.3)
3)
What interface management related research has been done? (Ch.4)
4)
How is Interface Management implemented in practice? (5.3)

a)
How does the interface management process look like?
b) What tools are used to support Interface Management?

5)
What are the main differences between the engineering disciplines? (5.5)
6)
What are the main factors causing integration issues? (Ch.6)
The mentioned sub-questions will be handled throughout the report. In the next chapter the research
methodology used to answer the research questions is described.
Ballast Nedam

2014
Chapter 2: Research methodology

This chapter discusses the research methodology that will be used to achieve the objectives and research goal
as defined. First, the chapter starts with the research design which will be used to perform the research.
Secondly, the scope of the research is defined in order to narrow the subject for research. Thirdly, the research
approach is discussed (Doorewaard, et al. 2007). As last, a report overview is given in where the content of
each chapter is described.
2.1
Research design
To adequately answer the research questions and reach the objective, a research design is set up. The research
design will consist of four stages which are:
Literature
Research
Results
Conclusions
The literature stage consists of two phases. The first phase (chapter 3) explores literature on construction
design processes, SE and the role of interface and configuration management. This phase gives answers on why
IM is requiring more attention at the moment, and how IM is proposed in the SE literature, leading to answers
on sub-questions 1 and 2. The second phase of the literature stage (chapter 4) examines IM related literature,
leading to an answer on sub-question 3.
The second stage consists of the research phase. A case study is conducted to explore the current IM practices
(sub-question 4). In here, the whole IM process has been examined, including the project organization and
used tools. By evaluating the IM methods the current pitfalls and successes are unveiled. Interviews with
project members of different engineering disciplines lead to a clear picture of the main differences between
these parties (sub-question 5).
The third stage exists of the results. By investigating both literature and findings from the case study, all main
factors causing integration issues are exposed (sub-question 6). At last, coupling the findings from literature
and practice with the current IM processes leads to a systematically approach for IM, which encounter the
main factors leading to integration issues.
In the last stage conclusions and recommendations are given. In here, a summary is conducted which
summarizes the main results and gives an answer on the main research question, and recommendations are
formulated to increase the current practices.
2.2
Research constraints
To execute the research a solution space has to be defined. Without such a space it would be very hard to
define a scope for this thesis. To demarcate the problem, the starting points and constraints have to be
defined.
The surveyed case studies and the thereby linked empirical research will focus on Ballast Nedam
projects and experts;
Ballast Nedam

2014
The research will focus on forms of Design and Construct (DC) projects;
The research will be conducted in a SE environment;
The research will make conclusions based on the data received from projects in where Ballast
Nedam is involved.
The research on system integration will be conducted from the perspective of the contractor.
Therefore, integration issues caused by the client, such as unclear scope packages and conflicting
requirements, are neglected.
2.3
Research approach
According to Doorewaard and Verschuren, five strategies can be recognized in order to approach a research:
survey, experiment, case study, well-founded theoretical approach, and desk research (Doorewaard, et al.,
2007). This report will use both a theoretical approach and a case study. The research starts with a literature
study on the main topics involved. In here, the design processes, SE and IM are widely elaborated.
In order to explore the IM process, as is currently conducted in infrastructure project development, is chosen
to perform a case study. Based on findings in the case study, the IM program can be evaluated, leading to the
main pitfalls and successes within this approach. Furthermore, the main factors causing the integration issues
could be identified which will indicate the direction for progress.
The results from literature and case study combined will assist in the development of a systematically IM
approach. This approach will encounter the factors causing the integration issues as much as possible and will
therefore lead to an answer on the main question. In the last stage, a conclusion and recommendations are
formulated.
2.3.1
Case study selection criteria
As indicated, current IM practices can only be explored in industry. In order to get the input required, a case
study is conducted. However, not every case is suitable to reveal all information needed. Therefore, the case
has to be carefully selected, based on several criteria. For this research, the case has to meet the following
selection criteria:
Involvement:
Since the research is done at Ballast Nedam the involvement of BN as a contractor is required.
Contract:
The project should be based on a Design & Construct (DC) contract or a related form such as Design,
Construct and Maintain (DCM) or Design, Build, Finance and Maintain (DBFM) contracts.
Approach:
The use of Systems Engineering is mandatory for the selection of the case.
Multi-disciplinarity:
In order to investigate the role of, and coordination between, different engineering disciplines the
project should have a strong multidisciplinary character.
Progress:
In order to interview the employees involved in the project, the project should currently be in
progress. In this way it is easier to obtain information and speak to all parties involved.
These selection criteria resulted in The Johan Frisosluis in Stavoren as case study for this research.
Ballast Nedam

2014
Johan Frisosluis Stavoren
Figure 2: Sketch of the Johan Frisosluis te Stavoren (Interra).
Principal:
General contractor:
Other main (sub)contractors involved:
Contract:
Summary:
Provincie Friesland
Ballast Nedam Infra
Machinefabriek Emmen, Croon Elektrotechniek, Royal Haskoning
and Sterk.
Design, Construct and Maintain (DCM)
The capacity of the Johan Frisosluis in Stavoren has to be expanded. The lock is forming a connection between
the Johan Frisokanaal en the Ijsselmeer and is for recreational purposes the most important entrance to De
Friese Meren. The current capacity of the lock is too small to handle all the vessels. Especially in summer
season long waiting times occur at the lock. Therefore Ballast Nedam is contracted to expand the capacity of
the lock for a total contract sum of 15.6 Million Euros.
2.4
Report overview
An overview of the report is given to give a clear view of what is handled in each of the chapters. The report
consist of 8 chapters, and are assigned as follows:
Chapter 1: Introduction
This chapter gives an introduction to the subject, as well as an extensive description of the main problems,
leading to the problem definition. In addition, the project goal, objectives and research questions are defined in
this part of the report.
Chapter 2: Research methodology
Chapter 2 starts with the research design, which explains the four stages which this research consists of and
indicates where the sub-questions will be answered throughout the report. In addition, the research approach
and constraints are described.
Ballast Nedam

2014
Chapter 3: Literature study
Within the chapter literature study, two main subjects are examined and described.
In here the literature on traditional and integration building industry as well as SE is examined and described.
Especially the role of interface and configuration management within SE is widely explored.
Chapter 4: IM related research
In chapter 4 IM related research is explored and evaluated. In here techniques are discussed to diminish design
iterations and prevent integration issues.
Chapter 5: Practical analysis
Chapter 5 Practical analysis consists of a case study. In this chapter the current IM practices are examined and
described. Furthermore, findings from interviews reveal the main differences between the engineering
disciplines and expose the most important factors leading to integration issues.
Chapter 6: Factors leading to integration issues
In chapter 6 all factors causing integration issues are subtracted from literature to verify the findings from the
case study. These results are compared and compressed into two main categories.
Chapter 7: IM framework
In chapter 7 a systematically approach for IM is proposed. In here the whole IM process is described in five
main steps which are interface identification, documentation, communication, control and closeout. In
addition, several pre-conditions are mentioned which have to be fulfilled to make the proposed IM process a
success.
Chapter 8: Conclusions and recommendations
As last, conclusions and recommendations are provided in chapter 8, as well as potential subjects for further
research.
Ballast Nedam

2014
Chapter 3: Literature Study

In this chapter a literature study is conducted. in paragraph 3.1 the traditional building industry, and the
current shift towards an integrated building industry, is described. Afterwards, the methodology of Systems
Engineering (SE) is explained (3.2). Paragraph 3.3 introduces the subject of Interface Management (IM), in
where clear definitions are given regarding interfaces and interface management, and the role and practical
guidelines of IM within the SE literature is described and explored. As last, Configuration Management (CM)
has been introduced and described in paragraph 3.4. As last, a conclusion is given, including a summary of the
chapter (3.5).
3.1
From traditional to integrated contracting
Currently a shift is occurring in the construction market. Where phases as design and construction were used to
be totally different and separated worlds, outsourced to different parties, now both worlds start to intermingle
(Anumba, et al. 2007). In this section the main differences and similarities between the traditional building
industry (3.1.1) and the integrated building industry (3.1.2) are evaluated. A comparison is given in
paragraph 3.1.3 in order to give a clear view of why the role of Interface Management is getting more
important in the construction industry nowadays (sub-question 1).
3.1.1
Traditional building Industry
Historically, a construction project could be divided into three main parties which are the client, the designer
and the constructor. Each of them would have their own tasks and responsibilities for their part of the process.
The life cycle of a project could be divided into several phases. These phases of the process are the initiative,
design, construction, operation and maintenance and as last demolition and recycling phase. These phases
were separated and succeeded one another, see Figure 3.
Figure 3: Project Life-cycle phases (Anumba, et al. 2007).
Traditionally, the client takes care of the initiative. In this phase the value of a project to realize is indentified.
Projects in the civil engineering sector usually have a broad social interest and serve a political goal. The client
develops the initiative in where the technical knowledge of the client determines the level of detail. This
initiative will be completed by a design orientated firm, usually an engineering firm. This engineering firm
develops a execution plan described in a specification. At the end of the design phase the specification will be
put on the market, where construction firms can subscribe. The firm which meets the criteria the best, usually
the one who bids the lowest price, will be chosen to build the construction project. This is the most common
way the civil engineering sector was used to work (Doornbos, 2005).
Looking at the building industry the design phase would usually consists of an architect, structural and services
engineers, see Figure 4 (Anumba, et al. 2007). The different phases of the design would be executed step for
step, and adjustment were made where necessary. Looking at Figure 4, based on the client brief, the architect
produces an architectural design, which is given to the structural engineer. The structural engineer would,
when finished, pass his design on to the services engineers, who on their turn make their design based on the
input given. Whenever modifications are needed, the design will go back one step. When the design is finished
Ballast Nedam

2014
the design will be put on the market after which a contractor will take responsibility for the construction of the
facility.
Figure 4: Traditional building process (Anumba, et al. 2007).
As can be seen in the figure, the structural engineers are separated from the services engineers. Due to the
successive contributions of the members of the design team, the traditional design process has a mainly linear
structure. There is a limited possibility of optimization during the traditional design process, while optimization
in the later stages of the process is often troublesome or even impossible. The services engineers, like
mechanical and electrical engineers, have to adjust their design to the structural design.
The process illustrated in Figure 4 appears to be quick and simple, but the lack of coordination often results in
high operating costs and sub-optimal solutions. Since the conventional design process usually does not involve
computer simulations of predicted energy performance, the resulting poor performance and high operating
costs will most often come as a surprise to the owners, operators or users. The introduction of highperformance systems late in the design process cannot overcome the handicaps imposed by initial
incompatible or otherwise poor design decisions (Larsson, 2004). The key disadvantages prevalent with this
sequential approach include (Anumba, et al. 2007):
The fragmentation of the different participants in the construction project, leading to misperceptions
and misunderstandings;
The fragmentation of design and construction data, leading to design clashes, omissions and errors;
The occurrence of costly design changes and unnecessary liability claims, occurring as a result of the
above;
The lack of true life-cycle analysis of the project, leading to an inability to maintain a competitive edge
in a changing marketplace;
Lack of communication of design rationale and intent, leading to design confusion and wasted effort.
10
Ballast Nedam

2014
Delivery processes that are fragmented, hierarchical and adversarial stand in the way of sustainability and
efficiency. Instead more integrated and collaborative approaches are required, in which specialists with
detailed knowledge of the installation, operation and performance of essential components and systems are
brought in at the early stages as part of an integrated delivery process (Specialist Engineering Alliance, 2009).
3.1.2
Integrated building industry
The market is currently shifting from the traditional ways of contracting, in where the contractor was only
responsible for construction, towards Private-Pubic-Partnerships. Jean-Paul Schaij, director of PPSsupport,
claims that the Dutch government saved about 15% on costs so far on projects which were outsourced with
these integrated contracts. According to Schaij the question is no longer if the government should make use of
integrated contracts, but rather how much responsibility should be transferred to the market (Jager, 2013). Not
only the design and construct phases could be outsourced but also aspects like Finance, Maintenance and
Operation. Recently innovative contract forms have been developed to shifts these risks away from the client.
Most common contracts are Design and Construct contracts (D&C-contract) or forms of that like DCM (Design,
Construct and Maintain) and DBFM (Design, Construct, Finance and Maintain) contracts (Jager, 2013).
Evaluation of projects realized with integrated contract forms showed many advantages. According to Jager
(2013) integrated contracts lead to:
An optimal use of knowledge from the market.

Less extra work for the contractor.
Projects which function better, for a lower price.
Sustainable solutions.
One of the biggest differences compared to the traditional building process is that the contractor is responsible
for both the design and construct activities, see Figure 5. By doing this, the client makes use of the knowledge
and expertise available on the market, and offers more flexibility to the contractors. In an integrated design
process various parties work together to a common goal from the early start. The skills and experience of all
specialty engineers can be integrated from the start which leads to more flexibility and more creative and
functional solutions (Anumba, et al. 2007).
Figure 5: Traditional Approach versus Early Contractor Involvement (De Witt, et al. 2005).
In the traditional approach the client spent a lot of time in the design phase. Because the design activities were
fragmented and succeeded each other, many iterations had to be done after each other leading to long lead
times. When a satisfactory design was accomplished, the design was transferred to a contractor who then only
had to execute the project within a certain time frame.
11
Ballast Nedam

2014
With the introduction of integrated contracts the contractor is responsible for both the design and construction
activities of the project. The contractor has to meet functional requirements by a given deadline in time. The
given deadline in time by the client and the concurrency on the market are the main reasons that the design
and construct activities have to be finished in a much shorter time frame than usual.
In order to compress the total lead time of the project, activities in the design and construction phase that
were once distinct and sequential, are now intermingled or overlapped.
Figure 6: Traditional versus Flexible model for product development (Iansiti , 1995).
As can be seen in Figure 6 is already started with the construction activities (implementation) while the design
is not for hundred percent finished yet (concept development). Unfortunately, the activities in the process
interact by a back and forth exchange of information. Overlapping the activities therefore, results in even more
interactions and a greater need for coordination (Verganti, 1997). In short one could say that overlapping of
activities typically introduces a higher level of uncertainty into the process that could cause additional rework,
and thus higher costs (Roemer, et al. 1999). To prevent extra iterations due to the overlapping of activities the
coordination and information flow between the engineering disciplines should be sufficient, since the
organization of these aspects have an huge impact on process efficiency and predictability (Eppinger, 1994).
3.1.3
Comparison between the traditional and integrated building industry
In the previous paragraphs the main aspects of the traditional and integrated building industry are explored.
New forms of contracting led to a shift of responsibilities in the construction market. By comparing these
traditional and integrated forms of contracts, the answer on the first sub-question can be given.
SQ:
Why is Interface Management becoming more important nowadays?
As mentioned in the introduction, the increasing size of projects and the advances in technology and
operations are a major cause for the amount of interfaces to grow in size as well as in complexity. In addition,
these projects involve many stakeholders and contractors, with different geographical locations and working
cultures. Furthermore, These contractors are under great pressure in a competitive market with respect to cost
and time-to-market (Tomiyama & Meijer, 2005).
However, the biggest reason why contractors should pay more attention now to IM is the new way of
contracting. Contractors are not only responsible for construction, but also for the design of the project.
Especially the overlapping of design and construction activities increased the importance of IM. In the
traditional way of contracting the whole design was a sequential process which took the time which was
needed. After the design was finished, a contractor would start with construction. Nowadays, with the great
pressure on cost and time-to-market design and construction activities start to overlap. This is not without any
risk. When the interfaces are not taken care of, and components which are already under construction
suddenly need to change, huge delays and additional costs could occur.
12
Ballast Nedam

2014
The use of integrated contracts asks for new approaches and processes for all parties. It is clear that the
compression and overlapping of the design and construction activities asks for better coordination between the
involved disciplines. Proper IM between all disciplines is necessary in order to come to a sufficient design.
Systems are designed to connect, both within the system under construction and to systems that are already
deployed. Unfortunately, in practice it seems that sub-systems and components are not aligned as much as
they should be (Anumba, et al. 2007).
In order to organize the processes of design and construct projects, like large infrastructure projects, SE has
been introduced. SE is a method to organize complex projects and has become a much used standard in the
construction industry. Because most design and construct projects in The Netherlands are currently working
with SE, the IM practices will be evaluated within this environment for this research. In the next chapter SE is
covered in order to get a better understanding of the current practices.
3.2
Systems Engineering
As mentioned in the previous chapter, SE is an approach currently used for the realization of D&C projects in
the construction industry. In this chapter the basis of the SE methodology is explained, including all main
processes within. This is done to get a clear view of how the projects are generally organized. Afterwards, in
paragraph 3.3 and 3.4 the role of interface and configuration management within the SE literature is explored
and practical guidelines are evaluated.
3.2.1
What is Systems Engineering?
System Engineering is an approach to systematically organize complex projects and has been introduced
especially for D&C projects in construction. After the use of SE in the telecommunication industry and other
sectors, SE has become a much used standard in the construction sector (Rijkswaterstaat, 2009). According to
The International Council on Systems Engineering (INCOSE) SE can be defined as:
An interdisciplinary approach and means to enable the realization of successful systems. Systems engineering
considers both the business and the technical needs of all customers with the goal of providing a quality product
that meets the user needs.
It is an interdisciplinary approach which contributes to develop and realize successful systems. With SE not only
the technical requirements are met but it also strives to meet all the interests of involved stakeholders
(Rijkswaterstaat, 2009).
For the implementation of System Engineering in the construction sector the NEN-ISO/IEC 15288 Systems and
software engineering - System lifecycle processes, 2008 is often used as guidance. Out of this standard more
standards have been developed for the implementation of SE in the civil engineering industry. Examples of
these guidelines are INCOSEs Handbook Systems Engineering Handbook, a guide for system life cycle
processes and activities and in the Dutch construction sector the Leidraad voor Systems Engineering binnen
de GWW-sector developed by Rijkswaterstaat and Prorail and SE-Wijzer Handleiding Systems Engineering
voor BAM Infra developed by the Koninklijke BAM groep.
The most common model used in these handbooks is the V-model in which the processes of system
engineering are explained step by step, see Figure 7. The emphasis of the V-model is on the relation between
the integration, verification and validation of the system (right part of the V-model) and the requirements and
design of the system (left part of the V-model).
13
Ballast Nedam

2014
Figure 7: V-model (Stevens & Brook, 1998).
The left path of the V-model represents the requirement analysis and the design phases and the right path
represents the integration phases. To each design phase corresponds a verification phase. For instance, the
design of components is verified by the components test, the subsystem design is verified by the subsystem
test and so forth. The left path of the diagram includes decomposition of requirements and creation of system
specifications in a design. Those processes (decomposition and creation) are achieved by breaking up a system
in subsystems in order to reduce its complexity, and to allow several design teams to work independently. For
this purpose, the left branch of the diagram describes decomposition where each design level gives more
functional and architectural details than the previous one. The right path of the V-diagram corresponds to
integration and verification, which is the construction phase where components are merged together into subsystems and ultimately, into the final system.
Left side v-model
The client formulates a list of functional requirements and puts the request out on the market. The contractor,
who is responsible for both the design and construction phase, has to come up with a design which complies
with these requirements. In order to prove that the requirements are met, a verification plan has to be formed
and executed during the process development. The design process consists of different stages, before the
tender a conceptual design is realized in where the broad design is displayed. When the client rewards the
project to the contractor, the conceptual design will be further detailed into a preliminary design and
ultimately a detailed design. Each phase consists of more detailed drawings of the project.
14
Ballast Nedam

2014
Figure 8: System Breakdown Structure
Decomposition
Within systems engineering, the design procedure consists of decomposing the complex system into a set of
sub-systems, which may be further divided into components. The systems engineering approach for product
development will ultimately decompose the design effort down to a point where individual teams of engineers
will have the task of designing a component, which is a small portion of the overall system that is manageable
for the given development schedule. These individual teams of engineering have different backgrounds such as
structural, mechanical and electrical and usually work separately from each other (Zummo, 2010).
The decomposition is usually done with a System Breakdown Structure (SBS), see Figure 8. The SBS is a tree of
components which form sub-systems and eventually the system. Every layer of the tree consists of more
details. By decomposing a system, components are formed which are easier to manage and could be designed
by one design team. These components increase the overview of the project. Usually two types of divisions, or
a combination of these, are used for the decomposition. One of these divisions is geographically, in which the
system is split up in sub-systems based on physical areas and locations. This approach is used to increase the
visibility and coherence of the system. The other way of breaking down is by dividing the system into parts
based on the engineering disciplines. In this way it is easy to assign the several design teams to their part of the
job. However, the risk of this classification is that the coherence of the system gets too little attention leading
to interface problems (BAM, 2008). The classification and the level of detail of the SBS, largely determines the
amount and type of internal interfaces which the project has to deal with. Since the complexity of a system is
related to the pattern of the relationships between the components, the classification of this SBS should not be
underestimated.
All components in the SBS have a specific ID number and will deliver a design document (i.e. drawings) ready
for construction. The more components there are, the more formal documents have to be developed and the
more interfaces exist between the components. On the other hand, if the sub-system is not decomposed
enough components derive which are disorderly and hard to allocate to an individual team of engineers. A
balance has to be found in here. The SBS is purely used to split the project in manageable parts of which the
scope is clear and to make sure that nothing will be left out of the project.
All components derived in the SBS make part of the final system and can be designed by individual design
teams. However, these components also have to complement each other to form the total system. As said,
15
Ballast Nedam

2014
most components have some kind of relationship or interface with each other. These interfaces have to be
recognized and taken care off as soon as possible in order to integrate the designs successfully.
Right side v-model
Next to the SBS, a Work Breakdown Structure (WBS) will be developed, which is derived from the SBS. This
WBS is a scheme of all work packages which has to be executed in order to construct the project. The WBS
shows the hierarchy of all work packages. Each work package is a package of related activities on behalf of an
object with a defined input and output. By using these work packages a connection is created between
content, time and money. By executing these work packages, components and sub-systems are integrated into
the final system. That is why this right side of the V-model is also defined as System Integration.
System Integration is the term used for the integration of all components and sub-systems in the construction
phase leading to the final system. The system integration process represents the first time that fully engineered
components and subsystems are linked to one another to perform as a unified functional entity, see Figure 9.
However, despite the best plans and efforts, the integration of a system containing newly developed elements
is almost certain to reveal unexpected incompatibilities (Kossiakoff, et al. 2011). It is even said that the iterative
aspect of design and the associated rework is fundamental to any complex system (Browning, 1998).
Figure 9: System Integration (Eppinger, 1997)
Integration consists of linking components and sub-systems together which could expose faults at their
interfaces. Failures in high levels of the right path of the V-model strongly delays the product development
process. Problems at the system level are hard to solve because they involve the entire system and,
consequently, it is a multidisciplinary problem that is linked to the conceptual design phase. These problems
can be of physical nature as well as of functional nature. To solve these problems the design often has to be
(partly) adapted. These unexpected incompatibilities show the importance of an early detection of possible
design failures to avoid these time consuming iterations.
3.3
Introduction of Interface Management
The new forms of contracting and the attached pressure on the time to market, makes the management of
interfaces more important than ever. When the interfaces in a project are not managed well, huge problems
could occur leading to delays and additional costs. Unfortunately, it seems that the impact of IM is often
underestimated in construction projects (Nooteboom, 2004). In the first part of this chapter the definitions of
an interface and IM are defined, and different types of interfaces are described. In paragraph 3.3.3 the role of
IM within the SE literature is explored and described.
3.3.1
Interface definition
Most interfaces arise during the decomposition of a project into different contracts, sub-systems and
components. At the moment, no consensus is made about the precise definition of these interfaces. Many
definitions of interfaces exist in the construction sector, which could cause a lot of confusion. Therefore, for
this research is chosen to use the following definition for interfaces:
16
Ballast Nedam

2014
Interfaces are places where a system or component affects the environment or another component (physically
and functionally) and vice versa (BAM, 2008)
These interfaces are the relations which exist within the system to realize and with the surrounding
environment. A distinction can be made between internal and external interfaces. Interfaces which exist
between the components and sub-systems within a system are called internal interfaces. The interfaces a
system has with other systems or the surrounding environment, which are out of the scope of the project, are
called external interfaces. An example of an external interface would be, for instance, the realization of a new
road which has to be connected to an already existing road. For an impression see Figure 10.
Figure 10: Schematization of internal and external interfaces (BAM, 2008).
The interfaces can be further divided into functional and physical interfaces. The functional interfaces are
derived from the functional requirements. For instance, it could be stated by the client that a bridge should be
able to open at least ten times an hour. This requirement gives an functional interface between the mechanical
design of the motor and the structural design of the bridge. The type of machine and bridge, the dimensions
and mass, all have impact on this interface. Therefore close coordination between the involved design teams is
necessary in order to meet that requirement.
Physical interfaces are places were two objects are literally physical related to each other. A physical interface
could be, for instance, a bridge which has to connect to the adjacent road. If the bridge is too long the bridge
will not fit, while if the bridge is too small a gab will arise between the road and the bridge. This is an example
of a simple and logical interface, but these objects have to be adjusted to each other in order to come up with
an integrated design.
A third distinction can be made looking at the different contractors. The interfaces between components falling
under one contractor, usually one engineering discipline, are called intra-disciplinary interfaces. The interfaces
between components, designed by different organizations, are called inter-disciplinary interfaces. See Figure 11
for an impression.
17
Ballast Nedam

2014
Figure 11: Intra-disciplinary versus Inter-disciplinary interfaces (Shokri, et al. 2012).
3.3.2
Interface Management definition
Unfortunately, IM has been a hidden aspect of project management for a long time (Nooteboom, 2004).
According to Chen, et al. (2007), the term IM contains the improvement of quality of physical connections
between construction components, the reduction of project conflicts among project participants through
planning and close coordination, and the optimization of design in terms of quality, compatibility,
constructability, cost and risk. Shokri, et al. (2012) considers IM as the process of managing communications,
responsibilities and coordination of project parties, phases, or physical entities which are interdependent.
By performing IM, a deep understanding of project complexity for all project participants will be developed,
and can therefore improve project planning by avoiding, minimizing, or eliminating potentials for interface
issues in advance (Chen, et al. 2007). IM is an ongoing process and should be considered dynamic throughout
the life cycle of the project, with the goal of maintaining the balance between scope, time, cost and quality
(Crumrine et al, 2005). The reason is that as a system grows or changes, its interfaces change as well. New
relationships will be established and new interfaces will be generated (Wren, 1967).
Currently, it is not widely known what IM means in construction and what scope is covered by IM. Only
recently an increased awareness of IM as missing link in the construction industry has been developed (Chen,
2007). Lately, several researchers defined their own definitions for IM. In order to prevent confusion about the
scope of IM one definition has been chosen for this research. Kossiakoff et al. (2011) defined a bilateral
definition for IM in the construction industry:
1.
2.
The identification and description of interfaces as part of system concept definition and
The coordination and control of interfaces to maintain system integrity during engineering
development, construction, and subsequent system enhancements.
In line with this definition, four main steps can be identified for an basic IM approach:
1.
2.
3.
4.
Identification of the interfaces

Description of the interfaces
Coordination of the interfaces
Control of the interfaces
18
Ballast Nedam

2014
In short, IM contains the identification, description, coordination and control of all interfaces during the whole
life cycle of the project.
3.3.3
Interface Management in SE literature
According to Kossiakoff et al. (2011) is the management of interfaces a major theme within SE. However, IM
literature in SE is scarce. The International Council on Systems Engineering (INCOSE), for instance, only
mentions to take into account the interfaces in the integration process, but describes no practical applications
or guidelines for IM. In this section of the report, several SE guidelines which do contain IM are described and
evaluated.
NASA developed the Systems Engineering Handbook in 2007 which contain IM practices. In order to focus on
IM in infrastructure projects, also SE guidelines for the construction industry are evaluated. In the Dutch Civil
Engineering industry two practical guidelines for SE have been developed, which do discuss the role of IM.
These guidelines, Leidraad voor Systems Engineering binnen de GWW-sector and SE-Wijzer Handleiding
Systems Engineering voor BAM Infra are developed by respectively Rijkswaterstaat and Prorail, and the
Koninklijke BAM groep. These SE guidelines are evaluated in order to get a clear view on how IM is proposed in
SE, and in particular the Dutch Civil Engineering industry. By exploring the SE literature on IM, the second subquestion will be answered throughout this section.
SQ:
How is interface management proposed in literature on Systems Engineering?
Systems Engineering Handbook

NASA (2007) states that management and control of interfaces is crucial to successful projects. The objective of
IM is to achieve functional and physical compatibility among all interrelated system elements. An interface is
any boundary between one area and another which could occur within the system (internal) or between the
system and another system (external). These interfaces may be functional or physical (e.g., mechanical,
electrical) in nature.
Ensuring that all system pieces work together is a complex task that involves teams, stakeholders, contractors,
and project management from the end of the initial concept definition stage, through the operations and
support stage. The IM tasks begin early in the development effort, when interface requirements can be
influenced by all engineering disciplines and applicable interface standards can be invoked. They continue
through design and checkout. During design, emphasis is on ensuring that interface specifications are
documented and communicated. During system element checkout emphasis is on verifying the implemented
interfaces. In verifying the interfaces, the systems engineer must ensure that the interfaces of each element of
the system or subsystem are controlled and known to the developers.
Throughout the product integration process activities, interface baselines are controlled to ensure that changes
in the design of system elements have minimal impact on other elements with which they interface. The
changes must be evaluated for possible impact on other interfacing elements and then communicated to the
affected developers. Although all affected developers are part of the group that makes changes, such changes
need to be captured in a readily accessible place so that the current state of the interfaces can be known to all.
Process description
NASA developed a flow diagram for the Interface Management Process and identified typical inputs, outputs,
and activities to consider in addressing interface management.
19
Ballast Nedam

2014
Figure 12: Interface Management Process (NASA, 2007).
Input:
Typical inputs needed to understand and address interface management would include the following:
System Description:
System Boundaries:
Organizational Structure:
Boards Structure:
Interface Requirements:
Interface Change Requests:
Allows the design of the system to be explored and examined to determine

where system interfaces exist.
Document physical boundaries, components and subsystems, which are all
drivers for determining where interfaces exist.
Decide which organization will dictate interfaces, particularly when there is
the need to jointly agree on shared interface parameters of a system. The
program and project WBS will also provide interface boundaries.
The Systems Engineering Management Plan (SEMP) should provide insight
into organizational interface responsibilities and drive out interface
locations.
Document the internal and external functional and physical interface
requirements.
These include changes resulting from program or project agreements or
changes on the part of the technical team.
Process Activities
During project formulation, the concept of operations of the product is analyzed to identify both external and
internal interfaces. The concept of operations is a document describing the characteristics of a proposed
system from the viewpoint of the user and is used to communicate the quantitative and qualitative system
characteristics to all stakeholders. This analysis will establish the origin, destination and special characteristics
of the interfaces that need to be documented and maintained.
As the system structure and architecture emerges, interfaces are added and existing interfaces could change,
and must be maintained. Thus, the IM process has a close relationship to other areas, such as requirements
definition and configuration management during this period. Typically, an Interface Working Group (IWG)
establishes communication links between those responsible for interfacing systems, end products, enabling
products, and subsystems. The IWG has the responsibility to ensure accomplishment of the planning,
20
Ballast Nedam

2014
scheduling, and execution of all interface activities. An IWG is typically a technical team with appropriate
technical membership from the interfacing parties.
During product integration, IM activities would support the review of integration and assembly procedures to
ensure interfaces are properly marked, and compatible with specifications and interface control documents.
The IM process has a close relationship to the verification and validation activities.
Outputs
Output to capture IM includes interface control documentation. This is the documentation that identifies and
captures the interface information and the approved interface change requests. Interface requirements are
documented in an Interface Requirements Document (IRD). Care should be taken to define interface
requirements and to avoid specifying design solutions when creating the IRD. In its final form, the Interface
Control Document (ICD) describes the detailed implementation of the requirements contained in the IRD. An
interface control plan (ICP) describes the management process for IRDs and ICDs. This plan provides the means
to identify and resolve interface incompatibilities and to determine the impact of interface design changes.
These outputs will then be maintained and approved using the Configuration Management process and
become a part of the overall technical data package for the project.
Interface Requirements Document (IRD)
An interface requirement defines the functional, performance, electrical, environmental, human, and physical
requirements and constraints that exist at a common boundary between two or more functions, system
elements, configuration items, or systems. The IRD is a document that collects all of these interface
requirements. The purpose of the IRD is to control the interfaces between interrelated components of the
system under development, as well as between the system under development and any external systems.
Interface requirements may be contained in the Systems Requirement Document until the point in the
development process where the individual interfaces are determined. IRDs are useful when separate
organizations are developing components of the system, or when the system must levy requirements on other
systems outside project control. During conceptual and preliminary design multiple IRDs are drafted for
different levels of interfaces.
Interface Control Document (ICD)
An interface control document or drawing details the physical interface between two system elements,
including the number and types of connectors, electrical parameters, mechanical properties, and
environmental constraints. In this document the design solution to the interface requirement is widely
described. ICDs are useful when separate organizations are developing design solutions, attached to each other
through a particular interface.
Interface Definition Document (IDD)
An IDD is a unilateral document controlled by the end item provider, and it basically provides the details of the
interface for a design solution that is already established. This document is sometimes referred to as a onesided ICD. The user of the IDD is provided connectors, electrical parameters, mechanical properties,
environmental constraints, etc., of the existing design. The user must then design the interface of the system to
be compatible with the already existing design interface.
21
Ballast Nedam

2014
Interface Control Plan (ICP)
An ICP should be developed to address the process for controlling identified interfaces and the related
interface documentation. Key content for the ICP is the list of interfaces by category and who owns the
interface. The ICP should also address configuration control to implement the change process for the
documents.
Leidraad voor Systems Engineering binnen de GWW-sector
Prorail and Rijkswaterstaat (2009) state that due to the high amount of internal and external interfaces, and
the fact that information must be transferred between parties and between phases in the construction
process, the communication and coordination of the available information is essential to prevent errors, and
thus prevent failure costs. In the guide interfaces are defined as both the functional and physical characteristics
which exist in order to let the system function as a whole. In here, a distinction is made in internal and external
interfaces.
According to the guide all internal and external interfaces should be listed in the requirements. The
requirement analysis will provide an overview of all, known at that time, requirements and interfaces. These
requirements, interfaces and optionally other information will be coupled to the objects in the project, which
form the basis for the design. The management of these interface requirements is very important. The
structured recording of this data ensures that the right information is available at the right time.
Tree structures are used as tools to help manage the complexity of systems. They provide a clear overview of
the system and the relations between the components. These tree structures are the Functional Breakdown
Structure (FBS), Requirements Breakdown Structure (RBS), System Breakdown Structure (SBS) and Work
Breakdown Structure (WBS). Next to these trees a Specification Tree could be developed, in where all
requirements, preconditions and interface requirements will be grouped by component and sub-system. The
specification tree shows the relationship between the specifications, structured to the different levels of detail,
as can be seen in Figure 13.
Figure 13: Relation between the Specification Tree and the System Breakdown Structure (Prorail and Rijkswaterstaat, 2009).
22
Ballast Nedam

2014
SE-Wijzer Handleiding Systems Engineering voor BAM Infra
According to this guide interfaces are places where a system or component affects the environment or another
component and vice versa. Interactions between a system and its environment are called external interfaces,
while interactions between objects within a system are called internal interfaces (BAM, 2008).
According to the guide the first step of interface management is the identification of these interfaces. These
interfaces have to be taken into account, while making choices about the design and construction
methodology. Thereafter, throughout the whole process up to the completion, interfaces should be monitored
closely. As the number of objects increases, the number of interfaces will increase as well. A practical tool
mentioned to monitor interfaces is 3D design, which reveal clashes between parts of a design much easier.
Another tool mentioned in order to get insight into the amount of interfaces and the most critical interfaces, is
the critical interface analysis or N-chart-analysis. These techniques will be addressed in more detail in chapter
4.
The guideline states that in order to manage and control the interfaces, for each of these interfaces an
Interface Control Document (ICD) has to compiled. In this document the attached interface requirements,
objects and agreements about the responsibility of this interface are stated. An example of such a document
can be seen in Appendix A. The interface requirements will also be added to the requirements management
system. The interface management process proceeds as following (BAM, 2008):
1.
Interfaces are identified during design and construction coordination meetings, or at the start of the
project in a separate interface identification meeting.
2.
For each interface a interface owner will be identified. This owner can be held responsible for the
timely coordination of the interface and has to write down the agreements made, related to that
interface, in the Interface Control Document.
3.
Coordination measures, which are agreed upon in order to settle a specific interface, will be included
as requirements in the Requirements Breakdown Structure.
4.
In the design coordination and construction meetings, the status of the interfaces will be regularly
discussed.
Figure 14: Interface Management Processes (BAM, 2008).
23
Ballast Nedam

2014
The process of IM is schematically shown in Figure 14. In here, a clear distinction is made between interdisciplinary and intra-disciplinary interfaces. The intra-disciplinary interfaces have to be settled within the
disciplines and do not require any coordination of the other disciplines. As already mentioned in the previous
chapters, contractors often coordinate their own IM issues well. It are the interfaces which cut across delivery
teams that cause the most issues. Therefore, for each inter-disciplinary interface, ICDs have to be developed in
order to write down the agreements between the involved contractors around that specific interface.
3.4
Introduction of Configuration Management
Another process within Systems Engineering is Configuration Management (CM). CM is an essential project
management tool which is suited for controlling changes during the design and construction phases of large
infrastructure projects (Kossiakoff, et al. 2011). The NASA Systems Engineering handbook defines CM as a
management discipline, which is applied over the products life cycle, to provide visibility into, and control to,
changes to performance and functional and physical characteristics. It ensures that the configuration of a
product is known and reflected in product information, that any product change is beneficial and is effected
without adverse consequences, and that changes are managed. The primary purpose of CM is maintaining
consistency in the constructed entitys functional and physical configuration, and to produce a product with the
desired specifications, design and functions (Admiari, 2010).
3.4.1
Process Description
Figure 15 provides a typical flow diagram for the Configuration Management Process and identifies typical
inputs, outputs, and activities to consider in addressing CM. The main aspects of CM can be divided into
document, baseline and change management.
Figure 15: Configuration Management process (NASA, 2007).
24
Ballast Nedam

2014
Document Management
CM enables all stakeholders, at any given time in the life of a product, to use identical data for development
activities and decision making. CM principles are applied to keep the documentation consistent with the
approved engineering, and to ensure that the product conforms to the functional and physical requirements of
the approved design (NASA, 2007). Under the principle of CM, all documents generated within a project are
closely managed, tracked, and archived. The process includes tracking and archiving all document changes,
versions, and approved communications, which is necessary to avoid the inclusion of document changes
without following a formal document approval process (PACO, 2010).
Baseline Management
In order to control the design so called baselines are used. The CM process defines multiple milestones in
advance, for each subsystem. These milestones in design have to be achieved after which the design will be
frozen. Next to these pre-determined milestones, the status of design may be frozen at any point in time
during project development. These (frozen) moments are called baselines.
CM gives insight in the differences in level of development between the several sub-systems, and what
consequences these differences have. In order to identify the consequences of one sub-system progressing
faster than another, all interfaces between the sub-systems should be known. When one sub-system proceeds
to the detailed design phase while another sub-system is still at conceptual design, huge problems could occur
if their interfaces are not worked out well.
Baseline management involves the capture and archive of the exact state of a project during key points of the
project lifecycle. Change to the project baselines requires a formalize approval process identifying the reason
for the change, its intended impacts, justification, and approval. Every version of every document is archived,
and the relationship between documents is captured.
Change Management
Changes are and will continue to be an inevitable part of the design and construction of any project. Even the
best set of design plans and detailed contract specifications are no guarantee that a particular project will not
experience numerous changes. This is particularly true when the scope involves a large-scale, multi-contract,
multi-phased complex project (INCOSE, 1998). Figure 16 indicates the usual change of requirements during
project development.
Change management is the process of approving (or denying) changes and is part of the CM process. Systems
engineers ensure that the change is necessary, and that the most cost-effective recommendation has been
proposed. It is important to consider both the consequences of a change, as well as the impact of not making
the change, especially as the system matures. Changes made later in the life cycle have an increasing risk of
hidden impacts which can adversely affect system cost, schedule, and technical performance.
25
Ballast Nedam

2014
.
Figure 16: Requirements changes are inevitable (NASA, 2007).
Therefore, the effort and cost associated with accommodating changes increases rapidly as the design matures.
By the time the system design is formulated in detail during the engineering design phase, the search for
opportunities for further enhancement can no longer be sustained. Accordingly, the system design is frozen,
and formal change control procedures are imposed to deal with necessary modifications, such as those
required by incompatibilities, external changes, or unexpected design deficiencies. Configuration control
maintains integrity by facilitating approved changes and preventing the incorporation of unapproved changes
into the items under configuration control.
Summary
The most important aspect a CM process should entail are:
26
A documented Configuration Management Plan (CMP);

Pre-determined milestones for each sub-system;
Insight in the differences in level of development between the several sub-systems, and the
involved consequences of these differences;
Ability to freeze the design at any given point in time;
Clear procedures for change management;
Clear procedures for deviations.
Ballast Nedam

2014
3.5
Introduction to Risk Management
Another process within Systems Engineering is Risk Management (RM). RM is an essential project management
tool to deal with all risks within the project. Risks are defined as events which could lead to delays, additional
costs or a decrease in quality. The goal of RM is achieving the projects objectives by identifying all
uncertainties within the project, at an early phase, and taking measures to monitor and control these risks
(BAM, 2008). Suddle (2004) schematized the risk management process, as can be seen in the figure below.
Figure 17: Part of risk assessment process (Suddle, 2004).
It is advised to appoint a risk manager in the project who gathers all input related to risks from all involved
disciplines, and documents this information in a risk register. The submission of risks is the responsibility of all
involved team members. The risk register is a systematic document in where all risks, and their relation to the
FBS, SBS, WBS and OBS, are specified.
Multiple methods exist to assist in the RM process. A much used method in infrastructure project development
is the RISMAN method (Prorail and Rijkswaterstaat, 2009). The RISMAN methodology takes into account seven
perspectives to come to a complete picture of all risks. These perspectives are political/administrative,
financial/economic, legal, technical, organizational, geographical and social. Of each risk is captured what the
undesirable events are, what the likelihood is of occurrence, the consequences of the event in terms of costs,
time and quality, prevention measures, mitigation strategies, roles and responsibilities and as last, its relation
to the requirements.
27
Ballast Nedam

2014
3.6
Conclusion
Under the chapter literature, the design processes and SE are explored to answer the first two sub-questions.
In line with sub-question one, it becomes clear that IM not only requires more attention nowadays because of
the increasing size and complexity of infrastructure projects, as well as the resulting increase in the amount of
parties involved. The main reason for the increased importance of IM is the new way of contracting;
contractors are now often responsible for both the design and construction phase of the project. With the
combination of the great pressure on the time-to-market and cost aspects of the project, it leads to
compressed design and construction schedules, which overlap where possible. This overlap of design and
construction activities make the implementation of IM crucial, since any interface issue is highly likely to affect
the construction phase, leading to huge delays and extra costs.
In order to handle these complex projects SE is introduced in the construction industry. This process starts with
functional requirements, given by the client, which should be met in the design. The design of the total project
is decomposed into several sub-systems and components and is displayed in a SBS. It is important to
understand that this decomposition has an important role in the amount and type of interfaces. The
components in the SBS determine the amount and complexity of the interfaces which will exist between these
components. These components are usually a small portion of the overall system, which is manageable for a
given development schedule, and can be designed by an individual team of engineers. An interface between
two components can either fall under the scope of a single contractor, as well as under the scope of multiple
contractors. These contractors usually have different backgrounds such as structural, mechanical and electrical
and most often work separately from each other, which makes the management and control of these
interfaces even harder (Zummo, 2010).
In paragraph 3.3 the definitions and types of interfaces are described, as well as the definition of IM. By these
definitions it becomes clear what an interface is, what types of interfaces can be distinguished and what scope
is covered by Interface Management. Furthermore, in line with the second sub-question, the role of IM in the
SE literature is explored in paragraph 3.4. In here, the role of interface management within the NASA Systems
Engineering Handbook (2007) and two other SE guidelines, developed for the Dutch Civil Engineering industry,
are described.
NASA (2007) states that management and control of interfaces is crucial to successful projects and provides a
flow diagram of the IM process. Interface documentation is mentioned as an important part of the process. The
Interface Requirements Document (IRD), Interface Control Document (ICD) and the interface control plan (ICP)
are mentioned to identify and capture the interface information and the approved interface change requests.
Throughout the product integration process activities, interface baselines are controlled to ensure that changes
in the design of system elements have minimal impact on other elements with which they interface.
Prorail and Rijkswaterstaat (2009) emphasis that due to the high amount of interfaces and stakeholders,
communication and coordination of the available information is essential to prevent errors, and thus prevent
failure costs. A clear distinction is made between internal and external interfaces. All interfaces should be listed
in the requirements, and be coupled to the components. The structured recording of this data ensures that the
right information is available at the right time. Typical SE tree structures, like FBS, RBS, SBS and WBS, are
mentioned as tools to manage the complexity of projects. A Specification tree is proposed in where all
requirements, preconditions and interface requirements will be grouped by component and sub-system. In this
way the specification tree shows the relationship between the specifications, structured to the different levels
of detail.
28
Ballast Nedam

2014
BAM (2008) also states the importance of documenting the interface information. Interface requirements have
to be derived and attached to the components, while forms as the ICD can be used to control the interfaces. In
the IM process a clear distinction is made between inter- and intra-disciplinary interfaces. The IM process,
according to the guide, exists of the identification of an interface, appoint responsibility for the settlement of
the interface, arrange coordination measures and as last held meetings regularly to control the status of the
interface. In addition, tools as the N-chart-analysis and 3D-design are pointed out to assist in the process.
In paragraph 3.4 the role of Configuration Management is explored. CM involves document, baseline and
change management and has therefore a huge connection to interface management. CM gives insight in the
differences in level of development between the several sub-systems, and what consequences these
differences have. Baselines are used to control the consequences of one sub-system progressing faster than
another. In addition, change management is the process of approving (or denying) changes and is part of the
CM process. The impacts of proposed changes on as well the component itself as on any affecting component,
is explored before making a decision. Formal change control procedures are imposed to deal with necessary
modifications after the design is frozen, such as those required by incompatibilities, external changes, or
unexpected design deficiencies. Paragraph 3.5 explains the role of risk management within the SE
methodology. Risks are defined as events which could lead to delays, additional costs or a decrease in quality.
RM is an essential project management tool to deal with all risks within the project, by taking measures to
prevent, monitor and control these risks (BAM, 2008).
29
Ballast Nedam

2014
Chapter 4: IM Related Research

Interface related research is quite scarce in construction. However, the nature of interfaces and related issues,
interface management and tools have been discussed to some extent. In this chapter, relevant research work is
reviewed and evaluated in order to answer the third sub-question.
SQ:
What interface management related research has been done?
In this chapter IM related research is conducted to prevent integration issues. In paragraph 4.1 techniques are
described to diminish design iterations, while in paragraph 4.2 the benefits of virtual design is described.
4.1
Concurrent Engineering
Concurrent Engineering, or fast-track construction, is defined as the process of completing sequential tasks in
parallel, in order to reduce the project delivery times (Anumba, et al. 2007). As explained in chapter 3, design
and construction activities that were once distinct and sequential, are now often intermingled or overlapped.
Bogus et al. (2002) claims that management of the interfaces between design and construction, and the
transfer of knowledge between design and construction activities, are critical in order to reduce the project
delivery time, especially for fast-track projects. Projects start to overlap more and more design and
construction activities in order to reduce the project delivery time. However, the degree to which design or
construction activities may be overlapped, and in turn the level to which various design disciplines may be
overlapped, depend on the type of information exchanged, and the degree of dependency between those
activities (Bogus, et al. 2006). Overlapping dependent activities compress the total lead time of the project, but
could bring along extra risk since the activities may be dependent on each other.
4.1.1
Activity relationships
Based on the information dependency relationship among activities, Prasad (1996) defines four types of activity
relationships as can be seen in Figure 18. These relationships are defined as dependent, semi-independent,
independent, and interdependent.
Figure 18: Activity Relationships (Bogus, et al. 2006).
Independent activities have no relations or interfaces with each other at all. For dependent activities, the
downstream activity cannot start before it receives the required information from the upstream activity. Semiindependent activities are characterized by one activity requiring only partial information from the preceding
activities before it can begin. As last, interdependent activities require a two-way information exchange
30
Ballast Nedam

2014
between the activities before either can be accomplished. Of these four types of relationships, only the
independent activities can be overlapped without any risk of rework. Increased coordination and exchange of
preliminary information becomes very significant when overlapping dependent activities.
Bases on these relationships between the activities, and the activity durations, a presumptive schedule can be
formed for the design and construction activities. This schedule could be further compressed by overlapping
certain activities.
4.1.2
Activity Characterization
The project delivery time can be reduced by overlapping (semi-)dependent activities. However, the degree to
which design or construction activities can be overlapped depends on the type of information exchanged and
the degree of dependency between those activities (Bogus, et al. 2006). Activity characterization contains the
recognition of the information needed to finish the design and construction task, as well as the identification of
the information produced by each task. This information is used to describe the degree of dependency
between activities (Krishnan et al. 1995). The degree of dependency, in turn, is a function of upstream task
evolution and downstream task sensitivity (Pena-More, et al. 2001). Pena-Mora and Li (2001) suggests that
adopting the characterizations of sensitivity and evolution, within design and construction activities, are a way
to indentify approaches for overlapping activities. The rate of evolution is defined as the rate of generating
design information from the minute of the activity initiation, until the fulfillment of the activity. The rate of
sensitivity an indication is of how sensitive downstream tasks are to changes in an upstream activity (Eppinger,
1994).
Rate of sensitivity
The sensitivity of an activity can be determined by evaluating activity constraints, input variables, and the level
of design integration. Sensitivity becomes important when one activity is dependent on another activity.
Among design activities the most common dependencies are information dependencies, and the sensitivity of
these dependencies to changes in upstream information. Activities that depend on information from another
activity are usually ordered so that all required information is available when the activity begins. However, an
activity could be started before the required information is available, based on assumptions. Unfortunately,
basing the design on assumptions involves a certain amount of risk that the preliminary information may
change before it is finalized. The amount of rework that must be performed, if preliminary information
changes, is related to the factor of the sensitivity of the downstream activity to changes in the upstream
information.
Sensitivity refers to how much rework, measured in additional time and costs, is required on the downstream
activity if upstream information changes. A highly sensitive activity would require a large amount of rework if a
piece of input information changed just a small amount. An activity with low sensitivity can sustain large
changes in input information with only minimal rework (Krishnan et al. 1997).
Identifying the sensitivity of downstream activities is important in overlapping decisions. Starting a highly
sensitive activity before all upstream information is complete entails an increased risk that significant rework
will be required, thus eliminating some of the time savings due to the original overlapping. On the other hand,
activities with a low sensitivity can be overlapped with little risk of rework required. By understanding activity
sensitivities, project managers can make informed decisions on overlapping strategies.
31
Ballast Nedam

2014
Rate of evolution
Evolution describes the rate at which design information is generated from the start of an activity through the
completion of the activity. The evolution of an activity can be determined by evaluating the levels of design
optimization, constraint satisfaction, external information exchange, and standardization (Bogus, et al. 2005).
An activity that includes the evaluation of many alternatives or optimization of a parameter will have a slower
evolution than an activity without these characteristics. if an activity requires information from multiple
external sources, which could lead to design iteration, then this information will affect the evolution of an
activity (Bogus, et al. 2005). See Figure 19 for an impression of slow versus fast evolution of a design
information.
Figure 19: Fast (left) versus slow (right) evolution (Bogus, et al. 2005)
Bogus, et al. (2005) observed that in the absence of time pressures, most designers would prefer to include
iterations in their designs to find the optimal solution for a particular activity. This indicates that there is a
natural tendency toward a slow evolution in many design activities. However, there are not many ideal
situations, which means that most design is performed under time and/or resource constraints. These
constraints could speed up the natural evolution of an activity.
Evolution characterizations can be used in project scheduling decisions to identify potential overlapping
opportunities. In general, activities with fast evolution are more amenable to overlapping than activities with
slow evolution. However, when making the decision to overlap activities, one must consider that there is a risk
that a particular piece of information may not be finalized before the downstream activity begins. In this
situation, several strategies can be adopted to allow the downstream activity to proceed.
Certain data are required to characterize an activity by evolution and sensitivity. This information is a result of
the assessment of the design and construction documents in addition to interviews with personnel who are
close to the project such as designers and builders.
32
Ballast Nedam

2014
4.1.3
Overlapping strategies
Bogus et al. (2005) indentified eight overlapping strategies based on evolution and sensitivity information
gathered through interviews with design professionals and literature as shown in Figure 20. Overlapping
strategies are strategies to overlap design activities which have relationships, or interfaces, with each other.
Figure 20: Basic Overlapping Strategy Framework (Bogus, et al. 2006)
Low Sensitivity Slow Evolution

Overlapping of activities via trading of preliminary design information is advised in case of low sensitivity and
slow evolution. The rate of evolution could increase by standardization or performing less iteration, and
therefore increase the risk of a less optimal solution. Set-based design also increases the rate of evolution. Each
task starts as soon as there is enough input date to permit the beginning of any conceptual work. The key of
set-based design is producing incomplete information, which is sufficient enough to release work to someone
else.
Low Sensitivity Fast Evolution
When low sensitivity is combined with a fast rate of evolution, it is advisable to undergo both the exchange of
preliminary design information, and early settlement of that information by freezing the design criteria.
Exchange of preliminary design information involves the release of design information form an upstream to a
downstream activity even when the upstream design is not complete yet. Freezing the design information
requires an early commitment of the project participants to the specific design criteria. This process of early
freezing helps eliminate some of the unpredictability of the designers of downstream activities (Ramadan,
2010). However, this uncertainty reduction could also lead to higher costs. Freezing of the design criteria very
early in the project leads to a higher possibility of cost increase due to the lack of design optimization. This
strategy of was first studied by Eldin (1996) as a possible schedule reduction technique, and it was revealed
that this strategy was successfully utilized in highway projects to determine bridge design criteria (Ramadan,
2010).
High Sensitivity Slow Evolution
Activities that are characterized by high sensitivity and slow evolution do not usually benefit from overlapping,
and it is preferred to decompose such activities into smaller sub-activities if possible. The rate of evolution
could be increased by standardization or performing less iteration, but this is not advised since the information
is very sensitive to any potential changes.
33
Ballast Nedam

2014
High Sensitivity Fast Evolution
Activities with a high rate of sensitivity and high evolution can be overlapped by an early finalization of
upstream data (Krishnan et al. 1995, 1997). This could be done by freezing the design criteria in an early phase.
Next to the strategies just mentioned, overdesign can be chosen, regardless of the rate of evolution and
sensitivity. By executing overdesign, a buffer is added in the design. This buffer prevents potential rework when
certain design criteria is not very accurate, or is likely to change.
4.1.4
Consequences
Overlapping dependent activities has several advantages such as the reduction of the project delivery times.
However, overlapping also has several disadvantages. The advantages and disadvantages are best to reflect in
the aspects time, cost and quality.
Time
Contractors are often under pressure to finish the project in time. As explained, designers could reduce the
project delivery times by overlapping strategies or strategies to reduce design iterations. These techniques, as
explained, could have a positive effect on the time aspect of the project but, on the other hand, may have a
negative influence on the quality and cost aspects.
Cost
Some of the techniques proposed require a certain amount of money to execute. In addition, parts of the
project which are finished before being properly reviewed, could lead to costly change orders or rework to
match the clients general requirements, or changes in the design of other disciplines (Lam, et al. 2008). For
instance, when the concrete structure is finalized before the electrical engineer determines the location and
dimension of the cables and pipes, rework may be necessary in the form of demolishing parts of the slabs due
to the need of more shafts. Rework is an important negative consequence of overlapping activities, as can be
seen in the figure below. The term rework is defined as the unnecessary effort of redoing an activity that was
incorrectly implemented in the first instance (Love and Li, 2000).
Figure 21: Consequences of overlapping dependent activities (Blacud, et al. 2009).
34
Ballast Nedam

2014
Quality
The techniques described above could also have a negative influence on the total quality of the project. Design
iterations, and taking into account many alternatives, lead in the long run to the most optimal solution.
Strategies as the least commitment strategy, deferred commitment, no iteration/optimization, early freezing of
design criteria and overdesign all could lead to a sub-optimal solution. When the solution does not meet the
required quality, costly rework is necessary. This process could take a lot of time and effort. It may put the
owner and the design firm in various legal conflicts where the contractor is held accountable to design and
deliver a good quality product (Ford, 2000).
When applying one of the strategies mentioned to overlap dependent activities, it is important to take into
account the nature and type of information. Factors as the rate of sensitivity and evolution indicate what
strategies may be applied and what not. For each strategy should be considered what the related costs are
(e.g.: money, recourses), what the profit is, and what the possible consequences are in case of rework.
4.2
Negative design iterations
Ballard (2000) did similar research and explores unnecessary, or negative, iterations in design. Design iterations
are primarily caused by incomplete information (Hollins and Pugh, 1990). An activity is performed under
incomplete information, if it precedes activities on whose output it depends. In most complex development
processes, clear precedence constraints do not exist. Instead, the information relationships between activities
are highly complex, and often activities are interdependent, which means that they are mutually dependent
and rely on each others output. Thus, it is far from obvious how to structure development processes, nor are
existing structures necessarily efficient. In particular, coupling restraints between activities are one of the
major causes for iterations (Ulrich and Eppinger, 1995). According to Ballard (2000), the most common
techniques for reducing negative iteration in design are:
Restructuring the design process;

Use Design Structure Matrices (DSMs) to re-sequence the design process.
Use pull scheduling to reduce batch sizes and achieve greater concurrency.
Reorganize the design process;

Make cross functional teams.
Use team problem solving (call a meeting).
Share ranges of acceptable solutions.
Change how the design process is managed;

Pursue a least commitment strategy.
Defer this decision (defer commitment).
Practice set-based design.
Use the Last Planner system of production control.
Overdesign (design redundancy when all else fails).
These techniques will be described in more detail in the following paragraphs.

4.2.1
Restructuring the design process
Much of the research is focused on the planning of design, based on the dependencies of elements within the
design. These interfaces and dependencies can be seen as an flow of information. Information that is needed
35
Ballast Nedam

2014
by one design team, in order to continue with their design. Uncovering this information flow and making a
design planning based on this flow could prevent many interface issues to occur.
During the design phase, customer requirements, constructive considerations, and quality standards are
defined and incorporated into construction drawings and technical specifications to guide construction
activities. In their research, larcn and Mardones (1998) consider design as a flow in where inspection, moving,
transformation and waiting for information, redesign due to errors, omissions, and uncertainty, etc. are all
recognized as waste. Improvement and optimization of the design process can avoid such value losses.
In order to improve and optimize the design process, the coordination between the different specialties, the
standardization of design information and the control of information flow should be improved (larcn and
Mardones, 1998). Coordination could be improved by a planning scheme of the design sequence and a plan to
control and evaluate changes introduced during the execution stage. Standardization could be realized by the
development of task list, which contains the input data for each of the designers, and the development of
work specifications, which standardize the presentation of the information. Control of the information flow
could be enhanced by developing check lists to control the parameters established in the task lists (larcn and
Mardones, 1998).
Miles and Ballard (2002) indicate that design and construction activities are insufficiently integrated in modern
projects. Especially when specialty contractors are involved in the modern fast-track projects, interface issues
occur. Their research proposal aims to reveal interface problems between mechanical design and construction,
pursue improvements that accomplish the lean objectives of maximizing value and minimizing waste, and
experimentally test those possible solutions. In their opinion, some failures at the interface are systematic
and cannot be resolved by simply working harder. The ideal solution lies in a total restructuring of the
delivery process around the creation of value and elimination of waste.
The proposed process modifications start from involving the key specialty contractors (including mechanical,
electrical, and structural engineers) in an initial process restructuring group. These disciplines have the greatest
number of project coordination interfaces and workflow concurrency. Since design requires a lot of
coordination, it is very important in the restructuring process to define and structure design work-packaging,
preferably before design progresses beyond the concept level.
Use DSM to re-sequence the design process
Bogus et al. (2002) proposes a methodology for overlapping design and construction activities, reconfiguring
the design-construction interface, and finally generating an ideal overlap schedule for a fast-track project. The
core of their model is the use of a Dependency Structure Matrix (DSM) to display activity relationships, and
partition the activities to reduce the backward flow of information. The DSM, which is similar to the N-chart as
described in paragraph 3.4.2, is a matrix representation of the project, and displays the dependencies of
activities or components within the project. There are tools available which are able to order these design
activities on the basis of their information requirements, and thereby reduce the feedback loops that usually
occur in design (Browning, et al. 2006).
Austin, et al. (1999) conclude that current design planning practice gives little consideration to the
interdisciplinary, iterative nature of the process. This leads to a design process that contains inevitable cycles of
rework, together with time delays and extra costs, in both design and construction. Therefore, the ADePT
(Analytical Design Planning Technique) methodology is proposed. This technique helps with the planning of
design activities, enables work to be monitored on the basis of the production of information, and allows
36
Ballast Nedam

2014
design to be fully integrated with the overall construction process (Austin, et al. 1999). The ADePT
methodology comprises four stages as is shown in Figure 22.
Figure 22: Analytical design planning technique (AdePT) (Austin et al. 1999).
Firstly, design activities are represented in the Design Process Model. The detailed design process is broken
down into the main disciplines, then into building elements and sub-systems, and ultimately into individual
design tasks. Secondly, all information dependencies between the design activities are mapped in a schedule.
In the third stage, the information gathered will be used to fill in a DSM. As last, iterative design tasks are
partitioned in a DSM and a planning tool is used to generate an optimal design schedule. The ADePT
methodology focuses on improving the design process by satisfying information dependencies among design
activities in a more efficient way.
Varghese and Senthilkumar (2008) state that design has a numerous amount of interdependent, knowledge
intensive multidisciplinary tasks. In addition, they state the overall process is inherently iterative in nature
which makes design hard to structure. Managing this phase requires a careful planning and coordination of the
information exchange between the several engineering disciplines. A structured method to organize the
interfaces and interactions between the various design disciplines is proposed, called the Design Interface
Management System (DIMS). In here, also the DSM is used as part of the methodology to structure the design
processes. However, instead of design activities as input for the DSM, technical drawings are used. As drawings
are well defined entities, it was found that capturing the interfaces at drawing level can eliminate the
ambiguity of selecting the appropriate abstraction level..
Other researchers have also made similar attempts to improve the design process. For instance, Chua et al.
(2003) proposes a Process-Parameter-Interface (PPI) model to manage the design process of Architecture,
Engineering, and Construction (AEC) projects. The model also aims to improve design process scheduling by
reducing information iterative loop and to enhance efficient collaboration. Biggest difference in here is that
parameters are used as input for the DSM. The tool is similar to activity-based DSM, but it can be used for
lower-level process sequencing. While an activity-based DSM includes reviews, tests, and analyses, a
37
Ballast Nedam

2014
parameter-based DSM documents the physical and rational relationships between the parameters that
determine design. An extensive description and evaluation of the DSM, ADePT and DIMS methodology, as well
as the PPI-model can be found in Appendix F.
Reduce batch sizes and achieve greater concurrency
Impacts of using small batch size in repetitive construction projects were investigated by several researchers
and practitioners. One of the main advantages of using small batch size is shortened duration (Sacks and
Goldin, 2007; Nielsen and Thomassen, 2004). Small batch size leads to early release of work completed in one
activity to a next activity. Therefore, small batch size can lead to reduced cycle time and faster delivery of
projects (Shim, 2011). Another advantage of using small batch size is that defective products can be detected
early. Typically a subcontractor inspects the work released from his preceding activity before he starts his work
(Sawhney, et al. 2009). Thus, rework or correction of defective work can be performed early and construction
duration can be saved due to early detection of defective work. However, reducing batch sizes also increases
the complexity by increasing the amount of design activities, and thereby increases the need for close
coordination and management.
Team pull scheduling
The Lean Construction Institute recommends producing such a work sequence by having the team responsible
for the work being planned to work backwards from a desired goal, by creating a 'pull schedule' (Ballard, 2000).
Doing so avoids incorporation of customary but unnecessary work, and yields tasks defined in terms of what
releases work and thus contributes to project completion.
4.2.2
Reorganize the design process
Other strategies to reduce design iterations fall under the category of reorganizing the design process.
Strategies in this category are team problem solving and sharing ranges of acceptable solutions.
Team problem solving
A meeting could be called to decide as a group on the values for the relevant design data. If the various
contributors to the decision are together in one place, at minimum there could be an acceleration of the design
iterations. At best, there could be real team problem solving. Using cross-functional teams and team problem
solving to produce design could accelerate the design solution and prevent integration and schedule issues.
Share range of acceptable solutions
Many other concepts and techniques of advanced design management are relevant to the reduction of
negative iteration. Suppose the participants had been willing to share the range of values acceptable to each. In
that case, it would be simple to determine if there are values for each dimension which are acceptable to all.
However, contractors might be unwilling to share that knowledge even if they are brought together face-toface, in hopes that the final solution better favored them as opposed to others. Indeed, it appears to be a
routine of current design practice that supposedly collaborating specialists effectively compete for the priority
of the values or criteria associated with their specialties (Ballard, 1999b).
38
Ballast Nedam

2014
4.2.3
Change how the design process is managed
Other strategies are more related to the management of the design process. Strategies in this category are a
least commitment strategy, deferred commitment, set-based design and the last planner system.
Least commitment strategy
A related but more extreme strategy is that of least commitment. This strategy aims for systematically defer
decisions until the last responsible moment (i.e., until the point at which failing to make the decision eliminates
an alternative). Knowledge of the lead times required for realizing design alternatives is necessary in order to
determine last responsible moments. Deferred commitment is a strategy for avoiding premature decisions, and
for generating greater value in design. It can reduce negative iteration by simply not initiating the iterative
loop.
Set-based design
In all design processes, alternatives are generated, evaluated, and selected. Usually the best alternative is
selected as quickly as possible, after which is proceeded to the next level of detail or decision. Project members
state that they do not want to waste time on designs that will not be used, and that they do not have time to
carry forward multiple alternatives (Ballard, 2000). Set-based design prevents this by departing from the
traditional practice of producing only completed design outputs, and rather share incomplete information as
needed by others to get started.
Willingness to share incomplete information has long been identified as a necessity for concurrency in design.
Sequential processing results in part from the implicit rule that only completed design work is advanced to
others. According to this strategy, each task starts as soon as there is enough input date to permit the
beginning of any conceptual work. For each task the real goals are defined, and is known which piece of
information is really needed by other teams, and what the tolerance is that may be accepted. In this way every
team may work exactly on what matters to it. The key of set-based design is producing incomplete information,
but sufficient enough to release work to someone else. This leads to a reduced design duration and cost by
doing design work more concurrently, and a increased efficiency from better communication among members
of the design team (Ballard, 2000).
Last planner system
When a team is delivering late, follow-on teams are prevented from starting when they planned to. The Last
Planner System makes project programs more predictable, and increases the chances that projects will be
completed on time. The method creates conversations at the right level, and at the right time, to build trust
between key project members. Personal relationships and peer pressure are key to managing the network of
commitments required deliver projects on time (Lean Construction Institute, 2005). The last planner system
enables the site supervisors to plain their workload on a weekly basis and assess their teams performance on a
daily basis (Lean Construction Institute, 2005). Meetings are used to discuss the workload of the upcoming
weeks, to ensure all in advance agreed upon goals are achieved.
4.2.4
Overdesign (design redundancy when all else fails)
When it is not possible to overlap dependent activities with the above strategies, overdesign could be a
solution in some cases. By applying overdesign a buffer is created for certain parameters. This buffer is created
to provide a factor of safety, or to encounter possible design errors or changes in design.
39
Ballast Nedam

2014
When an object has a high chance to be affected by design errors or changes in design, or when the
consequences in such a situation are relatively big, overdesign could be applied. By creating a buffer possible
changes or errors in design could be compensated in advance. However, overdesign usually involves more costs
than is necessary. Therefore, before implementing, the costs attached to overdesign should be compared
carefully with the possible consequences of not applying overdesign.
4.3
Virtual design
Other research has been conducted on virtual design. 3D design has been proposed to reveal clashes in design
in an earlier phase. Korman, Fischer and Tatum (2003) state that in many construction projects the
coordination is still done using 2D drawings and light tables in what is called as a Sequential Composite Overlay
Process (SCOP). This method of coordination has proven to be inadequate and has led to many conflicts
between systems, lack of confidence amongst subcontractors to prefabricate, rework in the field and an
overall lack of productivity installing these systems in the field. Khanzode (2010) conducted research on the
coordination of Mechanical, Electrical and Plumbing (MEP) systems in building construction. In their research,
the use of Virtual Design and Construction (VDC) tools like 3D4D (Fischer and Kunz, 2004) are evaluated. The
use of VDC tools provides the team members with a better simulation environment to try and test solutions,
and also enhances their knowledge of how the systems can be assembled in the field. This is an important point
and confirms observations made by others, that using simulation tools leads to better prototypes and better
outcomes (Schrage & Michael, 2000).
3D clash detection tools could be used to identify and resolve conflicts. There are commercial tools available
that allow project teams to bring in models from multiple CAD systems into a single model, and determine if
two or more systems conflict with each other. One such tool is Navisworks which has a Clash Detection
program that allows teams to automatically analyze the models for conflicts between systems (Khanzode,
2010).
4.4
Evaluation methodologies
Concurrent engineering
Overlapping strategies could be very useful to compress the project delivery time of construction projects. At
the moment lots of design and construction activities are already overlapped due to time constraints. However,
the dependencies between the activities, and the rate of sensitivity and evolution of the interface information,
are rarely taken into account when making such decisions. As can be seen in Figure 20, based on these aspects
several strategies could be applied in order to successfully overlap these activities. It is important to explore
the consequences of applying each strategy on the aspects of time, costs and quality to make sure all risks are
taking into account. Overlapping the right activities and choosing the best strategy could reduce the risk of
potential design iterations and rework.
Re-sequence design activities
Ballard (2000) proposes strategies to reduce negative design iterations in design and construction by
restructuring or reorganizing the design process, changing the way design is management and overdesign.
Restructuring of the design process focuses on re-sequencing the design activities and use pull scheduling to
reduce batch sizes. The DSM methodology is proposed as a tool to re-sequence the design activities, and is
widely elaborated in Appendix F. The theory on DSM in construction is promising but largely limited to
academia. Although the theory of DSM has been applied in a number of circumstances, analyses in
40
Ballast Nedam

2014
construction are only just now being undertaken in practice. The ADePT and DIMS methodology are one of the
few which have been implemented and evaluated in practice.
The main difficulty of the implementation of the DSM methodology in construction lies with the decomposition
of the project design process, and the size of the DSM matrix. As input for the DSM is tried to use parameters,
design drawings, and components and sub-subsystems as displayed in the SBS. Evaluation of the DIMS
methodology in practice, which used design drawings, exposed difficulties capturing all interfaces during the
design interface meetings, because of the large size of the matrix (100x100). The designers were finding
difficulties in managing the size of the matrix. Because of the large size they tried to use the matrix on subsystem level instead. However, on this level all inter-component dependencies were neglected which
decreased the usefulness of the matrix.
A second difficulty for using this methodology is filling in the matrix itself. Exposing all dependencies within the
project is a very hard task and time consuming task, which requires expertise from all different specialties
involved. In addition, a lot of dependencies cannot be recognized at the early phase of the project. As the
project progresses into more detail, more and more dependencies will be revealed. Basing the planning on a
matrix which is only filled in for 80% does not necessarily have to be the best option. Furthermore, even if an
optimal design sequence can be obtained, modifications have to be made to this planning due to construction
constraints. Therefore, an optimal design planning still has to be modified which encounters the benefits of the
planning.
Fortunately, even still an optimal design sequence could not be obtained during the case project many
advantages had been recognized. The designers were of the opinion that the DIMS methodology provided a
forum to make collaborative decisions during the design process, especially during the workshop for capturing
the interfaces. The discussions during the workshops had pro-actively matched the teams which required close
interaction for the exchange of information. The collaborative information sharing among the design
participants was acknowledged as a key driver for the production of error free Good for Construction
drawings (Varghese and Senthilkumar, 2012).
It can be concluded that the DSM methodologies are promising, but only after sufficient testing and launching
of commercial software can this systematic tool, for finding the optimal sequence in design, be implemented
in practice. Selecting the size of the matrix and finding all dependencies asks for dedication and time-efforts, of
all parties involved. According to Koskela et al. (1997) the principle of optimizing the sequence can also be
approached informally. If the projects type is familiar, the designers will have a good feel about the optimal
sequence of tasks. Therefore, especially in new, complex, projects the DSM methodology could be of value to
assist in determine the main sequence of design.
Other strategies
Strategies like forming cross functional teams, using team problem solving, set-based design, and sharing
ranges of acceptable solutions, are good strategies to work out complex dependent activities. These strategies
focus on collaboratively finding a solution and speed up the process. Strategies to change how the process is
managed like pursue a least commitment and defer commitment, are riskier strategies to reduce design
iterations and project delivery times, and should be prevented. The consequences of these strategies should be
carefully explored before implementation. The Last planner system focuses on carefully monitor all activities in
order to reduce the project delivery times, which is a strategy that focuses on the short term, and is best to use
in de construction phase.
41
Ballast Nedam

2014
As last, a strategy which is used very commonly is overdesign. When there are time constraints and no of the
above strategies might work, overdesign could be implemented in order to continue with successor activities.
Overdesign is likely to bring along extra costs, but could reduce or prevent the risk of rework in the end.
3D design
The use of Virtual Design and Construction tools provides the team members with a better simulation
environment to try and test solutions, and also enhances their knowledge of how the systems can be
assembled in the field (Schrage & Michael, 2000). 3D clash detection tools could be used to identify and resolve
clashes in a much earlier phase. There are commercial tools available that allow project teams to bring in
models from multiple CAD systems into a single model, and determine if two or more systems conflict with
each other.
Important to state is that identifying clashes in design alone, is not a solution for IM issues. Clash detection in
3D design is a helpful tool to help identify missed interfaces, as well as to control and monitor the physical
interfaces. However, the emphasis should be on identifying and elaborating interfaces in advance. Without a
proper IM process interfaces could easily be missed or neglected, which could lead to a tsunami of clashes later
on.
42
Ballast Nedam

2014
Chapter 5: Practical Analysis

In order to get a better understanding of how IM in implemented in practice, a case study is conducted. The
practices, as implicated in a real life case, are examined and described in this chapter. First, a description of the
case study is given in paragraph 5.1. Secondly, the project organization is basically described (5.2). Thirdly, the
IM practices are described as they occurred in the case study, and thereby answering the fourth sub-question
(5.3), where after these practices are evaluated (5.4). In paragraph 5.5 an answer is given of the fifth subquestion What are the main differences between the engineering disciplines?. In paragraph 5.6, the main
types of interfaces have been identified, as they occurred between the main engineering disciplines. As last, in
paragraph 5.7, the last sub-question is answered by summing up all main factors which are currently causing
the integration issues. In Chapter 6 Factors causing integration issues, the results from paragraph 5.7 will be
verified, by comparing the findings from case study with literature.
5.1
Case description
For this research the Johan Frisosluizen project in Stavoren is used as case study. The projects goal is to
increase the capacity of the Johan Frisosluis, which will be accomplished by placing a new lock next to the
already existing one. Ballast Nedam will design and construct this project on basis of a Design, Construct and
Maintain (DCM) contract, including 20 years of maintenance. This project has a strong multi-disciplinary
character and consists of six designing entities:
Ballast Nedam Infra
Machinefabriek Emmen
Croon
Sterk
BN Bouw en Ontw.
Royal Haskoning
Process monitoring and coordination (in control of Requirement

Management Tool (RMT) Relatics);
Mechanical engineering structures;
Electrical installations;
Sheet piles, fenders and mooring facilities;
Structural Engineering of the operating office;
Concrete Structure of the lock heads, road construction and planning of
project area.
Figure 23: The Johan Frizosluizen in Stavoren (Provincie Frysln, 2012).
All contractors work separately on their parts of the project. The main engineering disciplines in this project are
Royal Haskoning, Machinefabriek Emmen and Croon which are responsible for respectively the civil,
43
Ballast Nedam

2014
mechanical and electrical part of the design. All these entities were involved from the start of the project.
Because the information gathered is rather sector than company related the companies will be stated as
respectively Civil Engineering (CE), Mechanical Engineering (ME) and Electrical Engineering (EE).
5.2
Project Organization
The three engineering disciplines (CE, ME and EE) are all involved from the start of the project with a DCMcontract, in where the exact scope of each discipline is described. In order to integrate the several engineering
entities and handle the complexity of the project, a Project Management Plan (PMP) is developed in where is
described how the projects objectives are to be achieved. The design organization is described in the
Deelkwaliteitsplan Ontwerp (DKP-Ontwerp), which is a PMP for the design phase of the project.
In this PMP the design process is described as an iterative process, in where is worked from a rough to fine
level of detail. Therefore, three phases of design are distinguished which are the Conceptual design,
Preliminary design and Detailed design phase.
In the conceptual design phase, the requirements are derived and the system solution and main sub-systems
are generated and chosen. In this phase the main structure of the project becomes visible. In the preliminary
design phase the sub-systems and components are worked out in more detail. Finally, in the detailed design
phase, all final design drawings and documents, of all components and sub-systems, are ready for construction.
For every phase the following steps are followed:
1. Specification:
2. Generating solutions:
3. Interface Management:
4. Verification:
5.2.1
Collection of data, assumptions, prerequisites and requirements and the

organization of the available data;
Working out the design documents and visualize the design (preparation of
drawings and reports);
Identification and management of interfaces in order to let the design parts
connect to each other and the environment well;
Prove that the design complies with all the requirements coming from the
contract.
Technical tools
In order to manage and control all project information and dependencies, several software tools are used. One
of the main programs used in this project is a Document Management System (DMS). The DMS is a database in
where all drawings, calculations and formal documents, of all stakeholders, are documented in one single
system, to make sure that the involved parties have access to the available, and up-to-date, information at all
times. Next to a DSM also a Requirement Management Tool (RMT) is used, which is a database that shows all
relations within the project. In the RMT all relations between objects, activities, interfaces and requirements
are easily shown, and coupled to each other. As last, virtual design is partially used in order to increase the
visibility of the design drawings.
A DMS is a program used to track and store electronic documents. It is usually also capable of keeping track of
the different versions modified by different users. In this project Microsoft SharePoint is used as DMS.
SharePoint is a platform that serves as a framework for setting up a database for information sharing and
online collaboration within a group or organization, as is often done on intranet. All involved parties can place
their documents in the database, which is visible and available for all parties at any time. Having one system for
all documents prevents information to get lost, or confusion about specific information. The goal of using
SharePoint is that information can be shared in the right way with the right person.
44
Ballast Nedam

2014
Requirement Management Tool
A Requirement Management Tool (RMT) called Relatics is used to show all dependencies within the project.
According to the developers of Relatics, the program is used to manage the requirements, tests, risks, tasks and
all project objects in a coherent network of explicitly described information. It enables users to store all kinds
of project objects and integrate them in a meaningful way. For example, requirements can be related to
physical objects, physical objects to verification tests, and verification tests to responsible project members.
Relatics offers an extremely flexible architecture that can be constantly tailored to the project needs. While
project members continue their work, Relatics offers the possibility to change the project objects that need to
be managed, or to create extra reports that offer better insight (PKM Solutions, 2013).
However, the flexibility of the program can also have a downside. The program has to be build from scratch,
depending on the project needs. When people are new to the software and the project, it may take time to
have the program ready and complete. Furthermore, Relatics can only show textual information, which means
coupling to graphical figures is not possible. This is a major weakness since drawings are one of the most
important ways of communication in the construction industry.
At the Johan Frisososluizen in Stavoren, the Functional, System, Work and Requirements Breakdown Structure
(FBS, SBS, WBS and RBS) together with the interfaces are all listed in Relatics, and are all combined to each
other. When clicking on a object it becomes visible what functions it relates to, what its relation is to the WBS
and what formal documents exist of this object. Furthermore, all requirements and interfaces of this object and
risks are stated, and all verification plans and documents are attached. This tool makes sure that all disciplines
work from the same basis and that all crucial information is available and clear to everyone.
In Figure 24, the basic structure of Relatics is displayed. As said, it is possible to adapt this structure to the
project needs. The circles indicate entities, which are among others requirements, objects, persons and
activities. The relations are indicated by arrows.
Figure 24: basic structure of Relatics (PKM Solutions, 2009).
Virtual Design
In construction projects, most drawings are made in 2D drawing software, like AutoCad. These drawings are
used to communicate the design with the construction team. However, in order to increase the visibility of the
45
Ballast Nedam

2014
drawings also 3D drawings can be produced. In this project, the CE and ME worked with AutoCAD Civil 3D,
which is a 3D-model in where they both draw their designs, next to the formal 2D drawings.
Working with a 3D-model provides many benefits. One of them is that 3D drawings increase the visibility of the
project, and are therefore easier to understand by the other disciplines. For this reason it is easier to discuss
and reveal interfaces at the interface meetings. Furthermore, by designing in one model, the software can
reveal any physical design clashes too. Therefore, 3D design is an useful tool for interface control and detecting
any missed interfaces by clashes in the design.
5.3
In this paragraph the IM practices are described as they are implemented in Stavoren. Throughout the
paragraph a answer is given on the fourth sub-question:
SQ:
How is Interface Management implemented in practice?
In the DKP-Ontwerp at the beginning of the project, an Interface Management Plan (IMP) was conducted which
basically described the IM process. The goal of IM in here is defined as:
The control of interfaces between the objects themselves (internal interfaces) and the management of the
interfaces with the environment (external interfaces), so that the objects physically and functionally connect to
each other and the environment.
The process coordinator in the project, together with the project manager, are responsible for the control of
interfaces. The identification of the interfaces runs in parallel with the design process. The more details the
design consists of, the more interfaces could be identified. Significant risks coming from the interfaces have to
be documented and recorded in the risk register.
In order to identify the interfaces meeting with the involved parties were organized. This was done in each of
the three phases of the project. The identification of the interfaces happened during interface meetings and
within the individual design teams themselves, in where the interfaces were revealed based on experience.
5.3.1
IM before reorganization
At the beginning of the project in Stavoren, the organization was not sufficient, leading to several design teams
working separately from each other. During this phase the design teams identified their own interfaces, based
on their internal processes and were using different software tools. This led to a situation in where the design
teams were working with different version of the requirements and SBS. The interfaces which were derived out
of the SBS and requirements did therefore not comply with each other. Moreover, the CE and ME used excel
sheets to document their interfaces, while the EE used a N-chart analysis for their internal organization, as can
be seen in Figure 25. There was no common system in where all interfaces were gathered and controlled.
46
Ballast Nedam

2014
Figure 25: Impression of an N-chart, used by the Electrical Engineer in Stavoren.
In the matrix, developed by the EE, is visible what systems/components of the EE are dependent of each other
and in what way. The intra-disciplinary disciplinary interfaces are displayed in green. The inter-disciplinary
disciplines and the external interfaces are displayed in respectively blue and white. According to this matrix six
main interfaces exists which are described and worked out in the six Interface Control Documents (ICDs). These
interfaces are on a lower level of detail and can therefore be predicted in the early design phase. An ICD is a
report which contains all information regarding that interface. In short, the following aspects were included:
Introduction, including the type of interface;

Involved disciplines and description of their roles;
Appointed leader/coordinator of that interface;
Description of the interface, including all involved object and their specification;
Interface requirements;
Drawings and calculations of the final design solution which meets all requirements.
These ICDs are structured reports which are useful to document and collect all interface related information.
However, for the project in Stavoren the ICDs were not filled in yet in at the preliminary design phase. In this
stage a lot of interfaces were ignored or not even identified. In addition, only the EE was working with these
documents. It became clear that working aside from each other, without clear agreements about the
management of interface, and using different software tools, led to a lot of confusion and loss of information in
the project. There was no sufficient IM team who looked over the project as a whole, and coordinated the
several design teams. This, and several other aspects which are of less relevance for this thesis, resulted in a
reorganization in the project.
5.3.2
IM after reorganization
After the reorganization weekly meetings were organized to settle and identify the interfaces of a specific
object, which is at component level of the SBS. An interface manager was appointed to be in charge to organize
these meetings and lay down the IM process. The involved disciplines of a certain object were invited to an
interface meeting, in where a brainstorm session based on technical knowledge and experience revealed the
interfaces. These interfaces were given a specific ID number and were placed in an Interface Register (IR) in
RMT Relatics. These interfaces were also coupled to the objects in RMT Relatics, in where the status and other
47
Ballast Nedam

2014
related information is listed. In the upcoming meetings the status of all identified interfaces were discussed
until the interfaces could be stated as closed.
In Relatics all interfaces were gathered in two structures. One of them is the IR, which contains one big list of all
the indentified interfaces. These interfaces are ranked based on their specific interface ID number. In this list,
as can be seen in Figure 26, for each interface the following information could be documented:
ID-number
Interface title
Interface description
Status
Objects attached
Control measure
Responsibility for the control measure
Status control measure
Requirement ID
Requirement title
Figure 26: Impression of the interface register in Relatics.
In addition, all interfaces are also displayed in an interface tree structure, divided by couples of objects. In here
all interfaces fall under the attached sub-systems. By clicking on a combination of two sub-systems, all
interfaces falling under this category are displayed. Figure 27 gives an impression of what information can be
revealed by clicking on an interface. By clicking on a object, all requirements, interfaces and risks which are
related to that object are displayed. Also, a verification plan and report is included in where the design is tested
against all requirements.
Figure 27: Impression of an interface , displayed in the interface structure, in Relatics.
Furthermore, an interface matrix was developed in where all interfaces, between the components of the SBS,
were displayed by ID number to increase the visibility of all existing interfaces. This matrix is placed in
SharePoint , but to give an impression a copy is attached in appendix B. The goal of the matrix is to provide a
48
Ballast Nedam

2014
clearer view of what component have interfaces with each other. However, in this matrix is no distinction
made between inter-disciplinary and outer-disciplinary interfaces. In addition, the flow of information is not
visible in the interface matrix. In the N-chart developed by the EE (Figure 25) is visible what sub-systems are
dependent on another, and in what way. For instance the communication system is dependent of the energy
system, but not the other way around. In the interface matrix developed for the project is it only visible that an
interface exists between two components, but it is not visible in what way they are dependent to each other.
5.3.3
Conclusion
In this chapter is explained how IM is implemented in a real life project. Every discipline has internal interfaces
but also has a lot of interfaces with the other contractors. It becomes clear that if all contractors work
separately from each other, without communicating and coordinating, a project is likely to fail. In Stavoren,
after the reorganization, an interface manager was appointed to lay out the IM process and monitor the
project as a whole. As became clear, it is important that all information, and all relations within the project, are
documented in one single location, and that all contractors work with the same processes. Several tools were
implemented in Stavoren such as DMS Sharepoint, RMT Relatics and AutoCAD Civil 3D. RMT Relatics is used to
visualize all relations within the project, and stores all interfaces and related information systematically. In the
next paragraph the current practices are evaluated.
5.4
Evaluation Current Practices
In this part, the current practices as described in the previous paragraphs are evaluated. This is done by
evaluation the organization of IM, which changed during the course of the project, and by evaluating the
identification, description, coordination and control of the interfaces during the design phase. As last, also the
planning of design is evaluated.
5.4.1
Interface Management organization
In Stavoren, the management of interfaces did not go well in the beginning. IM did not get the necessary
priority which led to a situation in where all involved contractors worked separately. The contractors did not
work in the same requirements management tool, leading to contractors working with different versions of the
SBS, WBS and the requirements. Furthermore, a lack of understanding of how to work with SE, and how to
derive the functional requirements, led to several designs which did not comply with the requirements. No
interface manager was appointed, and the interface meetings were not structured and frequently organized.
Eventually, this situation led to a point in time where one of the contractors was already detailing his design,
while another was still working on the conceptual design. Interfaces between these contractors were not taken
into account at all.
After this phase, a reorganization has taken place. An interface manager was appointed, structured interface
meetings were organized, and the data was structurally stored in both Relatics and Sharepoint. It can be
concluded that the implementation of a sufficient IM program is required at the early phases of the project.
The later interfaces are taken into account the higher the risk of design iterations and rework. Furthermore, it
is important that the IM program receives support by all stakeholders. IM processes can only work if all
stakeholders cooperate. Therefore, alignment should be reached between all main stakeholders over the
importance and content of IM. The IM process, which includes tools, roles and responsibilities regarding IM,
should be agreed upon by all involved parties and documented in a IMP, in order to make the project a success.
49
Ballast Nedam

2014
5.4.2
Interface identification
Before interfaces can be managed and controlled, they have to be identified and described. The main difficulty
with interfaces is that the identification of these interfaces is, just like the design process, an iterative process.
Just as the design develops into more detail, also the interfaces develop into more and more detail. In an ideal
situation, it will be possible to identify and deal with all interfaces at the start of the project. However, the
design process works from a rough to detailed level in several phases. Because the detailed design is still
unknown at the beginning of the project, is it impossible to identify the interfaces on to that level in advance.
Furthermore, changes in the design could lead to new interfaces as well. Scope changes or new requirements
from the client, as well as modifications from the contractors themselves, could easily lead to new or changing
interfaces. This makes the identification of interfaces an iterative process. If the design changes, or more
details are uncovered, new interfaces can arise. This nature of interfaces makes the process of interface
management quite difficult.
The interfaces at the Johan Frisosluis were identified during weekly interface meetings. In here all involved
parties revealed the interfaces based on experience and logical thinking. The project team in Stavoren
succeeded to identify all main and most important interfaces in time. This was accomplished by inviting all
involved project members to the frequently held interface meetings, in where all interfaces were identified
systematically based on experience. As the project progresses, additional interfaces were identified and added
to the IR. In order to check if all physical interfaces have been identified, 3D design was used by the mechanical
and structural engineer in this project. The 3D model increased the visibility of the project and is able to
identify clashes between the designs.
In order to identify all interfaces, all contractors should actively participate in the structured organized
interface meetings. Some interfaces may not be relevant for one of the contractors but could be of huge
importance for the others. Insight in the importance of IM and follow up on the processes as described in the
PMP, as well as all agreements made, are necessary to prevent interface issues. Furthermore, it is advised to
work with 3D drawings as much as possible, since these drawings could easily identify clashes which could
otherwise be overlooked.
5.4.3
Interface specification
When an interface is identified, all information regarding that interface has to be documented and specified. It
is important that all interface information is documented, and available in one place, for each stakeholder, at
all times. The involved parameters, required interface information of both contractors, and agreements about
tasks and deadlines should be described as soon as possible, and stored in a common place.
At the Johan Frisosluis, all basic information regarding an interface is placed in the IR in RMT Relatics. When an
interface is identified, all required information has to be collected and documented. However, this was not
always done consistently. Information was often missing, leading to confusions during the elaboration of that
interface.
5.4.4
Interface coordination
When an interface is identified and described, the next step is to coordinate that interface. An interface exists
between two components and needs to be uncoupled so that both design teams can finish their designs
individually. However, it is not always as easy to uncouple and control an interface. Both designers have to
coordinate their designs closely which often requires a back and forth flow of information. This information
could be dependent on other designs which makes the whole an iterative and complex process. Close
coordination and formal agreements related to that interface should lead to a mutual solution.
50
Ballast Nedam

2014
In here, some progress can be achieved. First of all, the interface meetings, which reveal the dependencies
within the project, should be held as early as possible. The earlier interfaces are recognized the easier it is to
manage those interfaces. Secondly, formal agreements should be made regarding these interfaces. It still
happened that disciplines were not aware of their responsibilities regarding an interface. For instance, the layout of the concrete basement was based on both mechanical and electrical equipment. The CE was in the
opinion that the ME and EE had to coordinate the spatial interfaces regarding this equipment, while the EE and
ME were waiting for the CE to coordinate and manage that interface.
Furthermore, agreements were lacking about the deadlines for closing an interface. It has been mentioned
several times that interface information is not available at the moment others would like to see so. In this
project it happened multiple times that the CE needed information from the EE, while that information was not
available yet. When no deadlines are given, it could happen that specific information is not given the necessary
priority by the contractor. This could lead to a situation where the contractor waiting for the information has to
keep pushing and asking for this information, leading to delays. At the Johan Frisosluis, it happened a couple of
times that it took multiple interface meetings, before specific information was finally available.
This required flow of information should be made transparent, and deadlines for interface information should
be agreed upon sooner. When is known in advance, what information is needed by what design team on what
moment, and well defined agreements are made regarding this information, a lot of delays due to waiting, or
incorrect assumptions, could be avoided.
5.4.5
Interface control
The interfaces should be monitored and controlled during the entire project life cycle to make sure no errors
arise. The status of the interfaces is monitored during the interface meetings in the design phase. Open
interfaces will be discussed, and measures will be taken where necessary. For all elaborated interfaces
verification is needed before the interface can be closed.
For the physical interfaces clash detection software in 3D design, as well as 2D drawings, are used for
verification in design. When no clashes are identified in as well the 2D as 3D drawings, the interface can be
closed. Verification of the functional interfaces is a bit harder. Depending on the interface a, in advance agreed
upon, verification method will be used. This could entail calculations, drawings, literature or any other prove
to ensure that the requirements are met.
After an interface is closed, it still has to be controlled during production and construction. As an example, a
lock gate has to be placed in a lock head. This interface is elaborated by giving the lock head and gate a certain
dimension. When during production the gate appears to be a bit bigger, and/or the lock head appears to be a
bit smaller, huge problems could occur. This risk should be identified in advance and could be controlled by, for
instance, taking a bigger margin in the design, or monitoring the fabrication process more closely. High risk
interfaces should be identified as risk, and treated as such by the risk management department. During design,
production and construction, it has to be clear what interfaces, and attached activities, need extra attention
and why. Control measures should be taken to prevent potential integration issues where necessary.
5.4.6
Design Planning
Project are decomposed into several components, which fall under the scope of multiple contractors.
Nowadays, at the start of the project a global construction planning is based on the SBS and WBS. The
construction phase requires a certain sequence of activities and has a certain time frame. The construction of a
component cannot start without the approval of all related formal design documents. Therefore, the detailed
design drawings need to be ready at certain points. The planning of the design components is mainly based on
51
Ballast Nedam

2014
these requirements from construction. The components which have to be build first are therefore pulled
forward in the design phase. Unfortunately, when planning the sequence of design, the interfaces are rarely
taken into account.
This process can also be recognized at the project in Stavoren. Most of the interfaces are identified, but it is not
until the engineer starts with the design of that specific object that is noticed that specific information from
another engineer is needed. The other engineer could be working on other parts of the projects which forces
the initial engineer to wait, or go on with another component. Important is to state that the design process is
an iterative process which usually requires a back and forth flow of information. Therefore is tried to start with
the design of as many components as possible, and the most emphasis is put on the objects which have to be
ready first, in order to start with construction. For this project the design of the construction pit for instance
has been put forward, because the construction of this pit had to start relatively early in the process.
In addition, no distinction is made between the interfaces. Some interfaces carry high risk for the project, while
others do not. Some interfaces could have a big impact on the costs and lead time, but are handled late in the
design process because the construction requirements allow them to. It is advised to take into account the
interfaces with high risk, and pull them forward in the design phase where possible.
5.4.7
Conclusion
In this chapter the IM process is evaluated. It becomes clear that an IM process should be implemented as early
as possible in the project. A plan has to be developed in where all IM related processes, tools and roles are
described. Important in here is that these processes are supported by all contractors. Alignment between all
stakeholders should lead to a IM plan which is supported by all, and therefore more likely for the contractors to
stick to it. An important aspect of IM is the identification of the interfaces, which is already a difficult process
itself. The more details in design are uncovered the more interfaces arise. Furthermore, scope changes or new
requirements from the client could easily lead to new or different interfaces which makes the identification of
interfaces an iterative process. In Stavoren the interfaces were identified during interface meetings based on
experience, and 3D design was used to identify clashes in the design. RMT Relatics was used to document and
store all interface related information.
Most conflicts in the project occurred during the management and control of the interfaces. Both designers
have to coordinate their designs closely which often requires a back and forth flow of information. It happened
that disciplines were not aware of the responsibilities regarding an interface, and no agreements were made
about deadlines for solving an interface. This required flow of information should be made transparent, and
deadlines for interface information should be agreed upon in advance. When is known, in advance, what
information is needed, by what design team, on what moment, and well defined agreements are made
regarding this information, a lot of delays due to waiting, or incorrect assumptions, could be avoided.
Furthermore, at the moment there is no overview of what interfaces are more important than others. Some
interfaces could have a big impact on the costs and lead time, but are handled late in the design process
because the construction requirements allow them to. These interfaces have to be taken into account at the
planning of the design activities. These activities should either be pulled forward in the design phase, or other
agreements should be made in order to mitigate that risk.
5.5
Different Engineering Disciplines:
The interfaces which cross contractual boundaries are the most critical in infrastructure project development.
Even if all contractors interact with each other to resolve conflicts, or to improve the design, they are often
unaware of how their activities affect the delivery or operation of other project teams (Nooteboom, 2004). In
52
Ballast Nedam

2014
order to understand the difficulties regarding IM, the design processes of these engineering disciplines are
globally evaluated, based on the findings from the Johan Frisosluis in Stavoren. The main differences and
similarities, and the attached difficulties concerning the management of interfaces, are described. Thereby, an
answer will be given on the fifth sub-question:
SQ:
What are the main differences between the engineering disciplines?
The main engineering disciplines are all specialized in their field and produce different products. The CE usually
designs the civil structure, or lay-out of the project, the ME produces all mechanical equipment, and the EE
develops all electrical and software related parts of the project. All these products have to be integrated
successfully in order to develop the final system. Since the output of these disciplines differs a lot from each
other, it is not strange that the design processes slightly differs from each other as well. Three main differences
which have been identified in this chapter are the output they produce (objects versus systems), the internal
organization, and the path in time they take. These differences all bring their difficulties to the management of
interfaces, and should be taken into account at the start of the project.
5.5.1
Objects versus Systems
A big difference between the disciplines can be recognized by the output they produce. The CE en ME produces
physical objects, while the EE mainly produces systems and only have physical objects which support those
systems. This can be already be noticed by looking at the SBS. In the SBS the decomposition is done
geographically, in where the system is split up in object based sub-systems, based on physical areas and
locations. This approach is used to increase the visibility and coherence of the system. Next to that, all
components which have been derived from a sub-system are allocated to an engineering discipline. In this way
the scope and responsibility of all involved entities is made clear. In the SBS at the Johan Frisosluis in Stavoren,
the sub-systems are objects which are divided by location. These sub-systems are the upper lock head, the
lower lock head, the lock chamber, the project area, the road connection, the operating building and the
waiting bays. In Figure 28 a simplified version of the SBS is shown. The full version of the SBS can be seen in
Appendix B.
Figure 28: Edited version of the System Breakdown Structure in Stavoren.
The design of the EE is hard to decompose in objects, and even harder to designate to geographical locations.
The systems they produce cannot be allocated to a single sub-system and are therefore separated from the
rest in the SBS. So, next to the area specific sub-systems is there a sub-system called Electrical and
Instrumentation (E&I). The components attached to this sub-system are systems like the operation and
control of mechanical systems, the communication system, energy supply, lighting system and building
related systems. These components have no site specific destination and are functional systems instead of
objects. Only the building related systems could be related to the sub-system Operating building since they
53
Ballast Nedam

2014
only have relations with that specific sub-system. For the other components is it impossible to relate them to
one specific geographical location.
Next to the systems, the EE also designs physical objects, supporting the systems. Objects the EE could
produce, are objects like control panels, camera systems, cables and pipes. Those objects could be allocated to
several sub-systems but the difficulty here is that they all make part of the same system. When each camera is
a different component in the SBS, allocated to each specific subsystem, that will mean for each of these
cameras a separate formal detailed design drawing has to be produced. This is inconvenient for the EE because
all those designs are about the same, and are related to each other. For the cables and pipes is it even harder,
or even impossible, to divide the objects to different subsystems. The cables go through many components,
which means each piece of the cable have to be allocated to another subsystem.
It can be concluded that the EE is a complete different discipline compared to the ME and CE, looking at their
products. Due to the separation in the SBS is this leading to an enormous amount of interfaces for the EE. The
systems they produce cover the whole project. The EE not only has many functional interfaces with the ME, but
also has lots of physical interfaces all over the project.
5.5.2
Internal Organization
Another main difference between the EE and the other disciplines is that they work with a lot of
subcontractors. The CE and ME mainly design the objects their selves and only need suppliers for the materials
and detailed objects. In Stavoren the ME works with one sub-contractor, who is responsible for the design and
construction of the hydraulic drive. The EE develops systems, and because they do not possess all the specific
knowledge within the company, they have to outsource some of these systems.
These external companies have to design and construct these systems which bring even more complexity to
the project. The EE by nature is therefore already more of a system integrator than the other disciplines. The EE
has to control and monitor all the inter-disciplinary interfaces, and has to coordinate the interfaces of these
subcontractors with the ME and CE where necessary. For interfaces which require a back and forth flow of
information this process could be quite time consuming. The process takes more time than a direct line of
communication and will not stimulate the collaboration between the companies. Furthermore, sub-contractors
of the EE are less likely to adapt their design for the interest of the CE and ME, with whom they have no
contractual relationship with.
5.5.3
Path in time
Another difference between the disciplines is the path they take in time. The three main disciplines start with
their design based on all the requirements. The CE usually determines the main lay-out of the project at the
early start of the process. Whether the project contains a bridge, lock or a tunnel, the physical structure, which
will be visible, is always the civil structure. Therefore the global objects of the civil engineer are known
relatively soon in the project. Later on in the process the design will be worked out in more detail and the
dimensions of the structural design will be determined. For the ME, the physical objects can be determined
relatively quick as well. Looking at a bridge for instance, the design of the machine to operate the bridge with
depends on the global dimensions and type of the bridge. For the design of the machine the global dimensions,
height and functional requirements, like the speed the bridge should go open with, are crucial to determine
what kind of machine is going to get used. When all these requirements are known a trade-off analysis will be
performed to chose the best system.
The EE, on the other hand, starts with designing the main systems first. When the global lay-out of the civil
structure, and the type of mechanical machines, is known the EE can start with the design of the operation and
54
Ballast Nedam

2014
control systems of the mechanical machines. So, where the ME and CE start with physical site specific objects
and work these out in more detail, the EE starts with software and system related designs. The energy system
usually comes last, when all energy recipients are known. The specific details of the objects attached, which are
mainly cables and pipes, are not known until all the systems have been designed. The EE is in this process very
dependent on the other disciplines. The more details are known from the Structural and Mechanical design the
more details the EE can produce.
In addition, the EE usually works with a lot of sub-contractors and suppliers. The procedure behind finding subcontractors is quite time consuming. The EE has to make a tender and has to look for available suppliers with a
good price quality ratio. Next to these subcontractors the EE works with many suppliers, much more than the
other disciplines. For objects like cabinets, cables and power supplies suppliers has to be found. This consumes
a lot of time for the EE in the early design process, which make the EE usually be last in the design process.
At the moment the EE is designing the systems, a first indication of the physical objects can already be given. In
the conceptual design is already known globally were the control panels and communication pylons will be
placed, and where the cables will go. However, the details and exact dimensions will not be known until the
last phase of the process when the other designs are as good as finished. This lack of detailed information from
the EE, about the physical objects they produce, can lead to conflicts. When the size of the control panels is not
exactly known yet, and the CE finishes his design, or even starts with construction already based on
assumptions, serious problems can arise when this information suddenly changes. Talking with EEs they state
that they are constantly feeling the pressure of the other disciplines to come up with the detailed design
information. They feel that the rest is waiting on them and feel pushed in their design process because of these
interfaces.
5.5.4
Conclusion
In this chapter the main differences between the engineering disciplines in the design process are described.
Firstly, the EE designs systems, in where physical objects are included, while the other disciplines only design
physical objects. Therefore, the EE is usually separated in the SBS from the other disciplines. The components
of the CE and ME are divided into objects and geographical locations, while the components of the EE are
divided into systems. This setup shows the coherence of the project quite well, but on the other hand leads to
an enormous amount of interfaces for the EE. Secondly, the EE works with a lot of sub-contractors and
suppliers. All these extra parties makes the communication and collaboration between the entities much
harder. At last, the EE is very dependent on the design of the other disciplines which makes their design usually
finish last. A contractor waiting on interface information from the EE could either wait, or base his design on
assumptions. With the overlap of design and construction activities, contractors are more likely to base their
design on assumptions nowadays, in order to prevent delays. This brings along extra risk for the project.
5.6
Types of Interfaces
The interfaces which occur in a lock project are, of course, dependent on the way the project is decomposed.
By looking at the three main engineering disciplines a couple of standard interfaces could be identified, on a
lower level of detail. In other projects more contractors could be involved, which increases the amount, and
could influence the main types, of interfaces.
55
Ballast Nedam

2014
Figure 29: Main types of interfaces between the main engineering disciplines.
Based on the main interfaces between all different project teams seven main types of interfaces can be
distinguished. The main interfaces between the engineering disciplines are displayed below:
Main interfaces between CE ME:
1) Spatial interfaces;
In here, all spatial interfaces between the mechanical, structural and electrical objects are described.
The exact dimensions and locations of all objects have to comply with each other.
2) Connection of mechanical installations and objects to the concrete structure;
Mechanical installations and steel objects have to be connected to the concrete objects.
Main interfaces between CE EE:
1) Spatial interfaces;
In here, all spatial interfaces between the mechanical, structural and electrical objects are described.
The exact dimensions and locations of all objects have to comply with each other.
2) Cables and Pipes;
Cables and pipes could go through concrete and/or steel objects.
3) Connection of electrical objects to concrete or steel structure;
Electrical objects (e.g. light structure, sensors) have to be connected to the concrete or steel objects.
Main interfaces between ME EE:
1) Operation and control mechanical installations;
EE has to design the soft- and hardware to operate and control the mechanical installation.
2) Energy supply for mechanical installation;
EE has to supply energy for the mechanical installations.
3) Connection Cables to the mechanical installation;
Type of cables and type of connection points have to fit the mechanical installations.
4) Cables and Pipes;
Cables and pipes could go through steel objects.
56
Ballast Nedam

2014
5.7
Main difficulties regarding IM
In this chapter the IM practices as implemented in Stavoren are described and evaluated. During the case study
a lot of issues and problems regarding IM have been mentioned. Some interface issues occurred because of the
nature of the design processes, while others are caused by organizational or individual aspects. The main
problems and difficulties mentioned in the case study are summarized below.
1.
Interface Management did not get the necessary attention by all contractors.
Most contractors were able to handle their intra-disciplinary interfaces quite well, but did not really
focus on the intra-disciplinary interfaces. A lack of communication and coordination in the project led
to parties designing solo, without taking into account the interfaces with each other.
2.
Disciplines by nature, take another path in time.

Because the EE is relatively late in the design process compared to the CE, it happens that the CE
needs specific information, about for instance the dimensions and locations of cables and pipes, while
the EE does not have this information yet. In that case, the CE either has to wait or base his design on
assumptions.
3.
Lack of experience with Systems Engineering.

Some companies do not have experience in working with functional requirements, deriving the
requirements, making a design and/or identifying interfaces.
4.
No proper interface organization.

There was no interface manager and no proper Interface Management Plan in the beginning. It was
not clear for all parties what was expected from them.
5.
Responsibility for certain interfaces was not clear.

It happened several times that it was unknown who was responsible for the coordination of a certain
interface. It happened that both sides of an interface were just waiting for the other to come up with
a solution, or that both sides implemented a different solution without discussing this with the other.
6.
Lack of uniform tools.

Not all contractors were familiar with the tools used like Relatics. One contractor started to use his
own tool which caused some confusion and conflicts between the parties. When different tools are
used, the risk exists for instance that parties are working with different versions of certain documents.
7.
No deadlines for interfaces were always given.

There was no planning for the elaboration of interfaces. Interfaces were identified and documented,
but it was not clear when one of the parties attached to the interface needed specific information
from the other. This led to delays in some cases.
8.
There was no distinction in the kind of interfaces.

Some interfaces were of high risk for either costs, lead time or quality while others were just small
interfaces which could be handled anytime in the project without any risks attached. There was no
distinction made between the interfaces which made it impossible to focus on the most important
interfaces.
9.
All disciplines worked mainly from separate locations.

Working apart from each other complicates direct communication and collaboration.
10. The engineering disciplines possess specific knowledge and all speak their own language.
Because all disciplines have their own products and definitions, is it way harder to understand each
others processes and activities. Without sufficient communication and coordination
misunderstandings could easily occur.
57
Ballast Nedam

2014
11. Disciplines argue who will adapt his design to the other regarding an interface.
An interface occurs between at least two objects. The interface could give discussions about who will
adapt his design to the other, regarding the interface. In Stavoren it happened that the ME placed an
hydraulic drive in the basement, while the EE placed his equipment on the same place. One of the two
had to adjust his design to the other, but both were of the opinion it should be the other.
Every project is unique and has unique circumstances, which indicates these problems and difficulties
mentioned above do not necessarily have to apply to all infrastructure projects. Therefore, these results are
verified in the next chapter Factors causing integration issues. In here, the main problems and difficulties
regarding IM in literature and practice are evaluated and compared. At the end of the chapter the problems
are categorized in two main areas of concern.
58
Ballast Nedam

2014
Chapter 6: Factors causing integration issues

Many in the industry have determined that more effective IM would enhance the successful delivery of
projects (Nooteboom, 2004). However, this discovery of IM as a possible solution has been born from the
disappointment of projects gone wrong. That is, IM is not necessarily a new invention, but rather a critical
project component that to date has not been fully appreciated or appropriately addressed (Nooteboom, 2004).
In this chapter IM literature is explored to discover the main problems and difficulties regarding IM.
Throughout the chapter an answer will be given on the sixth sub-question:
SQ:
What are the main factors causing integration issues?
These factors are found by exploring all issues mentioned in related literature, as well as resulted from the case
study. The main factors causing integration issues, mentioned in literature, are described in paragraph 6.1. In
paragraph 6.2 the main differences and similarities, between findings from literature and case study, will be
evaluated. Thereafter the main problems will be compressed into two main categories (6.3 and 6.4).
6.1
Interface Management related issues
In other engineering sectors a lot of literature is available about integration issues. In aircraft design for
instance, Tristl et al. (2013) identified and clustered the main problems around dispersed information,
collaboration and shortcomings in the synchronization between the several disciplines involved in aircraft
design. The key factors causing these interface, and integration issues, are shown in Figure 30.
Figure 30: Key factors causing interface and respectively integration issues in aircraft design (Trist, et al. 2012).
In the construction industry, interface related studies are very limited. However, some research has been done
in order to reveal the most common interface issues, and to identify their potential causes. In literature,
insufficient and inaccurate interface information, as well as inefficiencies in information sharing, are among the
most often mentioned causes leading to many critical interface issues (Al-Hammad and Al-Hammad, 1996; AlHammad, 2000; Miles and Ballard, 2001). IM cannot be properly performed without a sufficient flow of
information (Chen, 2007).
Josephson et al. (1996) did a study on construction defects and found that, measured by cost, design-caused
defects had the biggest impact. Out of these design-caused defects, it were those originating from lack of
coordination between the disciplines which caused the main problems. Cost overruns and delays often
emanate from a lack of planning and coordination specific to the interfaces. Especially those which link
different scopes of work. Contractors often coordinate their own IM issues well, effectively managing their own
specific work scopes and schedules. However, problems arise when issues cut across delivery teams, with
cross-function issues often not receiving the necessary priority (Nooteboom, 2004). Moreover, various project
teams and disciplines are often unaware of how their activities affect the delivery or operation of other project
59
Ballast Nedam

2014
teams. Poorly defined interfaces between different scopes of work, and failing to properly manage resulting
conflicts, cause serious cost overruns and delays (Nooteboom, 2004).
In addition, the increasing amount of teams involved in the project makes it even harder to determine who has
the ownership of a particular interface. Often, confusing exists about who has ownership of a particular
interface. This dilemma is just one of many issues that project teams need to consider early in project
development because the later an issue is addressed, the greater the consequence and impact on delivery and
startup (Nooteboom, 2004).
Other researchers mentioned more factors for potential interface issues. According to Varghese and
Senthilkumar (2010) the three most important aspect for interface related delays in projects are inappropriate
assumptions, poor information flow and inappropriate sequence of work performed. Fritschi (2002)
mentions that the four main causes of interface issues in the design phase are no clear definition of tasks,
insufficient preparation work, unsatisfactory information, and poor communication. larcn and Mardones
(1998) also give many reasons for design problems. The main reasons include defects of individual specialists
and the lack of coordination among specialties, changes introduced by the owner and designers,
inconsistencies among drawings and specifications, designers with little knowledge and non technical
specifications.
Ballard (2000) has revealed estimates as high as 50% of design time spent on needless iteration. the main
causes for these needless design iterations in construction are according to Anumba, et al. (2007) uncertainty
(missing or unstable information), changes in requirements or scope, downstream stages are overlooked in
upstream stages, poor ordering of tasks and the need for correcting design errors.
As becomes clear, many different factors are related to integration issues. In the next part, the factors
identified in literature will be compared to the findings from practice in order to reveal the relations and
similarities between the two.
6.2
Comparing findings case study with literature
In paragraph 5.7 the main problems related to IM in Stavoren are mentioned. In table 1 (Appendix D) the
problems in Stavoren are compared with the main issues mentioned in literature. It can be concluded that
most of the problems mentioned in Stavoren can be related to the most common problems mentioned in
literature. Some factors identified in literature could be directly linked to the issues in practice, while others
have indirect links. Some of the factors identified in literature are (partly) caused by the aspects in practice, or
the other way around.
Based on the findings from literature and practice, two main categories for interface issues have been
identified. Most of the factors mentioned are related to two categories, which are a poor communication
among parties and a poor coordination among parties.
Poor communication among parties
Communication is the activity of conveying information. Infrastructure projects involves many stakeholders,
which cannot function effectively without good communication among the participants. This back and forth
flow of information is essential for project success. Poor communication causes a wide variety of design errors,
conflicts, delays, and project failures, which reduce the overall performance of project participants as well as
the quality of the final product. The communication between employees from the same company is usually
much better than across contracts boundaries. This is one of the main reasons inter-disciplinary interfaces
60
Ballast Nedam

2014
cause much more problems than intra-disciplinary interfaces. Poor communication can be divided into a lack of
communication and delayed or ineffective communication.
Lack of communication
A lack of communication usually arises from a lack of understanding what information is needed. When people
do not realize what information is needed for them to execute a task, poor communication will easily arise
among parties.
It is known that subsequent activities often require information from preceding activities. The pushing method,
in where people in preceding processes pass the information they think is important to people involved in
succeeding processes, has been used for years to communicate this kind of information (Chen, 2007). One of
the shortcoming of this method is that the information dependencies among parties is often unclear in
complex projects. Furthermore, people providing the information hardly know what information is exactly
needed by the people using the information (Nooteboom, 2004).
At the moment a Request for Information is often used as a way to gather all information needed (Chen,
2007). Just before specific information is needed for an activity this request is sent out. The user expects a
rapid response, but this is not always possible since the information needed could be dependent on others as
well. This could lead to a delay for that activity, and may on the long run even weaken the relationship
between the participants.
Delayed or ineffective communication
It also happens that there is no lack of communication, but the flow of information is still delayed or
ineffective. Communication could be delayed or ineffective if the information is insufficient, inaccurate or if
there are inefficiencies in information sharing.
This could happen due to multiple reasons. Tools and methods which are used to share information for
instance, play a major role. Communication could take place, among others, through telephone, face-to-face
meeting, electronic mail, instant message, voice and video conference, and web related software. Choosing a
sufficient medium, and be consistent, could prevent conflicts. Information related tools and software used in
the project should be well known to all involved participants.
Furthermore, it takes time for people to determine whom they should contact and to build a communication
channel, especially across contractual boundaries (Chen, 2007). Not knowing who to contact could prevent
timely and effective communication. More delays or misunderstanding could occur, when the people involved
in the communication are not direct users of that information (Chen, 2007). In that case further communication
is required. In general, it can be said that the most effective communication is conducted between people who
directly generate or use the information (Chen, 2007).
Moreover, the lack of information standards reduces the communication efficiency. When, for instance,
different formats, tolerance and measurement units are used, an environment will be created in where errors
are easily made (Al-Hammad and Al-Hammad, 1996).
Poor coordination among parties
A construction project has numerous participants who are more or less interrelated. Coordination amongst
them in both design and construction is required to ensure compatibility between subsystems and components
and to minimize conflicts in schedules and activities among different contractors. As already mentioned, poor
61
Ballast Nedam

2014
coordination among parties results in various interface issues, ultimately leading to delays and extra costs. The
causes of poor coordination among parties can be divided into several factors, as is elaborated below.
Unaware of interface issues
Problems related to the interfaces, are often not recognized as such in the construction industry. The
understanding of interface issues is still superficial and the importance of IM has not received wide acceptance
(Eppinger, et al. 1994). Project members witness design and construction conflicts and delays, but they seldom
categorize these problems as interface issues (Nooteboom, 2004). Therefore, they do not realize that close
coordination through organizational boundaries could avoid and resolve most of these issues. This
unawareness results in a poor coordination among different project disciplines.
Unaware of interface ownership & responsibilities
There is often unawareness of who has the ownership over a particular interface (Nooteboom, 2004). Each
interface may involve different contractors. It is of utmost importance that the scope of each contractor is clear
for all participants, in order to designate responsibility. However, even if the scope is well defined, it happens
that the ownership of an interface causes confusion. It could happen for instance, that a specific interface is
not clearly defined in project documents such as specifications or drawings. This results in a situation in where
it is unclear who is responsible for coordination. If also the general contractor, or the involved teams, fail to
appoint the responsibility of an interface to a certain project team or person, problems can arise.
Kuprenas and Rosson (2000) also conclude that questions of responsibility for contractors and disagreements
about scopes of work are common problems. Interfaces between contractors have to be defined and clarified
as soon as possible. This could prevent future confusion about the ownership and responsibility of those
interfaces. Shrive (1992) points out that preplanning of scopes and responsibilities for the whole work and
consideration of all contract interfaces, before bidding, is mandatory for the successful delivery of projects.
Lack of resource and personnel to facilitate coordination
Contractors usually lack a specialized interface manager to supervise interface coordination (Chen, 2007).
Project management personnel are normally not experts in IM and their time is also occupied by other
management activities. In addition, with the increasing project complexity, the total number of interfaces rises
enormously, making the task of the interface manager even harder. Moreover, extra resources to facilitate IM
are not widely available. There are no standardized interface databases or computer software for IM in the
construction industry. This makes the performance of IM difficult to enhance (Chen, 2007).
Lack of coordination among specialties
The main disciplines involved in infrastructure projects are the CE, ME and EE. Some of these specialty
contractors could be involved as subcontractor. Most problems arise when interface issues cut across
contractual boundaries, with cross-function issues often not receiving the necessary priority (Nooteboom,
2004). In practice, there is usually no contracting relationship between the specialties. Their respective
contracts do not fully specify coordination responsibilities. If the general contractor does not recognize these
issues and help initiate coordination among all the engineering disciplines, critical interface issues could arise.
Another reason for the lack of coordination among specialties is the absence of knowledge in each others field
of work. Disciplines like the CE, ME and EE have a unique character and have their own output and design
processes. When talking with the ME and EE, they state the biggest problem with general contractors and
construction managers, and even the architects and project owners, is that they do not understand the
62
Ballast Nedam

2014
mechanical and/or electrical contractors business or what they are supposed to do on the job (Orth and Mains,
2008). The lack of knowledge in each others work and processes prevents pro-active coordination.
Poor ordering of tasks
Also a poor ordering of tasks could prevent sufficient coordination among parties. Typically a global design
planning is produced by the project manager, which includes global activities and milestones. This planning is
distributed to the leader of each design team, who then plans their work within the framework of that planning
(Choo, et al. 2004). This approach assumes that design information is made available and communicated
between the project participants as required, either informally or formally via drawings and design reviews.
Experience shows that this is often not the case and that design should be planned around information flow,
rather than deliverables, if a coordinated and effective solution is to be found (Choo, et al. 2004).
Network analysis and critical path methods are the generally accepted methods for the planning and
scheduling of construction work on large to medium sized projects. However, they are inappropriate for design
management because of its ill-defined iterative nature (Ulrich and Eppinger, 1995). When tasks are ordered
without taking their interdependencies into account, a situation could occur where one task needs information
from another to proceed, while that other task is not even started with. This will easily lead to poor
coordination, and eventually to delays and conflicts.
Unable to work on site simultaneously
When design teams work at one physical location at the same point in time, coordination and communication
across these teams will be much easier (Khanzode, 2010). Unfortunately, design teams coming from different
companies are usually not located in the same area, which makes it harder to work at a common location. In
addition, many contractors work on more projects at the same time, which leads to situations in where the
designers work on the project at different days in the week. When design teams work at the same physical
locations at the same point in time, efficient and fast coordination and communication will be encouraged.
Unwilling to bear coordination and resolution responsibilities
All parties involved in a project have their own scope of the project and their own interests. It appears to be
current design practice that, supposedly collaborating specialists, effectively compete for the priority of the
values or criteria, associated with their specialties (Ballard, 1999). When contractors are purely focusing on
their own priorities and interests, poor coordination will follow.
Subcontractors are often unwilling to bear coordination and resolution responsibilities for potential or existing
interface issues. They are willing to make every effort to avoid their own mistakes that lead to financial penalty
or loss of profit, instead of considering the situation of others and conducting timely coordination for them
(Chen, 2007). In addition, in the multiple contracts is often not clearly specified that contractors are deemed to
cooperate regarding the interfaces, and that the interface solution has to be tested jointly.
Discussions could occur about who will adjust to the other in other to meet the interface requirements. The
subcontractor will most likely try to lower the costs of his scope of the project instead of looking at the project
as a whole. For instance, when the structural engineer can reduce the size of the concrete basement a
reduction in costs can be expected. If at the other hand a smaller basement lead to a situation where the EE
has to order smaller and more expensive control units, discussions could occur about the final solution.
63
Ballast Nedam

2014
Another cause for unwillingness to coordinate is a low profit margin. A low profit margin limits subcontractors
willingness and capability for coordination and resolution, which involves both time and cost. These issues
could lead to poor and inefficient coordination between the different parties.
In general can be said, the more risk a company bears, the better the involvement will be in the project. When
all companies have the same goal and interests, the coordination and collaboration will go much more fluently.
64
Ballast Nedam

2014
Chapter 7: Interface Management Framework

Without a sufficient IM program, integration issues could easily occur. Therefore, a systematic approach for
Interface Management (IM) is developed which identifies, manages and controls the interfaces, during all life
cycle phases of the project.
This chapter will start with the set-up of a successful IM program, which contains an Interface Management
Plan (IMP) for the project (7.1). In paragraph 7.2 a flowchart is given to schematize the most important
aspects of the IM process. This paragraph will be followed by the interface identification process (7.3), in
where is described how the interfaces are identified during the project. In interface documentation (7.4) is
described what interface related information should be obtained, how the interfaces will be documented, and
what forms and registers should be used. In paragraph 7.5 several strategies are mentioned to elaborate
complex and high-risk interfaces. Interfaces which are hard to uncouple with the standard forms, or carry a
high risk factor, may carry out one or more of the strategies to come up with a common solution. Paragraph 7.6
describes how the communication procedures look like, while in paragraph 7.7 is explained how to monitor and
control the interfaces. Technical tools which could be used to assist the IM program are handled in paragraph
7.8. As last, a conclusion of this chapter is given (7.10).
7.1
Interface Management set-up
At the start of the project, the foundation for IM should already be implemented. Several studies emphasized
that implementing IM at the early stages of the project will result in higher performance in terms of scope,
time, and schedule (Nooteboom, 2004; Chen, et al. 2007). Therefore, a IM plan should be implemented as early
as possible.
It is important to include all main parties from the start of the project in order to reach consensus about the IM
program. Understanding the importance of the process, as well as a commonly accepted process, is critical to
create a climate in where everyone participates proactively. Once an IM program has been established, the
program ensures all interactions between contractors, related to interfaces, are managed and coordinated
closely. This will avoid issues arising from misunderstandings or lack of information, and will allow decisions to
be made faster and with more clarity. Once alignment has been reached, all agreements and methods related
to IM have to be documented in an Interface Management Plan (IMP), which describes the whole IM process
for the project. Such a IMP describes a clear IM program for the project, which is supported by all stakeholders.
7.1.1
Defining the Interface Management Plan
The implementation of a systematic IM process involves the development of an IMP, which clearly describes
the roles, responsibilities and expectations of both the owner and the contractors. The IPM ensures all parties
understand the IM objectives for the project, and that the right people, processes and tools are in place when
and where needed. An IMP should include:
IM objectives, including interface (management) definitions and goals for the project for all contractors;
Clear roles and responsibilities of all involved parties and project members, including the IM team;
Plan of how to resolve conflicts and overcome barriers to the benefit of all;
Clear description of all communication channels;
Methods and procedures to handle changes;
Clear description of all registers and standard forms which will be used in the project;
65
Ballast Nedam

2014
Plan to define and handle high risk interfaces;

Clear description of all technical tools to be used;
Coordination expectations (e.g. frequency and setup of interface meetings);
Goals and definitions

The IPM will contain clear objectives and goals for the project, and in specific IM. In addition, the definition of
IM and interfaces are defined and a distinction is made in the type of interfaces. Three main categories of
interfaces can be distinguished which are intra-disciplinary, inter-disciplinary and external interfaces. Intradisciplinary interfaces fall under the scope of a single contractor, while inter-disciplinary interfaces exist
between two or more contractors. External interfaces are the interfaces which exist with an object outside the
scope of the project. Within these categories two main types of interfaces can be identified, namely physical
and functional interfaces.
Interface Management team
An interface Manager has to be appointed to lead the IM process. This person, which can be an external
person or a member of the main contractors project team, will be assisted by interface coordinators. These
coordinators are members of the other project teams and will be the single point of contact with authority and
responsibility for their scope of the interfaces. An simplified example of such an IM team can be found in Figure
31.
Figure 31: Interface Management team.
Interface Manager
An Interface Manager has to be appointed for the project, who will have primary responsibility for the whole
scope of IM. The Interface Manager is responsible for the development of the IPM and will carry out and
monitor the whole IM process. The Interface Manager will organize the interface meetings, assist with the
identification of interfaces, generate interface agreements, monitors all project teams to ensure timely
response to requests, assign tasks to team members, and will monitor the status of all interfaces thru to
closure.
Before the tender phase the client could already include an interface manager, or system integrator, to make
sure the exact scope of each contractor is clear and sufficient, and that the responsibilities of the main types of
interfaces are understood and clear. However, after the tender phase this person cannot longer take on the
66
Ballast Nedam

2014
role of interface manager since he or she will be an employee of the client, and therefore cannot have direct
influence in the decision making process of the contractor. This person can take on the role of tester, to verify
the documents of the contractors focusing on the interfaces.
The interface manager during design and construction is usually either an external person, or a member of the
general contractor, and preferably has quite some experience with multidisciplinary projects and IM. In smaller
projects the interface manager could be the project or process manager of the general contractor, which could
manage the interfaces next to his or her other daily tasks. However, in bigger projects it is advised to appoint
one person purely for the management of interfaces. Infrastructure projects are increasing in size as well as
complexity, which leads to more and more interfaces. Due to the complexity and the importance of this role, is
it advised to include the role of interface manager as a standard in such projects. In mega projects it could even
be advised to include two or more interface managers.
Interface managers must have the authority to motivate project teams and get issues resolved early, thus
preventing issues from being ignored or delayed. An interface manager also must have knowledge of project
organizations, leadership skills, and the ability to facilitate and negotiate issues, and usually has accountability
directly to the project manager (Nooteboom, 2004). A dedicated, experienced interface manager can anticipate
difficulties and facilitate rapid conflict resolution. The whole IM team collaborating could help to resolve critical
issues, facilitate timely decisions, and maintain schedules. The process of negotiating among team members
could lead to solutions that may not be everyones first choice, but will be necessary in order to meet the
delivery commitments (Nooteboom, 2004).
Interface coordinator
In order to effectively manage and control the interfaces, an interface coordinator is assigned in the
organization of each contracting party. This person is usually the design leader of that specific project team,
and will be the main contact for the interface manager. The interface coordinators are responsible for the
intra-disciplinary and external interfaces related to their scope, and will communicate with other coordinators
and the interface manager in case of inter-disciplinary interfaces, or other cross-boundary issues. It is
important that everyone knows who the single point of contact regarding the interfaces is. In fact, interface
coordinators are the contact bridge between the other team members of contracting parties, involved in every
interface. All interface communication will go through the interface coordinators of interfacing parties.
The responsibility of reporting any new interface issues rests with the design teams themselves. Designers who
discover any potential interface issue should report this to their interface coordinator, who on his turn will
report it to the interface manager. It is important that all design teams, or at least the coordinators, arrange
meetings on a regular basis. The frequency and main content of these meetings should also be agreed upon,
and documented in the IMP. These meetings will be used to discuss any new interfaces and check the status of
outstanding interface issues. Discussions and collaboration between the teams could enhance the interface
resolution. At the end of the meetings, new agreements will be made between the design teams, in order to
work out the outstanding interfaces.
The amount of responsibility that will be shifted from the interface manager to the interface coordinators
depends on the involvement in, and size of, the project. In general can be said, the more involved a contractor
is in the project, the more responsibility they can and will bear. Small sub-contractors are less likely to take the
initiative to coordinate and collaborate with other contractors. In those cases, the interface coordinators have
to be steered and supervised more closely by the interface manager. Therefore, when defining the roles and
responsibilities, it is also important to take into account the way the several companies are involved in the
project.
67
Ballast Nedam

2014
IM process
When the IM organization and all objectives and definitions are clear, the IM process itself can be defined. All
goals, as described in the IPM, will be met by following the IM program. The process contains of five main
steps, which are the identification, documentation, communication, control and closing of the interfaces:
1.
This phase includes the identification of the interfaces in the project.
2.
During this step, all required interface information is defined and documented. This interface
information includes the interface characteristics, involved parties, deadlines and needed documents.
It is important that everyone understands what to document and how to do it.
3.
Communication and coordination between all involved parties is necessary to successfully work out all
interfaces. In this paragraph the communication and coordination process is elaborated and is
explained how interfaces could be uncoupled, and how the participants should communicate with
each other.
4.
Interface Control
Interface control is necessary to make sure all agreements are met, and ultimately that all objects
meet the interface requirements. This could be seen as the verification phase of the interfaces.
5.
Interface Closing
The interface is considered closed if all involved parties agree on the efficiency, accuracy and
completion of all communicated and documented information and deliverables. However, even after
closure extra attention could be required to make sure all components meet the interface
requirements.
7.2
Flowchart
In this paragraph a flowchart is given of the IM process, as can be seen in Figure 32. Interfaces will be identified
by looking at the contract documents, and the breakdown structures like the SBS, WBS, FBS and RBS. These
interfaces are documented in the Interface Register (IR), in where all related information is described. A
responsibility matrix visualizes all main roles and responsibilities regarding the interfaces. The elaboration of
the interface happens with the help of Interface Agreements (IAs) which are generated by the IM team. The
responsible party requests specific information before a certain due date. The consulted party, which has to
deliver the information, has to approve the agreement. When the agreement is accepted, the consulted party
will provide the deliverables before the agreed due date. The deliverables will be verified by the responsible
party, after which the agreement can be closed. At this point, the design teams of all objects attached can
elaborate the interface solution individually. When the design is finished the design has to be verified, after
which the interface can formally be closed. After this phase, the interface still exists, and could still require
extra attention in later project phases like construction. When this is the case the interface could be attached
to the activities in the WBS, so that this information is known by the construction team.
68
Ballast Nedam

2014
Figure 32: Flowchart of the IM process.
69
Ballast Nedam

2014
7.3
Management of interfaces starts with the identification of the interfaces. The interfaces occur between the
sub-systems and components as described in the SBS. The FBS, RBS and SBS are used as three main
perspectives from which the interfaces could be subtracted. The functional decomposition could reveal
functional interfaces, which might be missed when only considering the objects and requirements. Relations
between the sub-functions could be recognized as functional interfaces. Looking at the requirement
decomposition; all contractors derive the requirements which are related to their scope. Some requirements
have to be fulfilled by multiple parties, leading to a relationship between the contractors which have to be
managed. Think for instance of a requirement for the minimum capacity of a lock. This capacity depends on the
size of the lock, the speed of the lock doors to open and close, the time to fill and empty a lock, and the
reliability and response time of the software used to operate the lock. These aspects are designed by several
parties and all have to be integrated in order to fulfill the underlying requirement.
The most sufficient way to reveal the physical interfaces is to look at the physical decomposition as elaborated
in the SBS. A N-chart, which is a matrix with the sub-systems or components on both axis, could be used as
tool to identify all internal interface possibilities (Prorail and Rijkswaterstaat, 2013). One of the major
advantages of the N-chart is that the developer is encouraged to systematically think about any possible
relationship, between all objects in the system. See the figure below for a simplified example of a small tunnel
for badgers.
Figure 33: N-chart of a tunnel for badgers (Prorail and Rijkswaterstaat, 2013).
The N-chart could entail different levels of detail. The lower the level of detail, the more interfaces will arise
and the bigger the chart will be. A higher breakdown level, like the sub-systems, would allow the N-chart to
have a better overview. However, in practice the decomposition should be implemented to the level at which
the entire system can be managed. It is not advised to work with a higher breakdown level since crucial
information could be lost, and interfaces may be missed. It requires some experience to draw an N-chart and
determine the correct breakdown level so that no critical interfaces are missed. Therefore, it is advised to hold
on to the decompositions as defined in the SBS.
70
Ballast Nedam

2014
At the beginning of the project, when not all detailed components are known yet, the main types of interfaces
between the sub-systems could already be identified. With the help of a N-chart in where all project teams,
and main sub-systems, are placed, all main, high level, interfaces could be identified. A simplified version of
such a N-chart of the Johanfriso Sluis is displayed in Figure 29, on page 56. The different types of interfaces will
help to understand what the main interfaces are, and could assist during the identification of the interfaces
between all objects. As the project progresses, new indentified interfaces could be categorized by the main
interface types, and be placed in the Interface Breakdown Structure (IBS).
All interfaces between the components are identified with the help of a N-chart based on these components.
It is recommended to order the component based N-chart on the contractors involved. By dividing the chart
into the several contractors, the inter- and intra-disciplinary interfaces can be distinguished relatively quick. As
described in chapter 6, especially the inter-disciplinary interfaces are responsible for the current interface
issues. An example of a N-chart, based on the SBS of the Johan Frisosluis in Stavoren, can be found in Figure
34. Each square, or ID-number, will represent an interface between those parts.
Figure 34: Example of a discipline based N-chart.
The colors in the N-chart quickly reveal what parties are involved regarding an interface. Each block shows all
possible interfaces between two contractors. As can be seen in Figure 34, the involvement of four contractors
in the project means there are four possible contractors to have interfaces with. Interfaces between
components of the same company, the intra-disciplinary interfaces, could easily be recognized by color and
should not be covered in the interface meetings. These are the responsibility of the individual contractors, and
will be handled internally.
Next to a division by contractor, the N-chart could also be ordered by components falling under the same subsystem. Because the sub-systems of a project are usually based on physical locations or other strong relations,
most interfaces are likely to fall within the sub-system itself. Especially in larger projects, where the sub-system
is managed by a separate person, it could be sufficient to see what interfaces fall within the sub-system (and
the scope of this manager), and what interfaces exist with other sub-systems. See appendix B for an example of
a sub-system based N-chart. By ordering the N-chart in these two ways, it becomes clear what interfaces fall
within and outside the sub-system, and what interfaces fall inside or outside the scope of the involved
contractors.
The identification of interfaces mainly happens during so called interface meetings. These meetings are
arranged by the interface manager, in where all involved parties are invited. Next to the design teams, also
members of other project disciplines like planning, construction and maintenance should participate in the
process. These interfaces will be identified by all team members of the project, using the design documents,
SBS, FBS, RBS, and all contract documents. If available, interface registers or lessons learned documents of
71
Ballast Nedam

2014
reference projects could be consulted. However, the identification of interfaces is mainly based on the
experience and common knowledge of the project members.
As explained, the earlier interfaces are identified the better. Therefore, the emphasis should be on identifying
all interfaces as soon as possible. The first interface meeting the interface kick-off workshop will be a
workshop in where the majority of interfaces should already be identified and specified. At the workshop all
possible options in the N-chart will be discussed, one by one, to reveal all interfaces. For all the interdisciplinary marks in the matrix, an Interface Register (IR) will be developed in where all interfaces are listed by
ID-number, while all interfaces are also placed in the IBS based on the main types of interfaces. In addition, it is
advised for each contractor to open an additional IR for their intra-disciplinary interfaces.
When all possibilities have been discussed, the majority of interfaces, including their involved contractors,
should be identified. However, as said, the identification of interfaces is a dynamic process. During detailing
more and more interfaces will be revealed. When a project member discovers a new interface, he has to report
this interface to the interface coordinator of his design team. The interface coordinator will consult the
interface manager who will place the interface in the IR. As the project progresses, interface meetings will be
held on a frequent basis to handle new or changed interfaces, and to work out all crucial and outstanding
interfaces.
7.4
Once an interface is identified and approved, the information related to each interface must be defined and
documented. Relevant interface information includes the interface characteristics, involved parties, deadlines
and needed documents. In this chapter is explained what interface related information should be obtained and
how and where this information should be documented.
7.4.1
Registers and forms
Each indentified interface gets an separate ID-number and will be placed in the IBS and IR. In here, all relevant
information about the interface is placed. Interface Agreements (IAs) are used to make formal agreements
about the exchange of information around an interface. Each interface could have multiple IAs. In these
agreements Action Items (AIs) could be submitted which are necessary to elaborate the interface. These AIs,
which are less formal, are small tasks which have to be executed by the responsible person within a certain
time frame. Formal Change Requests (CRs) could be used to propose changes to an interface or IA. As last,
Interface Control Documents (ICDs) could be used for the elaboration of complex interfaces. In these
documents the interface solution is described and elaborated, and a verification plan is included for the
design of all objects attached. Simpler interfaces are only elaborated in the design documents of the SBS
objects itself.
Figure 35: Interface documentation.
72
Ballast Nedam

2014
Interface Register
All interfaces will be placed in an IR. A well-managed IR provides access to up-to-date and accurate
information. Availability of interface information ensures that team members are able to review items more
rigorously, and make decisions quickly and with more accuracy and confidence. The information that needs to
be captured in the IR is the following:
Interface ID:
Interface title:
Interface description:
Type of interface:
Status:
Object IDs:
Objects involved:
Involved contractors:
Interface agreement ID:
Requirement ID:
Responsibility:
Risk:
ID number of the interface;

Interface title;
Short description of the interface;
External, Inter- or Intra-disciplinary;
Open, In progress or Closed;
ID number of the objects attached;
Title of the objects attached;
Name of the parties involved.;
ID number of the Interface Agreements (IAs) attached ;
ID number of the derived requirement;
Name of the responsible interface coordinator/contractor;
Risk factor; high/medium/low.
Table 2: Example of interface register.

Interface Register
ID
Title
Description
Type
Status
Object
ID
Objects
Involved
contractors
Interface
Agreement ID
Req. ID
Resp.
For each interface, a separate page can be added in where additional information, constraints and comments
could be placed. In here also the verification method is described, as well as the document ID-numbers in
where the interface solution and verification of both components is elaborated. More information about the
implementation of the IR and the additional interface pages can be found in Appendix E.
Status
The status of an interface is either open, in progress or closed. When an interface is identified but no
agreements are made yet to elaborate the interface the status will stay on open. The status will change to in
progress when agreements have been made about the interface solution, or the exchange of specific interface
information, including clear responsibilities and due dates. The status will change to closed at the moment the
interface solution has been verified for both components attached, as well as the integrated part. During
fabrication and construction the interface still exist, but the closed status indicates the interface has been
taken care off in the design of all objects attached. The interface manager will monitor all interfaces and when
the design of an object changes, after the settlement of an interface, the status could be changed back to
`Open` or `In progress`.
Interface requirements
For simple interfaces an interface requirement could be derived. Especially when this part of the project will be
outsourced to a sub-contractor. For each interface maximum one requirement could be derived and listed in
the RBS. More requirements could lead to confusion and conflicting requirements. By deriving a SMART
requirement of the interface solution, the interface is uncoupled. Think for instance of a wall and cables which
73
Ballast Nedam
Risk

2014
both have to placed parallel to a road. Contractor A could be assigned to place the wall between 3 and 4 meter
from the road, while contractor B has to place his cables between 1 and 3 meter from the road. By adding
these requirements to the component specifications, the interface is uncoupled for both parties.
Risk
The importance of an interface depends on the risks attached. Interfaces represent risk to the project, some
more than others. The interface coordinators must work with their project team to identify interfaces they feel
represent high-risk, and add additional management and oversight where necessary. In paragraph 7.4.3 is
described what factors should be taken into account by the assessment of an interface risk. Afterwards, in
paragraph 7.5, several strategies are proposed to uncouple these high-risk, and often complex, interfaces.
Interface Agreements
IAs are used to document and track the exchange of information and other deliverables between the
contracting parties in a project. IAs result in the exchange of project information generated by one party, that is
needed by another party to continue with its scheduled project tasks. This project information could be
delivered in the form of engineering drawings, specifications, design reports and calculations, equipment
details, project schedule information, etc.
These forms will only be used for inter-disciplinary and external interfaces. An IA is a formal form which
documents the exchange of information and deliverables, which are measurable and bound by a time frame,
between two parties. The deliverable is acknowledged and agreed upon by two contracting parties, both a
requester and a responder. During project execution contractors could be either requester or responder,
depending on their responsibility to the interface. In an IA the following information is provided:
Contracting parties, participants and their roles;

Attached interface and objects;
Required information or deliverable(s);
Responding document(s);
Action items;
Need date of the agreement;
Finish date when the interface conditions have been met.
In short, the requester fills in an IA form and requests for the delivery of specific interface information within a
certain time frame from another contractor. The responder has to sign this agreement if the requirements can
be met, which makes the agreement formal and frozen. When the delivery date cannot be met, a delivery date,
different from the request date, could be proposed. When consensus between the contractors cannot be
reached easily, the interface can be flagged as high-risk and/or the status may stay on open, which means the
interface will be discussed in the upcoming interface meeting.
Action items
Each IA could have several AIs. These actions are small tasks which have to be executed in order to fulfill the
agreement. An example of an action could be look up the required free space for maintenance of pipe Z, in
Manual X. These action are less formal than IAs, are much shorter in duration, and are designated to a single
project member who has to fulfill this action within a certain timeframe.
74
Ballast Nedam

2014
Change Requests
When an agreement has been reached the agreement is formally frozen, which means a baseline has been
formed. If after this phase modifications in the design are needed to any of the attached objects, or due dates
cannot be met, a formal change request has to be filled in. The configuration management team assesses all
proposed changes and monitors the projects overall progress. Before the design, or an agreement, can be
modified, first all consequences for all involved parties and possible options have to be explored.
Interface Control Document
ICDS could be used as extra document for the elaboration of complex interfaces. In this document both parties
could work on the interface solution, document all interface characteristics, and describe the process which led
to the interface solution. In addition, a verification plan should be added to verify the developed solution.
7.4.2
Interface Responsibilities
One of the major causes of integration issues is the lack of awareness about the ownership and responsibilities
regarding the interfaces. In the IAs is specified what specific information has to be exchanged, and what the
roles and responsibilities of all interacting parties are. However, before an IA can be developed it has to be
clear who the responder and who the requester is regarding the information.
A responsibility matrix, like the RASCI-matrix, could be used to visualize the roles and responsibilities belonging
to each interface (Rose, 2008). By using this matrix the responsibilities of the interconnecting parties involved
in the execution of the interface are identified. RASCI stands for Responsible, Accountable, Support, Consulted
and Informed, respectively. The description of roles for the interface execution is as follows:
Responsible:
Accountable:
Supportive:
Consulted:
Informed:
The party responsible for the interface overall performance, and approves the
accuracy of interface characteristics (i.e. the requester of interface information or
deliverables).
The party, who generates the IA, and has the legitimate authority to approve the
adequacy of the work, and makes the final decision to close an agreement.
The party who gives support to facilitate the process accomplishment (e.g. the party
who may have to grant the other parties access to the site).
The party who responds to the IAs and provides the deliverables.
The parties who need to know the status of the IA, in order to help them better
schedule their own work or the work of others.
The purpose of using RASCI matrix is reducing risk by increasing the visibility, and eliminating ambiguity about
the roles and responsibilities regarding the execution of each interface. A sample of a RASCI-chart is shown in
Table 3. The left column includes interface IDs, and the top row includes all the project members/contractors
who may be involved in an interface. The cross-sectional cells indicate the responsibility of each party
regarding an each interface, if there is a relationship.
Table 3: Sample of RASCI-Chart
Owner
Interface
Manager
RV1
R
A
RV2
A, S
RV3
I
A
RVi
S
A
75
Contractor A
Contractor B
S, C
R
R
Contractor i
C
C
I
Ballast Nedam

2014
Leading versus intersecting objects

In order to assist in filling in the IAs and RASCI-chart, and to determine which party is the requester and which
the responder, one could look at the interacting objects. It is often possible to make one object leading and
the attached object intersecting regarding an interface. It could be agreed that an intersecting object must
follow the design of the leading object. The designer of the leading object, in this case, will be the responder in
the IA. In other words, the designer of the intersecting object requests information from the leading objects
designer.
Looking at the type of dependency, it becomes clear that two objects, involved in an interface, could be oneway dependent or interdependent. One-way dependency means one of the objects is dependent on the other,
but not the other way around. For these interfaces, which can be determined by experience and intuition, is it
self-evident which object is leading. Think, for instance, of a road sign which has to be placed on a bridge. If
the design of the bridge changes, the place and details of the road sing could change as well. However, it will
not be the other way around. The leading object has to provide the intersecting object with information.
Unfortunately, many objects have a strong interdependent character which means the objects are both
depending on the design of each other, and cannot be uncoupled that easily. Making a choice whether an
object is intersecting or leading regarding an interface is therefore not always as easy to make. These objects
usually need multiple iterations in their design to come up with a sufficient design for both sides. Especially in
these cases confusion easily arises about the roles and responsibilities regarding the interface. Think, for
instance, of a concrete basement and equipment which have to be placed within. Will the size of the basement
determine the type and exact dimensions of the equipment, or is it the other way around?
Aspects like local lifecycle costs, critical objects and design planning could assist in appointing the roles
regarding an interface. Looking at the local lifecycle costs one could look at the costs attached to the objects,
and the costs to make modifications to the design. The party responsible for the more expensive object could
be made leading. In that case this party will have the privilege to determine the exact parameters of the design
related to that interface (within the solutions space of the requester).
Another method to assist in determine the leading objects is to look out for critical objects. Once the
interfaces have been located, it is often possible to determine these critical objects. Looking at the N-chart, it
becomes obvious some objects have more interfaces than others. An object which has relatively many
interfaces with other objects could be stated as critical. It is advised to make those objects leading in their
interfaces with other objects when possible. This means the design team of that object is the provider
concerning those IAs, and will be consulted party.
The leading coordinator of critical objects has to take into account that one IA could have consequences for
another. Coordinators have to look closely at all interfacing partners, and check what interfaces are the most
important and have to be worked out first. By being the responder the design team can closely monitor the
dependencies of all outstanding interfaces of the object.
As last, the design planning could play a role in assigning the main roles concerning an IA. When discussing the
interfaces it could become clear that two design teams, which have an interface, design their objects at
different points in time. These differences are mainly due to construction constraints. In these cases, it is
advised to make the object which is designed first the responder of the interface information, where possible.
The main reason for the distinction in leading and intersecting objects is to reach clear and unequivocal
agreements between parties. In the case an object cannot be made leading or intersecting, it usually means
76
Ballast Nedam

2014
the objects have a strong interdependent character, and therefore need a lot information from one another.
When no consensus can be reached about the direction of the flow of information, the content of this
information, or the due date this information has to be delivered, an IA cannot be developed. When it is not
possible to uncouple an interface with an IA, the interface will keep the status open and could be flagged as
medium or high risk. This interface will then be discussed again in the next interface meeting, in where
consensus has to be reached. Strategies to assist in the elaboration of these complex interface are discussed in
chapter 7.5.
7.4.3
Interface risk assessment
In general, interfaces represent risk to the project. However, some carry more risk than others. Only the
interfaces which contain a high risk for the project, and therefore, have a high potential to cause delays or
additional costs, require close coordination, control and management. Extensively document and manage
every single interface should be avoided, as it would cause the system to quickly become overburdened with
information.
With hundreds of interfaces which have to be managed, how can these be differentiated from one another?
How to ensure the right interfaces are monitored at the right time? In managing interfaces the Pareto-principle
applies, which means 80% of the problems are caused by 20% of the interfaces (Varghese and Senthilkumar,
2010). Therefore, it is important the IM team takes proactive measures to identify these problematic interfaces
as early as possible, and to keep track of the information exchanges at these interfaces. Interface coordinators
must work with their team to identify interfaces they feel represent high-risk. In addition, it is important that
an interface can be flagged as high or low risk at any given moment. Some interfaces carry no risk at the
beginning of the project, but could become problematic during the course of the project. When a risk is
recognized by a design team, it should immediately be flagged as such. This ensures that all involved parties
become aware of this risk instantly, and can give the interface the attention it requires.
Types of interface risk
Basically three main types of risks can be distinguished which are financial, schedule and performance risk.
Schedule risks are those risks associated with the adequacy of the time estimated and allocated for the design
and construction activities of the project. Financial risk is the risk associated with the ability of the project to
achieve its life-cycle cost objectives. As last, performance risk is the risk associated with the evolution of the
design affecting the level of performance, necessary to meet the stakeholder expectations and technical
requirements.
Schedule risk
When objects are dependent, it means one object needs information from another, in order to continue with
its design. However, when this information is not known in time conflicts could arise. If, for instance, the EE
needs to put his cables through a concrete wall, the CE has to know the exact location and dimensions of these
cables. Issues with this interface often occur in infrastructure projects. The EE does not know exactly where his
cables will go through at the time the CE wants to know this information.
Therefore, most of these schedule risks can already be identified during the preparation of the IAs. In the early
workshops most interfaces and required information have been identified. In here, consensus has to be
reached about the content, direction of flow and delivery dates of that information. The requester asks for
interface information within a certain time frame. When the responder cannot deliver this information within
that time frame delays could occur. The interface could be flagged as high or medium risk and will be discussed
77
Ballast Nedam

2014
in the upcoming interface meeting. Some interfaces may have a major impact on the critical path when their
deadlines are not met. These interfaces should be monitored closely to make sure no delays occur.
Financial Risk
Financial risk could be identified by exploring the consequences if an interface is not worked out well. Objects
of which high costs are attached when the interface is not elaborated well, could be flagged as high-risk. This
could be the case when the attached objects, or potential rework, is relatively expensive. Take for instance a
lock head which appears to be too big for the lock head. These gates are expensive, and take a long time to
produce. This interface could contain high risks for both schedule and costs.
Performance risk
Interfaces could have a performance risk when the objects attached are, for instance, technically hard to
elaborate. These risks could occur in the design process as well as in the construction, operation or maintain
phase. These risks could occur when errors are easy to make, and have relatively large consequences.
Factors influencing risk factor
Assessing interfaces as risk is an subjective task , which is mainly based on experience. Unfortunately, it is often
not as clear whether an interface has a high risk factor, and is it hard to make a thought-out decision.
Therefore, two aspects are indentified which should be take into account when assessing an interface risk.
These factors are the rate of dependency, including the rate of sensitivity and evolution, as well as the rate of
predictability of the interface information.
Rate of dependency
The degree of dependency can often be determined by the rate of upstream task evolution and downstream
task sensitivity (Pena-More, et al. 2001). The rate of evolution describes the rate at which design information is
generated from the start of an activity through the completion of the activity, where the rate of sensitivity is an
indication of how sensitive downstream tasks are to changes in an upstream activity (Eppinger, 1994). Highly
sensitive interface information is more likely to cause integration issues since the information is sensitive to
changes in upstream activities. Also external dependencies could be recognized as higher risk, since the
delivery of crucial information is out of the control of the project team.
Rate of predictability
The rate of predictability indicates whether specific interface information can be predicted within a certain
margin before the activity is finished. Because of the fact that engineering disciplines design their objects at
different points in time, is it often hard to meet the due dates of the required interface information. Instead of
waiting until the information is available, also a prediction can be made. As explained, activities with a slow
rate of evolution cannot deliver the design information before the activity is as good as finished. However,
sometimes the information could be predicted. By predicting this information the design team can finish their
design based on these assumptions, instead of having to wait on the information. A low rate of predictability
brings along extra risk when information is predicted.
When assessing an interface on the risks attached, is it important to think of the possible consequences if an
interface is not elaborated well, which could have an impact on time, costs and quality. The likelihood of an
interface occurring of an interface is hard to determine. An interface is identified, and the chance that the
interface is not elaborated well, or that crucial design information is going to change, is not as easy to predict.
78
Ballast Nedam

2014
However, the rate of sensitivity says something about how sensitive design information is for changes. Highly
sensitive interface information has therefore a higher likelihood for the risk to occur.
7.4.4
Conclusion
The IR, IAs, AIs, CRs, and ICDs are the main methods used for the documentation of interface information. If
consequently used, these registers and forms will contribute to diminish communication and coordination
issues. IAs are practically effective when the due dates are realistically planned, tracked, executed and closed
without slippages on progress for the intended purpose, scope and objective. Users will have a clear
understanding of what is expected, and know what needs to be communicated, when and with whom.
Templates for Interfaces, IAs and CRs could help to provide continuity and clarity to the process. An example of
such templates is provided in Appendix E.
In order to create an IA one party has to be the responder while the other has to be the requester related to
the interface information. A responsibility matrix, like the RASCI-matrix, could be used to visualize the roles and
responsibilities belonging to each interface. When disagreement arises regarding the responder and requester
one could look at which of the attaching objects is leading and which is intersecting. Aspects like local lifecycle
costs, critical objects and design planning could assist in making this decision.
For each interface should also be assessed what the risk of the interface is for the project. Three types of risk
could be distinguished which are schedule, financial and performance risk. When assessing an interface on risk
one should mainly look at the consequences, and take into account the rate of dependency and predictability
of the interface information. When information is highly dependent and sensitive to changes in an upstream
activity, a higher likelihood for risk occurs. In addition, a low rate of predictability brings along extra risk when
information is predicted.
7.5
Management of high-risk and complex interfaces
In the cases when it is not possible to develop an IA between the parties, to derive a requirement directly from
the interface, or when the interface is flagged as high risk, other strategies could assist in the elaboration of the
interface. In chapter 4 several strategies have been proposed. These strategies could be applied to work out
complex and high-risk interfaces.
Re-sequencing design activities
One of the most practical strategies is re-sequencing design activities. When the design for two interfacing
objects is scheduled at different points in time it should be tried to re-sequence the design activities and pull
one of the objects forward so that both objects can be worked on at the same time. Interfaces with high risks
should also be pulled forward in the design process, just like is currently done with components which have to
be finished earlier due to construction constraints. This way the planning could be changed so that complex
components with high interface risks are designed at the same time, preferably at the same physical location,
in an early phase of the design. This will make it easier to coordinate and to exchange specific information. In
addition, by pulling the involved objects forward in the design process more time is available for the
elaboration of that interface.
It should be explored what consequences pulling the objects forward have on the predecessor and successor
activities. Choosing a design solution could be based on assumptions which lead to constraints on the
predecessor activities. However, by elaborating the high risk interfaces earlier in the design process potential
delays and costs could be prevented in the long run. By freezing the design, modifications to the design will
only be possible after formal change requests, when all consequences have been evaluated. This will lead to
less unnecessary design iterations.
79
Ballast Nedam

2014
Reorganizing strategies
The exchange of information, as well as the collaboration and coordination, is much more fluent when both
parties are working on the interface solution at the same point in time. Reorganizing strategies as forming cross
functional teams, using team problem solving and sharing ranges of acceptable solutions, are good strategies
to further assist in the elaboration of complex interfaces. These strategies focus on collaboratively finding a
solution and speed up the process.
Predicting interface information
When it is not possible to re-sequence the design activities in order to let them overlap, other strategies could
be applied. When the interface information is not sensitive, and is quite easy to predict, assumptions could be
made about the parameters. The latter design team could make accurate assumptions about the interface
parameters, which could help the former team to finish their design. The risk of predicting this information
should be looked into carefully. When design team decides to wait delays could occur, while starting without
this information could be very risky. However, prediction of interface information could bring along extra risk in
case the assumptions fall out to be false. Therefore, before making assumptions about interface information,
next to the rate of sensitivity, evolution and predictability of the information also the potential consequences
should be carefully explored
Overdesign
A last strategy is overdesign. Overdesign could be implemented in order to continue with successor activities
when there are time constraints, and no of the above strategies is sufficient. Overdesign could also be applied
when information is based on assumptions, in order to reduce the risks of potential rework. By overdesign, a
buffer is created which makes the accuracy of the predicted parameters of the latter design team of less
importance. Overdesign brings along extra costs but could reduce or prevent the risk of rework in the end.
Therefore, the costs, benefits and risks of applying overdesign should be explored carefully before
implementing this strategy.
7.6
An important component of any IM program is to plan how the communication will be conducted between all
parties. Everyone must know what information to communicate, how to communicate this information, and
when to communicate it. Especially in construction projects that involve multiple parties, all working from
different locations, is effective communication essential. Clear, timely, accurate and consistent communication
should be promoted in order to reduce risk and encourage collaboration between the several parties.
Projects consist of a mix of both informal and formal forms of communication. Informal communication results
from efforts to bridge team gaps and ensure shared project scope and interface interpretations. Formal
communication results from a communication plan designed at the early design phase, and documented in the
IMP. This communication plan has to be created to accompany the projects IM program for how contractors
will communicate with each other, and how conflict will be resolved. Most important methods to communicate
are:
Electronic communication and face-to-face meetings;

Automated processes, forms, registers and tools;
Alerts and Notifications;
Reports and drawings.
80
Ballast Nedam

2014
Face-to-face meetings
All interfaces will be discussed during the interface meetings. In these face-to-face meetings, which are held on
a regular basis, the details, status, progress and possible agreements are discussed with all involved parties.
Further face-to-face communication will mainly go through the member of the IM team.
In case of conflicts, the interface manager and interface coordinators will communicate with each other, faceto-face. Interface managers must have the authority to motivate project teams and get issues resolved early,
thus preventing issues from being ignored or delayed. When conflicts arise the IM team is responsible to
engage a conversation between the involved parties, in where the interface manager will have the authority to
make decisions in the interest of the project. IM personnel can help resolve critical issues, facilitate timely
decisions, and maintain schedules. This negotiation process among teams occasionally results in solutions that
may not be universally appreciated but are necessary to meet delivery commitments.
Forms, registers and tools
The IR is used to communicate the existence and specifications like status and risk factor of all identified
interfaces. This IR is dynamic in nature, and could be adapted at any time by the IM team. The main roles and
responsibilities of each contractor regarding interfaces are communicated by a RASCI-chart. In this chart, for
each interface multiple roles and responsibilities can be assigned. The N-chart is used to communicate all high
risk, new and open interfaces to all stakeholders. This chart visualizes what interfaces need extra attention, in
real time, and forms the basis for the upcoming interface meeting.
Main formal forms to communicate interface related information with, are the IAs, and CRs. The IA is used to
request specific interface information and deliverables. The responder may communicate in several ways, but
the most convenient way is by specific drawings and reports. CRs are the formal way to communicate a request
to change an existing interface or IA. The Configuration Management (CM) team is responsible for controlling,
approving and rejecting changes during the design and construction phases of the project. More about CM can
be found in the next chapter.
The progress of the interfaces, and the exchange of interface information, have to be monitored to ensure each
party receives the requested information in a timely manner. The communication will mainly happen through
the IR, IA register, and AI register, in where the progress can be monitored by the IM team by looking at the
due dates. The N-chart, and the integration of high risk interfaces as milestone activities in the project
schedules, are used as extra method to communicate and monitor the most important interfaces to all project
members.
Technical tools play an important role in the communication procedure as well. These tools will be discussed in
paragraph 7.8. In short, communication through spreadsheets, excel, e-mail and phone is not recommended.
All ways of communication are accepted as support, but all formal communication have to go through the
tools, forms and registers as defined in the communication plan. Tools and templates encourage automated
processes, and leave less room for errors.
Alerts and Notifications
The IM team should notify the responder if IAs or AIs are over due date, and have to find a common solution.
Automated work processes could ease this process by flagging overdue activities and sending electronic
notifications and reminders to the involved parties. The interface manager is in charge of the progress and is
responsible to act when issues arise.
81
Ballast Nedam

2014
Reports and drawings
Reports and drawings are used to communicate the design solution to the construction team and main
stakeholders. Each object in the SBS contains a separate design document, which has to be sent to the client
and construction teams.
Conclusion
A communication plan has to be created in the early design phase to accompany the projects IM program. In
here should be stated how contractors will communicate with each other, and how conflicts will be resolved.
Participants should understand what information to communicate, how to communicate, and when to
communicate. Especially in construction projects that involve multiple parties, which all work from different
locations, is effective communication essential. Automated processes, forms, registers, electronic
communication, face-to-face meetings, alerts, notifications, reports and drawings could all be used as way to
communicate.
All interface face-to-face communication will go through the interface coordinators and ultimately the interface
manager. Most of the face-to-face communication between during the project teams will occur during the
interface meetings. In case of conflicts, the interface manager and interface coordinators will communicate
with each other, face-to-face, in order to come up with a common solution.
The IR is used to communicate the existence and specifications like status and risk factor of all identified
interfaces. Next to the IR, also the N-chart is used to communicate all high risk, new and open interfaces to all
stakeholders. Next to the IR, formal forms like the IAs and CRs, as well as the IA register are all used to
communicate interface related information with.
7.7
Interface Control
Monitor and control of the interfaces is necessary to keep an eye on the overall progress, to prevent and solve
integration issues, and to verify the design solutions during the whole project lifecycle. The IM team is
responsible for monitoring the interface data as stated in the IR, including the corresponding IA due dates. The
IM team should organize regular and ad-hoc interface meetings, in where the progress of all high risk and open
interfaces is discussed.
The IR, IA register and AI register are used to monitor all interfaces. IAs and AIs which are close to their due
date could receive a electric notification of alert. All involved parties should be aware of the work load,
progress and potential issues (e.g., deliverables are delayed or contractors are not communicating). During the
project it is important that all information is easily accessible. The registers and reports should provide the
project team with the data they need to continually monitor the progress.
The client and interfacing parties should be warned in case of a forecasted delay or any other interface related
issue. In addition, the IM team is also responsible for the verification of both components regarding the
interface solution. The design should meet the interface requirements, before an interface can be closed. Next
to the IM team, also the CM team, project planning, and the risk management department are involved in the
elaboration of interfaces, and play a major role in monitoring and control these interfaces.
7.7.1
Configuration Management
CM is a management discipline, applied over the products life cycle, that controls and monitors changes which
could affect performance, functional or physical characteristics. The CM team is responsible for the
82
Ballast Nedam

2014
management and control of the overall progress of the project by controlling, approving and rejecting changes
during the design and construction phases of the project. Under the scope of CM falls document management,
baseline control and change management.
Document management
Under the principle of CM, all documents generated within a project are closely managed, tracked, and
archived. The process includes tracking and archiving all document changes, versions, and approved
communications, which is necessary to avoid the inclusion of document changes without following a formal
document approval process (PACO, 2010).
Baseline control
The CM team defines multiple milestones in advance, for each subsystem. These milestones in design have to
be achieved after which the design will be frozen. Next to these defined milestones, the design will also be
frozen after each formal design step (i.e. after the conceptual, preliminary and detailed design phase). The IAs,
with due dates for the delivery of interface information, are also frozen in order to meet the deadline of the
interface milestones. These (frozen) moments are called baselines.
CM gives insight in the differences in level of development between the several sub-systems, and what
consequences these differences have. When one sub-system proceeds to the detailed design phase while
another sub-system is still at conceptual design, huge problems could occur if their interfaces are not worked
out well. The CM team monitors and steers this process where necessary.
Change management
Changes are and will continue to be an inevitable part of the design and construction of any project.
Throughout the design phase, interface baselines are controlled to ensure that changes in the design of
components have minimal impact on other components with which they interface. Formal CRs could be
submitted in order to adapt the design of an object, or agreement, which have been frozen. CRs also have to be
submitted to adapt the content or due date of an IA. Changes could be proposed to optimize the design, but
could also be the results of incompatibilities, external changes, or unexpected design deficiencies.
Configuration control maintains integrity by facilitating approved changes and preventing the incorporation of
unapproved changes into the items under configuration control.
The CM section has to study the consequences of such a change and will approve or reject the request. In here,
it is important to consider both the consequences of the change, as well as the impact of not making the
change, especially as the system matures. The effort and cost associated with accommodating changes
increases rapidly as the design matures. The critical objects require extra attention since these objects have
lots of interfaces. Modifications of a design leading to changes in a critical object could lead to a ripple effect,
affecting more and more objects.
7.7.2
Risk management
High risk interfaces, or crucial interfaces, should be easy to track and control throughout the entire project
lifecycle. As described in paragraph 7.3 is the N-chart a convenient tool to capture all interfaces. However,
cluttered and chaotic matrices should be avoided. Therefore, in order to prevent the N-chart for becoming
confusing and unclear, the amount of interfaces has to be controlled. In order to reduce the amount of
interfaces, without changing the level of decomposition, only those interfaces which require extra attention
should be put in the N-matrix. A traffic light system could be used to manage and report the critical nature of
83
Ballast Nedam

2014
interfaces. Green indicates everything goes well and that the interface is on target for the completion date.
New and open interfaces could be made green when agreements have been made regarding this interface.
Yellow indicates there are some concerns and issues that need to be addressed, while red indicates major
issues and high risk of not achieving. A colored system is visually strong and can be used as a reporting tool to
management and stakeholders, for an impression see Figure 36.
SBS 1100 1200 1300 1400
1100
1200
1300
1400
1510
1.8
1.11
1520
1.14
2111
2112
2113
6.5
2121 1.4
2131
5.1
2132
3.8
2133
3.3
1510
1520
2111
2112
2113
2121
2131
2132
2133
2.1
17.1
Figure 36: Impression of a N-chart with high-risk interfaces
The IR provides the ability to flag interfaces as high risk and revert back to low risk at any given moment. An
interface which does not represents risk during one phase of the project, may do so during another phase. On a
frequent basis (e.g. every two weeks), the chart will be updated with additional high-risk interfaces, and all
open and new interfaces which have been addressed could be removed.
All high risk interfaces should also be included in the risk register, in where the risk managers will threat the risk
as any other. This means the risk will get a quantification, and in consequence prevention measures will be
explored, as well as mitigation strategies. Risk mitigation is very important and without reporting high risk
interfaces, the risk manager is potentially making decisions without the complete picture.
7.7.3
Project planning
When the most crucial interfaces have been identified, extra control is needed to prevent potential issues with
these interfaces. An interface delay could impact a critical path activity in the overall project schedule, leading
to a delay of the project. Therefore, next to the visualization of all high risk interfaces in the N-chart, also the
schedule impact of these interfaces have to be monitored systematically by all stakeholders. Each project
stakeholder should be able to integrate high risk interfaces, as managed in the IM system, as key milestone
activities within its respective organizations project schedule.
In Figure 37, the process of schedule integration is simplified by three main aspects which are the interface
register, the N-chart and the project and discipline design programmes. In the IR all interfaces are displayed.
The interfaces which are flagged as high risk are transferred to the N-chart, in where they become easily
visibile for all stakeholders. For each high risk interface a milestone activity is established, which will be
integrated in the project and discipline desing programmes. This is a dynamic process since the high risk
interfaces can be flagged at any time of the project life-cycle. Regurarly the project schedules will be updated
by the newest updates of the IM system.
84
Ballast Nedam

2014
Figure 37: Integration of project schedule with interface milestones
The integration of the project schedule with the interface milestones will add transparency to the process and
increases the visibility of important interface due dates. As part of the project planners regular analysis of the
critical path, any impact caused by an interface, or impacting an interface is identified, assessed and reported
back to the interface coordinator. The interface coordinator on his turn must evaluate options to avoid or
mitigate the schedule impact of that specific interface within their project schedule. The project planner and
interface manager collaborating facilitates that all impacts on the project schedule caused by an interface, or
impacting an interface, will be monitored and controlled. Properly executed, schedule integration ensures that
interface related schedule risk can more easily be identified by each contractor and the project owner, and that
an efficient process exists to resolve interface related schedule issues.
7.7.4
Verification
As part of interface control, the design of all components related to an interface, have to be verified. During
validation and verification activities, multiple components are checked out as integrated subsystems or system.
For each interface, both the components attached to that interface, as well as the integrated system, have to
be verified before an interface can be closed.
Physical interfaces could be verified by checking the design drawings on inconsistencies. Clash detection
software in 3D modeling programs could be used to automate and ease that process. When this software is not
available, drawings could be checked manually on inconsistencies. Preferably, the verification method is
already be agreed upon at the moment an interface is set-up, to avoid confusion about it in later phases.
Functional interfaces and more complex interfaces cannot always be verified by checking drawings on
inconsistencies. The involved parties should discuss the verification method in advance. Depending on the
interface, a separate verification plan could be developed which could include calculations, tests, drawing,
prototypes, reports, etc. It should be clear who is responsible for the elaboration of what part of the interface,
how both parts will be verified, how the integrated (sub-)system will be verified, and, as last, by who and when
the interface will be verified.
The elaboration of an interface, including the verification plan, could be documented in a ICD, but may also be
included in the design documents. The ICD or design documents show the specific solution to an interface, of
both sides, and entail the verification details. The ICD and other verification documents can be communicated
to the owner, or other key stakeholders, if necessary. When the interface is complete, the interface manager
can close this interface in the IR. The interface manager is the only person who can adapt the status of
interfaces in the IR.
7.7.5
Conclusion
Monitor and control of the interfaces is necessary to keep an eye on the overall progress, to verify the design
solutions, and to prevent and solve integration issues during the whole project lifecycle. The IM team is
85
Ballast Nedam

2014
responsible for monitoring the interface data as stated in the IR, including the corresponding IA due dates.
They should organize regular and ad-hoc interface meetings, in where the progress of all high risk and open
interfaces is discussed. The IM team is also responsible for the verification of the interface solution. It should
be clear how both components will be verified, how the integrated sub-system will be verified, and, as last, by
who and when the interface will be verified.
The CM team is responsible for the management and control of the overall progress of the project by
controlling, approving and rejecting changes during the design and construction phases of the project. The CM
team also defines multiple milestones in advance, for each subsystem, and gives insight in the differences in
level of development between the several sub-systems, and reveal what consequences these differences have.
All high risk interfaces are visualized in the N-chart by a traffic light system. All these interfaces will be included
in the risk register, in where the interface is monitored and controlled by the risk manager. In addition, the
schedule impact of these interfaces have to be monitored systematically. For each high risk interface a
milestone activity could be established, which will be integrated in the project and discipline desing
programmes, and monitored and controlled by the project planners.
7.8
Interface Management Tools
The IM process has to contain of technical or engineering aspects (appropriate tools and methods) as well as
organizational design and soft management aspects. Tools alone, without the foundation of a well-structured
process, will not have the intended effect. On the other hand, a well structured process without tools to
support the method is hard to maintain, and is sensitive for errors. Therefore, both technical and organizational
aspects have to be combined in the IM program in order to cover all aspects of IM. In the previous chapters the
organizational aspects have been widely discussed. In this chapter, several tools are mentioned to assist in this
process.
To support an IM program, a collaborative solution with the ability to manage thousands of interfaces and
interactions between parties is essential. Using the right tools can make or break the IM process, and therefore
communication through a combination of Excel spreadsheets and e-mail is asking for trouble. Traditional
databases, spreadsheets and paper-based IM systems limit the efficiency of contractor interactions, and the
oversight of interface issues. Those methods increase the risk of losing data, deadlines not being met and
information not getting to the right individuals. At best, they allow rushed collaboration between interface
coordinators, but not across the scopes of work under their management.
IM is inseparably linked to a correct and efficient flow of information. Therefore, it is important this
information is delivered efficiently to all involved parties, at the right time. Tools like a Document Management
System (DMS) and Building Information Modeling (BIM) software could assist in here. For the management of
interfaces itself Relatics is currently used. Modifications to the IM process, as described in the previous
chapters, could be implemented in Relatics. However, also a specialized IM tool could be developed or
purchased which could automate the processes to a certain degree.
7.8.1
A DMS has to be used for the storage of all reports, drawings and documents in the project. The DMS should be
a system in where all relevant, interface related, documents are stored, and which is accessible by all involved
stakeholders, at all times. Having one DMS for all stakeholders, prevents information to get lost, and
misunderstandings about specific information.
86
Ballast Nedam

2014
Interface related documents which should be stored in the DMS are, among others, a copy of the IMP, records
of the interface meetings, current version of the N2-chart and RASCI-chart, ICDS, verification plans and design
documents. IM document control requirements include document revisions, unique document numbering
schema, as well as the ability to manage interfaces as controlled documents, that become part of the project
handover package at project close out.
7.8.2
Interface Management Tool
Next to a DMS in where all documents could be placed, also a collaborative platform should be used to support
the implementation of the IM process. This platform should be able to align all interface processes, and provide
a place which encourages coordination and clear communication between all involved parties.
Relatics
RMT Relatics is currently used as main software for the management of interfaces at Ballast Nedam, and many
other construction firms. With Relatics, all dependencies within a project can be visualized. According to the
developers of Relatics, the program is used to manage the requirements, tests, risks, tasks and all other project
objects in a coherent network of explicitly described information. It enables users to store all kinds of project
objects and integrate them in a meaningful way (PKM Solutions, 2013). In Figure 24, on page 45, the basic
structure of Relatics is displayed. As said, it is possible to adapt this structure to the project needs. The circles
indicate entities, which are among others requirements, objects, persons and activities while the relations are
indicated by arrows.
All breakdown structures, like the FBS, SBS, RBS, WBS and OBS, should be listed in Relatics, and have to be
combined to each other. By doing so, clicking on an object will show all specifications like the underlying and
parent objects, functions it fulfills, design and construct activities which are attached to the object, all
requirements which have to be met, and all risks and interfaces which have to be taken care off. When clicking
on the interface ID-number, all interface related information will be displayed.
See Appendix D and E for templates of all main registers and forms, and to get an impression of how all these
elements have to be integrated in Relatics.
Automated processes
Relatics offers an extremely flexible architecture that can constant be tailored to the project needs. While
project members continue their work, Relatics offers the possibility to change the project objects that need to
be managed, or to create extra reports that offer better insight (PKM Solutions, 2013). However, Relatics does
not entail automated processes. Automated processes in handling interfaces could further improve the IM
process.
Automated processes offer the means to control delivery of tasks to the right individuals, and send
notifications and alerts as required. Furthermore, electronic documents could automatically link all items in the
database. The many benefits of workflow automation include:
Increased consistency and less errors:

Standard forms reduce the potential for errors and ensure consistency.
Increased efficiency:
Automation of processes results in the elimination of many unnecessary steps, information is delivered to
the right individuals at the right time so that they can make the right decisions.
87
Ballast Nedam

2014
Better process control:

Improved management of processes achieved through standardizing working methods.
Consistent communication:
Notify key stakeholders if information related to an interface changes, send alerts on upcoming
deliverables and items which are overdue, and ensure the timely acceptance of requests and responses.
Evaluation of the DIMS tool, as described in Appendix F, concluded that the alert mechanisms, which
periodically notified specific individuals about their information requirements to meet the approaching
deadlines, played a significant role in eliminating delays in their project. On the market several ready-to-use IM
tools are available. Coreworx, for instance, offers an IM program which helps to manage projects interfaces
securely, quickly, and effectively (Coreworx, 2014). Profession IM tools like the Coreworx IM program provide
a platform which is purely focused on the documentation, management and control of interfaces, and
therefore provide a solution which is much more efficient than Relatics.
7.8.3
Building Information Modeling
Building Information Modeling (BIM) programs could be of huge assistance in infrastructure project
development. 3D geometry and supporting software (like for instance MX or Civil) are of invaluable assistance
when managing interfaces. Building in 3D increases the visualization of the project, and can be used as formal
way of communication. Clash detection software could easily detect physical clashes in the design in advance,
which could help to prevent integration issues. By building in 3D the process can also be monitored much
easier. At the moment, the usability of BIM programs is increasing rapidly. In the near future, these programs
are likely to do a lot more than visualizing the design in 3D. However, BIM software will always have an
assisting role in the IM process, rather than be the solution for IM itself.
7.8.4
Conclusion
Tools to assist in the IM process are a must. A well structured process without tools to support the
methodology is hard to maintain, and is sensitive for errors. Therefore, both technical and organizational
aspects have to be combined in the IM process in order to cover all aspects of IM.
Technical tools in the form of software come in many shapes and sizes. A DMS is necessary as platform to store
all documents in the project. All documentation should be stored, secured and available for all stakeholders at
all times. Through real-time access to interface status, progress and interface-related documents, stakeholders
are equipped with the information necessary to proactively respond to potential interface issues, in an early
stage of the project. Next the a DMS also a specific IM tool has to be used. Relatics is not purely developed for
IM, but could fulfill this role quite well. When more automated processes are wanted, specific IM tools could
be developed or purchased. On the market several ready-to-use IM programs are available for the
development of large multidisciplinary projects. BIM programs could further enhance the IM program by
increasing the visualization of the design solution, and automatically detect clashes between the several
components.
A successful IM program starts with a sufficient IM process. However, technical tools to implement, and assist
with, the IM process are just as important for the realization of a successful project. Sufficient use of technical
tools could improve the efficiency of the team, provide standardization across the project, and provide
consistency in the documentation and exchanging of data between contractors.
88
Ballast Nedam

2014
7.9
Conclusion
In this chapter an IM method is proposed and widely elaborated. At the start of the project a IMP has to be
developed in where the whole IM process is documented. This process consists of five main steps which are
interface identification, documentation, communication, control and closure. The IM team responsible for the
implementation of the IM process consists of an, preferably experienced, interface manager and by several
interface coordinators. Those coordinators are the representatives of each project team, responsible for the
elaboration of the interfaces, and are the single point of contact regarding any potential interface issue.
Before IM can start the SBS, WBS, RBS and OBS have to be specified. The components of the SBS indicate
where potential interfaces could occur, while coupling to the OBS will define the main responsibilities. The
identification of interface will mainly occur in the interface meetings. In here, the identification is mainly based
on the experience and common knowledge of the project members. The FBS, RBS and SBS are used as three
main perspectives from which the functional and physical interfaces could be subtracted. A N-chart could be
used as tool to identify all internal interface possibilities between the components. Throughout the course of
the project more and more interfaces will be identified, which have to be reported to the teams interface
coordinator.
When an interface is identified it will be placed in the IR, in where all related information is obtained.
Agreements about the exchange of information will be done with the help of IAs, which are the formal way of
requesting interface information. In order to create an IA one party has to be the responder while the other
has to be the requester related to that interface information. A responsibility matrix can be used to visualize
the roles and responsibilities belonging to each interface.
When it is not as easy to uncouple an interface with IAs, or when the interface carries a high risk factor, other
strategies could be applied to assist in elaborating the interface. It might be helpful to re-sequence the design
activities attached to those objects. When those objects are pulled forward in the design phase, and are
designed at the same point in time, collaboration is much easier and there will be more time to elaborate the
design activities. Also strategies like forming cross functional teams, using team problem solving and sharing
ranges of acceptable solutions, are good strategies to further assist in the elaboration of complex interfaces.
These strategies mainly focus on collaboratively finding a solution and will speed up the process.
However, the most common strategies to uncouple interfaces, which are designed at different points in time,
are making assumptions and applying overdesign. Predicting the interface information bring along extra risk for
the project when the assumptions appear to be incorrect. Therefore, before making assumptions about the
interface information, and applying overdesign, the benefits and costs, as well as the potential consequences
should be carefully explored.
A communication plan is required so that project members understand what information to communicate, how
to communicate, and when to communicate. The IR is used to communicate the existence and specification of
all interfaces. Next to the IR, also the N-chart is used to communicate all high risk, new and open interfaces to
all stakeholders. This chart visualizes what interfaces need extra attention, in real time, and forms the basis for
the upcoming interface meeting. Main formal forms to communicate interface related information with, are
the IAs, AIs, ICDs and CRs. All interface face-to-face communication will go through the interface coordinators
and ultimately the interface manager.
It is the IM teams responsibility to monitor and control the interfaces in order to keep an eye on the overall
progress, verify the design solutions, and to prevent and solve integration issues during the whole project
89
Ballast Nedam

2014
lifecycle. The IM team should organize regular and ad-hoc interface meetings, in where the progress of all high
risk and open interfaces is discussed.
CRs are used as formal forms to request a modification of the content or due date of an IA, or to request a
modification to a design aspect which has been frozen. The CM team is responsible for the management and
control of the overall progress of the project by controlling, approving and rejecting changes during the design
and construction phases of the project.
For each interface should also be assessed what the risk of the interface is for the project. Schedule, financial
and performance risk could occur if interfaces are not worked out well. All high risk interfaces will be included
in the risk register, in where the interface is monitored and controlled by the risk manager. In addition, the
schedule impact of these interfaces have to be monitored systematically. For each high risk interface a
milestone activity could be established, which will be integrated in the project and discipline desing
programmes, and monitored and controlled by the project planners.
In order to successfully implement the IM process technical tools are required. A Document Management
System is necessary as platform to store all documents in the project. All documentation should be stored,
secured and available for all stakeholders at all times. For the management of the interfaces an specific IM tool
has to be used. Relatics could be used for this purpose, but a tool which includes automated processes and
electronic notifications and alerts would simplify the process. As last, BIM programs could further enhance the
IM method by increasing the visualization of the design solution, and automatically detect clashes between the
several components.
90
Ballast Nedam

2014
Chapter 8: Conclusions and Recommendations

This report contains an exploratory study into integration issues as they currently occur in infrastructure
project development. Despite the best plans and efforts, the integration of a system containing newly
developed components is almost certain to reveal unexpected incompatibilities. Furthermore, current Interface
Management (IM) practices are explored and evaluated, and a systematic method is proposed. In this chapter,
first an answer is given on the research questions (8.1). Thereafter, general conclusions and recommendations
are given (8.2). The chapter ends with recommendations for further research (8.3).
8.1
Answering of the research questions
In this section an answer is given on all defined sub-questions, followed by the main question, as stated in
paragraph 1.4.
8.1.1
1.
Answering of the sub-questions
Why is interface management becoming more important nowadays?
In chapter 3.1 the differences between the traditional way of contracting and integrated contracting are
explored. As explained in paragraph 3.1.3, the introduction of integrated contracts led to a shift of
responsibilities in the construction market. Contractors are not only responsible for construction, but also for
the design phase of the project. This, in combination with great pressure on the time-to-market and cost
aspects of the project, led to the compression, and overlap, of design and construction schedules. The
compression and overlap of the design and construction activities asks for better coordination between the
involved disciplines, and thereby increases the need for a sufficient IM program.
2.
How is interface management proposed in literature on Systems Engineering?
Chapter 3.2 contains an introduction of Systems Engineering (SE), which has become a much used standard in
the Dutch construction industry. According to the SE philosophy, a system is first decomposed into sub-systems
and components, which is displayed in a Systems Breakdown Structure (SBS). These parts of the system, which
can be designed by different teams of engineers, are what causes the existence of interfaces. The way the SBS
is set-up determines the amount and type of interfaces within the project.
However, guidelines to identify, manage and control these interfaces are scarce in SE literature. Several
guidelines have been explored in paragraph 3.3.3. NASA mentions several standardized forms to assist in
identifying and capturing the interface information, and the approved interface change requests (NASA, 2007).
In addition, the link to Configuration Management (CM) is mentioned by proposing interface baselines to
ensure that changes in the design of components have minimal impact on other elements, with which they
interface.
SE guidelines in construction, like Prorail and Rijkswaterstaat (2009), emphasizes that the structured recording
of interface data ensures that the right information is available at the right time. The typical SE tree structures,
such as the Functional, Requirements, Systems and Work Breakdown Structure (FBS, RBS, SBS and WBS) are
mentioned as tools to manage the complexity of projects. A specification tree is proposed in where all
requirements, preconditions and interface requirements are grouped by component and sub-system. In this
way the specification tree shows the relationship between the specifications, structured to the different levels
91
Ballast Nedam

2014
of detail. BAM (2008) mentions that the IM process exists of four main steps: the identification of an interface,
appointing responsibility for the settlement of the interface, arranging coordination measures and as last held
meetings regularly to control the status of the interface. In addition, tools as the N-chart-analysis and 3Ddesign are pointed out to assist in this process. CM and risk management are mentioned as two SE disciplines
strongly related to IM. These processes are described in, respectively, chapter 3.4 and 3.5.
3.
What interface management related research has been done?
In chapter 4 IM related research is examined. Concurrent Engineering, or fast-track construction, is defined as

the process of completing sequential tasks in parallel in order to reduce the project delivery times (Anumba, et
al. 2007). As explained in chapter 3, design and construction activities are often overlapped nowadays. The
degree to which these activities may be overlapped, and in turn the level to which various design disciplines
may be overlapped, depend on the type of information exchanged and the degree of dependency between
those activities (Bogus, et al. 2006).
The degree of dependency of interface information can be characterized by the rate of sensitivity and
evolution. Pena-Mora and Li (2001) suggests that adopting the characterizations of sensitivity and evolution are
a way to indentify approaches for overlapping activities. Bogus et al. (2005) indentified eight overlapping
strategies based on these characteristics, as can be seen in Figure 20. These strategies could be implemented
when one design activity has to wait on the output of another activity, in order to continue with its design. All
consequences of each strategy should be explored on the aspects time, costs and quality before the activities
may be overlapped.
Ballard (2000) conducted research on the reduction of negative design iterations in design. One of the
proposed methods is to restructure the design process by re-sequencing the design activities based on the
dependencies. The design planning is nowadays mainly based on constraints coming from construction, and is
therefore not always logical when looking at the dependencies. However, after exploring literature on the
Design Structure Matrix (DSM) to re-sequence the design order, the conclusion can be conducted that these
methods are not directly implementable in the construction sector. The size of the matrix, as well as the
needed expertise and time to build such a matrix, make it quite difficult to optimize the design order. In
addition, constraints coming from construction will always keep influencing the planning of design in DC
projects, and thereby making the optimal (dependency based) design sequence less useful.
Other strategies mentioned by Ballast (2000) focus on increasing the coordination and communication
procedures between participants. The strategies mentioned are, among others, forming cross function teams,
using team problem solving, sharing ranges of acceptable solutions and sharing incomplete information. These
strategies could assist in the elaboration of complex interfaces by accelerating the process. Furthermore,
overdesign is proposed as strategy to make it possible to overlap dependent activities and thereby reduce
design iterations. Consequences of overdesign should be taken into account carefully since overdesign always
brings along certain risk to the project.
3D design is also mentioned as method to reveal clashes in design. Fischer and Tatum (2003) state that in many
construction projects the coordination is still done using 2D drawings and light tables in what is called a
sequential composite overlay process. This method of coordination has proven to be inadequate and has led to
many conflicts between systems, lack of confidence amongst subcontractors to prefabricate, rework in the field
and an overall lack of productivity installing these systems in the field. The use of virtual design and
construction tools provide the team members with a better simulation environment to try and test solutions
and enhance their knowledge of how the systems can be assembled in the field (Schrage & Michael, 2000).
There are commercial tools available that allow project teams to bring in models from multiple CAD systems
92
Ballast Nedam

2014
into a single model and determine if two or more systems conflict with each other. One such tool is
Navisworks which has a clash detection program that allows teams to automatically analyze the models for
conflicts between systems (Khanzode, 2010). However, it is important to state is that identifying clashes in
design alone, is not a solution for IM issues. Clash detection in 3D design is a helpful tool to help identify
missed interfaces, as well as to control and monitor the physical interfaces. Without a proper IM process
many interfaces will only be elaborated after the identification of a clash since the interfaces are not revealed
and elaborated in advance. This could lead to an enormous amount of unnecessary design iterations. In
addition, clash detection software only focuses on physical clashes in design but does not reveal functional
incompatibilities.
4.
How is Interface Management implemented in practice?
In chapter 5, a case study is conducted to expose the way IM is implemented in practice. The process leader
was responsible for the set-up of the IM process. Weekly meetings were organized to settle and identify the
interfaces of specific objects, which is at component level of the SBS. The involved disciplines of a certain object
were invited to an interface meeting in where a brainstorm session based on technical knowledge and
experience revealed the interfaces. These interfaces were given a specific ID-number and were placed in an
Interface Register (IR). Furthermore, an interface matrix was developed in where all interfaces, between the
components of the SBS were displayed by ID-number to increase the visibility of all existing interfaces.
After the identification of the interfaces, all contractors were responsible for the elaboration of their interfaces.
However, contactors did not always take responsibility and were often waiting for the other to come up with a
solution. In the interface meetings, drawings were brought by all disciplines to check the elaboration of the
interface from both sides. The interface solutions are described in the design reports, which are developed for
each of the objects in the SBS. In each report a chapter is included in where all interfaces of that object are
described and elaborated into detail.
Several tools are used in the project which assist in the IM process. Document Management System Microsoft
SharePoint is used to track and store all electronic documents in the project. All involved parties can place
their documents in the database which is visible and available for all parties at all times. Requirement
Management Tool (RMT) Relatics is used to show the dependencies within the project. In here the FBS, SBS,
WBS, RBS, risk and interface register are all listed and combined to each other. For each object is specified
what functions, activities, requirements, interfaces and risks it relates to. Relatics can only show textual
information, which means coupling to graphical figures is not possible. This is a major weakness since drawings
are one of the most important ways of communication in the construction industry. A 3D-model called
AutoCAD Civil 3D is used by two main contractors, in where the design drawings can be integrated into one 3D
model. 3D drawings increase the visibility of the project and are therefore easier to understand by the other
disciplines. Furthermore, by designing in one model the software can reveal any physical design clashes too.
5.
What are the main differences between the engineering disciplines?
The engineering disciplines in infrastructure projects are usually the civil or structural engineer (CE), the
mechanical engineer (ME) and the electrical engineer (EE). In chapter 5.5 the main differences between these
engineering disciplines are explored. The design process is for all disciplines an iterative process in where one
works from a rough to detailed level, resulting in a conceptual, preliminary and detailed design. The three main
differences which have been identified in this chapter are the (1) output they produce, (2) the internal
organization and (3) the path in time they take. These differences all bring their difficulties to an IM program,
and should be taken into account at the start of the project.
93
Ballast Nedam

2014
Firstly, the EE designs systems while the other disciplines mainly design physical objects. Therefore, the EE is
usually separated in the SBS from the other disciplines. The components of the CE and ME are divided into subsystems based on objects and geographical locations, while the components of the EE are divided into systems
and cannot be allocated to the location based sub-systems. The setup of the ME and CE shows the coherence
of the project quite well. The separation of the EE on the other hand leads to an enormous amount of
interfaces for the EE, which are not always as easy to predict (especially from the point of view of the ME and
CE). Secondly, the EE works with a lot of sub-contractors and suppliers. All these extra parties makes the
communication and collaboration between all these entities much harder. Thirdly, the path in time the
disciplines take slightly differ from each other. The lead times of the EE are relatively long, and in the beginning
are they very dependent on the input coming from the other engineers. Therefore, the EE usually starts a bit
later with the design activities which makes their design finishes last. The design of the EE is often still in
progress when the design of the CE and ME is already finished or even when construction is already started.
The specific details of the objects supporting the systems (i.e., cables and pipes, sensors and light) are not
known until all the systems (software) have been designed, thus these details are usually revealed in the last
phase of their design. It are these specific details of the objects which the other disciplines are dependent on.
The lack of specific details from the EE in an earlier phase causes a lot of friction in current infrastructure
project development. To prevent issues later on assumptions have to be made about the interface information.
In here, it is importance to carefully consider the potential consequences when the assumptions appear to be
incorrect. In addition, it is crucial no interfaces have been missed since the construction has already started.
This brings along certain risks to the project.
In order to get an impression of the high-level interfaces which occur between these engineering disciplines,
the main types of interfaces between these disciplines are identified and displayed in Figure 29, on page 56. It
is important to understand the nature of the several disciplines involved in the project, and take into account
these differences when developing the IM process.
6.
What are the main factors causing integration issues?
Factors causing integration issues in infrastructure project development have been explored by conducting a
case study (5.7) and a literature review (Ch.6). The findings have been compared to each other and are
summarized in table 1, in Appendix D. When analyzing these factors it becomes clear most issues could be
related to poor communication and coordination between the involved parties. Main factors identified are:
Poor communication between the involved parties:
Lack of communication among parties;
Delayed or ineffective communication among parties;
Poor coordination between the involved parties:
Unawareness of interface issues;
No clear ownership and responsibilities;
Lack of resources and personnel to facilitate coordination;
Lack of coordination among specialties;
Poor ordering of tasks;
Unable to work on site simultaneously;
Unwillingness to bear coordination and resolution responsibilities.
94
Ballast Nedam

2014
8.1.2
Answering of the main research question
IM is the discipline related to the integration processes. Implementing an IM process which encounters the
main factors causing the integration issues as mentioned in sub-question 6 could assist in diminishing these
issues. The main research question was defined as follows:
RQ:
How to improve the interface management practices in infrastructure project development, in order to
reduce unnecessary design iterations and rework?
Unnecessary design iterations and rework could be reduced by implementing a systematic approach for IM at
the start of the project. There are currently no clear guidelines of how to cope with the interfaces within an
infrastructure project. In most projects the benefit of IM is underestimated and the process does not get the
attention it requires. A lot of interfaces are not identified in an early phase, and even when they are identified
it is often unclear how to elaborate those interfaces efficiently.
The current practices could be improved by implementing a systematic IM approach at the start of the project,
including an IM team to lead and monitor this process. This approach has to contain guidelines of how to
identify and elaborate these interfaces in a systematic way. A clear IM process that provides a structure to cope
with these requirements is proposed in chapter 7. However, it should be noted that the proposed solution has
not been tested on a real life project and is therefore a theoretical approach. Without more research it cannot
be said with certainty that the proposed process, as described in chapter 7, will actually diminish unnecessary
design iteration and rework in real life projects.
8.2
General conclusions
By conducting this research and answering the research questions throughout the report, several conclusions
could be extracted. In this section the main conclusions for this research are summarized.
Introduction of integrated contracts led to an increase of integration issues
The introduction of integrated contracts led to the compression and overlap of the design and construction
schedules. Because of the current time pressure less time is available for coordination and communication with
the other parties. Furthermore, because of the nature of the different engineering disciplines is the design of
the EE usually finished last. The design of the EE is often still in progress when the design of the CE and ME is
already finished or even when construction is already started. The output of the EE could influence the design
of the CE and ME, and could therefore have huge consequences when construction of that object is already
started. The introduction of integrated contracts increased the amount and consequences of integration issues,
and therefore more attention have to be paid to the integrated system as a whole to prevent such issues from
happening.
Clear scope of work
Before an IM process to identify and elaborate the interfaces can be successful the scope of work of each
contractor has to be clear. Confusion about the responsibility of contractors and disagreements about scopes
of work are common problems. Before starting with a project the contractual boundaries for each contractor
have to be clear and all high-level interface responsibilities should be determined. The client should assist in
this process when outsourcing the project. When the parts of the project are not sufficient allocated to the
involved parties, grey areas could arise between the scopes of work. These grey areas of which nobody knows
who is responsible could be a huge risk to the project. Clear scope packages could be derived by making a clear
decomposition of the project and allocate all parts of the project to the responsible parties. This could be
95
Ballast Nedam

2014
achieved by coupling the several breakdown structures to each other and allocate each component and activity
to a certain contractor.
Contractual alignment
The type of involvement of the several parties in the project should not be underestimated and might even be
the most crucial factor. The type of contract mainly determines the contractors willingness to coordinate and
collaborate with others. Coordination and communication among the parties becomes much harder when a
contractor is not responsible for the projects main objectives (such as the delivery date) and does not bear the
risk of potential fines. In practice, there is usually no contracting relationship between the engineering
disciplines and their respective contracts do not fully specify coordination responsibilities.
Therefore, it is crucial that the project owner understand the importance of IM and enforces the involved
parties by contract to cooperate regarding the interfaces. If the involved parties are not enforced by contract to
cooperate and the general contractor does not recognize these issues, critical interface issues could easily
arise. Contractors could take a more passive attitude and could be less willing to put in effort (e.g., time, cost
and/or recourses) for the interest of the project as a whole and focus on their own priorities and interests
instead.
This is particularly important for the contractual involvement of the EE. The EE usually has the most physical
interfaces in the project due to its nature. The EE designs systems like software and develops objects (e.g.,
hardware/lampposts/cables) which support those systems. Those objects have a lot of physical interfaces and
because of the path in time they take their design is usually finished last. Therefore, in the contract of the EE
incentives should be included to cooperate for the sake of the project as a whole. For the EE it is often
convenient to finish its detailed design relatively late in the project. However, for the other contactors (i.e.,
CE/ME) could that be troublesome since their design depends on the output of the EE. Therefore, the involved
parties should make transparent what parameters they need from the EE in an early phase, so that the EE
could share preliminary information, or could make an accurate prediction if information is not yet available.
However, it is important that the EE has incentives to cooperate and puts in extra effort to reveal certain
information earlier. Without such incentives the EE is likely follow its natural path, causing potential issues and
delays for the other contractors.
Alignment of main contractors
All main parties should be involved from the start of the project in order to reach consensus about the content
of the Interface Management Plan (IMP). Alignment of main contractors is critical to ensure everyone is
working towards the same goals, with clear methods and tools to resolve potential integration issues. When all
main contractors understand the importance of such a program and reach consensus about the content of the
IMP, a climate will be created in where everyone is more likely to participate proactively. The aspects which
should be included in such an IMP are described in paragraph 7.1.1.
Interface Management process
In the IMP the IM process should be described, which contains procedures for the identification,
documentation, communication and verification of interfaces, as well as procedures for change and document
management.
Concluding aspects in here:
Emphasis should be on the early recognition and elaboration of interfaces. After the project have been
awarded a workshop has to be organized where all involved parties (including people from design,
construction and maintenance) systematically identify as much interfaces as possible. The internal and
96
Ballast Nedam

2014
external interfaces could be identified by looking at the system from three perspectives, namely the
FBS, SBS and RBS. The N-chart could assist in this process.
It should be tried to uncouple all indentified interfaces as soon as possible. An interface exists
between two components and needs to be uncoupled so that both design teams can finish their
designs individually. The required flow of information should be made transparent, and deadlines for
interface information should be agreed upon. When is known in advance, what information is needed
by what design team on what moment, and well defined agreements are made regarding this
information, a lot of delays due to waiting, or incorrect assumptions, could be avoided. For complex
and high-risk interfaces, strategies such as re-sequence the design activities, forming cross functional
teams, organizing meetings, sharing preliminary information and overdesign could assist in reaching
consensus about the interface solution.
The interfaces have to be prioritized based on an overall risk analysis. The high risk interfaces need
extra monitoring and control throughout the project. In addition, the objects attached to these
interfaces could be tried to pull forward in the design phase in order to get these objects designed in
an earlier phase, and preferably at the same point in time.
Standardized forms, charts and registers have to be used for the purpose of documenting and
controlling interface related information. Standardized forms are, among others, used to document
the agreements which are made to uncouple an interface, and to clearly defined roles and
responsibilities.
IM should be integrated with other SE disciplines, namely configuration management, risk

management and project planning.
Technical tools could make or break the IM process. It is important to use programs which all
contractors are able to work with. Three main tools are of great value for an IM process: a Document
Management System, an IM tool, and 3D design.
97
Document Management System:

A Document Management System (i.e., Microsoft Sharepoint) is required which could store
all documents, drawings and reports for the project. All project participants should have
excess to this information 24/7 from all locations.
IM tool:
An IM tool has to be used which could dynamically manage all interfaces. RMT Relatics is
often used to manage all requirements, and to couple all specifications to the objects and
activities. In here, all breakdown structures could be linked to each other. Of each object all
specifications like the requirements, risks and interfaces are attached. In Relatics, all registers
and charts for the purpose of IM can be implemented and controlled. This makes this tool
quite sufficient to implement the IM process. However, a tool which includes automated
processes, notifications and alerts, and adds graphical information could further enhance the
efficiency of the IM process.
3D design:
3D design and clash detection software are valuable to assist in the IM process. Clash
detection software could easily detect clashes within the design. These missed interfaces, or
design errors, are in this way detected in an early phase, which could prevent
Ballast Nedam

2014
incompatibilities later on in the project. In addition, all physical interfaces could be verified by
integrating all designs into one 3D model, which is much more efficient than checking the 2D
drawings manually on inconsistencies. Building Information Modeling (BIM) models are
emerging and could in potential be very useful for system integration purposes.
Qualified interface manager
An IM team has to be formed, which includes an interface manager and interface coordinators. The interface
coordinators are the single point of contact of each project team, and the contact bridge between the other
team members of contracting parties, involved in every interface. The IM team must set-up the IM process,
monitor and control all interfaces, and organize interface meetings with all involved participants. It is important
that the IM team, with the interface manager in particular, has experience with the development of
multidisciplinary projects and IM, knowledge of project organizations, leadership skills, and the ability to
facilitate and negotiate issues. When the IM team members are inexperienced or incapable project members,
who could not oversee the bigger picture, issues could easily arise.
Re-ordering the design activities
One of the strategies to reduce design iterations in design is to restructure the design process by re-sequencing
the design activities, based on the dependencies between the project elements. The design planning is
nowadays mainly based on constraints coming from construction, and is therefore not always logical, looking at
the internal dependencies. The DSM is mentioned several times as tool to develop an optimal design schedule
based on the dependencies within the project. Successful implementations of the methodology are found in
sectors like aerospace engineering and mechanical engineering. However, after exploring literature on the DSM
methodology to re-sequence the design order, the conclusion can be conducted that these methods are not
directly implementable in the construction sector.
The size of the matrix, as well as the needed expertise and time to build such a matrix, make it quite difficult
and time consuming to apply this method in practice. The unique circumstances in construction projects, as
well as a lack of evaluation of finished projects, make it difficult to predict all internal dependencies in advance.
When important dependencies within the project are missed the optimal design order according to the DSM
will lose most of its value. Furthermore, as explained in chapter 3, the design and construction schedules in DC
projects are compressed as much as possible and even overlap each other. Therefore, constraints coming from
the construction phase will have a big influence on the planning of the design activities. This means that even
when an optimal (dependency based) design sequence is developed, constraints from the construction
activities will counter the effect of this optimal design planning.
However, when infrastructure projects are more standardized, and there is more insight in the all
dependencies in the project in advance, it could be of value to fill in such a matrix. The DSM gives a very good
insight in all dependencies within the project and could serve as basis for similar projects in the future. The
matrix could also be developed after the realization of the project to get an understanding of what relations
have been missed or underestimated at the start.
8.3
Recommendations for Ballast Nedam
After the conducted research presented in this thesis, recommendations can be derived for Ballast Nedam.
These recommendations could be taken into account to diminish integration issues in infrastructure project
development. The recommendations derived are the following:
98
Ballast Nedam

2014
Steer, and take into account, the contractual responsibilities of the involved parties.
When BN gets involved in a new project as general contractor, it should make sure all involved
contractors share the same objectives and goals for the project as a whole. It was generally mentioned
in the interviews that some contractors lack responsibility towards the final result/performance. In
practice, there is usually no contracting relationship between the specialties and their respective
contracts do not fully specify coordination responsibilities. When the client wont include coordination
responsibilities in the contracts of each involved contractor, BN should carefully consider all risks
before executing the project. Especially the contractual involvement of the EE is crucial. The EEs
willingness to cooperate in an early phase, and to reveal certain information earlier, is necessary for a
successful development of the project.
When BN decides to outsource certain aspects of the project it is advised to elaborate the interfaces in
advance. When possible, interface requirements should be derived and added to the existing
requirements. By elaborating the interface solution in advance no confusion or conflicts can arise
regarding these interfaces later on.
Develop an IM work instruction for the BN handbook.

Based on the findings in this thesis a work instruction could be developed for the BN handbook. This
work instruction could serve as guide for the implementation of an IM program in any infrastructure
project, and serve as basis for the development of an IMP in each infrastructure project.
Include all main stakeholders for the set-up of the IMP.

Reach consensus, in the early design phase, or even in the tender phase, of each project, about the IM
program and software to be used in the project. Alignment of key stakeholders is crucial in order to
develop a process everyone can work with, believes in, and therefore, is more likely to stick to.
Understanding the importance of the process, as well as a commonly accepted method, is critical to
create a climate in where everyone participates proactively.
Further enhance the SE knowledge in the organization.

Lack of experience with the SE methodology was mentioned several times in the interviews as reason
why design iterations and rework occurred. It seems that, in many organizations, SE is not yet widely
understood and embedded. Deriving requirements to each scope, coming up with a design solution,
and developing a sufficient decomposition of the project is not always done well. When a project is
not decomposed sufficiently, or requirements are not well derived to each scope, issues could easily
occur later on in the project. Therefore, extra attention should be paid to include experienced SE
project members in each project, not only from BN but also from the other contractors involved.
BN should expand the SE knowledge in the entire organization, by giving seminars and work
instructions. It is especially important that all design teams understand how to derive functional
requirements, and how to decompose the project into logical components and activities.
Take time to evaluate projects, and develop lessons learned for internal use.
More time should be spend to the evaluation of executed projects and a lessons learned should be
developed. In addition, for each type of project, a clear decomposition including all interfaces and risks
should be collected in a database. By keeping a database, one is able to see in advance what objects
make part of a typical tunnel, bridge or lock project, what their interfaces are, and what the high risks
might be in the next project. Analysis of lessons learned within each project will further improve the
IM process and projects efficiency.
99
Ballast Nedam

2014
8.4
Recommendations for further research
The proposed solutions to diminish integration issues across contractual boundaries has its limitations. During
this research additional suggestions for research did came up. These suggestions do not fit in the scope and
therefore have been disregarded. The following subjects are worth studying:
Apply the approach for Interface Management at the start of a real project
A major limitation of this research is the fact that the proposed method have not been tested, and is
therefore a theoretical approach. The IM process as proposed has resulted from the existing practices
and is modified by results from literature and interviews. Using the approach in a real project could
determine the exact benefits and limitations of this approach.
Research into the amount and type of contracts used in infrastructure projects
The amount and type of contracts, play a major role in the complexity of the project. Different
objectives and interests of the involved parties impede the coordination and communication with
each other. Further research could be conducted in optimizing the type, amount and content of
contracts used in a particular project.
Research into technical tools to implement a systematic approach for Interface Management
Technical tools and software provide a lot of possibilities for further research. A tool could be
developed to implement the IM process and include automated processes. Further research is also
possible in Building Information Modeling (BIM) tools which could design the project in 3D, and
identify potential clashes in advance.
100
Ballast Nedam

2014
References
Admiari, A.R. (2010). A study of configuration management implementation in the construction industry.
Center for Advanced Infrastructure and Transportation, Rutgers University.
Al-Hammad, A. and Al-Hammad I. (1996). Interface Problems between Building Owners and Designers.
Journal of Performance of Constructed Facilities, ASCE, 10(3), 123-126.
Al-Hammad, A. (2000). Common Interface Problems among Various Construction Parties. Journal of
Performance of Constructed Facilities, ASCE, 14(2), 71-74.
Al-Hammad, A. and Assaf, S. (1992). Design-construction interface problems in Saudi Arabia. Building
Research and Information, 20(1), p.60-63.
Alarcn, L.F. and Mardones, D.A. (1998). Improving the Design-Construction Interface. Proceedings of the 6th
Annual Conference of the International Group for Lean Construction, Guaruja, Brazil.
Anumba, C.J., Kamara, J.M. and Cutting-Decelle, A.F. (2007). Concurrent Engineering in Construction. Taylor &
Francis, Abingdon, UK
Austin, S., Baldwin, A. & Newton, A. (1996) A Data Flow Model to Plan and Manage the Building Design
Process. Journal of Engineering Design Vol. 7. No. 1 pp 3-25
Austin, S., Baldwin, A., Li, B. and Waskett, P. (1999). Analytical Design Planning Technique for Programming
Building Design. Structures and Buildings: Proceedings of the Institution of Civil Engineers, Thomas Telford Ltd,
London, 134(2), 111-118.
Austin, S., Baldwin, A., Li, B. and Waskett, P. (2000). Application of the Analytical Design Planning Technique to
Construction Project Management. Department of Civil and Building Engineering, Loughborough University, UK.
BAM .(2008). SE-Wijzer, Handleiding Systems Engineering voor BAM infra. Koninklijke BAM Groep nv.
Ballard, G. (1999). "Can Pull Techniques Be Used In Design?" Proceedings of the Conference on Concurrent
Engineering in Construction, Espoo, Finland, August 1999.
Ballard, G. (2000). Positive vs Negative iteration in design. Proc. Eighth Annual Conference of the
International Group for Lean Construction (IGLC-8), 17-19 July, Brighton, U.K.
Biesboer, F. (2010). Het Dossier Tunnels, Oponthoud door technische installaties. De Ingenieur, 17 December
2010, p.20-31.
Bogus, S., Diekmann, J.E., and Molenaar, K.R. (2002). Methodology to Reconfigure the Design-Construction
Interface for Fast-Track Projects. Computing in Civil Engineering: Proceedings of the International Workshop on
Information Technology in Civil Engineering, Washington D.C.
Bogus, S., Molenaar, K., Diekmann, J. (2006). Strategies for overlapping dependent activities. Construction
Management and Economics. p. 829837.
Browning, T.R. (1998). Use of Dependency Structure Matrices for Product Development Cycle Time
Reduction. Proceedings of the Fifth ISPE International Conference on Concurrent Engineering: Research and
Applications. Tokyo, Japan.
101
Ballast Nedam

2014
Browning, T.R. (2001). Applying the Design Structure Matrix to System Decomposition and Integration
Problems: A Review and New Directions. IEEE Transactions on Engineering Management, Vol. 48, No. 3,
August 2001
Browning, T.R., Fricke, E. and Negele, H. (2006). Key Concepts in Modeling Product
Development Processes, Systems Engineering, Vol. 9, No. 2, pp. 104-128, 2006.
Chen, C., Ling, S., Chen, W. (2003). Project scheduling for collaborative product
development using DSM. International Journal of Project Management. p. 291299
Chen, Q. (2007). An Object Model Framework for Interface Management in Building Information Models. PhD
Thesis, Faculty of the Virginia Polytechnic Institute and State University, Blacksburg, Virginia
Chen, Q., Reichard, G. and Beliveau, Y. (2007). Interface ManagementA Facilitator of Lean Construction and
Agile Project Management. Proceedings IGLC-15, Michigan, USA.
Chua, D.K.H., Tyagi, A., Ling, S. and Bok, S.H. (2003). Process-Parameter-Interface Model for Lean Design
Management. Journal of Construction Engineering and Management, 2003.
Choo, H.J., Hammond, J., Tommelein, I.D., Austin, S.A., Ballard, G. (2004). DePlan: a tool for integrated design
management. Automation in Construction. Vol. 13, (2004), p. 313 326.
Couwenberg, F. (2011). Raakvlakmanagement, Database helpt bij afstemming deelcontracten in groot
project. IPMA Projectie Magazine, 04-2011, p. 6-11
Coreworx (2014). Retrived from:
< http://www.coreworx.com/coreworx-products/interface-management/>
DAmelio, V. (2010). Design Interference Detection for Multi-Disciplinary Product Development. PhD
Thesis, Technical University of Delft, Netherlands
De Witt, S., Yakowenko, G., Bohuslav, T., Ferguson, T., Hoelker, E., Molenaar, K., Schiess, G., Smythe, J., Triplett,
J., Wagman, R. (2005). Construction Management Practices In Canada and Europe. U.S. Department of
Transportation, Federal Highway Administration
Doorewaard, Hans and Verschuren, Piet. (2007). Het onderwerpen van een onderzoek. Den Haag : Boom
Lemma uitgevers, 2007.
Doornbos, H. (2005). Integraal ontwerpen in de GWW sector. PhD Thesis, University of Utrecht, Netherlands
DSM community. (2013). DSM. Retrived from:
<http://www.dsmweb.org>
Eppinger, S.D., Whitney, D.E., Smith, R.P. & Gebala, D.A. (1994) A Model-Based Method for Organising Tasks in
Product Development. Research in Engineering Design. Vol. 6, No. 1, pp 1-13.
Eppinger, S.D. (1997). A Planning Method for Integration of Large-Scale Engineering Systens. International
conference on Engineering design ICED 97, Tampere, Finland.
Eppinger, D. and Browning, T.R. (2002). Modeling Impacts of Process Architecture on Cost and Schedule Risk in
102
Ballast Nedam

2014
Product Development. Appeared in IEEE transactions on Engineering Management, Vol. 49, No.4, November
2002, p. 428-442
Fischer, M. and Kunz, J. (2004). The scope and role of Information Technology in Construction. Technical
Report 156, Center for Integrated Facilities Engineering (CIFE), Stanford University, Stanford CA, USA
Fritschi, N.C. (2003). Interface Management for Design Processes: Synergy of Hard and Soft
Skills for Project Management. Thesis, Fht Stuttgart-Hochschule Fr Technik, WS.
Helgerson, D. A., Billingsley, D.W., and Doerry, N.H. (2009). Initial DSM Application to U.
S. Navy Ship Design. Proceedings of 11th International Design Structure Matrix Conference, DSM09,
Greenville, South Carolina, USA, October.
Hollins, B., Pugh, S. (1990). Successful Product Design. Butterworths, London.
Huang, R., Huang, C., Lin, H., and Ku, W. (2008). Factor Analysis of Interface problems among Construction
PArties A case study of MRT. Journal of Marine Science and Technology, Vol. 16, No. 1, pp. 52-63
INCOSE: Systems Engineering Handbook, INCOSE, Release 1, January 1998
Iansiti, M. (1995). Shooting the Rapids: Managing Product Development in Turbulent
Environments. California Management Review, 38 (1), Fall, 37-58.
Jager, J. (2013). Nieuwe contractvormen, 10 mythes en hoe het werkelijk zit. Infra, februari 2013, nr. 1, p. 2225
Josephson, P.-E. and Hammarlund, Y. (1996). Quality defect costs in the 90s: a study of seven
construction projects. Report No. 49. Deptt. of Building Economics and Const. Mgmt., Chalmers University of
Technology.
Khanzode, A., Fischer, M., and Hamburg, S. (2000). Effect of Information Standards on the
Design-Construction Interface: Case Examples from the Steel Industry. Computing in Civil and
Building Engineering: Proceedings of the 8th International Conference, Stanford, CA.
Khanzode, A. (2010). An Integrated, Virtual Design and Construction and Lean (IVL) Method for Coordination
of MEP. CIFE Technical Report #TR187, February 2010, Stanford University
Korman, T., Fischer, M. and Tatum, C. (2003). Knowledge and reasoning for MEP coordination. Journal of
Construction Engineering and Management, NovemberDecember 2003, p. 627634,
Koskela, L., Ballard, G. and Tanhuanp, V-K. (1997). Towards Lean Design Management. Fifth Annual
Conference of the International Group for Lean Construction, 16-17 July, 1997, Gold Coast, Australia.
Kossiakoff, A., Sweet, W.N., Seymour, S.J. and Biemer, S.M. (2011). Systems Engineering principles and
practice. Second edition, John Wiley & Sons, New Jersey
Kuprenas, J.A. and Rosson, M. (2000). Interface Consideration on Multiple Prime Contractor Construction
Projects. Construction Congress VI: Building together for a Better Tomorrow in an Increasing Complex World:
103
Ballast Nedam

2014
Proceedings of the Congress, Orlando, FL.
Larsson, N. (2004). The Integrated Design Process. International Initiative for a Sustainable Built Environment
(iiSBE). Retrieved from:
<http://www.iisbe.org/down/gbc2005/Other_presentations/IDP_overview.pdf>
Maheswari, J.U. (2006). Modeling Activity Sequencing for Construction Projects using
Dependency Structure Matrix. Ph.D. Dissertation, IIT Madras, India.
McCord, K.R, & Eppinger, S.D. (1993). Managing the Integration Problem in Concurrent Engineering. Working
Paper 3594-93-MSA, MIT Sloan School of Management, August, 1993.
Miles, R.S., P.E. and Ballard, G. (2001). Problems in the interface between mechanical design and
construction: A research proposal. Submitted for publication in the Journal of Construction Research, special
issue on Lean Construction.
Newton, A., Steele, J., Austin, S. and Waskett, P. (2007). Benefits derived from use of DSM as part of the
ADePT approach to managing engineering projects. 9th international design structure matrix conference, 16-18
October 2007, Munich, Germany.
Nielsen, A. S. and M. A. Thomassen (2004) How to Reduce Batch-size, Proceedings of the 12th Annual
Conference International Group for Lean Construction (IGLC-12), Elsinore, Denmark
Nooteboom, U. (2004). Interface Management Improves On-time, On-Budget Delivery of Megaprojects. JPT
Online, Society of Petroleum Engineers.
Orth, D.L. and Mains, C. (2008). A Need for Expansion: Mechanical and Electrical Courses. Northern Kentucky
University, Kentucky, United States of America.
PACO Technologies. (2010). Retrieved from:
<http://www.pacotechnologies.com/Pages/Configuration-Management.aspx>
Pektas. S. T. and Pultar, M. (2006). Modeling Detailed Information Flows in Building Design with the Parameter
based Design Structure Matrix. Design Studies, 7 (1), 99-122.
Pena-Mora, F., and Li, M. (2001). Dynamic planning and control methodology for design/build fast-track
construction projects. Journal of Construction Engineering and Management. 127 (1) 117.
Pimmler, T.U. & Eppinger, S.D. (1995). Integration Analysis of Product Decompositions. Proc. of Sixth
International Conference on Design Theory and Methodology, Minneapolis, MN, Sept. 1994.
PKM Solutions. (2009). Toelichting Template Systems Engineering 02. PKM Solutions, Ridderkerk
PKM Solutions. (2013). Relatics. Retrived from:
<http://www.relatics.com/nl/product/>
Prasad, B. (1996). Concurrent Engineering Fundamentals: Integrated Product and Process
Organization. Prentice Hall, Upper Saddle River, NJ.
104
Ballast Nedam

2014
Project Management Institute (PMI) Houston. (2011). PMI Houston Energy Corridor Meeting. Presentation by
Khadially, R., Project Interface Manager, WISON Floating Systems. 27 june 2011. Abstracted from:
<http://www.projectexecutive.com/files/WISON_PMI_Interface_Management_RK_27June2011.pdf>
Prorail and Rijkswaterstaat. (2009). Leidraad voor Systems Engineering binnen de GWW-sector. Prorail and
Rijkswaterstaat, Netherlands
Prorail and Rijkswaterstaat. (2013). Leidraad voor Systems Engineering binnen de GWW-sector. Versie 3,
Prorail and Rijkswaterstaat, Netherlands
Provincie Frysln. (2012). FrieseMeren. Retrived from:
<http://www.friesemeren.nl/665>
Rijsenbrij, B. and van Gelder, H. (2010). HSL-Zuid: Lessen geleerd, Kennis in het groot. Gezamenlijk
programma van Rijkswaterstaat en Prorail
Roemer, T. A., Ahmadi, R. and Wang, R. H. (2000). Time-cost trade-offs in overlapped product development.
Oper. Res., vol. 48, no. 6, pp. 858865.
Rogers, J.L. & Padula, S.L. (1989). An Intelligent Advisor for the Design Manager. Technical Memorandum
101558, NASA.
Rouibah, K. and Caskey, K.R. (2003). Change management in concurrent engineering from a parameter
perspective Computers in Industry. Vol. 50, p. 15-34
Rose, H. (2008). Internal controls policies and procedures. John Wiley and Sons. P.83. ISBN 0-470-28717-9
Sacks, R. and M. Goldin (2007) "Lean Management Model for Construction of High-Rise Apartment
Buildings", Journal of Computing in Civil Engineering, 133(5)
Sawhney, A., Walsh, Kenneth D., Bashford, Howard H. and Palaniappan, Sivakumar (2009). "Impact of Inspected
Buffers on Production Parameters of Construction Processes." Journal of Construction Engineering and
Management, 135(4): 319-329.
Schrage, M. (2000). "Serious Play How the world's best companies simulate to innovate." Book Published by
Harvard Business School Press, 2000
Shim, E. (2011). Impacts of Matched Batch Sizes on Time Reduction in Construction Projects. 28th
International Symposium on Automation and Robotics in Construction, Seoul, Korea
Shokri, S., Safa, M., Haas, C., Haas, R., Maloney, K., and MacGillivray, S. (2012). Interface Management Model
for Mega Capital Projects.
Shrive, C.A. (1992). Specifying for Multiple Prime Contracts. The Construction Specifier, March, 1992.
Sosa, M., S. Eppinger, C. Rowles. 2007. Are Your Engineers Talking to Each Other When They Should. Harvard
Business Review. Retrived from:
< http://hbr.org/web/special-collections/insight/communication/are-your-engineers-talking-to-one-anotherwhen-they-should>
105
Ballast Nedam

2014
Specialist Engineering Alliance. (2009). Sustainable buildings need integrated team. Eclipse Research
Consultants. Retrived from:
<http://www.secgroup.org.uk/pdfs/2011/SEABrochure2011.pdf>
Stevens, R., Brook, P., Jackson. (1998). System Engineering: Coping with Complexity. Prentice Hall Europe,
ISBN 0-13-095085.
Suddle, S. (2004). Physical Safety in Multiple Use of Space. PhD Thesis, Delft University of Technology
Tayeh, A. (2009). The Relationship Between Contractors and Their Subcontractors in The Gaza Strip. Master
Thesis, The Islamic University of Gaza-Palestine
Tomiyama, T., Meijer, B.R. (2005). Directions of next generation product development. ElMaraghy HA,
ElMaraghy WH, Advances in design. Springer, London, pp 27-35.
Tristl, C., Karche, A., Klenk, H., Haubach-Lippmann, C. (2012). Towards a Framework for Synchronization of
Systems- and Mechanical/Electrical Engineering processes on multiple dimensions. Concurrent Engineering
Approaches for Sustainable Product Development in a Multi-Disciplinary Environment, Springer-Verlag London
2013, pp. 1021-1032
Tuholski and Tommelein. (2010). Design Structure Matrix Implementation on a Seismic Retrofit. ASCE Journal
of Management in Engineering, 26(3), 144-152.
Ulrich, K. and Eppinger, S.D. (1995). Product Design and Development. McGraw-Hill, New York, NY.
Van Klink, L.J.W., Gerder, E.J., Kandel, H.E. Kemper, A.D. and van der Does de Bye, M.R. (2010). Leren van de
Betuweroute, eindevaluatie aanlegfase Betuweroute in het kader van de regeling grote projecten.
Uitgevoerd door Rebel Group Advisory bv in opdracht van het Ministerie van Verkeer en Waterstaat.
Van Ruijven, L. (2007). Kostenbesparing door Systems Engineering bij project Sluiskiltunnel, Lessons
Learned. Retrived from:
<http://www.crow.nl/Downloads/specificeren_system/Kostenbesparing_door_SE_bij_project_
Sluiskiltunnel[1].pdf>
Varghese, K. and Senthilkumar, V. (2008). Analysis of workflow on design projects in India. Proceedings of
presentation in Joint Conference & Workshop Design Management in the Architectural Engineering
and Construction Sector, University of So Paulo, Brazil, 4-8 November 2008.
Varghese, K. and Senthilkumar, V. (2009). Structured Methodology to Formulate Drawing Dependency
Structure Matrix for Construction Design. Architectural Engineering and Design Management, 5:4, p. 225-248
Varghese, K. and Senthilkumar, V. (2010). Workflow and Organizational Structuring of Design Projects:
Analysis of two Case Studies in India. Gesto & Tecnologia de Projetos, Vol. 5, No. 3, November 2010, p.85-103
Varghese, K., Senthilkumar, V. and Chandran, A. (2010). A web-based system for design interface management
of construction projects. Automation in Construction, p. 197212
Varghese, K. and Senthilkumar, V. (2012). A case study based testing of design interface management system
(DiMs). Journal of Management in Engineering, August 6, 2012
106
Ballast Nedam

2014
Verganti, R. (1997). Leveraging on systematic learning to manage the early phases of product innovation
projects. R&D Mgt., vol. 27, no. 4, pp. 377392.
Wideman, R.M. (2002). Wideman Comparative Glossary of Project Management Terms. v3.1. Retrieved from:
<http://maxwideman.com/pmglossary/>
Yassine, A., Falkenburg, D. and Chelst, K. (1999). Engineering design management: An information structure
Approach. International Journal of Production Research, p. 2957-2975.
Yassine, A. and Braha, D. (2003). Complex Concurrent Engineering and the Design Structure Matrix Method.
Concurrent Engineering: Research and Applications, Vol. 11, No. 3, September 2003, p. 165-176
Zummo, K.J. (2010). A Methodology for the integration of design teams for the development of complex
Systems. PhD Thesis, Southern Methodist University, Dallas, USA
107
Ballast Nedam
Appendices
Table of contents
Appendix A
Appendix B
Appendix C
Appendix D
Appendix E
Appendix F
Appendix G
Templates Interface Control Documents.....................................................................................2

Interface Matrix of the Johan Frisosluis......................................................................................3
System Breakdown Structure of the Johan Frisosluis.................................................................4
Verification factors causing integration issues...........................................................................5
Implementation IM process in Relatics.......................................................................................7
Standardized forms ....................................................................................................................11
Description DSM methodology..................................................................................................15
Ballast Nedam
2014
Appendix A
Examples of Interface Control Forms used at different organizations.
Ballast Nedam
2014
Appendix B
Part of the interface matrix as used at the Johan Frisosluis in Stavoren.
Ballast Nedam
Appendix C
System Breakdown Structure (SBS) of the Johan Frisosluis in Stavoren:
Ballast Nedam
Appendix D
Table 1: Verification of the factors causing integration issues with findings from literature.
Case Study
The engineering disciplines possess specific
knowledge and speak their own language, leading to
misunderstandings.
Literature
Various project teams and disciplines are often
unaware of how their activities affect the delivery or
operation of other project teams, leading to poorly
defined interfaces between different scopes of work
(Nooteboom, 2004).
Insufficient and inaccurate interface information, as
well as inefficiencies in information sharing (AlHammad and Al-Hammad, 1996; Al-Hammad, 2000;
Miles and Ballard, 2001); poor communication
(Fritschi, 2002); poor information flow (Varghese and
Senthilkumar, 2010); unsatisfactory information
(Fritschi, 2002); uncertainty (missing or unstable
information) (Anumba, et al. 2007).
Lack of coordination among specialties (Josephson, et
al. 1996; larcn and Mardones, 1998).
The engineering disciplines, by nature, take another

path in time.
Insufficient and inaccurate interface information, as

well as inefficiencies in information sharing (AlHammad and Al-Hammad, 1996; Al-Hammad, 2000;
Miles and Ballard, 2001); poor communication
(Fritschi, 2002); poor information flow (Varghese and
Senthilkumar, 2010); unsatisfactory information
(Fritschi, 2002); uncertainty (missing or unstable
information) (Anumba, et al. 2007).
al. 1996; larcn and Mardones, 1998).
Discussions occur about who will adapt his design to

the other, regarding an interface.
Failing to properly manage resulting conflicts

(Nooteboom, 2004).
Lack of experience with Systems Engineering .

Some have no experience in working with functional
requirements, deriving the requirements, making a
design and/or identifying interfaces.
Inconsistencies among drawings and specifications

(larcn and Mardones, 1998).
The need for correcting design errors (Anumba, et al.
2007).
Designers with little knowledge (larcn and
Mardones, 1998); defects of individual specialists
(larcn and Mardones, 1998).
Ballast Nedam
2014
The engineering disciplines work from another

location which complicates direct communication and
collaboration.
Poor communication (Fritschi, 2002).
Lack of familiarity with the tools used
Not clear who is responsible for a certain interface
Confusing exists about who has ownership of a

particular interface (Nooteboom, 2004).

al. 1996).
No clear definition of tasks (Fritschi, 2002).

al. 1996).
There is no planning for the elaboration of interfaces
available. It is not clear when an interface has to be
closed.

al. 1996).
Poor information flow (Varghese and Senthilkumar,
2010).
Insufficient preparation work (Fritschi, 2002).
Inappropriate sequence of work performed (Varghese
and Senthilkumar, 2010); poor ordering of tasks
(Anumba, et al. 2007).
No overview of what the crucial interfaces are.

Inappropriate sequence of work performed (Varghese
and Senthilkumar, 2010); poor ordering of tasks
(Anumba, et al. 2007).
Interface Management did not get the necessary

attention by all contractors. Most contractors were
able to handle their intra-disciplinary interfaces quite
well, but did not really focus on the intra-disciplinary
interfaces.
Problems arise when issues cut across delivery teams,

with cross-function issues often not receiving the
necessary priority (Nooteboom, 2004)
No proper interface management organization.
IM Is a critical project component that to date has not

been fully appreciated, or appropriately addressed
(Nooteboom, 2004).
Changes in requirements or scope (Anumba, et al.

2007); changes introduced by the owner and
designers (larcn and Mardones, 1998).
Ballast Nedam
2014
Appendix E
In this Appendix is shown how all registers and forms related to the interfaces are displayed in Relatics, including a description of its intended use.
Interface Register
Interface Register
ID
Title
Description
Type
Status
Object
ID
Objects
Involved
contractors
Interface
Agreement ID
Req. ID
Resp.
Risk
Each contractor should have access to the main IR in Relatics, which looks like the figure above. In here all inter-disciplinary interfaces within the project are displaced. Next
to this register, also a separate IR could be placed in Relatics for each contractor, containing their intra-disciplinary and external interfaces. These interfaces are only
accessible for the contractor involved, which means each party has access to two IRs. One main register for the cross contractual interfaces and one for the internal
interfaces.
In the registers, it should be made possible to filter the interfaces by all aspects (e.g. title, type, status, risk, etc.). By including these filters will it be much easier to look and
find specific interfaces, like for instance the interfaces with a high risk factor.
Interface Breakdown Structure
All identified interfaces will also be placed in an IBS. In here all main interfaces identified between the contracts will serve as interface categories, like for instance cable
and pipes. In these categories all interfaces between the components related to that category are placed. In this way it will become much easier to look up all interfaces
belonging to a certain category.
Additional Interface details
By clicking on the ID-number of an interface all interface related information will be revealed. For a template of this sheet, see Appendix E. In here the following information
is obtained:
Ballast Nedam
Interface ID:
Interface title:
Interface description:
Type of interface:
Status:
Requirement:
Leading and intersecting objects:
Interface agreements:
Action items:
Related activities:
High risks:
Verification plan:
Further documents:
ID number of the interface;

Interface title;
Short description of the interface;
External, Inter- or Intra-disciplinary;
Open, In progress or Closed;
Title, ID, description and verification status if a requirement is derived from the interface;
Title and ID of objects;
Title, ID, description, requester, responder, due date and status of all IAs;
Title, ID, description, person, due date and status of all AIs;
WBS activity ID, status, role and person;
Title, ID-number, description;
Document title, document ID, status, role, person;
Document title, document ID, description.
Interface agreements
For each interface, one or more IAs are developed. A template of that form is given in Appendix E. In each IA the following information is obtained:
Interface Agreement ID:
Attached interface:
Attached objects:
Requester:
Responder:
Required information or deliverable(s):
Responding document(s):
Action items IDs:
Need date of the agreement:
Verification of the deliverables:
Finish date :
ID-number IA
Interface title and ID
Involved objects titles and IDs
Requesting party
Responding party
Description of the interface information or deliverables
Document title and ID
ID-number, Description, Roles, Due dates, Status
Due date
Status
Date when the interface conditions have been met
Ballast Nedam
Interface Agreement Register

The IA register will contain a list of all IAs, which allows the IM team to monitor these by filtering on, for instance, status or due date.
Interface Agreement Register
Interface
agreement ID
Requester
Responder
Interface ID
Object
ID
Objects
Due Date
Status
Open, In progress,
Verification, Closed
Action item register

Just like the IA register, also an AI register can be maintained which is a list of all AIs in the project. By filtering the AIs on due dates and status it becomes much easier to
foresee any potential delays or issues.
Action Item Register
Action
Item ID
Description
Person
Due Date
Status
Open, In progress,
Verification, Closed
SBS objects
Clicking on an object in Relatics will reveal all specifications.
Underlying and parent objects;

Functions it fulfills (FBS);
Design and construct activities (WBS) which are attached to the object;
All requirements which have to be met;
All risks and interfaces which have to be taken care off.
Ballast Nedam
WBS activities
Clicking on an object in Relatics will reveal all relations of that activity.
Underlying and parent activities;

Attached object (SBS);
Risks and interfaces which have to be taken into account.
Verificationmatrix
The verification matrix in Relatics verifies the requirements in the project for all objects. However, the verification matrix should also include the interfaces instead of just
the requirements. In this matrix an interface could be stated as verified, and the related document(s) could be attached.
10
Ballast Nedam
Appendix F
When clicking on the interface ID-number, a specification sheet will appear with all relevant information.
Interface Specification
interface title
General information
ID-number
Title
Description
Type of interface
Status
ID number of the interface

Interface title
Short description of the interface
External, Inter- or Intra-disciplinary
Open, In progress or Closed
Leading and intersecting object

Leading object
Object 1
Intersecting object
Object 2
Requirement
Req. title
Title
Req. ID
ID-number
Req. description
Short description
Interface Agreements
IA Title
Title
IA ID
ID-number
IA desription
Short description
Requester
Contractor
Action Items
AI Title
Title
AI ID
ID-number
AI desription
Short description
Person
Responsible person
Attached risk
Risk Title
Title
11
Risk-ID
ID-number
Responder
Contractor
Description
Short description
Ballast Nedam
Due date
Date
Status
Open/Closed
Due date
Date
Status
Open/Closed
Verification plan
Document title
Title
Document-ID
ID-number
Related activities
Activity ID
Activity out of the WBS
Further documents
Document title
Title
Document-ID
ID-number
Status
Open/in progress/approved
Role
Responsible role
Name
Responsible person
Status
open/in progress/closed
Role
Responsible role
Person
Responsible person
Document description
Short description
Additional comments
Additional comments
12
Ballast Nedam
Interface Agreement Form:

Interface Agreement
General information
ID-number
Title
ID number of the IA
IA title (e.g. Lockhead-Gate_IA_1.0)
Attached interface
Interface title
Interface ID-number
Attached Objects
Object 1 title
Object 2 title
Object 1 ID-number
Object 2 ID-number
Requester
Requesting party
Responder
Responding party
Required information or deliverables

Specific description of the required interface information
Deliverable 1
or deliverables
Responding document(s)
Document title
Title
Document ID
ID-number
Additional comments
Additional comments
Action Items
AI Title
AI title 1
AI title 2
AI ID-number
ID-number
ID-number
AI desription
Person
Short description Responsible person
Due date Status

Date
Open/Closed
Date
Open/Closed
Verified
By 'name person'
By 'name person'
ID-number
Date
By 'name person'
AI title n
13
Ballast Nedam
Open/Closed
Due date of the agreement

Due date
Date
Received date
Date when deliverables are received
Verification of the deliverables

Deliverables verified
Date of verification
Verified by
Comments
Verified Yes/No
Verification date
Name of responder which verified the deliverables
Extra comments
Extra comments
Extra comments
Signatures
Requester
Agree with the content of the IA
Closure of the IA
Date
Signature
Name
Date
Signature
Name
14
Ballast Nedam
Responder
Appendix G
Much of the research mentioned in chapter 4 proposes restructuring of the design process, based on the
dependencies between the project elements. The DSM is mentioned several times as part of their
methodology. In this appendix the ADePT methodology proposed by Austin et al. (1999), the DIMs
methodology proposed by Varghese and Senthilkumar (2008) and the Process-Parameter-Interface (PPI) model
of Chua et al. (2003) are evaluated, as well as the DSM methodology included in here.
DSM Methodology
A fundamental activity in project design, is the planning and control of work. In current construction industry
practice, design is planned by the same techniques as site construction, including network analysis (Austin, et
al. 2000). However, network analysis techniques and tools were designed to represent sequential processes
and cannot easily account for a process containing iteration, such as design (Austin, et al. 1996). This results in
the unwanted exclusion of information links between activities. In construction design, this problem is
particularly prevalent when considering information exchanged between design disciplines, because of the
disparate manner in which they undertake their work and its planning. Steward (1965) developed a theory that
a complex problem such as design could be solved more efficiently by representing the interrelationships
between activities in the form of a matrix (Austin, et al. 2000).
Design Structure Matrix (DSM)
The Design Structure Matrix (DSM), developed by Steward (1981), is an N-chart diagram used to capture
interactions and dependencies between teams, functions and activities (Browning et al, 2006). It has been
proved that the DSM method drastically reduces the design process time of multi disciplinary projects that
involves much iteration (Eppinger, et al. 1994). DSM provides a simple compact and visual representation of a
complex system that facilitates novel solutions to decomposition and integration problems (Browning, 2001).
The design structure matrix (DSM) is a matrix representation of a system, which shows the dependencies
between the elements of that system. System elements are listed in the first row and the first column of the
matrix and off-diagonal cells indicate the interactions or information flow between the system elements. There
are two main categories of DSM which are static and time-based, see figure 1.
Figure 1: Different types of DSM (Browning, 2001)
15
Ballast Nedam
2014
Static DSMs represent existing system elements simultaneously, such as components of a product architecture
or groups in an organization. In time-based DSMs, the ordering of the rows and columns indicates a flow
through time. In here upstream elements of a process precede downstream elements, and terms like
feedforward and feedback become meaningful when referring to interfaces. Out of these two categories,
four main types of DSMs can be distinguished as can be seen in table 1.
Table 1: DSM data types (DSM Community, 2013)
DSM data types
Representation
Applications
Component-based
(Product)
Component
relationships
System architecting, engineering and design
People-based
(Organization)
Organizational
relationships
unit
Organizational design, interface management, team

integration
Activity-based
(Process)
Activity input/output
relationships
Process improvement, project scheduling, iteration

management, information flow management
Parameter-based
(Low-level Process)
Design
parameter
relationships
Low level activity sequencing and process construction,

sequencing design decisions
The activity-based DSM shows the connections between the activities or elements and defines three types of
relationships. The three basic building blocks for describing the relationship amongst system elements are
sequential (or dependent), parallel (or concurrent), and coupled (or interdependent).
Figure 2: Types of relationships between tasks (Chen, et al. 2003)
The DSM can be used to find the optimal sequence of activities and provide an overview of all dependencies in
the project. Partitioning and tearing are two operations used for this purpose. Partitioning is the process of
reordering the DSM rows and columns which will maximize the availability of information required, and
minimize the amount of iteration and the size of any iterative loops within the process. Tearing is the process
of choosing the set of feedback marks that if removed from the matrix are called tears. The information
16
Ballast Nedam
required for these feedback marks will in that cased be determined based on assumptions (Varghese and
Senthilkumar, 2010).
Figure 3: DSM overview: (a) Spaghetti Graph; (b) Base DSM; (c) Partitioned DSM (Yassine and Braha, 2003).
Figure 3 gives an example of a partitioned DSM in order to reduce iteration in a sequential design process.
Looking at the figure it can be seen that task D needs information from task L. When task L is executed after
task B, it could happen that because of the information released by L, task B has to change. This change in task
B could on their turn lead to many more tasks that has to be re-done. In figure 3(c) the partitioned DSM can be
found. If the design tasks are executed in this sequence, less iteration is necessary and smaller feedback loops
will occur. As can be seen, only the coupled boxes, which are the interdependent tasks, require iteration.
In order to break down the iteration process even more, the marks which are placed above the diagonal should
tried to be teared. By making assumptions that can be done with some confidence the iteration within the
shaded areas can be reduced.
Evolution of DSM
Rogers and Padula (1989) at the NASA Langley Research Centre have demonstrated how the DSM could be
applied to the scheduling of problems with up to 50 activities at the conceptual phase of the design process.
Eppinger and core searchers at MIT have applied DSM to a number of engineering problems involving up to 100
activities, including the processes of semiconductor design for Intel Corporation (Eppinger, et al. 1994), an
automotive brake system and engine design for General Motors (McCord & Eppinger 1993), and the design
process of a climate control system for the Ford Motor Company (Pimmler & Eppinger 1995).
Interest shown in DSM in construction has been largely limited to academia. Although the theory of DSM has
been applied in a number of circumstances, analyses are only just now being undertaken in practice. The
applicability of the DSM methodology in construction design has been tested by the Indian institute of
technology (Varghese and Senthilkumar, 2008) and Loughborough University (Austin et al., 1999). However,
limited research has been done in construction industry compared to other industries.
Koskela et al. (1997) indicates that while the initial results of DSM methods are promising, that this method is
still in research phase. Only after sufficient testing and launching of commercial software can this systematic
tool for finding the optimal sequence in design be implemented in practice. According to Koskela et al. (1997)
the principle of optimizing the sequence can also be approached informally. If the projects type is familiar, the
designers will have a good feel about the optimal sequence of tasks. In design meetings, designers actively
present their input information needs regarding other designers, and the order of main design decisions is thus
agreed on.
17
Ballast Nedam
ADePT Methodology
Austin, et al. (1999) conclude that current building design planning practice gives little consideration to the
interdisciplinary, iterative nature of the process. Under this circumstance, the ADePT (Analytical Design
Planning Technique) is proposed. This project planning methodology helps to overcome these problems by
providing a logical, structured approach, based on information flow rather than the production of design
deliverables. It takes account of the iterative nature of design and can enable fully coordinated, integrated
design solutions to be developed within both budgetary and time constraints.
The first stage of the methodology is a model of the building design process, representing design activities and
their information requirements. IDEF0v is proposed as the most suitable modeling technique for construction
design in where all information requirements for a design activity can be presented.
Figure 4: IDEF0v modelling technique (Austin, et al. 1999).
The design process model (DPM) has a hierarchical structure, the first level of which sub-divides the process
into design undertaken by the professional disciplines: architecture, civil engineering, structural engineering,
mechanical engineering, and electrical engineering. There are different characteristics for each discipline
because of variations in the way they work. The DPM aims to describe the process at a non-specific level and
consequently it represents the design of a typical building and its systems.
For building design this means a basic model is developed at a non-specific level and consequently it represents
the design of a typical building and its systems. The project planning of a particular building will entail some
manipulation of the model to produce a project-specific process map.
The four engineering processes are partitioned into systems design. The design of the ground floor slab and
systems beneath it are civil engineering activities, while the design of above ground systems are represented
within the structural engineering model. The mechanical engineering section systems are decomposed further
into Requirements and Load Analysis, Schematic Design, Plant Layout Design and System Specifications
which are in turn broken down into individual design tasks. The electrical engineering section is represented in
terms of groups of systems such as Lighting Systems Design and Communications Systems Design before
being decomposed further into systems such as General Lighting Design and Emergency Lighting Design and
then into individual design tasks.
18
Ballast Nedam
The data in this model is linked via a dependency table to a Dependency Structure Matrix (DSM) analysis tool,
which is used in the second stage, to identify iteration within the design process and schedule the activities
with the objective of optimizing the task order.
There are many information dependencies between activities in complex problems such as construction design,
which can be clarified by accounting for different levels of information importance (strengths of dependency).
This can be done by classifying the dependencies within the matrix and using a partitioning algorithm that can
prioritize the sequencing of activities accordingly.
The classification of information within a matrix is a subjective exercise. Austin et al. (1996) described a three
point scale of classifications, used in ADePT, which is based on the strength of dependency of information,
sensitivity of activities to changes in information, and the ease with which information can be estimated within
the building design process, see figure 5.
Figure 5: The basis for allocating information classifications (Austin, et al. 1996).
To determine each information classification, three separate subjective judgments must be made and the
resulting classification is given a rating of either A, B or C (A being strong and C being weak). The philosophy
adopted by ADePT is that weak dependencies can be omitted from the matrix partitioning (because an
accurate estimate can easily be made), and therefore the size of iterative loops can be reduced and the design
process clarified.
The third stage of the methodology produces design programmes based on the optimized process sequence.
Finally, the fourth stage is where the design process is monitored and the flow of work is controlled. The
technique requires some iteration between the DSM and programming stages.
Figure 6: ADePT methodology (Austin, et al. 1999).
The detailed DPM and DSM tool offer an effective means of scheduling a design process based on the flow of
information through a project, rather than on the production of deliverables. The matrix indicates groups of
tasks that are interdependent and therefore require careful co-ordination. A project management program can
show the optimal design sequence (as determined by the matrix analysis tool) in the form of design
19
Ballast Nedam
programmes. These programmes highlight the iterative task groups identified by the matrix and ensure that
they are scheduled to take place in parallel, thereby reducing the likelihood and scale of redesign and
associated construction problems.
Practical implementation of ADePT
The most significant challenge lies in defining tactics to manage the design team as they work concurrently on
an interdependent design problem. There is no single solution as the number of activities and deliverables,
number of team members involved, and time required to develop the design will dictate the approaches used.
What is important is that each of these issues is thought about in turn and that an appropriate approach is put
in place.
The third stage of the methodology produces design programmes based on the optimized process sequence.
This process raises a number of issues. Conventional programming tools represent sequential processes and do
not allow elements of work containing iteration to be programmed. Thus, in current practice, feedback is not
identified, resulting in co-ordination failures and rework. With ADePT, the DSM analysis is used with a project
management tool, in order to demonstrate that these dependencies could be integrated with existing
construction planning systems, and a form of representation familiar to design planners and managers can be
used. This is done by grouping tasks that form a loop under a rolled up activity and removing
interrelationships from within the loop so that they can be programmed to occur in parallel. However,
establishing the effects of tearing an information dependency can prove difficult when a loop consists of a large
number of tasks and interrelationships.
In current practice, design is largely programmed to release information to suit the construction stage. The
proposed approach is fundamentally different in first producing an optimal programme to suit design, which is
then modified as it is integrated with a procurement and construction programme. In practice, it is unlikely that
the optimal sequence of design tasks will be realistic because of the production constraints put on the process
by the need to deliver a project in a short a time-scale as possible. However, comparison with a view of the
ideal construction sequence should provide a good starting point to integrate design within the wider project
process.
Evaluation of ADePT methodology
All stages of ADePT have been validated by Austin et al. (2000) though their application to a series of building
projects under construction. The design process model has been validated by producing project-specific
models and a broad range of design work has been embraced. The first task in formulating each project-specific
model is to ensure that the Desgin Process Model has an appropriate content and structure. This requires the
deletion of design activities from the generic model that are not relevant to the project, and the addition of
tasks associated with features of the building not already included.
The output from the DSM tools and corresponding design programmes have been compared with the planning
that was undertaken in practice. This has shown that the programmes used in practice did not take full account
of the iteration within the design process, and that the design had been planned almost entirely to suit the
construction process. Advantages of the ADePT methodology mentioned are among others (Newton, et al.
2007):
20
Ballast Nedam
Greater certainty of design coordination

Offers an ability to better prioritize design work
Improvement of collaboration between design members
However, the implication of ADePT cannot be accomplished without some sacrifices. The project teams must
be prepared to invest in the adoption of the new approach. Next to the extra costs for the consultancy support
and tools to deploy the ADePT technology, also a lot of extra time has to be contributed. It is necessary to
spend more time than is typical in current practice in order to produce a meaningful programme with ADePT.
All the parties in the design process have to describe all the design activities, and their dependencies and
information requirements carefully, which is a very time consuming effort. This asks for dedication and timeefforts, not only of the main contractor but of all the design disciplines involved.
DIMS Methodology
Design has a numerous amount of interdependent, knowledge intensive multidisciplinary tasks and the overall
process is inherently iterative in nature which makes design hard to structure (Varghese and Senthilkumar,
2008). Managing this phase requires a careful planning and coordination of the information exchange between
the several engineering disciplines. Varghese and Senthilkumar (2008) present a structured method to organize
the interfaces and interactions between the various design disciplines, the Design Interface Management
System (DIMS).
To facilitate the integration of the disciplines which will make up the overall design of the project, a Design
Interface Management Plan (DIMP), has to be developed. The issues of design interfaces can be solved in two
phases. The first phase is of a proactive measure to identify interfaces, and the second phase is a reactive
measure to resolve the interface problems which are not identified in the first step.
The first phase will exist of the following steps:
-
Divide the project in manageable portions (i.e. sub-systems, components) for which the interface
documentation is developed.
Identify the design interfaces between these elements in the early stages.
Couple the interfaces to the objects and add information such as responsible parties, scheduling,
design requirements and design parameters etc.
Integrate the disciplines for identified design interfaces.
Document, review and revise these interface issues for timely actions.
The second phase will exist of the following steps:

-
Compare the interfaces in a physical sense by providing an environment where each designer can
actively compare their work against all other current designs.
Identify the existence of design clashes.
Report and resolve in an organized matter.
A good communication mechanism is required in order to minimize the delays and impact due to design
changes. This mechanism should ensure that all design changes are identified, reviewed, approved and
communicated to all affected parties and functions. The change management processes will be reviewed as
part of the interface management processes.
21
Ballast Nedam
Interface Management Methodology

The proposed interface management methodology has three main steps which are definition, capture and
management/control. In the definition stage, the main project elements are listed out in the System
Breakdown Structure (SBS) prepared by the main contractor(s). In this phase the scope for each contractor is
clear, and the project is decomposed to portions which are manageable by individual design teams.
During the capturing stage, all parties involved to the design phase are required to identify their interfaces with
other design parties, vendors and client by a suitable tool through workshops or brainstorming sessions.
Next, the details of the identified design interfaces are discussed with other interfacing parties and are
documented during the interface meetings. As part of the discussions concerning the interface, a realistic date
by which the interface design information is to be available and shall be closed, shall also be identified. This
date will be adhered to by both the interfacing parties.
It is also the responsibility of the individual design teams to prepare, maintain and update the interface record.
Each design discipline is also required to prepare a list of major outstanding interface issues which have the
potential to affect scope, costs or schedule aspects of the design contracts.
The design manager shall keep the design discipline advised of any change in the status of all such interface
issues, and obtain the assistance of the design disciplines as appropriate. Any discrepancies, inconsistencies or
errors, identified by any reviewer, shall be notified to the originator and the other related parties of the
interface.
Modified Design Organization
The interface team is managed by the project interface manager, and is assisted by the interface coordinators
for each design team in the design process.
From each design team a coordinator is designated to act as an interface coordinator for their
discipline, which is usually the design leader. These coordinators will carry out the interface management tasks
such as interface identification, documentation and solving any interfacing issue that occurs, in addition to
their regular work. The discipline interface coordinators attend the regular scheduled weekly design interface
meetings and raise the issues which relate to their discipline and give inputs on the requirements of other
disciplines. All the interfacing issues and their corresponding resolutions data needs to be documented and
updated.
Drawing DSM (DDSM) methodology
It is cumbersome to capture the design interfaces or information dependencies in a complex design process. A
network diagram cannot show the details as the number of entities and their dependencies are large on most
projects. For this reason the DSM methodology is used to capture all the interfaces. However, in most DSM
based methodologies, the design schedule is modeled using an activity based DSM (Maheswari, 2006, Tuholski
and Tommelein, 2010). As activities can be defined at many levels, varying from a very detailed level to a high
level of abstraction, finding the suitable level of abstraction to formulate the activity DSM is very difficult. The
selection of appropriate abstraction level to represent an activity is critical to the practical utility of DSM.
Moreover, the guidelines suggested in the existing DSM methodologies require significant investment of the
22
Ballast Nedam
designers time to identify the appropriate matrix elements (activities) and foresee its interfaces (Helgerson, et
al. 2009).
The DIMS methodology proposes to capture the design interfaces at drawing level through formulating a
Drawing DSM (DDSM). As drawings are well defined entities, it was found that, capturing the interfaces at
drawing level can eliminate the ambiguity of selecting the appropriate abstraction level. In addition, a
structured decomposition procedure was also proposed to identify the design interfaces among the drawings
and transform these dependencies to identify relationships between other design entities. The workflow of the
decomposition procedure was automated using a server-based tool. As a result, it facilitated the participation
of all members of the design team (Senthilkumar, et al., 2010).
However, one of the key challenges in basing design management on a DDSM is that the designers cannot
identify the information dependencies between the drawings directly, as the relationships between drawings
are numerous and are not apparent at the initial design stage and at higher levels of abstraction. Further, the
DDSM is dynamic and will continue to evolve as detailed design progresses.
In order to formulate the DDSM, the following fundamental (conceptual) steps are proposed.
23
Ballast Nedam
Figure 7: DDSM formation methodology (Senthilkumar and Varghese, 2009).
Entity - Identification
Figure 8 shows a systematic decomposition framework used to identify entities for a generic project. Of the
entities, drawings and parameters entities (shaded) cannot be comprehensively identified at the initial stages
of the design and will evolve as the design progresses.
24
Ballast Nedam
Figure 8: project decomposition framework (Senthilkumar and Varghese, 2009).
Interface - Identification
This stage focuses on identifying the interfaces between the main components, subcomponents and teams.
This stage requires inputs from all stakeholders and can be in the form of workshops. The resulting interfaces
are represented in the form of a physical interface matrix (PIM) and a design interface matrix (DIM).
The DIMS tool generates the framework for Physical Interface Matrix (PIM) automatically from the defined
entities. PIM is a dynamic matrix and it gets updated when an entity is added / removed from the database to
accommodate the frequent scope change in fast-track projects. During the first session of the workshop, the
users were asked to identify physical interfaces between the already defined main components and
subcomponents in the PIM structure.
Figure 9: Physical Interface Matrix (PIM) (Senthilkumar and Varghese, 2009).
The system generates the Design Interface Matrix (DIM) structure automatically from the PIM. During the
second session of the workshop, the design interfaces were captured by each team. This workshop facilitates
25
Ballast Nedam
the interface identification process as the participants from all the teams were present in the common working
forum (workshop). The physical interfaces forms the basis for the designers to identify the design interfaces.
Figure 10 shows the generated DIM for main component 1.
Figure 10: Design Interface Matrix (DIM) of main component 1 (Senthilkumar and Varghese, 2009).
The shaded area represent the teams involved in the design. The DIM rows have two sections, the shaded
section represents the teams involved and the bottom section represents the subcomponents that have a
physical interface with main component 1, as identified in the PIM. The team versus subcomponent interfaces
are helpful in order to identify team versus team interfaces, since it is easier to identify the design interfaces if
the designer is focused on specific subcomponents.
The corresponding interfacing teams were notified by a system generated email as and when an issue is
generated. In response to the email, a response forms has to be filled in. These responses are updated in the
Design Interface Agreement (DIA) accordingly in the systems database. The DIA requires the documentation of
specific interface issues, the teams involved, the interface agreement reached and the status of that
agreement. The DIM is updated with colored symbols based on its status. The priority interfaces, identified
based on construction schedule, are notified with the red blink to assist the designers in resolving the issues.
Though the users interact through web, weekly interface meeting interactions were required especially when
an interface issue required collaboration among two or more teams. Further, the priority issues were also
26
Ballast Nedam
resolved during these meetings to meet the construction schedule. Hence, the weekly interface meeting was
mandatory. The interface discussions in these meetings are facilitated with the system generated report by
each team. Each team has two types of issues which are issues which need to be resolved by others, and issues
which need to be resolved within the own team. Further, the above two categories are grouped in priority
issues and non priority issues. The categorized report can be generated by the system.
Finally, each design team mapped the generated issues as input/output of their drawings. The system
generated the DDSM using the issues-drawings relationships established, as is shown in figure 11. This
approach of mapping the interface issues as input/output reduces the effort required in identifying the drawing
dependencies, compared to conventional DSM methodologies. The DSM captures the design interfaces
between the drawings, and strives for an optimal drawing release sequences.
Figure 11: Framework to create DDSM (Senthilkumar and Varghese, 2009).
Evaluation DIMS Methodology

Varghese and Senthilkumar (2012) implemented and tested the Design of Interface Management System
(DIMS) in construction on the design of an airport (Varghese and Senthilkumar, 2008). The project was
decomposed into many small manageable modules, and the drawings produced by various disciplines for each
27
Ballast Nedam
module were identified, and were listed as rows and columns headings to develop the drawing DSM. After the
DDSM was formulated, the design experts from all the involved disciplines were invited for capturing the
interfaces of the drawings.
Since the airport consists of large number of components and design drawings, the DSM methodology of
capturing the drawing interfaces cannot be done manually. The interface capture process during the design
interface meetings and the workshops was difficult, because of the large size of the matrix (100x100). The
designers were finding difficulties in managing the size of the matrix. Therefore, it was decided to decompose
the project into manageable levels of sub-components and the DSM is developed for each of these subcomponents, but the inter-component interfaces were not addressed in the above methodology (Senthilkumar
and Varghese, 2008).
The difficulty of the DSM methodology implementation in construction lies with the decomposition of the
project design process, and the size of the DSM matrix. It seems that the number of elements (drawings)
involved in the construction design process is more compared to the manufacturing, software and product
development (Varghese and Senthilkumar, 2008).
Furthermore, though the system can determine the sequence of drawing release as a part of the DSM
process, the designers were averse to use this because of the sequence was pre-determined by construction
requirements. The construction requirements were pulling the design sequence.
However, the results of working with the DIMS methodology is promising. The effectiveness of design interface
management was assessed through the quantifiable criteria such as the number of revisions, the delay in first
submission, the number of site rework and design productivity. Results from a case studies showed a positive
results in all of these fields. The drawing revisions, for instance, were lowered by 1/3 compared to the test case
(Varghese and Senthilkumar, 2012).
The designers were of the opinion that the DIMS methodology provided a forum to make collaborative
decisions during the design process, especially during the workshop for developing the PIM and DIM.
The designers were of the opinion that the discussions during the workshops had pro-actively matched the
teams which required close interaction for the exchange of information.
Moreover, the workshops resulted an increase in awareness of the specific information interdependencies. Assumption were made after appropriate discussions among the respective designers, which
resulted in a reduction of rework and revisions. Besides, also a reduction in site rework was recognized in the
case study. The collaborative information sharing among the design participants was acknowledged as a key
driver for the production of error free Good for Construction drawings (Varghese and Senthilkumar, 2012).
The web-based tool established the communication templates, reduced the communication lead time, kept
track of commitments and documented the communications. Together with the alert mechanism of the DIMS
tool, which periodically notified specific individuals about their information requirements to meet the
approaching deadlines, these aspects had a significant role in eliminating delay (Varghese and Senthilkumar,
2012).
28
Ballast Nedam
Parameter based DSM

The parameter-based DSM is a square matrix which defines the dependencies between parameters. The tool is
similar to activity-based DSM, but it is used for low-level process sequencing. Thus, the level of analysis
constitutes a main difference between activity- and parameter-based DSMs. These two types of DSMs also
differ in the scope of their representations. While an activity-based DSM includes reviews, tests, and analyses,
a parameter-based DSM documents the physical and rational relationships between the parameters that
determine design.
Pekta and Pultar (2006) propose a parameter-based DSM in order to model the detailed information flows in
the design process. The collaborative building design process is viewed as an iterative flow of interdependent
decisions of different design professionals. According to them, the parameter-based DSM reveals insights into
the process structure, optimum sequence of parameter decisions, iterative cycles and concurrency in the
process.
Next to Pektas and Pultar (2006), also Chua, et al. (2003) proposes a parameter based model. In their research
a Process-Parameter-Interface (PPI) model is proposed as part of their methodology, see figure 12.
According to Chua et al. (2003) the potential of efficiency gains in the flows in the architectureengineering-construction (AEC) design processes is promising and there is a need for reducing the wastes
related to flows, such as waiting for information, transformation of information and inspection. The PPI model
aims at achieving lean philosophy objectives, such as, reduction in the share of non-value adding activities,
increased transparency, process simplification and increased output flexibility.
Due to the fact that the several engineering disciplines mainly work in isolation, rework loops occur when the
specialist confirm their design with one another. Any change required in the design may lead to expensive
rework. Main cause of these late conflicts is that the design disciplines are all unaware of each others design
parameters, particularly in the detailed design phase. This unawareness leads to an overall design process that
is sensitive to conflicts and, consequently, to numerous rework loops. In addition, the coloration between the
specialist is quite passive and only triggered by a potential conflict foreseen by a design specialist or when a
conflict is discovered during the collaboration at the drawings level.
29
Ballast Nedam
Process-Parapmeter-Interface Model
Figure 12: Process-Parameter-Interface (PPI) Model for lean design management (Chua, et al. 2003).
Design iterations and rework form a major part of non-value adding activities in the AEC design processes.
These design reworks can be avoided by active collaboration among the design specialists over key design
parameters. This is facilitated by the PPI model engine, which generates a sequence, optimized with respect
to the number and length of rework loops. Besides, the engine also prompts the appropriate design specialists
at appropriate times for the design parameters that they need to produce. The model comprises a design
dictionary, which imparts transparency. Transparency is further facilitated by means of Interfaces. Process
simplification is achieved through the use of the design dictionary while output flexibility is increased by
frequent proactive collaboration among the design specialists facilitated by the model engine.
The design dictionary described the key parameters and includes aspects as estimability, volatility and owner.
The rate of estimability describes how well a parameter can be assumed or estimated, in case the parameter
value is unavailable. The volatility indicates the degree of potential change of the design parameter due to an
external environment or other agencies. The owner refers to the design specialist who owns a particular
parameter. By owning a parameter, the specialists has the freezing command over it.
The parameters collected are attached to design tasks in the Information Requirement Matrix (IRM) and the
Information Production matrix (IPM). In the IRM the design disciplines place the parameters required for
specific design tasks, while in the IPM the same designers indicate what parameters will be produced as output
of those design tasks.
30
Ballast Nedam
The PPI Model Engine as indicated in figure 12 generates a sequence, in which the key design parameters
involved in the design process, must be produced. This sequence is such that the rework loops are minimized.
The methodology to sequence the design process is based on the DSM. In this DSM the parameters are placed
and their dependencies in order to see in what sequence the parameters should be determined.
Validation PPI Model
Unfortunately, no validation or implementation of the PPI model has been executed so far. Therefore it is not
as easy to evaluate the methodology. However, the parameter based DSM described by Pekta and Pultar
(2006) was tested on a suspended ceiling for a public building in Turkey. Data was collected through interviews
with designers, which was an iterative and time-consuming process. The biggest challenge of the proposed
parameter-based DSM approach is the large number of parameters involved in building design. The number of
parameters needed to fully determine the properties of a product depends on its complexity. Rouibah and
Caskey (2003) estimate that an automobile can be described by 105 - 106 parameters, while an aircraft or ship
may have more than 106 . A equal amount of parameters is to be expected for complex infrastructure projects
(Rouibah and Caskey, 2003).
It would be a quite time consuming task to write down all these parameters, of which many do not even cross
intra-disciplinary boundaries. As said are the most relevant interfaces those which cross contractual
boundaries. A careful selection to identify the most critical parameters could simplify the model. However, this
selection is already a quite time consuming process of itself, which requires the collaboration of all design
disciplines. Furthermore, developing an optimal design sequence cannot be determined by only the most
crucial parameters since these could be dependent on other, less crucial, parameters. If these relationships are
not captured, an proposed optimized schedule will have way less value.
31
Ballast Nedam

PM Approach

Hochgeladen von

Dokumentinformationen

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

PM Approach

Hochgeladen von

Copyright:

Verfügbare Formate

Interface Management in multidisciplinary infrastructure project development

Interface Management in multidisciplinary

MSc Thesis | Construction Management and Engineering

Interface Management in multidisciplinary infrastructure project development

S.A. (Sebastiaan) Staats

Dr.ir. G.A. van Nederveen

Ir. T.J. van Beek

Ing. S.L. van der Geest

Technical University of Delft

Interface Management in multidisciplinary infrastructure project development

Technical University of Delft

Interface Management in multidisciplinary infrastructure project development

Technical University of Delft

Interface Management in multidisciplinary infrastructure project development

Technical University of Delft

Interface Management in multidisciplinary infrastructure project development

Technical University of Delft

Interface Management in multidisciplinary infrastructure project development

Technical University of Delft

Interface Management in multidisciplinary infrastructure project development

Technical University of Delft

Interface Management in multidisciplinary infrastructure project development

Technical University of Delft

Interface Management in multidisciplinary infrastructure project development

Technical University of Delft

Interface Management in multidisciplinary infrastructure project development

Technical University of Delft

Interface Management in multidisciplinary infrastructure project development

Technical University of Delft

Interface Management in multidisciplinary infrastructure project development

Technical University of Delft

Interface Management in multidisciplinary infrastructure project development

Technical University of Delft

Interface Management in multidisciplinary infrastructure project development

Technical University of Delft

Interface Management in multidisciplinary infrastructure project development

Technical University of Delft

Interface Management in multidisciplinary infrastructure project development

Technical University of Delft

Interface Management in multidisciplinary infrastructure project development

Technical University of Delft

Interface Management in multidisciplinary infrastructure project development

Technical University of Delft

Interface Management in multidisciplinary infrastructure project development

Research goal and objectives

Investigating the main factors causing integration issues

Technical University of Delft

Interface Management in multidisciplinary infrastructure project development

Why is interface management becoming more important nowadays? (3.1.3)

How is interface management proposed in literature on Systems Engineering? (3.3.3)

What interface management related research has been done? (Ch.4)

How is Interface Management implemented in practice? (5.3)

How does the interface management process look like?

b) What tools are used to support Interface Management?

What are the main factors causing integration issues? (Ch.6)

Technical University of Delft

Interface Management in multidisciplinary infrastructure project development

Chapter 2: Research methodology

Technical University of Delft

Interface Management in multidisciplinary infrastructure project development

Case study selection criteria

Technical University of Delft

Interface Management in multidisciplinary infrastructure project development

Johan Frisosluis Stavoren