Interface Management in multidisciplinary infrastructure project development

(1)

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

(2)

I

Technical University of Delft Ballast Nedam

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]

(3)

(4)

III

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

(5)

(6)

V

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,

(7)

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.

(8)

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.

(9)

(10)

IX

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.

(11)

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.

(12)

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.

(13)

(14)

XIII

XIV

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

(16)

XV

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

(17)

(18)

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

(19)

2

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.

(20)

3

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

(21)

4

Technical University of Delft Ballast Nedam 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-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.

(22)

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

(23)

6

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

(24)

7

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.

(25)

8

Technical University of Delft Ballast Nedam 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.

(26)

9 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

(27)

10

Technical University of Delft Ballast Nedam 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;

(28)

11

Technical University of Delft Ballast Nedam 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.

(29)

12

Technical University of Delft Ballast Nedam 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.

(30)

13

Technical University of Delft Ballast Nedam 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).

(31)

14

Technical University of Delft Ballast Nedam 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.

Interface Management in multidisciplinary infrastructure project development