This template is the result of studying and working with multiple real BIM Execution Plans from different projects, companies and sectors, keeping only the sections that add genuine value to the delivery of the asset, and discarding the ones that just add noise.

Throughout this post you’ll find comments I’ve added along the way, to give context and share my own opinion on certain decisions. At the end of the page you can find the template without comments, ready to download and watermark-free, in different formats. For any corrections, errors, or if you disagree with something, reach out at hello@gonzalojl.com.

Among all the references used to draft this BEP, priority has been given to the following sources:

• ISO 19650
• RIBA Plan of Work 2020 This template assumes a project running in a cloud-based collaborative environment, with multiple companies involved, using Autodesk Forma as the CDE hub.

[!caution] Disclamer Since a BEP is a contractual document, signed by every party involved and legally binding, sometimes its whole value is putting the obvious in writing, so nobody can later claim it wasn’t agreed. I’d also add: I take no responsibility for any legal issues arising from the use of this document.

BEP TEMPLATE

This can’t be a static document, just like a Revit model keeps evolving, so does the BEP. On every project there must be someone responsible, the BIM Manager, for keeping it updated with the key decisions made as the project progresses.

INDEX

SECTION 1: PROJECT OVERVIEW SECTION 2: PROJECT TEAM & BIM ROLES SECTION 3: BIM OBJECTIVES & USES SECTION 4: DELIVERABLES & PROGRAMME SECTION 5: MODEL STRATEGY SECTION 6: NAMING INFORMATION STANDARDS SECTION 7: COLLABORATION & CDE SECTION 8: COORDINATION SECTION 9: QUALITY CONTROL SECTION 10: TECHNICAL REQUIREMENTS SECTION 11: MODELLING GUIDELINES SECTION 12: ASSET INFORMATION

DOCUMENT CONTROL

Revision: incremented on every BEP modification, see Revision History below. Status: Opinions vary a lot here, every project defines its own. Keep it simple: don’t overcomplicate it with cryptic codes. For the BEP itself, “S0 Work in Progress / S1 Shared for review / A1 Authorized for use” is enough.

Revision History

Changes to the information management approach generate a new row in this table. Rev format: P0X during design/pre-construction, C0X during construction (per ISO 19650 National Annex convention).

SECTION 1: PROJECT OVERVIEW

1.1 Project Summary

Some projects also track fields like Number of Buildings, Number of Floors, Planned Construction Start, Planned Completion, or BEP Applicable Stage(s). Worth adding if they bring real value to your project.

1.2 Project Description

Add a short description of the building here. It should make clear the typology, the functional programme, and any particularity of the project relevant to BIM. A couple of examples:

New-build outpatient healthcare facility, 12,000 m² GIA, comprising 3 floors of clinical consultation rooms, diagnostic imaging suite, and administrative offices. The project will be delivered in two phases: Phase 1 (structure and envelope) and Phase 2 (fit-out and MEP), with Phase 1 handover required before Phase 2 design is finalised. MEP coordination is critical due to the density of medical equipment services.

Refurbishment and extension of an existing 1960s office building, retaining the original structural frame while adding a new top floor and full MEP replacement. Existing conditions are only partially documented, so point cloud survey data will be used as the basis for the existing-conditions model. No phased occupation — building will be fully vacated during works.

[FILL IN: brief project description]

1.3 Project Phases & Key Milestones

*This BEP uses the RIBA Plan of Work 2020 as the project stage framework, aligned with ISO 19650-2 information delivery milestones. For more information about Stages or Key Information Deliverables check source.

Bim Manager should complete start/end dates and key deliverables for the stages applicable to this project. Mark stages not in scope as N/A.

Detailed deliverable requirements per stage — file format, responsible party and submission date, are defined in Section 4 (Deliverables & Programme). LOD requirements per stage and element category are defined in Section 5 (Model Strategy).*

1.4 Reference Documents & Applicable Standards

*List every document that governs or informs this BEP, grouped in three blocks:

1.4.1 The client’s own requirements: EIR, AIR, Project Brief, etc 1.4.2 The standards and protocols this BEP follows: ISO 19650 series, national annexes, classification systems, other. 1.4.3 Project-specific reference material: surveys, geotechnical reports, planning permissions, etc.

*BEPs typically merge these into a single document list. This template splits them into three blocks: client-issued, industry standards, and project-specific so it’s clear who owns each document and who’s responsible for keeping it current.

