Being a Bad Host

I remember when I first starting using Revit Architecture, we were modeling key structural elements ourselves and using linked CAD files from MEP to complete our RCPs. I would bug my reseller at every turn to help me understand how the disciplines would work together without answer. Then an "Autodesk guy", as he was referred to in later conversation, told our Revit users group that Revit MEP wasn't ready yet and that no one should use it. They of course continued to sell it.
 

Many years later I am 3.5 years into my use of Revit MEP and have had the pleasure to see how many different firms are exploiting or suffering through a multi-discipline Revit workflow. Revit MEP and Revit Architecture's problems seems to be with the high level of dependency MEP objects have on host Architectural faces.

It is very easy for an architect to delete and recreate geometry that is, unapparent to them, the host of an MEP object. This destroy's the "warm and fuzzy" feeling Revit gives us about elements staying spatially coordinated.  In fact it can be a nightmare even if the element remains hosted. For example, sometimes a ceiling might move for some design purpose. If elements are hosted to those that have hard connections (e.g. ducts and air terminals) the architect runs the risk of destroying duct networks that don't have the space to adjust.

2 strategies need to be undertaken to make sure this works better:

First, Communicate design changes out side of Revit. This one is an age old problem between architects and MEPF consultants. You either need to setup a brute force way of communicating (email report of model changes by room upon receipt of a new model) or a software centric comparison automation (in Navisworks or the Compare Models Revit extension).

The most important change that needs to happen is both parties understanding the limitations, implications, and realities of a coordinated workflow in Revit.

Second, MEPF engineers need to respect and anticipate how the architect's model will change. MEPF engineers can host elements on reference planes where hosted and orphaned elements are sensitive to change. The model adjustment will be manual but many hosted elements can be changed at once. Or maybe no elements should be hosted at all. I ran an unconference session at this past AU called "Leveraging and Architect's Model in Revit MEP" and this was the sentiment of the group that attended. Those that had once hosted on planes no longer do so. A vast majority actually have a standard for non hosted components for everything.

Bottom line, this is a two way street. Architects need better ways to communicate changes per model update, and MEPF engineers need to host (or not host)objects in a way that protects them against damage caused by changes out of their control.

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.