BIM Information Manager — Expert Program | Module 2: Interface Management & ICDs (Lead

Appointed Party PoV)

CHAPTER 2.1
Interface Fundamentals — why complex projects live at the seams
General-first teaching · Applied-to-AMIA segment at the end · Verdict: Expert (all 5 Gauntlet layers
cleared)

How to read this chapter

Body is general (any sector). A small “Applied to AMIA APM” box follows. Assessment
= Expert Gauntlet: MCQ → Scenario → Rapid-Fire → Viva → Red-Team, each
scored /10 (pass ≥8).
● = correction logged · ● = learner enrichment · ▲ = tracked pattern · Deferrals point
to the future chapter where a topic is completed.
Chapter-level notes are issued as each chapter clears; the consolidated Module 2
glossary is issued at module close.

Part A — Body
A1. What an interface is
An interface is any boundary across which two parties, systems or elements must
exchange something — geometry, data, a physical connection, a service, a responsibility
or a signal — for the whole to work.
The principle that justifies the whole discipline
Most project failures don’t happen WITHIN a scope — they happen BETWEEN scopes.
Each party can deliver its own package perfectly and the project can still fail, because
nobody owned the gap between the packages. Interface management makes those
gaps somebody’s explicit, tracked responsibility.

A2. The interface taxonomy (7 types)

These apply on any project type — a hospital, a refinery, a data centre, a metro. Naming
the type matters because it tells you what must cross and how to govern it.

A3. Why interfaces multiply faster than scopes

For n interacting parties, the number of potential pairwise interfaces is n(n−1)/2.
Double the parties and you roughly quadruple the interfaces.

At 5 parties = 10 boundaries; at 15 = 105. Informal “just talk to each other” channels

cannot scale with this curve — which is exactly why the discipline exists: to impose
structure on a problem that grows non-linearly.

A4. Dependency direction — and breaking a deadlock

• One-way: A needs B’s output; B does not need A’s. Simple sequencing.
• Two-way: both sides depend on each other but can iterate.
 • Circular dependency: A needs B to proceed and B needs A to proceed — a deadlock.
Broken by nominating a first mover (issues preliminary information first), assigning a
single owner, and applying escalation if it stalls.
Deferral
Full treatment of dependency mapping (RASCI) and interface change/risk is
completed in Chapters 2.3 and 2.6. The one-page synthesis flowchart (types →
dependency direction → break mechanisms) is built as the Module 2 capstone visual.

A5. The interface lifecycle

[Link] — recognise and register the boundary (you can’t manage what you haven’t
named).
[Link] — what must cross, to what standard (LOIN), and when.
[Link] — name both sides, the single resolution owner, and the first mover.
[Link] — both sides + LAP approving authority accept the definition (documented in
an ICD).
[Link] / control — track status, control changes, escalate ageing interfaces.
[Link] — verify against evidence, record in the ICD, mark the register row closed.

A6. The Lead Appointed Party as system-owner (the lens)

Task teams manage the detail of interfaces they are party to — but only the party sitting
above the boundaries can see and govern the whole set. That is the LAP. As IM at LAP
level you do not personally resolve every clash; you own the system: the register, the
definitions standard, the forums, the escalation route and the audit trail. You make
interfaces visible and accountable across parties who each only see their own edge.
The ownership rule (memorise)
An interface always has two sides but must have exactly ONE owner for its resolution.
Unowned interfaces are where projects leak. Ownership must be personal (a named
individual), not organisational.

What makes the system BITE (from the Viva)

