What ISO 19650 Actually Asks of a Small Practice (and What It Doesn't)

ISO 19650 has a reputation problem, and small practices bear the worst of it. Say the number in a five-person studio and watch the reaction: it's for the megaprojects, it needs a BIM manager we can't afford, it means buying a platform, it's a hundred pages of British acronyms between us and the work. So small firms either ignore it — until a tender scores them down for it — or panic-buy compliance in the form of templates they don't understand and software they didn't need.

Both responses mistake what the standard is. Strip the vocabulary and ISO 19650 is a small set of old-fashioned professional disciplines — agree what information is needed, plan who produces it, produce it in a controlled way, check it before sharing, keep the record — dressed in terminology sized for projects where fifty organisations must do those things identically. The disciplines scale down beautifully. The ceremony doesn't have to come with them.

Here's the honest sorting: what the standard genuinely asks of you, what it lets you scale, and what it never asked for at all.

The five things it actually asks

1. Find out what information the client needs — in writing. The standard's entire machinery starts from information requirements: the client states what they need delivered (and why — planning, construction, operating the asset), and everything downstream exists to satisfy it. In megaproject form this is the EIR, a document tree with clause numbers. In small-practice form it can be a two-page schedule agreed at appointment: what deliverables, what formats, what the client will use them for. Most small-project pain traces to this conversation never happening — the client discovers at handover that they wanted something nobody was asked to produce. The standard's first demand is just: have the conversation, keep the record.

2. Plan the production before producing. The famous BEP — BIM Execution Plan — is, at its core, the answer to five questions: who produces what, in which software and formats, to which coordinates and naming rules, checked how, delivered when. For a small team on a small project, honest answers fit on a few pages. Its value isn't ceremony; it's that the questions get answered before the first exchange instead of being discovered at it — the shared coordinates paragraph alone repays the document (misaligned models remain the most common, most preventable federation failure going).

3. Keep information in a managed common environment. The CDE — common data environment — triggers the most spending anxiety, and needs the most demystification: the CDE is a set of behaviours, not a product. The behaviours: one agreed place per project for information (not inboxes); every file carrying a status that says what it may be used for (work in progress → shared for coordination → published for use); and revisions kept, not overwritten. A five-person practice can honour every one of those behaviours with disciplined folder structures, a naming convention, and a status field — on infrastructure it already has. Platforms automate the discipline; they were never the discipline itself.

4. Check before you share. The standard formalises a gate every good practice already believes in: information gets reviewed before it changes status — before the coordination issue, before the client sees it. Small-practice form: a named checker (not the author), a short checklist per deliverable type, and the check recorded. For models specifically, the check includes the things a free viewer exposes in minutes — coordinates landing where agreed, no stray elements, required properties present — the ten-minute triage we've detailed in reviewing IFC deliverables.

5. Keep the audit trail. Who received what, when, at what status. On a platform this is automatic; in a folder-based CDE it's a transmittal log — a spreadsheet, maintained honestly. Unglamorous, and the single most valuable artefact in the file when a dispute arrives two years later.

That's the standard's actual spine. Notice what it costs: conversations, a few short documents, naming discipline, a checking habit, a log. Overhead, yes — the kind of overhead a well-run practice was already carrying, now with shared names for its parts.

What scales down

Everything else flexes with project size, and the standard itself says so — its requirements are explicitly to be applied in a manner proportionate to the project. Proportionate, for a small practice, looks like: the responsibility matrix is a table with five rows, not a database; the mobilisation plan is a paragraph confirming the team has the software and the naming convention, not a capability audit; federation strategy on a two-consultant project is one sentence naming the shared coordinates and the exchange cycle. Writing less is not non-compliance. Writing things nobody will read is.

Pro tip: In tenders, small firms out-score bigger ones on ISO 19650 questions by being specific rather than voluminous. "Our CDE procedure: [half a page describing your actual folder structure, statuses, and naming]" reads as a firm that understands the standard. Forty pages of copied boilerplate reads as a firm that bought a template. Assessors have seen the template.

What it never asked for

The myths, plainly:

A platform purchase. No clause anywhere requires commercial software. The CDE is behaviours (above); the tools are your choice, and for a small practice the disciplined-folders version is fully legitimate.

A dedicated BIM manager. The standard assigns functions — someone must manage the information process — not headcount. In a small practice the function is a hat, worn by a director or a capable senior, for hours a week, not a salary.

"BIM" itself, in the maximalist sense. ISO 19650 is about managing information — which includes drawings, schedules, and reports. A practice delivering 2D drawings can still run requirements, a CDE, statuses, checks, and logs, and be honouring the framework's substance. The standard doesn't demand you model everything; it demands you manage what you produce.

Certification. Compliance is a way of working, demonstrable through your procedures and your project records. Third-party certification exists and some clients value it, but its absence is not non-compliance — and no small practice should be shamed into believing otherwise.

Why bother, if nobody's forcing you

The compliance argument — tenders ask, frameworks require — is real but boring. The better argument is selfish: every discipline on the spine's list is a discipline that saves you first. The requirements conversation prevents the handover surprise. The BEP's coordinates paragraph prevents the misaligned-model week. Statuses prevent the contractor pricing the superseded drawing. The checking gate catches the error while it's yours quietly, not the project's loudly. The log wins the dispute. Small practices have thinner margins for exactly these failures than the megaprojects the standard was drafted around — proportionate ISO 19650 is arguably worth more per head to a five-person studio than to a five-thousand-person one.

Start smaller than the standard's reputation suggests: this month, write the two-page information requirements schedule for your next appointment and put a status field in your file names. That's a real beginning, and it cost nothing but attention — much like the tools that support the checking and reviewing habits around it:

The free, browser-based toolkit → — model review, programs, boards, and takeoffs, no platform procurement required.

This article is orientation, not compliance advice. Contractual BIM obligations depend on your specific appointments and the standard's applicable parts — review them against your actual documents, with professional advice where stakes warrant.