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

Appointed Party PoV)

CHAPTER 2.4
Interface Forums & Governance
General-first teaching · Applied-to-AMIA segment · Verdict: Expert (Leaner Gauntlet: 2 Viva + 5 Red-
Team)

Program note — leaner format from this chapter onward

Given real study-time constraints, the Gauntlet is now: MCQ → Scenario (1 question)
→ Rapid-Fire → Viva (2 challenges) → Red-Team (5 items). Re-runs capped at ONE
attempt; anything still below bar is flagged 'revisit before interview' rather than
looped further. The Body is never shortened — only the review/assessment layers.

Part A — Body
2.1–2.3 gave you the instruments (interface concept, ICD, Register/Matrix/RASCI). 2.4 is
the GOVERNANCE SYSTEM that makes them move — the forum, the RFI triage rule, and
the escalation ladder.

2.4.1 The forum is where the instruments come alive

The Register tracks status; the ICD holds detail; RASCI assigns accountability. None of it
moves on its own — it moves because a recurring forum forces decisions. The Interface
Coordination Meeting (ICM) is that forum: the one place
Identify→Define→Assign→Agree happens in real time, in front of the people who can
authorise it.
Standing agenda: (1) new interfaces raised since last meeting, (2) definition &
agreement of newly raised items, (3) progress on open interfaces, (4) escalations, (5)
closures, (6) matrix review (new gaps/clusters/loops).

2.4.2 Roles in the forum

Role Function in the ICM
LAP IM (chair) Runs the agenda, drives to decisions, custodies the
register/ICDs
LAP design/technical leads Approving authority — required for the 'Agreed' gate (2.2)
Task-team technical/BIM Represent their party, commit to owner/first-mover roles
leads
Minute-taker (often the IM) The minutes ARE part of the audit trail

2.4.3 RFI triage, completed (deferred from 2.1 and 2.2)

The test: does answering it require only one party's knowledge (true RFI), or does it
expose a mutual dependency (misfiled interface)? A true RFI is answered normally, one-
way, closed. One that reveals a mutual dependency is redirected — logged as a
new/reopened entry in the Interface Register, given an owner/A and first mover, and an
ICD if significant. The RFI closes with a pointer to the new interface ID.

2.4.4 The escalation ladder (formalised)

Each level has a NAMED TRIGGER (TAT breach, contest, missed freeze, repeated non-
attendance) — escalation is never a vague judgement call, it's a defined threshold per
level.

2.4.5 The LAP lens

The forum is the one place all three instruments (Register, ICD, RASCI) and the
escalation ladder physically meet. As LAP IM, your job in the room isn't to resolve
interfaces — it's to make sure every item leaves with a decision: an owner assigned, a
status changed, or an escalation triggered. A meeting ending with 'discuss again next
week' on the same items IS the graveyard register, live.
Why the IM can't quietly suppress escalation (from the Viva)
Escalation is triggered by an OBJECTIVE, PRE-AGREED MECHANISM (the TAT breach,
the missed freeze point) — not by the IM's personal judgement on the day. Because
the register's colour-coding and the N2 chart are visible to others (not just the IM)
and reviewed in senior BIM/IM meetings, a stalled item with no escalation flag is
MORE visible and MORE damaging to the IM's credibility than escalating would be.
The system removes the IM's discretion to hide suppression.

How factual disputes are resolved (from the Viva)

When two parties disagree on THE FACTS (e.g. was delivery on time?), the ICM does
not adjudicate by whoever argues more persuasively. It is settled against the
OBJECTIVE RECORD: the ICD's dated resolution log and the register's timestamped
CDE container history — what was actually submitted, when, against the agreed
LOIN/date. Only genuine ambiguity in that record (rare) needs human technical
adjudication at L2, and even then against the AGREED DEFINITION in the ICD, not
either party's account.

Applied to AMIA APM

The weekly ICM is where L&T's IM coordinates signalling, traction power, comms,
PSD and rolling stock leads alongside the Fixed-Facility (civil) contractor — the cross-
boundary forum the JD's #1 responsibility requires. RFI triage matters especially at
the systems↔civil seam, where a routine civil RFI about embed clearances could
mask an unregistered interface.
Part B — Doubts
None raised for this chapter.

Part C — MCQ (Recall) — 30/30

