Do owners care who provides the info?

I attended a local BIM meetup a few weeks ago, the BoBTech (Boulder Building Technologies) Meetup group, and was asked an interesting question. Do owners care who the final model comes from for Facilities Management? Should we?

From a certain perspective, the answer is no, we don't necessarily care. At the end of the day, we need to know where our assets are located and to have all the appropriate asset data associated with it. Whether this comes from the designer, the contractor, or a third party is largely irrelevant as long as it is in the correct format.

However, we also know that we are less likely to get accurate system design information from the contractor, the designer has that. We also aren't going to get as accurate spatial coordination information from the designer unless they coordinate with the contractor. A third party doesn't have any of the correct info to start with, which means redoing the most work and costing the most money.

The responsibility for Record Drawings has traditionally laid with the design team. The information from the built condition for the final Facilities Management model should be reflected in the Record Drawings. That may sound obvious, yet it is rarely the case in practice.

So do owners care who provides the final model? Should we? Yes, we do, and we absolutely should because who we receive that model from is going to effect the accuracy of the information and the cost of providing it. The record drawings and record model are where the Facilities Management model should come from and those are still clearly the responsibility of the design team.

Revit 301: Copying Spaces from a host model to multiple consultant models

Some time ago I was working on a large project with an extensive Facilities Management component planned for post-occupancy. Because the designated FM software cannot pull Space data through a linked model for the various MEP trades, each one of the 15+ design consultant models needed to have all of the necessary Spaces within the models.
That's a lot of repetition, especially considering there were six separate models with room bounding elements. A process made even more challenging because the design models continued to change after CDs were issued as outstanding design issues and decisions were resolved.
As a result, the decision was made to model the spaces in a single model, then once everything was finalized and approved by the designer, client, and FM consultant, to have each consultant copy the spaces from the Spaces model into their own.
As it turns out, I was lucky enough to draw the straw for making this all work.
The space tool is on my personal list of least favorite Revit tools, and I anticipated a fair bit of frustration in working with it under these conditions. What I hadn't anticipated was the dance I eventually had to do in order to make it so the spaces could be copied with an absolute minimum of fuss into the mass of consultant models. As I hadn't come across any tips for putting this process together, I thought I should share it here.

This post assumes you already know how to place and work with spaces. In fact, it assumes that effort has been completed and you're just looking for a way to get your information propagated into a bunch of other models. If you need help working with spaces, other resources already exist addressing that, though I will likely post something with lessons learned along those lines eventually as well.

The setup process for prepping the Spaces source model for copying is below, followed by the process for copying sent to all of the design consultants.

1. Determine which Levels have spaces on them and which do not.
2. Create a view for each Level that has Spaces on it. Create a View Template for those views and hide all modeled elements, annotation and linked files. Hide everything except for space elements. Turn on References and Fill for the space elements.
3. Create a schedule of all spaces (Spaces by Level) with the Level and Count fields in the schedule. Sort it by Level and uncheck Show All Instances. This will ay space hosted to each Level, and only spaces hosted to that Level, with a single click.
4. Open up your first Level side by side with the Spaces by Level schedule. Select the line for that Level in the schedule, this will select all of the spaces for that Level. 

5. Switch to the plan view (Alt+Tab), being careful not to deselect the Spaces you have selected

6. Check the count from the Filter Tool against the count for the Level in the Spaces by Level schedule. They should match exactly. Also take a quick look at the Host Level in the Properties window, this should list just the current level you're working with. If it doesn't, then you have spaces for other levels still visible in the view.
7. Repeat steps 4-6 for all of the other Levels which host Spaces.

Seven Deadly Sins of Revit

As a facility owner with millions of square feet of buildings and dozens of projects going on at any given time, my team and I look at a lot of models and do a lot of QA. We see a lot of mistakes, and we also see a lot of efforts to get around our standards. We also have to live long-term with the consequences of poor work.

Consequently, here are my Seven Deadly Sins of Revit:

1. Faking it - I've seen every type of fakery you can imagine... Detail lines or model lines (it says Model, so that makes it okay, right?) in place of model content. Dumb annotation in place of tags. Drafting lines or CAD in place of schedules. Text hiding actual dimensions.

If you're faking it, you're not just doing it wrong, you're costing yourself time and money by not taking advantage of the efficiencies built into the tools.

2. Importing CAD files - I've seen this listed as a "Best Practice" in some trainings. There are two problems here though. The first is that importing CAD files is a common cause of fatal errors, particularly if they are exploded. The second is that importing a CAD file requires a good bit of prep work and cleanup to do it 'right'. Lots of prep + lots of cleanup + raised chance of a fatal error = Deadly Sin, definitely not a Best Practice.

3. Opening a file in the wrong version of Revit - This one pretty much speaks for itself. If your team is working in 2017, and you open your model in 2018 by mistake, chances are you're going to have to do some rework when you realize you're in the wrong version later.

4. Using Worksets like Layers - This seems to be becoming less common, but I still see it from time to time among less savvy firms. They see something that looks like it can be used in a familiar manner and latch on to it, instead of learning to use the tools the way they were designed to be used.

