Managing the complexity of engineering interfaces through ecollaboration

Abstract

Within large construction projects involving several work packages in different development stages (e.g., some in the design phase, others awarded to multiple contractors for execution), a key project success factor is the proper management of engineering and construction interfaces across all the involved actors. Ineffective interface management is often responsible for cost overruns and schedule slippage for large development projects, due to delays in commissioning and excessive rework.

Interface items are all those elements, within the scope of work under the responsibility of a contractor or an operator department, which might affect or be affected by the scope of work covered by other contracts. The interface management process defines how engineering and construction interfaces are identified, planned, executed, and controlled so that potential impacts on the design, cost, and schedule of the project are minimized.

A key aspect of interface management is the ability to effectively communicate, across all involved parties, all details related to an interface, including requirements, technical specifications, and potential issues. It is important that the communication channel is promptly established, the proper information is exchanged, and all involved parties acknowledge that they fully understand the interface requirements so that they can proceed with the execution of their scope of work.

A traditional approach to implementing interface management is based on maintaining a large interface register, where all interfaces are listed together with all the affected parties, and updating it every time new interfaces are identified. Within oil and gas projects, it is not unusual to manage several hundred up to thousands of interfaces. Therefore, an approach based on a Microsoft Excel register and the exchange of emails cannot be sustained throughout the duration of the project.

For this reason, an approach based on eCollaboration proves to be much more effective when dealing with large numbers of interfaces. Through eCollaboration, an electronic workflow across different companies can be set up on the web. The operator can coordinate the workflow in order to ensure that affected contactors are put in contact with each other, requested information is promptly exchanged, and interface issues are addressed and closed within an appropriate time limit, therefore minimizing the impacts on the overall project.

This paper will describe the eCollaboration approach and some practical applications to oil and gas projects, highlighting the benefits compared to the traditional approach: in particular, the ability to track the status of several hundred interfaces and to cross-reference their impact on the activities and cost elements of the project; the ability to identify bottlenecks, and to expedite the exchange of information on those interface items whose delay could affect the schedule of the project; and the ability to anticipate any misalignments between the operator and the contractors in the early stages, therefore minimizing the variation orders needed to solve the issues.

Introduction

When dealing with large capital projects, such as the construction of offshore and onshore facilities in the oil and gas industry, the owner/operator can take advantage of a range of contracting options, including:

  • Issuing a large engineering, procurement, and construction (EPC) contract to manage most of the scope of work of the project; and
  • Defining a number of smaller work packages, to be awarded to engineering and construction contractors.

The first option is usually more expensive, since most of the project risks are transferred from the owner to the EPC contractors; for this reason, EPC contractors usually include large cost contingencies and mark-up. Moreover, when dealing with megaprojects of several billion dollars, it is uncommon to find a single contractor that will take on all the risk and capital cost of the initiative. The second option, in addition to being less expensive, gives the operator more influence and control over the project; for this reason, it is becoming more and more common in the oil and gas industry.

The multiple work packages option implies that the operator has the ability to coordinate the execution of a number of different contracts, all contributing to the overall scope of work of the project. Exhibit 1 shows an example: On the left side of the figure, the product that has to be developed—a Floating Production Storage and Offloading system (FPSO), an offshore vessel equipped with topsides facilities and storage capabilities, collecting oil and gas from a number of producing wells—has been broken down into a number of components; in the upper part of the figure, the work breakdown structure is shown, including activities such as engineering design, procurement of material, construction, and installation. Each contractor (e.g., Contractor 4) has been awarded a scope of work comprising the execution of a number of activities (e.g., engineering and procurement) on one or more components of the product (e.g., flowlines from the wells to the FPSO topside facilities).

Exhibit 1—Sample contract breakdown structure for an offshore project

In this scenario, it is clear that there are many interfaces between contractors (i.e., portions of the scope of work of each contractor that might influence the scope of work of other contractors). This might happen both in terms of the product being developed (e.g., ensure that each flowline from the producing wells developed by Contractor 4 will smoothly connect to the topsides facilities developed by Contractor 2) and in terms of activities (e.g., ensure that no issues related to the engineering drawings prepared by Contractor 4 influence the execution of the scope of work of Contractor 5 for construction).

