BIM and Facility Management, with a little help from LEGO and AI

There is a question we often forget to ask, and it became the centrepiece of a three-hour workshop I delivered last week at Politecnico di Milano as part of a BIM Management master’s programme.

When an information model is delivered to the client,
how do we know whether the client is able to use it?

It sounds simple. It is not. It’s sometimes downplayed to three possible answers:

1. If the client asked for it, it means they’re able to use it;
2. It’s not our problem if the client can’t eventually used what they paid us to deliver;
3. We could always ask them more money when they figure out they can’t use what we gave them.

I loathe all three approaches. And the fact that most BIM-FM conversations skip straight past it — into LOIN definitions, IFC schemas, CMMS integration — is precisely the problem this workshop was designed to expose.

1. How it started

A logistics problem became a pedagogical opportunity. The invitation came from the master’s programme coordination, and the brief was pretty standard: BIM for Facility Management, three hours, a cohort of students supposed to have a solid technical background already oriented toward BIM management. What was not standard was the logistics of the workshop: I would have five to eight students physically in the room, and twenty more would be connected remotely. Some from home, many from their offices, which meant they probably couldn’t speak freely, might be half-attending, and would definitely not have their hands free to do anything physical.

Sometimes these situations have a simple solution: focus on the people in the room and treat the online participants as an audience. I disagree. On ethical grounds, I’m uncomfortable about having a two-tier classroom, and on pedagogical grounds I think twenty people represent too much collective intelligence to waste on passive attendance.

So I started thinking about how to turn the constraint into content. And that is when I called in Anthropic’s Claude.

2. The AI as co-designer

I want to be specific about what that collaboration looked like, because “I used AI to help design the workshop” can mean anything from generating bullet-point lists to something considerably more substantive. In this case, it was the latter.

The conversation ran over several sessions and covered the full arc of workshop design: constraints to be turned into structure, pedagogical logic, case design, material production, facilitation guides, assessment frameworks, and closing reflection. There were many moments where I pushed back, redirected, or discarded the model’s proposals entirely, but it functioned as a genuine thinking mirror at a level that I would not have reached working alone in the same timeframe.

A few specific contributions worth naming.

1. The asymmetric information model. Early in the conversation, I described the hybrid classroom problem: online participants could not do anything physical. We came up with a situation where in-room participants might not be pushed to access digital resources in the same way. Give each group different information about the same client, make the gap between information sets the problem to be solved, and use the act of bridging that gap as the learning experience. That framing became the backbone of the entire workshop.
2. The DC Comics clients. I had already decided to use fictional clients to lower the anxiety of assessment exercises: for some reason, we’re all much more willing to make bold diagnoses about Batman than about a real organisation. Claude ran with this immediately and built three client profiles (Wayne Enterprises / Gotham City, S.T.A.R. Labs / Central City, Kal-El Inc. / Metropolis) with character-consistent organisational pathologies that mapped cleanly onto the three archetypes I needed: Batman’s overreaching desire for control turned into a high digital maturity with zero organisational grounding; the Flash constantlu running around to fix problems himself meant a medium digital maturity and a firefighting approach with poor data quality; Superman’s heroism meant expert tacit knowledge with no digital infrastructure whatsoever.
3. The dataset. No way I was going to able to produce everything I produced in the time I had. Aside from the simulated content for three different kinds of registers for a sprinkler system, including the flavoured hand-written notes of the technician in Metropolis, I was able to convert my slides and notes into organic handouts and cheatsheets, which means I’m progressively able to accomodate more and more learning styles by incrementing the variety and quantity of the content I produce within the time and money budget I have for a lesson.
4. The VALA model. I wanted to build the assessment framework around ISO 55000’s four fundamentals — Value, Alignment, Leadership, Assurance — but needed a way to make them operational as diagnostic tools rather than abstract principles. The acronym VALA emerged in conversation, along with a maturity scale that mapped the four fundamentals onto four organisational levels. The framework is shaped, vetted against the standard; AI polished the scaffolding and iterated it through some case studies I had in the archive.

