Being a Bad Background

In an earlier post I described how architects and MEPF engineers can learn to benefit from a multi-discipline Revit environment by respecting and anticipating the pain points and natural workflows of the other. Now I'd like to talk about structural engineers.

The reliance on linked geometry to host elements really isn't present between Revit Architecture and Revit Structure. In stead there is the issue of redundant modeled geometry and the documentation reliance on structural elements in architecture.

Many firms have worked through the first of the two issues by defining clearly what elements the structural engineer will own and which the architect will. Structure might own the slab, architects might own the floor finishes. Structure might own the roof deck (usually modeled as a floor) and the architect will own the roofing above the deck (usually modeled as a roof). It takes a thorough LOD document, but it can and has been accomplished.

The other issue here is a little more troublesome, an architect's reliance on structural elements to complete certain document deliverables. A lot of architectural firms fake in structure so that they can get documents out the door (e.g. foundation and stoop conditions, trusses, framing). Significant and detrimental time is lost when this is necessary to do but sometimes it is necessary.

Architecturally you have to communicate those shared items that are required and when they are required. Structurally you have to make modeling accommodations for the architectural documents.

I can hear the structural engineers now "easy for him to say". Well it is easy for me to say and it is easy for them to do. May I be the first person to say(although probably not really the first): structural engineers have had the least amount to change and adjust to in a Revit workflow. A little cooperation will go a long way on this one. 

I want to point out that LOD really solves both of these issues outlined above, but it doesn't have to be the AIA e202 document. Think about a collaborative requirement, think about a usable "desktop" standard, think about a logical and timesaving document that might just save your profit and really set you apart. Ok, horse officially beaten.

Long Lists: The Death of Revit Productivity

Revit project files are massive repositories for information. Views, data rich model geometry, annotation elements, schedules all existing in one location putting a stunning amount of information at your fingertips. This amount of stuff to understand introduces some productivity challenges. These challenges are not overcome without some well practiced methods and a deep understanding of where your model bottlenecks for the users. One of the most tangible metrics to measure a progressive Revit process and standards adherence is to look at the length of the different lists in the project file. This is about ease of use and standardizing your views and content.

Type Selector  - Lists seem to bloat for a couple of reasons: There are a ton of objects loaded into the model  including duplicate types and Type properties have been used to define important, schedulable object properties. Purging periodically works as long as you don't have the duplicate types placed somewhere in the file. The other thing to consider is if type properties have been used too heavily when an instance property might provide a useful flexibility. There are pros and cons to shifting your parameters around so do so where benefit is most easily gained (e.g. door schedule)

Line Styles - Even in a default template this list starts longer than I would like with few options to delete or rename the out of the box line styles. One can only hope to intelligently order the line style types so that they easily and logically sort themselves. If you begin the custom line styles with a number (e.g. 1-Solid, 2- Hidden) they are easy to sift through and order themselves at the top of the line styles list. Tip: The number doesn't have to directly correspond to the specified line weight, reserve the thinnest line weights for patterns and items in the distance.

Project Browser - There are a few areas here to pay close attention. First duplicating view types (in 2013 available for Floor Plan, Ceiling Plan, and 3D views) was always something that worked well for architectural sets. Many firms have a custom view and sheet browser organization often utilizing custom parameters sorted. My only tip here is not to overload your views with multiple view purpose parameters. Keep it simple with Discipline, and Sub-discipline, and duplicated view types to shorten up those view lists. The Project Browser can also be useful when placing families because they are all organized by their object category. For instance, when placing a component from the type selector you have a list that includes plumbing fixtures, generic models, planting, etc. all in one place. The project browser allows you to see the list expand by category you can click and drag the types into the view to place an instance.

Detail Components - These components are all the same object category so you have to be very mindful of naming conventions as you populate you model with these 2D components. These lists can be very long and without a naming convention to sort the list of components users will really struggle to work quickly and consistently with these.