Most EIR documents I've reviewed over the years are either copy-pasted boilerplate that says nothing specific to the actual project, or so exhaustively detailed that delivery teams can't realistically respond to every clause. A good EIR sits in between — specific enough to be useful, focused enough to actually get followed. Here's the structure that works.
What an EIR is actually for
The EIR is the client's statement of what information they need from the project, and when — it exists so the delivery team can respond with a realistic BIM Execution Plan (BEP) rather than guessing what's expected. It's a contractual document on any ISO 19650-aligned project, not a nice-to-have.
The core sections, with what actually belongs in each
| Section | What to actually include |
|---|---|
| 1. Strategic purpose | Why BIM is being used on this project — asset management, cost certainty, programme efficiency — stated specifically, not generically |
| 2. Information requirements | What data is needed at each project stage (design intent, construction, as-built, FM handover) — tied to actual decisions the client needs to make |
| 3. LOD/LOIN by stage | Specific level of development expected per discipline at each milestone — vague language here is the most common EIR weakness |
| 4. CDE requirements | Which platform, file naming convention, approval workflow, and access permissions are expected |
| 5. Software and format requirements | Native formats expected, IFC export requirements, and any specific software version constraints |
| 6. Roles and responsibilities | Who is expected to act as Information Manager, Task Information Manager per discipline, etc. |
| 7. Commercial/contractual references | How EIR compliance ties into payment milestones or contractual deliverables |
The mistake that makes most EIRs useless
Writing LOD requirements as a single blanket statement — "all elements to LOD 350" — ignores that different elements need different development levels at different stages. A structural column needs LOD 350 well before a furniture layout does. Specify LOD by discipline and by stage, in a simple matrix, rather than one number applied uniformly across an entire project.
What good CDE requirements actually look like
Instead of "models will be shared via a Common Data Environment," specify the actual platform (BIM 360/ACC, or whatever your organization uses), the file naming convention expected (tied to your project's information container naming standard), and who has approval authority at each status gate (Work in Progress, Shared, Published, Archived). Vague CDE language is one of the most common reasons coordination breaks down mid-project — everyone assumes a different process.
A realistic length target
A focused, project-specific EIR for a mid-sized commercial project typically runs 8-15 pages, not 80. If it's longer than that, it's likely repeating generic ISO 19650 language the delivery team already knows, rather than stating project-specific requirements they actually need clarified.
EIR and BEP authoring is one of the core skills taught in our Apex plan, alongside hands-on multi-discipline coordination. Full curriculum on the Programs page.
Frequently asked questions
Who is responsible for writing the EIR?
The client or employer (or their appointed information manager) writes the EIR. The delivery team responds with a BIM Execution Plan describing how they will meet the requirements.
What is the difference between an EIR and a BEP?
The EIR states what information the client needs and when. The BEP is the delivery team's response, describing how they will meet those requirements.
Related reading: BEP vs IPP: What Changes Under the 2026 ISO 19650 Revision
