Structuring Internal Interfaces for a Refinery Upgrade Project
Structuring Internal Interfaces
Article 2 of 3
by William Becerra, Project Interface Manager
How do you set up project interfaces?
William Becerra is an experienced project engineering manager with interface management expertise. Mr. Becerra has worked the past 20 years as a client representative for companies like ConocoPhillips, P66, Aramco Services, and Marathon Oil Co. Visit LinkedIn to see William Becerra's full profile. We asked how project interfaces should be structured, William provided the following response.
Interfaces and Stakeholders
When defining internal interfaces for a project, you first need to define the main project scope boundaries and the stakeholders that will be related directly or indirectly with the project. When thinking about interfaces, try to answer the question: how will stakeholders impact the main project? Are there other projects (i.e. other stakeholders) who will have an indirect relationship with the main project? Stakeholders could be people from different organizations in the same company or the owner of the main project. As an example, in an upgrade project for a distributed control system (DCS) in an existing refinery (DCS Modernization), the owner of the refinery is also the owner of the project, but the division of the organization will make the existing operation team in the refinery a very important stakeholder to deal with during the implementation of the new project. The best way to improve communications with the refinery operations team is to add, as part of the main project team, a representative of operations who will be the liaison with refinery operations regarding the interfaces that will happen with the existing refinery units.
When the main project is defined, the other project’s (or sub-projects’) stakeholder’s and external stakeholder’s relationships should be clarified and confirmed. They must be treated independently, and the impact these subprojects have to the main project must be evaluated. This evaluation will indicate how the Interfaces should be prepared, the schedule impact, and the importance of getting the interface point to a “closed” status.
Defining the Interface Register
The definition of interfaces is very important during the first phases of the project. The creation and list of these interfaces during FEL-1 thru FEL-3 will initiate the Project Interface Register that will be used during the construction phase of the project. Some of these interfaces should be closed during the optimization or the define phases of the project, especially the ones related with the approval of the project, the environmental and government entities permits, studies, and any other external projects that require the main project approval. Most of the interfaces will be implemented and resolved during the EPC phase or construction phase of the project. Any delay, misunderstanding, omission, or issue with these interfaces could severely impact the cost and/or schedule of the main project.
Defining Interface Agreements
Managing interfaces, resolving issues, and exchanging deliverables, is done using interface agreements and action items. The complexity of an interface may lend itself to the number of interface agreements raised. There is no limit, nor any ‘hard and fast’ rule as to how many interface agreements it takes to resolve in interface. At the end of the day, every interface will have at least one interface agreement. These interfaces are less complete and may be related to a single document to be provided, a single permit to be issued, etc... The project may choose to avoid these ‘simple’ interfaces, instead determining if they can be handled as part of another interface or not tracked at all. Important consideration should be made, as you want to avoid anything falling through the cracks, as progress on all interfaces must be highlighted in PM/IM management meetings.
Some interfaces can be grouped into a single interface point, with a primary discipline identified. You may choose to identify the primary discipline based on the last discipline involved at the interface; the discipline responsible for closure.
It is important to understand the participation of the various disciplines, ensure no clashes, and understand dependencies when grouping interfaces. If issues are identified as part of this analysis, then separate interface points should be created.
Internal Interface Structure Example
The following illustrates an example of how one discipline can be setup to handle an interface with multiple discipline involvement. The example has been set up for the DCS modernization of a refinery using a new, modern design of fiber optic connections between instrumentation to the main control system. These projects replace existing junction boxes with smart panels called CHARMS I/O Cards (CIOCs), connecting the cables and wires coming from those instruments (analog or digital signals) to the new DCS system using a fiber optic cable (digital only).
In several cases, the DCS modernization of an existing refinery is combined with a major brown field project (Main Project), and several of these instruments will be re-used without modification, if the condition of the instrument is acceptable, and will be connected to the new CIOCs in lieu of the old existing junction boxes. These new CIOC panels are designed to capture analog signals as well as the digital signals. If the instrument locations are not in the boundary of the Main Project, then an interface will be created to link the owner of the instruments (refinery operations personnel) and the Main Project team.
Each CIOC panel could handle near to 90 connected instruments (new ones and existing ones). The panel will need the participation of the Civil Discipline for the installation (foundations and structural support of the panel and the shade), Electrical Discipline for the power connections and illumination, as well as the Instrumentation and Control Discipline for the connection of instruments to the panel and the main fiber optic to the control system. The last discipline to handle the panel to the project is Instrumentation and Control. The decision during FEED was to handle these interfaces using each PANEL as the interface to be handled by Instrumentation and Control (single discipline) and the Civil and Electrical component of the interface will be included using interface agreements
Figure 1: Interfaces & Interface Agreements for Modernization
Interfaces & Interface Agreements:
- Each PANEL will be a single interface
- Instrumentation is the last discipline to handle the panel, so Instrumentation is setup as the OWNER of the Interface
- Disciplines involved in the interfaces use Interface Agreements (IAs): Civil, Electrical and Instrumentation.
- This decision will limit the number of interfaces – assign interfaces to single discipline and link other disciplines through IAs
It’s important to note that the modernization project involved the installation of CIOCs in areas not controlled by the project, in units outside the project’s boundaries. The owner of these instruments in those areas was the refinery operations. There were around 80 new CIOC panels required in those areas, meaning 80 interfaces controlled by Instrumentation and Control (discipline lead). The required participation of the Civil and Electrical disciplines were done using interface agreements, connected in the interface management system with the schedule of the project.
When setting up interfaces, I recommend trying to reduce the total amount of interfaces joining the activities in a single discipline, and handle, internally in the interface, the other disciplines using interface agreements, especially for interfaces where the timing of involvement of the disciplines is not at the same time during the execution, that will be a clash to avoid. If more than one discipline will be at the interface at the same time, then divide that item into another interface to be handled by the next important discipline.
In Coreworx Interface Connect, after you have defined the interfaces (via Interface Points / IPs), the life of the interface, where all the communications and interactions happen, is through the interface agreements (IAs). The interface agreements will capture all important information and decisions (where all parties should be in agreement) to be controlled during the execution of the interface, using as possible a single discipline in each communication or IA. A single interface could have only one interface agreement or several of them, depending on the complications and requirements needed.
Remember, interface agreements are the tool in Coreworx that make the interface come alive and, at the end, all interface agreements need to be closed in order to have the interface itself set to the “closed” status.
Internal and External Interfaces
Now that Mr. Becerra has illustrated how internal interfaces can be structured on a project, let's look at how a system can be setup to handle both internal and external interfaces.
Internal & External Interfaces for an Offshore Project
Have a Question?
If you have a question for the interface management expert panel, please send it to us and we will be happy to send you an answer!