With this approach, it is the responsibility of the operator to ensure that all the interfaces between contractors are identified, documented, acknowledged, executed, and controlled in a timely manner. Interface issues are responsible for up to 20% of total installed costs (Nooteboon, 2004); therefore, a well-established interface management process is a critical success factor for large capital projects.

Interface Management for Large Construction Projects

In large construction projects, it is not uncommon that several hundred up to a few thousand interfaces are identified between project stakeholders, including:

  • Interfaces between contractors (e.g., ensuring that a connection joint between subsystems developed by each contractor smoothly fits at installation time), which need to be put in communication with each other by the operator of the project; and
  • Interfaces between contractor and operator (e.g., ensuring that design choices by one contractor, which lacks the full understanding of the project scope, do not affect the performance targets of the project as stated by the operator).

Exhibit 2 shows a sample identification of interfaces between two work packages (Umbilical and FPSO) and, for each identified item (labeled 1 to 12), the affected contractors during each project phase.

Exhibit 2—Identification of interfaces between two work packages

In any case, it is the responsibility of the operator to ensure that the interface management process is correctly performed throughout the duration of the project, including:

  • Initial identification of all the interfaces between work packages, clearly identifying the battery limit of the scope of work awarded to each contractor;
  • Expedition of the communication flow between the contractors affected by a common interface, ensuring that all the needed documentation (drawings, specifications, etc.) is exchanged and a common agreement for the execution of the interface is reached;
  • Evaluation and definition of any interface request made by any contractor during the execution of the project, ensuring that the appropriate actors are involved and an agreement on the interface is reached;
  • Management and control of any interface issue raised by any contractor during the execution of the project, ensuring that any deviation or change request is properly addressed and forwarded to the affected actors;
  • Addressing any pending interface request or interface issue in a proper time frame, to prevent any delay in the interface agreement and disruption of the project schedule; and
  • Tracking of the additional costs related to interface issues that turn into variation orders to be issued to the affected contractors.

The initial definition of the battery limits and the corresponding interfaces is usually performed through dedicated meetings with the contractor. However, since the contracts are often awarded on the basis of front-end engineering studies, it often occurs that during the detail engineering phase the contractors issue thousands of “technical queries” asking the operator to provide additional details and clarifications with reference to the scope of work of their work package. During this process, a large number of new interfaces can be identified and need to be appropriately managed. In some cases, the process of acknowledging all the details of an interface is only a matter of time, because the operator needs to ensure that all the appropriate documentation is shared across the affected parties in a timely manner. In other cases, there might be technical disagreement between two contractors about the appropriate way of implementing an interface; in such a case, it is the operator's responsibility to manage the conflict and facilitate an agreement, often by holding dedicated meetings.

In order to manage such a complex process, an interface management team needs to be assigned to the project, as well as a well-established interface management process and an appropriate tool set.

In terms of people, the main roles involved in interface management are:

  • Company interface management team: an operator team that ensures that the interface management process is consistently applied throughout all contractors, correctly routes all interface requests and issues across the affected actors, facilitates the timely closeout of interface agreements, and helps resolve conflicts across interface parties;
  • Company work package management team: an operator team appointed to manage all the communication between the company and a specific contractor, responsible for the implementation of a work package;
  • Company technical team: an operator team appointed to evaluate and validate any interface issue from a technical/multidisciplinary point of view; and
  • Contractor interface manager: one or more contractor representatives who are entitled to submit interface requests/issues, and to receive, accept, and approve the requested interface information.

The involved roles and the interface management process are usually project-specific, depending on the complexity of the project, the size of the team, and the number of contractors or other involved parties. Exhibit 3 shows a typical integrated interface management process, able to treat the project interfaces between two of the following parties:

  • EPC contractors
  • Company engineering department (for work packages not yet in execution)
  • Operator
  • Third parties (e.g., government agencies, joint venture partners)

