INSERT INSERT

CORPORATE PROJECT TITLE

LOGO PROJECT NUMBER

INTERFACE MANAGEMENT PLAN

Project title
Project number
Document number: xxx-001-1
Revision number: 0

PMO Manager:

Document contributors:
Name Title email
Name Title email
Name Title email
Name Title email

Probate Party:
Name Title email
Date approved:

Page | 1 Interface Management Plan xxxx-001-0 Revision 0

INSERT INSERT
CORPORATE PROJECT TITLE
LOGO PROJECT NUMBER

History
Release
Reason for release Detail
number
A Initial draft for review
B Second draft for review
C Final draft for review
0 Initial release
3.2.1: Corrected the spelling of “baef”
Changes to sections 3
1 3.3.4: Added reference to section 6.1
and 4
4.1: Changed the title of the header

References
1. Investment-Centric Project Management, Chapter 15
2. Web-Added-Value (WAV) download Unit Transformation Process (UTP)
3. Web-Added-Value (WAV) download Baseline Asset Execution Framework
4. Web-Added-Value (WAV) download Phase Execution Plan
5. Web-Added-Value (WAV) free download Direct Accountability

Page | 2 Interface Management Plan xxxx-001-0 Revision 0

INSERT INSERT
CORPORATE PROJECT TITLE
LOGO PROJECT NUMBER

Executive summary
This document prescribes the mandatory mechanics and mechanisms to be employed
by all participants to the Project to obtain the convergence of technical, physical,
algorithmic and operational interface issues as they arise in the course of the project’s
development. This plan is prepared, approved and issued under the probate authority of
the PMO project manager, and shall be adopted uniformly by all parties contracted to
participate in the work.

Page | 3 Interface Management Plan xxxx-001-0 Revision 0

INSERT INSERT
CORPORATE PROJECT TITLE
LOGO PROJECT NUMBER

Table of Contents
Section Page No.
Section 1 Introduction 5
1.1 Convergence of Execution 5
1.1.1 Role of Interface Management 5
1.1.2 Purpose of Interface Management 5
1.1.3 Scope of application 5
1.1.4 The Unit Transformation Process (UTP) 6
1.1.5 Role definitions 6
1.1.6 Definition of an issue-free junction 6
1.1.7 Limits on the scope 7
1.2 Interface issue resolution overview 7
1.2.1 Framework foundation 7
1.2.2 Accountability and Authority 9
1.2.3 Closure of interface issue 9
1.2.4 Software 9
Section 2 Organization 10
2.1 Interface Management Team 10
2.1.1 Line management 10
2.1.2 Technical Leadership 10
2.1.3 Responsibilities 11
Section 3 Interface controls 13
3.1 Control mechanics 13
3.1.1 Battery Limit Tables 13
3.1.2 Interface Register 15
3.1.3 Interface points 15
3.1.4 Interface agreements 16
3.1.5 Agreement Change Request (AC) 16
3.1.6 Requests for Information (RFI) 16
3.1.7 Notice of Change (NOC) Log 17
3.2 STATUS REPORTS 17
3.2.1 Reporting requirement 17
3.2.2 Interface point summary 17
3.2.3 Interface agreement status 17
3.2.4 Interface agreement summary 17
3.2.5 Early warning summary 18
3.2.6 RFI Summary 18
3.2.7 5NOC Log status 18
3.3 Coordination 18
3.3.1 Weekly coordination meeting 18
3.3.2 Monthly coordination meeting 18

List of Figures
Name Page No.
Figure 1 - Terminology of the UTP 6
Figure 2 – Project hierarchy 10

Page | 4 Interface Management Plan xxxx-001-0 Revision 0

INSERT INSERT
CORPORATE PROJECT TITLE
LOGO PROJECT NUMBER

Section 1 Introduction
1.1 Convergence of Execution
1.1.1 Role of Interface Management
The importance of interface management is such that a project will fail from interface
management’s deficiencies. Interface management premises that errors will happen and
changes will be incurred. It has nothing to do with error prevention and change
mitigation. Instead, its purpose is to control the impact of a convergence issue, in order
to obviate surprises and unintended consequences.

