Revit

Yes. The level of development is agreed for each stage, discipline and use — what the model needs to support at that point, not simply how detailed it looks. Over-modelling early spends effort on decisions that will change; under-modelling leaves gaps that show up in coordination. Where a project uses a defined LOD specification or BEP, we model to it; where it doesn't, we agree a practical scope per element category before modelling starts.

Yes. We follow your BEP, template, naming conventions, coordinates, model division and exchange procedures rather than substituting our own. Swapping in an internal convention mid-project undermines the coordination the BEP exists to protect. If something in the BEP is unclear or conflicts with the deliverables, we raise it rather than quietly working around it.

Yes. Discipline models are federated — typically in Navisworks — and clash tests are run between agreed discipline pairs, with results grouped and reviewed rather than issued as a raw list. Clash detection is a coordination aid: it finds geometric conflicts in what's been modelled, but resolving them is a design decision for the responsible team, and anything not yet modelled can't be detected.

Yes. Families are built for how they'll be used — correct category, types, parameters for schedules and tags, visibility at different detail levels, and connectors where MEP behaviour is needed — not just geometry that looks right in 3D. Manufacturer data is used where it's supplied. Complexity is kept proportionate: a family with more parametric behaviour than the project needs is harder to maintain.

By following how the team and contract actually work. Disciplines usually sit in separate linked models, with worksets inside each model for zones, levels or building elements where several people work at once. The aim is reasonable file performance and clear ownership — not creating worksets or links simply because the software allows them.

Yes, where it's part of the brief. Handover needs are scoped early — which assets need identification, which manufacturer, warranty or maintenance fields, and in what format the facilities team will use them. A design or construction model doesn't automatically become an asset database, so only the information the project actually requires is planned in and checked.

Yes. A first project is the right time to set up a template, a starter family library, naming conventions for views, sheets and families, and shared parameters. Getting these right once means later projects build on them instead of revisiting the same decisions each time.

Yes. Schedules are checked against the parameters they're meant to read, and tags are checked for consistent values across similar elements. A model can look complete and still report wrong quantities or mismatched tags if parameters were filled inconsistently, so data review is part of QA, not an extra.

Yes. Phases and phase filters are set up at the start so existing elements, demolition and new construction display and schedule correctly on each drawing. Adding phasing to a model that's already been built without it is awkward and error-prone, so it's planned before modelling ramps up.

Yes. Sheet numbering, view naming and view templates are agreed early. Once a project reaches dozens or hundreds of sheets, a haphazard index is hard to navigate and hard to fix without breaking references, so the structure is set before documentation volume grows.

Yes, if the requirement is known before modelling. We confirm which elements, parameters and classifications the downstream tool or process needs — for example consistent materials and room data for analysis, or separable elements for take-off — and build them in. Retrofitting that structure into a finished model is considerably more work.

Yes. Mechanical, electrical and plumbing modelling is available individually or alongside architectural and structural models, using MEP families with connectors and systems where the deliverables need them, and coordinated against the other disciplines.

Yes. Worksharing is set up with a workset structure that matches who works on what, so people aren't fighting over element ownership and the file stays responsive. Central or cloud-based collaboration follows whatever environment your team already uses.

Yes. An audit typically reviews warnings, family quality and duplication, workset and link structure, parameter consistency, view and sheet organisation, and file size. It's useful before taking over an inherited model or before a model is relied on for documentation or handover.

Yes, modelling to the brief and any design guidelines supplied for the building type. Specialist requirements — room data, equipment, servicing density — are taken from the project information rather than assumed.

Yes, in a supporting role. Models can be structured and exported so elements map cleanly to programme activities — consistent zones, levels and package parameters — for a 4D workflow run by your scheduling team. The sequencing itself sits with the project's planners.

Yes. On staged or package-tendered projects, worksets or package parameters can follow the construction packages so model content can be filtered, exported and issued per package.

Yes. Existing conditions, demolition and new work are represented with phases in one model, so drawings and schedules for each stage come from the same source. Where existing conditions come from a point cloud, see our Scan to BIM service.

Yes. Families are assigned the right category and parameters — shared parameters where values need to appear in schedules and tags — and are tested in a schedule before they're used across a project.

By agreeing the shared parameter file and naming at project start and having every party use it. If two consultants each create their own version of what should be the same parameter, schedules and exports split the data and the coordinated model becomes unreliable even when the geometry is right.

Yes, where presentation visuals are needed. Rendering from the same model used for documentation keeps the image consistent with the actual design. For higher-end visualisation, the model can be taken into a dedicated rendering workflow — see our 3D rendering service.

Yes. IFC export settings are agreed with the other party, and geometry, element classification and key parameters are checked after exchange in both directions. IFC doesn't transfer everything perfectly between platforms, so the check is part of the workflow rather than an assumption.

Yes. The inherited model is reviewed first — standards, warnings, families, links and completeness — and anything that needs correcting is flagged before new work is built on top of it.

Yes. Ongoing overflow support works inside your BEP, templates and families, so the model stays consistent whoever is working on it.