Yazan A b u a lfe ila t

Mapping Intertace
Management to Project
Management
Railway Project Case study

L Ạ M B E R T
A c a d e m ic P u b lis h in g
r 1

Yazan Abualteilat

Mapping lnterface Management to Project Management

 Yazan Abualíeilat

Mapping Interíace Management to

Project Management
Railway Project Case study

LAP LAMBERT Academic Publishing

Impressum /lm print (nur fũ r Deutschland/only fo r Germany)
Bibliograíische Intormation der Deutschen Nationalbibliothek: Die Deutsche
Nationalbibliothek verzeichnet diese Publikation in der Deutschen Nationalbibliograíie;
detaillierte bibliogratische Daten sind im Internet ùber http://dnb.d-nb.de abrutbar.
Alle in diesem Buch genannten Marken und Produktnamen unterliegen warenzeichen-,
marken- oder patentrechtlichem Schutz bzw. sind Warenzeichen oder eingetragene
Warenzeichen derjeweiligen Inhaber. Die Wiedergabe von Marken, Produktnamen,
Gebrauchsnamen, Handelsnamen, Warenbezeichnungen u.s.w. in diesem Werk berechtigt
auch ohne besondere Kennzeichnung nicht zu der Annahme, dass solche Namen im Sinne
der Warenzeichen- und Markenschutzgesetzgebung als frei zu betrachten vvăren und
daher von jedermann benutzt vverden dùríten.

Coverbild: www.ingimage.com

Verlag: LAP LAMBERT Academic Publishing GmbH & Co. KG

Heinrich-Bõckìng-Str. 6-8, 66121 Saarbrũcken, Deutschland
Teleton + 49 681 3720-310, Teletax +49 681 3720-3109
Email: info@lap-publishing.com

Approved by: Berlin, Hochschule íũrTechnik und Wírtschaft, 2011

Herstellung in Deutschland:
Schaltungsdienst Lange O.H.G., Berlin
Books on Demand GmbH, Norderstedt
Reha GmbH, Saarbrũcken
Amazon Distribution GmbH, Leipzig
ISBN: 978-3-8484-4772-5

lm print (only fo r USA, GB)

Bibliographic intormation published by the Deutsche Nationalbibliothek: The Deutsche
Nationalbibliothek lists this publication in the Deutsche Nationalbibliograĩie; detailed
bibliographic data are available in the Internet at http://dnb.d-nb.de.
Any brand names and product names mentioned in this book are subject to trademark,
brand or patent protection and are trademarks or registered trademarks of their respective
holders. The use of brand names, product names, common names, trade names, product
descriptions etc. even without a particular marking in this works is in no way to be
construed to mean that such names may be regarded as unrestricted in respect of
trademark and brand protection legislation and could thus be used by anyone.

Cover image: www.ingimage.com

Publisher: LAP LAMBERT Academic Publishing GmbH & Co. KG

Heinrich-Bõcking-Str. 6-8, 66121 Saarbrũcken, Germany
Phone +49 681 3720-310, Fax +49 681 3720-3109
Email: info@lap-publishing.com

Printed in the U.S.A.

Printed in the U.K. by (see last page)
ISBN: 978-3-8484-4772-5

Copyright © 2012 by the authorand LAP LAMBERT Academic Publishing GmbH & Co. KG
and licensors
All rights reserved. Saarbrũcken 2012
 Acknovvledgment

This research would not have been possible without help and support from many people. I wish
particularly to express my greatest gratitude to the following:

• My supervisor, Professor Dr. Christian Bõttger, for his invaluable advice, support, and for
the tlexibility he showed to me, and for the career support.

• Antti Kapanen, MBA&E program coordinator, who has been alvvays there, whenever he is
needed, and special thanks to him for encouraging me to overcome the time pressure
challenges.

• Deutsche Bahn International Makkah Metro Projectteam and particularly to Dr. Elahwiesy,
for the support, valuable input to thls thesis, the fruitful discussions, and for the access to
relevant documentation.

• My MBA&E dass mates for the wonderful time we had together in Berlin, for the
teamvvork environment they created, for their trìendly advices.

• My parents, for their support right from the beginning, for encouraging me to íurther
complete my graduate studies, and for their respect of all my decisions in life.

• Arab revolutionists, who inspired me by their continuous scariíies and perseverance to

earn theirtreedom backtrom dictators.

• My lovely wife Siba, for her patience, for her beliet in me, for her positive attitude. She
stood up behind me in every single decision, even if it was against her own interests. I am
indebted to my wife.

Yazan Abualíeilat
Berlin, May 2011.
 Abstract

More difficulties are facing the grovving number of railway projects in different parts of the world,

as well as, other big Capital investment projects. Organizations and researchers are searching for

methods to improve the períormance in terms of cost, time, and quality. One of the identiíied key

areas of improvement is interíace management.

The studies related to interíace management, deíined in literature as the management of

common boundaries between different entities, are still limited. A holistic view of interface
management is still not mature enough. Furthermore, the link between interíace management
(IM) and project management is still missing, leading to less effectiveness and efficiency of overall

projects' períormance.

This thesis tries to establish a clear link between IM and project management, by exploring various
common areas, such as the body of knowledge, and roles and responsibilities. Then it goes a step
turther by creating a complete Project Intertaces Management (PIM) Process, that includes six
sub-processes: 1) Plan Intertaces Management, 2) ldentify Interíaces, 3) Resolve Interíaces, 4)
Implement lnterfaces, 5) Validate lnterfaces, and 6) Monitor and Control lnterfaces.

This process is mainly characterized by two things, 1) it is built upon actual railvvay project
documentation prepared by leading organizations in the industry, and 2) inspired by the structure
of the PMBOK® Guide published by the Project Management Institute in 2008. These two
characteristics will enable this process first to communicate with project management processes
and to be íurther applied in the wider range of construction projects.

This thesis will add up to the IM body of knovvledge and is meant to be consìdered as a guide to IM

common practices.
 Contents

1 Introduction................................................................................................................................................ 1
1.1 Background...................... 1
1.2 Thesis Scope and Objectives................................................................................................. 1
1.3 Thesis Methodology.............................................................................................. 2
1.4 Thesis Organization.................................................................................................................. 3

2 Principles of Intertace Management..................................................................................................5

2.1 What is an Intertace?..................................................................................................... 5

2.2 What is Interíace Management?.....................................................................................................6
2.3 Objectives of Interíace Management............................................................................................ 7
2.4 Types of Interíaces.............................................................................................................. 8

3 Relationship betvveen Interíace Managementand Project Management................. 11

3.1 Body of Knowledge................................................................................................. 11

3.2 Factors Intluencỉng Intertace Management.............................................................................. 13
3.3 Project Lite Cycle........................................................................................................ 15
3.4 Processes Interactions..................................................................................................... 17
3.5 Roles and Responsibilities................................................................................................................ 18

4 Project Intertaces Management Process M odel......................................................................21

4.1 Plan Intertaces Management Process......................................................................................... 25

4.1.1 Plan Intertaces Management: Inputs................................................................................... 26
4.1.2 Plan Intertaces Management: Tools and Techniques...................................................27
4.1.3 Plan Intertaces Management: Outputs............................................................................... 29
4.2 Identity Interíaces Process.............................................................................................. 31
4.2.1 Identity Interíaces: Inputs....................................................................................................... 32
4.2.2 Identity Intertaces: Tools and Techniques........................................................................ 36
4.2.3 Identity Intertaces: Outputs............................................................................................... 38
4.3 Resolve Interíaces Process................................................................................................. 42
4.3.1 Resolve Intertaces: Inputs.................................................................................................... 44
4.3.2 Resolve Intertaces: Tools and Techniques........................................................................45
4.3.3 Resolve Interíaces: Outputs......................................................................................... 49
iii
 4.4 Implement lnterfaces Process.......................................................................................................50
4.4.1 Implement lnterfaces: Inputs................................................................................................51
4.4.2 Implement Interíaces: Tools and Techniques..................................................................52

4.4.3 Implement lnterfaces: Outputs............................................................................................53

4.5 Validate lnterfaces Process........................................................................................................... 54
4.5.1 Validate lnterfaces: Inputs......................................................................................................55
4.5.2 Validate Interíaces: Tools and Techniques.......................................................................56

4.5.3 Validate lnterfaces: Outputs.................................................................................................. 57

4.6 Monitor and Control Interíaces Process.................................................................................... 58
4.6.1 Monitor and Control lnterfaces: Inputs...............................................................................60
4 6.2 Monitor and Control Interíaces: Tools and Techniques................................................62
4.6.3 Monitor and Control lnterfaces: Outputs.........................................................................64

5 Conclusions and Recom m endations..............................................................................................67

5.1 Conclusions............................................................................................................................................. 67
CO
5.2 Recommendations..............................................................................................................................DO
5.2.1 Exploration of Interíaces Resolution Strategies.................................................................68
5.2.2 Surveying Interíace Management ...........................................................................................68

5.2.3 Development of IM Tools............................................................................................................ 88

Reterences............................................................................................................... 71
 Table of Figures

Figure 2-1 Interíace aspects/characteristics.................................................................................................. 9

Figure 3-1 Bodies of knowledge intersections............................................................................................12
Figure 3-2 lnterface issues multi-perspective cause and effect diagram........................................13
Figure 3-3 lnterface issues cause and effect diagram - project management perspective ....14
Figure 3-4 Sample metro project ]ife cyde.................................................................................................. 15
Figure 3-5 Interíace management within a typical metro project liíecyde - waterfall modell6
Figure 3-6 Cost of changes versus project time..........................................................................................17
Figure 3-7 Railway projects contracting typical model............................................................................18
Figure 3-S Interíace management roles and responsibilìties at a high-level.................................19
. Figure 4-1 PIM: a proposed new member of the PMBOKíamily of knowledge areas...............21
Figure 4-2 PIM process......................................................................................................................................... 22
Figure 4-3 PIM processes overvievv................................................................................................................ 23
Figure 4-4 PIM versus project phases - iterative model......................;.................................................24
Figure 4-5 Plan interỹaces Management process overview................................................................. 26
Figure 4-6 Plan lnterfaces Management data flow diagram................................................................ 26
Figure 4-7 Sample railway project interíaces dassitication...................................................................28
Figure 4-8 Interíace coding example..............................................................................................................29
Figure 4-9 Identi/y interỊaces process overview........................................................................................ 32
Figure 4-10 ldentify Interýaces data flow diagram.....................................................................................32
Figure 4-11 Example of railway System project W BS.............................................................................. 35
Figure 4-12 Example oF railway System PBS................................................................................................35
Figure 4-13 Sample interíace matrix of a railway System project......................................................37
Figure 4-14 Sample IDS .......................................................................................................................................40
Figure 4-15 Sample IR for a metro project.................................................................................................. 42
Figure 4-16 Resolve Interýaces process overview..................................................................................... 43
Figure 4-17 Resolve Interýaces data flow diagram.................................................................................... 43
Figure 4-18 Turnouts: typical railway projects' interíace.......................................................................46
Figure 4-19 Implement Interýaces process overview............................................................................... 51
Figure 4-20 Implement Interýaces data flow diagram.............................................................................51

Figure 4-21 lnterface Issues............................................................................................................................... 54

V
Figure 4-22 lnterface Issues............................................................................................................................... 54
Fìgure 4-23 Validate lnterfaces process overvievv.....................................................................................55
Figure 4-24 Valìdate Interýaces data flow diagram..................................................................................55
Figure 4-25 lnterface Issue.................................................................................................................................. 58
Figure 4-26 Interíace Issue..................................................................................................................................58
Figure 4-27 Monitor and Control Interýaces process overvievv........................................................... 59
Figure 4-28 Monitor and Control ínterỊaces data flow diagram.......................................................... 60

Figure 4-29 lnterface Issue.................................................................................................................................. 61

vi
111111111111111111111111 Abbreviations

ACS Access Control System