Interface management shuns the blame game in favor of full disclosure for the ultimate
good of the Project.

1.1.2 Purpose of Interface Management

The purpose of interface management is threefold:

1. Identify “junctions” where the input or output requirements of one

participant impact the input or output requirements of one or more
additional participants.
2. Propitiate the efficient flow of information between participants in the
pursuit of a resolution to the needs of the junction thus identified.
3. Establish a formal framework for decision-making associated with the
resolution.
4. Inject real-time visibility into all interface management issues among all
participants, to eliminate surprises, oversights or omissions from
participants’ unawareness.
It is a long acknowledged problem that large, complex, modular‐based projects struggle
to achieve on time, on budget project performance. This is largely due to interface
dependencies. Without established work processes to manage interface‐related issues,
the risk of schedule delays and cost overruns increases dramatically. Interface
Management problems can account for up to 20% of project costs and thus must be
appropriately managed by anticipation rather than reaction.

1.1.3 Scope of application

This plan pertains to the technical interfaces arising at the junction between two or more
of unit transformation processes (UTP), where inputs and outputs are inter-dependent.
Interface management occurs strictly at those junctions and is excluded from the inner-
workings of the processes implicated in a given junction. The junction acts as a node
through which flows information in the form of technical requirements. A requirement
may be physical (size, dimension, location), functional (flow rates, pressure rating, fluid
transfer), informational (contents review, squad check, scope demarcation agreement),
or operational (maintenance activity, testing and troubleshooting, temporary connections,

Page | 5 Interface Management Plan xxxx-001-0 Revision 0

INSERT INSERT
CORPORATE PROJECT TITLE
LOGO PROJECT NUMBER

etc.). In all cases, the success of the interface is achieved when all affected participants
agree on the form, fit and function of the junction, to the extent that it can be built and
operated in full compliance with the intended design.

1.1.4 The Unit Transformation Process (UTP)

The basic elements of the UTP are shown in Figure 1, where the inner workings of a
process lie within the activity boundary - delineated by the dash line. The manageable
“junctions” occur where the output from a preceding UTP meets the activity’s input, on
the left, and where the activity’s output becomes an input to a subsequent UTP, on the
right. The expression Inside Boundary Limit (IBL) applies to the inner workings of the
activity; whereas what lies between adjoining boundaries will be referred to as Outside
Boundary Limit (OBL).

Figure 1 - Terminology of the UTP

1.1.5 Role definitions

The following definitions apply to Figure 1:

 Accountability is the power vested upon an individual to execute a UTP. The

expression Accountable Party (AP) will apply to such an individual.
 Responsibility is the mandate assigned to an individual to marshal the
resources required to execute the UTP. The expression Responsible Party
(RP) will apply to such an individual.
 Authority is the power to approve the outputs of a UTP. The expression Probate
Party (PP) will apply to such an individual.

1.1.6 Definition of an issue-free junction

A junction is deemed correct when the input-output pair meshes perfectly, and the pair is
said to be converged. Geometric alignment is an example of convergence.
Convergence is the basis from which a junction is approved by the pertinent Probate

Page | 6 Interface Management Plan xxxx-001-0 Revision 0

INSERT INSERT
CORPORATE PROJECT TITLE
LOGO PROJECT NUMBER

Party (see article Error! Reference source not found.). Approval rests upon the
confirmation of compliance of the inputs and outputs to the constraints placed upon the
UTP, which are divided into four types: compliance, standards, criteria, and allocation.

 Compliance includes the regulatory requirements applicable to the execution of

the work, to the individuals performing the work, to the tools used for the work,
and the permits, both a priori and a posteriori. Compliance implies an obligation
created by regulators. Regardless of the origin of that obligation, once it is
deemed to apply to the project or the task, it cannot be contravened (unless
one wishes to test the goodwill of the pertinent regulator...).
 Standards encompass the codes, standards, specifications, requirements
