Interface Management in multidisciplinary infrastructure

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

I Technical University of Delft Ballast Nedam

Interface Management in multidisciplinary infrastructure project development 2014

Colophon

Report Type: Graduation report Title: Interface Management in multidisciplinary infrastructure project

development Subtitle: Diminishing integration issues across contractual boundaries in a

Systems Engineering environment Place: Lexmond Date: Monday, 3 March 2014 Author Name: S.A. (Sebastiaan) Staats Study number: 1339133 Telephone number: +31(0)6 48 01 88 14 E-mail address [email protected] Course: CME2000 – Graduation Thesis Master: Construction Management and Engineering (CME) University: Delft University of Technology

Faculty of Civil Engineering and Geosciences Graduation committee Chairman:

Prof.dr.ir. M.J.C.M Hertogh

Delft University of Technology

Faculty of Civil Engineering and Geosciences

[email protected]

First commissioner: Dr.ir. G.A. van Nederveen Delft University of Technology Faculty of Civil Engineering and Geosciences [email protected]

Second commissioner: Ir. T.J. van Beek Delft University of Technology Faculty of Mechanical, Maritime and Materials Engineering [email protected]

External commissioner: Ing. S.L. van der Geest Ballast Nedam BV Afdeling Proces Informatie Management (PIM) [email protected]

II Technical University of Delft Ballast Nedam


III Technical University of Delft Ballast Nedam

2014 Interface Management in multidisciplinary infrastructure project development

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

IV Technical University of Delft Ballast Nedam


V Technical University of Delft Ballast Nedam


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,

VI Technical University of Delft Ballast Nedam


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. Interface Identification

2. Interface Documentation

3. Interface Communication

4. Interface Control

5. 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.

Interface Identification

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.

Interface Documentation

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.

Interface Communication

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.

VII Technical University of Delft Ballast Nedam


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 project’s 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.

VIII Technical University of Delft Ballast Nedam


IX Technical University of Delft Ballast Nedam


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 geïntegreerde projecten te organiseren is Systems

Engineering (SE) geïntroduceerd. 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 coördinatie 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

categorieën, namelijk (1) een slechte communicatie tussen de partijen en (2) een slechte coördinatie tussen de

partijen.

X Technical University of Delft Ballast Nedam


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. Raakvlak identificatie

2. Raakvlak documentatie

3. Raakvlak communicatie

4. Raakvlak controle

5. 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 coördinator 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 geïdentificeerd worden door naar het systeem te kijken vanuit drie perspectieven,

namelijk de functie-, objecten-, en eisenboom. Deze raakvlakken zijn hoofdzakelijk geïdentificeerd 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 strategieën 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 strategieën om het proces te versnellen, maar

brengen ook extra risico mee voor het project. Daarom moeten vóór de toepassing van deze strategieën de

mogelijke consequenties zorgvuldig worden onderzocht.

XI Technical University of Delft Ballast Nedam


Raakvlak controle

Raakvlakken kunnen risico’s 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 geïntegreerd 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

coördinatie 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.

XII Technical University of Delft Ballast Nedam


XIII Technical University of Delft Ballast Nedam


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

XIV Technical University of Delft Ballast Nedam


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

XV Technical University of Delft Ballast Nedam


Abbreviations

AI Action Item

ADEPT Analytical Design Planning Technique

BIM Building Information Model

CE Civil Engineering

CM Configuration Management

CMP Configuration Management Plan

CR Change Request

DBFM Design, Build, Finance and Maintain

DC Design & Construct

DIMS Design Interface Management System

DMS Document Management System

DSM Dependency Structure Matrix

EE Electrical Engineering

E&I Electrical and Instrumentation

FBS Functional Breakdown Structure

IA Interface Agreement

IBS Interface Breakdown Structure

ICD Interface Control Document

ICP Interface Control Plan

ID Identification

IDD Interface Definition Document

IM Interface Management

IMP Interface Management Plan

INCOSE International Council on Systems Engineering

IR Interface Register

IRD Interface Requirements Document

ME Mechanical Engineering