What Claude could not do — and did not try to do — was replace domain knowledge. When the conversation moved into ISO 19650 territory, into the OIR→AIR→AIM chain, into the relationship between LOIN and client maturity, I was the one holding the substance. The model couldn’t access data and was as confused as your regular students when it came to LOD, LOI and LOIN. The AI was useful precisely because it could hold the structure while I focused on the content, and vice versa.

3. The Workshop Structure: a three-act exercise

3.1. The setup

Each of the three groups received a client brief — a one-page summary of their fictional client’s situation and stated goal — printed and left on the table for in-room participants, shared digitally with remote ones. The brief was deliberately thin: it told them what the client wanted, not what the client actually had.

Each group also received two packages of information about their client’s sprinkler system, chosen because it is safety-critical, subject to mandatory inspection regimes, and simple enough to use as a proxy without requiring specialist knowledge.

The physical package (in-room only) was an assembled set of LEGO components representing the assets, with labels attached. The labels were the first source of evidence: an inspection tag showing twelve quarterly inspections all marked “OK” with identical pressure readings, a maintenance intervention record with real specificity, and a note referring to a site binder that was conspicuously absent from the crate.

The digital package (on which remote participants could focus) was a document — an Excel spreadsheet or a Word report depending on the case — containing digital maintenance records, asset registers, or dashboards. Each document had a hidden problem: data that looked complete but was hollow, specifications that were technically impossible, or an email that reframed everything you thought you knew.

The asymmetry was the point I was describing: neither group had enough information on its own. The in-room team could touch things but had less insight on digital context; the remote team had data but no physical reference. They had to communicate — through chat, shared documents, whatever they could manage — to build a coherent picture. And the coherent picture, in every case, revealed something the client did not know about itself.

3.2. Understand what you have

Each group worked through a guided observation exercise with questions designed to move from surface reading to critical analysis, questions that told them where to look. This step took longer than planned. Students needed more time than the original 20-minute estimate to move from seeing a list of inspections to notice that all the pressure readings are identical, which should not be possible if these inspections actually happened. The transition from reading data to questioning it is slower than it looks on paper, and in retrospect it deserved more space.

The shared moment at the end of Step 1, when in-room and remote teams compared notes, was the most critical part of the afternoon. In every group, there was a moment of genuine surprise. So the dashboard says everything is fine, but you’re telling me the component looks forty years old? That surprise is what client engagement actually feels like.

3.3. Step 2: assess

After a brief plenary lecture introducing the assessment framework, each group applied the VALA model to their client case.

The lecture covered three things: the distinction between an asset, asset management, and an asset management system (a distinction that ISO 55000 makes carefully and practitioners collapse constantly); a four-level maturity scale derived from that distinction; and the four VALA fundamentals as diagnostic lenses.

The maturity scale is worth presenting in full, because it is the framework I would propose for anyone doing this kind of work.

The VALA assessment asked students to score each of the four fundamentals for their client and identify a root cause, the single weakness driving the others. This is where the exercise became genuinely diagnostic rather than descriptive. The three clients produced three different profiles.

Wayne Enterprises has a sophisticated digital infrastructure, but no one had ever cross-checked the data against the physical assets, and the consequence was a component specification in the system that referred to a product not commercially available until nine years after the building was completed. The system said something, and the building said otherwise.

S.T.A.R. Labs might land at Operational overall, with Assurance at Reactive. The gap here is different: they had good data on extraordinary interventions and hollow data on routine ones. Twelve quarterly inspections, all marked with identical pressure readings, all signed off by the same person who also filled in the forms si not a process: it’s a ritual with compliance in mind.

Kal-El Inc. landed at Reactive across the board, with Leadership as the root cause. Mr Man knew everything. The organisation knew nothing. Not because the organisation was incompetent, but because it had never needed to. Mr Man had been there for twenty-two years and showed no signs of leaving. Until he did.

