5 BIM Mistakes Small Architecture Firms Make - and how to fix them
BIM adoption among small architecture and engineering firms has grown significantly in recent years - but so has the gap between using BIM software and actually getting the benefits BIM promises. Many small studios open a BIM application, model their projects, and still end up with the same coordination problems, documentation errors, and client communication challenges they had before.
The reason is usually not the software. It is a handful of recurring workflow habits that undermine the whole point of working in BIM. Here are the five most common ones - and what to do about each.
Mistake 1: Using BIM as a 3D CAD tool
This is by far the most widespread problem. The architect opens the BIM application, draws walls, adds a roof, places windows and doors - and produces a model that looks like a building but functions like a 3D drawing. Elements have no data attached. Walls do not know they are walls. Rooms have no areas, no names, no properties.
The result: the model looks fine on screen, but you cannot extract a room schedule from it, you cannot run an energy analysis, you cannot produce a meaningful IFC export for a structural engineer. You have used BIM software to do CAD work.
The fix:
Build the model with data from the start, not as an afterthought. Every wall should have its type assigned, every room should be defined as a space with a name and function, every window and door should come from the component library rather than being drawn as geometry. It takes slightly longer at the modelling stage and saves significant time on every downstream task.
Mistake 2: Skipping the project template
Most BIM software ships with a default template. Most small firms use it unchanged for every project. This means every project starts with the wrong layer names, the wrong level structure, mismatched line styles, and no standard views set up - and someone spends the first day of every project fixing the same things.
A project template is not just a convenience. It is the definition of your office standard - how levels are named, which views are always created, what the title block looks like, which material library you use. Without it, every project drifts slightly differently and coordination between team members becomes unnecessarily complicated.
The fix:
Invest one or two days in building a proper office template. Define your standard level heights, layer naming convention, view organisation, title block, and material library. Save it and use it as the starting point for every new project. Update it once a year. The time investment pays back on the second project.
Mistake 3: Not using shared coordinates for multi-discipline projects
A small architecture firm receives the structural engineer's model as an IFC file and imports it. It lands 500 metres away from the architectural model, rotated 15 degrees, at the wrong elevation. An hour of manual repositioning follows. The same problem repeats when the MEP model arrives.
This happens because nobody agreed on a shared coordinate system before modelling started. Each discipline set their own project origin, and now nobody's model lines up with anyone else's.
The fix:
Before a multi-discipline project starts, agree with all consultants on a shared survey point and project north. Each discipline sets their model origin to the same real-world coordinate. When IFC files are exchanged, they land in the right place automatically. This takes fifteen minutes to set up and saves hours of repositioning on every project.
Mistake 4: Treating IFC export as a one-time delivery
Many firms export an IFC file once - at the end of the design phase, as a formal deliverable - and never think about it again during the project. This means the structural engineer and MEP consultants have been working from a version of the architectural model that may be weeks or months out of date. Clashes that could have been caught early are discovered late.
IFC is most valuable as a regular coordination tool, not a final deliverable. The point is to catch problems when they are still cheap to fix - in the model, not on site.
The fix:
Set a regular IFC exchange rhythm with your consultants - weekly or at each design milestone. It does not need to be a formal process: a shared folder where each discipline drops their current IFC is enough. Run clash detection before each coordination meeting so the agenda is based on actual current model data rather than what people remember from last time.
Mistake 5: Keeping the model and the documentation separate
The architect builds a careful BIM model. Then, when it comes to producing drawings for submission or construction, they trace over the model views in 2D - adding dimensions, annotations, and details as separate CAD work that has no connection to the model. When the design changes, the model is updated but the drawings are not, or vice versa. By the end of the project, nobody is quite sure which version is current.
This completely defeats the purpose of BIM. The whole point is that drawings are generated from the model - when the model changes, the drawings update automatically. If you are maintaining parallel sets of information, you are doing twice the work and introducing errors.
The fix:
Learn to produce your submission drawings directly from model views. Set up your floor plan views, section views, and elevation views in the BIM software with the correct annotation standards, and output them directly to DWG or PDF from there. Yes, it requires setting up view templates properly at the start. Yes, it is worth it - because every subsequent design change propagates through automatically.
The common thread
Looking at these five mistakes together, the pattern is clear: most of them come from treating BIM software as a more powerful version of 2D CAD, rather than as a fundamentally different way of working. The geometry is built, but the intelligence behind it is not used.
The firms that get the most out of BIM are not necessarily the ones with the most powerful hardware or the most expensive software licences. They are the ones that have taken the time to define how they work - templates, coordinate conventions, exchange rhythms, documentation workflows - and stick to it consistently.
None of the fixes above require more software. They require about a week of setup and a change in habit. That is a reasonable investment for something that pays back on every project for years.
Copyright © 2026 ArCADiasoft
HOME | PRODUCTS | COMPANY | CONTACT | FOR RESELLERS