Q1. What is the ICM, correctly defined?
A) A one-time kickoff meeting held only at project start
B) The recurring forum where Identify→Define→Assign→Agree happens in real time with
authority present ✓
C) A sub-committee that replaces the Interface Register
D) An optional catch-up with no decision-making authority
Feedback: 10/10.
Q2. What is the correct RFI triage rule?
E) Always answer it directly — RFIs and interfaces are unrelated
F) Screen it first: one-party knowledge stays RFI; mutual dependency redirects to the
register ✓
G) Log every RFI in the Interface Register regardless of content
H) Escalate every RFI straight to the stage gate
Feedback: 10/10.
Q3. What is the correct order of the escalation ladder?
I) Level 0 → Level 3 → Level 1 → Level 2
J) Level 0 (peer) → Level 1 (ICM) → Level 2 (LAP authority) → Level 3 (stage gate) ✓
K) No fixed order — ad hoc
L) Level 3 always happens first
Feedback: 10/10. All three formalised concepts you'd already been applying correctly
for three chapters.
Part D — Scenario (Application) — 8/10 (after 1 re-run)
Prompt: Chair the weekly ICM. Three 'still open, no change' items: a genuine peer
negotiation in progress; one that silently missed TAT; one misfiled item that should
have been an RFI. Handle all three within the meeting and name the ONE governing
principle tying the handling together.
Learner answer (summary): #1: ask for progress + tentative freeze date for closure
evidence. #2: ask for a revised date, check baseline schedule buffer before granting or
forcing closure. #3: instruct the party to raise an RFI + add peer review to prevent
recurrence.
Evaluation — 7/10
#1 and #2 strong — pulling toward a freeze point, and checking the baseline BUFFER
before granting a revised date is genuine programme-risk thinking.
● #3: said the misfiled item should be 'deleted from the N2 chart' / 'void in the
register.' Wrong direction — never delete; RETIRE/RECLASSIFY the row with an audit
note (why the ID was issued, why it's now void). The N2 chart is a derived view (2.3)
— it auto-reflects the register's corrected state, never edited directly.
Missing: the ONE governing principle the question asked for — no item leaves the
ICM without a state change (a date, an escalation, or a reclassification).

Re-run — 8/10 CLEARS

Corrected: 'mark as void with a note showing why the ID was issued and why it is
now void' — status change, not deletion, audit trail intact.
Governing principle stated: 'no interface issue leaves the ICM discussion without an
update and a state mark; preference is agreement and resolution.'

Part E — Rapid-Fire (Terminology) — 8/8

# Definition Answer Verdict
1 Recurring forum, decisions in real time, ICM ✓
authority present
2 Test to redirect an RFI to the register RFI triage → ✓ (2nd pass)
mutual-
dependency test
3 Correct action on a misfiled register row Mark void + ✓
remarks
4 Escalation Level 1 ICM discussion ✓
5 Escalation Level 3 Stage Gate Review ✓
Meeting
6 Trigger: Level 0 → Level 1 TAT breach ✓
7 Principle banning 'discuss again next week' Resolution-or- ✓
state-mark
# Definition Answer Verdict
principle
8 Instrument the N2 chart is derived from Interface Register ✓
8/8 — CLEARED. Only #2 needed a second pass to land on the TEST rather than the
process NAME — the familiar precision thread, now essentially self-correcting.
Part F — Viva Cross-Examination (2 challenges) — 8 · 8
Challenge 1 — “An IM might quietly avoid escalating to protect their reputation.”
Panel: What stops an IM from just not escalating, letting things sit at Level 0/1 forever?
Answer (summary): First pass explained the ladder mechanics and reframed away from
the premise ('it's not reputation, it's unresponsive parties') — 6/10, dodged the actual
question. Re-run named the mechanism directly: escalation is automatic, colour-coded
in the Register AND the N2 chart, visible in the BIM/IM review meeting and report —
8/10 CLEARS.
Evaluation
Escalation is triggered mechanically (a missed TAT/freeze point), not by the IM's
judgement. Because the Register and N2 chart are colour-coded and visible to senior
stakeholders independently of the IM, a stalled unescalated item is MORE visible and
MORE damaging than escalating — the system removes the IM's discretion to hide
suppression.

Challenge 2 — factual dispute: Party A says delivered on time, Party B disputes it.
Panel: How does governance resolve a disagreement about the FACTS, not just what to
do about it?
Answer (summary): First pass gave a resolution PATH (escalate to L2, LAP reviews, sets
revised freeze point) without naming what the dispute is checked AGAINST — 6/10. Re-
run named it: the record in the Interface Register + the CDE info container holding the
approved closure evidence; further disputes after approval go to L3 (LAP Technical
Head) — 8/10 CLEARS.
Evaluation
Disputes aren't settled by argument — they're settled against the OBJECTIVE
RECORD: the ICD's dated resolution log and the register's timestamped CDE container
(what was submitted, when, against the agreed LOIN/date). Only genuine ambiguity
in that record needs human technical adjudication, and even then against the ICD's
agreed definition, not either party's account.
Part G — Red-Team Audit (5 items) — 9/10, all 5 found
Exhibit E: a flawed ICM governance procedure. All five planted defects found and
corrected.
# Planted defect Correct position
1 Open item stays on agenda with 'no State-change principle — must carry a
other action required, provided state mark + agreed TAT for next action;
discussed' 'discussed only' banned
2 All RFIs logged directly into the register RFI triage required first; only
regardless of content mutual/cyclical-dependency items get an
interface ID (learner's addition: a distinct
'II/IID' designation for RFI-originated
items)
3 Escalation at the IM's Objective, process-driven trigger only —
discretion/judgement TAT breach raised by either party,
verified, then registered with owner/first
mover/RASCI at the first meeting
4 Chair decides disputes by whichever Decide ONLY by closure evidence +
party is more persuasive record/audit trail — presentation is
explicitly not a merit
5 L3 is permanently closed to further ICM Rare, largely one-way in the ordinary
discussion course — but a senior mediator (LAP
PD/PMC/owner's IM) can reintroduce it to
the ICM or a dedicated workshop, with
outcomes recorded in both ICM minutes
and the ICD
● Learner enrichments captured
#2: a distinct 'II' (Interfacing Issue) designation with its own IID for interfaces that
emerge via RFI triage, preserving provenance — to be kept INSIDE the one Interface
Register (tagged by origin), not a second parallel register.
#5: the L3 re-entry mechanism via senior mediation, with mandatory dual recording
(ICM minutes + ICD) even for this rare exception.
Part H — Record: Corrections, Pattern, Key Terms, Glossary,
Deliverables
● Corrections logged
• Scenario: 'delete from N2 chart / void in register' for a misfiled item — correct
action is retire/reclassify with an audit note; never delete history.
• Viva 1 (first pass): reframed away from the premise instead of naming the
mechanism that prevents an IM hiding suppression.
• Viva 2 (first pass): gave a resolution path without naming what the dispute is
checked against (the record).

● Learner enrichments captured

• II/IID sub-designation for RFI-originated interfaces (kept inside the single register,
tagged by origin).
• L3 re-entry via senior mediation, recorded in both ICM minutes and the ICD.

▲ Tracked pattern
Consistent with Modules 1–2: content and judgement are expert; the residual is naming
the exact mechanism/term under pressure rather than describing around it. Both Viva
challenges cleared on one re-run once the question was read literally (‘what specifically’
rather than ‘how in general’). The leaner Gauntlet format (2 Viva, 5 Red-Team, 1 re-run
cap) held full rigor with meaningfully less round-trip time.

“Use This Term When…”

When you mean… Say this term
why an IM can't quietly hide non-escalation Automatic, colour-coded trigger —
removes IM discretion
how a factual dispute gets settled Against the record (ICD log + CDE
container), not persuasion
wrong fix for a misfiled register row Never delete — retire/reclassify with an
audit note
the one rule for every ICM item State-change principle: date, escalation, or
reclassification
named trigger, Level 0 to Level 1 TAT breach

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

Term Definition
ICM Interface Coordination Meeting — the recurring forum where
interface decisions are made in real time
Term Definition
RFI triage Screening test: one-party knowledge stays RFI; mutual
dependency redirects to the register
Escalation ladder Level 0 (peer) → 1 (ICM) → 2 (LAP technical authority) → 3
(stage gate/commercial), each with a named trigger
State-change principle No item leaves the ICM without a date, an escalation, or a
reclassification
Void (register status) Correct status for a misfiled/incorrect row — retained with
an audit note, never deleted
II / IID Interfacing Issue designation for interfaces that originate via
RFI triage (learner enrichment)
Evidentiary resolution Factual disputes settled against the ICD/register record, not
by argument or presentation

Score summary
Layer Score Status
MCQ 30/30 ✓ Cleared
Scenario 7→8 ✓ Cleared (1 re-run)
Rapid-Fire 8/8 ✓ Cleared
Viva 8·8 ✓ Cleared (2 challenges)
Red-Team 9/10 ✓ Cleared (5 items)
Verdict: Chapter 2.4 cleared at expert standard.

Deliverables generated with this chapter

• N2_Charts_APM_MRT_Marine.xlsx — 3-sheet sample N2 matrices (APM, MRT,
Marine), conditionally coloured.
• Interface_Register_with_RASCI_and_N2.xlsx — live register with embedded RASCI
columns + a formula-driven N2 Matrix tab that auto-derives from the register (zero
formula errors, 114 formulas) + Dashboard.
• ICD_Sample.docx — worked ICD (IF-001, signalling→PSD door control), tied to the
register above.
• ICM_Live_MoM_Tracker.xlsx — meeting-by-meeting action log showing a real
escalation/de-escalation arc plus an RFI-triage example, with an Open Actions
Summary tab.