5. Abusing Model Groups - Model groups are a great tool, but they can be abused pretty easily. One of the more common causes of model corruption is the exclusion of elements in instances of model groups. Model Groups should always be a temporary solution for a design problem, not a long term one. And excluding elements from instances should not be used.

6. Internet Content - Content downloaded from the internet, whether from a manufacturer or a site like Revit City, should always be avoided. Manufacturers always over model their content and add all sorts of whacky parameters that can take ages to figure out. Online libraries like Revit City face similar challenges, and have no QA associated with them, there is absolutely no telling what is inside that content. Downloading content may seem like a time-saver, but cleaning it up is bound to bite you in the end.

7. In-Place Families - 'I'll come back and make a proper family later' is the typical refrain here. There's rarely, if ever, time to do that later though. Build it right the first time, it's faster than having to build it twice. There is a time and a place for In-Place families, most applications of IP do not fit that condition though.

On the flight of fee

Several months ago, an article was published by a mechanical engineering firm pronouncing BIM to be a red herring. There were a host of issues with the author's arguments, from logical fallacies to a lack of cohesion, enough so that they're not really worth getting into.

However, the article did highlight (indirectly) an important issue facing many engineering firms, the issue of fee shrinkage.

As the author correctly noted, back in the 70's and 80's engineers started shifting constructability issues to field (contractor) responsibility to avoid liability. Well, when you remove liability, or shift it elsewhere, fee goes with it, which I suspect is what is really at the heart of the matter here. Fees are falling as liability has been exculpated and many firms find themselves not knowing what to do about it. 

Some firms will look at falling profits and decide they should cut their liability further, as was done in the early 80's. I wish them luck as I don't know how much more liability they can really cut. Instead, liability must be wrested back from the contractors. Designers should demand greater responsibility for their designs and the attendant fees for that responsibility (and demonstrate they can follow through on it). The problem there is that designers commonly lack the constructability insight that contractors have (which is why we get uncoordinated design models), so that knowledge must be captured in some way. A few methods would include merging with a construction firm to provide a one-stop shop. Hiring tradesmen and bringing their insight and experience into the office. Sending out the design interns to work in the field for a period of time. Think outside the box. Take the lead and take responsibility, owners certainly aren't going to pay the same fees (or larger ones) for designs which take even less responsibility.

This is ibviously a simplified look at this issue, there is no magic pill or silver bullet to halt the flight of fees. However, our industry is going through a sea change, as it did almost 30 years ago when CAD displaced hand drafting. Firms have a choice in this change. They can take up the banner and take the lead down the BIM path. They can follow the leaders letting others blaze the trail and move along in their wake, either willingly or fighting the change step-by-step. Finally they can opt to resist the change in whole and continue down their same path, just like those unfortunate firms who have faded into memory, clinging fervently to their vellum, t-squares and drafting pencils for their construction documents.

What path they each take will be up to them.

Around the BIMternets

Links to some of the articles and BIM blog posts that caught my attention recently:

The BIM + Integrated Design blog has an interesting post on Flux, a Google driven software. It's more than a little bit on the pie in the sky side, but a good read nonetheless. Preston-Werner's quote in the opener was an amusing example of a coder who might need to spend some time seeing the world through something other than code.

The videos for BIMForum Dallas are up. I'll be eating up some time watching these myself over the next few weeks.

The Revit Kid had a short but useful post about a curtainwall manufacturer who is using Revit for highly detailed shop drawings. I love seeing manufacturers using BIM processes.
TheRevitKid.com and the blog of the curtainwall detailer.

What Revit Wants has a great quote from the October 2014 Augiworld by J&S Mechanical. In short, stop trying to make Revit act like AutoCAD and it can do great stuff for you. Including fabrication with SysQue.

CTC's BIM Project Suite has been updated. It's not a plugin I've used before, but their free Revit Properties tool caught my attention, allowing users to right-click to get info on what version of Revit it was saved in, whether work sharing is enabled, Central v. Local and a few other useful tidbits.

Changes

For four and a half years I worked for a small architecture firm in Denver as an Intern, Job Captain and BIM Manager. As a firm we were dedicated to pushing BIM as a valuable set of tools to our clients, our consultants, our contractors and ourselves. We did this passionately, in some cases knowing we were trying to sing into hurricane winds, but still hoping one or two notes would get through. Often we made progress. Occasionally we knew that at the very least, we'd be better practiced for the next effort to cajole someone onto the Starship BIM.

Six months ago that came to an end as I departed for a new opportunity. No longer will I be trumpeting and pushing BIM as a designer. Instead I will be pulling as the BIM Manager for the fifth largest facility of our type in the nation. We have arguably the highest BIM standards in the region and, within our particular industry, perhaps the highest standards globally.

So far this has been an incredible opportunity. Leaving the design industry and coming over to 'the dark side' as a facility owner has been an eye-opening experience.

This will still be my personal blog, not associated with my employer, all opinions here, expressed or implied, are my own and do not reflect official or unofficial positions of my employer.

What is changing is that instead of thinking about BIM and Revit in terms of small-business implementation, I will be considering it more directly from an Asset Management perspective, particularly in regards to aviation implementation.

Let the journey begin...