MEP Mechanical, Electrical and Plumbing

OBS Organizational Breakdown Structure

PMP Project Management Plan

PPI Process Parameter Interface

RBS Requirement Breakdown Structure

RM Risk Management

RMT Requirements Management Tool

SE Systems Engineering

SBS System Breakdown Structure

VDC Virtual Design and Construction

WBS Work Breakdown Structure

XVI Technical University of Delft Ballast Nedam


1 Technical University of Delft 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 sub-

systems, 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 (D’Amelio, 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.



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 Airbus’s A380 superjumbo suffered major delays and cost overruns because of late

inadequacies in the design of the electrical harnesses of various sections of the plane’s 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.



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



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, sub-

questions 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.



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;



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.



Johan Frisosluis Stavoren

Figure 2: Sketch of the Johan Frisosluis te Stavoren (Interra).

Principal: Provincie Friesland

General contractor: Ballast Nedam Infra

Other main (sub)contractors involved: Machinefabriek Emmen, Croon Elektrotechniek, Royal Haskoning

and Sterk.

Contract: Design, Construct and Maintain (DCM)

Summary:

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.



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.



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



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 high-

performance 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.



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.



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.



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 INCOSE’s 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).



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 sub-

systems 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.



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,



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:



‘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.



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. “The identification and description of interfaces as part of system concept definition” and

2. “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. Identification of the interfaces

2. Description of the interfaces

3. Coordination of the interfaces

4. Control of the interfaces



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 sub-

question 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.



Figure 12: Interface Management Process (NASA, 2007).

Input:

Typical inputs needed to understand and address interface management would include the following:

System Description: Allows the design of the system to be explored and examined to determine

where system interfaces exist.

System Boundaries: Document physical boundaries, components and subsystems, which are all

drivers for determining where interfaces exist.

Organizational Structure: 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.

Boards Structure: The Systems Engineering Management Plan (SEMP) should provide insight

into organizational interface responsibilities and drive out interface

locations.

Interface Requirements: Document the internal and external functional and physical interface

requirements.

Interface Change Requests: 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,



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 Documentation

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 “one-

sided 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.



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).



‘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).



The process of IM is schematically shown in Figure 14. In here, a clear distinction is made between inter-

disciplinary 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 product’s 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 entity’s 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).



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.



.

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:

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.



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 project’s 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.



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.



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).



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. Semi-