The process is usually initiated by a contractor (interface requesting party), which submits an interface request. The request is captured by the corresponding company work package management team, which performs a first evaluation of the request and decides whether to send it back to the requesting party or forward it to the company interface management team. This team validates the request with the optional support of technical personnel, and identifies and routes the request to the affected work package through the corresponding work package management team. The work package team manages the communication with the contractor (interface responding party), ensures that the required information is collected, and sends back the official reply to the requesting party through the mediation of the interface management team and the work package management team. Before finalizing an interface (i.e., collecting all the information needed to consolidate and acknowledge how the interface will be implemented by both parties), it is not uncommon to cycle back and forth across this workflow several times, and to spend several weeks/months before the interface is officially signed off and closed.

The same process can also be started by the company technical team, in case an interface request is identified by the company and one of the contractors is involved with it.

In order to ensure that this process is effectively in place, it is important to include an interface management procedure within the contractual agreements that are signed between the operator and the contractor. This procedure specifies both the official process to be followed and the tools to be used to exchange information.

Exhibit 3—Sample interface management process

Interface Management Tools

A key aspect of interface management is the ability to effectively communicate, across all involved parties, all the details related to an interface, including requirements, technical specifications, and potential issues. It is important that the communication channel is promptly established, the proper information is exchanged, and all involved parties acknowledge that they fully understand the interface requirements so that they can proceed with the execution of their scope of work. Both contractors and company representatives can be geographically distributed across several locations (e.g., construction yard, engineering offices, company headquarters, company subsidiary in a foreign country). Therefore, it is very important that information is made available in a prompt and consistent way to ensure that all parties are equipped with the most updated interface definition.

A traditional approach to implementing interface management is based on maintaining a large interface register within Microsoft Office tools (e.g., Microsoft Excel), where all interfaces are listed together with all the affected contractors, and exchanging information via email. This approach cannot be sustained throughout the duration of the project. The first reason is related to the amount of information: As previously explained, it is not unusual to manage several hundred up to thousands of interfaces; for each of them, it is common for information to cycle back and forth among the parties until an agreement is reached, therefore accounting for dozens of emails (and associated attachments) for each of the rows in the Microsoft Excel spreadsheet. Moreover, it becomes extremely difficult to track the timeliness of the needed information, to cross-reference each interface item onto the project elements (e.g., schedule, cost, quality) that might be affected, and to keep track of the different revisions of each interface element throughout the duration of the project.

For this reason, an approach based on eCollaboration proves to be much more effective. Through eCollaboration, an electronic workflow across different companies can be set up on the Internet. The operator can coordinate the workflow in order to ensure that affected contactors are put in contact with each other, requested information is promptly exchanged, and interface issues are addressed and closed within an appropriate time limit, therefore minimizing the impact on the overall project.

The eCollaboration Approach: Workflows

The eCollaboration approach should ensure that information is circulated through geographically distant parties in an efficient way. With this approach:

  • A website on the Internet is made available, where all involved parties access the interface information they need, according to their roles;
  • Each party can operate according to the steps of the workflow they are associated with; for example: review the current snapshot of the information associated with the interface, enter/update information, “release” the information to be processed by the next step of the workflow, or “reject” the information to be sent back to the previous step, typically asking for additional information in order to correctly process the request;
  • Email notifications are automatically issued to the appropriate recipients when a step is performed (e.g., notifying them about the approval or the rejection of the request), together with a web link to allow immediate access to the latest updated information about the interface; and
  • Online dashboards and reports are available to highlight pending and overdue items, with the option of sending expediting emails to the parties that are due to submit information.

Exhibit 4 shows an example of such a website, displaying the full interface register: Each line in the register represents an interface request involving an originator and a responder. Each item is assigned a formal coding, a workflow status (e.g., “Awaiting Approval,” “Awaiting Review,” etc.), and a list of associated attachments. The workflow status shows the detailed timing in which each approval/rejection step has been performed, allowing for timely information exchange. Moreover, a full audit trail of each modification can be provided, highlighting all the modifications that the interface request has undergone. Each party can see only the interface they are involved with, while some company roles (for example, the interface management party) has complete visibility on the register.

