Interface Management in multidisciplinary infrastructure project development

Transcription

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,

2 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 Author Name: S.A. (Sebastiaan) Staats Study number: Telephone number: +31(0) address Sebastiaan_staats@hotmail.com Course: CME2000 Graduation Thesis Master: Construction Management and Engineering (CME) University: Delft University of Technology Faculty of Civil Engineering and Geosciences Graduation committee Chairman: First commissioner: Second commissioner: External commissioner: Prof.dr.ir. M.J.C.M Hertogh Delft University of Technology Faculty of Civil Engineering and Geosciences m.j.c.m.hertogh@tudelft.nl Dr.ir. G.A. van Nederveen Delft University of Technology Faculty of Civil Engineering and Geosciences g.a.vannederveen@tudelft.nl Ir. T.J. van Beek Delft University of Technology Faculty of Mechanical, Maritime and Materials Engineering thomvanbeek@gmail.com Ing. S.L. van der Geest Ballast Nedam BV Afdeling Proces Informatie Management (PIM) s.vd.geest@ballast-nedam.nl I Technical University of Delft Ballast Nedam

3 II Technical University of Delft Ballast Nedam

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

5 IV Technical University of Delft Ballast Nedam

6 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, V Technical University of Delft Ballast Nedam

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

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

9 VIII Technical University of Delft Ballast Nedam

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

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

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

13 XII Technical University of Delft Ballast Nedam

14 Table of Contents Executive Summary... V Samenvatting... IX Table of Contents... XIII Abbreviations... XV Chapter 1: Introduction Background Problem Description Research goal and objectives Research questions...4 Chapter 2: Research methodology Research design Research constraints Research approach Report overview...7 Chapter 3: Literature Study From traditional to integrated contracting Systems Engineering Introduction of Interface Management Introduction of Configuration Management Introduction to Risk Management Conclusion...28 Chapter 4: IM Related Research Concurrent Engineering Negative design iterations Virtual design Evaluation methodologies...40 Chapter 5: Practical Analysis Case description Project Organization Interface Management Evaluation Current Practices Different Engineering Disciplines: Types of Interfaces Main difficulties regarding IM...57 XIII Technical University of Delft Ballast Nedam

15 Chapter 6: Factors causing integration issues Interface Management related issues Comparing findings case study with literature...60 Chapter 7: Interface Management Framework Interface Management set-up Flowchart Interface Identification Interface Documentation Management of high-risk and complex interfaces Interface Communication Interface Control Interface Management Tools Conclusion...89 Chapter 8: Conclusions and Recommendations Answering of the research questions General conclusions Recommendations for Ballast Nedam Recommendations for further research References XIV Technical University of Delft Ballast Nedam

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

17 XVI Technical University of Delft Ballast Nedam

18 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 Background Construction projects are becoming more and more complex and larger in scale due to advance in technology and operations. At the same time, contractors are under great pressure in a competitive market with respect to factors such as cost, time-to-market and quality (Tomiyama & Meijer, 2005). This increasing pressure and complexity of both products and processes made the successful realization of construction projects harder and harder. Projects are usually outsourced to several contractors due to the enormous size and the complexity of the infrastructure projects which all have a part to contribute in the system. Systems Engineering (SE) has been introduced as an approach to systematically organize these large, complex and multidisciplinary projects. Within SE, the design procedure consists of decomposing the complex system or project into a set of subsystems, which may be further divided into components. The SE approach for product development will ultimately decompose the design effort down to a point where individual teams of engineers will have the task of designing a component, which is a small portion of the overall system that is manageable for the given development schedule. These individual teams of engineers usually work separately from each other, and have different backgrounds such as structural, mechanical and electrical engineering (Zummo, 2010). Unfortunately, most of the components are somehow connected to one another. Interfaces are generally considered as the links between different construction components, stakeholders and project scopes (Shokri, Safa, Haas, Maloney and MacGillivray, 2012). Components are clearly defined and understood because they belong to one small module of the system. However, although each subsystem has a clear definition and it is supposed to behave as specified, designers can still be surprised by unpredicted problems that deteriorate the performance of the project as a whole (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

19 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. 2

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

21 interface management, resulting in a reduction of the additional costs and delays due to unnecessary design iterations and rework. Both the problems highlighted in this thesis, and the proposed solutions aim to contribute towards a structured and transparent management of interfaces. 1.4 Research questions The problem description and research model have been used to define the main research question that needs to be answered for achieving the goal as described in 1.3. In order to support the main question, subquestions have been derived. These sub-questions will be answered throughout the report and will ultimately lead to an answer on the main question Main question How to improve the interface management practices in infrastructure project development, in order to reduce unnecessary design iterations and rework? 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. 4

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

23 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 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. 6

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

25 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. 8

26 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 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) 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 9

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

28 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) Integrated building industry The market is currently shifting from the traditional ways of contracting, in where the contractor was only responsible for construction, towards Private-Pubic-Partnerships. Jean-Paul Schaij, director of PPSsupport, claims that the Dutch government saved about 15% on costs so far on projects which were outsourced with these integrated contracts. According to Schaij the question is no longer if the government should make use of integrated contracts, but rather how much responsibility should be transferred to the market (Jager, 2013). Not only the design and construct phases could be outsourced but also aspects like Finance, Maintenance and Operation. Recently innovative contract forms have been developed to shifts these risks away from the client. Most common contracts are Design and Construct contracts (D&C-contract) or forms of that like DCM (Design, Construct and Maintain) and DBFM (Design, Construct, Finance and Maintain) contracts (Jager, 2013). Evaluation of projects realized with integrated contract forms showed many advantages. According to Jager (2013) integrated contracts lead to: An optimal use of knowledge from the market. Less extra work for the contractor. Projects which function better, for a lower price. Sustainable solutions. One of the biggest differences compared to the traditional building process is that the contractor is responsible for both the design and construct activities, see Figure 5. By doing this, the client makes use of the knowledge and expertise available on the market, and offers more flexibility to the contractors. In an integrated design process various parties work together to a common goal from the early start. The skills and experience of all specialty engineers can be integrated from the start which leads to more flexibility and more creative and functional solutions (Anumba, et al. 2007). Figure 5: Traditional Approach versus Early Contractor Involvement (De Witt, et al. 2005). In the traditional approach the client spent a lot of time in the design phase. Because the design activities were fragmented and succeeded each other, many iterations had to be done after each other leading to long lead times. When a satisfactory design was accomplished, the design was transferred to a contractor who then only had to execute the project within a certain time frame. 11