definitions, templates, schemes, and other prescriptions upon the activity.
Industry standards are usually adopted based on professional practice and
acknowledged priority, or legislated. Standards are also specific to an owner’s
organization and imposed upon on project in equal force with the legislated
ones. Standards differ from compliance acts and regulations in that they usually
allow deviations, subject to thorough vetting procedures. Standards, ultimately,
endow the project execution framework with a uniformity of expectations across
the technical domains.
 Criteria are the externally defined constraints imposed on the inputs and
outputs. Criteria do not apply to the process.
 Allocation represents the budget, time, and physical limits allocated to the
activity.

1.1.7 Limits on the scope

This plan excludes the following project execution elements:
 Work associated with ISBL
 Contract changes and modifications
 Social performance scope of work
 Non-technical matters
 Regulatory matters
Note that technical interface management issues may result in changes to the project.
Such changes will remain in the realm of the PMOC process.

1.2 Interface issue resolution overview

1.2.1 Framework foundation
The resolution framework rests upon six pillars: (1) capture, (2) resolution, (3) escalation,
(4) management of change (MOC), (5) dissemination, and (6) transparency.

1. Capture - As the name indicates, capture seeks to flag an issue as soon as it comes
to light, and document it in a controlled fashion. No issue is too small or too benign to be
allowed to fly under the radar. All issues are therefore subject to interface oversight.
They are so governed for reasons of state: the state of a non-convergence must be

Page | 7 Interface Management Plan xxxx-001-0 Revision 0

INSERT INSERT
CORPORATE PROJECT TITLE
LOGO PROJECT NUMBER

understood in terms of its impact on the project. The capture process proceeds
throughout the life of an instance until it is resolved and closed. It also encompasses the
means of notification, the documentation generated, the trail of inputs and exchanges
leading to the resolution, and the quantified impact to the project as a whole.

2. Resolution - This is the mechanics for addressing an interface issue. It is more

process than paperwork, more people than procedures. The resolution stage ultimately
leads to the decision made by the project team to deny, fix, alter, or expand the initial
issue. The process is in fact a micro-scale project unto itself, which consumes time,
labor, and possibly materiel to reach a satisfactory conclusion. Its output could include
such deliverables as: calculations, drawings, analyses, procurement paperwork, change
orders, project directives, and project baseline adjustments.

3. Escalation - Interface issues are resolved on the principle of proximity: in other words,
those closest to the issue are best to solve it. Resolution mechanics are fundamentally a
bottom-up methodology. Issues that crop up at the lead level should be resolved at that
level, even when leads from different vendors are involved. When they cannot be solved
from within, they must be elevated to the next level, according to the project’s
accountability matrix. At each step, the interface team acts as responsible party for the
process, by coordinating and enabling the resolution mechanics until closure is
achieved. Within the project, the escalation buck stops with the PMO manager, who
must then validate the resolution with the framework lead. In a joint venture or corporate
partnership scenario, the framework lead assumes the final say on all interface
management issues.

4. Management of change (MoC) - Once an interface issue is resolved satisfactorily, its

solution must be implemented and its cost/schedule impact assigned against the
project’s baseline allocations. At a minimum, the solution implementation will be
authorized via a project directive or a change order, as discussed earlier in the chapter.
Significant changes affecting the contract or the scope of the project would be handled
via formal letters issued by the PMO. At no time should the authorization be
communicated via email, voicemail, or social media.

5. Dissemination - This process occurs once the MoC process yielded an authorization
to implement a solution. The dissemination process aims at keeping all project partners
apprised of the decision rendered on a specific interface issue, regardless of any
partner’s distance from it. It bears repeating that interface management is not a witch
hunt to burn a partner at the bad design stake. The blame game, when required, must be
pursued by the PMO on the basis of confidentiality and respect for the presumed guilty
party (lest circumstances lead to bad blood and pervasive distrust). The dissemination
process must limit itself to documentation that focuses on the nature of the decision
taken. It can, however, reveal valuable lessons about the origins of the issue, which
become part of the project’s lessons learned.

Page | 8 Interface Management Plan xxxx-001-0 Revision 0

INSERT INSERT
CORPORATE PROJECT TITLE
LOGO PROJECT NUMBER

6. Transparency - Transparency exists in tandem with dissemination. All project partners