Such functionality provides huge benefits in terms of overall visibility in the process, allowing users to highlight the average time to process interface requests and issues, to monitor and expedite the contractors that are slower in the provision of the requested information, to identify bottlenecks in the process, and to identify needs to increase the staffing level of the interface management team.

 

Exhibit 4—Sample interface register

Exhibit 5 shows some examples of the level of control that can be applied to the interface management process. Since the information related to originating party, responding party, technical disciplines involved, affected plant components, and time of approval of each step is all stored in a centralized database, it is possible to provide a dashboard displaying:

  • The overall performance of the process (e.g., average number of days from request submission/validation to response, or from request submission/validation to response acceptance by the originating party). The same statistics can be filtered by originating/responding party (therefore identifying contractors that are not providing timely feedback), by technical discipline (therefore identifying the need to increase the staffing level of specific disciplines), and by affected plant component; and
  • The number of overdue items, as well as a look ahead on the interface requests that need to be closed in the future.

Exhibit 5—Monitoring the interface management process

A key component of the approach is the flexibility in the definition and implementation of the workflow. Since each project has unique characteristics, organization charts, and contract strategies, it is common to define specific interface management workflows for each project. It is therefore important that the eCollaboration tool provides a way of easily configuring new workflows (i.e., adding or deleting approval steps; defining the next/previous step upon approval/rejection) with little or no need to involve software development specialists.

The eCollaboration Approach: Content