A register only changes outcomes — rather than becoming a 400-row graveyard —
when every open interface carries: (1) named personal accountability, (2) a
consequence-linked date (tied to a pour, procurement lock or design freeze, not an
arbitrary “30 days”), and (3) an automatic escalation trigger when those are
breached. Thesis: the register doesn’t solve interfaces; it makes the cost of leaving
them open visible, personal and unavoidable. You manage the accountability, not the
spreadsheet.
Applied to AMIA APM
L&T (LAP) owns interface management across the APM systems scope — signalling
↔ traction power ↔ comms ↔ PSD ↔ rolling stock — and the seams with the
Fixed Facility (civil) contractor. The BIM Information Manager runs the
register/ICD/forum system; the JD lists interface data management as responsibility
#1 precisely because an airport people-mover is a systems-integration project that
lives at the seams.
Authority note: the IM has no direct command over separate appointed parties;
leverage flows from the contract — unresolved interfaces surface as non-
conformances at stage-gate reviews adjudicated by the party that pays (DAEP).
Strongest when interface duties (IMSOP compliance) are written into each
appointment/EIR.
Part B — Doubts
No doubts raised before assessment; the learner elected to proceed and keep the
doubts door open for later (a doubt surfacing in a future chapter is cleared then and
logged back here).

Part C — MCQ (Recall) — 30/30

Q1. Why does interface management exist as a distinct discipline on large projects?
A) Because clash-detection software requires a dedicated operator
B) Because most failures occur BETWEEN scopes, not within them ✓
C) Because contracts legally require an interface manager
D) Because BIM models are too large for one team
Feedback: 10/10. Chose the principle, not the tooling/consequence distractors.
Q2. A pump must deliver a pressure a downstream process depends on. Which
interface type?
E) Physical interface
F) Spatial interface
G) Functional interface ✓
H) Contractual interface
Feedback: 10/10. What crosses is a performance dependency (functional), not the
physical connection touching it.
Q3. A project scales from 6 to 12 parties. Using n(n−1)/2, potential interfaces change
from…
I) 15 to 66 (roughly quadruples) ✓
J) 6 to 12 (simply doubles)
K) 15 to 30 (simply doubles)
L) 36 to 144 (squares)
Feedback: 10/10. Arithmetic correct (6→15, 12→66) and read the pattern (quadruples),
avoiding the ‘squares’ trap.
Part D — Scenario (Application)
Scenario 1 — the ownership problem (basement clash open 3 weeks)
Learner answer (summary): Gave the engineering fix (lower drainage on gravity fall,
hold headroom, avoid wall openings), then owner = MEP SPOC, close against a
reference drawing (BOP, slope, sections) recorded in the ICD.
Evaluation — 6/10
Right: reached Define→Assign→Agree→Close with the ownership rule; excellent
evidence-based closure discipline via the ICD.
Missed: answered the engineering fix, not the MANAGEMENT failure. The failure: the
interface was real but never registered/defined/assigned — it broke at
Identify→Assign, and no mechanism forced resolution, so it sat open in WIP for 3
weeks. Part (b) needed the standing machinery (register with status +
ageing/escalation, owner-assignment rule, recurring forum, escalation path).

Re-do 1 — 9/10 CLEARS

Built the system: an IMSOP; raise via official channel + log in the Interface Register;
weekly Interface Management Meeting to confirm viability, define resolution with
LAP approving authorities + stakeholder leads, assign owner + first mover; monitor
each meeting; close in the register. (Missing only the explicit escalation/ageing trigger
when a row stalls — the ‘spring’ that fires when the loop stalls.)

Scenario 2 — foundation embeds vs mechanical package (irreversible pour)

Learner answer (summary): Interference-coordination meeting, superimpose drawings,
get turbine cut-sheet + fixing-bolt details, 3D coordination workshop to fix position with
minimum offsets, mech team owns coordinated equipment layout over structural
layout, agree and close via ICD.
Evaluation — 7/10
Right: sound workshop-driven resolution; ownership rule applied (mech as owner).
Missed: did not NAME the interface types (data + physical + temporal/sequence);
under-solved the real trap — a CIRCULAR DEPENDENCY against an irreversible pour.
Needed the first-mover (mech issues preliminary embed data at agreed LOIN), plus a
freeze/hold point tied to the pour date with change control after freeze, and
awareness of tolerance stack-up.

Re-do 2 — 8/10 CLEARS

