Owner training

This page prepares the owner's project manager and the owner's BIM representative for the readiness test in the BEP Builder. Each section covers one topic: what it is, why it matters to an owner, what to require, and a common mistake. Each section lists the test questions it prepares for. The examples are Canadian and general; Quebec is used where language or local practice changes the answer.

Questions marked (BIM representative only) are asked only of the BIM representative.

When you are ready, take the owner readiness test (BEP Builder, step 2 Owner, section Owner readiness). Answers are written in your own words. The answer key only shows after you commit your answers.

1. The purpose of BIM and BIM uses

What it is. A BIM use is a specific job the model does for the project, such as coordinating trades before construction, producing quantities for an estimate, or giving the maintenance team asset data. The purpose of BIM on a project is the list of results the owner wants from those uses.

Why it matters to an owner. Every use costs modelling time, data entry and checking time. A use nobody acts on is paid for and wasted. A use with no stated data requirements gives a model that cannot do the job.

What to require.

• A short statement of the owner's goals: cost certainty, fewer site conflicts, usable handover data, or others.
• Only the uses that serve those goals, each with an owner, a milestone and a deliverable.
• For each use, the elements and parameters it needs. Quantity take-off at the end of schematic design, for example, needs the elements to be measured, the unit for each, the parameters the estimator uses, and the level of development at that milestone.

Common mistake. Accepting the designer's long list of uses because it looks thorough. Fifteen uses on a $12 million school means fifteen sets of requirements to write and check.

2. EIR and BEP

What it is. The EIR (exchange information requirements) is the owner's statement of what information it needs, when, and in what form. The BEP (BIM execution plan) is written by the firm or team and says how they will deliver it.

Why it matters to an owner. The owner sets the rules and the firm answers them. If the owner does not write requirements, the firm's plan becomes the only rulebook, and it will describe what the firm already does.

What to require.

• An EIR issued with the tender, containing: the purpose and uses, deliverables per milestone with file formats, the checking and acceptance method, the roles and minimum team, and the owner's own response times.
• A pre-appointment BEP or BIM proposal from each bidder, scored with the bid.
• A post-award BEP checked by the owner against the EIR and accepted or returned in writing before modelling relies on it.
• Updates of the BEP at each stage and when the team or scope changes.

Common mistake. Treating the plan as a firm's document that the owner just files. A plan nobody checked is a promise nobody holds.

3. Levels of development and information

What it is. LOD describes how developed an element is in the model, in geometry and reliability. LOI is the information the element carries: parameters such as fire rating or manufacturer. They are separate. A detailed 3D duct with no tag and no capacity has good geometry and no information.

Why it matters to an owner. "LOD 300" alone is not a requirement. It leaves open which elements, which data, by which milestone and who models them. The result is a dispute at acceptance.

What to require. For each element or element type that matters:

• the parameters it must carry and their allowed values;
• the milestone from which each parameter is due;
• the use each parameter serves, so no one fills fields nobody needs;
• who models and fills it;
• how the owner checks that it is filled in and correct.

Door data for a facility team is a worked case: element (door), parameters (fire rating, hardware set, location), allowed values, due at the end of design development, checked by counting filled fields per door type.

LOD 500 means elements verified in the field after construction. It is not a more detailed model. If the owner wants it, the owner says for which elements, how they are verified and to what tolerance (survey, scan or inspection), who records changes, who updates the model, and who signs the verification. It is extra scope and must be scheduled and paid for.

The OpenBEP LOD specification does this for 63 element types: for each level, what must be drawn in 3D, which Revit parameters the element must carry, and which BIM uses need them. Start from it instead of a single number.

Common mistake. Writing a single LOD number for the whole project and assuming it covers the data.

4. Deliverables per milestone

What it is. A milestone is a point in design or construction (for example the end of schematic design) at which the firm delivers defined information and the owner decides whether to accept it.

Why it matters to an owner. Deliverables defined only at the end arrive late and wrong. Per-milestone deliverables let the owner find a gap while it is cheap to fix.

What to require at each milestone, besides drawings.

• Native model files of each discipline.
• The BEP, updated for the stage.
• A parameter report or schedule export for the elements due at that stage.
• The coordination report and the issue log with status.
• A list of open questions and assumptions the owner must decide.

Common mistake. Asking for the model "at the end of the stage" without saying what must be in it.

5. Accepting and checking models

What it is. Acceptance is the owner's decision that a delivered model meets the requirements. It rests on a check of the delivered files.

Why it matters to an owner. Looking at a model in 3D shows geometry. It does not show whether the data is present. A firm that checks its own work and reports "compliant" has given an opinion, not verification.

What to require.

• A rule-based check that counts, for each element type, whether each required parameter is present and actually filled in.
• The check run at every milestone, against a threshold agreed in advance.
• The check run by the owner or a party independent of the firm being checked.
• Acceptance tied to the result of the check.

