Interface Documentation

Once an interface is identified and approved, the information related to each interface must be defined and documented. Relevant interface information includes the interface characteristics, involved parties, deadlines and needed documents. In this chapter is explained what interface related information should be obtained and how and where this information should be documented.

7.4.1 Registers and forms

Each indentified interface gets an separate ID-number and will be placed in the IBS and IR. In here, all relevant information about the interface is placed. Interface Agreements (IAs) are used to make formal agreements about the exchange of information around an interface. Each interface could have multiple IAs. In these agreements Action Items (AIs) could be submitted which are necessary to elaborate the interface. These AIs, which are less formal, are small tasks which have to be executed by the responsible person within a certain time frame. Formal Change Requests (CRs) could be used to propose changes to an interface or IA. As last, Interface Control Documents (ICDs) could be used for the elaboration of complex interfaces. In these documents the interface ‘solution’ is described and elaborated, and a verification plan is included for the design of all objects attached. Simpler interfaces are only elaborated in the design documents of the SBS objects itself.

73

Technical University of Delft Ballast Nedam Interface Register

All interfaces will be placed in an IR. A well-managed IR provides access to up-to-date and accurate information. Availability of interface information ensures that team members are able to review items more rigorously, and make decisions quickly and with more accuracy and confidence. The information that needs to be captured in the IR is the following:

Interface ID: ID number of the interface; Interface title: Interface title;

Interface description: Short description of the interface; Type of interface: External, Inter- or Intra-disciplinary; Status: Open, In progress or Closed; Object –IDs: ID number of the objects attached; Objects involved: Title of the objects attached; Involved contractors: Name of the parties involved.;

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

Responsibility: Name of the responsible interface coordinator/contractor;

Risk: Risk factor; high/medium/low.

Table 2: Example of interface register.

Interface Register

ID Title Description Type Status Object ID

Objects Involved contractors

Interface Agreement ID

Req. ID Resp. Risk

For each interface, a separate page can be added in where additional information, constraints and comments could be placed. In here also the verification method is described, as well as the document ID-numbers in where the interface solution and verification of both components is elaborated. More information about the implementation of the IR and the additional interface pages can be found in Appendix E.

Status

The status of an interface is either open, in progress or closed. When an interface is identified but no agreements are made yet to elaborate the interface the status will stay on ‘open’. The status will change to ‘in progress’ when agreements have been made about the interface solution, or the exchange of specific interface information, including clear responsibilities and due dates. The status will change to ‘closed’ at the moment the interface solution has been verified for both components attached, as well as the integrated part. During fabrication and construction the interface still exist, but the ´closed´ status indicates the interface has been taken care off in the design of all objects attached. The interface manager will monitor all interfaces and when the design of an object changes, after the settlement of an interface, the status could be changed back to `Open` or `In progress`.

Interface requirements

For simple interfaces an interface requirement could be derived. Especially when this part of the project will be outsourced to a sub-contractor. For each interface maximum one requirement could be derived and listed in the RBS. More requirements could lead to confusion and conflicting requirements. By deriving a SMART requirement of the interface solution, the interface is uncoupled. Think for instance of a wall and cables which

74

Technical University of Delft Ballast Nedam both have to placed parallel to a road. Contractor A could be assigned to place the wall between 3 and 4 meter from the road, while contractor B has to place his cables between 1 and 3 meter from the road. By adding these requirements to the component specifications, the interface is uncoupled for both parties.

Risk

The importance of an interface depends on the risks attached. Interfaces represent risk to the project, some more than others. The interface coordinators must work with their project team to identify interfaces they feel represent high-risk, and add additional management and oversight where necessary. In paragraph 7.4.3 is described what factors should be taken into account by the assessment of an interface risk. Afterwards, in paragraph 7.5, several strategies are proposed to uncouple these high-risk, and often complex, interfaces. Interface Agreements

IAs are used to document and track the exchange of information and other deliverables between the contracting parties in a project. IAs result in the exchange of project information generated by one party, that is needed by another party to continue with its scheduled project tasks. This project information could be delivered in the form of engineering drawings, specifications, design reports and calculations, equipment details, project schedule information, etc.

These forms will only be used for inter-disciplinary and external interfaces. An IA is a formal form which documents the exchange of information and deliverables, which are measurable and bound by a time frame, between two parties. The deliverable is acknowledged and agreed upon by two contracting parties, both a requester and a responder. During project execution contractors could be either requester or responder, depending on their responsibility to the interface. In an IA the following information is provided:

 Contracting parties, participants and their roles;  Attached interface and objects;

 Required information or deliverable(s);  Responding document(s);

 Action items;

 Need date of the agreement;

 Finish date when the interface conditions have been met.