ATO Automatic Train Operation
ATP Automatic Train Protection
ATS Automatic Train Supervision
BBRS Broad Band Radio System
CIV Civil
cw Civil Works
CCTV Closed Circuit Television
COM, COMMS Communication System
DEP Depot
E&M Electrical & Mechanical
GC General Contractor
HMS Heavy Maintenance shed
HR Human Resources
ILMS Inspection and Light Malntenance Shed
IDS Interíace Data Sheet
IM lnterface Management
IRM Interíace Revievv Meeting
IR Interíaces Register
L&E Lifts and Escalators
MMS Maintenance Management System
MEP Mechanical, Electrical, and Plumping
occ Operation Control Centre
PDCA Plan, Do, Check, Act
PED, PSD Platíorm Edge Door, Platíorm Screen Doors
PSS Power Supply System
PBS Product Breakdovvn structure
PIM Project Intertaces Management
PMBOK Project Management Body of Knovvledge
PMI Project Management Institute
PM Project Manager
PAS Public Address System
PIS Public Iníormation System
R&R Roles and Responsibilities
RSK Rolling stock
SCA, SCADA SCADA, Supervisory Control and Data Acquisition System
SIG Signalling
T&c Testing & Commissioning
TRK Track
TPS Traction PovverSupply
WBS Work Breakdown Structure

vii
1 Introduction

1.1 Background

Many railvvay projects are in different phases in different parts of the vvorld. More countries
have realized lately the importance of such mass, high speed transit Systems to cope with
the megatrends such as the expansion of metropolitan areas, increase of people on the
move, and the decrease of natural resources, accompanied by increasing worldwide support
for environmental triendly Solutions.

These big capital-demanding, politically-initiated projects are undertaken mainly by big

European players, trying to copy what has been already accomplished decades ago in
Europe in other places of the world, such as the Middle East, America, and East Asia.

"Viele Projekte, viele Schwierigkeiten" (many projects, many difficulties) this is how Bõttger
and Wanner (2009) titled their article, in which they shed some light on railvvay projects
belng undertaken here and there tacing real challenges. In other industries the picture does
not seem to be brighter, the Standish Group (1995) famous chaos report indicates that
52.7% of projects will cost 189% of their original estimates.

The Project Management Institute (PMI), a globally recognized nonproíit organization, tried
since its establishment to build project management proíessionals capable of enhancing
projects' success rates. Recent researches showed slight improvement than what was
concluded by the Standish group research. Though, this is not enough, and something
seems to be still missing especially in those railway and high Capital investment projects.

Nooteboom (2004), 30 years of experience in the design and implementation of offshore oil
and gas subsea and íloating production Systems, States that “ Interíace Management (IM)
has been a missing link of project management for a long tĩme” . He turther condudes by
saying that "Interíace management has been a silent, hidden aspect of project management
for a long time, but it was not specitically named or grasped until the rise of mega projects,
many of which have suffered signiíicant losses".

In the literature of project management, interíace related studies are very limited. Interíace
management is still not covered appropriately in the project management text books,
although from what can be seen in railvvay projects, engineers are attributing many project
issues to poor interíace management by main contractors.

1.2 Thesis Scope and Objectives

This research intends to establish a link between interíace management and project
management through proposing an interíace management processes similar to what is

1
developed for other knovvledge areas like risk management, procurement management,
quality management within the context of the project management Standard authored by
PMI as a guide for project management best practices.

The background of this research will be the railway industry. Thereíore, many examples,
figures, and statements wi11 be derived from this industry. Railway projects is an
environment rich of ìnteríaces and suffering from poor interíace management.

This thesis has the following objectives:

1) To better understand interíace management in the context of railway projects

2) To revievv project management best practices outlined in project management
standards

3) To develop a complete interíace management process throughout the project life

cyde, using the same language of project management, and show some interlinks
between project management and interíace management.
4) To organize some of the scattered interíace related literature in a framework that
can communicate with project management framework
5) To contribute to what can be named in the future "lnterface Management Best
Practices"

1.3 Thesis Methodology

In order to achieve the thesis objectives listed above, a clear research methodology has to
be followed. The following characterizes the methodology of this thesis:

1) Involvement in an actual metro construction project, suffering from real intertace

management problems, located in the Middle East. The involvement is achieved by
taking part of the System Engineer/Consultant team. This involvement includes
attending technical and managerial meetings, visiting the project site, preparing
pertormance reports, managing project documentations, etc...
2) Review of corporate unpublished internal interíace management related documents
including but not limited to interíace matrices, registers, design documents.
3) Conducting face to face intervievvs with experts in intertace management, taking
different management and supervision roles.
4) Extensive literature revievv of interface management related studies from projects
perspective and Systems engineering perspective.

2
 5) Extensive review of "A Guide to the PMBOK", a project management Standard
published by the Project Management Institute (PMI).
6) Customizing project management tools and techniques to serve in interíace
management context.
7) Utilization of accumulated knowledge from years of experience in consultancy and
training in the field of project management.

1.4 Thesis Organization

The thesis is organized in the following six chapters

Chapter 1 Introduction: Describes the background of this thesis, clarifies the scope and
objectives of the thesis, then explains the main characteristics of the methodology followed
in this thesis, and íinally presents the organization of the thesis.

chapter 2 Principles of Interíace Management: The majority of this chapter is the outcome
of a literature revievv, in which definitions of interíace and interíace management are
presented. Interíace management objectives and different types of interíaces are also
highlighted.

Chapter 3 Relationship between Interíace Management and Project Management: This

chapter emphasizes the strong relationship betvveen IM and project management from
different perspectives; the body of knowledge, factors causing interíace issues, project life
cycle, processes intersections, and roles and responsibilities.

Chapter 4 Project Interíaces Management Process: This chapter includes the bulk of this
thesis and the major added value. In this chapter a complete interface management process
is proposed consisting of five main sub processes starting with Plan Interýaces Management
process and ending with Monitor and Control Interỷaces. This chapter was developed after a
careíul review of the PMBOK® Guide 2008, thereíore the language and the structure of this
part is very similar to chapters 4 to 12 in the guide. As mentioned in the objectives and the
methodology of this thesis, by doing so, integration betvveen project management and
interíace management can be easier. For each process in this chapter inputs, tools and
techniques, and outputs were specitied. The processes were also supported with examples
and íigures from the railway projects industry.

Chapter 5 Conclusions and Recommendations: Summarizes the thesis fìndings, while trying
to propose further studies in the same topic, to complete what has been started.

3
4
2 Principles of Interíace Management

2.1 What is an Interíace?

Different researchers have cited different "interíace" deíinitions; most of them derived their
definitions from a combination of dictionary and practice deíinitions. For example
Nooteboom (2004) deíined interíaces as "common boundaries between people, Systems,
equipment, or concepts". Chen (2007) included 4 deíinitions of interíaces in her dissertation
two of which she considered to be more widely used; the íirst is "A surtace or shared
boundary betvveen two tunctional units, detined by different characteristics such as
function, physical interconnection, spatial relationship and signal, or in other words, a
suríace torming a common boundary between adjacent regions, bodies, substances or
phases". The second deíinition is "A point or place at vvhich independent and often
unrelated Systems or diverse groups interact".

Going to project sites, and attending a couple of meetings, one will recognize very fast that
the word "interíace" is one of the most commonly used words in the daily discussions of a
typical railway or construction project. Thus, there must be at least a common unconscỉous
understanding of the meaning of an interíace, away from dictionaries and academics. A
direct question to any engineer will lead to the following understanding that an interíace ís
something once identified between two or more entities, Systems, persons, etc... it has to be
resolved and properly managed othervvise, undesirable results might occur sooner or later.
In this sense interíaces are seen as inevitable negative things that will most lĩkely bring
troubles with. This concept was pointed out by Lai (2005) "the contìicts among units that
need to be coordinated and resolved". The units are likely to be contractors, materĩals, or
events, and their interactive relationships which can cause interíace issues later on.

For this research the following detlnltion quoted from an unpublished metro project

document seems to fit well "there is an interíace between two Systems or subsystems when

one of them needs for its conception or realĩzation to take in account inputs from the other

one".

5
Out of the deíinitions scattered in literature, three characteristics of any project interface
can be realized:

1. Involves two or more different parties/entities (for example, contractors, owner,

designer, Systems, subsystems, etc...)

2. Requires coordination and management.

3. Can have different aspects, such as physical, functional, contractual etc... (A detailed
description of types of interfaces can be found later in section 2.4).

2.2 What is Interíace Management?

The National Aeronautical and Space Admìnistration (NASA, 2007) ỉn their Systems
engineering handbook dedicates a complete section for intertace management, in which
they State that IM is "an element of Systems engineering that helps to ensure that all pieces
of the System work together to achieve the system's goals and continue to operate together
as changes are made during the system's liíecycle". In another location in the same
handbook NASA States that IM includes "identification, deíinition, and control of
interfaces".

The Center for Chemical Process Safety a division of the American Institute of Chemical
Engineers (2004) detines IM as "the systematic control of all Communications that support a
process operation".

It should be noted from which perspective IM is deíined; the two above detìnitions belong
to the manuíacturing arena, and thereíore focuses on the Systems engineering perspective
more than the project management one, which Is prevalent in the construction and the
railway industry. As the railvvay projects is the background íield íorthis research, the project
management perspective is tavored over the Systems engineering one. Therefore the
following definition is adopted for this research, which is pointed out by Chen (2007) and
derived from the construction industry "the management of the boundaries among project
entities (people/participants, processes/phases, resources, contracts, costs, schedules,
systems/Tunctions, and safety/risks) to enable a dynamic and well-coordinated construction
System".

6
Another detĩnition for Project Interíaces Management is introduced in chapter four by this
research.

2.3 Objectives of lnterface Management

Objectives of IM can be derived from the dehnitions listed above. But in the literature
researchers and practitioners elaborated further on this part to show the importance of IM
and to encourage íurther efforts in the direction of developing processes and tools to help
solve the issues related to interface management.

Nooteboom (2004), Corning from the offshore industry, in his article titled "Interíace
Management Improves On-Tìme, On-Budget Delivery of Megaprojects" States that
"multidisciplined projects can easĩly have some 75,000 task-related interfaces", and
continues by saying that "the breadth and scope of these interíaces finds IM problems
typically accounting for up to 20% of project cost". From these statements Corning from a
person with over 30 years of experĩence in mega projects, one can realize what beneíits a
systematic approach to interíace management can alone bring to a particular project.

Accordingto an unpublished metro project document, the objective of IM is to provide a

process to control the exchange of intormation between two or more parties, in
order to resolve all aspects related to interíaces from identihcation to validation and
can have turther the following objectives:

• Ensuring that each party to an interíace understands the requirements of the other
party(ies) and manages his work on the basis of the same interíace data.

• Knowing that the exchange and agreement of the interface data should be
pertormed in a timely manner.

• Veriíying during testing, installation, integration and commissioning of the project

that interíaces are implemented as designed and expected, and to identity and solve
any problem (space, physical interfaces, íunctional interíaces, etc.) that may arise.

An interíace can be viewed as 3 roadblock to project progress, which means a project

cannot be completed vvithout overcoming these interíaces, which exist in the project even if

nobody did anything, because they are natural ingredient of the deliverables. Thus, these

7
interfaces shall be defined, and responsibilities to interíacing parties shall be assigned, and a
controlling body shall make sure that the needed inputs are provided. The provoking
question would be then, how to períorm interíace management in the context of projects,
and what interactions with project management are there.

2.4 Types of Interíaces

Understanding interíaces and the abìlity to categorize them, is vital for resolving the
interfaces later on, thereíore talking about types of interíaces is not a kind of luxury work,
but rather a complex task that researchers did not agree on, and practitioners in projects
are missing, and thereíore íacing difficulties in tackling identiíied interíaces.

Pavitt and Gibb (2003) categorized project interíaces into three main categories: 1) physical;
has to do with actual connections between Systems, elements, and components, more or
less technical in their nature, 2) contractual; usually between contractors, and
subcontractors, has a commercial dimension and determined by the way the scope of work
is packaged, and 3) organizational; mainly connections between people throughout the
project from initiation up to dosure.

Figure 2-1 shows a non-comprehensive list of different interface categories derived from an
unpubiished metro project documents. Accordingto the same resource, an interíace can be
categorized under more than one category; thereíore, those can be also named as aspects
or characteristics (i.e. It can be said that an intertace has a íunctional and a scheduling
aspects or characteristics).

Interíace Category Description

Physical Such as contact, weight, mechanical or electrical compatibility,

vibrations, etc...

Topological Resulting from relative position, e. g. of rolling stock and civil

works, at standstill as well when running

Punctional When a System expects another System to pertorm a tunction in

a speciíic manner, or two Systems must co-operate to pertorm a
function

8
Understanding Protocols, contents and íormat of data transmission messages

Design Limits of design, which intormation is to be provided by whom to

whom?

