Choosing software for architectural work
An attractive image does not prove that software will support the office workflow. Editable drawings, useful model information and exchanges that partners can actually use matter more. Define those results before comparing products.
Define work and deliverables
An office producing 2D drawings has different needs from a team sharing a building model. Alterations may require existing plans, several file formats and clear separation of existing and proposed work. Visualization is a separate requirement from quantities or construction drawings.
Describe typical projects and planned seats. Separate regular deliverables from occasional uses so that a long feature list does not become the reason for buying unused modules.
| Work objective | Useful demonstration |
|---|---|
| 2D drawing | Editable plans, annotations and suitable outputs |
| BIM and quantities | Structured objects, properties and checkable reports |
| Visualization | Required views and image outputs |
| Coordination | Agreed model and issue exchange |
Check Swiss templates and libraries
Local templates, component libraries, area reports and classifications can help with setup. Check what the licence includes, what needs a service package and how your office standards will be retained.
References to standards in a template do not replace professional project review. Choosing software alone does not make BIM mandatory for every Swiss project. Requirements depend on the specific commission and agreed deliverables.
Test exchange with an example
Ask for the actual IFC and DWG versions required and PDF outputs. An open exchange format does not automatically retain every native editing feature. BCF exchanges model-related issues and comments; the model itself is shared separately.
Use a small non-confidential example to check storeys, coordinates, units, object properties and quantities. Test a correction travelling back as well. Successful export alone does not prove usable exchange at the receiving partner.
Organize collaboration and responsibilities
Individual work, internal teams and outside specialists need different permissions, versions and approvals. Agree who combines models, incorporates changes and closes outstanding issues.
Compare shared project storage and model coordination separately. Define authoritative project versions and limited access that allows external partners to contribute.
Account for existing projects and devices
State operating systems, known software versions and file types. Old projects, custom libraries and add-ons can affect a move more than new drawing features. Ask which older versions will remain readable and editable.
Check hardware and graphics needs using a representative project. A pilot migration should work on copies and preserve the original. Training, template adjustments and transition time belong in the implementation plan.
Compare costs over the period of use
Compare the same number of seats and modules. Licensing, local content, collaboration, storage, support and version upgrades may be separate charges. A starting price does not cover this whole scope.
Separate one-off work from ongoing fees. Ask about exports, future access to old projects and the cost of a later move. A useful quotation states its assumptions and excluded services.
| Cost component | Clarify in the quotation |
|---|---|
| Licences and modules | Seats, term and required functions |
| Local content | Templates, libraries and updates |
| Collaboration | Project access, storage and outside participants |
| Implementation and change | Training, migration, support and future exports |
Prepare the enquiry and pilot
An initial enquiry can state project types, seats, systems, known programs, required outputs and partner formats. Describe templates and libraries together in one short brief. Do not include confidential drawings, credentials or complete project files.
Then agree a bounded pilot: create a drawing, exchange the model, check a change and produce outputs. Decide using those tasks before migrating the entire team or project archive.
Frequently asked questions
Does a 2D office have to adopt BIM?
Not simply because it chooses software. Check agreed deliverables and whether a building model is actually needed.
Can an IFC model be edited like a native file?
Not automatically. It may serve exchange without retaining the same native functions or library relationships. Test the specific case.
Does BCF replace the model file?
No. It describes model-related issues and views referring to a separately shared model.
What happens to old projects?
Clarify supported versions, conversion and retained access. Test a copy before changing original files.
What device information is helpful?
Operating system and known hardware are enough initially. The provider should assess needs against planned project sizes and features.
Can we request a quote without uploading drawings?
Seats, project types and required formats support an initial scope assessment. A suitable example can be agreed later for more detailed testing.