A plan or a plan-writing tool states the requirements. It does not verify models. Other tools do that: schedule exports from the authoring software, scripts, or rule-checking software reading IDS files. The LOD specification lists, for each element type, the parameters such a check counts at each level.

Common mistake. Accepting a "compliant" statement from the firm as proof.

6. File formats: native, IFC, COBie, IDS, BCF

What it is. Native files are the files of the authoring software (for example Revit). IFC is an open exchange format, a derived copy. COBie is a structured data format for asset information. IDS is a machine-readable file of information requirements that a checking tool tests models against. BCF is an open format for exchanging issues and comments linked to model views.

Why it matters to an owner. The native files are what the next project, the renovation and the operator will edit. IFC loses data and cannot be edited well. Requiring it everywhere costs mapping and checking time on every export.

OpenBEP's position.

• Native files are the contractual master, delivered at every milestone and at handover with their families and templates.
• IFC is required only when a use needs it: a system or partner that cannot open the native files, a long-term archive, or automated checks that read IFC.
• If IFC is required, the owner supplies the export settings and the data to include.
• IDS and BCF are good practice: IDS for acceptance checks, BCF for review and coordination comments. Neither replaces the model.
• Before agreeing to COBie, ask which system loads it, which asset types and fields it needs, and test the file by loading it before final payment.

Common mistake. Requiring IFC because it is "the open standard", with no use that needs it, or accepting IFC alone in place of the native files.

7. Common data environment and approvals

What it is. The CDE is the shared platform where project information is stored, shared and approved. Files move through states, for example work in progress, shared, published and archived.

Why it matters to an owner. The CDE holds the approved versions and the history of who approved what. If it belongs to a firm, that record leaves when the firm does.

What to require.

• The owner owns the CDE, or it is transferred to the owner at handover with its archive.
• Role-based access, document states and an audit trail.
• Approval for use by a named person with authority, not by the author alone.
• Only the published state used for construction or payment.

Common mistake. Leaving the CDE as a firm's internal tool and finding at handover that the history stays behind.

8. Roles: BIM manager and coordinator

What it is. The BIM manager sets up and runs the BIM process of a firm or team: standards, the plan, quality. The BIM coordinator brings the discipline models together, runs clash checks and follows issues until they are closed. The owner's BIM representative speaks for the owner.

Why it matters to an owner. When these roles are blurred, nobody answers for the plan and nobody closes issues.

What to require. Each role named in writing for the project, with its responsibilities. The lead firm is held to account for its team. The owner checks independently.

Common mistake. Assuming the coordinator is the owner's person, or that the BIM manager also checks the owner's acceptance.

9. Team capacity and key people

What it is. The team a firm names at award is the team the owner evaluated. Capacity is the hours each named person actually gives to this project.

Why it matters to an owner. A bid can name strong people who are also named on two other projects. Replacing a key person after award changes what the owner bought.

What to require.

• The weekly hours of each named key person, compared with the owner's estimate.
• A backup for each key person.
• Notice and owner approval before any replacement.
• A replacement of equal, proven skill (CV, test, references).
• The committed hours written into the contract, with the right to refuse a reduction.

The Project scorecard tracks each party's BEP commitments month by month, the hours delivered included, so a team that is thinning out shows up early.

Common mistake. Reading the team list in the bid and never asking for hours.

10. Existing conditions

What it is. In a renovation or addition, the model of the existing building comes from drawings, a laser scan or a survey. Each has an accuracy and gaps.

Why it matters to an owner. When the existing model is wrong, the cost shows up on site. If the contract does not say who relied on what, the question is argued afterwards, and the owner often pays.

What to require.

• A statement of the accuracy and coverage of any scan or survey the owner supplies.
• A statement from the firm of what it verified itself.
• A clear allocation of reliance: the owner's scan, the firm's verification, or both.
• Areas not scanned or not visible listed as risks, with an allowance.

Common mistake. Handing bidders a scan with no statement of what it covers and assuming the firm will absorb the difference.

11. As-built and handover data

What it is. The as-built model reflects what was actually built. Handover data is the package the owner's operations team needs: asset data, documents, warranties.

Why it matters to an owner. Under a standard CCDC 2 stipulated-price contract, the contractor records as-built changes. Updating the model from those records is extra scope unless it is specified. If nobody is named and paid to do it, the as-built model stays as designed.

What to require.

• A named party, paid, to update the model from the contractor's records, and a named party to check it.
• The as-built model in native files with its verification statement.
• Asset data in the format the maintenance system loads, with asset classes and parameters decided before design starts and checked at each milestone, not only at the end.
• Operation and maintenance documents and warranties linked to the assets.
• The CDE archive and issue history.
• Each part checked before the final payment.