Supply Limits of supply, completeness to be checked (e. g. a cable

connecting two Systems has to be provided, whatever the

contractual issues)

Installation Who installs what (limits of installation need not to correspond

to supply limits)? Is installation possible and easy? This indudes
the possibility of delivering the equipment to its íìnal location.

Time scheduling Resulting from precedence relationship; an activity has to finish

before the other can start e. g. cable ducts have to be present

betore ínstallĩng cables.

Figure 2-1 Interíace aspects/characteristics (based on unpublished metro project

documents)

In general, interíaces as it is the case for risks for example, can be categorized into internal

and external. Deíining what is internal and what is external can vary from 3 project to
another. The purpose of such categorization usually helps deíine who shall manage what
interíaces. An example is shown in Figure4-7 chapter4 of this thesis.

Another dimension of intertaces categorization and classiíication can be based on the

importance of the interíace. For instance to specify whether an interíace is saíety related or
not. The purpose of such categorization is prioritization of interíaces, which will turther
improve the effectiveness of interíace management when it comes to cost/time trade offs,
allocation of resources, and bargaining situations. This kind of prioritization can be either
subjective or based on a safety and impact analysis contorming to the project needs and

stakeholders' tolerances.

Another dimension of Interíaces is the topological aspect; some interíaces are related to the
respective position of two subsystems. According to an unpublished metro project
documents, those interfaces can be identified and handled as any other interíaces, except
that an explanatory drawing is oíten necessary.

9
Finally, from a Systems engĩneering prospective, NASA (2007) classiíies interfaces into two
major categories; íunctional and physical, and further subcategorize them into control,
aerodynamic, environmental, noise, space, data, electrical, etc.... An example for a
functionaI-space interface is the space required to perform maintenance. Another example

to physical-electrical would be an electrical current moving from AC outletto fan wire.

10
3 Relationship betvveen lnterface Management and

Project Management

In railway industry, IM exists In a broader context governed by project management.

Interíaces are nothing but interlinks between project deliverables, people, and

organizations.

This chapter emphasizes the strong relationship between IM and project management from
different perspectives; the body of knovvledge, íactors causing interíace issues, project life
cycle, processes intersections, and roles and responsibilities (R&Rs).

3.1 Body of Knowledge

Reviewing the scattered literature, One can recognize that most of IM body of knowledge ĩs
still limited to practitioners, and organizational documentations, in other words companies'
know-how. A holistic view of the topic interíace management is still missing. Papers talking
about IM are still just dealing with speciíic problems in IM such as "Improving the Design-
Construction Interíace" (Alarcon and Mardones, 1998), "Common Interíace Problems
among Owners and Contractors (Al-Hammad, 1990) in addition to many others. No single
book is dedicated for interíace management when compared to a huge library of project
management books. A Standard for interíace management practices to serve as a guide for
practitioners to best practices is still missing as well, if compared to PMBOK® Guide and
Prince2 in project management for example.

Chen (2007) in her doctor of philosophy dissertation titled “An Object Model Framework for
Interíace Management in Building Iníormation Models" tried to build a holistic view of the
topic intertace management by developing a model and a framework, building on all the
efforts of previous researchers. Chen (2007) herselí says that "In the literature of building
construction, interíace related studies are very limited".

Major part of published intertace management body of knovvledge can be found within the
Systems engineering literature, sometimes under different names, such as "Systems

11
Integration". NASA for instance cover interíace management topic in their Systems
engineering handbook and they explicítly consider IM as an element of Systems engineering.
This advanced position can be attributed to the fact that high-tech Products manufacturing
organizations had to deal earlier with complex interfaces within their Products.

On the contrary, IM is implicitly covered in project management text books under sections
like "Integration Management" and "Communications Management", which usually cover
only the non-technical side of interfaces such as organizational and contractual interfaces
and any interfaces that has to do with project management artiíacts like interfaces that can

be found in a project schedule due to precedence relationships. Very few text books uses
the term "lnterface Management" explicitly. This is understood, because project
management does not try to get into the technical issues of projects which can vary from an
industry to an índustry in terms of knowledge, processes, skills, tools and techniques. For
instance, the Project Management Institute (PMI) insists that the scope of the PMBOK Guide
is limited to those practices that are considered applicable to most projects most of time.

Figure 3-1 illustrates the concept of intersecting bodies of knowledge. The intersection
between Systems engineering and IM is having a larger area to indicate that IM is covered
more explicitly is Systems engineering publications.

Interíace
Management

Systems
Project Engineering
Management

Figure 3-1 Bodies of knowledge intersections

12
3.2 Factors Iníluencing Interíace Management

Several studies such as (Al-Hammad, 2000) íocused on common factors leading to interíace
problems among interíacing parties such as owners, contractors, designers, subcontractors,
maintenance contractors, etc.... Huang et al (2008) based on a comprehensive lìterature
revievv in addition to face to face interviews and short survey with subject matter experts in
track engineering projects, listed 28 factors leading to interíace issues, and grouped them
subjectively into six different categories: íinancial problems, inadequate contract and
specihcation, environmental problems, technological improvement, track characteristics,
and cultural differences, and other common causes of interíace problems.

Chen (2007) has gone turther and built a complete multi-perspective cause and effect
diagram as show in Figure 3-2. For each perspective Chen (2007) listed several íactors that
lead to interface issues. Figure 3-3 illustrates the project management perspective. This is
considered by the author of this research as a clear evidence of the strong relationship
betvveen IM and project Management.