29 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) Comparison between the traditional and integrated building industry In the previous paragraphs the main aspects of the traditional and integrated building industry are explored. New forms of contracting led to a shift of responsibilities in the construction market. By comparing these traditional and integrated forms of contracts, the answer on the first sub-question can be given. SQ: Why is Interface Management becoming more important nowadays? As mentioned in the introduction, the increasing size of projects and the advances in technology and operations are a major cause for the amount of interfaces to grow in size as well as in complexity. In addition, these projects involve many stakeholders and contractors, with different geographical locations and working cultures. Furthermore, These contractors are under great pressure in a competitive market with respect to cost and time-to-market (Tomiyama & Meijer, 2005). However, the biggest reason why contractors should pay more attention now to IM is the new way of contracting. Contractors are not only responsible for construction, but also for the design of the project. Especially the overlapping of design and construction activities increased the importance of IM. In the traditional way of contracting the whole design was a sequential process which took the time which was needed. After the design was finished, a contractor would start with construction. Nowadays, with the great pressure on cost and time-to-market design and construction activities start to overlap. This is not without any risk. When the interfaces are not taken care of, and components which are already under construction suddenly need to change, huge delays and additional costs could occur. 12

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

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

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

33 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 the role of IM within the SE literature is explored and described Interface definition Most interfaces arise during the decomposition of a project into different contracts, sub-systems and components. At the moment, no consensus is made about the precise definition of these interfaces. Many definitions of interfaces exist in the construction sector, which could cause a lot of confusion. Therefore, for this research is chosen to use the following definition for interfaces: 16

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

35 Figure 11: Intra-disciplinary versus Inter-disciplinary interfaces (Shokri, et al. 2012) 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 18

36 In short, IM contains the identification, description, coordination and control of all interfaces during the whole life cycle of the project Interface Management in SE literature According to Kossiakoff et al. (2011) is the management of interfaces a major theme within SE. However, IM literature in SE is scarce. The International Council on Systems Engineering (INCOSE), for instance, only mentions to take into account the interfaces in the integration process, but describes no practical applications or guidelines for IM. In this section of the report, several SE guidelines which do contain IM are described and evaluated. NASA developed the Systems Engineering Handbook in 2007 which contain IM practices. In order to focus on IM in infrastructure projects, also SE guidelines for the construction industry are evaluated. In the Dutch Civil Engineering industry two practical guidelines for SE have been developed, which do discuss the role of IM. These guidelines, Leidraad voor Systems Engineering binnen de GWW-sector and SE-Wijzer Handleiding Systems Engineering voor BAM Infra are developed by respectively Rijkswaterstaat and Prorail, and the Koninklijke BAM groep. These SE guidelines are evaluated in order to get a clear view on how IM is proposed in SE, and in particular the Dutch Civil Engineering industry. By exploring the SE literature on IM, the second subquestion will be answered throughout this section. SQ: How is interface management proposed in literature on Systems Engineering? Systems Engineering Handbook NASA (2007) states that management and control of interfaces is crucial to successful projects. The objective of IM is to achieve functional and physical compatibility among all interrelated system elements. An interface is any boundary between one area and another which could occur within the system (internal) or between the system and another system (external). These interfaces may be functional or physical (e.g., mechanical, electrical) in nature. Ensuring that all system pieces work together is a complex task that involves teams, stakeholders, contractors, and project management from the end of the initial concept definition stage, through the operations and support stage. The IM tasks begin early in the development effort, when interface requirements can be influenced by all engineering disciplines and applicable interface standards can be invoked. They continue through design and checkout. During design, emphasis is on ensuring that interface specifications are documented and communicated. During system element checkout emphasis is on verifying the implemented interfaces. In verifying the interfaces, the systems engineer must ensure that the interfaces of each element of the system or subsystem are controlled and known to the developers. Throughout the product integration process activities, interface baselines are controlled to ensure that changes in the design of system elements have minimal impact on other elements with which they interface. The changes must be evaluated for possible impact on other interfacing elements and then communicated to the affected developers. Although all affected developers are part of the group that makes changes, such changes need to be captured in a readily accessible place so that the current state of the interfaces can be known to all. Process description NASA developed a flow diagram for the Interface Management Process and identified typical inputs, outputs, and activities to consider in addressing interface management. 19

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

38 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 onesided ICD. The user of the IDD is provided connectors, electrical parameters, mechanical properties, environmental constraints, etc., of the existing design. The user must then design the interface of the system to be compatible with the already existing design interface. 21

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

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

41 The process of IM is schematically shown in Figure 14. In here, a clear distinction is made between interdisciplinary and intra-disciplinary interfaces. The intra-disciplinary interfaces have to be settled within the disciplines and do not require any coordination of the other disciplines. As already mentioned in the previous chapters, contractors often coordinate their own IM issues well. It are the interfaces which cut across delivery teams that cause the most issues. Therefore, for each inter-disciplinary interface, ICDs have to be developed in order to write down the agreements between the involved contractors around that specific interface. 3.4 Introduction of Configuration Management Another process within Systems Engineering is Configuration Management (CM). CM is an essential project management tool which is suited for controlling changes during the design and construction phases of large infrastructure projects (Kossiakoff, et al. 2011). The NASA Systems Engineering handbook defines CM as a management discipline, which is applied over the 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) Process Description Figure 15 provides a typical flow diagram for the Configuration Management Process and identifies typical inputs, outputs, and activities to consider in addressing CM. The main aspects of CM can be divided into document, baseline and change management. Figure 15: Configuration Management process (NASA, 2007). 24

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

43 . 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. 26

44 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. 27

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

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

47 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 Activity relationships Based on the information dependency relationship among activities, Prasad (1996) defines four types of activity relationships as can be seen in Figure 18. These relationships are defined as dependent, semi-independent, independent, and interdependent. Figure 18: Activity Relationships (Bogus, et al. 2006). Independent activities have no relations or interfaces with each other at all. For dependent activities, the downstream activity cannot start before it receives the required information from the upstream activity. Semiindependent activities are characterized by one activity requiring only partial information from the preceding activities before it can begin. As last, interdependent activities require a two-way information exchange 30

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

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

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

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

52 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 Restructuring the design process Much of the research is focused on the planning of design, based on the dependencies of elements within the design. These interfaces and dependencies can be seen as an flow of information. Information that is needed 35

53 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 36

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

55 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 Reorganize the design process Other strategies to reduce design iterations fall under the category of reorganizing the design process. Strategies in this category are team problem solving and sharing ranges of acceptable solutions. Team problem solving A meeting could be called to decide as a group on the values for the relevant design data. If the various contributors to the decision are together in one place, at minimum there could be an acceleration of the design iterations. At best, there could be real team problem solving. Using cross-functional teams and team problem solving to produce design could accelerate the design solution and prevent integration and schedule issues. Share range of acceptable solutions Many other concepts and techniques of advanced design management are relevant to the reduction of negative iteration. Suppose the participants had been willing to share the range of values acceptable to each. In that case, it would be simple to determine if there are values for each dimension which are acceptable to all. However, contractors might be unwilling to share that knowledge even if they are brought together face-toface, in hopes that the final solution better favored them as opposed to others. Indeed, it appears to be a routine of current design practice that supposedly collaborating specialists effectively compete for the priority of the values or criteria associated with their specialties (Ballard, 1999b). 38

