Professional Documents
Culture Documents
Colophon
Report
Type:
Title:
Graduation report
Interface Management in multidisciplinary infrastructure project
development
Diminishing integration issues across contractual boundaries in a
Systems Engineering environment
Lexmond
Monday, 3 March 2014
Subtitle:
Place:
Date:
Author
Name:
Study number:
Telephone number:
E-mail address
Course:
Master:
University:
Graduation committee
Chairman:
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
First commissioner:
Second commissioner:
External commissioner:
Ballast Nedam
2014
II
Ballast Nedam
2014
Preface
By means of this report I finish a period of seven years of studies at the Delft University of Technology. In 2006,
I started with the Bachelor of Civil Engineering mainly due to a keen interest in the realization of large
construction projects. After completing my bachelor, I realised that pure civil engineering was not exactly what
I was interested in, instead it is the management of these large construction projects that has aroused my
interest. Therefore, I made the decision to continue my studies in the field of construction management and
started with the Master program Construction Management and Engineering. During my master studies, I
learned a lot about project and process management, as well as the Systems Engineering methodology. As final
part of my study, I hereby present you my graduation thesis.
I would like to express my gratitude to the people who made this all possible. First of all, I want to thank Ballast
Nedam for giving me the opportunity for conducting this graduation thesis and especially the department of
Project Information Management. Steven van der Geest, who performed the role of external commissioner,
supported me during this period and provided me with information and useful suggestions. I also want to
express my gratitude to Professor M.J.C.M Hertogh and G.A. van Nederveen of the faculty Civil Engineering &
Geosciences and to T.J van Beek of the faculty of Mechanical, Maritime and Materials Engineering for their
constructive feedback.
Last but not least, I want to express my gratitude to my friends and family that have supported me during my
entire period of study allowing me to have an enjoyable time.
The only thing that remains now for me is wishing you much pleasure while reading this report.
Sebastiaan Staats
Lexmond, March 2014
III
Ballast Nedam
IV
Ballast Nedam
Executive Summary
The introduction of integrated contracts led to a shift of responsibility from the client to the contractor.
Contractors are not only responsible for construction, but also for the design of a project. The use of integrated
contracts asks for new approaches and processes. Systems Engineering (SE) has been introduced in order to
organize the processes of integrated projects. SE is a method of organizing complex projects and has become a
standard in the construction industry. Within SE, the design procedure consists of decomposing a complex
system, or project, into a set of sub-systems. These sub-systems may further be divided into components. The
SE approach for product development will ultimately break down the design effort down to a point where an
individual team of engineers are able to design one component. Each component is small portion of the overall
system that is manageable for the given development schedule.
Infrastructure projects have become more complex, and larger in scale, due to the advances in technology and
operations. These projects are usually outsourced to multiple contractors and sub-contractors. These parties
could have different backgrounds and working cultures, and they are usually located at different geographical
locations. Each contactor is responsible for the development of one or more components or sub-systems.
Although these components and sub-systems are being developed separately, many share a common
connection or interface. When these commonalities are not taken into account, integration issues can easily
occur when the components are integrated.
Problem statement
In practice, numerous projects have been delayed and extended their budget because of integration issues.
What is notable about these failed projects is that the most expensive mistakes and delays can be traced back
to integration issues between the different design teams. Design teams usually succeed in the development of
the individual projects components and subsystems within their scope, but do not pay enough attention to the
project as a whole. The lack of Interface Management (IM), between different engineering disciplines, leads to
unnecessary design iterations and rework, causing additional costs and a substantial delay of the project.
Systematic approach for Interface Management
In this thesis, a systematic IM method is proposed to diminish integration issues across contractual boundaries
within infrastructure project development. Analysis has been done through a literature research and a case
study have been conducted.
The case study that was conducted explores and evaluates current IM processes. The main factors leading to
integration issues have also been identified. The main issues mentioned are: overall unawareness of interface
issues, ownership and responsibilities regarding the interfaces are not clear, lack of coordination among
specialties, insufficient and inaccurate interface information, poor information flow, poor ordering of tasks, no
overview of what the crucial interfaces are, and lack of a proper IM organization (IM team and tools). These
main factors could be brought back to two categories which are (1) poor communication among the involved
parties and (2) poor coordination among the involved parties.
The focus of this thesis is to establish a basis for a structured IM process. The IM process has to contain both
technical aspects (tools and software) as well as organizational aspects. Tools and software could be of major
assistance during the management of interfaces. However, without the foundation of a well-structured
process, interfaces simply cannot be managed effectively. Software may assist in detecting physical interfaces,
Ballast Nedam
Interface Identification
Interface Documentation
Interface Communication
Interface Control
Interface Closing
The IM process requires an IM team which is responsible for the implementation of the process. An interface
manager has to be appointed, and each design team should appoint an interface coordinator who serves as the
single point of contact regarding the interfaces.
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
Ballast Nedam
VII
Ballast Nedam
VIII
Ballast Nedam
Samenvatting
De invoering van integrale contracten heeft geleid tot een verschuiving van de verantwoordelijkheden van de
klant naar de opdrachtnemer. Opdrachtnemers zijn niet alleen meer verantwoordelijk voor de uitvoer van een
constructie project, maar ook voor het ontwerp. Het gebruik van integrale contracten vraagt om nieuwe
werkmethodes en processen. Om de processen van gentegreerde projecten te organiseren is Systems
Engineering (SE) gentroduceerd. SE is een methode om complexe projecten te organiseren en is uitgegroeid
tot een standaardmethode in de bouw. Binnen SE begint het ontwerpproces met het ontleden van het
complexe systeem, of project, in een reeks van subsystemen. Deze subsystemen kunnen verder worden
onderverdeeld in componenten. Volgens de SE methodiek wordt een project ontleed tot aan het punt waarop
een individueel ontwerpteam een component kan ontwerpen. Dit component is een klein onderdeel van het
totale project, en is beheersbaar binnen het gegeven tijdschema.
Infrastructurele projecten zijn complexer en grootschaliger geworden als gevolg van de vooruitgang in
technologie en operaties. Deze projecten worden meestal uitbesteed aan verschillende aannemers en
onderaannemers. Deze partijen kunnen verschillende achtergronden en werkculturen hebben, en bevinden
zich meestal op verschillende geografische locaties. Elke aannemer of onderaannemer is verantwoordelijk voor
de ontwikkeling van n of meerdere componenten of subsystemen. Hoewel deze componenten vaak
afzonderlijk ontwikkeld worden, hebben veel van deze componenten en subsystemen een verbinding of
raakvlak met elkaar. Wanneer deze raakvlakken worden verwaarloosd, kunnen er problemen optreden tijdens
het integreren van deze componenten op de werkplaats.
Probleemstelling
In de praktijk hebben integratieproblemen er toe geleid dat veel projecten zijn vertraagd, en het budget
hebben overschreden. Wat opvalt aan deze mislukte projecten is dat de grootste fouten die leiden tot hogere
kosten en vertraging gerelateerd kunnen worden aan integratieproblemen tussen de ontwerpteams.
Ontwerpteams slagen er meestal in de componenten en subsystemen binnen hun werkgebeid te realiseren,
maar besteden niet genoeg aandacht aan het project als geheel. Het gebrek aan raakvlakmanagement tussen
de verschillende ontwerpteams leidt tot onnodige ontwerp iteraties en extra werk, wat uiteindelijk leidt tot
extra kosten en aanzienlijke vertragingen.
Systematische aanpak voor raakvlakmanagement
In dit afstudeerrapport is een systematische aanpak voor raakvlakmanagement voorgesteld om
integratieproblemen te verminderen tussen de contractuele partijen tijdens de ontwikkeling van
infrastructurele projecten. Onderzoek is gedaan door middel van een literatuuronderzoek en het uitvoeren van
een casestudie.
De casestudie die is uitgevoerd onderzoekt en evalueert de huidige raakvlakmanagement processen. Hierin zijn
ook de huidige factoren onderzocht die momenteel leiden tot de integratieproblemen. De belangrijkste
factoren zijn: het onbewust zijn van raakvlakproblemen, rollen en verantwoordelijkheden met betrekking tot
de raakvlakken zijn niet duidelijk, gebrek aan cordinatie tussen de ontwerpspecialismen, onvoldoende en
onjuiste raakvlakinformatie, slechte informatiestroom, onjuiste volgorde van ontwerpactiviteiten, geen inzicht
in wat de cruciale raakvlakken zijn en het gebrek aan een goede raakvlakmanagement organisatie
(raakvlakmanagement team en software). Deze belangrijkste factoren kunnen worden herleid naar een tweetal
categorien, namelijk (1) een slechte communicatie tussen de partijen en (2) een slechte cordinatie tussen de
partijen.
IX
Ballast Nedam
Raakvlak identificatie
Raakvlak documentatie
Raakvlak communicatie
Raakvlak controle
Raakvlak sluiting
Een raakvlakmanagement team is vereist dat verantwoordelijk is voor de implementatie van het
raakvlakmanagement proces. Een raakvlakmanager moet worden aangesteld, en binnen elk ontwerp team
dient een raakvlak cordinator te worden benoemd die zal dienen als eerste aanspreekpunt betreffende de
raakvlakken.
Raakvlak identificatie
De nadruk moet liggen op het zo vroeg mogelijk erkennen en uitwerken van de raakvlakken. Raakvlak
overleggen moeten georganiseerd worden waarin alle betrokken partijen (waaronder mensen van ontwerp,
uitvoer en onderhoud) vertegenwoordigd zijn om systematisch de raakvlakken te identificeren. De interne en
externe raakvlakken kunnen gedentificeerd worden door naar het systeem te kijken vanuit drie perspectieven,
namelijk de functie-, objecten-, en eisenboom. Deze raakvlakken zijn hoofdzakelijk gedentificeerd op basis van
ervaring en algemene kennis van de projectleden.
Raakvlak documentatie
Gestandaardiseerde formulieren, matrices en registers dienen gebruikt te worden voor het documenteren en
controleren van raakvlak gerelateerde informatie. Zo kunnen formulieren gebruikt worden voor het
documenteren van afspraken die zijn gemaakt om een raakvlak te ontkoppelen, en kunnen matrices gebruikt
worden om gedefinieerde taken en verantwoordelijkheden vast te leggen.
Raakvlak communicatie
Een raakvlak bestaat tussen twee componenten en dient te worden ontkoppeld zodat beide partijen
individueel hun ontwerp kunnen afronden. Interface Agreement (IA) formulieren worden gebruikt om de
uitwisseling van raakvlakinformatie tussen de partijen te standaardiseren. In deze formulieren is de benodigde
raakvlakinformatie beschreven en is er een deadline gegeven voor het moment dat deze informatie benodigd
is. Door het gebruik van deze formulieren kunnen de meeste raakvlakken ontkoppeld worden.
Wanneer het niet mogelijk is om een raakvlak te ontkoppelen door middel van standaardformulieren kunnen
andere strategien worden toegepast. Ontwerpactiviteiten kunnen naar voren worden getrokken zodat beide
objecten op hetzelfde tijdstip kunnen worden ontworpen. Het vormen van multidisciplinaire teams, het
organiseren van meetings, of het delen van de oplossingsruimtes met elkaar kan ervoor zorgen dat er op een
snelle manier de meest optimale oplossing gevonden wordt. Als dit niet mogelijk is, en er is geen tijd om te
wachten op de andere partij, dan kunnen er ook aannames gedaan worden over de raakvlakinformatie en/of
kan er overdimensionering kan worden toegepast. Dit zijn goede strategien om het proces te versnellen, maar
brengen ook extra risico mee voor het project. Daarom moeten vr de toepassing van deze strategien de
mogelijke consequenties zorgvuldig worden onderzocht.
Ballast Nedam
XI
Ballast Nedam
XII
Ballast Nedam
Table of Contents
Executive Summary ................................................................................................................................................ V
Samenvatting......................................................................................................................................................... IX
Table of Contents ................................................................................................................................................ XIII
Abbreviations ....................................................................................................................................................... XV
Chapter 1: Introduction .......................................................................................................................................1
1.1
Background .............................................................................................................................................1
1.2
Problem Description ...............................................................................................................................1
1.3
Research goal and objectives .................................................................................................................3
1.4
Research questions.................................................................................................................................4
Chapter 2: Research methodology......................................................................................................................5
2.1
Research design ......................................................................................................................................5
2.2
Research constraints...............................................................................................................................5
2.3
Research approach .................................................................................................................................6
2.4
Report overview .....................................................................................................................................7
Chapter 3: Literature Study .................................................................................................................................9
3.1
From traditional to integrated contracting.............................................................................................9
3.2
Systems Engineering .............................................................................................................................13
3.3
Introduction of Interface Management................................................................................................16
3.4
Introduction of Configuration Management ........................................................................................24
3.5
Introduction to Risk Management........................................................................................................27
3.6
Conclusion ............................................................................................................................................28
Chapter 4: IM Related Research........................................................................................................................30
4.1
Concurrent Engineering ........................................................................................................................30
4.2
Negative design iterations ....................................................................................................................35
4.3
Virtual design ........................................................................................................................................40
4.4
Evaluation methodologies ....................................................................................................................40
Chapter 5: Practical Analysis .............................................................................................................................43
5.1
Case description ...................................................................................................................................43
5.2
Project Organization .............................................................................................................................44
5.3
Interface Management .........................................................................................................................46
5.4
Evaluation Current Practices ................................................................................................................49
5.5
Different Engineering Disciplines:.........................................................................................................52
5.6
Types of Interfaces ...............................................................................................................................55
5.7
Main difficulties regarding IM ..............................................................................................................57
XIII
Ballast Nedam
XIV
Ballast Nedam
Abbreviations
AI
ADEPT
BIM
CE
CM
CMP
CR
DBFM
DC
DIMS
DMS
DSM
EE
E&I
FBS
IA
IBS
ICD
ICP
ID
IDD
IM
IMP
INCOSE
IR
IRD
ME
MEP
OBS
PMP
PPI
RBS
RM
RMT
SE
SBS
VDC
WBS
Action Item
Analytical Design Planning Technique
Building Information Model
Civil Engineering
Configuration Management
Configuration Management Plan
Change Request
Design, Build, Finance and Maintain
Design & Construct
Design Interface Management System
Document Management System
Dependency Structure Matrix
Electrical Engineering
Electrical and Instrumentation
Functional Breakdown Structure
Interface Agreement
Interface Breakdown Structure
Interface Control Document
Interface Control Plan
Identification
Interface Definition Document
Interface Management
Interface Management Plan
International Council on Systems Engineering
Interface Register
Interface Requirements Document
Mechanical Engineering
Mechanical, Electrical and Plumbing
Organizational Breakdown Structure
Project Management Plan
Process Parameter Interface
Requirement Breakdown Structure
Risk Management
Requirements Management Tool
Systems Engineering
System Breakdown Structure
Virtual Design and Construction
Work Breakdown Structure
XV
Ballast Nedam
XVI
Ballast Nedam
Chapter 1: Introduction
This first chapter introduces the subject, in paragraph 1.1, background information is given which is followed by
the problem description (1.2). The problems that have been recognized lead up to the problem definition at
the end of the paragraph. This problem definition led to the research goal and objectives which are stated in
paragraph 1.3. The last paragraph (1.4) defines the research questions which will be answered throughout the
report. The research methodology which will be used to achieve the research goal, and to answer all the
research questions will be discussed in Chapter 2.
1.1
Background
Construction projects are becoming more and more complex and larger in scale due to advance in technology
and operations. At the same time, contractors are under great pressure in a competitive market with respect to
factors such as cost, time-to-market and quality (Tomiyama & Meijer, 2005). This increasing pressure and
complexity of both products and processes made the successful realization of construction projects harder and
harder.
Projects are usually outsourced to several contractors due to the enormous size and the complexity of the
infrastructure projects which all have a part to contribute in the system. Systems Engineering (SE) has been
introduced as an approach to systematically organize these large, complex and multidisciplinary projects.
Within SE, the design procedure consists of decomposing the complex system or project into a set of subsystems, which may be further divided into components. The SE approach for product development will
ultimately decompose the design effort down to a point where individual teams of engineers will have the task
of designing a component, which is a small portion of the overall system that is manageable for the given
development schedule. These individual teams of engineers usually work separately from each other, and have
different backgrounds such as structural, mechanical and electrical engineering (Zummo, 2010).
Unfortunately, most of the components are somehow connected to one another. Interfaces are generally
considered as the links between different construction components, stakeholders and project scopes (Shokri,
Safa, Haas, Maloney and MacGillivray, 2012). Components are clearly defined and understood because they
belong to one small module of the system. However, although each subsystem has a clear definition and it is
supposed to behave as specified, designers can still be surprised by unpredicted problems that deteriorate the
performance of the project as a whole (DAmelio, 2010). The system integration process represents the first
time that fully engineered components and subsystems are linked to one another, and are made to perform as
a unified functional entity. Despite the best plans and efforts, the integration of a system containing newly
developed components is almost certain to reveal unexpected incompatibilities (Kossiakoff, Sweet, Seymour
and Biemer, 2011).
In order to prevent integration issues, all interfaces between the components and sub-systems should be taken
into account in advance. Industry leaders believe that Interface Management (IM) systems improve alignment
between stakeholders and can reduce project issues and conflicts (Shokri, et al. 2012). However, systematically
identifying and managing all interfaces seems to be a continual struggle for owners and contractors. The lack of
IM in projects may results in deficiencies in the project cost, time, and quality aspects, or might even result in
failures after the project had been handed over. Hence, having a sufficient IM program to effectively handle
the interfaces throughout the whole project life cycle is critical to project performance.
Ballast Nedam
2014
1.2
Problem Description
Companies that design complex, highly engineered products all had their failed projects they would rather
forget about. Ford and Bridgestone Firestone lost billions of dollars after their failure to coordinate the vehicle
design of the Ford Explorer with the design of its tires (Sosa, Eppinger and Rowles, 2007). Likewise, the
development of the Airbuss A380 superjumbo suffered major delays and cost overruns because of late
inadequacies in the design of the electrical harnesses of various sections of the planes frame (Sosa, Eppinger
and Rowles, 2007).
In the construction sector similar problems can be recognized. If the interfaces between the components and
subsystems are not properly taken into account, sub-solutions could be derived which do not fully connect to
each other. Consequently, conflicts could occur in the project, leading to unnecessary design iterations, rework
or even failure. Multiple examples exist of projects which have been delayed or have exceeded the budget
because of these integration issues. In fact, up to 20% of total project cost is related to interface management
issues (Nooteboom, 2004).
The Leidsche Rijntunnel A2 and the Roertunnel A73 have been substantial delayed because the complex
technical installations did not match to each other. The technical installations are not installed and coupled
until late in the project. Therefore, functional and physical clashes in the design are not always recognized
before the subsystems are integrated and installed into the project. Clashes identified in this phase of the
project life cycle could easily lead to substantial delays and extra costs. Ir. M. Smitt, director of Strukton Civil,
states that disciplines as Civil Engineering and Electrical Engineering have been separated worlds for a long
time, even on a management level work is not coordinated well (Biesboer, 2010).
L. van Ruijven, Manager technical development at Croon, evaluated the project Sluiskiltunnel. The
Sluiskiltunnel is a tunnel under the canal of Gent. The lesson learned here was that the multidisciplinary design
should have integrated better in regards to the disciplines of Civil and Electra and both these designs were not
fully optimized. It further states that the most important causes of failure costs in projects are the inadequate
exchange of information and communication between the different contractors (van Ruijven, 2007).
Another case is the HSL-Zuid, a 125 km-long high-speed railway line in the Netherlands, which has substantial
integration issues. The project suffered heavily because of the interfaces between the several sub-systems.
Superstructure,transport and sub-systems as the foundation were outsourced to different parties with
different contracts. The project manager had to manage all these interfaces and found himself sandwiched
between the different parties while this was never the intention to do so (Rijsenbrij & van Gelder, 2010).
The Betuweroute, which is a 160 km long freight railway from the Maasvlakte near Rotterdam to the German
border which was completed in 2007 are also known to have similar problems. This project was outsourced in
many regional contracts in order to get the lowest price for each part of the project. However, all these
different parties increased the need for coordination and IM. All sub-systems had to comply to the same
requirements and had to match one another. These issues were heavily underestimated at the early stage of
the project, leading to a substantial delay of the railway (van Klink, et al. 2010).
What notable about these failed projects is that the most expensive mistakes and delays could be traced back
to integration issues between the different design teams. These design teams all succeeded in the
development of the projects components and subsystems within their scope, but did not pay enough attention
to the project as a whole (Sosa, Eppinger and Rowles, 2007). Ballast Nedam acknowledge these problems, and
that the lack of IM between different engineering disciplines leads to unnecessary design iterations and
rework, causing additional costs and a substantial delay of the project.
Ballast Nedam
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
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:
This report focuses on the implementation of interface management in point of view of the contractor. A
literature study will be conducted on the design processes in order to get a clear view on the current practices.
The role of interface management in these processes is explored and evaluated through both literature and a
case study. Findings, from both literature and the conducted case study, gain insight in the factors causing
interface issues during infrastructure project development. Evaluation of the current interface management
practices lead to a complete picture of the shortcomings and successes of the applied method. by investigating
literature on interface management related subjects, aspects are explored which could encounter the main
factors causing the integration issues. Additions to the current practices lead to a systematic approach for
Ballast Nedam
1.4
Research questions
The problem description and research model have been used to define the main research question that needs
to be answered for achieving the goal as described in 1.3. In order to support the main question, subquestions have been derived. These sub-questions will be answered throughout the report and will ultimately
lead to an answer on the main question.
1.4.1
Main question
How to improve the interface management practices in infrastructure project development, in order to reduce
unnecessary design iterations and rework?
1.4.2
Sub-questions
In line with the main question several sub questions have been derived. The sub questions will serve as the
basis of the research and will lead, ultimately, to an answer on the main question:
1)
2)
3)
4)
What are the main differences between the engineering disciplines? (5.5)
6)
The mentioned sub-questions will be handled throughout the report. In the next chapter the research
methodology used to answer the research questions is described.
Ballast Nedam
2.1
Research design
To adequately answer the research questions and reach the objective, a research design is set up. The research
design will consist of four stages which are:
Literature
Research
Results
Conclusions
The literature stage consists of two phases. The first phase (chapter 3) explores literature on construction
design processes, SE and the role of interface and configuration management. This phase gives answers on why
IM is requiring more attention at the moment, and how IM is proposed in the SE literature, leading to answers
on sub-questions 1 and 2. The second phase of the literature stage (chapter 4) examines IM related literature,
leading to an answer on sub-question 3.
The second stage consists of the research phase. A case study is conducted to explore the current IM practices
(sub-question 4). In here, the whole IM process has been examined, including the project organization and
used tools. By evaluating the IM methods the current pitfalls and successes are unveiled. Interviews with
project members of different engineering disciplines lead to a clear picture of the main differences between
these parties (sub-question 5).
The third stage exists of the results. By investigating both literature and findings from the case study, all main
factors causing integration issues are exposed (sub-question 6). At last, coupling the findings from literature
and practice with the current IM processes leads to a systematically approach for IM, which encounter the
main factors leading to integration issues.
In the last stage conclusions and recommendations are given. In here, a summary is conducted which
summarizes the main results and gives an answer on the main research question, and recommendations are
formulated to increase the current practices.
2.2
Research constraints
To execute the research a solution space has to be defined. Without such a space it would be very hard to
define a scope for this thesis. To demarcate the problem, the starting points and constraints have to be
defined.
The surveyed case studies and the thereby linked empirical research will focus on Ballast Nedam
projects and experts;
Ballast Nedam
The research will focus on forms of Design and Construct (DC) projects;
The research will be conducted in a SE environment;
The research will make conclusions based on the data received from projects in where Ballast
Nedam is involved.
The research on system integration will be conducted from the perspective of the contractor.
Therefore, integration issues caused by the client, such as unclear scope packages and conflicting
requirements, are neglected.
2.3
Research approach
According to Doorewaard and Verschuren, five strategies can be recognized in order to approach a research:
survey, experiment, case study, well-founded theoretical approach, and desk research (Doorewaard, et al.,
2007). This report will use both a theoretical approach and a case study. The research starts with a literature
study on the main topics involved. In here, the design processes, SE and IM are widely elaborated.
In order to explore the IM process, as is currently conducted in infrastructure project development, is chosen
to perform a case study. Based on findings in the case study, the IM program can be evaluated, leading to the
main pitfalls and successes within this approach. Furthermore, the main factors causing the integration issues
could be identified which will indicate the direction for progress.
The results from literature and case study combined will assist in the development of a systematically IM
approach. This approach will encounter the factors causing the integration issues as much as possible and will
therefore lead to an answer on the main question. In the last stage, a conclusion and recommendations are
formulated.
2.3.1
As indicated, current IM practices can only be explored in industry. In order to get the input required, a case
study is conducted. However, not every case is suitable to reveal all information needed. Therefore, the case
has to be carefully selected, based on several criteria. For this research, the case has to meet the following
selection criteria:
Involvement:
Since the research is done at Ballast Nedam the involvement of BN as a contractor is required.
Contract:
The project should be based on a Design & Construct (DC) contract or a related form such as Design,
Construct and Maintain (DCM) or Design, Build, Finance and Maintain (DBFM) contracts.
Approach:
The use of Systems Engineering is mandatory for the selection of the case.
Multi-disciplinarity:
In order to investigate the role of, and coordination between, different engineering disciplines the
project should have a strong multidisciplinary character.
Progress:
In order to interview the employees involved in the project, the project should currently be in
progress. In this way it is easier to obtain information and speak to all parties involved.
These selection criteria resulted in The Johan Frisosluis in Stavoren as case study for this research.
Ballast Nedam
Principal:
General contractor:
Other main (sub)contractors involved:
Contract:
Summary:
Provincie Friesland
Ballast Nedam Infra
Machinefabriek Emmen, Croon Elektrotechniek, Royal Haskoning
and Sterk.
Design, Construct and Maintain (DCM)
The capacity of the Johan Frisosluis in Stavoren has to be expanded. The lock is forming a connection between
the Johan Frisokanaal en the Ijsselmeer and is for recreational purposes the most important entrance to De
Friese Meren. The current capacity of the lock is too small to handle all the vessels. Especially in summer
season long waiting times occur at the lock. Therefore Ballast Nedam is contracted to expand the capacity of
the lock for a total contract sum of 15.6 Million Euros.
2.4
Report overview
An overview of the report is given to give a clear view of what is handled in each of the chapters. The report
consist of 8 chapters, and are assigned as follows:
Chapter 1: Introduction
This chapter gives an introduction to the subject, as well as an extensive description of the main problems,
leading to the problem definition. In addition, the project goal, objectives and research questions are defined in
this part of the report.
Chapter 2: Research methodology
Chapter 2 starts with the research design, which explains the four stages which this research consists of and
indicates where the sub-questions will be answered throughout the report. In addition, the research approach
and constraints are described.
Ballast Nedam
Ballast Nedam
3.1
Currently a shift is occurring in the construction market. Where phases as design and construction were used to
be totally different and separated worlds, outsourced to different parties, now both worlds start to intermingle
(Anumba, et al. 2007). In this section the main differences and similarities between the traditional building
industry (3.1.1) and the integrated building industry (3.1.2) are evaluated. A comparison is given in
paragraph 3.1.3 in order to give a clear view of why the role of Interface Management is getting more
important in the construction industry nowadays (sub-question 1).
3.1.1
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.
Traditionally, the client takes care of the initiative. In this phase the value of a project to realize is indentified.
Projects in the civil engineering sector usually have a broad social interest and serve a political goal. The client
develops the initiative in where the technical knowledge of the client determines the level of detail. This
initiative will be completed by a design orientated firm, usually an engineering firm. This engineering firm
develops a execution plan described in a specification. At the end of the design phase the specification will be
put on the market, where construction firms can subscribe. The firm which meets the criteria the best, usually
the one who bids the lowest price, will be chosen to build the construction project. This is the most common
way the civil engineering sector was used to work (Doornbos, 2005).
Looking at the building industry the design phase would usually consists of an architect, structural and services
engineers, see Figure 4 (Anumba, et al. 2007). The different phases of the design would be executed step for
step, and adjustment were made where necessary. Looking at Figure 4, based on the client brief, the architect
produces an architectural design, which is given to the structural engineer. The structural engineer would,
when finished, pass his design on to the services engineers, who on their turn make their design based on the
input given. Whenever modifications are needed, the design will go back one step. When the design is finished
Ballast Nedam
As can be seen in the figure, the structural engineers are separated from the services engineers. Due to the
successive contributions of the members of the design team, the traditional design process has a mainly linear
structure. There is a limited possibility of optimization during the traditional design process, while optimization
in the later stages of the process is often troublesome or even impossible. The services engineers, like
mechanical and electrical engineers, have to adjust their design to the structural design.
The process illustrated in Figure 4 appears to be quick and simple, but the lack of coordination often results in
high operating costs and sub-optimal solutions. Since the conventional design process usually does not involve
computer simulations of predicted energy performance, the resulting poor performance and high operating
costs will most often come as a surprise to the owners, operators or users. The introduction of highperformance systems late in the design process cannot overcome the handicaps imposed by initial
incompatible or otherwise poor design decisions (Larsson, 2004). The key disadvantages prevalent with this
sequential approach include (Anumba, et al. 2007):
The fragmentation of the different participants in the construction project, leading to misperceptions
and misunderstandings;
The fragmentation of design and construction data, leading to design clashes, omissions and errors;
The occurrence of costly design changes and unnecessary liability claims, occurring as a result of the
above;
The lack of true life-cycle analysis of the project, leading to an inability to maintain a competitive edge
in a changing marketplace;
Lack of communication of design rationale and intent, leading to design confusion and wasted effort.
10
Ballast Nedam
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:
One of the biggest differences compared to the traditional building process is that the contractor is responsible
for both the design and construct activities, see Figure 5. By doing this, the client makes use of the knowledge
and expertise available on the market, and offers more flexibility to the contractors. In an integrated design
process various parties work together to a common goal from the early start. The skills and experience of all
specialty engineers can be integrated from the start which leads to more flexibility and more creative and
functional solutions (Anumba, et al. 2007).
Figure 5: Traditional Approach versus Early Contractor Involvement (De Witt, et al. 2005).
In the traditional approach the client spent a lot of time in the design phase. Because the design activities were
fragmented and succeeded each other, many iterations had to be done after each other leading to long lead
times. When a satisfactory design was accomplished, the design was transferred to a contractor who then only
had to execute the project within a certain time frame.
11
Ballast Nedam
Figure 6: Traditional versus Flexible model for product development (Iansiti , 1995).
As can be seen in Figure 6 is already started with the construction activities (implementation) while the design
is not for hundred percent finished yet (concept development). Unfortunately, the activities in the process
interact by a back and forth exchange of information. Overlapping the activities therefore, results in even more
interactions and a greater need for coordination (Verganti, 1997). In short one could say that overlapping of
activities typically introduces a higher level of uncertainty into the process that could cause additional rework,
and thus higher costs (Roemer, et al. 1999). To prevent extra iterations due to the overlapping of activities the
coordination and information flow between the engineering disciplines should be sufficient, since the
organization of these aspects have an huge impact on process efficiency and predictability (Eppinger, 1994).
3.1.3
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:
As mentioned in the introduction, the increasing size of projects and the advances in technology and
operations are a major cause for the amount of interfaces to grow in size as well as in complexity. In addition,
these projects involve many stakeholders and contractors, with different geographical locations and working
cultures. Furthermore, These contractors are under great pressure in a competitive market with respect to cost
and time-to-market (Tomiyama & Meijer, 2005).
However, the biggest reason why contractors should pay more attention now to IM is the new way of
contracting. Contractors are not only responsible for construction, but also for the design of the project.
Especially the overlapping of design and construction activities increased the importance of IM. In the
traditional way of contracting the whole design was a sequential process which took the time which was
needed. After the design was finished, a contractor would start with construction. Nowadays, with the great
pressure on cost and time-to-market design and construction activities start to overlap. This is not without any
risk. When the interfaces are not taken care of, and components which are already under construction
suddenly need to change, huge delays and additional costs could occur.
12
Ballast Nedam
3.2
Systems Engineering
As mentioned in the previous chapter, SE is an approach currently used for the realization of D&C projects in
the construction industry. In this chapter the basis of the SE methodology is explained, including all main
processes within. This is done to get a clear view of how the projects are generally organized. Afterwards, in
paragraph 3.3 and 3.4 the role of interface and configuration management within the SE literature is explored
and practical guidelines are evaluated.
3.2.1
System Engineering is an approach to systematically organize complex projects and has been introduced
especially for D&C projects in construction. After the use of SE in the telecommunication industry and other
sectors, SE has become a much used standard in the construction sector (Rijkswaterstaat, 2009). According to
The International Council on Systems Engineering (INCOSE) SE can be defined as:
An interdisciplinary approach and means to enable the realization of successful systems. Systems engineering
considers both the business and the technical needs of all customers with the goal of providing a quality product
that meets the user needs.
It is an interdisciplinary approach which contributes to develop and realize successful systems. With SE not only
the technical requirements are met but it also strives to meet all the interests of involved stakeholders
(Rijkswaterstaat, 2009).
For the implementation of System Engineering in the construction sector the NEN-ISO/IEC 15288 Systems and
software engineering - System lifecycle processes, 2008 is often used as guidance. Out of this standard more
standards have been developed for the implementation of SE in the civil engineering industry. Examples of
these guidelines are INCOSEs Handbook Systems Engineering Handbook, a guide for system life cycle
processes and activities and in the Dutch construction sector the Leidraad voor Systems Engineering binnen
de GWW-sector developed by Rijkswaterstaat and Prorail and SE-Wijzer Handleiding Systems Engineering
voor BAM Infra developed by the Koninklijke BAM groep.
The most common model used in these handbooks is the V-model in which the processes of system
engineering are explained step by step, see Figure 7. The emphasis of the V-model is on the relation between
the integration, verification and validation of the system (right part of the V-model) and the requirements and
design of the system (left part of the V-model).
13
Ballast Nedam
The left path of the V-model represents the requirement analysis and the design phases and the right path
represents the integration phases. To each design phase corresponds a verification phase. For instance, the
design of components is verified by the components test, the subsystem design is verified by the subsystem
test and so forth. The left path of the diagram includes decomposition of requirements and creation of system
specifications in a design. Those processes (decomposition and creation) are achieved by breaking up a system
in subsystems in order to reduce its complexity, and to allow several design teams to work independently. For
this purpose, the left branch of the diagram describes decomposition where each design level gives more
functional and architectural details than the previous one. The right path of the V-diagram corresponds to
integration and verification, which is the construction phase where components are merged together into subsystems and ultimately, into the final system.
Left side v-model
The client formulates a list of functional requirements and puts the request out on the market. The contractor,
who is responsible for both the design and construction phase, has to come up with a design which complies
with these requirements. In order to prove that the requirements are met, a verification plan has to be formed
and executed during the process development. The design process consists of different stages, before the
tender a conceptual design is realized in where the broad design is displayed. When the client rewards the
project to the contractor, the conceptual design will be further detailed into a preliminary design and
ultimately a detailed design. Each phase consists of more detailed drawings of the project.
14
Ballast Nedam
Decomposition
Within systems engineering, the design procedure consists of decomposing the complex system into a set of
sub-systems, which may be further divided into components. The systems engineering approach for product
development will ultimately decompose the design effort down to a point where individual teams of engineers
will have the task of designing a component, which is a small portion of the overall system that is manageable
for the given development schedule. These individual teams of engineering have different backgrounds such as
structural, mechanical and electrical and usually work separately from each other (Zummo, 2010).
The decomposition is usually done with a System Breakdown Structure (SBS), see Figure 8. The SBS is a tree of
components which form sub-systems and eventually the system. Every layer of the tree consists of more
details. By decomposing a system, components are formed which are easier to manage and could be designed
by one design team. These components increase the overview of the project. Usually two types of divisions, or
a combination of these, are used for the decomposition. One of these divisions is geographically, in which the
system is split up in sub-systems based on physical areas and locations. This approach is used to increase the
visibility and coherence of the system. The other way of breaking down is by dividing the system into parts
based on the engineering disciplines. In this way it is easy to assign the several design teams to their part of the
job. However, the risk of this classification is that the coherence of the system gets too little attention leading
to interface problems (BAM, 2008). The classification and the level of detail of the SBS, largely determines the
amount and type of internal interfaces which the project has to deal with. Since the complexity of a system is
related to the pattern of the relationships between the components, the classification of this SBS should not be
underestimated.
All components in the SBS have a specific ID number and will deliver a design document (i.e. drawings) ready
for construction. The more components there are, the more formal documents have to be developed and the
more interfaces exist between the components. On the other hand, if the sub-system is not decomposed
enough components derive which are disorderly and hard to allocate to an individual team of engineers. A
balance has to be found in here. The SBS is purely used to split the project in manageable parts of which the
scope is clear and to make sure that nothing will be left out of the project.
All components derived in the SBS make part of the final system and can be designed by individual design
teams. However, these components also have to complement each other to form the total system. As said,
15
Ballast Nedam
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
The new forms of contracting and the attached pressure on the time to market, makes the management of
interfaces more important than ever. When the interfaces in a project are not managed well, huge problems
could occur leading to delays and additional costs. Unfortunately, it seems that the impact of IM is often
underestimated in construction projects (Nooteboom, 2004). In the first part of this chapter the definitions of
an interface and IM are defined, and different types of interfaces are described. In paragraph 3.3.3 the role of
IM within the SE literature is explored and described.
3.3.1
Interface definition
Most interfaces arise during the decomposition of a project into different contracts, sub-systems and
components. At the moment, no consensus is made about the precise definition of these interfaces. Many
definitions of interfaces exist in the construction sector, which could cause a lot of confusion. Therefore, for
this research is chosen to use the following definition for interfaces:
16
Ballast Nedam
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.
The interfaces can be further divided into functional and physical interfaces. The functional interfaces are
derived from the functional requirements. For instance, it could be stated by the client that a bridge should be
able to open at least ten times an hour. This requirement gives an functional interface between the mechanical
design of the motor and the structural design of the bridge. The type of machine and bridge, the dimensions
and mass, all have impact on this interface. Therefore close coordination between the involved design teams is
necessary in order to meet that requirement.
Physical interfaces are places were two objects are literally physical related to each other. A physical interface
could be, for instance, a bridge which has to connect to the adjacent road. If the bridge is too long the bridge
will not fit, while if the bridge is too small a gab will arise between the road and the bridge. This is an example
of a simple and logical interface, but these objects have to be adjusted to each other in order to come up with
an integrated design.
A third distinction can be made looking at the different contractors. The interfaces between components falling
under one contractor, usually one engineering discipline, are called intra-disciplinary interfaces. The interfaces
between components, designed by different organizations, are called inter-disciplinary interfaces. See Figure 11
for an impression.
17
Ballast Nedam
3.3.2
Unfortunately, IM has been a hidden aspect of project management for a long time (Nooteboom, 2004).
According to Chen, et al. (2007), the term IM contains the improvement of quality of physical connections
between construction components, the reduction of project conflicts among project participants through
planning and close coordination, and the optimization of design in terms of quality, compatibility,
constructability, cost and risk. Shokri, et al. (2012) considers IM as the process of managing communications,
responsibilities and coordination of project parties, phases, or physical entities which are interdependent.
By performing IM, a deep understanding of project complexity for all project participants will be developed,
and can therefore improve project planning by avoiding, minimizing, or eliminating potentials for interface
issues in advance (Chen, et al. 2007). IM is an ongoing process and should be considered dynamic throughout
the life cycle of the project, with the goal of maintaining the balance between scope, time, cost and quality
(Crumrine et al, 2005). The reason is that as a system grows or changes, its interfaces change as well. New
relationships will be established and new interfaces will be generated (Wren, 1967).
Currently, it is not widely known what IM means in construction and what scope is covered by IM. Only
recently an increased awareness of IM as missing link in the construction industry has been developed (Chen,
2007). Lately, several researchers defined their own definitions for IM. In order to prevent confusion about the
scope of IM one definition has been chosen for this research. Kossiakoff et al. (2011) defined a bilateral
definition for IM in the construction industry:
1.
2.
The identification and description of interfaces as part of system concept definition and
The coordination and control of interfaces to maintain system integrity during engineering
development, construction, and subsequent system enhancements.
In line with this definition, four main steps can be identified for an basic IM approach:
1.
2.
3.
4.
18
Ballast Nedam
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:
19
Ballast Nedam
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:
Process Activities
During project formulation, the concept of operations of the product is analyzed to identify both external and
internal interfaces. The concept of operations is a document describing the characteristics of a proposed
system from the viewpoint of the user and is used to communicate the quantitative and qualitative system
characteristics to all stakeholders. This analysis will establish the origin, destination and special characteristics
of the interfaces that need to be documented and maintained.
As the system structure and architecture emerges, interfaces are added and existing interfaces could change,
and must be maintained. Thus, the IM process has a close relationship to other areas, such as requirements
definition and configuration management during this period. Typically, an Interface Working Group (IWG)
establishes communication links between those responsible for interfacing systems, end products, enabling
products, and subsystems. The IWG has the responsibility to ensure accomplishment of the planning,
20
Ballast Nedam
21
Ballast Nedam
Figure 13: Relation between the Specification Tree and the System Breakdown Structure (Prorail and Rijkswaterstaat, 2009).
22
Ballast Nedam
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.
23
Ballast Nedam
3.4
Another process within Systems Engineering is Configuration Management (CM). CM is an essential project
management tool which is suited for controlling changes during the design and construction phases of large
infrastructure projects (Kossiakoff, et al. 2011). The NASA Systems Engineering handbook defines CM as a
management discipline, which is applied over the products life cycle, to provide visibility into, and control to,
changes to performance and functional and physical characteristics. It ensures that the configuration of a
product is known and reflected in product information, that any product change is beneficial and is effected
without adverse consequences, and that changes are managed. The primary purpose of CM is maintaining
consistency in the constructed entitys functional and physical configuration, and to produce a product with the
desired specifications, design and functions (Admiari, 2010).
3.4.1
Process Description
Figure 15 provides a typical flow diagram for the Configuration Management Process and identifies typical
inputs, outputs, and activities to consider in addressing CM. The main aspects of CM can be divided into
document, baseline and change management.
24
Ballast Nedam
25
Ballast Nedam
.
Figure 16: Requirements changes are inevitable (NASA, 2007).
Therefore, the effort and cost associated with accommodating changes increases rapidly as the design matures.
By the time the system design is formulated in detail during the engineering design phase, the search for
opportunities for further enhancement can no longer be sustained. Accordingly, the system design is frozen,
and formal change control procedures are imposed to deal with necessary modifications, such as those
required by incompatibilities, external changes, or unexpected design deficiencies. Configuration control
maintains integrity by facilitating approved changes and preventing the incorporation of unapproved changes
into the items under configuration control.
Summary
The most important aspect a CM process should entail are:
26
Ballast Nedam
3.5
Another process within Systems Engineering is Risk Management (RM). RM is an essential project management
tool to deal with all risks within the project. Risks are defined as events which could lead to delays, additional
costs or a decrease in quality. The goal of RM is achieving the projects objectives by identifying all
uncertainties within the project, at an early phase, and taking measures to monitor and control these risks
(BAM, 2008). Suddle (2004) schematized the risk management process, as can be seen in the figure below.
It is advised to appoint a risk manager in the project who gathers all input related to risks from all involved
disciplines, and documents this information in a risk register. The submission of risks is the responsibility of all
involved team members. The risk register is a systematic document in where all risks, and their relation to the
FBS, SBS, WBS and OBS, are specified.
Multiple methods exist to assist in the RM process. A much used method in infrastructure project development
is the RISMAN method (Prorail and Rijkswaterstaat, 2009). The RISMAN methodology takes into account seven
perspectives to come to a complete picture of all risks. These perspectives are political/administrative,
financial/economic, legal, technical, organizational, geographical and social. Of each risk is captured what the
undesirable events are, what the likelihood is of occurrence, the consequences of the event in terms of costs,
time and quality, prevention measures, mitigation strategies, roles and responsibilities and as last, its relation
to the requirements.
27
Ballast Nedam
3.6
Conclusion
Under the chapter literature, the design processes and SE are explored to answer the first two sub-questions.
In line with sub-question one, it becomes clear that IM not only requires more attention nowadays because of
the increasing size and complexity of infrastructure projects, as well as the resulting increase in the amount of
parties involved. The main reason for the increased importance of IM is the new way of contracting;
contractors are now often responsible for both the design and construction phase of the project. With the
combination of the great pressure on the time-to-market and cost aspects of the project, it leads to
compressed design and construction schedules, which overlap where possible. This overlap of design and
construction activities make the implementation of IM crucial, since any interface issue is highly likely to affect
the construction phase, leading to huge delays and extra costs.
In order to handle these complex projects SE is introduced in the construction industry. This process starts with
functional requirements, given by the client, which should be met in the design. The design of the total project
is decomposed into several sub-systems and components and is displayed in a SBS. It is important to
understand that this decomposition has an important role in the amount and type of interfaces. The
components in the SBS determine the amount and complexity of the interfaces which will exist between these
components. These components are usually a small portion of the overall system, which is manageable for a
given development schedule, and can be designed by an individual team of engineers. An interface between
two components can either fall under the scope of a single contractor, as well as under the scope of multiple
contractors. These contractors usually have different backgrounds such as structural, mechanical and electrical
and most often work separately from each other, which makes the management and control of these
interfaces even harder (Zummo, 2010).
In paragraph 3.3 the definitions and types of interfaces are described, as well as the definition of IM. By these
definitions it becomes clear what an interface is, what types of interfaces can be distinguished and what scope
is covered by Interface Management. Furthermore, in line with the second sub-question, the role of IM in the
SE literature is explored in paragraph 3.4. In here, the role of interface management within the NASA Systems
Engineering Handbook (2007) and two other SE guidelines, developed for the Dutch Civil Engineering industry,
are described.
NASA (2007) states that management and control of interfaces is crucial to successful projects and provides a
flow diagram of the IM process. Interface documentation is mentioned as an important part of the process. The
Interface Requirements Document (IRD), Interface Control Document (ICD) and the interface control plan (ICP)
are mentioned to identify and capture the interface information and the approved interface change requests.
Throughout the product integration process activities, interface baselines are controlled to ensure that changes
in the design of system elements have minimal impact on other elements with which they interface.
Prorail and Rijkswaterstaat (2009) emphasis that due to the high amount of interfaces and stakeholders,
communication and coordination of the available information is essential to prevent errors, and thus prevent
failure costs. A clear distinction is made between internal and external interfaces. All interfaces should be listed
in the requirements, and be coupled to the components. The structured recording of this data ensures that the
right information is available at the right time. Typical SE tree structures, like FBS, RBS, SBS and WBS, are
mentioned as tools to manage the complexity of projects. A Specification tree is proposed in where all
requirements, preconditions and interface requirements will be grouped by component and sub-system. In this
way the specification tree shows the relationship between the specifications, structured to the different levels
of detail.
28
Ballast Nedam
29
Ballast Nedam
In this chapter IM related research is conducted to prevent integration issues. In paragraph 4.1 techniques are
described to diminish design iterations, while in paragraph 4.2 the benefits of virtual design is described.
4.1
Concurrent Engineering
Concurrent Engineering, or fast-track construction, is defined as the process of completing sequential tasks in
parallel, in order to reduce the project delivery times (Anumba, et al. 2007). As explained in chapter 3, design
and construction activities that were once distinct and sequential, are now often intermingled or overlapped.
Bogus et al. (2002) claims that management of the interfaces between design and construction, and the
transfer of knowledge between design and construction activities, are critical in order to reduce the project
delivery time, especially for fast-track projects. Projects start to overlap more and more design and
construction activities in order to reduce the project delivery time. However, the degree to which design or
construction activities may be overlapped, and in turn the level to which various design disciplines may be
overlapped, depend on the type of information exchanged, and the degree of dependency between those
activities (Bogus, et al. 2006). Overlapping dependent activities compress the total lead time of the project, but
could bring along extra risk since the activities may be dependent on each other.
4.1.1
Activity relationships
Based on the information dependency relationship among activities, Prasad (1996) defines four types of activity
relationships as can be seen in Figure 18. These relationships are defined as dependent, semi-independent,
independent, and interdependent.
Independent activities have no relations or interfaces with each other at all. For dependent activities, the
downstream activity cannot start before it receives the required information from the upstream activity. Semiindependent activities are characterized by one activity requiring only partial information from the preceding
activities before it can begin. As last, interdependent activities require a two-way information exchange
30
Ballast Nedam
Activity Characterization
The project delivery time can be reduced by overlapping (semi-)dependent activities. However, the degree to
which design or construction activities can be overlapped depends on the type of information exchanged and
the degree of dependency between those activities (Bogus, et al. 2006). Activity characterization contains the
recognition of the information needed to finish the design and construction task, as well as the identification of
the information produced by each task. This information is used to describe the degree of dependency
between activities (Krishnan et al. 1995). The degree of dependency, in turn, is a function of upstream task
evolution and downstream task sensitivity (Pena-More, et al. 2001). Pena-Mora and Li (2001) suggests that
adopting the characterizations of sensitivity and evolution, within design and construction activities, are a way
to indentify approaches for overlapping activities. The rate of evolution is defined as the rate of generating
design information from the minute of the activity initiation, until the fulfillment of the activity. The rate of
sensitivity an indication is of how sensitive downstream tasks are to changes in an upstream activity (Eppinger,
1994).
Rate of sensitivity
The sensitivity of an activity can be determined by evaluating activity constraints, input variables, and the level
of design integration. Sensitivity becomes important when one activity is dependent on another activity.
Among design activities the most common dependencies are information dependencies, and the sensitivity of
these dependencies to changes in upstream information. Activities that depend on information from another
activity are usually ordered so that all required information is available when the activity begins. However, an
activity could be started before the required information is available, based on assumptions. Unfortunately,
basing the design on assumptions involves a certain amount of risk that the preliminary information may
change before it is finalized. The amount of rework that must be performed, if preliminary information
changes, is related to the factor of the sensitivity of the downstream activity to changes in the upstream
information.
Sensitivity refers to how much rework, measured in additional time and costs, is required on the downstream
activity if upstream information changes. A highly sensitive activity would require a large amount of rework if a
piece of input information changed just a small amount. An activity with low sensitivity can sustain large
changes in input information with only minimal rework (Krishnan et al. 1997).
Identifying the sensitivity of downstream activities is important in overlapping decisions. Starting a highly
sensitive activity before all upstream information is complete entails an increased risk that significant rework
will be required, thus eliminating some of the time savings due to the original overlapping. On the other hand,
activities with a low sensitivity can be overlapped with little risk of rework required. By understanding activity
sensitivities, project managers can make informed decisions on overlapping strategies.
31
Ballast Nedam
Figure 19: Fast (left) versus slow (right) evolution (Bogus, et al. 2005)
Bogus, et al. (2005) observed that in the absence of time pressures, most designers would prefer to include
iterations in their designs to find the optimal solution for a particular activity. This indicates that there is a
natural tendency toward a slow evolution in many design activities. However, there are not many ideal
situations, which means that most design is performed under time and/or resource constraints. These
constraints could speed up the natural evolution of an activity.
Evolution characterizations can be used in project scheduling decisions to identify potential overlapping
opportunities. In general, activities with fast evolution are more amenable to overlapping than activities with
slow evolution. However, when making the decision to overlap activities, one must consider that there is a risk
that a particular piece of information may not be finalized before the downstream activity begins. In this
situation, several strategies can be adopted to allow the downstream activity to proceed.
Certain data are required to characterize an activity by evolution and sensitivity. This information is a result of
the assessment of the design and construction documents in addition to interviews with personnel who are
close to the project such as designers and builders.
32
Ballast Nedam
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.
33
Ballast Nedam
Consequences
Overlapping dependent activities has several advantages such as the reduction of the project delivery times.
However, overlapping also has several disadvantages. The advantages and disadvantages are best to reflect in
the aspects time, cost and quality.
Time
Contractors are often under pressure to finish the project in time. As explained, designers could reduce the
project delivery times by overlapping strategies or strategies to reduce design iterations. These techniques, as
explained, could have a positive effect on the time aspect of the project but, on the other hand, may have a
negative influence on the quality and cost aspects.
Cost
Some of the techniques proposed require a certain amount of money to execute. In addition, parts of the
project which are finished before being properly reviewed, could lead to costly change orders or rework to
match the clients general requirements, or changes in the design of other disciplines (Lam, et al. 2008). For
instance, when the concrete structure is finalized before the electrical engineer determines the location and
dimension of the cables and pipes, rework may be necessary in the form of demolishing parts of the slabs due
to the need of more shafts. Rework is an important negative consequence of overlapping activities, as can be
seen in the figure below. The term rework is defined as the unnecessary effort of redoing an activity that was
incorrectly implemented in the first instance (Love and Li, 2000).
34
Ballast Nedam
4.2
Ballard (2000) did similar research and explores unnecessary, or negative, iterations in design. Design iterations
are primarily caused by incomplete information (Hollins and Pugh, 1990). An activity is performed under
incomplete information, if it precedes activities on whose output it depends. In most complex development
processes, clear precedence constraints do not exist. Instead, the information relationships between activities
are highly complex, and often activities are interdependent, which means that they are mutually dependent
and rely on each others output. Thus, it is far from obvious how to structure development processes, nor are
existing structures necessarily efficient. In particular, coupling restraints between activities are one of the
major causes for iterations (Ulrich and Eppinger, 1995). According to Ballard (2000), the most common
techniques for reducing negative iteration in design are:
Much of the research is focused on the planning of design, based on the dependencies of elements within the
design. These interfaces and dependencies can be seen as an flow of information. Information that is needed
35
Ballast Nedam
36
Ballast Nedam
Figure 22: Analytical design planning technique (AdePT) (Austin et al. 1999).
Firstly, design activities are represented in the Design Process Model. The detailed design process is broken
down into the main disciplines, then into building elements and sub-systems, and ultimately into individual
design tasks. Secondly, all information dependencies between the design activities are mapped in a schedule.
In the third stage, the information gathered will be used to fill in a DSM. As last, iterative design tasks are
partitioned in a DSM and a planning tool is used to generate an optimal design schedule. The ADePT
methodology focuses on improving the design process by satisfying information dependencies among design
activities in a more efficient way.
Varghese and Senthilkumar (2008) state that design has a numerous amount of interdependent, knowledge
intensive multidisciplinary tasks. In addition, they state the overall process is inherently iterative in nature
which makes design hard to structure. Managing this phase requires a careful planning and coordination of the
information exchange between the several engineering disciplines. A structured method to organize the
interfaces and interactions between the various design disciplines is proposed, called the Design Interface
Management System (DIMS). In here, also the DSM is used as part of the methodology to structure the design
processes. However, instead of design activities as input for the DSM, technical drawings are used. As drawings
are well defined entities, it was found that capturing the interfaces at drawing level can eliminate the
ambiguity of selecting the appropriate abstraction level..
Other researchers have also made similar attempts to improve the design process. For instance, Chua et al.
(2003) proposes a Process-Parameter-Interface (PPI) model to manage the design process of Architecture,
Engineering, and Construction (AEC) projects. The model also aims to improve design process scheduling by
reducing information iterative loop and to enhance efficient collaboration. Biggest difference in here is that
parameters are used as input for the DSM. The tool is similar to activity-based DSM, but it can be used for
lower-level process sequencing. While an activity-based DSM includes reviews, tests, and analyses, a
37
Ballast Nedam
Other strategies to reduce design iterations fall under the category of reorganizing the design process.
Strategies in this category are team problem solving and sharing ranges of acceptable solutions.
Team problem solving
A meeting could be called to decide as a group on the values for the relevant design data. If the various
contributors to the decision are together in one place, at minimum there could be an acceleration of the design
iterations. At best, there could be real team problem solving. Using cross-functional teams and team problem
solving to produce design could accelerate the design solution and prevent integration and schedule issues.
Share range of acceptable solutions
Many other concepts and techniques of advanced design management are relevant to the reduction of
negative iteration. Suppose the participants had been willing to share the range of values acceptable to each. In
that case, it would be simple to determine if there are values for each dimension which are acceptable to all.
However, contractors might be unwilling to share that knowledge even if they are brought together face-toface, in hopes that the final solution better favored them as opposed to others. Indeed, it appears to be a
routine of current design practice that supposedly collaborating specialists effectively compete for the priority
of the values or criteria associated with their specialties (Ballard, 1999b).
38
Ballast Nedam
Other strategies are more related to the management of the design process. Strategies in this category are a
least commitment strategy, deferred commitment, set-based design and the last planner system.
Least commitment strategy
A related but more extreme strategy is that of least commitment. This strategy aims for systematically defer
decisions until the last responsible moment (i.e., until the point at which failing to make the decision eliminates
an alternative). Knowledge of the lead times required for realizing design alternatives is necessary in order to
determine last responsible moments. Deferred commitment is a strategy for avoiding premature decisions, and
for generating greater value in design. It can reduce negative iteration by simply not initiating the iterative
loop.
Set-based design
In all design processes, alternatives are generated, evaluated, and selected. Usually the best alternative is
selected as quickly as possible, after which is proceeded to the next level of detail or decision. Project members
state that they do not want to waste time on designs that will not be used, and that they do not have time to
carry forward multiple alternatives (Ballard, 2000). Set-based design prevents this by departing from the
traditional practice of producing only completed design outputs, and rather share incomplete information as
needed by others to get started.
Willingness to share incomplete information has long been identified as a necessity for concurrency in design.
Sequential processing results in part from the implicit rule that only completed design work is advanced to
others. According to this strategy, each task starts as soon as there is enough input date to permit the
beginning of any conceptual work. For each task the real goals are defined, and is known which piece of
information is really needed by other teams, and what the tolerance is that may be accepted. In this way every
team may work exactly on what matters to it. The key of set-based design is producing incomplete information,
but sufficient enough to release work to someone else. This leads to a reduced design duration and cost by
doing design work more concurrently, and a increased efficiency from better communication among members
of the design team (Ballard, 2000).
Last planner system
When a team is delivering late, follow-on teams are prevented from starting when they planned to. The Last
Planner System makes project programs more predictable, and increases the chances that projects will be
completed on time. The method creates conversations at the right level, and at the right time, to build trust
between key project members. Personal relationships and peer pressure are key to managing the network of
commitments required deliver projects on time (Lean Construction Institute, 2005). The last planner system
enables the site supervisors to plain their workload on a weekly basis and assess their teams performance on a
daily basis (Lean Construction Institute, 2005). Meetings are used to discuss the workload of the upcoming
weeks, to ensure all in advance agreed upon goals are achieved.
4.2.4
When it is not possible to overlap dependent activities with the above strategies, overdesign could be a
solution in some cases. By applying overdesign a buffer is created for certain parameters. This buffer is created
to provide a factor of safety, or to encounter possible design errors or changes in design.
39
Ballast Nedam
4.3
Virtual design
Other research has been conducted on virtual design. 3D design has been proposed to reveal clashes in design
in an earlier phase. Korman, Fischer and Tatum (2003) state that in many construction projects the
coordination is still done using 2D drawings and light tables in what is called as a Sequential Composite Overlay
Process (SCOP). This method of coordination has proven to be inadequate and has led to many conflicts
between systems, lack of confidence amongst subcontractors to prefabricate, rework in the field and an
overall lack of productivity installing these systems in the field. Khanzode (2010) conducted research on the
coordination of Mechanical, Electrical and Plumbing (MEP) systems in building construction. In their research,
the use of Virtual Design and Construction (VDC) tools like 3D4D (Fischer and Kunz, 2004) are evaluated. The
use of VDC tools provides the team members with a better simulation environment to try and test solutions,
and also enhances their knowledge of how the systems can be assembled in the field. This is an important point
and confirms observations made by others, that using simulation tools leads to better prototypes and better
outcomes (Schrage & Michael, 2000).
3D clash detection tools could be used to identify and resolve conflicts. There are commercial tools available
that allow project teams to bring in models from multiple CAD systems into a single model, and determine if
two or more systems conflict with each other. One such tool is Navisworks which has a Clash Detection
program that allows teams to automatically analyze the models for conflicts between systems (Khanzode,
2010).
4.4
Evaluation methodologies
Concurrent engineering
Overlapping strategies could be very useful to compress the project delivery time of construction projects. At
the moment lots of design and construction activities are already overlapped due to time constraints. However,
the dependencies between the activities, and the rate of sensitivity and evolution of the interface information,
are rarely taken into account when making such decisions. As can be seen in Figure 20, based on these aspects
several strategies could be applied in order to successfully overlap these activities. It is important to explore
the consequences of applying each strategy on the aspects of time, costs and quality to make sure all risks are
taking into account. Overlapping the right activities and choosing the best strategy could reduce the risk of
potential design iterations and rework.
Re-sequence design activities
Ballard (2000) proposes strategies to reduce negative design iterations in design and construction by
restructuring or reorganizing the design process, changing the way design is management and overdesign.
Restructuring of the design process focuses on re-sequencing the design activities and use pull scheduling to
reduce batch sizes. The DSM methodology is proposed as a tool to re-sequence the design activities, and is
widely elaborated in Appendix F. The theory on DSM in construction is promising but largely limited to
academia. Although the theory of DSM has been applied in a number of circumstances, analyses in
40
Ballast Nedam
41
Ballast Nedam
42
Ballast Nedam
5.1
Case description
For this research the Johan Frisosluizen project in Stavoren is used as case study. The projects goal is to
increase the capacity of the Johan Frisosluis, which will be accomplished by placing a new lock next to the
already existing one. Ballast Nedam will design and construct this project on basis of a Design, Construct and
Maintain (DCM) contract, including 20 years of maintenance. This project has a strong multi-disciplinary
character and consists of six designing entities:
Ballast Nedam Infra
Machinefabriek Emmen
Croon
Sterk
BN Bouw en Ontw.
Royal Haskoning
All contractors work separately on their parts of the project. The main engineering disciplines in this project are
Royal Haskoning, Machinefabriek Emmen and Croon which are responsible for respectively the civil,
43
Ballast Nedam
5.2
Project Organization
The three engineering disciplines (CE, ME and EE) are all involved from the start of the project with a DCMcontract, in where the exact scope of each discipline is described. In order to integrate the several engineering
entities and handle the complexity of the project, a Project Management Plan (PMP) is developed in where is
described how the projects objectives are to be achieved. The design organization is described in the
Deelkwaliteitsplan Ontwerp (DKP-Ontwerp), which is a PMP for the design phase of the project.
In this PMP the design process is described as an iterative process, in where is worked from a rough to fine
level of detail. Therefore, three phases of design are distinguished which are the Conceptual design,
Preliminary design and Detailed design phase.
In the conceptual design phase, the requirements are derived and the system solution and main sub-systems
are generated and chosen. In this phase the main structure of the project becomes visible. In the preliminary
design phase the sub-systems and components are worked out in more detail. Finally, in the detailed design
phase, all final design drawings and documents, of all components and sub-systems, are ready for construction.
For every phase the following steps are followed:
1. Specification:
2. Generating solutions:
3. Interface Management:
4. Verification:
5.2.1
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
Ballast Nedam
Virtual Design
In construction projects, most drawings are made in 2D drawing software, like AutoCad. These drawings are
used to communicate the design with the construction team. However, in order to increase the visibility of the
45
Ballast Nedam
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:
In the DKP-Ontwerp at the beginning of the project, an Interface Management Plan (IMP) was conducted which
basically described the IM process. The goal of IM in here is defined as:
The control of interfaces between the objects themselves (internal interfaces) and the management of the
interfaces with the environment (external interfaces), so that the objects physically and functionally connect to
each other and the environment.
The process coordinator in the project, together with the project manager, are responsible for the control of
interfaces. The identification of the interfaces runs in parallel with the design process. The more details the
design consists of, the more interfaces could be identified. Significant risks coming from the interfaces have to
be documented and recorded in the risk register.
In order to identify the interfaces meeting with the involved parties were organized. This was done in each of
the three phases of the project. The identification of the interfaces happened during interface meetings and
within the individual design teams themselves, in where the interfaces were revealed based on experience.
5.3.1
IM before reorganization
At the beginning of the project in Stavoren, the organization was not sufficient, leading to several design teams
working separately from each other. During this phase the design teams identified their own interfaces, based
on their internal processes and were using different software tools. This led to a situation in where the design
teams were working with different version of the requirements and SBS. The interfaces which were derived out
of the SBS and requirements did therefore not comply with each other. Moreover, the CE and ME used excel
sheets to document their interfaces, while the EE used a N-chart analysis for their internal organization, as can
be seen in Figure 25. There was no common system in where all interfaces were gathered and controlled.
46
Ballast Nedam
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:
These ICDs are structured reports which are useful to document and collect all interface related information.
However, for the project in Stavoren the ICDs were not filled in yet in at the preliminary design phase. In this
stage a lot of interfaces were ignored or not even identified. In addition, only the EE was working with these
documents. It became clear that working aside from each other, without clear agreements about the
management of interface, and using different software tools, led to a lot of confusion and loss of information in
the project. There was no sufficient IM team who looked over the project as a whole, and coordinated the
several design teams. This, and several other aspects which are of less relevance for this thesis, resulted in a
reorganization in the project.
5.3.2
IM after reorganization
After the reorganization weekly meetings were organized to settle and identify the interfaces of a specific
object, which is at component level of the SBS. An interface manager was appointed to be in charge to organize
these meetings and lay down the IM process. The involved disciplines of a certain object were invited to an
interface meeting, in where a brainstorm session based on technical knowledge and experience revealed the
interfaces. These interfaces were given a specific ID number and were placed in an Interface Register (IR) in
RMT Relatics. These interfaces were also coupled to the objects in RMT Relatics, in where the status and other
47
Ballast Nedam
ID-number
Interface title
Interface description
Status
Objects attached
Control measure
Responsibility for the control measure
Status control measure
Requirement ID
Requirement title
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.
Furthermore, an interface matrix was developed in where all interfaces, between the components of the SBS,
were displayed by ID number to increase the visibility of all existing interfaces. This matrix is placed in
SharePoint , but to give an impression a copy is attached in appendix B. The goal of the matrix is to provide a
48
Ballast Nedam
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
In this part, the current practices as described in the previous paragraphs are evaluated. This is done by
evaluation the organization of IM, which changed during the course of the project, and by evaluating the
identification, description, coordination and control of the interfaces during the design phase. As last, also the
planning of design is evaluated.
5.4.1
In Stavoren, the management of interfaces did not go well in the beginning. IM did not get the necessary
priority which led to a situation in where all involved contractors worked separately. The contractors did not
work in the same requirements management tool, leading to contractors working with different versions of the
SBS, WBS and the requirements. Furthermore, a lack of understanding of how to work with SE, and how to
derive the functional requirements, led to several designs which did not comply with the requirements. No
interface manager was appointed, and the interface meetings were not structured and frequently organized.
Eventually, this situation led to a point in time where one of the contractors was already detailing his design,
while another was still working on the conceptual design. Interfaces between these contractors were not taken
into account at all.
After this phase, a reorganization has taken place. An interface manager was appointed, structured interface
meetings were organized, and the data was structurally stored in both Relatics and Sharepoint. It can be
concluded that the implementation of a sufficient IM program is required at the early phases of the project.
The later interfaces are taken into account the higher the risk of design iterations and rework. Furthermore, it
is important that the IM program receives support by all stakeholders. IM processes can only work if all
stakeholders cooperate. Therefore, alignment should be reached between all main stakeholders over the
importance and content of IM. The IM process, which includes tools, roles and responsibilities regarding IM,
should be agreed upon by all involved parties and documented in a IMP, in order to make the project a success.
49
Ballast Nedam
Interface identification
Before interfaces can be managed and controlled, they have to be identified and described. The main difficulty
with interfaces is that the identification of these interfaces is, just like the design process, an iterative process.
Just as the design develops into more detail, also the interfaces develop into more and more detail. In an ideal
situation, it will be possible to identify and deal with all interfaces at the start of the project. However, the
design process works from a rough to detailed level in several phases. Because the detailed design is still
unknown at the beginning of the project, is it impossible to identify the interfaces on to that level in advance.
Furthermore, changes in the design could lead to new interfaces as well. Scope changes or new requirements
from the client, as well as modifications from the contractors themselves, could easily lead to new or changing
interfaces. This makes the identification of interfaces an iterative process. If the design changes, or more
details are uncovered, new interfaces can arise. This nature of interfaces makes the process of interface
management quite difficult.
The interfaces at the Johan Frisosluis were identified during weekly interface meetings. In here all involved
parties revealed the interfaces based on experience and logical thinking. The project team in Stavoren
succeeded to identify all main and most important interfaces in time. This was accomplished by inviting all
involved project members to the frequently held interface meetings, in where all interfaces were identified
systematically based on experience. As the project progresses, additional interfaces were identified and added
to the IR. In order to check if all physical interfaces have been identified, 3D design was used by the mechanical
and structural engineer in this project. The 3D model increased the visibility of the project and is able to
identify clashes between the designs.
In order to identify all interfaces, all contractors should actively participate in the structured organized
interface meetings. Some interfaces may not be relevant for one of the contractors but could be of huge
importance for the others. Insight in the importance of IM and follow up on the processes as described in the
PMP, as well as all agreements made, are necessary to prevent interface issues. Furthermore, it is advised to
work with 3D drawings as much as possible, since these drawings could easily identify clashes which could
otherwise be overlooked.
5.4.3
Interface specification
When an interface is identified, all information regarding that interface has to be documented and specified. It
is important that all interface information is documented, and available in one place, for each stakeholder, at
all times. The involved parameters, required interface information of both contractors, and agreements about
tasks and deadlines should be described as soon as possible, and stored in a common place.
At the Johan Frisosluis, all basic information regarding an interface is placed in the IR in RMT Relatics. When an
interface is identified, all required information has to be collected and documented. However, this was not
always done consistently. Information was often missing, leading to confusions during the elaboration of that
interface.
5.4.4
Interface coordination
When an interface is identified and described, the next step is to coordinate that interface. An interface exists
between two components and needs to be uncoupled so that both design teams can finish their designs
individually. However, it is not always as easy to uncouple and control an interface. Both designers have to
coordinate their designs closely which often requires a back and forth flow of information. This information
could be dependent on other designs which makes the whole an iterative and complex process. Close
coordination and formal agreements related to that interface should lead to a mutual solution.
50
Ballast Nedam
Interface control
The interfaces should be monitored and controlled during the entire project life cycle to make sure no errors
arise. The status of the interfaces is monitored during the interface meetings in the design phase. Open
interfaces will be discussed, and measures will be taken where necessary. For all elaborated interfaces
verification is needed before the interface can be closed.
For the physical interfaces clash detection software in 3D design, as well as 2D drawings, are used for
verification in design. When no clashes are identified in as well the 2D as 3D drawings, the interface can be
closed. Verification of the functional interfaces is a bit harder. Depending on the interface a, in advance agreed
upon, verification method will be used. This could entail calculations, drawings, literature or any other prove
to ensure that the requirements are met.
After an interface is closed, it still has to be controlled during production and construction. As an example, a
lock gate has to be placed in a lock head. This interface is elaborated by giving the lock head and gate a certain
dimension. When during production the gate appears to be a bit bigger, and/or the lock head appears to be a
bit smaller, huge problems could occur. This risk should be identified in advance and could be controlled by, for
instance, taking a bigger margin in the design, or monitoring the fabrication process more closely. High risk
interfaces should be identified as risk, and treated as such by the risk management department. During design,
production and construction, it has to be clear what interfaces, and attached activities, need extra attention
and why. Control measures should be taken to prevent potential integration issues where necessary.
5.4.6
Design Planning
Project are decomposed into several components, which fall under the scope of multiple contractors.
Nowadays, at the start of the project a global construction planning is based on the SBS and WBS. The
construction phase requires a certain sequence of activities and has a certain time frame. The construction of a
component cannot start without the approval of all related formal design documents. Therefore, the detailed
design drawings need to be ready at certain points. The planning of the design components is mainly based on
51
Ballast Nedam
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
The interfaces which cross contractual boundaries are the most critical in infrastructure project development.
Even if all contractors interact with each other to resolve conflicts, or to improve the design, they are often
unaware of how their activities affect the delivery or operation of other project teams (Nooteboom, 2004). In
52
Ballast Nedam
The main engineering disciplines are all specialized in their field and produce different products. The CE usually
designs the civil structure, or lay-out of the project, the ME produces all mechanical equipment, and the EE
develops all electrical and software related parts of the project. All these products have to be integrated
successfully in order to develop the final system. Since the output of these disciplines differs a lot from each
other, it is not strange that the design processes slightly differs from each other as well. Three main differences
which have been identified in this chapter are the output they produce (objects versus systems), the internal
organization, and the path in time they take. These differences all bring their difficulties to the management of
interfaces, and should be taken into account at the start of the project.
5.5.1
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.
The design of the EE is hard to decompose in objects, and even harder to designate to geographical locations.
The systems they produce cannot be allocated to a single sub-system and are therefore separated from the
rest in the SBS. So, next to the area specific sub-systems is there a sub-system called Electrical and
Instrumentation (E&I). The components attached to this sub-system are systems like the operation and
control of mechanical systems, the communication system, energy supply, lighting system and building
related systems. These components have no site specific destination and are functional systems instead of
objects. Only the building related systems could be related to the sub-system Operating building since they
53
Ballast Nedam
Internal Organization
Another main difference between the EE and the other disciplines is that they work with a lot of
subcontractors. The CE and ME mainly design the objects their selves and only need suppliers for the materials
and detailed objects. In Stavoren the ME works with one sub-contractor, who is responsible for the design and
construction of the hydraulic drive. The EE develops systems, and because they do not possess all the specific
knowledge within the company, they have to outsource some of these systems.
These external companies have to design and construct these systems which bring even more complexity to
the project. The EE by nature is therefore already more of a system integrator than the other disciplines. The EE
has to control and monitor all the inter-disciplinary interfaces, and has to coordinate the interfaces of these
subcontractors with the ME and CE where necessary. For interfaces which require a back and forth flow of
information this process could be quite time consuming. The process takes more time than a direct line of
communication and will not stimulate the collaboration between the companies. Furthermore, sub-contractors
of the EE are less likely to adapt their design for the interest of the CE and ME, with whom they have no
contractual relationship with.
5.5.3
Path in time
Another difference between the disciplines is the path they take in time. The three main disciplines start with
their design based on all the requirements. The CE usually determines the main lay-out of the project at the
early start of the process. Whether the project contains a bridge, lock or a tunnel, the physical structure, which
will be visible, is always the civil structure. Therefore the global objects of the civil engineer are known
relatively soon in the project. Later on in the process the design will be worked out in more detail and the
dimensions of the structural design will be determined. For the ME, the physical objects can be determined
relatively quick as well. Looking at a bridge for instance, the design of the machine to operate the bridge with
depends on the global dimensions and type of the bridge. For the design of the machine the global dimensions,
height and functional requirements, like the speed the bridge should go open with, are crucial to determine
what kind of machine is going to get used. When all these requirements are known a trade-off analysis will be
performed to chose the best system.
The EE, on the other hand, starts with designing the main systems first. When the global lay-out of the civil
structure, and the type of mechanical machines, is known the EE can start with the design of the operation and
54
Ballast Nedam
Conclusion
In this chapter the main differences between the engineering disciplines in the design process are described.
Firstly, the EE designs systems, in where physical objects are included, while the other disciplines only design
physical objects. Therefore, the EE is usually separated in the SBS from the other disciplines. The components
of the CE and ME are divided into objects and geographical locations, while the components of the EE are
divided into systems. This setup shows the coherence of the project quite well, but on the other hand leads to
an enormous amount of interfaces for the EE. Secondly, the EE works with a lot of sub-contractors and
suppliers. All these extra parties makes the communication and collaboration between the entities much
harder. At last, the EE is very dependent on the design of the other disciplines which makes their design usually
finish last. A contractor waiting on interface information from the EE could either wait, or base his design on
assumptions. With the overlap of design and construction activities, contractors are more likely to base their
design on assumptions nowadays, in order to prevent delays. This brings along extra risk for the project.
5.6
Types of Interfaces
The interfaces which occur in a lock project are, of course, dependent on the way the project is decomposed.
By looking at the three main engineering disciplines a couple of standard interfaces could be identified, on a
lower level of detail. In other projects more contractors could be involved, which increases the amount, and
could influence the main types, of interfaces.
55
Ballast Nedam
Figure 29: Main types of interfaces between the main engineering disciplines.
Based on the main interfaces between all different project teams seven main types of interfaces can be
distinguished. The main interfaces between the engineering disciplines are displayed below:
Main interfaces between CE ME:
1) Spatial interfaces;
In here, all spatial interfaces between the mechanical, structural and electrical objects are described.
The exact dimensions and locations of all objects have to comply with each other.
2) Connection of mechanical installations and objects to the concrete structure;
Mechanical installations and steel objects have to be connected to the concrete objects.
Main interfaces between CE EE:
1) Spatial interfaces;
In here, all spatial interfaces between the mechanical, structural and electrical objects are described.
The exact dimensions and locations of all objects have to comply with each other.
2) Cables and Pipes;
Cables and pipes could go through concrete and/or steel objects.
3) Connection of electrical objects to concrete or steel structure;
Electrical objects (e.g. light structure, sensors) have to be connected to the concrete or steel objects.
Main interfaces between ME EE:
1) Operation and control mechanical installations;
EE has to design the soft- and hardware to operate and control the mechanical installation.
2) Energy supply for mechanical installation;
EE has to supply energy for the mechanical installations.
3) Connection Cables to the mechanical installation;
Type of cables and type of connection points have to fit the mechanical installations.
4) Cables and Pipes;
Cables and pipes could go through steel objects.
56
Ballast Nedam
5.7
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.
3.
4.
5.
6.
7.
8.
9.
10. The engineering disciplines possess specific knowledge and all speak their own language.
Because all disciplines have their own products and definitions, is it way harder to understand each
others processes and activities. Without sufficient communication and coordination
misunderstandings could easily occur.
57
Ballast Nedam
11. Disciplines argue who will adapt his design to the other regarding an interface.
An interface occurs between at least two objects. The interface could give discussions about who will
adapt his design to the other, regarding the interface. In Stavoren it happened that the ME placed an
hydraulic drive in the basement, while the EE placed his equipment on the same place. One of the two
had to adjust his design to the other, but both were of the opinion it should be the other.
Every project is unique and has unique circumstances, which indicates these problems and difficulties
mentioned above do not necessarily have to apply to all infrastructure projects. Therefore, these results are
verified in the next chapter Factors causing integration issues. In here, the main problems and difficulties
regarding IM in literature and practice are evaluated and compared. At the end of the chapter the problems
are categorized in two main areas of concern.
58
Ballast Nedam
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
In other engineering sectors a lot of literature is available about integration issues. In aircraft design for
instance, Tristl et al. (2013) identified and clustered the main problems around dispersed information,
collaboration and shortcomings in the synchronization between the several disciplines involved in aircraft
design. The key factors causing these interface, and integration issues, are shown in Figure 30.
Figure 30: Key factors causing interface and respectively integration issues in aircraft design (Trist, et al. 2012).
In the construction industry, interface related studies are very limited. However, some research has been done
in order to reveal the most common interface issues, and to identify their potential causes. In literature,
insufficient and inaccurate interface information, as well as inefficiencies in information sharing, are among the
most often mentioned causes leading to many critical interface issues (Al-Hammad and Al-Hammad, 1996; AlHammad, 2000; Miles and Ballard, 2001). IM cannot be properly performed without a sufficient flow of
information (Chen, 2007).
Josephson et al. (1996) did a study on construction defects and found that, measured by cost, design-caused
defects had the biggest impact. Out of these design-caused defects, it were those originating from lack of
coordination between the disciplines which caused the main problems. Cost overruns and delays often
emanate from a lack of planning and coordination specific to the interfaces. Especially those which link
different scopes of work. Contractors often coordinate their own IM issues well, effectively managing their own
specific work scopes and schedules. However, problems arise when issues cut across delivery teams, with
cross-function issues often not receiving the necessary priority (Nooteboom, 2004). Moreover, various project
teams and disciplines are often unaware of how their activities affect the delivery or operation of other project
59
Ballast Nedam
6.2
In paragraph 5.7 the main problems related to IM in Stavoren are mentioned. In table 1 (Appendix D) the
problems in Stavoren are compared with the main issues mentioned in literature. It can be concluded that
most of the problems mentioned in Stavoren can be related to the most common problems mentioned in
literature. Some factors identified in literature could be directly linked to the issues in practice, while others
have indirect links. Some of the factors identified in literature are (partly) caused by the aspects in practice, or
the other way around.
Based on the findings from literature and practice, two main categories for interface issues have been
identified. Most of the factors mentioned are related to two categories, which are a poor communication
among parties and a poor coordination among parties.
Poor communication among parties
Communication is the activity of conveying information. Infrastructure projects involves many stakeholders,
which cannot function effectively without good communication among the participants. This back and forth
flow of information is essential for project success. Poor communication causes a wide variety of design errors,
conflicts, delays, and project failures, which reduce the overall performance of project participants as well as
the quality of the final product. The communication between employees from the same company is usually
much better than across contracts boundaries. This is one of the main reasons inter-disciplinary interfaces
60
Ballast Nedam
61
Ballast Nedam
62
Ballast Nedam
63
Ballast Nedam
64
Ballast Nedam
7.1
At the start of the project, the foundation for IM should already be implemented. Several studies emphasized
that implementing IM at the early stages of the project will result in higher performance in terms of scope,
time, and schedule (Nooteboom, 2004; Chen, et al. 2007). Therefore, a IM plan should be implemented as early
as possible.
It is important to include all main parties from the start of the project in order to reach consensus about the IM
program. Understanding the importance of the process, as well as a commonly accepted process, is critical to
create a climate in where everyone participates proactively. Once an IM program has been established, the
program ensures all interactions between contractors, related to interfaces, are managed and coordinated
closely. This will avoid issues arising from misunderstandings or lack of information, and will allow decisions to
be made faster and with more clarity. Once alignment has been reached, all agreements and methods related
to IM have to be documented in an Interface Management Plan (IMP), which describes the whole IM process
for the project. Such a IMP describes a clear IM program for the project, which is supported by all stakeholders.
7.1.1
The implementation of a systematic IM process involves the development of an IMP, which clearly describes
the roles, responsibilities and expectations of both the owner and the contractors. The IPM ensures all parties
understand the IM objectives for the project, and that the right people, processes and tools are in place when
and where needed. An IMP should include:
IM objectives, including interface (management) definitions and goals for the project for all contractors;
Clear roles and responsibilities of all involved parties and project members, including the IM team;
Plan of how to resolve conflicts and overcome barriers to the benefit of all;
Clear description of all communication channels;
Methods and procedures to handle changes;
Clear description of all registers and standard forms which will be used in the project;
65
Ballast Nedam
Interface Manager
An Interface Manager has to be appointed for the project, who will have primary responsibility for the whole
scope of IM. The Interface Manager is responsible for the development of the IPM and will carry out and
monitor the whole IM process. The Interface Manager will organize the interface meetings, assist with the
identification of interfaces, generate interface agreements, monitors all project teams to ensure timely
response to requests, assign tasks to team members, and will monitor the status of all interfaces thru to
closure.
Before the tender phase the client could already include an interface manager, or system integrator, to make
sure the exact scope of each contractor is clear and sufficient, and that the responsibilities of the main types of
interfaces are understood and clear. However, after the tender phase this person cannot longer take on the
66
Ballast Nedam
67
Ballast Nedam
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
Ballast Nedam
69
Ballast Nedam
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
Ballast Nedam
The colors in the N-chart quickly reveal what parties are involved regarding an interface. Each block shows all
possible interfaces between two contractors. As can be seen in Figure 34, the involvement of four contractors
in the project means there are four possible contractors to have interfaces with. Interfaces between
components of the same company, the intra-disciplinary interfaces, could easily be recognized by color and
should not be covered in the interface meetings. These are the responsibility of the individual contractors, and
will be handled internally.
Next to a division by contractor, the N-chart could also be ordered by components falling under the same subsystem. Because the sub-systems of a project are usually based on physical locations or other strong relations,
most interfaces are likely to fall within the sub-system itself. Especially in larger projects, where the sub-system
is managed by a separate person, it could be sufficient to see what interfaces fall within the sub-system (and
the scope of this manager), and what interfaces exist with other sub-systems. See appendix B for an example of
a sub-system based N-chart. By ordering the N-chart in these two ways, it becomes clear what interfaces fall
within and outside the sub-system, and what interfaces fall inside or outside the scope of the involved
contractors.
The identification of interfaces mainly happens during so called interface meetings. These meetings are
arranged by the interface manager, in where all involved parties are invited. Next to the design teams, also
members of other project disciplines like planning, construction and maintenance should participate in the
process. These interfaces will be identified by all team members of the project, using the design documents,
SBS, FBS, RBS, and all contract documents. If available, interface registers or lessons learned documents of
71
Ballast Nedam
7.4
Interface Documentation
Once an interface is identified and approved, the information related to each interface must be defined and
documented. Relevant interface information includes the interface characteristics, involved parties, deadlines
and needed documents. In this chapter is explained what interface related information should be obtained and
how and where this information should be documented.
7.4.1
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.
72
Ballast Nedam
Title
Description
Type
Status
Object
ID
Objects
Involved
contractors
Interface
Agreement ID
Req. ID
Resp.
For each interface, a separate page can be added in where additional information, constraints and comments
could be placed. In here also the verification method is described, as well as the document ID-numbers in
where the interface solution and verification of both components is elaborated. More information about the
implementation of the IR and the additional interface pages can be found in Appendix E.
Status
The status of an interface is either open, in progress or closed. When an interface is identified but no
agreements are made yet to elaborate the interface the status will stay on open. The status will change to in
progress when agreements have been made about the interface solution, or the exchange of specific interface
information, including clear responsibilities and due dates. The status will change to closed at the moment the
interface solution has been verified for both components attached, as well as the integrated part. During
fabrication and construction the interface still exist, but the closed status indicates the interface has been
taken care off in the design of all objects attached. The interface manager will monitor all interfaces and when
the design of an object changes, after the settlement of an interface, the status could be changed back to
`Open` or `In progress`.
Interface requirements
For simple interfaces an interface requirement could be derived. Especially when this part of the project will be
outsourced to a sub-contractor. For each interface maximum one requirement could be derived and listed in
the RBS. More requirements could lead to confusion and conflicting requirements. By deriving a SMART
requirement of the interface solution, the interface is uncoupled. Think for instance of a wall and cables which
73
Ballast Nedam
Risk
In short, the requester fills in an IA form and requests for the delivery of specific interface information within a
certain time frame from another contractor. The responder has to sign this agreement if the requirements can
be met, which makes the agreement formal and frozen. When the delivery date cannot be met, a delivery date,
different from the request date, could be proposed. When consensus between the contractors cannot be
reached easily, the interface can be flagged as high-risk and/or the status may stay on open, which means the
interface will be discussed in the upcoming interface meeting.
Action items
Each IA could have several AIs. These actions are small tasks which have to be executed in order to fulfill the
agreement. An example of an action could be look up the required free space for maintenance of pipe Z, in
Manual X. These action are less formal than IAs, are much shorter in duration, and are designated to a single
project member who has to fulfill this action within a certain timeframe.
74
Ballast Nedam
Interface Responsibilities
One of the major causes of integration issues is the lack of awareness about the ownership and responsibilities
regarding the interfaces. In the IAs is specified what specific information has to be exchanged, and what the
roles and responsibilities of all interacting parties are. However, before an IA can be developed it has to be
clear who the responder and who the requester is regarding the information.
A responsibility matrix, like the RASCI-matrix, could be used to visualize the roles and responsibilities belonging
to each interface (Rose, 2008). By using this matrix the responsibilities of the interconnecting parties involved
in the execution of the interface are identified. RASCI stands for Responsible, Accountable, Support, Consulted
and Informed, respectively. The description of roles for the interface execution is as follows:
Responsible:
Accountable:
Supportive:
Consulted:
Informed:
The party responsible for the interface overall performance, and approves the
accuracy of interface characteristics (i.e. the requester of interface information or
deliverables).
The party, who generates the IA, and has the legitimate authority to approve the
adequacy of the work, and makes the final decision to close an agreement.
The party who gives support to facilitate the process accomplishment (e.g. the party
who may have to grant the other parties access to the site).
The party who responds to the IAs and provides the deliverables.
The parties who need to know the status of the IA, in order to help them better
schedule their own work or the work of others.
The purpose of using RASCI matrix is reducing risk by increasing the visibility, and eliminating ambiguity about
the roles and responsibilities regarding the execution of each interface. A sample of a RASCI-chart is shown in
Table 3. The left column includes interface IDs, and the top row includes all the project members/contractors
who may be involved in an interface. The cross-sectional cells indicate the responsibility of each party
regarding an each interface, if there is a relationship.
Table 3: Sample of RASCI-Chart
Owner
Interface
Manager
RV1
R
A
RV2
A, S
RV3
I
A
RVi
S
A
75
Contractor A
Contractor B
S, C
R
R
Contractor i
C
C
I
Ballast Nedam
76
Ballast Nedam
In general, interfaces represent risk to the project. However, some carry more risk than others. Only the
interfaces which contain a high risk for the project, and therefore, have a high potential to cause delays or
additional costs, require close coordination, control and management. Extensively document and manage
every single interface should be avoided, as it would cause the system to quickly become overburdened with
information.
With hundreds of interfaces which have to be managed, how can these be differentiated from one another?
How to ensure the right interfaces are monitored at the right time? In managing interfaces the Pareto-principle
applies, which means 80% of the problems are caused by 20% of the interfaces (Varghese and Senthilkumar,
2010). Therefore, it is important the IM team takes proactive measures to identify these problematic interfaces
as early as possible, and to keep track of the information exchanges at these interfaces. Interface coordinators
must work with their team to identify interfaces they feel represent high-risk. In addition, it is important that
an interface can be flagged as high or low risk at any given moment. Some interfaces carry no risk at the
beginning of the project, but could become problematic during the course of the project. When a risk is
recognized by a design team, it should immediately be flagged as such. This ensures that all involved parties
become aware of this risk instantly, and can give the interface the attention it requires.
Types of interface risk
Basically three main types of risks can be distinguished which are financial, schedule and performance risk.
Schedule risks are those risks associated with the adequacy of the time estimated and allocated for the design
and construction activities of the project. Financial risk is the risk associated with the ability of the project to
achieve its life-cycle cost objectives. As last, performance risk is the risk associated with the evolution of the
design affecting the level of performance, necessary to meet the stakeholder expectations and technical
requirements.
Schedule risk
When objects are dependent, it means one object needs information from another, in order to continue with
its design. However, when this information is not known in time conflicts could arise. If, for instance, the EE
needs to put his cables through a concrete wall, the CE has to know the exact location and dimensions of these
cables. Issues with this interface often occur in infrastructure projects. The EE does not know exactly where his
cables will go through at the time the CE wants to know this information.
Therefore, most of these schedule risks can already be identified during the preparation of the IAs. In the early
workshops most interfaces and required information have been identified. In here, consensus has to be
reached about the content, direction of flow and delivery dates of that information. The requester asks for
interface information within a certain time frame. When the responder cannot deliver this information within
that time frame delays could occur. The interface could be flagged as high or medium risk and will be discussed
77
Ballast Nedam
78
Ballast Nedam
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
In the cases when it is not possible to develop an IA between the parties, to derive a requirement directly from
the interface, or when the interface is flagged as high risk, other strategies could assist in the elaboration of the
interface. In chapter 4 several strategies have been proposed. These strategies could be applied to work out
complex and high-risk interfaces.
Re-sequencing design activities
One of the most practical strategies is re-sequencing design activities. When the design for two interfacing
objects is scheduled at different points in time it should be tried to re-sequence the design activities and pull
one of the objects forward so that both objects can be worked on at the same time. Interfaces with high risks
should also be pulled forward in the design process, just like is currently done with components which have to
be finished earlier due to construction constraints. This way the planning could be changed so that complex
components with high interface risks are designed at the same time, preferably at the same physical location,
in an early phase of the design. This will make it easier to coordinate and to exchange specific information. In
addition, by pulling the involved objects forward in the design process more time is available for the
elaboration of that interface.
It should be explored what consequences pulling the objects forward have on the predecessor and successor
activities. Choosing a design solution could be based on assumptions which lead to constraints on the
predecessor activities. However, by elaborating the high risk interfaces earlier in the design process potential
delays and costs could be prevented in the long run. By freezing the design, modifications to the design will
only be possible after formal change requests, when all consequences have been evaluated. This will lead to
less unnecessary design iterations.
79
Ballast Nedam
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 projects IM program for how contractors
will communicate with each other, and how conflict will be resolved. Most important methods to communicate
are:
80
Ballast Nedam
Face-to-face meetings
All interfaces will be discussed during the interface meetings. In these face-to-face meetings, which are held on
a regular basis, the details, status, progress and possible agreements are discussed with all involved parties.
Further face-to-face communication will mainly go through the member of the IM team.
In case of conflicts, the interface manager and interface coordinators will communicate with each other, faceto-face. Interface managers must have the authority to motivate project teams and get issues resolved early,
thus preventing issues from being ignored or delayed. When conflicts arise the IM team is responsible to
engage a conversation between the involved parties, in where the interface manager will have the authority to
make decisions in the interest of the project. IM personnel can help resolve critical issues, facilitate timely
decisions, and maintain schedules. This negotiation process among teams occasionally results in solutions that
may not be universally appreciated but are necessary to meet delivery commitments.
Forms, registers and tools
The IR is used to communicate the existence and specifications like status and risk factor of all identified
interfaces. This IR is dynamic in nature, and could be adapted at any time by the IM team. The main roles and
responsibilities of each contractor regarding interfaces are communicated by a RASCI-chart. In this chart, for
each interface multiple roles and responsibilities can be assigned. The N-chart is used to communicate all high
risk, new and open interfaces to all stakeholders. This chart visualizes what interfaces need extra attention, in
real time, and forms the basis for the upcoming interface meeting.
Main formal forms to communicate interface related information with, are the IAs, and CRs. The IA is used to
request specific interface information and deliverables. The responder may communicate in several ways, but
the most convenient way is by specific drawings and reports. CRs are the formal way to communicate a request
to change an existing interface or IA. The Configuration Management (CM) team is responsible for controlling,
approving and rejecting changes during the design and construction phases of the project. More about CM can
be found in the next chapter.
The progress of the interfaces, and the exchange of interface information, have to be monitored to ensure each
party receives the requested information in a timely manner. The communication will mainly happen through
the IR, IA register, and AI register, in where the progress can be monitored by the IM team by looking at the
due dates. The N-chart, and the integration of high risk interfaces as milestone activities in the project
schedules, are used as extra method to communicate and monitor the most important interfaces to all project
members.
Technical tools play an important role in the communication procedure as well. These tools will be discussed in
paragraph 7.8. In short, communication through spreadsheets, excel, e-mail and phone is not recommended.
All ways of communication are accepted as support, but all formal communication have to go through the
tools, forms and registers as defined in the communication plan. Tools and templates encourage automated
processes, and leave less room for errors.
Alerts and Notifications
The IM team should notify the responder if IAs or AIs are over due date, and have to find a common solution.
Automated work processes could ease this process by flagging overdue activities and sending electronic
notifications and reminders to the involved parties. The interface manager is in charge of the progress and is
responsible to act when issues arise.
81
Ballast Nedam
7.7
Interface Control
Monitor and control of the interfaces is necessary to keep an eye on the overall progress, to prevent and solve
integration issues, and to verify the design solutions during the whole project lifecycle. The IM team is
responsible for monitoring the interface data as stated in the IR, including the corresponding IA due dates. The
IM team should organize regular and ad-hoc interface meetings, in where the progress of all high risk and open
interfaces is discussed.
The IR, IA register and AI register are used to monitor all interfaces. IAs and AIs which are close to their due
date could receive a electric notification of alert. All involved parties should be aware of the work load,
progress and potential issues (e.g., deliverables are delayed or contractors are not communicating). During the
project it is important that all information is easily accessible. The registers and reports should provide the
project team with the data they need to continually monitor the progress.
The client and interfacing parties should be warned in case of a forecasted delay or any other interface related
issue. In addition, the IM team is also responsible for the verification of both components regarding the
interface solution. The design should meet the interface requirements, before an interface can be closed. Next
to the IM team, also the CM team, project planning, and the risk management department are involved in the
elaboration of interfaces, and play a major role in monitoring and control these interfaces.
7.7.1
Configuration Management
CM is a management discipline, applied over the products life cycle, that controls and monitors changes which
could affect performance, functional or physical characteristics. The CM team is responsible for the
82
Ballast Nedam
Risk management
High risk interfaces, or crucial interfaces, should be easy to track and control throughout the entire project
lifecycle. As described in paragraph 7.3 is the N-chart a convenient tool to capture all interfaces. However,
cluttered and chaotic matrices should be avoided. Therefore, in order to prevent the N-chart for becoming
confusing and unclear, the amount of interfaces has to be controlled. In order to reduce the amount of
interfaces, without changing the level of decomposition, only those interfaces which require extra attention
should be put in the N-matrix. A traffic light system could be used to manage and report the critical nature of
83
Ballast Nedam
1510
1520
2111
2112
2113
2121
2131
2132
2133
2.1
17.1
The IR provides the ability to flag interfaces as high risk and revert back to low risk at any given moment. An
interface which does not represents risk during one phase of the project, may do so during another phase. On a
frequent basis (e.g. every two weeks), the chart will be updated with additional high-risk interfaces, and all
open and new interfaces which have been addressed could be removed.
All high risk interfaces should also be included in the risk register, in where the risk managers will threat the risk
as any other. This means the risk will get a quantification, and in consequence prevention measures will be
explored, as well as mitigation strategies. Risk mitigation is very important and without reporting high risk
interfaces, the risk manager is potentially making decisions without the complete picture.
7.7.3
Project planning
When the most crucial interfaces have been identified, extra control is needed to prevent potential issues with
these interfaces. An interface delay could impact a critical path activity in the overall project schedule, leading
to a delay of the project. Therefore, next to the visualization of all high risk interfaces in the N-chart, also the
schedule impact of these interfaces have to be monitored systematically by all stakeholders. Each project
stakeholder should be able to integrate high risk interfaces, as managed in the IM system, as key milestone
activities within its respective organizations project schedule.
In Figure 37, the process of schedule integration is simplified by three main aspects which are the interface
register, the N-chart and the project and discipline design programmes. In the IR all interfaces are displayed.
The interfaces which are flagged as high risk are transferred to the N-chart, in where they become easily
visibile for all stakeholders. For each high risk interface a milestone activity is established, which will be
integrated in the project and discipline desing programmes. This is a dynamic process since the high risk
interfaces can be flagged at any time of the project life-cycle. Regurarly the project schedules will be updated
by the newest updates of the IM system.
84
Ballast Nedam
The integration of the project schedule with the interface milestones will add transparency to the process and
increases the visibility of important interface due dates. As part of the project planners regular analysis of the
critical path, any impact caused by an interface, or impacting an interface is identified, assessed and reported
back to the interface coordinator. The interface coordinator on his turn must evaluate options to avoid or
mitigate the schedule impact of that specific interface within their project schedule. The project planner and
interface manager collaborating facilitates that all impacts on the project schedule caused by an interface, or
impacting an interface, will be monitored and controlled. Properly executed, schedule integration ensures that
interface related schedule risk can more easily be identified by each contractor and the project owner, and that
an efficient process exists to resolve interface related schedule issues.
7.7.4
Verification
As part of interface control, the design of all components related to an interface, have to be verified. During
validation and verification activities, multiple components are checked out as integrated subsystems or system.
For each interface, both the components attached to that interface, as well as the integrated system, have to
be verified before an interface can be closed.
Physical interfaces could be verified by checking the design drawings on inconsistencies. Clash detection
software in 3D modeling programs could be used to automate and ease that process. When this software is not
available, drawings could be checked manually on inconsistencies. Preferably, the verification method is
already be agreed upon at the moment an interface is set-up, to avoid confusion about it in later phases.
Functional interfaces and more complex interfaces cannot always be verified by checking drawings on
inconsistencies. The involved parties should discuss the verification method in advance. Depending on the
interface, a separate verification plan could be developed which could include calculations, tests, drawing,
prototypes, reports, etc. It should be clear who is responsible for the elaboration of what part of the interface,
how both parts will be verified, how the integrated (sub-)system will be verified, and, as last, by who and when
the interface will be verified.
The elaboration of an interface, including the verification plan, could be documented in a ICD, but may also be
included in the design documents. The ICD or design documents show the specific solution to an interface, of
both sides, and entail the verification details. The ICD and other verification documents can be communicated
to the owner, or other key stakeholders, if necessary. When the interface is complete, the interface manager
can close this interface in the IR. The interface manager is the only person who can adapt the status of
interfaces in the IR.
7.7.5
Conclusion
Monitor and control of the interfaces is necessary to keep an eye on the overall progress, to verify the design
solutions, and to prevent and solve integration issues during the whole project lifecycle. The IM team is
85
Ballast Nedam
7.8
The IM process has to contain of technical or engineering aspects (appropriate tools and methods) as well as
organizational design and soft management aspects. Tools alone, without the foundation of a well-structured
process, will not have the intended effect. On the other hand, a well structured process without tools to
support the method is hard to maintain, and is sensitive for errors. Therefore, both technical and organizational
aspects have to be combined in the IM program in order to cover all aspects of IM. In the previous chapters the
organizational aspects have been widely discussed. In this chapter, several tools are mentioned to assist in this
process.
To support an IM program, a collaborative solution with the ability to manage thousands of interfaces and
interactions between parties is essential. Using the right tools can make or break the IM process, and therefore
communication through a combination of Excel spreadsheets and e-mail is asking for trouble. Traditional
databases, spreadsheets and paper-based IM systems limit the efficiency of contractor interactions, and the
oversight of interface issues. Those methods increase the risk of losing data, deadlines not being met and
information not getting to the right individuals. At best, they allow rushed collaboration between interface
coordinators, but not across the scopes of work under their management.
IM is inseparably linked to a correct and efficient flow of information. Therefore, it is important this
information is delivered efficiently to all involved parties, at the right time. Tools like a Document Management
System (DMS) and Building Information Modeling (BIM) software could assist in here. For the management of
interfaces itself Relatics is currently used. Modifications to the IM process, as described in the previous
chapters, could be implemented in Relatics. However, also a specialized IM tool could be developed or
purchased which could automate the processes to a certain degree.
7.8.1
A DMS has to be used for the storage of all reports, drawings and documents in the project. The DMS should be
a system in where all relevant, interface related, documents are stored, and which is accessible by all involved
stakeholders, at all times. Having one DMS for all stakeholders, prevents information to get lost, and
misunderstandings about specific information.
86
Ballast Nedam
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:
87
Ballast Nedam
Evaluation of the DIMS tool, as described in Appendix F, concluded that the alert mechanisms, which
periodically notified specific individuals about their information requirements to meet the approaching
deadlines, played a significant role in eliminating delays in their project. On the market several ready-to-use IM
tools are available. Coreworx, for instance, offers an IM program which helps to manage projects interfaces
securely, quickly, and effectively (Coreworx, 2014). Profession IM tools like the Coreworx IM program provide
a platform which is purely focused on the documentation, management and control of interfaces, and
therefore provide a solution which is much more efficient than Relatics.
7.8.3
Building Information Modeling (BIM) programs could be of huge assistance in infrastructure project
development. 3D geometry and supporting software (like for instance MX or Civil) are of invaluable assistance
when managing interfaces. Building in 3D increases the visualization of the project, and can be used as formal
way of communication. Clash detection software could easily detect physical clashes in the design in advance,
which could help to prevent integration issues. By building in 3D the process can also be monitored much
easier. At the moment, the usability of BIM programs is increasing rapidly. In the near future, these programs
are likely to do a lot more than visualizing the design in 3D. However, BIM software will always have an
assisting role in the IM process, rather than be the solution for IM itself.
7.8.4
Conclusion
Tools to assist in the IM process are a must. A well structured process without tools to support the
methodology is hard to maintain, and is sensitive for errors. Therefore, both technical and organizational
aspects have to be combined in the IM process in order to cover all aspects of IM.
Technical tools in the form of software come in many shapes and sizes. A DMS is necessary as platform to store
all documents in the project. All documentation should be stored, secured and available for all stakeholders at
all times. Through real-time access to interface status, progress and interface-related documents, stakeholders
are equipped with the information necessary to proactively respond to potential interface issues, in an early
stage of the project. Next the a DMS also a specific IM tool has to be used. Relatics is not purely developed for
IM, but could fulfill this role quite well. When more automated processes are wanted, specific IM tools could
be developed or purchased. On the market several ready-to-use IM programs are available for the
development of large multidisciplinary projects. BIM programs could further enhance the IM program by
increasing the visualization of the design solution, and automatically detect clashes between the several
components.
A successful IM program starts with a sufficient IM process. However, technical tools to implement, and assist
with, the IM process are just as important for the realization of a successful project. Sufficient use of technical
tools could improve the efficiency of the team, provide standardization across the project, and provide
consistency in the documentation and exchanging of data between contractors.
88
Ballast Nedam
7.9
Conclusion
In this chapter an IM method is proposed and widely elaborated. At the start of the project a IMP has to be
developed in where the whole IM process is documented. This process consists of five main steps which are
interface identification, documentation, communication, control and closure. The IM team responsible for the
implementation of the IM process consists of an, preferably experienced, interface manager and by several
interface coordinators. Those coordinators are the representatives of each project team, responsible for the
elaboration of the interfaces, and are the single point of contact regarding any potential interface issue.
Before IM can start the SBS, WBS, RBS and OBS have to be specified. The components of the SBS indicate
where potential interfaces could occur, while coupling to the OBS will define the main responsibilities. The
identification of interface will mainly occur in the interface meetings. In here, the identification is mainly based
on the experience and common knowledge of the project members. The FBS, RBS and SBS are used as three
main perspectives from which the functional and physical interfaces could be subtracted. A N-chart could be
used as tool to identify all internal interface possibilities between the components. Throughout the course of
the project more and more interfaces will be identified, which have to be reported to the teams interface
coordinator.
When an interface is identified it will be placed in the IR, in where all related information is obtained.
Agreements about the exchange of information will be done with the help of IAs, which are the formal way of
requesting interface information. In order to create an IA one party has to be the responder while the other
has to be the requester related to that interface information. A responsibility matrix can be used to visualize
the roles and responsibilities belonging to each interface.
When it is not as easy to uncouple an interface with IAs, or when the interface carries a high risk factor, other
strategies could be applied to assist in elaborating the interface. It might be helpful to re-sequence the design
activities attached to those objects. When those objects are pulled forward in the design phase, and are
designed at the same point in time, collaboration is much easier and there will be more time to elaborate the
design activities. Also strategies like forming cross functional teams, using team problem solving and sharing
ranges of acceptable solutions, are good strategies to further assist in the elaboration of complex interfaces.
These strategies mainly focus on collaboratively finding a solution and will speed up the process.
However, the most common strategies to uncouple interfaces, which are designed at different points in time,
are making assumptions and applying overdesign. Predicting the interface information bring along extra risk for
the project when the assumptions appear to be incorrect. Therefore, before making assumptions about the
interface information, and applying overdesign, the benefits and costs, as well as the potential consequences
should be carefully explored.
A communication plan is required so that project members understand what information to communicate, how
to communicate, and when to communicate. The IR is used to communicate the existence and specification of
all interfaces. Next to the IR, also the N-chart is used to communicate all high risk, new and open interfaces to
all stakeholders. This chart visualizes what interfaces need extra attention, in real time, and forms the basis for
the upcoming interface meeting. Main formal forms to communicate interface related information with, are
the IAs, AIs, ICDs and CRs. All interface face-to-face communication will go through the interface coordinators
and ultimately the interface manager.
It is the IM teams responsibility to monitor and control the interfaces in order to keep an eye on the overall
progress, verify the design solutions, and to prevent and solve integration issues during the whole project
89
Ballast Nedam
90
Ballast Nedam
8.1
In this section an answer is given on all defined sub-questions, followed by the main question, as stated in
paragraph 1.4.
8.1.1
1.
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.
Chapter 3.2 contains an introduction of Systems Engineering (SE), which has become a much used standard in
the Dutch construction industry. According to the SE philosophy, a system is first decomposed into sub-systems
and components, which is displayed in a Systems Breakdown Structure (SBS). These parts of the system, which
can be designed by different teams of engineers, are what causes the existence of interfaces. The way the SBS
is set-up determines the amount and type of interfaces within the project.
However, guidelines to identify, manage and control these interfaces are scarce in SE literature. Several
guidelines have been explored in paragraph 3.3.3. NASA mentions several standardized forms to assist in
identifying and capturing the interface information, and the approved interface change requests (NASA, 2007).
In addition, the link to Configuration Management (CM) is mentioned by proposing interface baselines to
ensure that changes in the design of components have minimal impact on other elements, with which they
interface.
SE guidelines in construction, like Prorail and Rijkswaterstaat (2009), emphasizes that the structured recording
of interface data ensures that the right information is available at the right time. The typical SE tree structures,
such as the Functional, Requirements, Systems and Work Breakdown Structure (FBS, RBS, SBS and WBS) are
mentioned as tools to manage the complexity of projects. A specification tree is proposed in where all
requirements, preconditions and interface requirements are grouped by component and sub-system. In this
way the specification tree shows the relationship between the specifications, structured to the different levels
91
Ballast Nedam
92
Ballast Nedam
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.
The engineering disciplines in infrastructure projects are usually the civil or structural engineer (CE), the
mechanical engineer (ME) and the electrical engineer (EE). In chapter 5.5 the main differences between these
engineering disciplines are explored. The design process is for all disciplines an iterative process in where one
works from a rough to detailed level, resulting in a conceptual, preliminary and detailed design. The three main
differences which have been identified in this chapter are the (1) output they produce, (2) the internal
organization and (3) the path in time they take. These differences all bring their difficulties to an IM program,
and should be taken into account at the start of the project.
93
Ballast Nedam
Factors causing integration issues in infrastructure project development have been explored by conducting a
case study (5.7) and a literature review (Ch.6). The findings have been compared to each other and are
summarized in table 1, in Appendix D. When analyzing these factors it becomes clear most issues could be
related to poor communication and coordination between the involved parties. Main factors identified are:
Poor communication between the involved parties:
Lack of communication among parties;
Delayed or ineffective communication among parties;
Poor coordination between the involved parties:
Unawareness of interface issues;
No clear ownership and responsibilities;
Lack of resources and personnel to facilitate coordination;
Lack of coordination among specialties;
Poor ordering of tasks;
Unable to work on site simultaneously;
Unwillingness to bear coordination and resolution responsibilities.
94
Ballast Nedam
IM is the discipline related to the integration processes. Implementing an IM process which encounters the
main factors causing the integration issues as mentioned in sub-question 6 could assist in diminishing these
issues. The main research question was defined as follows:
RQ:
How to improve the interface management practices in infrastructure project development, in order to
reduce unnecessary design iterations and rework?
Unnecessary design iterations and rework could be reduced by implementing a systematic approach for IM at
the start of the project. There are currently no clear guidelines of how to cope with the interfaces within an
infrastructure project. In most projects the benefit of IM is underestimated and the process does not get the
attention it requires. A lot of interfaces are not identified in an early phase, and even when they are identified
it is often unclear how to elaborate those interfaces efficiently.
The current practices could be improved by implementing a systematic IM approach at the start of the project,
including an IM team to lead and monitor this process. This approach has to contain guidelines of how to
identify and elaborate these interfaces in a systematic way. A clear IM process that provides a structure to cope
with these requirements is proposed in chapter 7. However, it should be noted that the proposed solution has
not been tested on a real life project and is therefore a theoretical approach. Without more research it cannot
be said with certainty that the proposed process, as described in chapter 7, will actually diminish unnecessary
design iteration and rework in real life projects.
8.2
General conclusions
By conducting this research and answering the research questions throughout the report, several conclusions
could be extracted. In this section the main conclusions for this research are summarized.
Introduction of integrated contracts led to an increase of integration issues
The introduction of integrated contracts led to the compression and overlap of the design and construction
schedules. Because of the current time pressure less time is available for coordination and communication with
the other parties. Furthermore, because of the nature of the different engineering disciplines is the design of
the EE usually finished last. The design of the EE is often still in progress when the design of the CE and ME is
already finished or even when construction is already started. The output of the EE could influence the design
of the CE and ME, and could therefore have huge consequences when construction of that object is already
started. The introduction of integrated contracts increased the amount and consequences of integration issues,
and therefore more attention have to be paid to the integrated system as a whole to prevent such issues from
happening.
Clear scope of work
Before an IM process to identify and elaborate the interfaces can be successful the scope of work of each
contractor has to be clear. Confusion about the responsibility of contractors and disagreements about scopes
of work are common problems. Before starting with a project the contractual boundaries for each contractor
have to be clear and all high-level interface responsibilities should be determined. The client should assist in
this process when outsourcing the project. When the parts of the project are not sufficient allocated to the
involved parties, grey areas could arise between the scopes of work. These grey areas of which nobody knows
who is responsible could be a huge risk to the project. Clear scope packages could be derived by making a clear
decomposition of the project and allocate all parts of the project to the responsible parties. This could be
95
Ballast Nedam
96
Ballast Nedam
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.
Technical tools could make or break the IM process. It is important to use programs which all
contractors are able to work with. Three main tools are of great value for an IM process: a Document
Management System, an IM tool, and 3D design.
97
IM tool:
An IM tool has to be used which could dynamically manage all interfaces. RMT Relatics is
often used to manage all requirements, and to couple all specifications to the objects and
activities. In here, all breakdown structures could be linked to each other. Of each object all
specifications like the requirements, risks and interfaces are attached. In Relatics, all registers
and charts for the purpose of IM can be implemented and controlled. This makes this tool
quite sufficient to implement the IM process. However, a tool which includes automated
processes, notifications and alerts, and adds graphical information could further enhance the
efficiency of the IM process.
3D design:
3D design and clash detection software are valuable to assist in the IM process. Clash
detection software could easily detect clashes within the design. These missed interfaces, or
design errors, are in this way detected in an early phase, which could prevent
Ballast Nedam
8.3
After the conducted research presented in this thesis, recommendations can be derived for Ballast Nedam.
These recommendations could be taken into account to diminish integration issues in infrastructure project
development. The recommendations derived are the following:
98
Ballast Nedam
Steer, and take into account, the contractual responsibilities of the involved parties.
When BN gets involved in a new project as general contractor, it should make sure all involved
contractors share the same objectives and goals for the project as a whole. It was generally mentioned
in the interviews that some contractors lack responsibility towards the final result/performance. In
practice, there is usually no contracting relationship between the specialties and their respective
contracts do not fully specify coordination responsibilities. When the client wont include coordination
responsibilities in the contracts of each involved contractor, BN should carefully consider all risks
before executing the project. Especially the contractual involvement of the EE is crucial. The EEs
willingness to cooperate in an early phase, and to reveal certain information earlier, is necessary for a
successful development of the project.
When BN decides to outsource certain aspects of the project it is advised to elaborate the interfaces in
advance. When possible, interface requirements should be derived and added to the existing
requirements. By elaborating the interface solution in advance no confusion or conflicts can arise
regarding these interfaces later on.
Take time to evaluate projects, and develop lessons learned for internal use.
More time should be spend to the evaluation of executed projects and a lessons learned should be
developed. In addition, for each type of project, a clear decomposition including all interfaces and risks
should be collected in a database. By keeping a database, one is able to see in advance what objects
make part of a typical tunnel, bridge or lock project, what their interfaces are, and what the high risks
might be in the next project. Analysis of lessons learned within each project will further improve the
IM process and projects efficiency.
99
Ballast Nedam
8.4
The proposed solutions to diminish integration issues across contractual boundaries has its limitations. During
this research additional suggestions for research did came up. These suggestions do not fit in the scope and
therefore have been disregarded. The following subjects are worth studying:
Apply the approach for Interface Management at the start of a real project
A major limitation of this research is the fact that the proposed method have not been tested, and is
therefore a theoretical approach. The IM process as proposed has resulted from the existing practices
and is modified by results from literature and interviews. Using the approach in a real project could
determine the exact benefits and limitations of this approach.
Research into the amount and type of contracts used in infrastructure projects
The amount and type of contracts, play a major role in the complexity of the project. Different
objectives and interests of the involved parties impede the coordination and communication with
each other. Further research could be conducted in optimizing the type, amount and content of
contracts used in a particular project.
Research into technical tools to implement a systematic approach for Interface Management
Technical tools and software provide a lot of possibilities for further research. A tool could be
developed to implement the IM process and include automated processes. Further research is also
possible in Building Information Modeling (BIM) tools which could design the project in 3D, and
identify potential clashes in advance.
100
Ballast Nedam
References
Admiari, A.R. (2010). A study of configuration management implementation in the construction industry.
Center for Advanced Infrastructure and Transportation, Rutgers University.
Al-Hammad, A. and Al-Hammad I. (1996). Interface Problems between Building Owners and Designers.
Journal of Performance of Constructed Facilities, ASCE, 10(3), 123-126.
Al-Hammad, A. (2000). Common Interface Problems among Various Construction Parties. Journal of
Performance of Constructed Facilities, ASCE, 14(2), 71-74.
Al-Hammad, A. and Assaf, S. (1992). Design-construction interface problems in Saudi Arabia. Building
Research and Information, 20(1), p.60-63.
Alarcn, L.F. and Mardones, D.A. (1998). Improving the Design-Construction Interface. Proceedings of the 6th
Annual Conference of the International Group for Lean Construction, Guaruja, Brazil.
Anumba, C.J., Kamara, J.M. and Cutting-Decelle, A.F. (2007). Concurrent Engineering in Construction. Taylor &
Francis, Abingdon, UK
Austin, S., Baldwin, A. & Newton, A. (1996) A Data Flow Model to Plan and Manage the Building Design
Process. Journal of Engineering Design Vol. 7. No. 1 pp 3-25
Austin, S., Baldwin, A., Li, B. and Waskett, P. (1999). Analytical Design Planning Technique for Programming
Building Design. Structures and Buildings: Proceedings of the Institution of Civil Engineers, Thomas Telford Ltd,
London, 134(2), 111-118.
Austin, S., Baldwin, A., Li, B. and Waskett, P. (2000). Application of the Analytical Design Planning Technique to
Construction Project Management. Department of Civil and Building Engineering, Loughborough University, UK.
BAM .(2008). SE-Wijzer, Handleiding Systems Engineering voor BAM infra. Koninklijke BAM Groep nv.
Ballard, G. (1999). "Can Pull Techniques Be Used In Design?" Proceedings of the Conference on Concurrent
Engineering in Construction, Espoo, Finland, August 1999.
Ballard, G. (2000). Positive vs Negative iteration in design. Proc. Eighth Annual Conference of the
International Group for Lean Construction (IGLC-8), 17-19 July, Brighton, U.K.
Biesboer, F. (2010). Het Dossier Tunnels, Oponthoud door technische installaties. De Ingenieur, 17 December
2010, p.20-31.
Bogus, S., Diekmann, J.E., and Molenaar, K.R. (2002). Methodology to Reconfigure the Design-Construction
Interface for Fast-Track Projects. Computing in Civil Engineering: Proceedings of the International Workshop on
Information Technology in Civil Engineering, Washington D.C.
Bogus, S., Molenaar, K., Diekmann, J. (2006). Strategies for overlapping dependent activities. Construction
Management and Economics. p. 829837.
Browning, T.R. (1998). Use of Dependency Structure Matrices for Product Development Cycle Time
Reduction. Proceedings of the Fifth ISPE International Conference on Concurrent Engineering: Research and
Applications. Tokyo, Japan.
101
Ballast Nedam
Browning, T.R. (2001). Applying the Design Structure Matrix to System Decomposition and Integration
Problems: A Review and New Directions. IEEE Transactions on Engineering Management, Vol. 48, No. 3,
August 2001
Browning, T.R., Fricke, E. and Negele, H. (2006). Key Concepts in Modeling Product
Development Processes, Systems Engineering, Vol. 9, No. 2, pp. 104-128, 2006.
Chen, C., Ling, S., Chen, W. (2003). Project scheduling for collaborative product
development using DSM. International Journal of Project Management. p. 291299
Chen, Q. (2007). An Object Model Framework for Interface Management in Building Information Models. PhD
Thesis, Faculty of the Virginia Polytechnic Institute and State University, Blacksburg, Virginia
Chen, Q., Reichard, G. and Beliveau, Y. (2007). Interface ManagementA Facilitator of Lean Construction and
Agile Project Management. Proceedings IGLC-15, Michigan, USA.
Chua, D.K.H., Tyagi, A., Ling, S. and Bok, S.H. (2003). Process-Parameter-Interface Model for Lean Design
Management. Journal of Construction Engineering and Management, 2003.
Choo, H.J., Hammond, J., Tommelein, I.D., Austin, S.A., Ballard, G. (2004). DePlan: a tool for integrated design
management. Automation in Construction. Vol. 13, (2004), p. 313 326.
Couwenberg, F. (2011). Raakvlakmanagement, Database helpt bij afstemming deelcontracten in groot
project. IPMA Projectie Magazine, 04-2011, p. 6-11
Coreworx (2014). Retrived from:
< http://www.coreworx.com/coreworx-products/interface-management/>
DAmelio, V. (2010). Design Interference Detection for Multi-Disciplinary Product Development. PhD
Thesis, Technical University of Delft, Netherlands
De Witt, S., Yakowenko, G., Bohuslav, T., Ferguson, T., Hoelker, E., Molenaar, K., Schiess, G., Smythe, J., Triplett,
J., Wagman, R. (2005). Construction Management Practices In Canada and Europe. U.S. Department of
Transportation, Federal Highway Administration
Doorewaard, Hans and Verschuren, Piet. (2007). Het onderwerpen van een onderzoek. Den Haag : Boom
Lemma uitgevers, 2007.
Doornbos, H. (2005). Integraal ontwerpen in de GWW sector. PhD Thesis, University of Utrecht, Netherlands
DSM community. (2013). DSM. Retrived from:
<http://www.dsmweb.org>
Eppinger, S.D., Whitney, D.E., Smith, R.P. & Gebala, D.A. (1994) A Model-Based Method for Organising Tasks in
Product Development. Research in Engineering Design. Vol. 6, No. 1, pp 1-13.
Eppinger, S.D. (1997). A Planning Method for Integration of Large-Scale Engineering Systens. International
conference on Engineering design ICED 97, Tampere, Finland.
Eppinger, D. and Browning, T.R. (2002). Modeling Impacts of Process Architecture on Cost and Schedule Risk in
102
Ballast Nedam
103
Ballast Nedam
104
Ballast Nedam
105
Ballast Nedam
Specialist Engineering Alliance. (2009). Sustainable buildings need integrated team. Eclipse Research
Consultants. Retrived from:
<http://www.secgroup.org.uk/pdfs/2011/SEABrochure2011.pdf>
Stevens, R., Brook, P., Jackson. (1998). System Engineering: Coping with Complexity. Prentice Hall Europe,
ISBN 0-13-095085.
Suddle, S. (2004). Physical Safety in Multiple Use of Space. PhD Thesis, Delft University of Technology
Tayeh, A. (2009). The Relationship Between Contractors and Their Subcontractors in The Gaza Strip. Master
Thesis, The Islamic University of Gaza-Palestine
Tomiyama, T., Meijer, B.R. (2005). Directions of next generation product development. ElMaraghy HA,
ElMaraghy WH, Advances in design. Springer, London, pp 27-35.
Tristl, C., Karche, A., Klenk, H., Haubach-Lippmann, C. (2012). Towards a Framework for Synchronization of
Systems- and Mechanical/Electrical Engineering processes on multiple dimensions. Concurrent Engineering
Approaches for Sustainable Product Development in a Multi-Disciplinary Environment, Springer-Verlag London
2013, pp. 1021-1032
Tuholski and Tommelein. (2010). Design Structure Matrix Implementation on a Seismic Retrofit. ASCE Journal
of Management in Engineering, 26(3), 144-152.
Ulrich, K. and Eppinger, S.D. (1995). Product Design and Development. McGraw-Hill, New York, NY.
Van Klink, L.J.W., Gerder, E.J., Kandel, H.E. Kemper, A.D. and van der Does de Bye, M.R. (2010). Leren van de
Betuweroute, eindevaluatie aanlegfase Betuweroute in het kader van de regeling grote projecten.
Uitgevoerd door Rebel Group Advisory bv in opdracht van het Ministerie van Verkeer en Waterstaat.
Van Ruijven, L. (2007). Kostenbesparing door Systems Engineering bij project Sluiskiltunnel, Lessons
Learned. Retrived from:
<http://www.crow.nl/Downloads/specificeren_system/Kostenbesparing_door_SE_bij_project_
Sluiskiltunnel[1].pdf>
Varghese, K. and Senthilkumar, V. (2008). Analysis of workflow on design projects in India. Proceedings of
presentation in Joint Conference & Workshop Design Management in the Architectural Engineering
and Construction Sector, University of So Paulo, Brazil, 4-8 November 2008.
Varghese, K. and Senthilkumar, V. (2009). Structured Methodology to Formulate Drawing Dependency
Structure Matrix for Construction Design. Architectural Engineering and Design Management, 5:4, p. 225-248
Varghese, K. and Senthilkumar, V. (2010). Workflow and Organizational Structuring of Design Projects:
Analysis of two Case Studies in India. Gesto & Tecnologia de Projetos, Vol. 5, No. 3, November 2010, p.85-103
Varghese, K., Senthilkumar, V. and Chandran, A. (2010). A web-based system for design interface management
of construction projects. Automation in Construction, p. 197212
Varghese, K. and Senthilkumar, V. (2012). A case study based testing of design interface management system
(DiMs). Journal of Management in Engineering, August 6, 2012
106
Ballast Nedam
107
Ballast Nedam
Appendices
Table of contents
Appendix A
Appendix B
Appendix C
Appendix D
Appendix E
Appendix F
Appendix G
Ballast Nedam
2014
Appendix A
Examples of Interface Control Forms used at different organizations.
Ballast Nedam
2014
Appendix B
Part of the interface matrix as used at the Johan Frisosluis in Stavoren.
Ballast Nedam
Appendix C
System Breakdown Structure (SBS) of the Johan Frisosluis in Stavoren:
Ballast Nedam
Appendix D
Table 1: Verification of the factors causing integration issues with findings from literature.
Case Study
The engineering disciplines possess specific
knowledge and speak their own language, leading to
misunderstandings.
Literature
Various project teams and disciplines are often
unaware of how their activities affect the delivery or
operation of other project teams, leading to poorly
defined interfaces between different scopes of work
(Nooteboom, 2004).
Insufficient and inaccurate interface information, as
well as inefficiencies in information sharing (AlHammad and Al-Hammad, 1996; Al-Hammad, 2000;
Miles and Ballard, 2001); poor communication
(Fritschi, 2002); poor information flow (Varghese and
Senthilkumar, 2010); unsatisfactory information
(Fritschi, 2002); uncertainty (missing or unstable
information) (Anumba, et al. 2007).
Lack of coordination among specialties (Josephson, et
al. 1996; larcn and Mardones, 1998).
Ballast Nedam
2014
Ballast Nedam
2014
Appendix E
In this Appendix is shown how all registers and forms related to the interfaces are displayed in Relatics, including a description of its intended use.
Interface Register
Interface Register
ID
Title
Description
Type
Status
Object
ID
Objects
Involved
contractors
Interface
Agreement ID
Req. ID
Resp.
Risk
Each contractor should have access to the main IR in Relatics, which looks like the figure above. In here all inter-disciplinary interfaces within the project are displaced. Next
to this register, also a separate IR could be placed in Relatics for each contractor, containing their intra-disciplinary and external interfaces. These interfaces are only
accessible for the contractor involved, which means each party has access to two IRs. One main register for the cross contractual interfaces and one for the internal
interfaces.
In the registers, it should be made possible to filter the interfaces by all aspects (e.g. title, type, status, risk, etc.). By including these filters will it be much easier to look and
find specific interfaces, like for instance the interfaces with a high risk factor.
Interface Breakdown Structure
All identified interfaces will also be placed in an IBS. In here all main interfaces identified between the contracts will serve as interface categories, like for instance cable
and pipes. In these categories all interfaces between the components related to that category are placed. In this way it will become much easier to look up all interfaces
belonging to a certain category.
Additional Interface details
By clicking on the ID-number of an interface all interface related information will be revealed. For a template of this sheet, see Appendix E. In here the following information
is obtained:
Ballast Nedam
Interface ID:
Interface title:
Interface description:
Type of interface:
Status:
Requirement:
Leading and intersecting objects:
Interface agreements:
Action items:
Related activities:
High risks:
Verification plan:
Further documents:
Interface agreements
For each interface, one or more IAs are developed. A template of that form is given in Appendix E. In each IA the following information is obtained:
Interface Agreement ID:
Attached interface:
Attached objects:
Requester:
Responder:
Required information or deliverable(s):
Responding document(s):
Action items IDs:
Need date of the agreement:
Verification of the deliverables:
Finish date :
ID-number IA
Interface title and ID
Involved objects titles and IDs
Requesting party
Responding party
Description of the interface information or deliverables
Document title and ID
ID-number, Description, Roles, Due dates, Status
Due date
Status
Date when the interface conditions have been met
Ballast Nedam
Requester
Responder
Interface ID
Object
ID
Objects
Due Date
Status
Open, In progress,
Verification, Closed
Description
Person
Due Date
Status
Open, In progress,
Verification, Closed
SBS objects
Clicking on an object in Relatics will reveal all specifications.
Ballast Nedam
WBS activities
Clicking on an object in Relatics will reveal all relations of that activity.
Verificationmatrix
The verification matrix in Relatics verifies the requirements in the project for all objects. However, the verification matrix should also include the interfaces instead of just
the requirements. In this matrix an interface could be stated as verified, and the related document(s) could be attached.
10
Ballast Nedam
Appendix F
When clicking on the interface ID-number, a specification sheet will appear with all relevant information.
Interface Specification
interface title
General information
ID-number
Title
Description
Type of interface
Status
Req. ID
ID-number
Req. description
Short description
Interface Agreements
IA Title
Title
IA ID
ID-number
IA desription
Short description
Requester
Contractor
Action Items
AI Title
Title
AI ID
ID-number
AI desription
Short description
Person
Responsible person
Attached risk
Risk Title
Title
11
Risk-ID
ID-number
Technical University of Delft
Responder
Contractor
Description
Short description
Ballast Nedam
Due date
Date
Status
Open/Closed
Due date
Date
Status
Open/Closed
Verification plan
Document title
Title
Document-ID
ID-number
Related activities
Activity ID
Activity out of the WBS
Further documents
Document title
Title
Document-ID
ID-number
Status
Open/in progress/approved
Role
Responsible role
Name
Responsible person
Status
open/in progress/closed
Role
Responsible role
Person
Responsible person
Document description
Short description
Additional comments
Additional comments
12
Ballast Nedam
ID number of the IA
IA title (e.g. Lockhead-Gate_IA_1.0)
Attached interface
Interface title
Interface ID-number
Attached Objects
Object 1 title
Object 2 title
Object 1 ID-number
Object 2 ID-number
Requester
Requesting party
Responder
Responding party
Responding document(s)
Document title
Title
Document ID
ID-number
Additional comments
Additional comments
Action Items
AI Title
AI title 1
AI title 2
AI ID-number
ID-number
ID-number
AI desription
Person
Short description Responsible person
Short description Responsible person
Verified
By 'name person'
By 'name person'
ID-number
Date
By 'name person'
AI title n
13
Ballast Nedam
Open/Closed
Verified Yes/No
Verification date
Name of responder which verified the deliverables
Extra comments
Extra comments
Extra comments
Signatures
Requester
Agree with the content of the IA
Closure of the IA
Date
Signature
Name
Date
Signature
Name
14
Ballast Nedam
Responder
Appendix G
Much of the research mentioned in chapter 4 proposes restructuring of the design process, based on the
dependencies between the project elements. The DSM is mentioned several times as part of their
methodology. In this appendix the ADePT methodology proposed by Austin et al. (1999), the DIMs
methodology proposed by Varghese and Senthilkumar (2008) and the Process-Parameter-Interface (PPI) model
of Chua et al. (2003) are evaluated, as well as the DSM methodology included in here.
DSM Methodology
A fundamental activity in project design, is the planning and control of work. In current construction industry
practice, design is planned by the same techniques as site construction, including network analysis (Austin, et
al. 2000). However, network analysis techniques and tools were designed to represent sequential processes
and cannot easily account for a process containing iteration, such as design (Austin, et al. 1996). This results in
the unwanted exclusion of information links between activities. In construction design, this problem is
particularly prevalent when considering information exchanged between design disciplines, because of the
disparate manner in which they undertake their work and its planning. Steward (1965) developed a theory that
a complex problem such as design could be solved more efficiently by representing the interrelationships
between activities in the form of a matrix (Austin, et al. 2000).
Design Structure Matrix (DSM)
The Design Structure Matrix (DSM), developed by Steward (1981), is an N-chart diagram used to capture
interactions and dependencies between teams, functions and activities (Browning et al, 2006). It has been
proved that the DSM method drastically reduces the design process time of multi disciplinary projects that
involves much iteration (Eppinger, et al. 1994). DSM provides a simple compact and visual representation of a
complex system that facilitates novel solutions to decomposition and integration problems (Browning, 2001).
The design structure matrix (DSM) is a matrix representation of a system, which shows the dependencies
between the elements of that system. System elements are listed in the first row and the first column of the
matrix and off-diagonal cells indicate the interactions or information flow between the system elements. There
are two main categories of DSM which are static and time-based, see figure 1.
15
Ballast Nedam
2014
Static DSMs represent existing system elements simultaneously, such as components of a product architecture
or groups in an organization. In time-based DSMs, the ordering of the rows and columns indicates a flow
through time. In here upstream elements of a process precede downstream elements, and terms like
feedforward and feedback become meaningful when referring to interfaces. Out of these two categories,
four main types of DSMs can be distinguished as can be seen in table 1.
Table 1: DSM data types (DSM Community, 2013)
Representation
Applications
Component-based
(Product)
Component
relationships
People-based
(Organization)
Organizational
relationships
unit
Activity-based
(Process)
Activity input/output
relationships
Parameter-based
(Low-level Process)
Design
parameter
relationships
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).
The DSM can be used to find the optimal sequence of activities and provide an overview of all dependencies in
the project. Partitioning and tearing are two operations used for this purpose. Partitioning is the process of
reordering the DSM rows and columns which will maximize the availability of information required, and
minimize the amount of iteration and the size of any iterative loops within the process. Tearing is the process
of choosing the set of feedback marks that if removed from the matrix are called tears. The information
16
Ballast Nedam
required for these feedback marks will in that cased be determined based on assumptions (Varghese and
Senthilkumar, 2010).
Figure 3: DSM overview: (a) Spaghetti Graph; (b) Base DSM; (c) Partitioned DSM (Yassine and Braha, 2003).
Figure 3 gives an example of a partitioned DSM in order to reduce iteration in a sequential design process.
Looking at the figure it can be seen that task D needs information from task L. When task L is executed after
task B, it could happen that because of the information released by L, task B has to change. This change in task
B could on their turn lead to many more tasks that has to be re-done. In figure 3(c) the partitioned DSM can be
found. If the design tasks are executed in this sequence, less iteration is necessary and smaller feedback loops
will occur. As can be seen, only the coupled boxes, which are the interdependent tasks, require iteration.
In order to break down the iteration process even more, the marks which are placed above the diagonal should
tried to be teared. By making assumptions that can be done with some confidence the iteration within the
shaded areas can be reduced.
Evolution of DSM
Rogers and Padula (1989) at the NASA Langley Research Centre have demonstrated how the DSM could be
applied to the scheduling of problems with up to 50 activities at the conceptual phase of the design process.
Eppinger and core searchers at MIT have applied DSM to a number of engineering problems involving up to 100
activities, including the processes of semiconductor design for Intel Corporation (Eppinger, et al. 1994), an
automotive brake system and engine design for General Motors (McCord & Eppinger 1993), and the design
process of a climate control system for the Ford Motor Company (Pimmler & Eppinger 1995).
Interest shown in DSM in construction has been largely limited to academia. Although the theory of DSM has
been applied in a number of circumstances, analyses are only just now being undertaken in practice. The
applicability of the DSM methodology in construction design has been tested by the Indian institute of
technology (Varghese and Senthilkumar, 2008) and Loughborough University (Austin et al., 1999). However,
limited research has been done in construction industry compared to other industries.
Koskela et al. (1997) indicates that while the initial results of DSM methods are promising, that this method is
still in research phase. Only after sufficient testing and launching of commercial software can this systematic
tool for finding the optimal sequence in design be implemented in practice. According to Koskela et al. (1997)
the principle of optimizing the sequence can also be approached informally. If the projects type is familiar, the
designers will have a good feel about the optimal sequence of tasks. In design meetings, designers actively
present their input information needs regarding other designers, and the order of main design decisions is thus
agreed on.
17
Ballast Nedam
ADePT Methodology
Austin, et al. (1999) conclude that current building design planning practice gives little consideration to the
interdisciplinary, iterative nature of the process. Under this circumstance, the ADePT (Analytical Design
Planning Technique) is proposed. This project planning methodology helps to overcome these problems by
providing a logical, structured approach, based on information flow rather than the production of design
deliverables. It takes account of the iterative nature of design and can enable fully coordinated, integrated
design solutions to be developed within both budgetary and time constraints.
The first stage of the methodology is a model of the building design process, representing design activities and
their information requirements. IDEF0v is proposed as the most suitable modeling technique for construction
design in where all information requirements for a design activity can be presented.
The design process model (DPM) has a hierarchical structure, the first level of which sub-divides the process
into design undertaken by the professional disciplines: architecture, civil engineering, structural engineering,
mechanical engineering, and electrical engineering. There are different characteristics for each discipline
because of variations in the way they work. The DPM aims to describe the process at a non-specific level and
consequently it represents the design of a typical building and its systems.
For building design this means a basic model is developed at a non-specific level and consequently it represents
the design of a typical building and its systems. The project planning of a particular building will entail some
manipulation of the model to produce a project-specific process map.
The four engineering processes are partitioned into systems design. The design of the ground floor slab and
systems beneath it are civil engineering activities, while the design of above ground systems are represented
within the structural engineering model. The mechanical engineering section systems are decomposed further
into Requirements and Load Analysis, Schematic Design, Plant Layout Design and System Specifications
which are in turn broken down into individual design tasks. The electrical engineering section is represented in
terms of groups of systems such as Lighting Systems Design and Communications Systems Design before
being decomposed further into systems such as General Lighting Design and Emergency Lighting Design and
then into individual design tasks.
18
Ballast Nedam
The data in this model is linked via a dependency table to a Dependency Structure Matrix (DSM) analysis tool,
which is used in the second stage, to identify iteration within the design process and schedule the activities
with the objective of optimizing the task order.
There are many information dependencies between activities in complex problems such as construction design,
which can be clarified by accounting for different levels of information importance (strengths of dependency).
This can be done by classifying the dependencies within the matrix and using a partitioning algorithm that can
prioritize the sequencing of activities accordingly.
The classification of information within a matrix is a subjective exercise. Austin et al. (1996) described a three
point scale of classifications, used in ADePT, which is based on the strength of dependency of information,
sensitivity of activities to changes in information, and the ease with which information can be estimated within
the building design process, see figure 5.
Figure 5: The basis for allocating information classifications (Austin, et al. 1996).
To determine each information classification, three separate subjective judgments must be made and the
resulting classification is given a rating of either A, B or C (A being strong and C being weak). The philosophy
adopted by ADePT is that weak dependencies can be omitted from the matrix partitioning (because an
accurate estimate can easily be made), and therefore the size of iterative loops can be reduced and the design
process clarified.
The third stage of the methodology produces design programmes based on the optimized process sequence.
Finally, the fourth stage is where the design process is monitored and the flow of work is controlled. The
technique requires some iteration between the DSM and programming stages.
The detailed DPM and DSM tool offer an effective means of scheduling a design process based on the flow of
information through a project, rather than on the production of deliverables. The matrix indicates groups of
tasks that are interdependent and therefore require careful co-ordination. A project management program can
show the optimal design sequence (as determined by the matrix analysis tool) in the form of design
19
Ballast Nedam
programmes. These programmes highlight the iterative task groups identified by the matrix and ensure that
they are scheduled to take place in parallel, thereby reducing the likelihood and scale of redesign and
associated construction problems.
Practical implementation of ADePT
The most significant challenge lies in defining tactics to manage the design team as they work concurrently on
an interdependent design problem. There is no single solution as the number of activities and deliverables,
number of team members involved, and time required to develop the design will dictate the approaches used.
What is important is that each of these issues is thought about in turn and that an appropriate approach is put
in place.
The third stage of the methodology produces design programmes based on the optimized process sequence.
This process raises a number of issues. Conventional programming tools represent sequential processes and do
not allow elements of work containing iteration to be programmed. Thus, in current practice, feedback is not
identified, resulting in co-ordination failures and rework. With ADePT, the DSM analysis is used with a project
management tool, in order to demonstrate that these dependencies could be integrated with existing
construction planning systems, and a form of representation familiar to design planners and managers can be
used. This is done by grouping tasks that form a loop under a rolled up activity and removing
interrelationships from within the loop so that they can be programmed to occur in parallel. However,
establishing the effects of tearing an information dependency can prove difficult when a loop consists of a large
number of tasks and interrelationships.
In current practice, design is largely programmed to release information to suit the construction stage. The
proposed approach is fundamentally different in first producing an optimal programme to suit design, which is
then modified as it is integrated with a procurement and construction programme. In practice, it is unlikely that
the optimal sequence of design tasks will be realistic because of the production constraints put on the process
by the need to deliver a project in a short a time-scale as possible. However, comparison with a view of the
ideal construction sequence should provide a good starting point to integrate design within the wider project
process.
Evaluation of ADePT methodology
All stages of ADePT have been validated by Austin et al. (2000) though their application to a series of building
projects under construction. The design process model has been validated by producing project-specific
models and a broad range of design work has been embraced. The first task in formulating each project-specific
model is to ensure that the Desgin Process Model has an appropriate content and structure. This requires the
deletion of design activities from the generic model that are not relevant to the project, and the addition of
tasks associated with features of the building not already included.
The output from the DSM tools and corresponding design programmes have been compared with the planning
that was undertaken in practice. This has shown that the programmes used in practice did not take full account
of the iteration within the design process, and that the design had been planned almost entirely to suit the
construction process. Advantages of the ADePT methodology mentioned are among others (Newton, et al.
2007):
20
Ballast Nedam
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.
Compare the interfaces in a physical sense by providing an environment where each designer can
actively compare their work against all other current designs.
Identify the existence of design clashes.
Report and resolve in an organized matter.
A good communication mechanism is required in order to minimize the delays and impact due to design
changes. This mechanism should ensure that all design changes are identified, reviewed, approved and
communicated to all affected parties and functions. The change management processes will be reviewed as
part of the interface management processes.
21
Ballast Nedam
22
Ballast Nedam
designers time to identify the appropriate matrix elements (activities) and foresee its interfaces (Helgerson, et
al. 2009).
The DIMS methodology proposes to capture the design interfaces at drawing level through formulating a
Drawing DSM (DDSM). As drawings are well defined entities, it was found that, capturing the interfaces at
drawing level can eliminate the ambiguity of selecting the appropriate abstraction level. In addition, a
structured decomposition procedure was also proposed to identify the design interfaces among the drawings
and transform these dependencies to identify relationships between other design entities. The workflow of the
decomposition procedure was automated using a server-based tool. As a result, it facilitated the participation
of all members of the design team (Senthilkumar, et al., 2010).
However, one of the key challenges in basing design management on a DDSM is that the designers cannot
identify the information dependencies between the drawings directly, as the relationships between drawings
are numerous and are not apparent at the initial design stage and at higher levels of abstraction. Further, the
DDSM is dynamic and will continue to evolve as detailed design progresses.
In order to formulate the DDSM, the following fundamental (conceptual) steps are proposed.
23
Ballast Nedam
Entity - Identification
Figure 8 shows a systematic decomposition framework used to identify entities for a generic project. Of the
entities, drawings and parameters entities (shaded) cannot be comprehensively identified at the initial stages
of the design and will evolve as the design progresses.
24
Ballast Nedam
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.
The system generates the Design Interface Matrix (DIM) structure automatically from the PIM. During the
second session of the workshop, the design interfaces were captured by each team. This workshop facilitates
25
Ballast Nedam
the interface identification process as the participants from all the teams were present in the common working
forum (workshop). The physical interfaces forms the basis for the designers to identify the design interfaces.
Figure 10 shows the generated DIM for main component 1.
Figure 10: Design Interface Matrix (DIM) of main component 1 (Senthilkumar and Varghese, 2009).
The shaded area represent the teams involved in the design. The DIM rows have two sections, the shaded
section represents the teams involved and the bottom section represents the subcomponents that have a
physical interface with main component 1, as identified in the PIM. The team versus subcomponent interfaces
are helpful in order to identify team versus team interfaces, since it is easier to identify the design interfaces if
the designer is focused on specific subcomponents.
The corresponding interfacing teams were notified by a system generated email as and when an issue is
generated. In response to the email, a response forms has to be filled in. These responses are updated in the
Design Interface Agreement (DIA) accordingly in the systems database. The DIA requires the documentation of
specific interface issues, the teams involved, the interface agreement reached and the status of that
agreement. The DIM is updated with colored symbols based on its status. The priority interfaces, identified
based on construction schedule, are notified with the red blink to assist the designers in resolving the issues.
Though the users interact through web, weekly interface meeting interactions were required especially when
an interface issue required collaboration among two or more teams. Further, the priority issues were also
26
Ballast Nedam
resolved during these meetings to meet the construction schedule. Hence, the weekly interface meeting was
mandatory. The interface discussions in these meetings are facilitated with the system generated report by
each team. Each team has two types of issues which are issues which need to be resolved by others, and issues
which need to be resolved within the own team. Further, the above two categories are grouped in priority
issues and non priority issues. The categorized report can be generated by the system.
Interface Management
Finally, each design team mapped the generated issues as input/output of their drawings. The system
generated the DDSM using the issues-drawings relationships established, as is shown in figure 11. This
approach of mapping the interface issues as input/output reduces the effort required in identifying the drawing
dependencies, compared to conventional DSM methodologies. The DSM captures the design interfaces
between the drawings, and strives for an optimal drawing release sequences.
27
Ballast Nedam
module were identified, and were listed as rows and columns headings to develop the drawing DSM. After the
DDSM was formulated, the design experts from all the involved disciplines were invited for capturing the
interfaces of the drawings.
Since the airport consists of large number of components and design drawings, the DSM methodology of
capturing the drawing interfaces cannot be done manually. The interface capture process during the design
interface meetings and the workshops was difficult, because of the large size of the matrix (100x100). The
designers were finding difficulties in managing the size of the matrix. Therefore, it was decided to decompose
the project into manageable levels of sub-components and the DSM is developed for each of these subcomponents, but the inter-component interfaces were not addressed in the above methodology (Senthilkumar
and Varghese, 2008).
The difficulty of the DSM methodology implementation in construction lies with the decomposition of the
project design process, and the size of the DSM matrix. It seems that the number of elements (drawings)
involved in the construction design process is more compared to the manufacturing, software and product
development (Varghese and Senthilkumar, 2008).
Furthermore, though the system can determine the sequence of drawing release as a part of the DSM
process, the designers were averse to use this because of the sequence was pre-determined by construction
requirements. The construction requirements were pulling the design sequence.
However, the results of working with the DIMS methodology is promising. The effectiveness of design interface
management was assessed through the quantifiable criteria such as the number of revisions, the delay in first
submission, the number of site rework and design productivity. Results from a case studies showed a positive
results in all of these fields. The drawing revisions, for instance, were lowered by 1/3 compared to the test case
(Varghese and Senthilkumar, 2012).
The designers were of the opinion that the DIMS methodology provided a forum to make collaborative
decisions during the design process, especially during the workshop for developing the PIM and DIM.
The designers were of the opinion that the discussions during the workshops had pro-actively matched the
teams which required close interaction for the exchange of information.
Moreover, the workshops resulted an increase in awareness of the specific information interdependencies. Assumption were made after appropriate discussions among the respective designers, which
resulted in a reduction of rework and revisions. Besides, also a reduction in site rework was recognized in the
case study. The collaborative information sharing among the design participants was acknowledged as a key
driver for the production of error free Good for Construction drawings (Varghese and Senthilkumar, 2012).
The web-based tool established the communication templates, reduced the communication lead time, kept
track of commitments and documented the communications. Together with the alert mechanism of the DIMS
tool, which periodically notified specific individuals about their information requirements to meet the
approaching deadlines, these aspects had a significant role in eliminating delay (Varghese and Senthilkumar,
2012).
28
Ballast Nedam
29
Ballast Nedam
Process-Parapmeter-Interface Model
Figure 12: Process-Parameter-Interface (PPI) Model for lean design management (Chua, et al. 2003).
Design iterations and rework form a major part of non-value adding activities in the AEC design processes.
These design reworks can be avoided by active collaboration among the design specialists over key design
parameters. This is facilitated by the PPI model engine, which generates a sequence, optimized with respect
to the number and length of rework loops. Besides, the engine also prompts the appropriate design specialists
at appropriate times for the design parameters that they need to produce. The model comprises a design
dictionary, which imparts transparency. Transparency is further facilitated by means of Interfaces. Process
simplification is achieved through the use of the design dictionary while output flexibility is increased by
frequent proactive collaboration among the design specialists facilitated by the model engine.
The design dictionary described the key parameters and includes aspects as estimability, volatility and owner.
The rate of estimability describes how well a parameter can be assumed or estimated, in case the parameter
value is unavailable. The volatility indicates the degree of potential change of the design parameter due to an
external environment or other agencies. The owner refers to the design specialist who owns a particular
parameter. By owning a parameter, the specialists has the freezing command over it.
The parameters collected are attached to design tasks in the Information Requirement Matrix (IRM) and the
Information Production matrix (IPM). In the IRM the design disciplines place the parameters required for
specific design tasks, while in the IPM the same designers indicate what parameters will be produced as output
of those design tasks.
30
Ballast Nedam
The PPI Model Engine as indicated in figure 12 generates a sequence, in which the key design parameters
involved in the design process, must be produced. This sequence is such that the rework loops are minimized.
The methodology to sequence the design process is based on the DSM. In this DSM the parameters are placed
and their dependencies in order to see in what sequence the parameters should be determined.
Validation PPI Model
Unfortunately, no validation or implementation of the PPI model has been executed so far. Therefore it is not
as easy to evaluate the methodology. However, the parameter based DSM described by Pekta and Pultar
(2006) was tested on a suspended ceiling for a public building in Turkey. Data was collected through interviews
with designers, which was an iterative and time-consuming process. The biggest challenge of the proposed
parameter-based DSM approach is the large number of parameters involved in building design. The number of
parameters needed to fully determine the properties of a product depends on its complexity. Rouibah and
Caskey (2003) estimate that an automobile can be described by 105 - 106 parameters, while an aircraft or ship
may have more than 106 . A equal amount of parameters is to be expected for complex infrastructure projects
(Rouibah and Caskey, 2003).
It would be a quite time consuming task to write down all these parameters, of which many do not even cross
intra-disciplinary boundaries. As said are the most relevant interfaces those which cross contractual
boundaries. A careful selection to identify the most critical parameters could simplify the model. However, this
selection is already a quite time consuming process of itself, which requires the collaboration of all design
disciplines. Furthermore, developing an optimal design sequence cannot be determined by only the most
crucial parameters since these could be dependent on other, less crucial, parameters. If these relationships are
not captured, an proposed optimized schedule will have way less value.
31
Ballast Nedam