independent 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



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.



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.



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.



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 client’s 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).



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 other’s 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



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, larcón 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 (larcón 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 (larcón 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



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



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-to-

face, 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).



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 team´s 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.



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 pre‐fabricate, 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 3D‐4D (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



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 sub-

system 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 project’s 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.



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.



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 sub-

question ‘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 project’s 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 Process monitoring and coordination (in control of Requirement

Management Tool (RMT) ‘Relatics’);

• Machinefabriek Emmen Mechanical engineering structures;

• Croon Electrical installations;

• Sterk Sheet piles, fenders and mooring facilities;

• BN Bouw en Ontw. Structural Engineering of the operating office;

• Royal Haskoning Concrete Structure of the lock heads, road construction and planning of

project area.

Figure 23: The Johan Frizosluizen in Stavoren (Provincie Fryslân, 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,



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 DCM-

contract, 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 project’s 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: Collection of data, assumptions, prerequisites and requirements and the

organization of the available data;

2. Generating solutions: Working out the design documents and visualize the design (preparation of

drawings and reports);

3. Interface Management: Identification and management of interfaces in order to let the design parts

connect to each other and the environment well;

4. Verification: Prove that the design complies with all the requirements coming from the

contract.

5.2.1 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.

Document Management System

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.



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



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 Interface Management

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.



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



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



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.



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.



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 lay-

out 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



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



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



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



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 sub-

contractors 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.



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.



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 other’s processes and activities. Without sufficient communication and coordination misunderstandings could easily occur.



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.



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; Al-

Hammad, 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



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’. larcón 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



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



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 other’s 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



mechanical and/or electrical contractor’s business or what they are supposed to do on the job (Orth and Mains,

2008). The lack of knowledge in each other’s 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.



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.



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;



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. Intra-

disciplinary 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 contractor’s 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



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 everyone’s 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.



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. Interface Identification

This phase includes the identification of the interfaces in the project.

2. Interface Documentation

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. Interface Communication

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.



Figure 32: Flowchart of the IM process.



7.3 Interface Identification

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.



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 sub-

system. 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



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 inter-

disciplinary 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 Interface Documentation

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.



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: ID number of the interface;

Interface title: Interface title;

Interface description: Short description of the interface;

Type of interface: External, Inter- or Intra-disciplinary;

Status: Open, In progress or Closed;

Object –IDs: ID number of the objects attached;

Objects involved: Title of the objects attached;

Involved contractors: Name of the parties involved.;

Interface agreement ID: ID number of the Interface Agreements (IAs) attached ;

Requirement ID: ID number of the derived requirement;

Responsibility: Name of the responsible interface coordinator/contractor;

Risk: 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. Risk

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 ćlosed´ 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

Òpen` or Ìn 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



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.



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 project’s 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: The party responsible for the interface overall performance, and approves the

accuracy of interface characteristics (i.e. the requester of interface information or

deliverables).

Accountable: 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.

Supportive: 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).

Consulted: The party who responds to the IAs and provides the deliverables.

Informed: 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

Contractor A Contractor B … Contractor i

RV1 R A S, C I

RV2 A, S R C

RV3 I A R C

…

RVi S A C R I



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 object’s

designer.

Looking at the type of dependency, it becomes clear that two objects, involved in an interface, could be one-

way 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



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



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.



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.



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 Interface Communication

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 project’s 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.



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, face-

to-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.



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 project’s 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 product’s life cycle, that controls and monitors changes which

could affect performance, functional or physical characteristics. 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. 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



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 1510 1520 2111 2112 2113 2121 2131 2132 2133

1100

1200

1300

1400

1510 1.8 1.11

1520 1.14

2111

2112

2113 6.5

2121 1.4 2.1

2131 5.1

2132 3.8

2133 3.3 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 organization’s 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.



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 planner’s 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



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 Document Management System

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.



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.



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.



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 team’s 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 team’s 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



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.



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 Answering of the sub-questions

1. 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



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 3D-

design 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



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.



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 sub-

systems 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.



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



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 project’s 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



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.

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



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:



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 won’t 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 EE’s

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 project’s efficiency.



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.



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. Alarcón, 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. 829–837.

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.



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. 291–299

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 Management—A 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/>

D’Amelio, 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



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 Für 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, DSM’09,

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, 3758.

Jager, J. (2013). “Nieuwe contractvormen, 10 mythes en hoe het werkelijk zit.” Infra, februari 2013, nr. 1, p. 22-

25

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, November‐December 2003, p. 627‐634,

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:



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) 1–17.

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.

http://www.relatics.com/nl/product/



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 Fryslân. (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. 858–865.

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-another-

when-they-should>



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 São 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.” Gestâo & 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. 197–212

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



Verganti, R. (1997). “Leveraging on systematic learning to manage the early phases of product innovation

projects.” R&D Mgt., vol. 27, no. 4, pp. 377–392.

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



2014

Appendices

Table of contents

Appendix A Templates Interface Control Documents.....................................................................................2

Appendix B Interface Matrix of the Johan Frisosluis......................................................................................3

Appendix C System Breakdown Structure of the Johan Frisosluis.................................................................4

Appendix D Verification factors causing integration issues ...........................................................................5

Appendix E Implementation IM process in Relatics .......................................................................................7

Appendix F Standardized forms ....................................................................................................................11

Appendix G Description DSM methodology ..................................................................................................15



2014

Appendix A

Examples of Interface Control Forms used at different organizations.


Appendix B

Part of the interface matrix as used at the Johan Frisosluis in Stavoren.


Appendix C

System Breakdown Structure (SBS) of the Johan Frisosluis in Stavoren:



2014

Appendix D

Table 1: Verification of the factors causing integration issues with findings from literature.

Case Study Literature

The engineering disciplines possess specific

knowledge and speak their own ‘language’, leading to

misunderstandings.

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 (Al-

Hammad 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; larcón 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 (Al-

Hammad 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; larcón 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

(larcón and Mardones, 1998).

The need for correcting design errors (Anumba, et al.

2007).

Designers with little knowledge (larcón and

Mardones, 1998); defects of individual specialists

(larcón and Mardones, 1998).


The engineering disciplines work from another

location which complicates direct communication and

collaboration.

Poor communication (Fritschi, 2002).


al. 1996).

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).

No clear definition of tasks (Fritschi, 2002).


al. 1996).

Poor communication (Fritschi, 2002).

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. Poor communication (Fritschi, 2002).

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 (larcón and Mardones, 1998).



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:


Interface ID: ID number of the interface;

Interface title: Interface title;

Interface description: Short description of the interface;

Type of interface: External, Inter- or Intra-disciplinary;

Status: Open, In progress or Closed;

Requirement: Title, ID, description and verification status if a requirement is derived from the interface;

Leading and intersecting objects: Title and ID of objects;

Interface agreements: Title, ID, description, requester, responder, due date and status of all IAs;

Action items: Title, ID, description, person, due date and status of all AIs;

Related activities: WBS activity ID, status, role and person;

High risks: Title, ID-number, description;

Verification plan: Document title, document ID, status, role, person;

Further documents: 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: ID-number IA

Attached interface: Interface title and ID

Attached objects: Involved objects’ titles and IDs

Requester: Requesting party

Responder: Responding party

Required information or deliverable(s): Description of the interface information or deliverables

Responding document(s): Document title and ID

Action items ID’s: ID-number, Description, Roles, Due dates, Status

Need date of the agreement: Due date

Verification of the deliverables: Status

Finish date : Date when the interface conditions have been met


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.


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.


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 ID number of the interface

Title Interface title

Description Short description of the interface

Type of interface External, Inter- or Intra-disciplinary

Status Open, In progress or Closed

Leading and intersecting object

Leading object Object 1

Intersecting object Object 2

Requirement

Req. title Req. ID Req. description

Title ID-number Short description

Interface Agreements

IA Title IA ID IA desription Requester Responder Due date Status

Title ID-number Short description Contractor Contractor Date Open/Closed

Action Items

AI Title AI ID AI desription Person Due date Status

Title ID-number Short description Responsible person Date Open/Closed

Attached risk

Risk Title Risk-ID Description



Verification plan

Document title Document-ID Status Role Name

Title ID-number Open/in progress/approved Responsible role Responsible person

Related activities

Activity ID Status Role Person

Activity out of the WBS open/in progress/closed Responsible role Responsible person

Further documents

Document title Document-ID Document description


Additional comments

Additional comments


Interface Agreement Form:

Interface Agreement

General information

ID-number ID number of the IA

Title 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

Deliverable 1 Specific description of the required interface information or deliverables

Responding document(s)

Document title Document ID Additional comments

Title ID-number Additional comments

Action Items

AI Title AI ID-number AI desription Person Due date Status Verified

AI title 1 ID-number Short description Responsible person Date Open/Closed By 'name person'

AI title 2 ID-number Short description Responsible person Date Open/Closed By 'name person'

…

AI title n ID-number Short description Responsible person Date Open/Closed By 'name person'


Due date of the agreement

Due date Date

Received date Date when deliverables are received

Verification of the deliverables

Deliverables verified Verified Yes/No

Date of verification Verification date

Verified by Name of responder which verified the deliverables

Comments Extra comments

Extra comments

Extra comments

Signatures

Requester Responder

Agree with the content of the IA

Date

Signature

Name

Closure of the IA Date

Signature

Name



2014

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)


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 unit

relationships

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


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 project’s 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.


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.


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


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):


- 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 time-

efforts, 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.


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


designer’s 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.


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.


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


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 system’s 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


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.

Interface Management

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


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 sub-

components, 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 inter-

dependencies. 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).


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 architecture-

engineering-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 other’s 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.


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.


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.