56 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 Overdesign (design redundancy when all else fails) When it is not possible to overlap dependent activities with the above strategies, overdesign could be a solution in some cases. By applying overdesign a buffer is created for certain parameters. This buffer is created to provide a factor of safety, or to encounter possible design errors or changes in design. 39

57 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 40

58 construction are only just now being undertaken in practice. The ADePT and DIMS methodology are one of the few which have been implemented and evaluated in practice. The main difficulty of the implementation of the DSM methodology in construction lies with the decomposition of the project design process, and the size of the DSM matrix. As input for the DSM is tried to use parameters, design drawings, and components and sub-subsystems as displayed in the SBS. Evaluation of the DIMS methodology in practice, which used design drawings, exposed difficulties capturing all interfaces during the design interface meetings, because of the large size of the matrix (100x100). The designers were finding difficulties in managing the size of the matrix. Because of the large size they tried to use the matrix on subsystem level instead. However, on this level all inter-component dependencies were neglected which decreased the usefulness of the matrix. A second difficulty for using this methodology is filling in the matrix itself. Exposing all dependencies within the project is a very hard task and time consuming task, which requires expertise from all different specialties involved. In addition, a lot of dependencies cannot be recognized at the early phase of the project. As the project progresses into more detail, more and more dependencies will be revealed. Basing the planning on a matrix which is only filled in for 80% does not necessarily have to be the best option. Furthermore, even if an optimal design sequence can be obtained, modifications have to be made to this planning due to construction constraints. Therefore, an optimal design planning still has to be modified which encounters the benefits of the planning. Fortunately, even still an optimal design sequence could not be obtained during the case project many advantages had been recognized. The designers were of the opinion that the DIMS methodology provided a forum to make collaborative decisions during the design process, especially during the workshop for capturing the interfaces. The discussions during the workshops had pro-actively matched the teams which required close interaction for the exchange of information. The collaborative information sharing among the design participants was acknowledged as a key driver for the production of error free Good for Construction drawings (Varghese and Senthilkumar, 2012). It can be concluded that the DSM methodologies are promising, but only after sufficient testing and launching of commercial software can this systematic tool, for finding the optimal sequence in design, be implemented in practice. Selecting the size of the matrix and finding all dependencies asks for dedication and time-efforts, of all parties involved. According to Koskela et al. (1997) the principle of optimizing the sequence can also be approached informally. If the 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. 41

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

60 Chapter 5: Practical Analysis In order to get a better understanding of how IM in implemented in practice, a case study is conducted. The practices, as implicated in a real life case, are examined and described in this chapter. First, a description of the case study is given in paragraph 5.1. Secondly, the project organization is basically described ( 5.2). Thirdly, the IM practices are described as they occurred in the case study, and thereby answering the fourth sub-question ( 5.3), where after these practices are evaluated ( 5.4). In paragraph 5.5 an answer is given of the fifth subquestion What are the main differences between the engineering disciplines?. In paragraph 5.6, the main types of interfaces have been identified, as they occurred between the main engineering disciplines. As last, in paragraph 5.7, the last sub-question is answered by summing up all main factors which are currently causing the integration issues. In Chapter 6 Factors causing integration issues, the results from paragraph 5.7 will be verified, by comparing the findings from case study with literature. 5.1 Case description For this research the Johan Frisosluizen project in Stavoren is used as case study. The 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, 43

61 mechanical and electrical part of the design. All these entities were involved from the start of the project. Because the information gathered is rather sector than company related the companies will be stated as respectively Civil Engineering (CE), Mechanical Engineering (ME) and Electrical Engineering (EE). 5.2 Project Organization The three engineering disciplines (CE, ME and EE) are all involved from the start of the project with a DCMcontract, in where the exact scope of each discipline is described. In order to integrate the several engineering entities and handle the complexity of the project, a Project Management Plan (PMP) is developed in where is described how the 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 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. 44

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

63 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 IM before reorganization At the beginning of the project in Stavoren, the organization was not sufficient, leading to several design teams working separately from each other. During this phase the design teams identified their own interfaces, based on their internal processes and were using different software tools. This led to a situation in where the design teams were working with different version of the requirements and SBS. The interfaces which were derived out of the SBS and requirements did therefore not comply with each other. Moreover, the CE and ME used excel sheets to document their interfaces, while the EE used a N²-chart analysis for their internal organization, as can be seen in Figure 25. There was no common system in where all interfaces were gathered and controlled. 46

64 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 IM after reorganization After the reorganization weekly meetings were organized to settle and identify the interfaces of a specific object, which is at component level of the SBS. An interface manager was appointed to be in charge to organize these meetings and lay down the IM process. The involved disciplines of a certain object were invited to an interface meeting, in where a brainstorm session based on technical knowledge and experience revealed the interfaces. These interfaces were given a specific ID number and were placed in an Interface Register (IR) in RMT Relatics. These interfaces were also coupled to the objects in RMT Relatics, in where the status and other 47

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

66 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 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 Interface Management organization In Stavoren, the management of interfaces did not go well in the beginning. IM did not get the necessary priority which led to a situation in where all involved contractors worked separately. The contractors did not work in the same requirements management tool, leading to contractors working with different versions of the SBS, WBS and the requirements. Furthermore, a lack of understanding of how to work with SE, and how to derive the functional requirements, led to several designs which did not comply with the requirements. No interface manager was appointed, and the interface meetings were not structured and frequently organized. Eventually, this situation led to a point in time where one of the contractors was already detailing his design, while another was still working on the conceptual design. Interfaces between these contractors were not taken into account at all. After this phase, a reorganization has taken place. An interface manager was appointed, structured interface meetings were organized, and the data was structurally stored in both Relatics and Sharepoint. It can be concluded that the implementation of a sufficient IM program is required at the early phases of the project. The later interfaces are taken into account the higher the risk of design iterations and rework. Furthermore, it is important that the IM program receives support by all stakeholders. IM processes can only work if all stakeholders cooperate. Therefore, alignment should be reached between all main stakeholders over the importance and content of IM. The IM process, which includes tools, roles and responsibilities regarding IM, should be agreed upon by all involved parties and documented in a IMP, in order to make the project a success. 49