Named the types (sequencing + physical + data). Broke the circular dependency by
first-mover selection, mech as first mover and owner per the ownership rule;
correctly noted it is case-by-case. (Still to add: the freeze/hold point that PROTECTS
the interface after resolution before an irreversible event.)
Part E — Rapid-Fire (Terminology) — 8.5/10
# Definition Answer Verdict
1 Boundary across which two parties/systems Interface ✓
must exchange something
2 Two sides, exactly one responsible party for Ownership Rule ✓
resolution
3 Interface type = a timing/completion “sequential ○
dependency interfacing” temporal/se
quence
4 A needs B and B needs A — deadlock Circular ✓
dependency
5 Locks agreed data at a point before an Freeze point / date ✓
irreversible event
6 Party that issues its info first to break a First Mover ✓
dependency
7 Living log of each interface’s sides, owner, Interface Register ✓
status, closure
8 Formal procedure for how interfaces are Interface Control ✓ (IMSOP)
raised/run/closed SOP
Only real slip: #3 — ‘sequential interfacing’ is descriptive, not the named type. Lock
temporal / sequence interface.
Part F — Viva Cross-Examination — 8·8·8
Challenge 1 — “Isn’t your register just a graveyard?”
Panel: A beautiful register that documents problems but doesn’t solve them — prove
you’re not just a spreadsheet administrator.
Answer (summary): First attempt returned to machinery (weekly meeting, freeze point,
progress report) — 6/10. Re-run named the actual variable: person-wise accountability
+ TAT threshold + senior escalation trigger — 8/10 CLEARS.
Evaluation
The difference between a live register and a graveyard is the human accountability
system on top of it, not the tool. Refinement to reach 9–10: make the date
CONSEQUENCE-linked (tied to a pour/procurement cut-off), not merely time-based.

Model answer / named concept

Two IMs, identical register — the variable is: (1) named personal accountability, (2)
consequence-linked dates, (3) automatic escalation. ‘The register makes the cost of
leaving an interface open visible, personal and unavoidable. I manage the
accountability, not the spreadsheet.’

Challenge 2 — “You have no authority over powerful subcontractors.”

Panel: A powerful sub refuses the owner role, ignores your TAT, skips your meeting.
What actual power do you have?
Answer (summary): Located authority in the contract + stage-gate structure: subs must
pass milestone gates adjudicated by the owner (‘the person who pays’); non-
cooperation becomes a documented NC/red flag raised on behalf of the LAP — 8/10
CLEARS.
Evaluation
Correct source of authority. Sharpen: name the instrument crisply (NCR → escalation
→ stage gate → client visibility) and ensure interface duties are embedded in each
appointment/EIR so cooperation is contractual, not goodwill.

Model answer / named concept

‘My authority isn’t personal command — it flows from the contract. Non-cooperation
is logged as an interface NCR, escalated via LAP technical authority, and surfaces at
the stage gate the appointing party adjudicates. It bites because it touches payment
and client reputation — strongest when IMSOP compliance is written into their
appointment.’

Challenge 3 — “Isn’t this just clash detection with paperwork?”

Panel: Conflation trap: separate interface management from clash detection.
Answer (summary): Rejected firmly: clash/interference checking (Navisworks/Solibri) is
a small subset at BIM-coordinator level; interface management covers 6–7 types incl.
data/dependency, circular, and temporal/sequence interfaces that hit the critical path
— invisible to a clash tool — 8/10 CLEARS.
Evaluation
Clean separation, strong critical-path point. To reach 9–10, deliver the packaged one-
liner (below) rather than an unfolding argument.

Model answer / named concept