should have full awareness, in real time, to all interface issues, from capture to
dissemination. At the outset, an issue unsuspected of certain ramifications may be
deemed applicable to a partner who was not initially involved with its discovery. In this
fashion, any number of partners may choose to participate in the resolution, after
notifying the interface manager. Reviewing all interface issues upon capture is therefore
a mandatory requirement that is imposed on all SPT partners (SCP partners are
excluded from this obligation). Finally, transparency cannot function without rigid
controls. Access cannot be a free-for-all for readers and writers. Wider transparency
dictates tighter central control. The interface management software is the operating
system of the entire operation.

1.2.2 Accountability and Authority

The onus for the resolution of an interface issue rests with the Probate Party (PP)
assigned to approve the junction of the UTP (see Figure 1). This individual is, by default,
the closest person to the problem. If the issue cannot be resolved at this level, two
things happen: the initial PP relinquishes the mandate to his immediate superior, but
takes on the Accountable Party (AP). Further escalation up the project hierarchy will
swap the PP role in this fashion; however, the AP role always remains with the same
person.

1.2.3 Closure of interface issue

The dissemination of a resolved interface issue implies completion. Once the resolution
has been duly published and disseminated, the interface manager must declare the
matter closed. If more work is needed to complete the resolution, the interface manager
can still disseminate the solution, with the caveat that it is provisional. It is up to this
individual to elaborate a strategy to follow up on all the loose ends associated with an
issue. An issue is explicitly unfinished until closure has been declared. It goes without
saying that a project cannot be completed with interface issues still outstanding.

1.2.4 Software
Transparency implies real-time access, which, in turn, implies software. For this project,
the following database application will be used: NAME REQUIRED.

Page | 9 Interface Management Plan xxxx-001-0 Revision 0

INSERT INSERT
CORPORATE PROJECT TITLE
LOGO PROJECT NUMBER

Section 2 Organization
2.1 Interface Management Team
2.1.1 Line management
The Interface Management Team is a functional group reporting to the Execution Chief,
as shown in Figure 2 (in the box Interfaces). The team is led by the Interface Manager.
At the Framework Team level, the position of Interface Advisor exits to support all
Interface Managers active within the Framework’s portfolio of projects. The Interface
Manager may be assisted by a Records Technician in charge of datum entry and report
generation through the Interface Management Software (see 1.2.4). Each contractor
active on the project will assign a Partner Interface Coordinator (PIC) who will report
directly to the Interface Manager in interface management matters.

Figure 2 – Project hierarchy

2.1.2 Technical Leadership

Together, the Interface Manager and Project Interface Coordinators focus on the
implementation and execution of the interface management plan. Each party’s technical
team will work in conjunction with the interface management team in the following
manner:

 Unit Discipline Leads (UDL), representing the technical interests of their

respective disciplines with a given unit
 Unit Engineering Leads (UEL), representing the technical interests of their
respective units
 Partner Engineering Managers (PEM), representing the technical interests of
each contractor’s scope of work
 Partner Project Managers (PPM), representing the overall interests of each
contractor’s project execution group.

Page | 10 Interface Management Plan xxxx-001-0 Revision 0

INSERT INSERT
CORPORATE PROJECT TITLE
LOGO PROJECT NUMBER

2.1.3 Responsibilities
2.1.3.1 Interface Advisor
The project Interface Advisor is a member of the Framework Team and assigned the
mandate of monitoring the state and progress of interface management issues arising
across all projects in the portfolio. The Advisor also assists the Interface Manager in
resolving interface matters that could not be solved at the PMO Project Manager level
.
2.1.3.2 Interface Manager
The Interface Manager is responsible for Interface Management on the project. Main
duties include:

 Implement, enforce, train and update this plan

 Establish a distribution matrix for interface documents
 Chair weekly interface management meetings
 Issue the meetings’ agenda, notifications and minutes
 Chair the weekly interface coordination meetings
 Develop and maintain the Interface Register (see article ‎4.2)
 Publish the interface register, the dashboards and reports (See Section ‎5)