67 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 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 Interface coordination When an interface is identified and described, the next step is to coordinate that interface. An interface exists between two components and needs to be uncoupled so that both design teams can finish their designs individually. However, it is not always as easy to uncouple and control an interface. Both designers have to coordinate their designs closely which often requires a back and forth flow of information. This information could be dependent on other designs which makes the whole an iterative and complex process. Close coordination and formal agreements related to that interface should lead to a mutual solution. 50

68 In here, some progress can be achieved. First of all, the interface meetings, which reveal the dependencies within the project, should be held as early as possible. The earlier interfaces are recognized the easier it is to manage those interfaces. Secondly, formal agreements should be made regarding these interfaces. It still happened that disciplines were not aware of their responsibilities regarding an interface. For instance, the layout of the concrete basement was based on both mechanical and electrical equipment. The CE was in the opinion that the ME and EE had to coordinate the spatial interfaces regarding this equipment, while the EE and ME were waiting for the CE to coordinate and manage that interface. Furthermore, agreements were lacking about the deadlines for closing an interface. It has been mentioned several times that interface information is not available at the moment others would like to see so. In this project it happened multiple times that the CE needed information from the EE, while that information was not available yet. When no deadlines are given, it could happen that specific information is not given the necessary priority by the contractor. This could lead to a situation where the contractor waiting for the information has to keep pushing and asking for this information, leading to delays. At the Johan Frisosluis, it happened a couple of times that it took multiple interface meetings, before specific information was finally available. This required flow of information should be made transparent, and deadlines for interface information should be agreed upon sooner. When is known in advance, what information is needed by what design team on what moment, and well defined agreements are made regarding this information, a lot of delays due to waiting, or incorrect assumptions, could be avoided 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 Design Planning Project are decomposed into several components, which fall under the scope of multiple contractors. Nowadays, at the start of the project a global construction planning is based on the SBS and WBS. The construction phase requires a certain sequence of activities and has a certain time frame. The construction of a component cannot start without the approval of all related formal design documents. Therefore, the detailed design drawings need to be ready at certain points. The planning of the design components is mainly based on 51

69 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 Conclusion In this chapter the IM process is evaluated. It becomes clear that an IM process should be implemented as early as possible in the project. A plan has to be developed in where all IM related processes, tools and roles are described. Important in here is that these processes are supported by all contractors. Alignment between all stakeholders should lead to a IM plan which is supported by all, and therefore more likely for the contractors to stick to it. An important aspect of IM is the identification of the interfaces, which is already a difficult process itself. The more details in design are uncovered the more interfaces arise. Furthermore, scope changes or new requirements from the client could easily lead to new or different interfaces which makes the identification of interfaces an iterative process. In Stavoren the interfaces were identified during interface meetings based on experience, and 3D design was used to identify clashes in the design. RMT Relatics was used to document and store all interface related information. Most conflicts in the project occurred during the management and control of the interfaces. Both designers have to coordinate their designs closely which often requires a back and forth flow of information. It happened that disciplines were not aware of the responsibilities regarding an interface, and no agreements were made about deadlines for solving an interface. This required flow of information should be made transparent, and deadlines for interface information should be agreed upon in advance. When is known, in advance, what information is needed, by what design team, on what moment, and well defined agreements are made regarding this information, a lot of delays due to waiting, or incorrect assumptions, could be avoided. Furthermore, at the moment there is no overview of what interfaces are more important than others. Some interfaces could have a big impact on the costs and lead time, but are handled late in the design process because the construction requirements allow them to. These interfaces have to be taken into account at the planning of the design activities. These activities should either be pulled forward in the design phase, or other agreements should be made in order to mitigate that risk. 5.5 Different Engineering Disciplines: The interfaces which cross contractual boundaries are the most critical in infrastructure project development. Even if all contractors interact with each other to resolve conflicts, or to improve the design, they are often unaware of how their activities affect the delivery or operation of other project teams (Nooteboom, 2004). In 52

70 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 Objects versus Systems A big difference between the disciplines can be recognized by the output they produce. The CE en ME produces physical objects, while the EE mainly produces systems and only have physical objects which support those systems. This can be already be noticed by looking at the SBS. In the SBS the decomposition is done geographically, in where the system is split up in object based sub-systems, based on physical areas and locations. This approach is used to increase the visibility and coherence of the system. Next to that, all components which have been derived from a sub-system are allocated to an engineering discipline. In this way the scope and responsibility of all involved entities is made clear. In the SBS at the Johan Frisosluis in Stavoren, the sub-systems are objects which are divided by location. These sub-systems are the upper lock head, the lower lock head, the lock chamber, the project area, the road connection, the operating building and the waiting bays. In Figure 28 a simplified version of the SBS is shown. The full version of the SBS can be seen in Appendix B. Figure 28: Edited version of the System Breakdown Structure in Stavoren. The design of the EE is hard to decompose in objects, and even harder to designate to geographical locations. The systems they produce cannot be allocated to a single sub-system and are therefore separated from the rest in the SBS. So, next to the area specific sub-systems is there a sub-system called Electrical and Instrumentation (E&I). The components attached to this sub-system are systems like the operation and control of mechanical systems, the communication system, energy supply, lighting system and building related systems. These components have no site specific destination and are functional systems instead of objects. Only the building related systems could be related to the sub-system Operating building since they 53

71 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 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 Path in time Another difference between the disciplines is the path they take in time. The three main disciplines start with their design based on all the requirements. The CE usually determines the main lay-out of the project at the early start of the process. Whether the project contains a bridge, lock or a tunnel, the physical structure, which will be visible, is always the civil structure. Therefore the global objects of the civil engineer are known relatively soon in the project. Later on in the process the design will be worked out in more detail and the dimensions of the structural design will be determined. For the ME, the physical objects can be determined relatively quick as well. Looking at a bridge for instance, the design of the machine to operate the bridge with depends on the global dimensions and type of the bridge. For the design of the machine the global dimensions, height and functional requirements, like the speed the bridge should go open with, are crucial to determine what kind of machine is going to get used. When all these requirements are known a trade-off analysis will be performed to chose the best system. The EE, on the other hand, starts with designing the main systems first. When the global lay-out of the civil structure, and the type of mechanical machines, is known the EE can start with the design of the operation and 54

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

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

74 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. 57

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

76 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 59

77 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 60

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

79 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 62

80 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. 63

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

82 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 Defining the Interface Management Plan The implementation of a systematic IM process involves the development of an IMP, which clearly describes the roles, responsibilities and expectations of both the owner and the contractors. The IPM ensures all parties understand the IM objectives for the project, and that the right people, processes and tools are in place when and where needed. An IMP should include: IM objectives, including interface (management) definitions and goals for the project for all contractors; Clear roles and responsibilities of all involved parties and project members, including the IM team; Plan of how to resolve conflicts and overcome barriers to the benefit of all; Clear description of all communication channels; Methods and procedures to handle changes; Clear description of all registers and standard forms which will be used in the project; 65