‘Clash detection is spatial, retrospective and tool-driven — it finds where two objects
already overlap in a model. Interface management is multi-dimensional, proactive
and process-driven — it manages boundaries (physical, data, functional, temporal,
systems, contractual) before they’re even modelled, most of which no geometry tool
can detect. Clash detection is one input that feeds the register; it is not the register.’
Part G — Red-Team Audit — 9/10 (6 of 6 found)
Exhibit B: a flawed draft IMSOP submitted for approval. All six planted defects found
and corrected.
# Planted defect Correct position
1 Teams resolve internally, report to LAP Kills LAP visibility; interfaces must be
after closure ‘for record’ raised, tracked live and defined/assigned
in the forum — not reported post-hoc
2 Assigned to both parties jointly, shared Violates ownership rule — two sides
equally agree, ONE owns (after resolution +
agreement)
3 Monthly review; blanket 30-day TAT for Weekly review; target date tied to
all baseline impact (the freeze point), not an
arbitrary constant
4 Navisworks clash detection = primary Clash detection is the first geometric
identification method check at coordinator level for
low/medium impact; escalate to ICM only
when unresolved — not the primary
method
5 Unresolved interface just re-tabled until Needs escalation; may stay open only if
agreement blocked by an un-produced input
(procurement/cut-sheets/method
statements/approvals) with documented
reason
6 Pour data revisable up to the day of the Data frozen at the freeze point (LAP
pour design-lead approval); post-freeze
deviation via change control with cost
impact reviewed by LAP CM
● Refinements noted
#5: keep interface escalation (technical) and personnel no-show escalation
(HR/commercial) as two distinct tracks — don’t blend them.
#6 phrasing: data is ‘locked/frozen at’ the freeze point (avoid ‘fix’, which also means
‘resolve’ in an audit doc).
Part H — Record: Corrections, Pattern, Key Terms, Glossary
● Corrections logged
• Scenario 1: answered the engineering fix instead of the management failure (level-
of-abstraction slip — answer as system-owner first).
• Rapid-Fire #3: ‘sequential interfacing’ → temporal/sequence interface.
• Red-Team #6: ‘fix’ → lock/freeze (phrasing precision).

● Learner enrichments captured

• First-mover pulled into the STANDING process (not just one scenario) as a general
deadlock-break device.
• Legitimate carve-out for keeping an interface open: blocked by an un-produced
input (procurement data, cut-sheets, method statements, logistics plans, approvals),
otherwise documented reason required. Personnel no-show escalation (max twice,
formal warnings).

▲ Tracked pattern
Under adversarial pressure, tendency to reach for tools/process rather than the
underlying principle (Viva C1), and occasional loose terminal naming/phrasing (RF #3,
RT #6). Root cause is precision-of-expression, not knowledge — corrected within one
re-run each time. Fix: when challenged ‘why does this work?’, lead with the
behavioural principle, then name the instrument.

“Use This Term When…”

When you mean… Say this term
a timing/completion dependency Temporal / sequence interface
A needs B and B needs A Circular dependency
who goes first to break the deadlock First mover
lock the data before an irreversible event Freeze / hold point
the arbitrary date is wrong — tie it to… a consequence-linked date
a stalled row must rise on its own Automatic escalation trigger
two sides but one responsible party Ownership rule (personal, not org.)
non-cooperation must be made to cost NCR surfaced at the stage gate

Terms introduced in this chapter (feeds the Module 2 glossary)

Term Definition
Interface Any boundary across which two parties/systems must
exchange something for the whole to work
Interface types Physical, spatial, functional, data/information,
Term Definition
systems/control, temporal/sequence,
contractual/organisational
n(n−1)/2 Count of potential pairwise interfaces for n parties — grows
non-linearly
Ownership rule Two sides, exactly one (named) owner for resolution
Interface lifecycle Identify → Define → Assign → Agree → Monitor/control →
Close
Circular dependency Mutual A↔B deadlock; broken by first mover + owner +
escalation
First mover Party nominated to issue its information first to break a
dependency
Freeze / hold point Point at which agreed data is locked before an irreversible
event; later change via change control
Interface Register Live list/tracker of all interfaces with status, owner, dates,
escalation flag
ICD Interface Control Document — detailed agreed record per
significant interface
IMSOP Interface Management Plan/SOP — the governing procedure
for the interface system
TAT Turnaround time / threshold for how long an interface may
stay open before escalation
Consequence-linked date Resolution date tied to a downstream event (pour,
procurement lock, design freeze)

Score summary
Layer Score Status
MCQ 30/30 ✓ Cleared
Scenario 9·8 ✓ Cleared (after re-do)
Rapid-Fire 8.5/10 ✓ Cleared
Viva 8·8·8 ✓ Cleared
Red-Team 9/10 ✓ Cleared
Verdict: Chapter 2.1 cleared at expert standard.