monthly
 Act as final decision level on unresolved interface points
2.1.3.3 Partner Interface Coordinators
The Partner Interface Coordinator (PIC) manages the day-to-day execution of interface
management tasks on the project. Duties will include:

 Act as lead and primary Partner contact vis-à-vis interface coordination on the
project
 Establish and maintain their respective interface document register (IDR) dates
for their interface documents to be provided to the IM
 Coordinate the review and interdisciplinary squad checks of interface
documents within their respective PECs
 Issue all interface documents to the Interface Manager
 Flag and bringing to the attention of other interface coordinators any technical
deviations directly affecting U&O or any other area.
 Establish and maintain their respective RFI logs
 Control the efficient and timely flow of documentation and information in the
pursuit of interface point resolutions.
 Maintain and control each Partner’s Battery Limit Tables.
2.1.3.4 Records Technician
This individual reports to the Interface Manager and works directly with the interface
management software. Duties will include:
 Perform datum entries

Page | 11 Interface Management Plan xxxx-001-0 Revision 0

INSERT INSERT
CORPORATE PROJECT TITLE
LOGO PROJECT NUMBER

 Update the database records

 Prepare reports
 Distribute the reports to the appropriate parties.

Page | 12 Interface Management Plan xxxx-001-0 Revision 0

INSERT INSERT
CORPORATE PROJECT TITLE
LOGO PROJECT NUMBER

Section 3 Interface controls

3.1 Control mechanics
3.1.1 Battery Limit Tables
For each installation (primary, secondary and tertiary), the Technical Chief will prepare
and publish Boundary Limit Tables (BLT), by discipline. These tables shall be used as
primary registers of technical requirements for which interface convergence will be
assessed in accordance with article 1.1.6. The tables identify all the junction points of a
boundary limit. Once generated, the tables are taken over by the Interface Manager and
the pertinent Partner Interface Coordinators for maintenance and control. The tables
must include all known interface items, even if they are fully quantified at any given point
in time. This will allow the project to highlight needed information, to assign
responsibilities to get that information, and to monitor progress toward completion.

3.1.1.1 Process BLT

