Interface Management System
Every boundary between two parties, in one governed register.
Technical, organisational, contractual and stakeholder interfaces on a capital project are held in one numbered register, with an owner on each side, an enforceable required-by date, and the actions, meetings, decisions and documents needed to close the boundary.
- 0
- Interface types
- 0
- Roles
- 0
- Workspace areas
- 0
- Lifecycle states
Not inside an organisation. Between two of them.
Engineering clashes, lost actions and contract disputes almost never start inside a single company. They start at a boundary that two parties each assumed the other owned, tracked in a spreadsheet neither of them controls.
Each line is an interface: a commitment from one party to another, with a discipline, a required-by date and an owner on both sides. IFMS numbers every one of them and measures the project against them.
Technical and organisational interfaces in the same register.
A foundation load between disciplines and a laydown-area boundary between contractors are both interfaces: each has two parties, an obligation and a required date. Governing them in one interface-management model prevents one class of boundary from becoming invisible.
Number, title, type, discipline, responsible party, owner, required-by date, priority and status are held on the governed interface record and can be filtered individually.
- An owner on each sideResponsible organisation and owner are separate fields, because an interface without two named people is a note, not a commitment.
- Waiting on whomUnder review is held apart from open, so waiting on the other party is distinguishable from waiting on nobody.
- Escalated is explicitAn interface awaiting a decision above the interface owner carries that as its own state.
Five states, and one of them means somebody else.
An open interface is unresolved but not necessarily awaiting a specific receiving-party review. An interface under review is explicitly awaiting that review. Keeping those states distinct makes the register operationally useful rather than merely descriptive.
Eleven workspace areas, all hanging from the register.
Actions, meetings, decisions and controlled documents remain linked to the interface that generated them, rather than becoming disconnected records in separate tools.
The interface register
Every technical, organisational, contractual and stakeholder interface numbered, classified, owned on both sides and given a required-by date that the register measures against.
- Interface Register
- Projects
- Organisations
Commitments and coordination
Actions raised from interfaces and from meetings, each with an owner and a due date; meetings with their agendas and minutes; and decisions recorded against the interface they resolve.
- Actions
- Meetings
- Decisions
Evidence
Version-controlled documents attached to the interface they belong to, so the drawing, specification or data sheet at the boundary is found with the boundary rather than in a document system somewhere else.
- Documents
- Knowledge
Portfolio visibility
Executive and project dashboards with performance by responsible organisation, exceptions raised as specific findings, and governed reports with their own identity and export formats.
- Executive Dashboard
- Reports
- Report Identity
Governance
Projects, organisations and users with nine roles, configuration, deployment standard, governed data management and a full audit trail behind every change.
- Users
- Configuration
- Data Management
- Deployment Standard
- Audit Trail
The coordination meeting that finally has one list.
Owner-operators, national and international oil companies, engineering and construction contractors, project management consultancies and construction contractors all bring their own tracker to the same meeting. IFMS replaces them with one register that every party can see their own position in.
- Nine roles from tenant administrator to client representative
- Per-project scope across a multi-project portfolio
- Performance reported by responsible organisation
Performance by responsible organisation as well as by project.
Open interfaces, overdue interfaces, overdue actions and closure rate are reported by responsible organisation so each party can see the obligations attributable to it.
Two owners, not one
An interface exists between two parties, so it carries a responsible organisation and an owner on each side. There is no single accountable party to hide behind.
Escalation is a state
An interface awaiting a decision above the interface owner is escalated, and the dashboard says so as a specific finding rather than as a colour.
Performance by organisation
Open, overdue, actions overdue and closure rate are reported per responsible organisation, which is the measure a project director actually needs at a coordination meeting.
Audit behind every change
Numbering, classification, ownership, lifecycle, actions, meetings, decisions and documents all sit behind one audit trail.
More of what the application covers.
- Interface numbering and classification by discipline
- Required-by dates measured across the portfolio
- Meetings with agendas, minutes and the actions they raise
- Version-controlled documents attached to the interface
- Governed import and export of the register
- Report identity and export formats
- Nine roles from tenant administrator to client representative
- Multi-project portfolio with per-project scope
Interfaces, beside the delivery and contract systems they cross.
- PDMSPDMS: Project Delivery Management SystemPDMS governs project delivery and stage gates; IFMS governs the interfaces between the parties delivering the work.
- CMSCMS: Contracts Management SystemCMS governs the contractual obligations and notices that may sit behind a contractual interface.
- EDMSEDMS: Enterprise Document Management SystemEDMS governs controlled documents and transmittals; IFMS links the relevant evidence to the interface boundary.
- CCMSCCMS: Completion, Commissioning & Handover Management SystemCCMS governs completion and handover; IFMS identifies unresolved interfaces that may constrain readiness or gate release.
See IFMS with one of your live interfaces.
Bring one interface between two contractors. We will show the register entry it becomes, the actions and decisions that hang from it, and how it appears in the performance figures for both organisations.