The BEP shall be read in conjunction with all documents listed below; if there’s a conflict, the EIR takes precedence.*

1.4.1 Client Requirements

Reference: code the client has given the document (their referencing system, not yours). Version / Date: which version or issue date you’re working from. Issuer: the client, or a consultant acting on their behalf.

If no formal EIR has been issued by the client, note this explicitly: “No formal EIR has been issued. This BEP has been developed based on the project brief and agreed team protocols.” The EIR/AIR compliance summary is provided in Appendix G.

1.4.2 Standards & Protocols

This BEP is developed in accordance with the ISO 19650 series (Parts 1, 2, and where applicable 3 and 5), [National standard/annex, if applicable — e.g. BS EN ISO 19650], and [Classification system, e.g. Uniclass 2015 — only if required by the EIR].

1.4.3 Project Reference Documents

Reference / Location in CDE: where the file lives in the project’s CDE (folder/path). Notes: free text for context (e.g. “ground floor only”, “pending surveyor”)

This section earns its keep when someone new joins the project, they know exactly where to find the key project documents, all centralised in the BEP.

1.5 BEP Scope & Limitations

Que cubre el BEP -> In Scope Que no cubre el BEP -> Out of Scope Quien se encarga de mantenerlo actualizado -> BEP Maintenance

In Scope

This BEP governs the production, management and exchange of information for the following:

• All BIM models produced by the Appointed Parties listed in Section 2
• All project stages identified in Section 1.3
• All disciplines: [FILL IN: e.g. Architecture, Structure, MEP, Civil, Landscape]
• The Common Data Environment defined in Section 7

Out of Scope

The following are explicitly excluded from this BEP unless a separate agreement is reached:

• [FILL IN: e.g. Specialist subcontractor BIM, FM BIM post-handover, geospatial data management, facade engineering, etc]

If any party whose BIM work is out of scope of this BEP shall define their own information management approach and communicate it to the BIM Manager for coordination purposes.

BEP Maintenance

This is a live document, reviewed and updated by the BIM Manager at every project stage gate. Any substantive change to the information management approach triggers a new revision (see Revision History). Storage and version control follow the CDE workflow states defined in Section 7.

SECTION 2: PROJECT TEAM & BIM ROLES

2.1 Project Parties

• *Organisation: All organisations involved in the project.
• Project Role: The organisation’s function on this project (e.g. Lead Designer, Structural Engineer, Main Contractor).
• ISO 19650 Classification: Appointing Party / Lead Appointed Party / Appointed Party. (Defined in ISO 19650-2 clause 3.)
• Abbreviation code: this code will be used throughout this BEP and in all file naming (see Section 6.2). Codes shall be 2–6 alphanumeric characters, uppercase, no spaces.*

2.2 BIM Roles, Responsibilities & Contact Directory

*I’ve seen some BEPs describe in detail what each role does. I rely on the RACI matrix below instead, it leaves no ambiguity about who’s responsible for what, activity by activity.

BIM Manager

Project-wide role, responsible for the overall information management strategy across all appointed parties. Point of contact with the Appointing Party on all BIM matters

BIM Coordinator

Responsible for BIM production within a single discipline or appointed party. Reports progress and issues to the BIM Manager

BIM Author / Modeller

Responsible for day-to-day production of BIM models under the direction of their BIM Coordinator. Flags issues, clashes or standard deviations to the BIM Coordinator immediately

This table is for contact assignment only, responsibility per activity is defined in the RACI matrix below.

Since Modellers tend to rotate on larger projects, I’d recommend listing the responsible organisation rather than an individual’s name for that row.

2.3 Responsibilities Matrix (RACI)

This matrix follows the same logic as the Information Management Assignment Matrix in ISO 19650-2 Annex A (clause 5.1.1), adapted here to project-level functional roles (BIM Manager / Coordinator / Author) rather than the ISO’s contractual parties (Appointing Party / Lead Appointed Party). For the ISO original, see UK BIM Framework Guidance Part A.

The Appointing Party’s level of involvement varies by project. On projects where the client has an active BIM function, their role may extend to R/A on review and acceptance activities. On projects where the client is passive, their column will be predominantly I. Adjust accordingly.

2.4 Software & Tools

*These are proposed as a starting point, as they are the most widely adopted in the industry globally. Adjust to your project’s actual software stack.

SECTION 3: BIM OBJECTIVES & USES

3.1 BIM Objectives