In short, the requester fills in an IA form and requests for the delivery of specific interface information within a certain time frame from another contractor. The responder has to sign this agreement if the requirements can be met, which makes the agreement formal and frozen. When the delivery date cannot be met, a delivery date, different from the request date, could be proposed. When consensus between the contractors cannot be reached easily, the interface can be flagged as high-risk and/or the status may stay on ‘open’, which means the interface will be discussed in the upcoming interface meeting.

Action items

Each IA could have several AIs. These actions are small tasks which have to be executed in order to fulfill the agreement. An example of an action could be “look up the required free space for maintenance of pipe Z, in Manual X”. These action are less formal than IAs, are much shorter in duration, and are designated to a single project member who has to fulfill this action within a certain timeframe.

75

Technical University of Delft Ballast Nedam Change Requests

When an agreement has been reached the agreement is formally frozen, which means a baseline has been formed. If after this phase modifications in the design are needed to any of the attached objects, or due dates cannot be met, a formal change request has to be filled in. The configuration management team assesses all proposed changes and monitors the project’s overall progress. Before the design, or an agreement, can be modified, first all consequences for all involved parties and possible options have to be explored.

Interface Control Document

ICDS could be used as extra document for the elaboration of complex interfaces. In this document both parties could work on the interface solution, document all interface characteristics, and describe the process which led to the interface solution. In addition, a verification plan should be added to verify the developed solution.

7.4.2 Interface Responsibilities

One of the major causes of integration issues is the lack of awareness about the ownership and responsibilities regarding the interfaces. In the IAs is specified what specific information has to be exchanged, and what the roles and responsibilities of all interacting parties are. However, before an IA can be developed it has to be clear who the responder and who the requester is regarding the information.

A responsibility matrix, like the RASCI-matrix, could be used to visualize the roles and responsibilities belonging to each interface (Rose, 2008). By using this matrix the responsibilities of the interconnecting parties involved in the execution of the interface are identified. RASCI stands for Responsible, Accountable, Support, Consulted and Informed, respectively. The description of roles for the interface execution is as follows:

 Responsible: The party responsible for the interface overall performance, and approves the accuracy of interface characteristics (i.e. the requester of interface information or deliverables).

 Accountable: The party, who generates the IA, and has the legitimate authority to approve the adequacy of the work, and makes the final decision to close an agreement.

 Supportive: The party who gives support to facilitate the process accomplishment (e.g. the party who may have to grant the other parties access to the site).

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

 Informed: The parties who need to know the status of the IA, in order to help them better schedule their own work or the work of others.

The purpose of using RASCI matrix is reducing risk by increasing the visibility, and eliminating ambiguity about the roles and responsibilities regarding the execution of each interface. A sample of a RASCI-chart is shown in Table 3. The left column includes interface IDs, and the top row includes all the project members/contractors who may be involved in an interface. The cross-sectional cells indicate the responsibility of each party regarding an each interface, if there is a relationship.

Table 3: Sample of RASCI-Chart

Owner Interface

Manager

Contractor A Contractor B … Contractor i

RV1 R A S, C I

RV2 A, S R C

RV3 I A R C

…

76

Technical University of Delft Ballast Nedam Leading versus intersecting objects

In order to assist in filling in the IAs and RASCI-chart, and to determine which party is the requester and which the responder, one could look at the interacting objects. It is often possible to make one object ‘leading’ and the attached object ‘intersecting’ regarding an interface. It could be agreed that an intersecting object must follow the design of the leading object. The designer of the leading object, in this case, will be the responder in the IA. In other words, the designer of the intersecting object requests information from the leading object’s designer.

Looking at the type of dependency, it becomes clear that two objects, involved in an interface, could be one- way dependent or interdependent. One-way dependency means one of the objects is dependent on the other, but not the other way around. For these interfaces, which can be determined by experience and intuition, is it self-evident which object is ‘leading’. Think, for instance, of a road sign which has to be placed on a bridge. If the design of the bridge changes, the place and details of the road sing could change as well. However, it will not be the other way around. The ‘leading’ object has to provide the ‘intersecting’ object with information. Unfortunately, many objects have a strong interdependent character which means the objects are both depending on the design of each other, and cannot be uncoupled that easily. Making a choice whether an object is intersecting or leading regarding an interface is therefore not always as easy to make. These objects usually need multiple iterations in their design to come up with a sufficient design for both sides. Especially in these cases confusion easily arises about the roles and responsibilities regarding the interface. Think, for instance, of a concrete basement and equipment which have to be placed within. Will the size of the basement determine the type and exact dimensions of the equipment, or is it the other way around?

