One of my (many) projects these days is wrangling our long-standing CAD standards and much-newer BIM standards into a single, unified “Graphics Standards Manual”. As I try to get a grip on this spaghetti bowl of topics, I’ve started to divide them into two categories: process and outcome. You could also call it screen vs. plot. Or, in complete sentences: “How does it act?” vs. “How does it look?”
Today, these two halves of a model or drawing are about equal. I suspect, as we continue to move closer to IPD, the “process” side will begin to prevail. Today, however, I’m more likely to see a QC comment complaining about the symbol representing a kicker than about the fact that it’s a faked-in detail component when it should have been modeled.
This philosophical division also helps categorize standards topics into “CAD”, “BIM”, and “graphics”. The first two are process-based, such as project setup procedures for each system. The last is outcome-based, such as our typical abbreviations and acronyms. Some topics span all three categories, like the information contained in a graphical column schedule. What that schedule looks like is part of Graphics, but getting it there is part of CAD/BIM.
I’m still working on the best way to organize all these discrete yet related topics. My ideal scenario would be a fully-linked searchable database or website. For now, we have OneNote. It’s pretty good, but harder to lock down against inadvertent editing than I would like.
As I keep writing things down, I’ll post the categorization here, but in the meantime, how do you handle unified standards for separate software solutions?
BIMmuse 
I live more in the mechanical engineering world than in the architectural space, but I can certainly appreciate your quandary. Nice post explaining the challenge of process versus outcome. I think one important consideration in this debate is the level at which your work product will be consumed/shared/reused. For example (in my world), if your work product is a STEP file, it doesn’t matter how the model features were ordered to arrive at that result, so process standards aren’t relevant. On the other hand, if your work product is a SolidWorks file, good modeling practices are important to the downstream use (and reuse) of the work product.
I did want to share a thought with you on how to manage your standards manual. OneNote is a great tool, but I agree it has limitations. You should consider a wiki as an option. If you have SharePoint available (many people have access to it but don’t use it), it has a built-in wiki with pretty rich features. If you don’t have SharePoint (or another wiki engine) available in your IT environment, take a look at something like http://tiddlywiki.com/. You could even share it on DropBox or some other file sharing platform if you don’t have access to build/share your own web-based wiki. Just a thought.
Nice blog post, thanks for sharing.