Each row starts as a client requirement, pulled from the EIR, or as something the delivery team proposes because it adds value to the project. In the first column, turn the need into an objective, then assign it a BIM Use. Finally, set a priority, keep in mind, if everything is high priority, nothing is. The table is a generic starting point; adjust it to the real project.

3.2 Excluded BIM Uses

• Energy Analysis
• Lighting Analysis
• Structural Analysis
• HVAC Analysis
• Other Engineering Analysis (acoustic, evacuation, geotechnical…)
• Sustainability Certification (LEED / BREEAM…)
• Virtual Reality / Virtual Tour
• Construction System Design
• Construction Site Logistics Planning
• 4D Sequencing / Detailed Construction Planning
• Site Instruction Issuance
• Digital Fabrication
• Emergency / Disaster Planning

Declaring exclusions explicitly here, rather than leaving them unmentioned, avoids disputes later about what the model was supposed to cover.

SECTION 4: DELIVERABLES & PROGRAMME

4.1 Deliverable Formats

*These are proposed as a starting point, as they are the most widely adopted in the industry globally. Adjust to your project’s actual software stack.

4.2 Information Delivery Plan (TIDP/MIDP)

Per ISO 19650-2, each task team maintains its own Task Information Delivery Plan (TIDP): what it will deliver, at what LOD, in what format, and by when. The Master Information Delivery Plan (MIDP) is the BIM Manager’s compilation of every TIDP into a single project-wide delivery schedule (see RACI, 2.3).

Both are living schedules, updated far more frequently than this BEP, and are maintained outside it: [FILL IN: location in CDE where TIDPs and the compiled MIDP are stored].

*I keep dates/LOD/format out of the BEP itself, they change weekly, the BEP doesn’t. Its job here is just to say the mechanism exists and where to find it, not to hold a copy that goes stale in days.

SECTION 5: MODEL STRATEGY

5.1 Model Breakdown Structure

For projects above a certain size, the project model isn’t a single file, it’s split into several independent native models, each with a defined scope, which are then federated for coordination and clash detection (see 2.4 and 4.1). This split is usually driven by two criteria:

• By discipline: Architecture, Structure, MEP (and its sub-disciplines where the project warrants it: HVAC, Plumbing, Electrical…), Landscape, etc.
• By volume / building / zone: when the project has multiple buildings, independent construction phases, or zones large enough that splitting them improves model performance.

Add a short description of the split strategy here. If the strategy combines discipline and zone, it’s worth attaching an explanatory diagram. A couple of examples:

- Single-building project: models are split by discipline only, Architecture, Structure, MEP (with HVAC, Plumbing, and Electrical as separate models if project size justifies it). No further split needed.

- Multi-building project: models are split by discipline and by volume, e.g. ARC Floor 1–3, ARC Floor 4–6, STR Floor 1–3, STR Floor 4–6, PLU Floor 1–3, PLU Floor 4–6.

[FILL IN: describe, using one of the strategies above, how models are split on this project]

This section is not a model register. The full, up-to-date list of models is maintained in the Model Register, outside this document: [FILL IN: CDE location].

Like the TIDP/MIDP (see 4.2), this register changes more frequently than the BEP itself — this subsection only fixes the split criterion, not the list itself.

5.2 Model Ownership

Model ownership defines who holds legal title to each model (separate from who is responsible for producing it (see RACI, 2.3)). This matters for reuse rights after handover, liability if a model is used beyond its original purpose, and what happens if a party leaves the project.

Two contractual approaches are common:

Client ownership: the Appointing Party(Client) becomes owner of all models upon delivery, regardless of who authored them.

Author ownership: each Task Team retains ownership of the model(s) it produces, and grants the Client a usage licence sufficient for the project’s purposes (coordination, handover, FM).

Which one applies is a contractual decision, not a BIM one. Check the appointment/contract documents before filling this in. If they’re silent on it, flag it back to the Client rather than assuming.