Aspects like local lifecycle costs, critical objects and design planning could assist in appointing the roles regarding an interface. Looking at the local lifecycle costs one could look at the costs attached to the objects, and the costs to make modifications to the design. The party responsible for the more expensive object could be made leading. In that case this party will have the privilege to determine the exact parameters of the design related to that interface (within the solutions space of the requester).

Another method to assist in determine the ‘leading’ objects is to look out for critical objects. Once the interfaces have been located, it is often possible to determine these critical objects. Looking at the N²-chart, it becomes obvious some objects have more interfaces than others. An object which has relatively many interfaces with other objects could be stated as critical. It is advised to make those objects leading in their interfaces with other objects when possible. This means the design team of that object is the provider concerning those IAs, and will be ‘consulted party’.

The leading coordinator of critical objects has to take into account that one IA could have consequences for another. Coordinators have to look closely at all interfacing partners, and check what interfaces are the most important and have to be worked out first. By being the responder the design team can closely monitor the dependencies of all outstanding interfaces of the object.

As last, the design planning could play a role in assigning the main roles concerning an IA. When discussing the interfaces it could become clear that two design teams, which have an interface, design their objects at different points in time. These differences are mainly due to construction constraints. In these cases, it is advised to make the object which is designed first the responder of the interface information, where possible. The main reason for the distinction in leading and intersecting objects is to reach clear and unequivocal agreements between parties. In the case an object cannot be made ‘leading’ or ‘intersecting’, it usually means

77

Technical University of Delft Ballast Nedam the objects have a strong interdependent character, and therefore need a lot information from one another. When no consensus can be reached about the direction of the flow of information, the content of this information, or the due date this information has to be delivered, an IA cannot be developed. When it is not possible to uncouple an interface with an IA, the interface will keep the status ‘open’ and could be flagged as medium or high risk. This interface will then be discussed again in the next interface meeting, in where consensus has to be reached. Strategies to assist in the elaboration of these complex interface are discussed in chapter 7.5.

7.4.3 Interface risk assessment

In general, interfaces represent risk to the project. However, some carry more risk than others. Only the interfaces which contain a high risk for the project, and therefore, have a high potential to cause delays or additional costs, require close coordination, control and management. Extensively document and manage every single interface should be avoided, as it would cause the system to quickly become overburdened with information.

With hundreds of interfaces which have to be managed, how can these be differentiated from one another? How to ensure the right interfaces are monitored at the right time? In managing interfaces the Pareto-principle applies, which means 80% of the problems are caused by 20% of the interfaces (Varghese and Senthilkumar, 2010). Therefore, it is important the IM team takes proactive measures to identify these problematic interfaces as early as possible, and to keep track of the information exchanges at these interfaces. Interface coordinators must work with their team to identify interfaces they feel represent high-risk. In addition, it is important that an interface can be flagged as high or low risk at any given moment. Some interfaces carry no risk at the beginning of the project, but could become problematic during the course of the project. When a risk is recognized by a design team, it should immediately be flagged as such. This ensures that all involved parties become aware of this risk instantly, and can give the interface the attention it requires.

Types of interface risk

Basically three main types of risks can be distinguished which are financial, schedule and performance risk. Schedule risks are those risks associated with the adequacy of the time estimated and allocated for the design and construction activities of the project. Financial risk is the risk associated with the ability of the project to achieve its life-cycle cost objectives. As last, performance risk is the risk associated with the evolution of the design affecting the level of performance, necessary to meet the stakeholder expectations and technical requirements.

Schedule risk

When objects are dependent, it means one object needs information from another, in order to continue with its design. However, when this information is not known in time conflicts could arise. If, for instance, the EE needs to put his cables through a concrete wall, the CE has to know the exact location and dimensions of these cables. Issues with this interface often occur in infrastructure projects. The EE does not know exactly where his cables will go through at the time the CE wants to know this information.

Therefore, most of these schedule risks can already be identified during the preparation of the IAs. In the early workshops most interfaces and required information have been identified. In here, consensus has to be reached about the content, direction of flow and delivery dates of that information. The requester asks for interface information within a certain time frame. When the responder cannot deliver this information within that time frame delays could occur. The interface could be flagged as high or medium risk and will be discussed

78

Technical University of Delft Ballast Nedam in the upcoming interface meeting. Some interfaces may have a major impact on the critical path when their

In document Interface Management in multidisciplinary infrastructure project development (Page 89-96)