The pattern that emerged across all three cases: Assurance is almost always the weakest fundamental, even for organisations that believe they have it, and some root cause always lies in Leadership. The dashboard is not assurance. The filled-in form is not assurance. Assurance is a process — verifiable, repeatable, independent — that checks whether what the system says is true. Most organisations have the appearance of assurance. Very few have the substance.

3.4. Step 3: propose a strategy

Armed with the VALA assessment, each group could build at least the first step of a three-phase strategic proposal for their client, following a framework anchored in ISO 19650’s information chain: OIR → AIR → AIM.

Two principles should govern the proposals:

1. The root cause comes first. Whatever VALA fundamental is driving the others is what Phase 1 must address: a technically sophisticated AIM built on top of an unresolved Leadership or Assurance problem will not be used, will not be trusted, and will decay. Wayne Enterprises does not need a better information model in Phase 1: they need a physical verification audit. S.T.A.R. Labs does not need a new CMMS: they need to redesign their inspection process. Kal-El Inc. does not need software: they need Mr Man in a room with whoever replaces him, for as long as it takes.
2. The Level of Information must be sustainable. The right LOI is the highest level the client can maintain without external support in twelve months’ time. An AIM with twenty attributes per asset, all verified and current, delivers more value than one with eighty attributes where sixty are stale or guessed. This is obvious when you say it aloud. It is routinely ignored in practice.

The gate conditions — what must be demonstrably true before Phase 2 begins — should generate the most interesting discussion, as it’s the definition of quality and there’s no BIM without quality assurance.

4. The closing: what we entered with, and what we left with

We closed with a reflection on the digital/physical gap, not as a problem to solve but as a structural, permanent condition to manage.

The same gap appears in every context where a digital representation must track a physical reality: the 4D model that reflects the plan but not the site, the coordinated model that was accurate at sign-off but had diverged by the time installation began, the as-built AIM that was perfect at handover and never updated again. In each case, the failure is a process failure. Someone decided — explicitly or by omission — that keeping the model honest was less important than something else.

5. On replicability

The workshop is designed to be replicated. The framework — VALA assessment, three-phase proposal, LOIN calibration — is independent of the fictional clients: you could run the same exercise with three real anonymised cases, or with three client profiles drawn from your own practice. The DC Comics wrapper is a convenience just as LEGO, in this case: they lower the anxiety of assessment and make the client personalities legible quickly, but it is not load-bearing.

The asymmetric information model is what’s load-bearing. If both groups have access to the same information, the gap disappears and with it the most important learning moment of the day: the discovery that two teams looking at the same client from different positions see fundamentally different things, and that neither picture is complete.

This means, the physical model is also load-bearing, or something like it. Remote participants working only from digital documents produce assessments that are technically competent but tend to miss the texture of physical reality: the label that contradicts the appearance, the component that looks its age, the absence of a document that should be there. That texture is not decorative. It is the substance of what field assessment actually is.

6. A note on the standards

Everything in this workshop is anchored in ISO 55000 and ISO 19650. The VALA model is derived directly from the four fundamentals of asset management as defined in ISO 55000 §2.4.2. The maturity scale maps onto the progression from having assets to having a system that realises value from them consistently. The OIR→AIR→AIM chain is ISO 19650’s information management framework applied to the operational phase.

I cite the standards not to add authority but because they are genuinely useful. The ISO 55000 definitions are precise in ways that matter: the distinction between an asset, asset management, and an asset management system is the difference between organisations that have dashboards and organisations that have assurance. Students who have read the standard recognise the derivation; students who have not can take it as an introduction.

One note for completeness: the ISO 55000 version I worked from for the workshop is the 2014 edition. The 2024 revision exists and I referenced it in the slides. The fundamentals are consistent across versions; the vocabulary has been refined. Use the most current version.

All workshop materials described in this article — assessment guides, VALA sheets, client briefs, facilitation notes — are available on request. The framework is open for use and adaptation with attribution. Go out there and make a difference.