A small practice decides to “move to BIM.” It buys licences, schedules training and starts a model on the next live project. Three weeks later, drawings are still being corrected in CAD, the model contains conflicting information and nobody knows which file controls the issue set. The first change a firm needs is not a new toolbar. It is an agreement about deliverables, ownership and review.
This article is for architects joining or leading a small-practice transition. It is distinct from choosing a software stack: the software may already be chosen. The challenge is how to shift a working process without putting a live client project at risk or expecting one motivated junior to maintain two complete documentation systems alone.
Define the outcome before the model
Ask what problem the move is meant to solve. Is the firm trying to coordinate with consultants, reduce repeated drawing edits, produce schedules, meet a client’s BIM requirement or improve its own design reviews? Each goal suggests a different pilot and level of model information. “Everyone uses BIM now” is not a deliverable.
Write the first project’s required outputs: plans, sections, schedules, visualisations, model exchange and issue package. Which of these must be contractually delivered? Who will receive the model and in what format? What can remain a drawing or external document? Avoid promising a fully coordinated model when the team has not agreed how consultant files will be exchanged or checked.
The Autodesk article on model coordination describes coordination as an issue and collaboration process. It is vendor guidance, so its product details are not universal. The useful general point is that a model only helps when the team can identify, assign and close an issue.
Choose a pilot with bounded risk
The first pilot should be large enough to reveal real coordination problems and small enough that the office can review the output carefully. A modest extension or defined package within a larger project may work better than the practice’s most urgent, complex deadline. If the next live project is the only option, narrow the BIM experiment to a stage or deliverable and keep an explicit fallback.
Define the pilot’s success criteria before starting: fewer repeated manual changes, a reliable schedule, an agreed consultant exchange or a clear issue log. Do not promise a productivity gain in the first month. Training and template development take time. Measure rework and review effort alongside drawing output, not only the speed of the person modelling.
Assign a senior reviewer who can check design and documentation, even if they are still learning the tool. A technically fast junior should not become the sole quality gate because nobody else can navigate the model. The project architect must still own design decisions and the issued package.
Decide where the truth lives
For each deliverable, state the source of record. Is the door schedule generated from the model or maintained externally? Are wall types defined in the model, specification or both? Which file is authoritative for consultant coordination? How are changes from CAD backgrounds brought into the model? A small team can tolerate mixed tools if it knows how contradictions are found and resolved.
Create a “change travels” map. When a door width changes, list the plan, schedule, detail, code check and consultant information that must update. Test the map with one real change before the project grows. If a team member updates the model but not a linked specification, BIM has not removed the coordination problem; it has moved it.
Define file naming, shared coordinates, model ownership and issue dates. Decide who can edit which elements and how changes are reviewed. These may sound like large-firm concerns, but a two-person practice can lose hours when both people work from different versions. Keep the protocol short enough to use.
Train around tasks, not menus
Start with the work the team must perform next week: setting levels, modelling a wall, placing doors, creating a sheet, exporting a consultant file and issuing a revision. Pair each lesson with an office drawing standard. Generic software training may teach buttons while leaving the practice’s actual deliverables unresolved.
Give everyone a role-based learning path. A principal may need to review sheets, annotate decisions and understand model risks. A project architect may need to manage views and coordination. A junior may need to model and document under a clear template. Not every person needs to become an advanced family author. Training time should be protected in the programme, not squeezed into nights.
Build a tiny internal library: one approved title block, a handful of common assemblies, view templates and a checklist for issuing. Do not import a huge template whose parameters nobody understands. Add an element when a real project needs it and someone can maintain it.
Make consultant exchange explicit
Ask each consultant what they can supply, how often and with what coordinates and classification. Some may work in different software or issue drawings rather than models. Agree how their information will be referenced and reviewed. A BIM transition fails quickly when the architectural team assumes all consultants will participate in a process nobody has contracted for.
Create a simple exchange calendar with dates, file format, origin point, version and responsible person. After each exchange, record issues, owners and closure status. Do not rely on a colourful clash screenshot as evidence that a problem is solved. The resolution should appear in an authorised design decision and the affected documents.
If the client requests a model for operations or future use, clarify what information it needs and who will validate it. A design model built for drawing production may not contain reliable asset data. Define the scope and fee before promising a handover model.
Review the first issue set like a drawing set
BIM does not make drawings correct automatically. Check dimensions, annotation, schedules, specifications, model views and consultant interfaces. Print or review the PDF set at the scale the contractor will receive. An object can be modelled beautifully and documented ambiguously. The team remains responsible for the issued information.
After the first issue, hold a short retrospective: where did the model help, where did the team double-handle information, which template element caused confusion and what training would prevent the next error? Keep the result to a few changes that can be implemented on the next project. A long wish list may never be used.
If the pilot shows that some work should remain in CAD for now, record why and when to revisit it. A staged transition is still a transition. The office can set a clear boundary between old and new processes rather than pretending every project has fully migrated.
What to ask if you are joining the firm
Ask to see one recent issued package if the firm can share it. The drawings reveal the current standard that the model must support. A conversation about software becomes more concrete when everyone can point to the actual sheet, schedule and coordination problem.
“Which project is the pilot? What deliverable is expected from the model? Who reviews my work? How much training time is allocated? Which documents remain outside BIM? How will consultants exchange information?” These questions tell you whether the firm has a method or is hoping one new hire will invent one while meeting deadlines.
If you are the candidate hired for BIM skill, clarify your authority. Can you set standards, or only produce drawings? Who approves template changes? Will you have support when a modelling choice affects cost or contract scope? A good transition uses your expertise without asking you to carry responsibilities beyond your role.
A small practice does not need a giant BIM manual to begin. It needs a bounded pilot, a source of record for each deliverable, a reviewer and a way to close coordination decisions. The software can then serve the work instead of becoming another parallel version of it.
Browse current architecture jobs on Jobs.archi and compare your next step with our guide to the gap between architecture school and practice.
The post When a Small Architecture Firm Moves From CAD to BIM, What Changes First? first appeared on jobs.archi.