There’s a game I’d like to play (queue The Cranberries): take two EIRs from the last month, any project really, and delete project name and phase. Then place them in front of somebody else and ask them to guess. Which kind of project? Is it a school? A hotel? A renovation? A new construction? In many cases, they won’t be able to tell.
The structure will be familiar. The clauses will be familiar. The LOD tables, the lists of deliverables, the references to standards, the matrices of responsibilities (if any) might all be technically correct, all formally aligned with best practice, and yet remain strangely interchangeable. What should be the most stage-specific document in the procurement process of a project often reads like a generic declaration. The vocabulary changes slightly, the logo in the header is different, but the informational ambition remains indistinguishable.
This is the template trap.
Mind you: templates are not the problem in themselves. I work in standard development, and it would be weird if I said that. Templates are necessary instruments for consistency and efficiency. The problem begins when templates are inherited instead of designed. When the EIR is assembled without knowledge, clauses are copied from previous tenders, expanded to cover some frequent scenarios, and rarely removed even when they do not apply. The EIR often is a document that appears thorough but lacks strategic sharpness: this week we’ll see how that happens, and how to avoid it.
1. The Outsourced Responsibility
If the template trap might explain why many EIRs look the same, outsourced responsibility explains why they are disconnected from the project’s actual goals.
In many organisations, especially for public procurement, the drafting of the EIR is delegated almost entirely to external so-called BIM consultants. I know because I’m one of them, sometimes. On paper, this makes sense: digital specialists are expected to know standards, formats, interoperability constraints, naming conventions, and contractual structures. They are fluent in the language of ISO 19650, in information containers, in data drops and CDE workflows. The problem is not competence. The problem is distance.
When digital strategy is outsourced, it risks becoming a silo: the consultant can structure information, but cannot define its value in isolation. They can specify how information should be delivered, but often lack visibility on why certain information matters more than other data for that specific asset. Operational priorities, maintenance philosophies, risk tolerances, long-term investment strategies are rarely written into the brief with clarity. They sit inside the organisation, fragmented across departments, sometimes deliberately protected.
Our industry has a complicated relationship with information. Operational knowledge is frequently treated as proprietary, as leverage, sometimes even as internal politics. Access is granted selectively. BIM consultants — especially when they are (or they are perceived as) younger professionals — are considered technical operators rather than strategic actors. They are brought in to “BIM” (whatever that means) not to investigate or question the asset strategy. They are considered too junior, too specialised, or simply outside the circle of trust required to access financial, operational or political intelligence about the project. The result is predictable: requirements are written without full operational insight.
If the consultant does not know how the facility will be procured, maintained, financed, or repurposed, the EIR cannot meaningfully align information to lifecycle value. It becomes a technically correct document floating above the real economics of the asset.
There is also a generational dimension to this problem: BIM expertise emerged in a cohort that, in many markets, is younger than the traditional decision-makers who control budgets and strategic direction.
This creates a tragic asymmetry:
- those who understand digital information structures often do not hold institutional power;
- those who hold power do not always fully grasp the implications of information governance.
The EIR is then positioned as a technical annex rather than as a strategic instrument, and that creates a governance vacuum.
If the client delegates authorship of the EIR but does not internalise ownership of its intent, who actually owns the information model, in the Agile sense of the word? Is it the consultant who wrote the requirements, who’ll probably be long gone when the project is awarded and kicks off? The design team who populates the models according to requirements there’s no one left to understand? The dude who federates them, who might be another clueless consultant? Those who inherit the models at the end of a long and winding process?
Too often, the answer is unclear.
And this ambiguity becomes even more critical when we recognise a simple fact: the information embedded in the model increasingly carries more operational relevance than the information printed on drawings, and not just from a legal standpoint (as is the case in Italy, at least on paper). Drawings describe geometry at a moment in time. Structured model data, if defined properly, can describe performance, maintenance cycles, warranties, spatial relationships, asset hierarchies, and might influence decisions long after construction ends. Do you really want to outsource it as if it doesn’t matter? If governance of that information is outsourced without strategic oversight, the most valuable layer of the project is left without a clear political owner. An EIR, in that context, is failing because it is politically unanchored.
2. How to Anchor It Back
2.1 From Delegation to Co-Authorship
If the problem begins with delegation, the correction begins with presence.
The most common instruction given to BIM consultants at the procurement stage is: “Write us an EIR,” which doesn’t mean jack shit. Even if it suggests trust in expertise, it implies disinterest: the task is seen as primarily technical — a matter of standards, exchange formats, naming conventions, model progression tables — while what’s being delegated is the definition of value.
When the drafting of the EIR is treated as a service to be delivered in isolation, the client steps away from the very moment where strategic clarity is most needed, whether it’s unintentionally or because they’re jackasses. The consultant, in the context of this approach, often receives fragments: a brief, a timeline, never a capital expenditure estimate, a maintenance aspiration if they’re lucky. Rarely do they receive structured access to the reasoning behind the asset. What risks are being prioritised? No one knows. What operational model is being pursued? They think “6d” means something. What performance indicators actually matter five years after handover? Who cares. Without this intelligence, the EIR can only approximate relevance. What you need here isn’t a consultant: it’s a sorcerer.
My proposal? Instead of outsourcing the document, organisations can design structured working sessions where requirements are defined collectively. Not as open brainstorming, because clients don’t have the expertise to talk about LODs, but as facilitated conversations in which the consultant helps to translate project goals into clear modelling and information management objectives: identify the lifecycle decisions that will shape the asset, surface the operational constraints that are usually implicit, articulate the risks that information must mitigate. In that room, digital consultants are translators instead of scribes (or sorcerers), who convert strategic intent into structured information requirements. And, most importantly, operational stakeholders turn from passive recipients to active parties who clarify what data will actually be used. Senior decision-makers are not distant signatories; they make explicit the priorities that will govern trade-offs.
This shift might make the process slower, but also makes it anchored. We like anchors. Especially if Barbossa comes down on them.
It also dissolves the artificial boundary between technical and strategic. When digital specialists who might be junior are invited into conversations about asset performance, financing structures or long-term maintenance models, they gain the context necessary to write meaningful requirements. Conversely, when leaders who might be senior are exposed to the implications of data structures and interoperability constraints, they begin to understand that information governance is not an IT issue but an organisational one.
Co-authorship, even if I’m a fan, isn’t about consensus for its own sake: it’s about alignment. An EIR produced through shared definition carries traceable intent and it’s a document where each requirement can be linked back to a decision, a risk, or an operational objective that was explicitly discussed. The document becomes less verbose but more deliberate. Less defensive, but more accountable.
In that configuration, the EIR stops being an outsourced artefact and starts becoming what it was always meant to be: a structured expression of collective responsibility. And trust me, I’m speaking against my best interest because it’s technically more work for the consultant.
2.2 Sharing the Knowledge
I hate to state the obvious, but co-authorship only works if the knowledge in the room is real.
One of the quiet obstacles in defining meaningful information requirements is the assumption that operational and financial intelligence is too sensitive to be shared. Asset performance data, maintenance cost structures, risk exposure models, contractual constraints, insurance frameworks are often treated as confidential by default. The result is a paradox: the EIR is expected to define the information backbone of the asset, yet the people drafting it are shielded from understanding the asset’s economic and operational logic.
In practice, much of this caution is cultural rather than legal. Because I’m feeling too kind to simply say it’s bullshit.
If information is genuinely confidential, the mechanism to protect it is straightforward: a non-disclosure agreement can be drafted in a matter of hours, clearly defining scope, duration, permitted use, and liability. The legal infrastructure for controlled information sharing already exists in every serious project environment. The barrier is rarely procedural complexity, but discomfort: the instinct to retain control by limiting visibility.
It is also important to distinguish between information that is strategically sensitive and information that is simply internal.
Sensitive information, in its strict sense, is data whose disclosure would materially damage competitive position, violate regulatory obligations, compromise security, or expose the organisation to financial or legal harm. Trade secrets, acquisition strategies, personal data protected by law, security infrastructure vulnerabilities are legitimately restricted domains.
But many of the elements required to define a robust EIR do not fall into that category. High-level maintenance strategies, asset performance targets, lifecycle cost assumptions, risk allocation logic, intended procurement models are not trade secrets. They are structural parameters.
When such information is withheld, consultants are forced to reverse-engineer intent from surface indicators, and they compensate by over-specifying deliverables, defaulting to industry templates or requesting comprehensive datasets “just in case.” What looks like excessive technical ambition is often an attempt to manage uncertainty created upstream.
Also, opening access does not mean dissolving boundaries: it means being precise about what truly requires protection and what simply requires clarity. Controlled transparency allows digital specialists to align information structures with operational priorities. It enables them to understand, for example, whether granular asset tagging is critical because the client operates an intensive preventive maintenance regime, or whether spatial data accuracy matters more due to leasing models or regulatory reporting requirements. If it sounds like gibberish, that’s why I draft EIRs and you probably don’t, but please talk to me. When invisible knowledge remains invisible, the EIR becomes generic by necessity. When context is shared, even selectively and under agreement, requirements gain direction.
Last but not least, the act of sharing signals that information governance is a collective responsibility rather than a technical service. And it transforms the drafting of the EIR from a speculative exercise into a grounded one, rooted in the real economics and risks of the asset it is meant to support. In short, a work that carries and generates value.
I believe that’s why you pay me.
No Comments