( People/ > c Methods/ 's ______________

(^Participants J KProcessos J R eso urces ^

Intertace ^
Issu es J

(bocum entation) f Project ^ (En viro n m en t)

yManagement/ ----------------

Figure 3-2 Interíace issues multi-perspective cause and effect díagram (Chen Q. , 2007)

13
Ignoring interíace n lỉfie n s h lp i
btw. Com p. o rsu b syste m s

Inaccurate projQct
costestlm ata

Figure 3-3 Interíace issues cause and effect diagram - project management perspective
(Chen Q ., 2007)

14
3.3 Project Life Cycle

"A project life cycle is a collection of generally sequential and sometimes overlapping
project phases whose name and number are determined by the management and control
needs of the organization or organizations involved in the project, the nature of the project
itself, and its area of application" (PMI, 2008, p. 15). Figure 3-4 shows a sample life cycle of a
metro construction project.

Preliminary Detailed Testing and

Design Design Comissioning
Phasel Phase2 Phase3 Phase4 Phase5

Figure 3-4 Sample metro project life cycle

Intertace Management takes place in the project environment which is broader by

definition. Therefore, IM is bounded by the project life cycle of the particular project. This
concept is illustrated in two ways; the íirst one using the waterfall or sequential model
Figure 3-5, where some kind of sequence is noticed in IM activities (processes) during the
project with some overlapping illustrated using dotted lines, and the second one using the
iterative model as shown in Figure 4-3 next chapter, where the IM cyde of activities
(processes) repeats itself in every phase.

The processes will be described in detail in Chapter4.

15
 P r e lím in a r y D e t a ĩle d M a n u fa c tu rin g T e s tin g a n d
D e s ig n / D e s ig n / in sta lla tio n y ? C o m issio n in g

Figure 3-5 Interíace management vvithin a typical metro project lifecycle - waterfall model

Understanding the project liíecyde and its characteristics, helps align the objectives of IM
with the higher level objectives of the project itself. For instance, it is common that changes
at the beginning of a project require fewer resources than in the middle or at the end of the
project. This concept is illustrated ĩn Figure 3-6. This concept can be reílected on IM, for
instance interíaces identitìcation should be completed in the early design phase, as far as
possible. Ideally all questions related to an interíace (interíace resolutĩon) should be settled
durlng the design phase as well, induding the testing and the verification method. However,
some details can only be agreed at a later phase, due to the Progressive elaboration nature
of projects, and the possibility of change requests.

16
 Figure 3-6 Cost of changes versus project time

3.4 Processes Interactions

In PMBOK Guide (2008), PMI breaks down project management into 5 process groups;
initiating, planning, executing, monitoring and controlling and íinally dosĩng. In each of
these processes groups, there are further sub processes. The total number of these
processes is 44. For each of these processes there are inputs, tools & techniques and

outputs.

In Chapter 4 of this thesis, similar approach is adopted for interface management. This
approach does not only imitate the project management processes but also communícates
with it. This communication is done through different ways; the first one, that outputs from
project management processes are inputs Into interíace management processes and vice
versa. For instance resolving certain intertaces might affect procurement decisions, while
packaging the work in the WBS will affect the deíinition of the interíaces. Furthermore,
identifying new interíaces may lead to identiíication of new risks, where change requests In
response to an interface issue requires project management integrated change control
process to make the decision vvhether to approve or reject. The second thing is that
interíace management proposed processes use some common project management tools

such as checklist analysis, critical path method, etc...

This interaction is not new; Godinot (2003) tried to utllize the work breakdown structure as

a tool to improve interíace management. Project management has taken this approach
before by using tools from other íields like lshikawa diagram, and some other statistical

analysis tools.

17
Details of theses interactions will be described later in Chapter4.

3.5 Roles and Responsibilities

IM roles and responsibilities (R&Rs) are directly affected by the way the project has been
contracted. Railway projects for instance, are typically avvarded to a main contractor or a
consortium, a group of contractors. Even if the project is awarded to a single contractor, this
main general contractor (GC) will start subcontracting the various parts (deliverables) of the
project according to competencies. Civil works are usually packaged together, where other
works like the Systems part (high technology) such as power supply, signalling, rolling stock
and other works are subcontracted to different organizations. This way of packaging the
work as symbolically, illustrated in Figure 3-7, has a direct impact on the shape of interface
management organization.

Figure 3-7 Railvvay projects contractingtypica! model

Then, as per the GC approach, vvorking groups can be íurther íormed; One representing the
Systems' subcontractors induding representatives of each System or subcontractor and
another group for civil works and dosely related works. Based on such grouping approach

18
roles and responsibilities can be assigned as shown in Figure 3-8 as derived from
unpublished metro project documentation.

Role Responsibilities

• Overall supervision of the IM.

• Follow very dosely the identification and the resolution of the interfaces
between the Systems group from one side and the cw group from the
otherside.
• Get intormed of interíaces with external entities and will be
involved every time the resolution of these interfaces may impact
GC/PM (Pertorming
íinancially or technically the construction and the operation of the
Organization)
project.
• Organize regular Interíace Review Meetings (IRMs), and invite involved
parties to it as necessary.
• Supervise the administration ofthe System group of the interfaces
register for all identiíied interfaces between groups and with
extemal entities.

• Manage their internal interíaces under their own responsibility.

• Have full responsibility of managingthe interíaces between them under
supervision of the GC/PM.
Systems and cw • Co-operate to the identiíication, resolution and management of all
groups (sub- intertaces between them. For each interíace betvveen the subcontractors,
contractors) one will act as the fĩrst entity and take the lead in the management of the
interíace with support from the other group (the "second entity").
• ldentify any interíace with external entities and manage them in co-
operation with the GC/PM.

• Establish the Product Breakdown structure of its Systems, according

to the principles given by the PM.
• Administrate the interíaces register and fill it with data for all identiíied
interíaces.
Systems group (sub-
• Communicate with the cw group for acceptance.
contractors) only
• Report the status of identified interíaces to the GC/PM.
• Prepare and complete the Interíace Data Sheets (IDSs) and thereíore
assess the different aspects of the interíaces (design, supply, installation,
testing, hazards and SIL, etc.) and establish the co-ordination drawings.
Figure 3-8 lnterface management roles and responsibilities at a high-level

Each party the general contractor/project manager, the System group and the civil works
groups shall assign an interface manager. This interíace manager or coordinator as pointed
out in literature shall deal with all interíace matters of the party he/or she is representing.

19
This interface manager, vvhich is becoming a must in projects, will be very dose to the
project manager. He/or she shall be equipped with strong communication skill to handle
interíace issues among various different parties and should have a strong technical
background to understand the project complexity (Shirley et al. 2006).

From what is described above, there will be for sure overlapping roles and responsibilities
betvveen project management and IM. The degree of overlapping is dependent on the size
and complexity of the project.

Pinally, in exceptional cases, the owner, or main contractor might go a step íurther and
subcontract the whole project interface management activities to a different organization.

20
4 Project Interíaces Management Process Model

Project lnterfaces Management (PIM) indudes the processes of conducting interíace

management planning, as well as the ident'rfication of project interíaces and trying to come
up with Solutions to be implemented, and controlled in coordination with all involved
parties to support the overall project activities from design up to commissioning towards
successtul condusion. PIM is presented here utilizing the structure and the language being
used by PMI (2008) in the PMBOK® Guide (chapters 4 to 12). The purpose behind this is to
bring clear structure to PIM. This structure will serve as a guide for practitioners, and will
further enable the integrability of PIM with project management. Figure 4-1 illustrates the

concept of integrability.

Figure4-1 PIM: a proposed new member of the PMBOKtamily of knovvledge areas

In this chapter the term "Project lnterfaces Management" (PIM) will be used instead of
"lnterface Management" IM. The reason behind this replacement is to emphasize, that this
chapter introduces a process solely designed to manage project interfaces, which may not
be applícable elsewhere in the broader context of intertace management, such as interíaces

within supply chains or operations. Furthermore, if PIM is to be integrated into project

management as proposed in Figure 4-1, the scope of PIM is to be further limited to technical

21
interfaces, to avoid any possible coníusion with project Communications and integration
management already covered in project management standards.

The PIM process proposed here indudes six sub-processes as shown in Figure 4-2 inspired
by the famous PDCA cycle of "Plan-Do-Check-Act" known also as the Shevvhart cyde. Each
process will have inputs; these inputs will be processed using some kind of tools and
techniques to produce speciíic output that might be íurther used by another process.

\
Validate
tnterfaces
____________ /

Figure 4-2 PIM process

Figure 4-3 provides an overview of Project Interíaces Management Processes, which are as
follows:

4.1 Plan Interíaces Management - The process of detining how to períorm intertace
management activities throughoutthe project.

4.2 ldentify Interíaces -The process of detìning and documenting which project interíaces
should be managed.

4.3 Resolve Interíaces - The process of developing agreed upon Solutions and actions to
tackle each identiíied interíace.

4.4 Implement lnterfaces - The process of communicating and directing the execution of
the agreed upon interíaces' resolutions.

4.5 Validate lnterfaces - The process of ensuring that each interíace is completely resolved
satisfactorily and obtaining formal acceptance.

22
4.6 Monitorand Control lnterfaces-The process of tracking identitied interíaces, identifying
new interíaces, monitoring the implementation and validation of interíaces, evaiuating
interíace management processes effectiveness throughout the project, and managing
changes to interíaces as they occur.

1 Inputs .1 Inputs .1 Inpuls

• Project Management Plan
.2 Tools and Techniques
« lnterface Management
Prindptes
• Planning Meetings and
Analysis
• Interíace Classiíication/
Categorízation
• Interíace Coding
.3 Outputs
• Intertaces Management Plan
1 1nputs
• Interíaces Management Plan
• System s Architecture Drawings
• Seope Baseline
• Product Breakdown Structure
• Procurement Oocuments
.2 Tools and Tectiniques
» Ooeumentation Reviews
• lnterface Matrices
• Iníormation Gatheríng
Techniques
• Checkllst Analysis
• Ẽxpert Judgmẽnt
• [níormation Systems
,3 Outputs
• Intertace Data Sheet(s)
• Intertaees Register
• Intertaces Management Plan
• lnterface Data Sheet(s)
• lnterfaces Register
• Project Sctiedule
> Project Documents
.2 Toots and Techniques
• Technical Resolution Meeting
• Intetíace Hazard Analysis
• Expert Judgment
• Strategies for ResoMng
Interíaces
• Simulation and ModeUng
.3 Outputs
• Interíace Data Sheet(s)
updates
• Intertaces Register updates
• Interíace-Relãted Procvirement
Decisions
• Project Management Plan
Updates
.1 Inputs
• Interíaces Management Plan
• Intertace Data Sheat(s)
• Interíaces Register
• Project Management Plan
■ Approved Chãnge Requests
.2 Tools and Techniques
• Iníormation Distribution Tools
• Communication Methods
.3 Outputs
• Implemented Intertaces
• Interíace Issues
• Interíaces Management Plan
• lnterface Data Sheet(s)
• Interíaces Register
• Project Management Plan
• Testing and Commisskining
Documents
.2 Tools and Techniques
• Inspection
• Reviews
.3 ỡutputs
« Validated Intertaces
• Interíace Issues
1 Inputs
• Interíaees Management Plan
• Intertace Oata Sheet(s)
• Interíaces Register
• Implemented and Validated
lnterfaces
- Interíace Issues
• Proịect Management Plan
• Períormance Reports
• Work Períormanee Iníormation
.2 Tools and Techniques
• Intertace Review Meetings
• Audrts
• Interíace Reassessment
• Varíance Analysls
.3 Outputs
• Proịect Documents updates
• Process Assets Updates
• Change Requests

Figure 4-3 PIM processes overview

These processes interact with each other and with other processes within project
management knowledge areas in an iterative way during the whole project life cycle as

illustrated in Figure 4-4. This means that any of these processes might occur several times in

23
the same prọịect phase and in different phases for the same interíace or for different
interíaces.

Figure 4-4 PIM versus project phases - iteratĩve model

The pertormance of these processes over and over vvithin organizations through various
similar projects will create organizational assets. These assets might be tangible such as
documentations or intangible such as knovvledge and expertise obtained by engĩneers.
These organizational process assets as they accumulate will start to iníluence every
intertaces management process descrìbed later, and will provìde each process with valuable
inputs (PMI, 2008, p. 32). These inputs might indude but are not limited to:

• Common deíinitions and abbreviations,

• Standard templates,

• Interíace classification/categorization,

• Roles and responsibilities,

• Lessons learned,

• lnterfaces registers, and data sheets for historical projects,

• Historical schedule, cost, and time baselines

• Testing procedures,

• Standardized guidelines and work instructions,

• Communication requirements,

• Interíace issues log, punch lists, project deviations lists,

• lnterface management evaluatĩon,

• Change requests, etc...

24
 .in E m n m m m iiim i
To avoid redundancy organizational process assets are not mentioned later in the processes
inputs.

In addition to the organizational process assets, the tactors described in section 3-2 and
furtherfactors described by (Al-Hammad, 2000) and (Huang, Huang, Lin, & Ku, 2008) as well
as (Chen Q ,, 2007) will iníluence PIM processes directly or Indirectly.

Examples of these factors include but are not limited to:

• Availability of skilled labor,

• Availability of proper iníormation Systems,

• Availability of space,

• VVeatherand geological situation ofthe site,

• Availability of iníormation standards,

• The structure of the project,

• Governmental regulations,

• The quality of the written contract, etc...

The interíace management team should be aware of such íactors. Thereíore these íactors
can be seen as inputs to the processes. To avoid redundancy these íactors are not listed
later in the processes descriptions.

4.1 Plan Interíaces Management Process

Plan Interýaces Management is the process of deíining how to períorm intertace

management activities throughout the project. This process provides a roadmap for the
other five processes described later.

This process should be done as early as possible in parallel to other project management
plans development such as the communication, procurement, schedule, and other
management plans. Besides, it is not uncommon, that this process is períormed by external
parties, consultants, designing organizations especially in large and complex projects prior

to detailed design phases.

25
It is intended that this plan will apply through design, construction, and commissioning of
the project. Figure 4-5 shows the inputs, tools and techniques, and outputs for this process
and the data flow diagram is shovvn in Figure 4-6.

INPUTS TOOLS AND TECHNIQUES OUTPUTS

• Project Management Plan • lnterface Management • lnterfaces Management Plan

Principles

• Planning Meetings and

Analysis

• lnterface
Classification/Categorization

• Interíace Coding
Figure 4-5 Plan lnterfaces Management process overvievv

Figure 4-6 Plan Interýaces Management data flow diagram

4.1.1 Plan Interíaces Management: Inputs

.1 Project Management Plan

The project management plan is a living document that draws the roadmap of not only
work execution but also detines how scope, schedule, and cost shall be planned,
monitored, and controlled (PMI, 2008, pp. 81,82).

The project management plan includes but is not limited to:

26
 • Description of the project lifecycle and project phases,
• How work will be executed to accomplish project objectives,
• Scope, schedule, and cost baselines,
• Management plans including but not limited to scope, requirements, schedule,
cost, human resources, quality, Communications, risk, procurement, change,
contiguration, etc...

The interface management team shall ensure to have always the latest updates of the

project management plan.

4.1.2 Plan lnterfaces Management: Tools and Techniques

.1 Interíace Management Principles

Interíace management principles can be found in literature and in the knovvledge

accumulated through the years due to the continuous conscious and unconscious
practice of interíace management.

Although there is no such book or Standard dedicated to the best practices of interíaces
management. Nevertheless, deíinitely such thing might develop in the upcoming years.

Detinitions of interíace, and interíace management can be derived from these

principles. Understanding these principles is essential for the intertace management
team while developing the intertaces management plan.

.2 Planning Meetings and Analysis

Meetings shall be organized to develop the intertaces management plan. Attendees

may include all parties that will be responsibỉe for intertace management later on in the
project. other stakeholders can be invited as appropriate. The involvement of key
stakeholders in planning will minimize conílict later on, and shall create a buy in
situation and common understanding of the whole interíace management group of
processes.

PIM responsibilities will be assigned in these meetings. Interíace categories and

classitications will be tailored to the needs of the project. Templates for the next

27
 processes may be tailored for this project or developed from scratch if they do not
already exist (PMI, 2008, p. 279).

.3 lnterface Classifìcation/Categorization

As mentioned in chapter 2 of this thesis, interíaces dassiíication and categorization

serve two primary purposes; first deíiningthe roles and responsibilities like the sample
of interíaces classiíication shown in Figure 4-7. The second purpose is to íurther help in
resolving interíaces, this categorization can be a customized version of what is available
in literature according to the needs of the project.

X
other Projects (lines) J

Leqend:

• Interíaces betvveen the sam e System (Black)

• Interíaces between System s in the System
package or between clvil vvorks (Rủd)
• Interíaces between the Systems on one side
and the ch/iỉ works on the otherside ( ;• • • ■'.)
• lnterfaces between the proJect System s, civll
works and extem al entitles, such a s road
works, Utilities, etc (Green)
• Interíaces between ữie X Y 2 project (metro lìne)
and other future or parallel projects (lỉnes)
(Biue)

Figure 4-7 Sample railway project interfaces dassiíication (based on unpublished metro
project documentation)

.4 Interíace Coding

Each intertace shall have a unique number (code) for tracking purposes. This code will
be used later in Identiỷy lnterfaces Process as a constant field in the interíaces register,

28
 and the intertaces data sheets. Besides tracking, coding can serve in referring to the
interfacing entities, and which entity is leading. Based on project needs it might be also
important to take into consideration the possibility of the continuous identiíication,
merging, and elimination of interíaces at later phases. Figure 4-8 shows an interíace

coding example.

324 MWE GHA

Ặ Ị
: Seconđary Enlity
(Subcontractor, System, etc...)
Primary Entity
....... (Subcóntractór. System, etc...)

---------- Interíace Number

Figure 4-8 Interíace coding example (based on unpublished metro project documentation)

4.1.3 Plan Interíaces Management: Outputs

.1 Interíaces Management Plan

The interfaces management plan, or interface management design as preíerred to be

named by engineering organizations, describes how interíace management will be
structured and períormed on the project. It can either become a subset of project
management plan in case there is integration between project management and PIM or

can be regarded as a standalone technical document.

Thỉs plan or design can be tormal or iníormal, highly detailed or broadly íramed and
based on the needs of the project. The quality of this document will highly affect the
quality of intertace management, the more elaboration; the more systematic interfaces
management shall be expected.

The interfaces management plan includes but is not limited to:

• Principles of interíaces: includes the definitions of interíace, interíace

management, and other important terms, as well as describes the objectives of

interface management,

29
• Methodology: deíìnes the approaches, tools, and data sources that may be used
to períorm interíace management on the project,

• Roles and responsibilities: Deíines the leading and supporting roles at different
levels; entities {sụch as Systems subcontractors) or personnel level (such as
specific positions vvithin the períorming organization),
• Project interíace management team organization chart: relation to the whole
project team would be a value adding iníormation,

• staffing requirements: based on project needs PIM might require dedicated

personnel that shall be recruited at different stages of the project. This part can
be a customized version of the project staffing plan, or simply can indude a
reíerence to the relevant sections of the project staffing plan,
• Timing: deíines when and how írequent interíace management processes will
be carried out during the project liíecycle. Can indude some sort of guidelines of
how to link PIM activities and the project schedule,
• Classification of interíaces: a practical classiíication that might be linked to roles
and responsibilities. Figure 4-7 includes an example drawn from unpublished
metro project documentation,

• Categories of intertaces: defines the various types of interíaces, the criticality

aspect of interíaces, and the interíace of topological aspect,
• Detinition of interíace criticality and priority scales: this part can be later used
in the Identiỷy ínterfaces and Resolve Interýaces Processes,
• Interíace metrics: as will come later can show a broad frame of the interíacing
entities, Systems, subcontractors, etc... in the project, that can be used later as a
tool to help identiíy intertaces later in the project,
• Interíace management processes: describes the different PIM processes that
will be períormed in the project, can be simiỉar to the six processes proposed in
this chapter tailored to the project needs and can include a brief description of
the inputs, outputs, tools and techniques of each process,
• Coordinating interíaces with other project aspects such as risk management,
scheduling, pertormance reporting, procurement management, etc... A

30
 reterence to sections in the project management plan might save some details

in this part,

• Communication requirements: what interface related intormation shall be

communicated, to whom, who will distribute this intormation, how trequent, in

what format, etc.... This part can also indude a description of escalation process.

Interface review meetings can be described in this section in terms of content,

trequency, and target attendees, in addition to meetings templates,

• Any constraints and assumptions that could affect PIM,

• Templates: interfaces management plan can include template for the other
processes such as interfaces register, interface data sheet, and

• Glossary of terms and abbreviations

4.2 Identiíy Interíaces Process

The process of determining and documenting which project intertaces should be managed.
This definition implies that not all intertaces will be documented. For instance from the
point of view of the general contractor in a metro project an internal interíace within
supplier of the signalling equipment is the responsibility of the later and should not be
included in the project interfaces register, vvhile for example an interface between the
signalling equipment and the platíorm screen doors should be registered and managed.

This process starts at the preliminary design phase, nevertheless, it may need to be
completed in the following phases. Identihcation of critical interfaces at a very late stage
can indicate poor interface management.

Since each interíace involves at ỉeast two entities, responsibilities should be made dear in

the interíaces management plan, regarding who shall register the intertace, and who shall

issue the interíace data sheet. For instance in raìlvvay projects this responsibility is more

likely to be assigned to the Systems group (the group of units, teams, subcontractors

responsible for signalling, power supply, rolling stock, and Communications Systems, and

other). However, agreement should be obtained on registering an interíace, and issuing and

interíace data sheet by the involved entities.

31
Figure 4-9 shows the inputs, tools and techniques, and outputs for this process and the data
flow diagram is shown in Figure 4-10.

INPUTS TOOLS AND TECHNIQUES OUTPUTS

• lnterfaces Management Plari • Documentation Revĩews • Interíace Data Sheet(s)

• Systems Architecture • lnterface Matrices • Interíaces Register

Drawings
• lnformation Gathering
• Scope Baselỉne Techniques

• Product Breakdown Structure • Checklist Analysỉs

• Procurement Documents • Expert Judgment

• Iníormation Systems
Figure 4-9 Identỉýy Interýaces process overvievv

• Syslsms Arehilscture
Órawings
I •• PBS
Procurement Oecuments

Figure 4-10 Identiýy Interýaces data flow diagram

4.2.1 Identity Interíaces: Inputs

.1 Interíaces Management Plan

Refer to section 4 .I.3 .I.

.2 Systems Architecture Dravvings

Architectural drawings are the main representation tools in construction projects in

general and in railvvay Systems in particular. Based on these dravvings not only

32
 interíaces can be defined but also estimates of costs and time are generated. Thus
dravvings are multi-purpose communicating tools among engineers. Dravvings save
thousands of words, and help achieving common understanding.

.3 Scope Baseline

A scope baseline according to (PMI, 2008, p. 122) indudes the following:

• Scope statement,

• WBS and
• a WBS dictionary
A baseline means it has been approved; hence any change to this scope should be done

through proper change management.

Project management text books contain a very detailed description of the scope
statement objectives and content. WBS, stands for Work Breakdown structure, is a
tree-like decomposition of the project into smaller more manageable deliverables and
groups of activities. The WBS dictionary is a kind of companion document that explains
every component in the WBS. An example of a WBS of a railvvay System project is

shown in Figure 4-11.

The scope baseline will constitute the primary input for deíining the interfaces within

different project work packages.

.4 Product Breakdown structure

PBS is a tree-like decomposition of the final product into Systems, subsystems, etc. PBS
is very similar to the WBS and should eventually refer to the same final product.

Nevertheless, the PBS is prepared from a technical perspective rather than a project

management perspective as in the WBS. A WBS can give a better cost and resource

estimation possibilities when compared with the PBS. An example of PBS of a railway

System project is shown in Figure 4-12.

33
.5 Procurement Documents

Procurement documents, especially contracts and sub contracts are very helpíul in

identifying hidden ìnteríaces. Reading between the lines of those legally binding

documents will reveal some other interíaces that might not be considered in the scope.

Any other technical or non-technical document that may help in deíiningthe ínteríaces

should be made available to the interíace management team.

34
 Metro System

Figure 4-11 Example of railway System project WBS

Figure 4-12 Example of railway System PBS

35
UililiỉUtiiHẩilỉlẳHểỉiilỉlMtiUỈỈOtiUU
4.2.2 ldentify Interíaces: Tools and Techniques

.1 Documentation Revievvs

The continuous review of project documentation; the technical such as dravvings,

layouts, designs, and the managerial including but not limited to contracts and plans is a
helptul tool to identify interíaces. The reviews of technical documents are usually done
by experts in different project Systems. Theretore the interíace management team shall
coordinate with those experts for the prompt feedback.

In practice project documentation is subject to rectification throughout the whole

project, thus it is usual for some interfaces to be identiíied at a later stage of the
project. A typical railway project includes thousands of documents to be revievved.
Revision process involves several layers of reviewers ending by the consultant or
engineer review for acceptance. These documents are considered as part of project
deliverables, most of the time even payments are linked to the provision of proper
documentation.

.2 Interíace Matrices

A matrix presents data in a form of columns and rows, in which additional iníormation
can be speciíied atthe intersection cells. Systems, subsystems, project components can
be presented at both columns and rows headers. The selection of matrices' content will
eventually determine the level of detail of the interíaces that can be deíined.

These matrices provide a handy tool also to deíine the leading System of every
ìnteríace. Figure 4-13 shows a sample of an interíace matrix drawn from unpublished
railway project documentation.

.3 Intormatĩon Gathering

There are many well-known techniques for gathering iníormation that can be helpíul in
identiíying project interíaces. These techniques are vvidely described in literature, and

most professionals have experienced these techniques in different situations.

36
 Examples of these techniques indude but are not limited to:

• Brainstorming

• Delphi technique

• Intervievving

Figure 4-13 Sample interface matrix of a railway System project

.4 Checklist Analysis

lnterface identification checklists are usually developed based on historical data

accumulated from the pertormance of similar projects. The interíace management
team should review such checklists, if exists, extensively and considerthem as a starting
point that can bring further interíaces.

As part of project closeout, updating these checklists to be used for íuture projects is
something that should not be skipped. The quality of these checklists is proportional to
the attention given to them (PMI, 2008, p. 287).

.5 Expert Judgment

Experts vvithin the performing organization, suppliers, and even sometimes external to

the project parties can be identiíied by the intertace management team and invited to
have an overvievv of the project scope and contribute to interíace identiíication (PMI,

2008, p. 288).

37
.6 In to r m a tio n S y s t e m s

Iníormation System will allow the proper exchange of iníormation regarding interíace

identifications. Permissions can be regulated to govern registering interfaces task.

These Systems are novvadays accessed Online. Such Systems can save a lot of paper

work.

4.2.3 ldentify lnterfaces: Outputs

.1 Interíace Data Sheet(s)

Each intertace must have only one Interíace Data Sheet (IDS). Once an intertace is
identified the leading entity shall develop and issue the IDS with inputs from the second
entity and other involved parties as necessary. Eventually all involved parties should
agree on and sign this IDS.

The IDS may include after this process, depending on what is agreed upon in the
intertaces management plan, but is not limited to:

• lnterface title,
• Intertace code,
• Interíace location
• Involved entities (intertacing parties),
• lnterface description induding (as relevant):
- Physical aspects
- Function,
- Data and iníormation required for interíace resolution,
- Design responsibilities,
- Supply responsibilities,
- Installation responsibilities,
- Testing responsibilities
• Interíace dassitication: for example internal or external, should be according to
what is specitìed in the interíaces management plan,

38
 • Interíace category: for example íunctional, physical, schedule, supply, etc...,
should be according to what is speciíied in the interíaces management plan
• Environmental constraints: for example temperature, humidity, etc...

• Assumptions

• Comments.

The IDS should be bríef, so as to be easily manageable. Also it should be avoided to

include items that require constant control and update such as the status and the
deadline, these items will be part of the next described output.

When it is not possible to describe the interíace in a few lines, reterence will be made
to a document or a plan where the issue is dealt with. Figure 4-14 Shows a sample of an
IDS drawn from a railway construction project (unpublished metro project
documentation).

39
 INTERFACE DATA SHEET

Ttí e 21 Xì'ĩ As 5Se-.*- '-S-Tít iCSv

Lecatíoo: “*s'i * —«

ln t « f s « Ca^eíiumbo*: X S S ^ Srf«yre«tmJ(V/?(|: \ í P nariY- Vaee-a®

!nterf»ẽngEnổt>«: Entty 1 [L ead^D C-: T K t y

E n ttf 2 :* s < Sc-rr-M-.r

Hefcoc DWV-S>WHW0CE-3ClCi:CS
lnterf*<r Dtacrpton Summtry
Cr.s-sa-sS-Srspt*- sy s**? e * 4 * « s .'5LÌ a é ; r : r . 3e s*sv/ 5 * 2 _ 5 “ 1 3 =:y*e * a t Sff s f / s e s .t e s t saaes
s--S5^ sr.'ía —^ e ia -a .« ^ e S > sso '? sc --5 e *fsr—ít.
t s 1! s e a S e » :3 rr—-^-'atetne C-Arrg
- ’ j'n 9C3Ì3C! >íĩ*T;«vep*:>5 * * • « :*
- 2 o e * st' ars. ir4e r e - g e *Sỷs s t s

RcgonâìâStic
te r 0 » *S ” - :a sẽcr 'w t
1 ữ vaca-tí A3 ĩ X r » f » S C í» > « í» -v: :r : - . á í * •ỉ< :
Ĩ:< 1 Ổ S '
■
> V2S Ỉ ± / J 9 * >s ta»iisí 2' ? : ts-VaetT n< :r :- « s .v Í Í S ‘ Í« Í:'
3 Ĩ5 t * h e t a « r5< *K Ĩ9 '> w e ĩ T •s< : r l - i : S ' • « s » :iỂ e *
1 ®5V« * a : « »r:a*:-.5te* 5*2: :■ > «:? •s< »ĩ< 3s- : k 5ĩ *

Erníronment CerBtrẽntK
rpe*ste*',“«Tse^-'tt:-2Ũt2-50 *c
ĩtara5« —sersr.-e: »2CĨD-7Ũ*c

Figure 4-14 Sample IDS (based on unpublished metro project documentatĩon)

IDS(s) will continuously be updated with iníormation resulting from the other interface
management processes, and may further include additional items after Resolve
lnterfaces Process.

.2 Interíaces Register

Once the IDS is issued not necessarily signed, the interíace should be registered. Each
row in the interíaces register (IR) will correspond to an interíace data sheet. Interíace
coding in this case is very important to properly track interfaces.

IR will continuously be updated with iníormation resulting from the other interíaces
management processes. Thus, as time passes the interíace register will grow in terms of
quantity and quality of inputs. In other vvords, Identiýy Interýaces Process is the initiator
of the interfaces register, and then it will be made available for all other processes.

40
IR after ldentify Interýaces Process will indude a lĩst of identiíied interíaces, and for each

interíace, more or less, the following intormation can be entered:

• lnterface Code: should be based on the agreed upon interíace coding as

described in the interíaces management plan,
• Author: the author can be a person or a group, and most probably in large
prọịects such as railvvay projects it will be one of the subcontractors,

• Date registered: this can be the date the ínteríace data sheet was issued.
• Short description: to give the minimum understanding of the interíace,
• Safety related: a (Yes/No) field that is of great importance for interíace
management. As it can the basis for prioritization, vvhenever tradeoffs are
required. Indicating whether it is satety related or not, can be based on
subjective opinion or safety analysis períormed by subject matter experts,
• Priority: using a scale of words for simplicity (such as high, medium, and low) or
numeral (such as a number between 1 and 5). Either way, this shall be

predeíined in the interfaces management plan with dear interpretation,

• Owner: every interíace involves two or more entities, Systems, subsystems, etc...
for efficiency, and according to best practices, only one entity should lead, and
be responsible for the development of the interíace data sheet, and the
resolution later on. The author and the owner do not have to be the same. A
good interfaces management plan shall include a methodology for detining who
should lead. Leading roles can follow the industry practices, for instance it is
common in railvvay projects whenever there is an interíace between signalling
System and civil work the signalling System supplier should lead,
• Oeadlines: this field most probably wiil be detined in Resolve Interíaces Process.
This field can include planned aspect and actual aspect of supply of informatĩon,
resolving the interíace, testing. The integrity of deadlĩne should be maintained as
possible. Though variation from deadlines can be acceptable to a certain extent

based on project stakeholders' tolerances,

• Status: to show whether the intertace is still open or already closed. Thĩs field
shall be updated laterthrough Monitorand Control Interíaces Process, and

• Comments as necessary.

41
Figure 4-15 shows a sample interíace register for a metro project.

A i "_____c 0 < L
Code 1 A.ithor 1 °'UO Entityl 1 Enrity2 1 IntcrlaceOesrption _ S4fety Prioritv Owncj ll1RD
esolution
Dddlin« J Locatlont
3_____OI _____ BL_____ 3. Q
cíãĨĨrũnỹróứtỉrígsn5 “ "ị ■ ỊEqulpcment
00003-psD-av Wlliea4J- «/a5/20<JPSD Intutootoadi endbetweenj 1
ỊCluil ịequlp m entroom md PSDaxid í 3 WES . 24*03/2010 aosed roomstall
2 1 í 1' 1 J?ED-_________ _____•__ i 1 stìOorts
3 00005-PSD-CIV Waheed,J. 09/10/2009PSD Clvll LoeatlonofeastInbradcets No 4 WES 30/04/2010 Open sta tloní’
Platíorms
1SyndnDnỊasÔwbỈỊ3Mẽ«rtrilri “ “ V • J—
4 00023-RSK-PSD ỊymtaiC .ị ĩo/W!nmỊ^j* jpso dãlBMÌÚinL-...........
1 CNB 1 aaiAM/aonỉ Open General
OO^-S.G-MP omtnn, F B W a o . a i n . m n , No . THA 30/04/^m. Cpnn
5 _______________________ __________ _______ _________ _ ________ ____________ ____ sheđ

, I | X n ^ £ S Ĩ ^ X " H Y° I * J

' Mser-PSD-MEI' Hons l

________ _______ ______
22/08/2010 PSD
______ ________ ___ _
MEP oov/erlsolatorconneetlon md
____________type__________
Y5S
____ _____ ____
J
_____
MỊS
____
lo /tu /H n l 0p_"en stmons-
Platform$
]_ ' "1 1dibteann«áíoãb«Bwetn 1 " ........ , “1 ’ Dcpõt
05642-MEP-SCA RdtM>H. Ị taỊữBtSữáMEP IsCAQA SCAOAond bulldlng ! No í, 3 ị MOR ì 04/04/2010Closcd ■dminttntia I
8 ------ . J .... . . . i ____L _ ...I ______L«ạíMWW^WỊt|®__________ . ..._. ,_ L __________________J__7 .______ "builđlniĩ J
, O^-SIG-OSK u *0 . 11/12/2010 Slgnalllng ™ " s Ve 1 THA 10/02/2M1 Ooeõ Gennral

Figure 4-15 Sample IR for a metro project

4.3 Resolve lnterfaces Process

The process of developing agreed upon Solutions and actions to tackle each identiíied
interface. The deíinition implies that all involved entities/parties should agree on the
solution and the actions to be turther taken to resolve the interíace. These actions shall be
documented as part of the IDS and as a result the intertace register will be also updated.

The results of thĩs process will iníluence other project management processes. Theretore
coordination is necessary with the project management team. For instance some dates
might have to be changed in the project schedule, some procurement decisions might also
have to be made, experts might have to be brought to participate on the resolution etc...

This process takes place during the whole design phase. Due to the iterative nature of the
processes it can reoccur in later phases either for a kind of turther analysis for a certain
solution, or to agree on a resolution for a nevvly identiíied interíace. Resolutions will most
probably include a design aspect, installation and manuíacturing aspect, and a testing
aspect. All of these aspects will be taken into consideration when implementing the
interface resolution and further validating the interíace as well be íurther described in the
next sections.

42
The GC/PM is not in charge of identification and resolution of the ĩnteríaces. He will
only supervise these processes and take binding decisions, should the groups not be
able to agree about the resolution of an interíace problem.

Sometimes there is no need to deal with interíaces, the solution of whích is obvious for all
concerned Partĩes. Fĩgure 4-16 shows the inputs, tools and techniques, and outputs for thĩs

process and the data flow diagram is shown in Figure 4-17.

1NPUTS TOOLS AND TECHNIQUES OUTPUTS

• lnterfaces Management Plan
• lnterface Data Sheet(s)
• lnterfaces Regỉster
• Project Schedule
• Project Documents
• Technical Resolution Meeting • Interíace Data Sheet(s)
Updates
• Interíace Hazard Analysis
• lnterfaces Register updates
• Expert Judgment
• Ínterface-Related
• Strategies for Resolving
Procurement Decisions
lnterfaces
• Project Management Plan
• Simulation and Modeling
Updates

Figure 4-16 Resolve lnterfaces process overvìevv

Fỉgure 4-17 Resolve lnterface$ data flow diagram

4.3.1 Resolve lnteríaces: Inputs

.1 Intertaces Management Plan

Refer to 4 .I.3 .I.

.2 Interíace Data Sheet(s)

Reterto 4.2.3.I.

.3 Interíaces Register

Refer to section 4.2.3.2.

.4 Project Schedule

A project schedule shall at least contain a planned start and tinish date of each activity.
Highly proíessional organizations usually add resources to each activities; tinancial and

man power as well as equipment. Project schedules nowadays are developed specially
in complex projects such as railvvay projects using specialized software, examples of
these software Solutions are available in the market and customization can be íurther
implemented for optimum results (PMI, 2008, pp. 157-159).

The project schedule can be presented in different forms such as Gantt chart, network
diagram, or a simple table of activities.

It is important to mention especially in large and complex projects such as railway

projects, a proper schedule is a master schedule that consolidates the schedules of all
subcontractors integrated in a way that shows the interdependencies of different
activities even among different partles/subcontractors.

44
.5 Project Documents

Project documents include but are not limited to:

• Architectural drawings,

• Procurement documents,

• Project management plan, and

• Any document that can help on resolving interíaces.

4.3.2 Resolve Interíaces: Tools and Techniques

.1 Technical Resolution Meetings

Once an interface ĩs ídentĩíied, and potential interíace issues become íoreseeable, any
entity/party may call for an interíace technical resolution meeting. Stakeholders may be
invited as necessary. Every entity is expected to contribute in this meeting to come up
with a proper solution. However responsibility for the technical resolution of the
interface remains to owner (the leading entity) of the interíace (unpublished metro

project documents).

Consensus is recommended but difficult to reach; therefore meeting facilitating skills

are vital in such situations. Diverting opinions are healthy as long as they are facilitated
in a proíessional way, away from bias, and personalizatĩon.

.2 Interíace Hazard Analysis

To determine safety related interíaces, a hazard analysis can be conducted. In railvvay

projects' as many other construction projects, interfaces involve many hazards
especially during installatĩon and even testing. These hazards can indude but not
limited to possibility of loss, injury, disadvantage and destruction.

The impact of these hazards may extend to operation, if not properly resolved during
design and installation, and validated during testìng. A typical safety related interface in
railway projects are track turnouts. Figure 4-18 shows an example of a turnout.

Turnouts are controlled remotely by signalling equipment usually supplled by a

45
 particular subcontractor, powered by certain supply equipment supplied by another
subcontractor, gives the opportunity for the rolling stock to change direction. Improper
resolution, implementation and validation of this intertace might lead to what is called
derailment during testing of the rolling stock and even later during operations while
hundreds or thousands of passengers are onboard.

Figure 4-18 Turnouts: typical railway projects' interíace

.3 Expert iudgment

An expert is a person or a group of people from inside or outỉide the project, enjoying a
specialized education/training, know!edge, set of skills, or having years of experience.

In railway projects it is common for an expert to be invited to analyze a certain issue.

These experts come usually from the suppliers' organizations with special testing
equipment for a detined period oftime to give some kind of technical advice.

.4 Strategies for Resolving Interíaces

Reaching what can be named as "Strategies for Resolving lnterfaces" will be handy for
practitioners; it can help in further brainstorming proper Solutions for interface issues.
Among these initial strategies generally seen in practice are the following:

46
• Elimination: or avoidance of a specitic interface. There can be a kind of
consensus that the less number of interfaces the better it is for the project. The
challenge ìs how an intertace can be eliminated. A major source of intertaces is
the way the project is being packaged and structured. For instance
subcontracting signalling equipment and telecommunication equipment to the
same supplier might reduce number of interíaces or at least make the interíace
as an internal interíace that should be handled at the subcontractor level.

• Coordination: this strategy is useful for topological type of interíaces. For

instance "coordĩnatỉon dravvings", which are drawings that show civil works and
the relationship between various equipment serving different Systems as they
come into close proximity or interíere with each other, are very useful to define
accurately the respective position of different pieces of equipment and avoid
conílicts in thĩs matter. A typical example is the interface between MEP
equipment and telecommunication equipment in an operation control room
(unpublished metro project documentation).

• Scheduling/ Sequencing: this is useful to resolve schedule-related interíaces,

activities that have to be done in a specific order mandated by some sort of
technical dependencies or resource limitations. For instance MEP work should
usually be íinished beíore other Systems equipment are installed to avoid
damages that can be caused to sensitive internal signal equĩpment that has to be
installed inside station control rooms.
Sequencing requires minimum understanding of critical path concepts. The
critical path is the longest Chain of activities that any single change in this path
will change the whole duration of the project. Thereíore, it is particularly
important to identĩfy any interíace located on the critical path of the project, as
some interíace resolutions might affectthe critical path.
Relying on project management team to resolve those interíaces is not

adequate, as they might over look certain technical constraints.

• Standardization: following standards and industry practices is common in railvvay

projects and sometimes mandated contractually even by the owner of the

project. Standardization helps avoid several interíace issues that might occur in

47
 the future and provides so to say a proven already implemented solution
elsevvhere. A typical example is in using screws, for instance for different
materiats and expected loads there are predeíined standards that specities the
thickness, the shape and the material of the screvvs.
Standardization strategy indudes copying a successíul Setup of an interface that
has been implemented in a similar project executed in regions that does not
tolerate with quality such as in west Europe region, thus it is common to hear in
a technical meeting, in the context of defending a certain resolution, this how

this interíace was resolved in United Kingdom in XYZ project.

• Transterring: this might be a very extreme strategy to shift all or part of the
responsibilities of intertace management to a third party or to another
subcontractor. Such transíer should be acknowledged by the owner of the
project.

.5 Simulation and Modeling

Using specialized software to simulate the movements of the train is typical in railway
industry. These types of software can provide a visual opportunity to resolve a certain
problem. Simulation is not always applicable, and deíinitely is very costly.

One of the emerging construction technologies is 4D modeling. "Four-dimensional (4D)

models link three-dimensional geometrical models with construction schedule data. The
visual link betvveen the schedule and construction site conditions is capable of
facilitating decision making duríng both planning and construction stages" (Chau,
Anson, & Zhang, 2004).

"4D modeling helps project teams analyze activity sequencing, improve constructability,
improve work flow for subcontractors, and visualize the construction work to be done"
(Emerging Constructìon Technologies - 4D Modeling, 2000).

According to Fischer (2006) "The difficulty and cost of creating and using such models is
currently blocking their widespread adoption".

48
4.3.3 Resolve Intertaces: Outputs

.1 Interíace Data Sheet(s) Updates

These updates may include:

• Further details to the location,

• Further elaborations on the physical aspects

• Further elaboration to the íunction,

• Data and iníormation required for interíace resolution,

• Design responsibilities,

• Supply responsibilities,

• Installation responsibilities,

• Testing responsibilities,

• Environmental constraints,

• Testing procedures,

• Further assumptions, and

• Comments.

.2 Interíaces Register Updates

These updates may indude:

• Resolution deadline,

• Further elaboration on the description of the interíace,

• Better estimate of the intertace priority, safety aspect, and

• Comments as necessary.

.3 Interíace-Related Procurement Decisions

lnterfaces' resolutìons will demand maybe special equipment, additỉonal supplies, and
speciíĩc expertise. Such procurement decisions should be escalated to project
management to go through approval processes.

49
.4 Project Management Plan Updates

Since most of interíace resolutions will create additional activities, change the current
duration estimates of existing activities, or require additional resources etc..., the
project time schedule, most probably, wilỉ undergo changes, and most probably these
changes will affect the critical path, thus the critical path should be recalculated.

These updates demand coordination betvveen the interface managementteam and the
project management team. This coordination can be either by having a representative
from the project management team attending the regular interíace review meetings or
through technical resolution meetings.

Not only the schedule might be affected, even the scope can be affected, and to avoid
scope creep proper coordination with project management people should be done.

4.4 Implement Interíaces Process

The process of communicating and directing the execution of the agreed upon interíaces'
resolutions. Implementing by this deíinition does not mean the direct doing (i.e. design of
interface, manuíacturing, and installation) as this is the job of the engineers and the various
project Iabor at their different levels. Hence, the responsibility of the interíace management
team is to communicate the resolutions of the interíaces to the design, manuíacturing, and
ínstallation peoplẽ and directing them to do it in the proper way as agreed upon earlier.

According to this meaning Implement Interýaces process takes place, once the different
interfacing entities agreed on a certain resolution and actions; during the design to make
sure that interface resolution is considered in the design, during manutacturing to make
sure that the resolution has been also considered in the manufacturing and during
installation as well.

Figure 4-18 shows the inputs, tools and techniques, and outputs for this process and the
data flow diagram is shown in Figure 4-19.

50

» lnterfaces Management Plan
• lnterface Data Sheet(s)
* lnterfaces Register
TOOLS ANDTECHNIQUES
• lnformation Distribution • lmplemented Interíaces
Tools
• lnterface Issues
• Communicatìon Methods

• Project Management Plan

* Approved Change Requests

Fỉgure 4-19 Implement Interýaces process overvievv

Pro ject
M an ag em en t

Figure 4-20 Implement Interýaces data flow diagram

4.4.1 Implement lnterfaces: Inputs

.1 Interiaces Management Plan

Refer to sections 4.1.3.1.

.2 Interíace Data Sheet(s)

Refer to sections 4.2.3.1 and to 4.3.3.I.

.3 lnterfaces Register

Referto sections 4.2.3.2 and 4.3.3.2.

51
.4 Project Management Plan

Project management plan is already described in section 4.1.1.1, The major important
part of the project management plan for implementation parts is the schedule; when
activities should be pertormed.

In practice daily, and vveekly reports are created to help guide execution of activitles on
the short run, since the big master schedule include a higher level of activities and
updating the schedule requires time.

.5 Approved change Requests

Approved change requests should be integrated into the project baseline, if not, it is
important to be communicated through the implementation process, as they usually
include expansion and reduction of scope. This will in turn íníluence all aspects of the
project including interíaces (PMI, 2008, pp. 93-99).

4.4.2 Implement Intertaces: Tools and Techniques

.1 lnformation Distribution Techniques

As mentioned above in Implement ínterỹaces process deíinition, it is about

communicating and directing the implementation, and not the physical execution of the
work. Thus iníormation distribution techniques are needed including electronic tools
such as the email, fax, and telephone, or hard copy exchange of intormation which is
still dominating the exchange of official letters between different entities.

Web application is more and more being used in projects, these web applications can
include scheduling, and reporting features, which can provide a complete and
interactive environmentíorcommunication and collaboration (PMI, 2008, p. 260).

.2 Communication Methods

Meetings, coníerencing, face to face conversations, presentations, and vvorkshops all

are examples of methods through which interfaces resolutions can be communicated

and directed.

52
 In this process communication skills are necessary. The selection of the method to
communicate iníormation should be carefully made. Different situations require
different communication methods. For instance face to face methods are much more
effective than any other methods, since body language is used (PMI, 2008, p. 260).

4.4.3 Implement Interíaces: Outputs

.1 Implemented Interíaces

This output is just to indicate that the implementation of interíaces once íinished,
should be communicated to be further validated. This completion of interface
implementation in practice means that a design has been prepared, or some equipment
has been manufactured/installed etc...

.2 lnterface Issues

While implementing interíaces issues will result. These issues can result from the
factors discussed in section 3.2 in this thesis such as delays in payments, or poor labor
skills, or weather conditions, etc...

Nevertheless, these issues can simply be due to unsuccessíul resolution which proved
to be unsuitable during implementation, or can be due to poor implementation

resulting from lack of labor skills.

These issues will become an input into Monitor and Control Interýaces process, so it can
be tackled. If the issue can be solved by revvorking the same resolution in a proper way,
this would be good otherwise Resolve Intertaces process may need to be repeated for
the interíace. Examples of such issues are shown in Figures 4-21 and 4-21 taken from a

metro project.

53
 Figure 4-21 Interíace Issues: a) installed signal is blocked by the platíorm screen door
installed by other subcontractor, thus the metro driver wiil not be able to see it during
operation in the righttiming b) signalling brackets designed and installed by MEP
subcontractor are not able to hold the load of signals supplíed by different subcontractor

Figure 4-22 Interíace Issues: a) signalling cables interíering with power cables, which is not
acceptable according to industry practices b) Sharp edges due to poor civil work might harm
power supply cables

4.5 Validate Interíaces Process

The process of ensuring that each interíace is completely resolved satisíactorily and
obtaining íormal acceptance. This process takes place not only during the testing phase of
the project but also during design, since designs should be reviewed and get approved. This
process includes quality control aspects as well as scope veriíication aspect. This means it
ensures the correctness and the completeness of the interíace. Thus inspections are
pertormed to make sure that implementation of interfaces contorms to requirements from
one side and to quality standards from another side. In this sense, it is the input to formalize

54
the acceptance of the deliverables, and might be a prior step to further integration tests as

well as full trial operations if exists.

Figure 4-23 shows the inputs, tools and techniques, and outputs for this process and the

data flow diagram is shown in Figure 4-24.

INPUTS TOOLS AND TECHNIQ.UES OUTPUTS

• lnterfaces Management Plan • Inspection • Validated Interíaces

1
• Interíace Data Sheet(s) 1 • Reviews • Interíace Issues

• Interíaces Register

• Project Management Plan

• Testing and Commissioning

Documents

Figure 4-23 Validate Interýaces process overvievv

Figure 4-24 Validate Interýaces data flow diagram

4.5.1 Validate Interíaces: Inputs

.1 lnterfaces Management Plan

Refer to section 4 .I.3 .I.

55
.2 Interíaces Data Sheet(s)

Reíerto sections 4.2.3.1, and 4.3.3.I.

.3 Interíaces Register

Refer to sections 4.2.3.2, and 4.3.3.2.

.4 Project Management Plan

Reterto section 4.1.1.1.

.5 Testing and Commissioning Documents

Testing and commissioning documents include but not limited to:

• Testingplans

• Testing procedures

• Requestíorinspections

• Documentation accompanying implemented Solutions

4.5.2 Validate lnterfaces: Tools and Techniques

.1 Inspection

For each interface, veriíication methods shall be identifìed. These veriíicatìon methods
can range from simple observation to complex dynamic tests. All these verification
methods should be ĩnduded in the testing and commissioning documents.

An inspection is the examination of a work product to determine whether it coníorms

to requirements listed in the IDS, standards, and to specihcations. The results of an
inspection generally include measurements and may be conducted at any level (PMI,
2008, p. 213). The results of inspection can be either acceptance with or without
comments, or rejection with comments.

Comments are usually expected to be revievved and performed if possible. Rejection

may be due to non-conformance to standards and planned ĩnteríace resolution, or

56
 basically because the originally proposed solution was not the best one. Thus, change
requests may be needed.

Inspections also indude íactory acceptance tests and type tests usually conducted at
the production íacilities of suppliers. Although these tests are costly in terms of
accommodating experts to attend those tests, but it worth it, to discover any
discrepancies beíore shipment.

.2 Reviews

lnterfaces have to be validated vvhile it is stiỉl on paper, before it is too late. If deviations
are found then, it will cost only the paper and deíinitely the engineering time of rework,
but this is incomparable to the costs of tinding deviations after manutacturing or even
installation.

Different degrees of comments will result from those reviews, some of which must be
implemented, and others are recommended. It should be stated if resubmission is
required of designs, procedures, or any othertype of document.

In railvvay projects, those reviews usually involve layers of reviewers and eventually
conduded by the review of a third party representing the owner.

4.5.3 Validate Interíaces: Outputs

.1 Validated Interíaces

As a result of successíul ĩnspections interíaces are validated, this can be íormal by

signing a kind of acceptance documents, especially if these inspections are carried out
by third parties.

.2 lnterface Issues

New interíace issues may be discovered during inspection and documentation revievvs.
These issues can result, basically because the originally proposed solutỉon was not
suitable, or because resolution was not properly implemented.

57
 other interíace issues may simply result due to other environmental tactors discussed
earlier in section 3.2. Regardless of the causes of these issues, these issues should be
raised in a timely manner, by any of the interíacing parties or by a third party the
consultant for instance.

Pictures are useíul means of communicating these issues. Figures 4-25 and 4-26 show
íurther examples of interíace issues taken from a metro project site.

Figure 4-26 !nterface Issue: cable ducts wíth Sharp edges creating improper environment for
inspection and maintenance of rolling stock in depot area

4.6 Monitor and Control Interíaces Process

The process of tracking identihed interíaces, identifying new interíaces, monitoring the
implementation and validation of interfaces, evaluating interíace management processes
effectiveness throughout the project, and managing changes to interfaces as they occur.

58
This process starts at the end of the detailed design phase and lasts until the end of the
project.

This process ensures that all change requests that may affect interíace deíínitions and/or
agreed upon resolutions have already passed through proper project change control
process.

Figure 4-27 shows the inputs, tools and techniques, and outputs for thĩs process and the
data flow diagram is shown in Figure 4-28.

INPUTS TOOLS AND TECHNIQUES OUTPUTS

• Interíaces Management Plan • lnterface Review Meetings • Project Documents updates

• Interíace Data Sheet(s) • Audits • Process Assets Updates

• lnterfaces Register • Interíace Reassessment • Change Requests

• Implemented and Validated • Variance Analysis

Interíaces

• lnterface Issues

• Project Management Plan

• Performance Reports

• Work Performance
Intormation
Figure 4-27 Monitor and Control lnterfaces process overview

59
 Figure 4-28 Monitor and Control Interýaces data flow diagram

4.6.1 Monitor and Control Interíaces: Inputs

.1 Intertaces Management Plan

Reíer to section 4.1.3.1.

.2 Interíace Data Sheet(s)

Reíerto sections 4.2.3.1 and 4.3.3.1,

.3 lnterfaces Register

Reíerto sections 4.2.3.2 and 4.3.3.2.

.4 Implemented and Validated Interíace(s)

Through this process the status of the interíace will be updated in the interíaces
register.

60
.5 Interíace Issues

Interíace issues resulting from improper implementation, and those discovered during
validation discussed earlier are communicated to the control process to be resolved.
Figure 4-29 shows another example of interíace issues.

Figure 4-29 Interíace Issue: desert cooler blocking a power control panel

.6 Project Management Plan

Refer to section 4.1.1.1,

.7 Pertormance Reports

Those structured reports are prepared by project management teams on a periodical

basis. They can be presented in different forms and can indude diagrams, updated
project schedules. In general they should show or refer to the following intormation

about activities:

• Planned and executed,

• Planned but not executed,

• Not planned but executed, and

• Planned íorthe next reporting period.

Most likely these reports will indude also a list of issues for each project sub System.

61
.8 Work Períormance lnformation

Non-structured iníormation resulting from execution of project activities, which is

usually collected either íormally or intormally, ừequently or randomly, through the
different communication means (PMI, 2008, p. 87).

This iníormation in relation to intertaces will be mainly, regarding the progress of

interíace resolution implementation, and the change of the interíace status. This
iníormation can be fed directly into the interíaces register and interíace data sheets as
mentioned above in the updates, and/or used in various reporting activities, and
recurrent and non-recurrent meetings.

4.6.2 Monitor and Control lnterfaces: Tools and Techniques

.1 Interíace Revievv Meetings

According to unpublished metro project documents, representatives from interíacing

parties will attend regular interíace review meetings (IRM) organized and chaired
by the PM (in principle on a weekly basis, to be adapted as necessary).

The purpose ofthe IRM can be summarized asfollows:

• Revievv of al! interíaces (not necessarily during the same session),

• Assess priorities,
• Report to the GC/PM the overall status,

• Control and monitor interíace resolution,

• Arbitrate, if necessary,
• Endorse changes, and

• Sign interíace key - points.

The IRM will be attended by the interíace management representative of each group.
As appropriate, it may be required a contract, cost control or engineering
representative to attend the meeting. The Interíace Register will be consequently

updated.

62
.2 Audits

The GC/PM and the owner (customer) will have the possibility, if they wish, to pertorm
any random audits for the purpose of making sure that intertace management is
properly períormed and the technical agreed resolutions are implemented.
Furthermore, compliance with schedule, cost and contractual matters would be of the
GC/PM and the owner concern.

Audits should not be always done externally; the intertace management team should be
concerned about the effectiveness of the whole interíace management, and can
introduce these audits during regular meetings or conduct separate audit meetings
(PMI, 2008, p. 310).

Proper planning of audits, and deíining the íormat and objectives is crucial specially that
people all over are usually sensitive to audits and try to resist it. These audits may
trigger updates to the intertaces management plan as well as to the organizational
process assets.

.3 Interíace Reassessment

As the project progresses, new iníormation is available, and project changes might be
introduced, thus new interíaces might be identified, and current interface detinitions
might turn to be not accurate and requires revision. Thereíore, interíace reassessment
should be regularly scheduled (PMI, 2008, p. 310).

Reassessment of intertaces saves the need to go back to Intertace Resolution Process.

Reassessment can result into new different resolutions that are more cost and time
effective.

.4 Variance Anaiysis

Variation from intertace baseline (interíace register and interíace data sheets) is

inevitable, so what is usually required in case of variation is a kind of systematic analysis

to measure the magnitude of variation. This will typically include documentation

63
 revievvs, examining the work períormance iníormation, observation, and other means
(PMI, 2008, p. 127).

Variance analysis might result in a need for some corrective or preventive measures to
control the variation. At [east should lead to a clear documentation of the variance, if
exists, as appropriate, so it can be íurther communicated.

4.6.3 Monitor and Control lnterfaces: Outputs

.1 Project Documents Updates

These updates may indude a complete revievv of the interface data sheet for a speciíic
interíace and additions reílecting the actual implemented resolutions.

Intertaces register will be fine-tuned, status of interfaces will be changed according to

performance intormation, new deadlines will replace old ones, and additional
comments may be added. Other project documents will be subject to updates including

but not limited to:

• Project baselines (scope, schedule, cost)

• Project logs (issues, assumptions, etc...)

• Punchlist

• Deviations list
• Risk register

.2 Process Assets Updates

PIM processes produce iníormation that can be used for íuture projects, and should be
captured in the organizational process assets.

The organizational process assets that may be updated indude, but are not límited to:

• Templatesíorthe Interíaces Management Plan, including interíace matrix,

• Interíace register and interíace data sheets,

• lessons learned from interíace management activities,

• Causes of variances,

64
 • Resolutions implemented and the reasons of those chosen resolutions, and

• Interíace dassiíications and categoríes.

At project closure, final versions of IR, IDSs induding resolutions as implemented, and
interíaces management plan, in addition to any supplementary documents should be
induded in the project documentation both as a hardcopy and soft copy if possible

(PMI, 2008, pp. 128, 312).

.3 Change Requests

According to PMI (2008, pp. 87) "when issues are found whĩle project work is being
períormed, change requests are issued which may modiíy project policies or
procedures, project scope, project cost or budget, project schedule, or project quality".
These change requests if approved, will have direct or ĩndirect effect on interíaces
definition, and/or resolution.

Change requests are not resulting only from issues, these requests can be needed as
preventive or corrective actions to eliminate a negative impact factor later in the
project.

Change requests initiators might be within the interíace management team, or external
even to the project, and can be optional or legally/contractually mandated.

65
ẲlilUUUUUUUUUUliilUiiỉl UUỈlUilUU

66
5 Conclusions and Recommendations

This thesis has first introduced interíace management principles as depicted in literature.
Then the link betvveen project management and interíace management was dearly
established from various perspectives. Then, íinally a practical approach was introduced to
períorm interface management within the framework of project management.

5.1 Conclusions

Railvvay projects are complex in nature and indude many interíaces, if not properly
managed will lead to issues, which will consume time, costs, and resources, and will affect
the overall project owner/customer satisíaction. A better understanding and increasing
avvareness of IM is a íirst step tovvards proper performance of interíace management
processes.

IM shall be no longer a hidden aspect of project management. Linkage with project

management should be made dear. This thesis has emphasized the strong correlation
betvveen IM and project management. Overall project pertormance will deíinitely be
rectiíied if IM is not ignored and clearly linked to project management, through structured
process and appropriate assignment of roles and responsibilities.

A complete interíace management process starting from preliminary design and ending wíth
project handover phases has been created in this thesis. This process used the same
language of project management standards, and showed solid, and verihable interlỉnks with
project management.

PIM proposed processes are iterative in nature. These processes should start as early as
possible; literally as soon as the project requirements are deíined. Interíace resolutions
should be built in the design and not only inspected in testing. Many issues are resulting not
only because of the lack of interíace management, but also due to the late start of ìnteríace

management activities.

67
A substantial amount of IM knovvledge is stored in experts' minds and projects'
documentation. This valuable knowledge should be properly captured and structured to
contribute to what can be called in the future "Intertace Management Best Practices".

5.2 Recommendations

5.2.1 Exploration of Intertaces Resolution Strategies

This thesis tried to develop a kind of strategies for resolving interíaces, such as
standardization, elimination, and coordination. A deeper research on this part by surveying
and interviewing experts then analyzing the outcomes statistically will help build a general
common practice in resolving interíaces.

This can evolve to a kind of situational resolution to interíaces; under certain conditions and
with certain types of interíaces, a particular approach is to be recommended to resolve the
interíace, and predict what kind of issues may result.

5.2.2 Surveying Interíace Management Awareness

Interíace management awareness, among engineers and practĩtioners as well as managers

and all project stakeholders, is still questioned. Observations show that there is no
consensus on what interíace management includes. Engineers are complaining of poor
interíace management, but there is no common ansvver on how can things be improved.

A comprehensive questionnaire can be prepared, based on a careíul and deep literature

review. This questionnaire can be distributed to as much people as possíble including all
levels of projects' personnel from different technical backgrounds. The results can then be
compiled and analyzed to come up with frurtful conclusions.

5.2.3 Development of IM Tools

IM is still lacking specialized tools to íacilitate interíaces identiíication, resolution, and

tracking. Some tools were proposed in this thesis in an abstract manner rangingtrom simple
ones like interíaces matrix, and a complex one such as simulation and 4D modeling. A
dedicated research for one of these tools or the development of a completely new tool, like

68
for instance the house of quality in quality management, the critical path method in project
management, etc... will be very handy.

69
R e teren ces

Alarcon, L. F., & Mardones, D. A. (1998]. Improving The Design-Construction Interíace.

IGLC. Guaruja, Braziì.

Al-Hammad, A. (2000). Common Interface Problems Among Various Constructìon

Parties. Journal ofP erform an ce o f Constructed F acilities, 71-74.

Bõttger, c., & Wanner, K. (2009, November). Viele Projekte, viele Schvvierigkeiten. ppp
lnfrastructure, pp. 10-13.

Browning, T. R. (1998). Integrative Mechanisms for Multiteam Integratíon: Findings

from Five Case Studies. In Systems Engineering, Voỉume 1, Issue 2 (pp. 95 -1 1 2 ). New
York, N.Y.: John Wiley and Son, Inc.

Center for Chemical Process Saíety, American Institute of Chemical Engineers. (2004,
March 1). Interíace Management - Eíĩective Communication to Improve Process Safety.
Safety A ỉerts.

Chau, K., Anson, M., & Zhang, J. (2004). Four-Dimensional Visualization of Construction
Scheduling and Site Utĩlization./ouma/ o f Construction Engineering an d Management,
ACSE, 598 -6 0 6 .

Chen, Q. (2007). An Object Model Framework for Interíace Management in Building

Iníormation Models. Dissertation . Virginia: Virginia Polytechnic Institute and State
University.

Chen, Q., Reichard, G., & Beliveau, Y. (2006). An Interface Object Model for Interface
Management in Building Construction. European Conference on P roductand Process
Modeling, (pp. 119-126). Valencia, Spain.

Chen, Q., Reichard, G., & Beliveau, Y. Quly, 2007). Interíace Management - A Facilitator of
Lean Construction and Agile Project Management. IGLC, (pp. 57 - 66). Michigan, USA.

Emerging Construction Technologies - 4D Modeling. (2000). Retrieved May 7, 2011, from

Devision of Construction Engineering and Management, Purdue University:
http://rebar.ecn.purdue.edu/ect/links/technologies/other/4d.aspx

Fischer, M. (2006). Introduction to 4D. Retrieved May 7, 2011, from 4D CAD Research:
http://www.stanford.edu/group/4D/projects/projects.shtml

Godinot, M. (2003). The Work Breakdown Structure Matrix: A Tool to Improve Interíace
Management Master T hesis. National University of Singapore.

Huang, R.-Y., Huang, C.-T., Lin, H., & Ku, W.-H. (2008). Factor Analysis Of Interíace
Problems Among Construction Parties - A Case Study OĨIAKĨ. Ịournal o f Marine Science
and Technology, Vol 16, N o .l, 52-63.

71
Lai, M. L. (2005). Application of Construction Interface Management Master T hesis.
National Chiao Tung University.

Morris, p. w. (1983). Managing Project Interiáces - Key Points for Project Success. In D.
I. Cleland, & w. R. King, Project M anagement H andbook (pp. 16 - 56). New York: John
Wiley& Sons, INC.

National Aeronautical and Space Administration. (2007). NASA Systems Engineering

Handbook. Washington, DC.

Nooteboom, u. (2004, August). Interiàce Management Improves On-time, On-Budget

Delivery of Mega Proịects./PTOnline.

Pavitt, T. c., & Gibb, A. G. (2003). Interíace Management within Constructìon: in

Particular, Building Facade.Ịournal o f Construction Engineering and M anagem ent, 8-15.

PMI. (2008). A Guide to the Proịect Management Body ofK now ledge - Fourth Edition.
Pennsylvania, USA: Project Management Institute, Inc.

Shirley, Richard R.; Stevens, Ịames H.; P.E.; D.Alistair, Strachan; Engineering, Mustang;
L.p. (2006, October). Complex Projects Need Coordination. Harts E& p.

Standish Group International. (1995). Chaos Report.

VVideman, R. (2002). Wideman Comparative Glossary o f Project M anagement Terms.

72
nuĩ HHHHnHĩ HHnnr
 i want morebooks!
B u y y o u r b o o k s fa s t a n d s t r a i g h t f o r w a r d O n lin e - at o n e o f w o r l d 's
í a s t e s t g r o w i n g O n lin e b o o k Stores! E n v i r o n m e n t a l l y s o u n d d u e to
P rin t-o n -D e m a n d te c h n o lo g ie s .

Buy your books Online at

www.get-morebooks.com
Kaufen Sie Ihre Bũcher schnell und unkompliziert Online - auf einer
der am schnellsten vvachsenden Buchhandelsplattíormen weltweit!
Dank Print-On-Demand umvvelt- und ressourcenschonend produzi-
ert.

Biicher schneller Online kauíen

www.morebooks.de
VDM Verlagsservicegesellschaít mbH
 ũ
FSC
www.fsc.org
MIX
P a p ie r a u s verantvvo rtungsvollen Q u elle n
P a p e r from re sp o n slb le so u rc e s
FSCs C105338

Printed by Books on Demand GmbH, Norderstedt / Germany