83 Plan to define and handle high risk interfaces; Clear description of all technical tools to be used; Coordination expectations (e.g. frequency and setup of interface meetings); Goals and definitions The IPM will contain clear objectives and goals for the project, and in specific IM. In addition, the definition of IM and interfaces are defined and a distinction is made in the type of interfaces. Three main categories of interfaces can be distinguished which are intra-disciplinary, inter-disciplinary and external interfaces. Intradisciplinary interfaces fall under the scope of a single contractor, while inter-disciplinary interfaces exist between two or more contractors. External interfaces are the interfaces which exist with an object outside the scope of the project. Within these categories two main types of interfaces can be identified, namely physical and functional interfaces. Interface Management team An interface Manager has to be appointed to lead the IM process. This person, which can be an external person or a member of the main 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 66

84 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. 67

85 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. 68

86 Figure 32: Flowchart of the IM process. 69

87 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. 70

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

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

90 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 closed status indicates the interface has been taken care off in the design of all objects attached. The interface manager will monitor all interfaces and when the design of an object changes, after the settlement of an interface, the status could be changed back to `Open` or `In progress`. Interface requirements For simple interfaces an interface requirement could be derived. Especially when this part of the project will be outsourced to a sub-contractor. For each interface maximum one requirement could be derived and listed in the RBS. More requirements could lead to confusion and conflicting requirements. By deriving a SMART requirement of the interface solution, the interface is uncoupled. Think for instance of a wall and cables which 73

91 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 is described what factors should be taken into account by the assessment of an interface risk. Afterwards, in paragraph 7.5, several strategies are proposed to uncouple these high-risk, and often complex, interfaces. Interface Agreements IAs are used to document and track the exchange of information and other deliverables between the contracting parties in a project. IAs result in the exchange of project information generated by one party, that is needed by another party to continue with its scheduled project tasks. This project information could be delivered in the form of engineering drawings, specifications, design reports and calculations, equipment details, project schedule information, etc. These forms will only be used for inter-disciplinary and external interfaces. An IA is a formal form which documents the exchange of information and deliverables, which are measurable and bound by a time frame, between two parties. The deliverable is acknowledged and agreed upon by two contracting parties, both a requester and a responder. During project execution contractors could be either requester or responder, depending on their responsibility to the interface. In an IA the following information is provided: Contracting parties, participants and their roles; Attached interface and objects; Required information or deliverable(s); Responding document(s); Action items; Need date of the agreement; Finish date when the interface conditions have been met. In short, the requester fills in an IA form and requests for the delivery of specific interface information within a certain time frame from another contractor. The responder has to sign this agreement if the requirements can be met, which makes the agreement formal and frozen. When the delivery date cannot be met, a delivery date, different from the request date, could be proposed. When consensus between the contractors cannot be reached easily, the interface can be flagged as high-risk and/or the status may stay on open, which means the interface will be discussed in the upcoming interface meeting. Action items Each IA could have several AIs. These actions are small tasks which have to be executed in order to fulfill the agreement. An example of an action could be look up the required free space for maintenance of pipe Z, in Manual X. These action are less formal than IAs, are much shorter in duration, and are designated to a single project member who has to fulfill this action within a certain timeframe. 74

92 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 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 Contractor A Contractor B Contractor i Manager RV1 R A S, C I RV2 A, S R C RV3 I A R C RVi S A C R I 75

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

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

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

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

97 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. 80

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

99 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 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 82

100 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 Risk management High risk interfaces, or crucial interfaces, should be easy to track and control throughout the entire project lifecycle. As described in paragraph 7.3 is the N²-chart a convenient tool to capture all interfaces. However, cluttered and chaotic matrices should be avoided. Therefore, in order to prevent the N²-chart for becoming confusing and unclear, the amount of interfaces has to be controlled. In order to reduce the amount of interfaces, without changing the level of decomposition, only those interfaces which require extra attention should be put in the N²-matrix. A traffic light system could be used to manage and report the critical nature of 83

101 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 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 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. 84

102 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 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 Conclusion Monitor and control of the interfaces is necessary to keep an eye on the overall progress, to verify the design solutions, and to prevent and solve integration issues during the whole project lifecycle. The IM team is 85

103 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 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 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. 86

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

105 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, ). 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 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 Conclusion Tools to assist in the IM process are a must. A well structured process without tools to support the methodology is hard to maintain, and is sensitive for errors. Therefore, both technical and organizational aspects have to be combined in the IM process in order to cover all aspects of IM. Technical tools in the form of software come in many shapes and sizes. A DMS is necessary as platform to store all documents in the project. All documentation should be stored, secured and available for all stakeholders at all times. Through real-time access to interface status, progress and interface-related documents, stakeholders are equipped with the information necessary to proactively respond to potential interface issues, in an early stage of the project. Next the a DMS also a specific IM tool has to be used. Relatics is not purely developed for IM, but could fulfill this role quite well. When more automated processes are wanted, specific IM tools could be developed or purchased. On the market several ready-to-use IM programs are available for the development of large multidisciplinary projects. BIM programs could further enhance the IM program by increasing the visualization of the design solution, and automatically detect clashes between the several components. A successful IM program starts with a sufficient IM process. However, technical tools to implement, and assist with, the IM process are just as important for the realization of a successful project. Sufficient use of technical tools could improve the efficiency of the team, provide standardization across the project, and provide consistency in the documentation and exchanging of data between contractors. 88

106 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 89

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

108 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 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 NASA mentions several standardized forms to assist in identifying and capturing the interface information, and the approved interface change requests (NASA, 2007). In addition, the link to Configuration Management (CM) is mentioned by proposing interface baselines to ensure that changes in the design of components have minimal impact on other elements, with which they interface. SE guidelines in construction, like Prorail and Rijkswaterstaat (2009), emphasizes that the structured recording of interface data ensures that the right information is available at the right time. The typical SE tree structures, such as the Functional, Requirements, Systems and Work Breakdown Structure (FBS, RBS, SBS and WBS) are mentioned as tools to manage the complexity of projects. A specification tree is proposed in where all requirements, preconditions and interface requirements are grouped by component and sub-system. In this way the specification tree shows the relationship between the specifications, structured to the different levels 91

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

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

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

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

113 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 Interface Management process In the IMP the IM process should be described, which contains procedures for the identification, documentation, communication and verification of interfaces, as well as procedures for change and document management. Concluding aspects in here: Emphasis should be on the early recognition and elaboration of interfaces. After the project have been awarded a workshop has to be organized where all involved parties (including people from design, construction and maintenance) systematically identify as much interfaces as possible. The internal and 96

114 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 97

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

116 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. 99

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

