Interface Control

Monitor and control of the interfaces is necessary to keep an eye on the overall progress, to prevent and solve integration issues, and to verify the design solutions during the whole project lifecycle. The IM team is responsible for monitoring the interface data as stated in the IR, including the corresponding IA due dates. The IM team should organize regular and ad-hoc interface meetings, in where the progress of all high risk and open interfaces is discussed.

The IR, IA register and AI register are used to monitor all interfaces. IAs and AIs which are close to their due date could receive a electric notification of alert. All involved parties should be aware of the work load, progress and potential issues (e.g., deliverables are delayed or contractors are not communicating). During the project it is important that all information is easily accessible. The registers and reports should provide the project team with the data they need to continually monitor the progress.

The client and interfacing parties should be warned in case of a forecasted delay or any other interface related issue. In addition, the IM team is also responsible for the verification of both components regarding the interface solution. The design should meet the interface requirements, before an interface can be closed. Next to the IM team, also the CM team, project planning, and the risk management department are involved in the elaboration of interfaces, and play a major role in monitoring and control these interfaces.

7.7.1 Configuration Management

CM is a management discipline, applied over the product’s life cycle, that controls and monitors changes which could affect performance, functional or physical characteristics. The CM team is responsible for the

83

Technical University of Delft Ballast Nedam management and control of the overall progress of the project by controlling, approving and rejecting changes during the design and construction phases of the project. Under the scope of CM falls document management, baseline control and change management.

Document management

Under the principle of CM, all documents generated within a project are closely managed, tracked, and archived. The process includes tracking and archiving all document changes, versions, and approved communications, which is necessary to avoid the inclusion of document changes without following a formal document approval process (PACO, 2010).

Baseline control

The CM team defines multiple milestones in advance, for each subsystem. These milestones in design have to be achieved after which the design will be ‘frozen’. Next to these defined milestones, the design will also be frozen after each formal design step (i.e. after the conceptual, preliminary and detailed design phase). The IAs, with due dates for the delivery of interface information, are also frozen in order to meet the deadline of the interface milestones. These (frozen) moments are called baselines.

CM gives insight in the differences in level of development between the several sub-systems, and what consequences these differences have. When one sub-system proceeds to the detailed design phase while another sub-system is still at conceptual design, huge problems could occur if their interfaces are not worked out well. The CM team monitors and steers this process where necessary.

Change management

Changes are and will continue to be an inevitable part of the design and construction of any project. Throughout the design phase, interface baselines are controlled to ensure that changes in the design of components have minimal impact on other components with which they interface. Formal CRs could be submitted in order to adapt the design of an object, or agreement, which have been frozen. CRs also have to be submitted to adapt the content or due date of an IA. Changes could be proposed to optimize the design, but could also be the results of incompatibilities, external changes, or unexpected design deficiencies. Configuration control maintains integrity by facilitating approved changes and preventing the incorporation of unapproved changes into the items under configuration control.

The CM section has to study the consequences of such a change and will approve or reject the request. In here, it is important to consider both the consequences of the change, as well as the impact of not making the change, especially as the system matures. The effort and cost associated with accommodating changes increases rapidly as the design matures. The critical objects require extra attention since these objects have lots of interfaces. Modifications of a design leading to changes in a critical object could lead to a ripple effect, affecting more and more objects.

7.7.2 Risk management

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

84

Technical University of Delft Ballast Nedam interfaces. Green indicates everything goes well and that the interface is on target for the completion date. New and open interfaces could be made green when agreements have been made regarding this interface. Yellow indicates there are some concerns and issues that need to be addressed, while red indicates major issues and high risk of not achieving. A colored system is visually strong and can be used as a reporting tool to management and stakeholders, for an impression see Figure 36.

SBS 1100 1200 1300 1400 1510 1520 2111 2112 2113 2121 2131 2132 2133 1100 1200 1300 1400 1510 1.8 1.11 1520 1.14 2111 2112 2113 6.5 2121 1.4 2.1 2131 5.1 2132 3.8 2133 3.3 17.1

Figure 36: Impression of a N²-chart with high-risk interfaces

The IR provides the ability to flag interfaces as high risk and revert back to low risk at any given moment. An interface which does not represents risk during one phase of the project, may do so during another phase. On a frequent basis (e.g. every two weeks), the chart will be updated with additional high-risk interfaces, and all open and new interfaces which have been addressed could be removed.

All high risk interfaces should also be included in the risk register, in where the risk managers will threat the risk as any other. This means the risk will get a quantification, and in consequence prevention measures will be explored, as well as mitigation strategies. Risk mitigation is very important and without reporting high risk interfaces, the risk manager is potentially making decisions without the complete picture.

