If you did a web search for "sustainable" and "Revit" and ended up here, this probably isn't the blog article you were looking for. What it is, is an article about solving Revit problems and challenges to their sustainable conclusion. Sustainability is often associated with avoiding the depletion of natural resources and how that sentiment relates to the built world. What we will be discussing here is the sustainability of the choices we make when confronted with the need for a solution to a problem in Revit, or any other design software for that matter. I was first confronted with this concept when I was learning Revit in a capacity beyond a production designer. I had been asked to act as discipline BIM lead on a new project where I would be responsible for maintaining the mechanical model and troubleshooting issues that our users would run into along the life cycle of the project. Not yet knowing a lot of the inner workings of Revit at the time, I often leaned on our BIM Manager to bounce ideas off of. I would present the problem and my proposed solution and they would always respond with "I like your solution, but is it sustainable". This would in turn challenge me to think the solution through to its logical conclusion. This eventually became my mantra when considering any solution to a Revit problem no matter how large or small.
When considering moving forward with any solution in Revit there are three questions to ask: 1) Is my solution infinitely scalable? 2) How much maintenance does my solution require? and 3) How does my solution effect the current users of the model? These, in my own humble opinion, are the three most fundamental aspects of any problem solving or decision making. It can quite literally be applied to any life decision. Life translation: will my decision positively impact both the large and small aspects of my life, will I need to constantly revisit this decision and reassure myself it was the best course of action, and how does my decision affect others. Sorry, I'm getting off track, and quite honestly, a little preachy. Lets get back to it and look at some examples of sustainable and non-sustainable solutions to each of these questions.
Is the solution infinitely scalable? This is probably the most challenging of the three questions as it requires trying to think of all of the possible pitfalls and loopholes your solution might run into...good luck. This is really where it is best to bounce your ideas off of both lesser and more experienced users than yourself. It will give you perspectives and insights that you may not come up with yourself, because quite simply, you just haven't run into them yourself.
How much maintenance does the solution require? A sneaky one to pin down since there is no real definitive scale to base it on. How much maintenance is a lot or a little. Just because you are maintaining the solution daily doesn't necessarily make it a lot especially if it is being done as a regularly scheduled daily maintenance. On the flip side, just because you don't have to do it often, doesn't mean its easily maintained. My favorite example of a sustainable solution was one that came out of merging two non-sustainable solutions and showcases answers to both the scalable and maintenance questions.
When trying to pull off a successful project in Revit for an Industrial client, you are faced with problems that the average commercial Revit project isn't faced with. One of those problems is the shear quantity of pipe system types and how and where those appear on sheets. During the project I mentioned earlier, I was BIM Lead for the mechanical models and my colleague was BIM Lead for the process models. To meet the requirements of the client CAD standards, certain pipe system groups had to be shown on specific drawing types. I don't want to diverge too much into what that means, but to put it simply lets say that all of the chilled water systems could only show on certain drawings, and the heating water systems could only shown on others. To accomplish this within the same Revit project files, we used a series of view templates and view filters. My solution consisted of making an opt-in filter for each pipe system type within my models. This gave me an on-off switch for every pipe system, which meant that every on-off switch had to be added to each view template so that each system that didn't belong on the sheet could have its visibility unchecked. This worked just fine in my model set because the amount of mechanical system types were in the dozens and were finite, so once they were built the job was done and required no further maintenance. However, my colleague's system types had the potential to be in the hundreds and subject to continuous additions. They're solution was to add a prefix to each new system via the system browser on a daily basis. The prefix was based on the client CAD standards that outlined how the systems should be broken up into groups or sub-disciplines. In turn, an opt-out [am I using this analogy correctly?] view filter could be added to the view template for each system type group, and would look for all systems that didn't fit the criteria and used to turn their visibility off. This solution posed as the gateway to the final solution but in its infancy wasn't scalable either and required constant unpredictable maintenance.
So what now, how did we follow these two solutions to their sustainable solutions? To put some back story to the problem, we were currently using the System Abbreviation to tag the system type and our system type name was a description of the system itself. Short of creating yet another project parameter to clog up the works, we needed a clean solution that was both scalable and required little or no maintenance. The solution was to stop using the System Abbreviation to tag the system and start using the system type name. This required renaming all of our current pipe system types to their abbreviations. Doing this freed up the system abbreviation parameter so that we could add the system group prefixes that my colleague had been using to handle his filters. If you're not familiar with the MEP side of Revit, Revit uses the system abbreviation parameter to name systems, for example, if my system abbreviation for chilled water supply is CHWS, Revit creates chilled water systems CHWS 1, CHWS 2, CHWS 3, etc... It required quite a bit of work up front, but zero maintenance on the back end. It was infinitely scalable, because no matter how many pipe system types we had to create they would be built so that they fell into a system group and met their view filter's criteria. This was effectively doing the ongoing maintenance that my colleague had been doing but automatically, behind the scenes, seamlessly, and sustainably.
How does my solution effect other users? Lets try to have some fun poking, prodding, and ruffling some feathers with this one. We all know that at any time there are no less that a half dozen ways to get the results you want in Revit. But five out of six of the ways are instant gratification my friends and ultimately lead to no good. I recently had the pleasure of coming into work one morning and booting up my email to find a flurry of activity from my team telling me that their annotation was all mess up in their model. After a couple minutes of investigation I found that the root of the problem was that someone had changed the text height of our standard annotation text type. Well, you can't blame a person for trying and they did what anybody would do and took matters into their own hands. However, if they had asked themselves the three fundamental questions of sustainability they would have gotten to question number three and thought: "nope, that's not going to work. If I change the text height of the 3/32" text type to 1/4", that's probably going to have some negative downstream effects on other users." As far as examples go, I could go on for days: changing standard view template settings for one off instances instead of making a custom view template, changing annotation family settings instead of saving out as a new family, modifying view filters instead of creating a new one, on and on and on. At any rate, this is quite possibly the most important question to ask yourself whenever approaching a Revit problem and solution. Especially since we're dealing with a piece of software that inherently provides multiple solution paths to any problem. How is my solution going to impact others? The best solutions don't impact other users at all but rather improve their lives seamlessly, and sustainably.
So the next time you're faced with a Revit challenge and find a solution, ask yourself the three fundamental questions of sustainable problem solving and see where it leads you. I hope it leads you to a better solution and a better Revit.