[FILL IN: state which ownership approach applies to this project; if ownership isn't uniform across all models, you can list the exceptions by discipline here]

5.3 LOD Requirements

Not every element in the model needs to reach the same LOD at the same time. This subsection sets a baseline LOD range per stage for the model as a whole, then lists the exceptions, element categories or families that need to reach a higher LOD earlier.

[FILL IN: list any element categories or specific families that deviate from the stage baseline above, and state their target LOD]

Examples of typical exceptions: structural connections and MEP distribution routing (ducts, pipes, cable trays) often need to reach LOD 350 earlier than the rest of the model, since 3D Coordination depends on it. Generic equipment, furniture, and landscaping usually stay at LOD 200 well into later stages, since they don’t affect coordination and their real geometry isn’t known until procurement.

Modelling elements to a higher LOD than the stage actually requires slows the model down and adds rework for no practical benefit. LOD should match what that stage’s BIM Uses need, not be maximised by default.

For full element-by-element LOD definitions organised by Uniformat, this BEP defers to the BIMForum Level of Development Specification rather than reproducing it here.

5.4 Shared Coordinates / Georeferencing

The project’s real-world position is established once, in a single reference model, typically the Site/Civil model, or a dedicated datum file (see Section 6 for naming), which acts as the primary coordinate source for the whole project. Every discipline model acquires its coordinates from that reference rather than defining its own, which is what keeps all models aligned when federated for coordination.

[FILL IN: name/discipline of the reference model]

If the reference position changes (e.g. an updated topographic survey) the update is made only in the reference model, which then publishes its coordinates; every discipline model must re-acquire to pick up the change, and alignment should be re-validated in the federated coordination environment (see 2.4) before the next coordination milestone.

On campus or multi-building projects, published coordinates and a shared site model keep each building positioned correctly relative to the others, not just internally consistent.

If only part of the site is resurveyed, only the affected discipline models need to reacquire, no need to republish project-wide by default.

Model geometry close to the project’s internal origin (0,0,0) rather than at its real-world coordinates, the further elements are modelled from the origin, the more significant geometric precision errors become. Real-world position comes from the coordinate system itself, not from moving the geometry.

Responsibility for publishing and re-acquiring coordinates when the reference changes should be assigned in the RACI (2.3).

SECTION 6: NAMING INFORMATION STANDARDS

6.1 Naming Convention Principles

A structured, consistent naming convention makes it possible to sort, filter, and locate any file or model in the CDE without opening it. The same rules apply to every file, model, and drawing produced on the project, regardless of who produces it.

• Use only letters, numbers, and the field separator defined below — no spaces, no accented, non-ASCII, or special characters (# % & + ( ) : * etc.)
• Use CamelCase within each field or word segment (e.g. ElectricalPanel, not electrical panel)
• Fields always appear in the same fixed order, from broadest category to most specific
• Every field is always populated — if a field doesn’t apply to a given file, use a placeholder value (e.g. XX) rather than omitting it, so the name stays a consistent, parseable length

Fields can be separated using either a hyphen or an underscore. Both work; the important thing is applying the same choice everywhere, including at object level (Section 11).

[FILL IN: field separator used across this project — "-" or "_"]

Example (hyphen used here for illustration):

PROJ-ARC-DR-L02-A-001

PROJ -> Project code ARC -> Discipline/role DR -> File type L02 -> Level/location A -> Status/suitability code 001 -> Sequential number

This is a generic illustration, the actual field structure, order, and codes for this project are defined in 6.2.

6.2 File & Model Naming Structure

File and model names on this project follow this field structure:

[FILL IN: field structure and code tables used on this project]

The number of fields depends on the project and on company standards. Packing in more codes doesn’t make a project better organised. Focus on fields that genuinely help you sort, filter, and locate files, and avoid fields that force every discipline to relink their models each time the project moves to a new phase. In this template, and from experience, the following structure is recommended:

Project – Zone/Level – Discipline – Type – Number

*Status and Revision are deliberately left out of this core structure. They change every time a model is shared, and baking them into the file name means relinking every model that references it.

SECTION 7: COLLABORATION & CDE

7.1 CDE Platform & Structure

The project’s Common Data Environment (CDE) is [FILL IN: platform, e.g. Autodesk Construction Cloud, BIM 360, Trimble Connect].

[FILL IN: top-level folder structure or use the proposed below]

This BEP only fixes the top-level (“mother”) folders. Subfolders get created continuously as the project runs; any structure fixed here today would be outdated within days.

ISO 19650 defines four information states a container moves through as it’s developed: Work in Progress, Shared, Published, Archived. A tested, widely-used starting point:

01 WIP — editable only by the authoring task team → e.g. CAD / BIM / SHEETS / EXPORT / FAMILIES

02 SHARED — shared for coordination, comment, or review, read-only outside the authoring team → e.g. CAD / BIM

03 PUBLISHED — authorised for construction, procurement, or handover, contractual, read-only → e.g. YYYYMMDD_Description

04 ARCHIVED — superseded or closed-out information, kept for audit trail → e.g. YYYYMMDD_Description

Numeric prefixes (01_WIP, 02_SHARED…) are optional, just to force this sort order in platforms that default to alphabetical. Adapt naming to your company’s or client’s own convention.

7.2 Information States

Every information container (file, model, drawing, dataset) moves through defined states as it develops. ISO 19650-1 (clause 12) defines four, mapped to the CDE folders in 7.1.

This isn’t a strictly linear sequence, a container can move back to WIP for revision at any point, and often cycles between WIP and Shared several times before it’s ready to publish.

Each container is also assigned a status code: metadata stating its permitted use within its current state (e.g. “suitable for coordination” and “suitable for review and comment” are both Shared, but authorise different things).

[FILL IN: status code convention used on this project]

The status codes below follow the ISO 19650-2 National Annex, a UK convention, not core ISO 19650 text, but the most widely adopted set in practice in my experience. Projects outside the UK annex framework may use a reduced or different set; whatever is chosen should be documented here rather than assumed.

Work in Progress: S0: initial status

Shared (non-contractual): S1: suitable for coordination S2: suitable for information S3: suitable for review and comment S4: suitable for stage approval S6: suitable for PIM authorisation S7: suitable for AIM authorisation

Published (contractual): A1, A2… An: authorised and accepted, per stage B1, B2… Bn: partial sign-off, with comments

Published (for AIM acceptance): CR: as-constructed record

Full definitions and worked examples: UK BIM Framework Guidance Part C.

[FILL IN: model/file exchange frequency between disciplines]

Weekly exchange on a fixed day is the most consistent pattern, preferably as an automated platform publish. Frequency can flex up or down depending on the project stage.

7.3 Access & Permissions

Each task team can only edit its own WIP area, and has read-only access elsewhere in the CDE unless a container has reached Shared or Published. Publishing rights, moving a container from Shared to Published, are restricted to the BIM Manager or CDE administrator (see Responsibilities Matrix, 2.3).

The CDE owner, or the Appointing Party by default, holds sole authority to grant and revoke access at any time, without needing anyone else’s agreement. Some parties may be excluded from parts of the CDE entirely, regardless of a container’s state, for example specialist subcontractors working from issued drawings only, without access to native or coordination models.

[FILL IN: where access and permissions are configured and reviewed]

e.g. Access is managed through the Autodesk Forma Docs admin panel by the BIM Manager, and reviewed at each stage gate and whenever an organisation joins or leaves the project.

Who holds which permission changes constantly as people join and leave the project, so it isn’t listed here (same logic as the Model Register 5.1 and TIDP/MIDP 4.2). Access should be granted per company, or by named individual account if more granularity is needed.

SECTION 8: COORDINATION

8.1 Coordination Process

Coordination on this project runs through Autodesk Forma Model Coordination (see 2.4). Discipline models are uploaded to the project’s Coordination Space in Forma, and clashes between them are detected automatically every time a new version is published, on the same cadence as the model exchange (see 7.2).

For Model Coordination to isolate what it’s testing, each model needs one 3D view per system, set up specifically for coordination, showing only what’s relevant to it, with links and unrelated categories switched off. Once created, the view is added to the model’s publish set and the model synced with central, only then does publishing carry it through to the Coordination Space, there’s no separate coordination-only file to build or maintain.

Two approaches are common for where these views live:

Federated drawings model: a shared model that links every discipline, often the same one already used to produce general drawings, carries the system coordination views for the whole project, and is published to the Coordination Space under its own identifiable name. One model to keep current, but every discipline depends on it.

Native discipline models: each native model carries its own coordination view(s), e.g. the electrical model holds separate views for low voltage, medium voltage, lighting and power, published straight from that model, with no federation step at all.

Either way, split views only as far as the project genuinely needs. A single coordination view is enough for most disciplines; splitting further, e.g. structure into horizontal and vertical elements, only pays off in complex projects.

[FILL IN: state which approach this project follows, and where the coordination views are published from]

Preparing and maintaining the coordination views for a model is the responsibility of that model’s author (see RACI, 2.3); confirming they’ve been correctly configured is the BIM Manager’s.

A model with zero open clashes usually isn’t a sign the design is resolved, it’s a sign the views aren’t scoped to catch anything yet. A model completely free of clashes isn’t a realistic goal at any stage of the project.

8.2 Clash Detection Rules

Autodesk Forma Model Coordination tests every published system against every other automatically, there’s no separate step to manually configure which pairs get tested. This section defines the policy applied to what comes back: tolerance, priority and what’s excluded by design.

Tolerance

A single tolerance applies across the whole coordination environment by default. Only reduce or increase it for a specific system if there’s a real reason to.

[FILL IN: default tolerance, in mm]

[FILL IN: any system-specific overrides, and the reason for each — leave blank if none apply]

Priority

High

Most results get reviewed and prioritised as they come in, but some systems are always High priority regardless of what they clash with:

• Structure
• Underground Utilities [FILL IN: any other system that should always be treated as High priority on this project]

Structure goes first by default because it’s usually the first thing built and the hardest to move once everything else depends on it being exactly where it is.

Standing Exclusions

The following are not treated as real conflicts, they’re embedded in a linked model by design:

• Manholes or drainage boxes embedded within a slab
• Diffusers or light fittings recessed into a ceiling
• Sockets and switches embedded within a partition
• [FILL IN: any other pairing specific to this project]

These are proposed as a starting point, add or remove items based on what your project actually needs.

Agreeing on these upfront, rather than re-flagging the same false positive on every report, is what keeps reviews focused on what actually needs a decision.

It’s also worth tracking the trend from one report to the next: is the count going up or down, and have the clashes flagged last time actually been resolved.

8.3 Issue Management

A clash doesn’t automatically become a tracked issue. Once reviewed against the rules in 8.2, it’s either marked not an issue and closed directly, typically because it falls under a standing exclusion or is otherwise judged not to need action, or promoted to an issue when a discipline actually needs to do something about it.

An issue is assigned to whoever is responsible for resolving it. Once that party believes it’s fixed, they mark it Answered; the issue owner then reviews it and only changes it to Closed once satisfied.

The BIM Coordinator creates and assigns issues from clashes that need action, and acts as issue owner, reviewing and closing them once resolved (see RACI, 2.3); each assignee is responsible for resolving the issue in their own model.

Every issue keeps the model context it was created from, and a running comment thread. A status changed to Closed with no comment explaining what was actually done is hard to audit later, and impossible for anyone but the assignee to trust.

A separate, manually maintained change log is unnecessary once issue tracking covers this natively.

8.4 Coordination Meetings

A coordination kickoff happens at the start of each stage, to walk through the clash matrix (8.2) against that stage’s models and agree any changes before testing begins. Beyond that, a recurring coordination meeting reviews what’s come out of Model Coordination since the last one, open issues, anything overdue, and what needs reprioritising.

The BIM Coordinator runs the recurring meeting; each discipline attends when it has open issues assigned to it.

[FILL IN: recurring meeting frequency, and where the schedule and minutes are kept]

Meeting dates, attendees, and minutes change too often to keep here, they’re logged in the CDE instead (same logic as the Model Register, 5.1, and TIDP/MIDP, 4.2).

SECTION 9: QUALITY CONTROL

9.1 Quality Control Strategy

Before an information container (see 7.2) can change state, it must pass quality assurance (QA) and quality control (QC). Following ISO 19650-2, this happens at two gates:

• Approval for Sharing From Work in Progress to Shared (clause 5.6).
• Authorisation for Publication From Shared to Published (clause 5.7).

Sharing is asking whether it’s safe for other disciplines to build on. Publication is asking whether you’d put your name behind it contractually. Treating every internal exchange as if it needed the same process is usually what slows a project down.

9.2 Model Checks

Below is a proposed set of categories to consider when auditing the models, which in my experience works very well.

Model structure and organization

• Each discipline modelled on its own dedicated workset.
• [FILL IN: add a check specific to your project]

Naming conventions

• Sheet naming and numbering follow the project convention (6).
• [FILL IN: add a check specific to your project]

Modeling quality

• No duplicate elements.
• [FILL IN: add a check specific to your project]

Families

• Family parameters configured and filled correctly.
• [FILL IN: add a check specific to your project]

Coordination and deliverables

• Shared coordinates aligned across all models (5.4).
• [FILL IN: add a check specific to your project]

Data and parameters

• MEP elements have their system assigned.
• [FILL IN: add a check specific to your project]

Sheets and drawings

• Every view has a view template applied.
• [FILL IN: add a check specific to your project]

Prohibitions

• No imported or exploded CAD files.
• [FILL IN: add a check specific to your project] Before a model is authorised for Published (9.1), the BIM Manager (2.3) audits it against these checks. At project completion, this same audit also confirms the model is ready for handover: no further edits expected, links resolved, information complete.

[FILL IN: where this check-by-check register lives, or note if it isn't tracked separately from this section]

Personally, I always use my own template to check model quality. It’s designed to be automated with any QC/QA addin. It can also help you finish filling in this section. → Model Audit Template.

SECTION 10: TECHNICAL REQUIREMENTS

10.1 Units & Precision

All models on the project use the same unit system and precision, agreed once at project start so schedules, exports, and coordination stay consistent across disciplines.

Metric and imperial units are never mixed within the same model. For linked or exported 2D CAD, the convention is 1 drawing unit = 1.00 m; files at a different scale must be corrected before linking.

ISO 19650 doesn’t mandate specific units or precision, this reflects common practice among the projects reviewed for this template (all metric).

10.2 Model Performance & Size

Native model files are kept under 1GB: purged of unused elements regularly and compacted weekly. This keeps the file responsive enough to open, save, and sync without becoming a bottleneck for the team, and keeps upload/download times to the CDE (7.1) manageable across the project.

Each model’s BIM Author (2.3) is responsible for its performance.

10.3 Shared Parameters

A single shared parameter file governs the project; disciplines do not create their own. Parameters are matched by GUID, not by name.

Two files defining an identically-named parameter are not interchangeable, and will break shared schedules, tags, and IFC exports downstream.

[FILL IN: CDE location of the master shared parameter file]

New parameters are requested from the BIM Manager (2.3), who adds them to the master file and reissues it to the team.

The file should be read-only for the rest of the team: Revit can still read parameters from it, but no one can edit it, whether by mistake or on purpose.

10.4 CAD Export Configuration

CAD exports (DWG and similar) use a single, predefined export configuration; disciplines do not configure their own on each export. This only applies to deliverables; WIP exports (7.2) don’t need to follow it.

[FILL IN: CDE location of the export configuration]

The configuration itself isn’t specified parameter by parameter here, it’s an internal company standard, kept in the firm’s CDE and copied into the project’s CDE for the team to use.

SECTION 11: MODELLING GUIDELINES

11.1 Worksets

New worksets are not created by individual discipline teams; requests go to the BIM Manager (2.3), who adds the workset across all project files so the list stays identical everywhere.

[FILL IN: project workset list]

Worksets are the key piece of Revit’s collaboration model, and they share git’s goal but not its method: instead of letting everyone work in parallel and reconciling changes afterwards, Revit locks the element before anyone can touch it, because there’s no way to merge two edited versions of a wall the way you’d merge two versions of a text file. Touching an element borrows it to you automatically until you sync, hence the familiar “can you sync and relinquish?“

11.2 Spatial Elements

This subsection should clarify when Rooms, Areas, Spaces, and Zones are actually used on the project. Below is a suggested default.

Spatial elements are easy to conflate since they occupy the same physical space, but measure different things.

Rooms: Bounded by building elements, used for usable area calculations. Areas: Group or subdivide rooms along lines set for functional convenience, used for gross floor area or functional-zone calculations. Spaces: Not used by default. Needed only where Energy or HVAC Analysis is an active BIM Use (3.1); if the project needs them, flag it to the BIM Manager for the next revision (1.5). Zones: Not used by default, for the same reason as Spaces.

Spaces carry thermal and occupancy properties and drive energy analysis and services sizing. Zones group spaces that share the same thermal properties and heating/cooling system..

SECTION 12: ASSET INFORMATION

12.1 Asset Data Requirements

This section should point to the official documents that set out everything the information container needs for exchange with asset and facility management. If that documentation doesn’t exist yet, it’s worth noting that here rather than guessing at its content.

Where a formal AIR and AIM exist (1.4.1), they set out the specific conditions that apply here, such as [FILL IN: maintenance intervals, warranty terms]. Both are held in [FILL IN: CDE folder].

Even without a formal AIR or AIM, a project can still owe the client some baseline exchange conditions, just not a full asset dataset built from assumptions. If that’s the situation here, list them directly instead of waiting for documentation that isn’t coming.

If neither has been issued, note that explicitly, and record any exchange conditions agreed directly with the client below instead:

• [FILL IN: condition]
• [FILL IN: condition]
• [FILL IN: additional conditions, as needed]