The Process Battery Limits Table deals primarily with piping connections and process
conditions and include the following fields:

 PFD and PID

 System diagrams (site wide system on a single drawing, enabling holistic
review of the specific commodity generation, distribution and consumption.
 Stream data
 Utility Summaries
 Utility Flow Diagrams
 Effluent Summaries
 Chemicals and Catalysts
 Aqueous Effluent Summary
 Solid Emission Summary
 Air Emission Summary
 Tank VOC Summary
 Noise Summary
3.1.1.2 Electrical BLT
The Electrical Battery Limits Table deals primarily with cable connections and will
include:
 Load lists
 Area classifications
 Power distribution physical interfaces
 Single Line diagrams
 MCC and VFD Single Line Diagrams
Page | 13 Interface Management Plan xxxx-001-0 Revision 0
INSERT INSERT
CORPORATE PROJECT TITLE
LOGO PROJECT NUMBER

 Overall Single Line Diagram

 System Studies
 Cable and Tray Systems
3.1.1.3 Automation BLT
Automation Battery Limits Table deals primarily with communications and will include:

 Inter-process unit control and battery limit signals (to be shown on battery limit
P&IDs)
 Common plant wide systems (other than process control) such as fire alarm,
security, vibration analysis, gas detection, etcetera
 Remote instrument buildings (REBs)
 Main automation contractor (MAC) interface for REB sizing, fibre optics plan,
loop templates design, etc.
 IT interface for backbone LAN for communication, fire alarm
 Business LAN, communication panels, fibre optic patch panels, interplant
software
3.1.1.4 Piping and layout BLT
The project site plan assigns a plot area to each specific process unit or facility. This
drawing is the primary document for coordination of plot space allocation. It is the
responsibility of each UEL to dimensionally define the actual area required and piping
locations within their allocated plot for the contractor’s scope of work. Individual plot
geometry is somewhat flexible and can be altered by the UEL. The BLT will include:

 Plot plans
 Site plans
 Coordinate system
 Piping interfaces (the area plot plans will define the location of the on-plot
battery limit isolation valves and the valve arrangement for all lines entering or
leaving the unit’s battery limits. These drawings shall be complete with:
 Line numbers, size and piping class
 Dimensions, elevations and coordinates, centreline elevations
 Heat tracing requirements for all lines
 Insulation requirements
 Anchor locations ISBL, shoes.
 Piping Specifications and Classes
3.1.1.5 Civil, Structural and Architectural BLT
CSA Battery Limits will include:
 • Sewers
 Underground piping
 Grading and Paving
Page | 14 Interface Management Plan xxxx-001-0 Revision 0
INSERT INSERT
CORPORATE PROJECT TITLE
LOGO PROJECT NUMBER

 Pipe way
 Geo-technical
 Blast study circle

3.1.2 Interface Register

The Interface Register is the primary document for managing technical interface issues,
from generation to resolution and close-out. The register will be generated as a report
from the database software (see 1.2.4) and will track the status of all changes emanating
from the approved resolutions, as well as the ties into the Notice of Change Register
(NOC). As a minimum the Interface Register will contain the following information:

 Interface Number ; Revision Number and Date

 Title
 Short Description
 Data Supplier
 Data Receiver
 Need Date
 Forecast Delivery Date
 Close-out Date
 General Comments
The Register shall be:

 kept current by the Interface Manager or his delegate

 updated weekly from inputs from the PIC
 reviewed weekly by the IM and the PIC
 reviewed monthly by the Interface Management Team
 be maintained in parallel with the NOC register

3.1.3 Interface points

Interface points identify junctions where a technical interface requirement exists between
two or more participants. Interface points can be created at any point during the
project’s life cycle by any technical project personnel. The Interface point represents the
real interface. It is the junction mentioned in article ‎1.1, and acts as the parent to
Interface Agreements. All participants have the ability to create Interface Points and to
modify existing Interface Points.

Newly raised interface points are first documented on an Interface Point Form. Each
completed form describes the interface and its physical aspects. It also specifies the
parties that are responsible for, or have a vested interest in the interface.

Page | 15 Interface Management Plan xxxx-001-0 Revision 0

INSERT INSERT
CORPORATE PROJECT TITLE
LOGO PROJECT NUMBER

Newly raised interface points will be added to the Interface Register to initiate the
resolution process. As much as possible, interface points will be grouped by Package,
allowing for enhanced searching and reporting.

No Interface Point can be closed until all activities related to it have been closed and
agreed via an interface agreement or a change request.

The owner of an interface point is responsible for shepherding its resolution until closure.
The owner of an interface point is the discipline lead who controls the input at the IBL
boundary.

3.1.4 Interface agreements

The purpose of the Interface Agreement is to ensure that all procedures have been
complied with, that requests are completed and that the agreement reflects all
dimensions of the agreement between the participants. The agreements are formal
communications documenting the interface needs of one participant, and the
commitment of the other participant(s) to meet these needs before a specified date.

Interface Agreements can be created between participants to satisfy the requirements of

the Interface identified by the Interface Point form. Interface Agreements spell out the
work or deliverables required as well as the date required. Participants have the
responsibility to manage interfaces using Interface Agreements to document the
deliverables and information required by other participants. Mutual agreement and
acceptance are required by both parties before the Interface Agreement can be closed.
The details of each interface agreement, along with the documents involved, are
recorded in the Interface Register.

3.1.5 Agreement Change Request (AC)

During the life of an Interface Agreement, the original requirements or scope may
change, the physical location may change or the need date may change as events
cause the project to accelerate or slow down. The requirement to change an approved
agreement is first initiated via a new Interface Point, followed by the publication of the
associated Approved Change Request Form. The ACR is recorded on the Interface
Register.

3.1.6 Requests for Information (RFI)

Requests for Information are utilized to formally solicit information or action on a given
technical matter, from other participants. Any participant can initiate an RFI during the
life of the project, and remains the owner of that RFI until it has successfully been
fulfilled. The nature of the technical information sought includes:

 Clarifications on missing or conflicting information

 Specifics of the nature of a junction at a Unit’s boundary
 Requests to correct a mistake or error
 Request to clarify a specific scope of work or work demarcation

Page | 16 Interface Management Plan xxxx-001-0 Revision 0

INSERT INSERT
CORPORATE PROJECT TITLE
LOGO PROJECT NUMBER

 Request for review, squad check or verification of a deliverable

 Request to produce a calculation or analysis required by one’s Unit ISBL.
In all cases, the initiator of the RFI is responsible for shepherding it from submission to
completion and closure. All RFI are recorded on the Interface Register.

3.1.7 Notice of Change (NOC) Log

In cases where the resolution of an interface point results in a necessary change to the
technical configuration of the project, the Notice of Change process is triggered. The
change is documented in the NOC Log, and tied back to an entry in the Interface
Register. This log will be maintained by the Interface Manager. It lists all changes to the
issued for design (IFD) documents from all units, as well as the impact of those changes.

3.2 STATUS REPORTS

3.2.1 Reporting requirement
The PMO will provide dashboard reports to support an overview of interfaces for a
selected contract or contractor, as well as the ability to provide early warning of potential
schedule slippages. The following dash boards will be developed and implemented by
the Interface Manager:

 Interface Point Summary

 Interface Agreement Status
 Interface Agreement Summary
 Early Warning Summary
 RFI summary
 NOC Log status

3.2.2 Interface point summary

The Interface Point Summary displays an overview of all Interface Points. The report
provides a summary of all Interface Points grouped by Package and then by status.
Participants can quickly view the progress and number of interfaces for a given package.
Progress is indicated by the movement of Interface Points from the initial status of
'Issued', to 'Finalized' and finally to ‘Closed’.

3.2.3 Interface agreement status

This report provides an overview of all Interface Agreements created, with a break down
by status. The Dash board can be filtered based on Participant, Package, Phase, Area,
System and Discipline.

3.2.4 Interface agreement summary

This report provides to the PMO and the Framework Team an overview of all Interface
Agreements created, grouped by Package, with a break down by status.

Page | 17 Interface Management Plan xxxx-001-0 Revision 0

INSERT INSERT
CORPORATE PROJECT TITLE
LOGO PROJECT NUMBER

3.2.5 Early warning summary

This report identifies what Interface deliverables are due within a specified period of
days, or have already become overdue. The Early Warning dash board provides a
snapshot view of all Interface Agreements which are nearing their due date.

3.2.6 RFI Summary

This report presents a detailed summary of all RFI, listed by package and by status
(Issued, Finalized, Closed, Late). The report will also highlight the RFI that are due
within a specified period of days, or have already become overdue.

3.2.7 5NOC Log status

This report provides an overview of all items listed in the NOC Log, with a break down by
status. The Dash board can be filtered based on Participant, Package, Phase, Area,
System and Discipline.

3.3 Coordination
3.3.1 Weekly coordination meeting
This meeting will serve as the principal venue for the IM and the PIC to exchange
information, update status of deliverables and identify any potential conflicts or problems.
This meeting is not intended to resolve issues and conflicts. Resolution shall be
achieved in smaller working groups involving only personnel necessary to derive the
desired outcome. The weekly meeting will be chaired by the Interface Manager and will
cover:
 Reviewing open items on the NOC log
 Update the Interface Register’s delivery schedule for interface documents
 Discuss any other issues unit interface coordinators would like to raise
 Develop or clarify any interface procedures
 Risk review and mitigation
 Pending changes.

3.3.2 Monthly coordination meeting

This meeting will serve as the principal venue for the Interface Manager, the Partner
Interface Coordinator and the contractors’ project managers to exchange information,
update status of deliverables and identify any potential conflicts or problems. This
meeting will also serve as forum for interface decisions not achieved from at the
contractors’ project manager level. The monthly meeting will be chaired by the Interface
Coordinator and will cover:
 Status of outstanding Interface Register records that are past due
 Reviewing open items on the NOC log
 Final decision on unresolved interface points elevated beyond the contractors’
project manager level.

Page | 18 Interface Management Plan xxxx-001-0 Revision 0