7.7.3 Project planning

When the most crucial interfaces have been identified, extra control is needed to prevent potential issues with these interfaces. An interface delay could impact a critical path activity in the overall project schedule, leading to a delay of the project. Therefore, next to the visualization of all high risk interfaces in the N²-chart, also the schedule impact of these interfaces have to be monitored systematically by all stakeholders. Each project stakeholder should be able to integrate high risk interfaces, as managed in the IM system, as key milestone activities within its respective organization’s project schedule.

In Figure 37, the process of schedule integration is simplified by three main aspects which are the interface register, the N²-chart and the project and discipline design programmes. In the IR all interfaces are displayed. The interfaces which are flagged as ‘high risk’ are transferred to the N²-chart, in where they become easily visibile for all stakeholders. For each high risk interface a milestone activity is established, which will be integrated in the project and discipline desing programmes. This is a dynamic process since the high risk interfaces can be flagged at any time of the project life-cycle. Regurarly the project schedules will be updated by the newest updates of the IM system.

85

Technical University of Delft Ballast Nedam

Figure 37: Integration of project schedule with interface milestones

The integration of the project schedule with the interface milestones will add transparency to the process and increases the visibility of important interface due dates. As part of the project planner’s regular analysis of the critical path, any impact caused by an interface, or impacting an interface is identified, assessed and reported back to the interface coordinator. The interface coordinator on his turn must evaluate options to avoid or mitigate the schedule impact of that specific interface within their project schedule. The project planner and interface manager collaborating facilitates that all impacts on the project schedule caused by an interface, or impacting an interface, will be monitored and controlled. Properly executed, schedule integration ensures that interface related schedule risk can more easily be identified by each contractor and the project owner, and that an efficient process exists to resolve interface related schedule issues.

7.7.4 Verification

As part of interface control, the design of all components related to an interface, have to be verified. During validation and verification activities, multiple components are checked out as integrated subsystems or system. For each interface, both the components attached to that interface, as well as the integrated system, have to be verified before an interface can be closed.

Physical interfaces could be verified by checking the design drawings on inconsistencies. Clash detection software in 3D modeling programs could be used to automate and ease that process. When this software is not available, drawings could be checked manually on inconsistencies. Preferably, the verification method is already be agreed upon at the moment an interface is set-up, to avoid confusion about it in later phases. Functional interfaces and more complex interfaces cannot always be verified by checking drawings on inconsistencies. The involved parties should discuss the verification method in advance. Depending on the interface, a separate verification plan could be developed which could include calculations, tests, drawing, prototypes, reports, etc. It should be clear who is responsible for the elaboration of what part of the interface, how both parts will be verified, how the integrated (sub-)system will be verified, and, as last, by who and when the interface will be verified.

The elaboration of an interface, including the verification plan, could be documented in a ICD, but may also be included in the design documents. The ICD or design documents show the specific solution to an interface, of both sides, and entail the verification details. The ICD and other verification documents can be communicated to the owner, or other key stakeholders, if necessary. When the interface is complete, the interface manager can close this interface in the IR. The interface manager is the only person who can adapt the status of interfaces in the IR.

7.7.5 Conclusion

Monitor and control of the interfaces is necessary to keep an eye on the overall progress, to verify the design solutions, and to prevent and solve integration issues during the whole project lifecycle. The IM team is

86

Technical University of Delft Ballast Nedam responsible for monitoring the interface data as stated in the IR, including the corresponding IA due dates. They should organize regular and ad-hoc interface meetings, in where the progress of all high risk and open interfaces is discussed. The IM team is also responsible for the verification of the interface solution. It should be clear how both components will be verified, how the integrated sub-system will be verified, and, as last, by who and when the interface will be verified.

The CM team is responsible for the management and control of the overall progress of the project by controlling, approving and rejecting changes during the design and construction phases of the project. The CM team also defines multiple milestones in advance, for each subsystem, and gives insight in the differences in level of development between the several sub-systems, and reveal what consequences these differences have. All high risk interfaces are visualized in the N²-chart by a traffic light system. All these interfaces will be included in the risk register, in where the interface is monitored and controlled by the risk manager. In addition, the schedule impact of these interfaces have to be monitored systematically. For each high risk interface a milestone activity could be established, which will be integrated in the project and discipline desing programmes, and monitored and controlled by the project planners.

In document Interface Management in multidisciplinary infrastructure project development (Page 99-103)