118 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), Al-Hammad, A. (2000). Common Interface Problems among Various Construction Parties. Journal of Performance of Constructed Facilities, ASCE, 14(2), Al-Hammad, A. and Assaf, S. (1992). Design-construction interface problems in Saudi Arabia. Building Research and Information, 20(1), p 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), 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 Ballard, G. (2000). Positive vs Negative iteration in design. Proc. Eighth Annual Conference of the International Group for Lean Construction (IGLC-8), July, Brighton, U.K. Biesboer, F. (2010). Het Dossier Tunnels, Oponthoud door technische installaties. De Ingenieur, 17 December 2010, p 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 Browning, T.R. (1998). Use of Dependency Structure Matrices for Product Development Cycle Time Reduction. Proceedings of the Fifth ISPE International Conference on Concurrent Engineering: Research and Applications. Tokyo, Japan. 101

119 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 , Chen, C., Ling, S., Chen, W. (2003). Project scheduling for collaborative product development using DSM. International Journal of Project Management. p 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, 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 Couwenberg, F. (2011). Raakvlakmanagement, Database helpt bij afstemming deelcontracten in groot project. IPMA Projectie Magazine, , p Coreworx (). Retrived from: < 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, Doornbos, H. (2005). Integraal ontwerpen in de GWW sector. PhD Thesis, University of Utrecht, Netherlands DSM community. (2013). DSM. Retrived from: < 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 Eppinger, S.D. (1997). A Planning Method for Integration of Large-Scale Engineering Systens. International conference on Engineering design ICED 97, Tampere, Finland. Eppinger, D. and Browning, T.R. (2002). Modeling Impacts of Process Architecture on Cost and Schedule Risk in 102

120 Product Development. Appeared in IEEE transactions on Engineering Management, Vol. 49, No.4, November 2002, p 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 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, Jager, J. (2013). Nieuwe contractvormen, 10 mythes en hoe het werkelijk zit. Infra, februari 2013, nr. 1, p 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 , Koskela, L., Ballard, G. and Tanhuanpää, V-K. (1997). Towards Lean Design Management. Fifth Annual Conference of the International Group for Lean Construction, July, 1997, Gold Coast, Australia. Kossiakoff, A., Sweet, W.N., Seymour, S.J. and Biemer, S.M. (2011). Systems Engineering principles and practice. Second edition, John Wiley & Sons, New Jersey Kuprenas, J.A. and Rosson, M. (2000). Interface Consideration on Multiple Prime Contractor Construction Projects. Construction Congress VI: Building together for a Better Tomorrow in an Increasing Complex World: 103

121 Proceedings of the Congress, Orlando, FL. Larsson, N. (2004). The Integrated Design Process. International Initiative for a Sustainable Built Environment (iisbe). Retrieved from: < 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 MSA, MIT Sloan School of Management, August, 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. 9 th international design structure matrix conference, 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: < 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), 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) 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 PKM Solutions. (2009). Toelichting Template Systems Engineering 02. PKM Solutions, Ridderkerk PKM Solutions. (2013). Relatics. Retrived from: < Prasad, B. (1996). Concurrent Engineering Fundamentals: Integrated Product and Process Organization. Prentice Hall, Upper Saddle River, NJ. 104

122 Project Management Institute (PMI) Houston. (2011). PMI Houston Energy Corridor Meeting. Presentation by Khadially, R., Project Interface Manager, WISON Floating Systems. 27 june Abstracted from: < 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: < 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 Rogers, J.L. & Padula, S.L. (1989). An Intelligent Advisor for the Design Manager. Technical Memorandum , NASA. Rouibah, K. and Caskey, K.R. (2003). Change management in concurrent engineering from a parameter perspective Computers in Industry. Vol. 50, p Rose, H. (2008). Internal controls policies and procedures. John Wiley and Sons. P.83. ISBN 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): 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, Sosa, M., S. Eppinger, C. Rowles Are Your Engineers Talking to Each Other When They Should. Harvard Business Review. Retrived from: < 105

123 Specialist Engineering Alliance. (2009). Sustainable buildings need integrated team. Eclipse Research Consultants. Retrived from: < Stevens, R., Brook, P., Jackson. (1998). System Engineering: Coping with Complexity. Prentice Hall Europe, ISBN 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 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 Tuholski and Tommelein. (2010). Design Structure Matrix Implementation on a Seismic Retrofit. ASCE Journal of Management in Engineering, 26(3), 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: < 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 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 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 Varghese, K., Senthilkumar, V. and Chandran, A. (2010). A web-based system for design interface management of construction projects. Automation in Construction, p Varghese, K. and Senthilkumar, V. (2012). A case study based testing of design interface management system (DiMs). Journal of Management in Engineering, August 6,

124 Verganti, R. (1997). Leveraging on systematic learning to manage the early phases of product innovation projects. R&D Mgt., vol. 27, no. 4, pp Wideman, R.M. (2002). Wideman Comparative Glossary of Project Management Terms. v3.1. Retrieved from: < Yassine, A., Falkenburg, D. and Chelst, K. (1999). Engineering design management: An information structure Approach. International Journal of Production Research, p 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 Zummo, K.J. (2010). A Methodology for the integration of design teams for the development of complex Systems. PhD Thesis, Southern Methodist University, Dallas, USA 107

125 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

126 Appendix A Examples of Interface Control Forms used at different organizations. 2

127 Appendix B Part of the interface matrix as used at the Johan Frisosluis in Stavoren. 3

128 Appendix C System Breakdown Structure (SBS) of the Johan Frisosluis in Stavoren: 4

129 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). Lack of coordination among specialties (Josephson, et al. 1996; larcón and Mardones, 1998). Discussions occur about who will adapt his design to the other, regarding an interface. 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. Failing to properly manage resulting conflicts (Nooteboom, 2004). 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). 5