Common mistake. Deciding what the maintenance team needs at handover, when it is too late to collect it.

12. Contract order of precedence

What it is. The order of precedence says which document governs when two disagree, for example the model and the issued drawings.

Why it matters to an owner. If the contract is silent, a disagreement on site becomes a claim.

What to require. The contract and the plan state which governs, for which deliverable, before tender. If the drawings govern, say so and say what the model is for.

Common mistake. Leaving the question open because "the model and the drawings come from the same source".

13. Payment tied to accepted milestones

What it is. A share of each fee instalment is released only when the milestone BIM deliverable is accepted.

Why it matters to an owner. Money is the owner's strongest lever. Owners whose BIM programmes held up made acceptance of the BEP and of each milestone a condition of payment.

What to require.

• A set share of each instalment tied to accepted BIM deliverables.
• Acceptance based on the agreed check, not on a date.
• BEP acceptance as a condition of the first payment.
• The time the owner has to accept, and what happens if it rejects.

Common mistake. Paying on time while the BIM deliverables are late, then having no leverage.

14. Change orders

What it is. A change order adjusts scope, price and schedule after the contract is awarded.

Why it matters to an owner. A new wing added halfway through design means more modelling, coordination and checks. If the change order covers only drawings, the BIM work is either unpaid or silently dropped.

What to require.

• The BIM effort priced in the change, from the rates in the firm's bid.
• The BEP, milestones and schedule updated and re-approved.
• No work on the changed model before the change is approved.

Common mistake. Treating BIM as part of the drawings and leaving it out of the change.

15. Procurement and abnormally low bids

What it is. A bid with BIM hours far below what the plan needs.

Why it matters to an owner. It signals thin, late or unpaid BIM work.

What to require. The owner's own estimate of BIM hours, prepared before the tender. A low bid is clarified before award or rejected as abnormally low.

Common mistake. Awarding on the lowest fee and expecting the plan to be delivered in full.

16. Ownership and intellectual property

What it is. Who owns, and who may use, the model, the data and the content inside them.

Why it matters to an owner. The owner needs to use and modify the delivered model for the life of the facility, including for renovations by another firm.

What to require.

• A right for the owner to use, copy and modify the delivered model and data.
• The firm may keep its own tools and generic content, but the licence to the owner covers anything embedded in the model.
• All of this in the contract, not only in the plan.

Common mistake. Leaving ownership to the plan, which is not the contract.

17. AI and security

What it is. Project models and data can be sent to outside services, including online AI tools, and can be reached by many users.

Why it matters to an owner. The owner has confidentiality and privacy duties. A hospital, a school or a secure facility has sensitive areas.

What to require.

• Written owner permission before any project data goes to an outside service, including an AI service.
• A statement of which service, where the data is stored and whether it is used to train a model.
• The firm stays responsible for results and a person checks AI output.
• Access by role and need, named users, a log of logins, and access removed when a person leaves.
• Sensitive areas removed or simplified in shared models.
• The plan says what may leave the CDE, and who may take it.

Common mistake. Learning after the fact that the model was uploaded to a tool for convenience.

18. Owner time and capacity

What it is. Reviewing models, answering questions and accepting milestones takes owner time every week.

Why it matters to an owner. An owner who takes 25 working days to return comments on a submission leaves the team working on assumptions. Rework, delay and extra-cost claims follow.

What to require of itself.

• A weekly hours estimate for owner BIM work, based on project size and uses.
• A named owner's BIM adviser or staff member when the hours do not cover it. On a $40 million project, two hours a week for BIM is not enough.
• Training for owner staff before the start.
• Response times written into the plan and the schedule, matching the time the owner can really give.

The Project scorecard checks the owner's own commitments too: review times and decisions made by the agreed date.

Common mistake. Writing a ten-day response time into the plan with no one assigned to meet it.

19. Small projects

What it is. A small project is delivered by a small firm with little spare time for BIM. A $3 million school renovation is an example.

Why it matters to an owner. Requirements copied from a large project cannot be met and so cannot be enforced.

What to require.

• A few uses that pay back, for example coordination, review and handover data.
• Fewer, simpler deliverables and a short plan.
• The basics kept: who owns the files, which format is the master, how deliverables are accepted.

Common mistake. Reusing a large project's requirements unchanged.

20. Language

What it is. On a Quebec project, the operator may work in French. Names of parameters, views and documents in the model are part of what the operator uses.

Why it matters to an owner. If language is not stated, the firm chooses, often at handover, and the operator receives data it cannot use.

What to require.

• The language of deliverables, parameter names and model views stated in the EIR.
• Whether the plan and training material are in French.
• A check at a milestone that the names in the model are the ones the operator can use.

Common mistake. Leaving language to the firm.