The second key success point of the eCollaboration approach is the way information is exchanged. There are many paradigms that can be used:

  • Social collaboration: Unstructured pieces of information, usually free text, are posted by each party. Text might be complemented with attachments (e.g., Microsoft Office documents, CAD drawings). However, this method does not allow the user to properly classify the attributes of each interface, such as the involved technical disciplines, the affected plant components, and the deadlines to be fulfilled. These attributes are fundamental to correctly routing the request across the appropriate parties;
  • Document-based collaboration: A web-based document management system collects versioned attachments where each party provides the requested information about the interface. The disadvantage of this approach is that the documents always need to be opened in order to retrieve the main attributes of the interfaces. Moreover, it is often required that specific sections of the interface information are not made available to all the involved parties (e.g., the company's internal discussion about the potential impact of the interface request on the schedule and costs of the project should be kept invisible to the originating contractor), and this is not immediately achievable within a Microsoft Office document; and
  • Form-based collaboration: This is the preferred approach, and it will be discussed in detail in the next sections.

With the form-based collaboration approach, information is organized with small electronic form components that can be configured to be assembled into a single form (see Exhibit 6). Each form component can be assigned to be read or edited by specific parties involved in the workflow. For example, the originating party is entitled to edit the upper part of the form, where the interface request is described. The originating party will be entitled to read the lower part of the form, where the response of the responding party will be entered. The central part of the form, which is used by the operator to correctly identify the responding party and the involved technical disciplines, can be left invisible to both the originating and responding parties. Moreover, in the central part of the form, the operator can also add complementary information to the form, such as:

  • The items in the project plan that can be potentially affected by each interface issue (e.g., delay in milestone fulfillment, slippage in scheduled activities);
  • The items in the product breakdown structure that can be potentially affected by changes due to interface issues;
  • The items in the cost breakdown structure that can be potentially affected by change orders to realign the operator with the contractor due to interface issues;
  • The baseline project documents (drawings, specifications, etc.), referenced in the official document management system of the project; and
  • Any other project communication occurring between the operator and the contractor (such as technical queries, change requests, variation order requests, and non-conformity reports) as a consequence of an interface issue.

The ability to keep such information hidden to the external contractors allows users to maximize the transparency in the exchange of information, while retaining the confidentiality of those data that are used internally by the operator.

Even in this case, the ability to manipulate the layout and content of the electronic forms (i.e., adding or deleting sections of the form, entitling parties to read or edit each section), without the involvement of software development specialists, is very important. Exhibit 7 shows an example of how the interface management process can be tailored to the specific needs of each project. The workflow includes nine steps, from “Submit Interface Request” to “Close Out.” A menu allows users to “Insert New Steps” (upper part), as well as delete unnecessary steps (not shown in the figure). Moreover, by clicking on the “Editable Form Sections,” a menu is displayed where it is possible to select which sections will comprise the electronic form; for example, the form section titled “Linked and Attached Documents” is included in the overall form to provide a button to upload any number of named attachments. Moreover, the menu allows users to define the visibility rules of each form section: For example, the section named “Technical Team/Functional Support,” where comments from company technical specialists are entered, will not be visible to external contractors (the checkbox named “Visibility External” is not flagged).

 

Exhibit 6—Exchanging information on electronic forms

Exhibit 7—Configuring the content of electronic forms

Eni's Applications in Oil and Gas Projects

Eni, an international oil company headquartered in Milan, Italy, has been applying the eCollaboration approach to interface management since 2009 on selected oil and gas megaprojects. Due to the importance of linking together the information related to interface requests, potential schedule delays, additional costs, project changes, and variation orders to be issued to contractors, Eni decided to extend the internal project planning and control tool, named SIGEP and based on the commercial Project Objects tool, with specific eCollaboration modules to support the previously described workflows (Piantanida, Mattu, Boi, Gaudioso, 2012).

Eni's projects were located in different geographic areas, with different challenges (offshore projects in the Barents Sea, West Africa, Kazakhstan, and Indonesia; onshore projects in the Middle East), involving more than 20 engineering and construction contractors around the world. Contractors have been engaged by ensuring that appropriate interface management procedures were included in the contractual annexes, and by providing a half-day training on the use of the eCollaboration tool. The interface management process typically involves 50 to 180 people, depending on the size of the project. In the projects of the last year, roughly 4,500 interfaces were managed, with a total of 30,000 approval/rejection steps through which information was exchanged. In the same period, 1,200 deviation requests were generated by the contractors as a result of the process of refining the engineering details of their work packages, and 850 variation orders were issued to cope with the modifications in the scope of work. In terms of the daily efforts of the interface management team, Exhibit 8 shows the number of interface requests that were generated on a monthly basis within one single megaproject.

 

Exhibit 8—Number of interface requests generated monthly within one megaproject

In terms of the effectiveness of the interface management process, it helps to reduce the cost of the variation orders related to interface misalignment to under 2% of the overall CAPEX budget.

Conclusions

Setting up an effective interface management process is of key importance when dealing with multiple work packages awarded to engineering and construction contractors, because it can prevent cost overruns and schedule slippage due to delays in commissioning and excessive rework. The use of web-based, workflow-oriented collaboration across the operator and all the involved engineering and construction contractors makes this a particularly efficient and effective approach to coping with the complexity of interface management.

Acknowledgments

We wish to acknowledge the work of Bernardo Principato, Stefano Salustro, and Stefano Bontumasi, who promoted the introduction of interface management processes in some of the major projects operated by Eni, as well as all the people who worked for the implementation and the support of the eCollaboration tool, with specific reference to Francesco Sirabella and Armando Rocca.

References

Nooteboon, U. (August 2004). Interface management improves on-time, on-budget delivery of megaprojects. Journal of Petroleum Technology, 56 (8), 32–34.

Piantanida, M., Mattu G., Boi E., Gaudioso, G. (November 2012). Project management meets business process management tools—a step beyond project collaboration. IPMA World Congress, Crete, Greece.

This material has been reproduced with the permission of the copyright owner. Unauthorized reproduction of this material is strictly prohibited. For permission to reproduce this material, please contact PMI or any listed author.

© 2014, Marco Piantanida, PMP, Giorgio Cognigni, Massimo Mancarella, Gioacchino Gaudioso
Originally published as a part of the 2014 PMI Global Congress Proceedings – Dubai, UAE

Advertisement

Advertisement

Related Content

Advertisement

Publishing or acceptance of an advertisement is neither a guarantee nor endorsement of the advertiser's product or service. View advertising policy.