130 The engineering disciplines work from another location which complicates direct communication and collaboration. Poor communication (Fritschi, 2002). Lack of coordination among specialties (Josephson, et 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). Lack of coordination among specialties (Josephson, et 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. Lack of coordination among specialties (Josephson, et 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. No proper interface management organization. Problems arise when issues cut across delivery teams, with cross-function issues often not receiving the necessary priority (Nooteboom, 2004) 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). 6

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

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

133 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. 9

134 WBS activities Clicking on an object in Relatics will reveal all relations of that activity. Underlying and parent activities; Attached object (SBS); Risks and interfaces which have to be taken into account. Verificationmatrix The verification matrix in Relatics verifies the requirements in the project for all objects. However, the verification matrix should also include the interfaces instead of just the requirements. In this matrix an interface could be stated as verified, and the related document(s) could be attached. 10

135 Appendix F When clicking on the interface ID-number, a specification sheet will appear with all relevant information. Interface Specification interface title General information ID-number Title Description Type of interface Status ID number of the interface Interface title Short description of the interface External, Inter- or Intra-disciplinary Open, In progress or Closed Leading and intersecting object Leading object Object 1 Intersecting object Object 2 Requirement Req. title 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 Title ID-number Short description 11

136 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 Title ID-number Short description Additional comments Additional comments 12

137 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 Specific description of the required interface information Deliverable 1 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' 13

138 Due date of the agreement Due date Date Received date Date when deliverables are received Verification of the deliverables Deliverables verified Date of verification Verified by Comments Verified Yes/No Verification date Name of responder which verified the deliverables Extra comments Extra comments Extra comments Signatures Agree with the content of the IA Date Signature Requester Responder Closure of the IA Name Date Signature Name 14

139 Appendix G Much of the research mentioned in chapter 4 proposes restructuring of the design process, based on the dependencies between the project elements. The DSM is mentioned several times as part of their methodology. In this appendix the ADePT methodology proposed by Austin et al. (1999), the DIMs methodology proposed by Varghese and Senthilkumar (2008) and the Process-Parameter-Interface (PPI) model of Chua et al. (2003) are evaluated, as well as the DSM methodology included in here. DSM Methodology A fundamental activity in project design, is the planning and control of work. In current construction industry practice, design is planned by the same techniques as site construction, including network analysis (Austin, et al. 2000). However, network analysis techniques and tools were designed to represent sequential processes and cannot easily account for a process containing iteration, such as design (Austin, et al. 1996). This results in the unwanted exclusion of information links between activities. In construction design, this problem is particularly prevalent when considering information exchanged between design disciplines, because of the disparate manner in which they undertake their work and its planning. Steward (1965) developed a theory that a complex problem such as design could be solved more efficiently by representing the interrelationships between activities in the form of a matrix (Austin, et al. 2000). Design Structure Matrix (DSM) The Design Structure Matrix (DSM), developed by Steward (1981), is an N²-chart diagram used to capture interactions and dependencies between teams, functions and activities (Browning et al, 2006). It has been proved that the DSM method drastically reduces the design process time of multi disciplinary projects that involves much iteration (Eppinger, et al. 1994). DSM provides a simple compact and visual representation of a complex system that facilitates novel solutions to decomposition and integration problems (Browning, 2001). The design structure matrix (DSM) is a matrix representation of a system, which shows the dependencies between the elements of that system. System elements are listed in the first row and the first column of the matrix and off-diagonal cells indicate the interactions or information flow between the system elements. There are two main categories of DSM which are static and time-based, see figure 1. Figure 1: Different types of DSM (Browning, 2001) 15

140 Static DSMs represent existing system elements simultaneously, such as components of a product architecture or groups in an organization. In time-based DSMs, the ordering of the rows and columns indicates a flow through time. In here upstream elements of a process precede downstream elements, and terms like feedforward and feedback become meaningful when referring to interfaces. Out of these two categories, four main types of DSMs can be distinguished as can be seen in table 1. Table 1: DSM data types (DSM Community, 2013) DSM data types Representation Applications Component-based (Product) Component relationships System architecting, engineering and design People-based (Organization) Organizational relationships unit Organizational design, interface management, team integration Activity-based (Process) Activity input/output relationships Process improvement, project scheduling, iteration management, information flow management Parameter-based (Low-level Process) Design parameter relationships Low level activity sequencing and process construction, sequencing design decisions The activity-based DSM shows the connections between the activities or elements and defines three types of relationships. The three basic building blocks for describing the relationship amongst system elements are sequential (or dependent), parallel (or concurrent), and coupled (or interdependent). Figure 2: Types of relationships between tasks (Chen, et al. 2003) The DSM can be used to find the optimal sequence of activities and provide an overview of all dependencies in the project. Partitioning and tearing are two operations used for this purpose. Partitioning is the process of reordering the DSM rows and columns which will maximize the availability of information required, and minimize the amount of iteration and the size of any iterative loops within the process. Tearing is the process of choosing the set of feedback marks that if removed from the matrix are called tears. The information 16

141 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. 17

142 ADePT Methodology Austin, et al. (1999) conclude that current building design planning practice gives little consideration to the interdisciplinary, iterative nature of the process. Under this circumstance, the ADePT (Analytical Design Planning Technique) is proposed. This project planning methodology helps to overcome these problems by providing a logical, structured approach, based on information flow rather than the production of design deliverables. It takes account of the iterative nature of design and can enable fully coordinated, integrated design solutions to be developed within both budgetary and time constraints. The first stage of the methodology is a model of the building design process, representing design activities and their information requirements. IDEF0v is proposed as the most suitable modeling technique for construction design in where all information requirements for a design activity can be presented. Figure 4: IDEF0v modelling technique (Austin, et al. 1999). The design process model (DPM) has a hierarchical structure, the first level of which sub-divides the process into design undertaken by the professional disciplines: architecture, civil engineering, structural engineering, mechanical engineering, and electrical engineering. There are different characteristics for each discipline because of variations in the way they work. The DPM aims to describe the process at a non-specific level and consequently it represents the design of a typical building and its systems. For building design this means a basic model is developed at a non-specific level and consequently it represents the design of a typical building and its systems. The project planning of a particular building will entail some manipulation of the model to produce a project-specific process map. The four engineering processes are partitioned into systems design. The design of the ground floor slab and systems beneath it are civil engineering activities, while the design of above ground systems are represented within the structural engineering model. The mechanical engineering section systems are decomposed further into Requirements and Load Analysis, Schematic Design, Plant Layout Design and System Specifications which are in turn broken down into individual design tasks. The electrical engineering section is represented in terms of groups of systems such as Lighting Systems Design and Communications Systems Design before being decomposed further into systems such as General Lighting Design and Emergency Lighting Design and then into individual design tasks. 18

143 The data in this model is linked via a dependency table to a Dependency Structure Matrix (DSM) analysis tool, which is used in the second stage, to identify iteration within the design process and schedule the activities with the objective of optimizing the task order. There are many information dependencies between activities in complex problems such as construction design, which can be clarified by accounting for different levels of information importance (strengths of dependency). This can be done by classifying the dependencies within the matrix and using a partitioning algorithm that can prioritize the sequencing of activities accordingly. The classification of information within a matrix is a subjective exercise. Austin et al. (1996) described a three point scale of classifications, used in ADePT, which is based on the strength of dependency of information, sensitivity of activities to changes in information, and the ease with which information can be estimated within the building design process, see figure 5. Figure 5: The basis for allocating information classifications (Austin, et al. 1996). To determine each information classification, three separate subjective judgments must be made and the resulting classification is given a rating of either A, B or C (A being strong and C being weak). The philosophy adopted by ADePT is that weak dependencies can be omitted from the matrix partitioning (because an accurate estimate can easily be made), and therefore the size of iterative loops can be reduced and the design process clarified. The third stage of the methodology produces design programmes based on the optimized process sequence. Finally, the fourth stage is where the design process is monitored and the flow of work is controlled. The technique requires some iteration between the DSM and programming stages. Figure 6: ADePT methodology (Austin, et al. 1999). The detailed DPM and DSM tool offer an effective means of scheduling a design process based on the flow of information through a project, rather than on the production of deliverables. The matrix indicates groups of tasks that are interdependent and therefore require careful co-ordination. A project management program can show the optimal design sequence (as determined by the matrix analysis tool) in the form of design 19

144 programmes. These programmes highlight the iterative task groups identified by the matrix and ensure that they are scheduled to take place in parallel, thereby reducing the likelihood and scale of redesign and associated construction problems. Practical implementation of ADePT The most significant challenge lies in defining tactics to manage the design team as they work concurrently on an interdependent design problem. There is no single solution as the number of activities and deliverables, number of team members involved, and time required to develop the design will dictate the approaches used. What is important is that each of these issues is thought about in turn and that an appropriate approach is put in place. The third stage of the methodology produces design programmes based on the optimized process sequence. This process raises a number of issues. Conventional programming tools represent sequential processes and do not allow elements of work containing iteration to be programmed. Thus, in current practice, feedback is not identified, resulting in co-ordination failures and rework. With ADePT, the DSM analysis is used with a project management tool, in order to demonstrate that these dependencies could be integrated with existing construction planning systems, and a form of representation familiar to design planners and managers can be used. This is done by grouping tasks that form a loop under a rolled up activity and removing interrelationships from within the loop so that they can be programmed to occur in parallel. However, establishing the effects of tearing an information dependency can prove difficult when a loop consists of a large number of tasks and interrelationships. In current practice, design is largely programmed to release information to suit the construction stage. The proposed approach is fundamentally different in first producing an optimal programme to suit design, which is then modified as it is integrated with a procurement and construction programme. In practice, it is unlikely that the optimal sequence of design tasks will be realistic because of the production constraints put on the process by the need to deliver a project in a short a time-scale as possible. However, comparison with a view of the ideal construction sequence should provide a good starting point to integrate design within the wider project process. Evaluation of ADePT methodology All stages of ADePT have been validated by Austin et al. (2000) though their application to a series of building projects under construction. The design process model has been validated by producing project-specific models and a broad range of design work has been embraced. The first task in formulating each project-specific model is to ensure that the Desgin Process Model has an appropriate content and structure. This requires the deletion of design activities from the generic model that are not relevant to the project, and the addition of tasks associated with features of the building not already included. The output from the DSM tools and corresponding design programmes have been compared with the planning that was undertaken in practice. This has shown that the programmes used in practice did not take full account of the iteration within the design process, and that the design had been planned almost entirely to suit the construction process. Advantages of the ADePT methodology mentioned are among others (Newton, et al. 2007): 20

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

146 Interface Management Methodology The proposed interface management methodology has three main steps which are definition, capture and management/control. In the definition stage, the main project elements are listed out in the System Breakdown Structure (SBS) prepared by the main contractor(s). In this phase the scope for each contractor is clear, and the project is decomposed to portions which are manageable by individual design teams. During the capturing stage, all parties involved to the design phase are required to identify their interfaces with other design parties, vendors and client by a suitable tool through workshops or brainstorming sessions. Next, the details of the identified design interfaces are discussed with other interfacing parties and are documented during the interface meetings. As part of the discussions concerning the interface, a realistic date by which the interface design information is to be available and shall be closed, shall also be identified. This date will be adhered to by both the interfacing parties. It is also the responsibility of the individual design teams to prepare, maintain and update the interface record. Each design discipline is also required to prepare a list of major outstanding interface issues which have the potential to affect scope, costs or schedule aspects of the design contracts. The design manager shall keep the design discipline advised of any change in the status of all such interface issues, and obtain the assistance of the design disciplines as appropriate. Any discrepancies, inconsistencies or errors, identified by any reviewer, shall be notified to the originator and the other related parties of the interface. Modified Design Organization The interface team is managed by the project interface manager, and is assisted by the interface coordinators for each design team in the design process. From each design team a coordinator is designated to act as an interface coordinator for their discipline, which is usually the design leader. These coordinators will carry out the interface management tasks such as interface identification, documentation and solving any interfacing issue that occurs, in addition to their regular work. The discipline interface coordinators attend the regular scheduled weekly design interface meetings and raise the issues which relate to their discipline and give inputs on the requirements of other disciplines. All the interfacing issues and their corresponding resolutions data needs to be documented and updated. Drawing DSM (DDSM) methodology It is cumbersome to capture the design interfaces or information dependencies in a complex design process. A network diagram cannot show the details as the number of entities and their dependencies are large on most projects. For this reason the DSM methodology is used to capture all the interfaces. However, in most DSM based methodologies, the design schedule is modeled using an activity based DSM (Maheswari, 2006, Tuholski and Tommelein, 2010). As activities can be defined at many levels, varying from a very detailed level to a high level of abstraction, finding the suitable level of abstraction to formulate the activity DSM is very difficult. The selection of appropriate abstraction level to represent an activity is critical to the practical utility of DSM. Moreover, the guidelines suggested in the existing DSM methodologies require significant investment of the 22

147 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. 23

148 Figure 7: DDSM formation methodology (Senthilkumar and Varghese, 2009). Entity - Identification Figure 8 shows a systematic decomposition framework used to identify entities for a generic project. Of the entities, drawings and parameters entities (shaded) cannot be comprehensively identified at the initial stages of the design and will evolve as the design progresses. 24

149 Figure 8: project decomposition framework (Senthilkumar and Varghese, 2009). Interface - Identification This stage focuses on identifying the interfaces between the main components, subcomponents and teams. This stage requires inputs from all stakeholders and can be in the form of workshops. The resulting interfaces are represented in the form of a physical interface matrix (PIM) and a design interface matrix (DIM). The DIMS tool generates the framework for Physical Interface Matrix (PIM) automatically from the defined entities. PIM is a dynamic matrix and it gets updated when an entity is added / removed from the database to accommodate the frequent scope change in fast-track projects. During the first session of the workshop, the users were asked to identify physical interfaces between the already defined main components and subcomponents in the PIM structure. Figure 9: Physical Interface Matrix (PIM) (Senthilkumar and Varghese, 2009). The system generates the Design Interface Matrix (DIM) structure automatically from the PIM. During the second session of the workshop, the design interfaces were captured by each team. This workshop facilitates 25

150 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 as and when an issue is generated. In response to the , 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 26