Omniclass Table 49 and the Sumex Parameter Manager

Over the past two years or so, I have been working on the development of a shared parameter file for the Omniclass "Properties" Table (Table 49). While I have finally come out with a useful version of the file that I am comfortable sharing with the world, I had also realized that in the process, impementation of the file was going to be cumbersome due to the method by which Revit sorts Parameters.

In a Revit Shared Parameter file, parameters can only be grouped once, with no further subgroupings available. In the real world, there is so much more that is needed in order to sort and organize the attributes within projects. All of the CSI Standards leverage 3, 4, 5 or more levels in their organization structures, but the parameter managment in Revit only allows for one level. The Table 49 Shared Parameter file is grouped by its highest level, and then numerically based upon the succeeding levels. Handy, but but still doesn't allow for proper management of the nearly 1000 properties. In order to combat this, rather than try to reinvent the way parameters are MANAGED, I decided to rethink how they are LOADED.

The Sumex Parameter Manager changes how we might think about the administration of project information. Instead of loading parameters one at a time, object by object, or into a project, this affords the ability to batch add parameters to hundreds of families at once, whether they are in a library on a hardrive or within an open Revit project.

The Sumex parameter manager can leverage the Table 49 Properties Shared Parameter file to build a Schema which will load various different parameters into various different families based on common attributes found whithin them. This is explained more in depth below.

The Omniclass Table 49 Shared Parameter file is available in two differnent configurations, based upon whether or not it is being used with Revit Architecture or Revit MEP. Some of the physical properties can be more accurately conveyed in Revit MEP than they can in Revit Architecture, simply based on the availability of the parameters within the software. MEP based parameters are left as simple text parameters in Architecture. Both Files, along with more information on the Sumex Parameter Manager can be found here:

• Sumex Parameter Manager
• Omniclass Table 49 Shared Parameter File - Revit Architecture
• Omniclass Table 49 Shared Parameter File - Revit MEP

What the SPM Does:

Parameter Management
The Sumex Parameter Manager allows a Revit user to Add, Remove and Replace parameters in Revit Families in bulk. This means no more opening, modifying, saving and closing every family one at a time to add the attributes. Not only does it allow for updating families in bulk, but leverages “Schemas” that can assign specific attributes based on specific criteria.
Whether you want to add parameters to your Revit project categories, the families loaded in a project, or your entire family library, the Sumex Parameter Manager has the ability to manipulate parameters in both projects and families.

Schemas
Think of a “Schema” as an office master for your Revit Families. Schemas are data maps that
describe how you want information to be passed into Revit. They work alongside an existing shared parameter file, and allow you to assign or “Map” parameters to one or more
Revit Categories, MasterFormat™ Keynote designations, or Uniformat Assembly
Codes. This allows the software to work quickly and update an entire library based on information that is likely already available in the Revit families that you want to process. Schemas can be saved for future use and can be created and modified using the included Schema Builder interface or for advanced users, a text or spreadsheet editor may assist you in working more quickly.

How it Works: Let’s say that you want to add 7 parameters to all of your window families, and 5 parameters to all of your door families. Leveraging your existing shared parameter file, the Schema Builder” assigns parameters based on Revit Category, MasterFormat™ (5 or 6 Digit) Keynote, or Uniformat™ Assembly Code. You can even assign a Level of Development to each parameter to filter only those which are relevant to the amount of detail you want in your project.

Why Sumex Parameter Manager:
Since 2005, Sumex Design has been at the forefront of developing AEC content, from specifications, to CAD files, to Revit components; we have created 8000+ Revit Families for over 300 manufacturers and successfully implemented BIM into their AEC toolboxes. BIM is as much about data as it is about graphics.

Being specifiers as well as seasoned content developers, we understand that a critical part of implementing BIM is processing the information in the model. Without a painless strategy for data management, the widespread adoption of new BIM standards becomes an uphill battle. At Sumex Design, we’re sharing our expertise and techniques with the world, by creating data management tools.

We know you have options, and that you’re already spending enough for your software every year, so we’re keeping costs low. At $249.00 USD, the Sumex Parameter Manager will add invaluable new functionality to your current workflow and save you countless hours of time processing, updating and organizing your BIM library.

Downloads:

• Sumex Parameter Manager
• Omniclass Table 49 Shared Parameter File - Revit Architecture
• Omniclass Table 49 Shared Parameter File - Revit MEP
  

Interesting Article - Joshua Prince-Ramus on The Myth Of Architectural Genius

http://www.forbes.com/2010/06/12/architecture-eco-buildings-technology-future-design-joshua-ramus.html

This is a great article, and smack in the middle of my wheelhouse, so I thought I would point it out. It made me see that there are many architects that are still somewhat shortsighted and nervous when it comes to BIM. While it is scary to get into new technology, CAD was not the demise of Architecture, nor will BIM be. Some excerpts from the article that I thought were worth mentioning:

The biggest change in our profession is what's called building information modeling, or BIM. It will either be the harbinger of death or the salvation of architecture. BIM creates a three-dimensional model of a building in which every piece is tagged in terms of price and time. It lets you discover ways of construction and sequencing and optimizing shapes for cost.

Many Architects are selling the technology short, and this is just one case of it. BIM can do far more than analyze Cost and Time, but more importantly manage the nouns, verbs and adjectives (What, How and Why) of every aspect of a building. If someone selects a specific window, the information includes a “Why” based on the properties of the window (Energy Efficiency or Light Transmittance/Refraction). A wall knows that it has certain sound characteristics, fire characteristics and structural capabilities. By leveraging this type of information a building can be looked at as a “Whole” rather than a sum of its parts to streamlie design and create more efficient buildings for the lowest cost.

The reason why it could be the harbinger of death is that the technology is incredibly complex and operating the software is a specialty in and of itself. That person makes a lot of assumptions and spits out the options to be picked (I call that design) by the architect (which I call "stylist"). That further marginalizes the architect from the center of the project, which is the realm of project management and structural engineering and acceptance of liability--the execution side of things.

I am in partial agreement with this statement, and I am that specialist that he talks of. I disagree of the marginalization of the architect though, as an architect’s strengths are in forging the Design Aesthetic of the building, and hire others to implement the design through hand drawings, CAD and now BIM. The technology is creating the need for that “Stylist” which I refer to as the “Knowledge Manager”, who is little more than another employee of the architect. It’s the Building Owners that will drive the demise. If they choose to go with more standardized designs, then the need for the “design aesthetic” is diminished. I just don’t foresee than happening, since Architecture is the convergence of Art and Engineering, with the emphasis on Art.

All of this is why I decided to write a second book (I Just got the contract from Wiley Press last Thursday) on the need for management of the information and processes within a BIM project. This eliminates the “assumptions” that he discussed here by having a seasoned professional (Architectural Construction Specifier), like myself as an administrator of the project (Stylist, Knowledge Manager) from the earliest design concepts all the way through to Facility Commissioning and ongoing lifecycle and maintenance. I’m looking for case studies in the Boston Area right now, and the book will be released at the American Institute of Architects (AIA) show in 2013. I am hoping that more professionals like this will identify the need for information and process management as time goes on.

Classification Systems for Building Products and Materials

In this day of BIM based design, the concept of cataloging materials has been turned on its ear. It’s no longer enough to just see what a material looks like in a 3”x3” sample chip and hope that it is what you want for a project. BIM affords design and construction teams the ability to not only thoroughly visualize, but quantify and qualify the material based on its merits and the design intent of the project. What I mean by this is the ability to embed computer readable information into a material that tells us not just what a material looks like, but what it “is” and how much of it is present on a project or in a given location. This is a tremendous benefit to both architects and contractors, giving them the ability to analyze product options and determine alternate solutions through cross referencing attributes.

Let’s suppose a solid wood material is specified on a project in order to provide the necessary density on a wall that is designed to reflect sound. Let’s also suppose that the wall has substantial curves, making the bending of the material very labor intensive, and potentially detrimental to the integrity of the wood. Rather than accepting the material at face value, researching materials in order to find an alternative product that achieves the required density, but is more flexible might lead the designer to a laminated material with a high density backer that meets the design intent, looks the same, and is less expensive. The difficulty in this type of operation is ensuring that the information about what the material is, how it performs, and what it looks like needs to be not only catalogued, but standardized.

The Construction Specifications Institute (CSI) develops and manages standards and formats that surround the AECOO communities, including MasterFormat™, Uniformat™, and the series of Omniclass Tables. The rapid growth of BIM creates a need to organize materials using not only methods understandable by people, but also by computers. To simplify, BIM software is little more than a series of tables in a database. These tables have relationships with one another, and in order to ensure that the connections are not broken by the use different colloquialisms or a varying taxonomy, each entry in a table should have some sort of unique identifier (GUID), or “primary key”. This is where CSI comes in. Just as MasterFormat catalogs the resulting effort of a given task, and Uniformat classifies entire elements within a project, Omniclass Table 23 – Products, and Table 41 – Materials catalog specific building products and materials so that regardless of the actual naming, a computer can understand what the user is referring to. It is no different than a librarian using the Dewey Decimal System to Catalog an entire library of books.

In terms of a library, the 200 Class (Level 1) within the Dewey system refers to Religion, with subcategory 220 (Level 2) referring to Bibles. There are entries beneath 220 which refer to the Old Testament (221) and New Testament (225), as well as other books which fall into the same category of “Bibles”. The word “Bible” needs to be put into context though, as the term has also been associated with anthologies and books that are designed to be all-encompassing, such as the AutoCAD Bible from Sybex Publishing. Even though libraries and bookstores have become keyword searchable, the Dewey Decimal system is still used to actually find the book or periodical within the larger bookstore or library, and create a singular reference for a certain type of book or specific title. This allows a machine to make a unique reference to a book, and only that book.

Similarly, a building product or material has the same hierarchical structure using Omniclass. Table 23 organizes products using four grouped pairs of digits, where the first is always the table number, in this case 23. As information is added, additional pairs may be added to further elaborate on the product. At the top level, table 23 products would look like this: 23.00.00.00 – Products, and at its most detailed fifth level it might look like this: 23.30.10.11.34.17 – Mail Slot. In this example, 23.30.00.00 (Level 1) refers to “Openings”; 23.30.10.00 (Level 2) refers to “Doors”; 23.30.10.11 (Level 3) refers to “Door Components”; 23.30.10.11.34 (Level 4) refers to “Door Accessories”. While one person might refer to the component as a “mail slot”, another might refer to it as a “postal opening”. Either way, the classification system will allow the user to choose the taxonomy while still allowing a computer to understand the intent.

Omniclass Table 41 – Materials performs the same operation, but rather than considering Building Products, it considers actual physical materials, regardless of their origin. It organizes materials down to their elemental level, which may not seem relevant, until you consider that specific chemicals may be banned from a project, or certain types of materials may be favorable. Table 41 uses the standard Omniclass “grouped pairs” format with Level 1 organizing materials into Periodic Elements, Solids, Liquids, and Gases. Level 2 through 5 dive deeper into the categorization of a material where level five 41.30.20.11.99.11 refers specifically to Cast Iron, which is different from Wrought Iron (41.30.20.11.99.14) or Ductile Iron (41.30.20.11.99.17).

Within each of these material and products, there are a series of attributes or physical properties which define what it is, how it behaves, how it performs, what it looks like, and a host of other considerations. Omniclass Table 49 – Properties creates a taxonomy that allows attributes to be given specific names and identifiers, making them uniform and machine readable. There are many different names which can apply to the same attribute, and a single character, capitalized letter, or mark in the naming will throw a computer for a loop. For instance, in some circles, the term U-Value is used, where in others, the term U-Factor is used. Those who understand what is being discussed may know that the two terms are synonymous, but a computer does not. By leveraging Table 49 and creating an enumeration strategy, one can assign specific attributes to building products and materials, and ensure that all of the information will show up in database reports, exports, and schedules.

With a membership base of Building Product Manufacturers, Architects, Specifiers, Engineers, and Contractors, CSI has more knowledge and experience than any organization in categorizing, classifying, and cataloging building materials. As the keepers of MasterFormat, Uniformat, and Omniclass, the expertise of the membership is implementing standards and formats for use in BIM software. This allows BIM software and processes to grow from visual design tools to data rich analysis and digital prototyping models. Structuring models to be useful for downstream usage requires that information be clear, concise, complete, correct, and consistent. It is arguable that without standards and formats developed and maintained by CSI, none of this would be possible.

Organizing BIM Content by how it is used

Implementing the Component: Primary, Secondary, and Tertiary

Components which are added to an architectural model can be categorized as primary, secondary, and tertiary. Exactly which category a specific component fits into depends largely on the individual or discipline. In addition to the architectural components, a series of structural, mechanical and specialty components are used to further detail the model for design and analysis through specialty consultants and contractors. For architectural purposes, it is not always necessary to add each structural element, mechanical equipment, or specialty components unrelated to the design intent. In many cases taking into consideration only basic dimensions and locations is acceptable to allow other contractors and consultants to design based on the spaces allotted. While this is a disjointed approach and in no way collaborative, it is not an uncommon practice, and as such should be taken into consideration when thinking about how to organize the various types of components used in modeling.

Primary components are made up of the core elements used to enclose and access spaces; floors, walls, ceilings, roofs, and openings. These elements of the project are the first to be added, often during schematic design. They divide spaces, create layouts, and enclose the overall building. Walls are added into a project and used to enclose and divide spaces. It is important to maintain a consistent reference point within the wall so that they align properly. Because walls have several materials within them, from structural, to surfaces, to finishes, and determining the reference point is often specific to the needs or type of project at hand. When creating exterior walls, using the exterior edge of the structural member as the reference plane may prove to be the most effective, where when creating interior walls, the center line of the wall may be most effective. Using a consistent strategy for aligning walls minimizes the risk of errors through design development. In many cases the number of layers and thickness of materials within the wall is unknown until well after the original walls have been placed. A great deal of time is spent manipulating these elements such that they may become permanent as design development progresses. Once the design begins to consider secondary components, it is common for errors to occur should the primary components need to be moved or changed. Developing a strategy for creating, maintaining, and organizing wall assemblies will allow walls to be swapped out at any time without the risk of moving walls due to differing reference points.

As Bim technology improves, the number of components which may be defined as secondary is increasing. Before they were made readily available, components like toilet partitions and fixed furnishings were not always graphically modeled. This is largely due to the amount of effort required to create a graphic representation of a component. As more manufacturers make their components available, the number of designers wanting to place them in their model increases.

Secondary components are essential to the design, but made remain largely unknown or undecided until later in design development. They rely on the dimensions and locations of the primary components for decision-making and product selection, and are generally non-structural in nature. The most common secondary components on projects are stairs and railings, fixtures and fittings, casework and cabinetry, specialty partitions, and certain types of fixed furnishings and storage. These types of components are essential to the understanding of spatial relationships, and the conceptualization of many aspects of the project. It gives the owner an understanding of what the space is used for. The walls may define the boundary of a kitchen, but the cabinets determine what it is.

If we think about different components in relationship to the overall size of the project, we can make the determination of how graphically accurate they need to be. Secondary components are those that are integral to the design, but not integral to the structure. In most cases these types of components are selected based on their appearance as much as they are based on their performance. When component is selected partially or entirely based on its aesthetic, how it is represented within the model becomes more important. The frequency at which these components are placed in the model is also a consideration when determining the graphic accuracy. If a component is placed in the project only once but is selected solely based on its aesthetic, it is reasonable to put more effort into its graphic accuracy, as maintaining its performance and file size is not as relevant as a component such as a door which may be placed hundreds of times throughout a single project.

Component size and location also come into play when considering the graphic accuracy of an object. A good rule of thumb is if you can't see it from 10 to 15 feet away in its installed position, don't spend a lot of time on it. This is a typical distance which is used for up-close rendering. Since the primary reason for making close representations of products is to improve the rendering aspect of the model, if it's not being rendered, it might as well be a cube. There are many components in a project that are actually very small. Whether it is a light switch, a drawer pull, or a window crank, deciding how accurate these components must be is important undertaking. While every manufacturer wants to think that their components are the most important, we have to look at the model in terms of scale. Ask yourself how important a window crank is to a 1,000,000 ft.² building, and what purpose it serves if it is not visible in rendered views. The answer lies in its ability to be quantified and qualified. If a component needs to be quantified or qualified, it can add value to the model. Let's go back to window hardware as an example and look at three possible scenarios: 1.) If a manufacturer offers several hardware options, and it will likely be visible in many rendered views, it should be added to the model graphically and have the ability to select options. 2.) If a manufacturer offers several options for the type of hardware used but it will not be seen in a rendered view, it is more effective to list the hardware as an attribute of the window without graphically modeling it. 3.) If only one type of hardware is available from the manufacturer, is perfectly acceptable to omit from both the graphics and the information contained in the project. If there are no choices which may be made, and the component is not commonly used for selection or specification purposes, then adding it to the model offers little value to the architect, specifier, or contractor.

Bob's BIM Tip: If you can't see a component from 10 to 15 feet away in its installed position, don't spend a lot of time on it.

Tertiary components are those which are added during detailing, or not at all. While it is my belief that every component that is used on a project should be brought into the model in some way, shape, or form, that does not necessarily mean it should be done graphically. There are ways to embed information regarding components without actually placing them in the project, and there are ways to simplify how a tertiary component is placed in a model as well. Hopefully this will minimize the number of tertiary components within a project, and increase the number of secondary components. Over time this could translate into more accurate models, and a greater demand for as-built models as a final deliverable to the owner.

A component like door hardware is an essential element within a project, is found in hundreds of locations, and even has its own special schedule, yet it is arguably a tertiary component which is often overlooked or omitted. Most architects choose not to deal with door hardware for the amount of effort necessary versus the benefit received from placing it in the model. Components like this are often better represented in context. Door hardware is a function of a door, and as such should be placed and controlled from within that door. Rather than attempting to place door hardware components at each location within the project, making door hardware a function of the door itself can allow it to be a graphic aspect of the model, and carry the important information to its respective schedules.

Accessories, movable furnishings, and equipment are tertiary components. Because they may be relocated at any time, and are more commonly used for conceptualization and space planning, these types of components are typically not modeled. As a general rule, when the placement of a component is not integral to the structure or the design of a project, the component can be considered "tertiary". Another way to look at it is if there is no specification section for the component within the project, it is probably a tertiary component.

High Performance Annotations

The method I use to annotate with BIM is to add a material AND its Specification Section Number to the annotation for vendor neutral materials that are not specifically called out. (06 11 00_2x4 Dimensional Lumber – Species as Noted in the Contract Documents) or (07 54 00_TPO Membrane – Thickness as Noted in the Contract Documents). I use the term "Contract Documents" here as there are changes happening in the industry, and while the contract document now would be the Project Manual, in the future, it may not be. One may reference a tabular specification, or formatted data sheet of some kind. The descriptions are very fluid and allow for modification based on the amount of information known…

A knowledge manager may handle the annotations for the Roof Membrane Layer in a section view of a roof like this:

• PP - (07 00 00_Roof as Noted in the Contract Documents)
  
• SD - (07 50 00_Roof Membrane – As Noted in the Contract Documents)
  
• DD - (07 54 00_Roof Membrane - Thermoplastic – As Noted in the Contract Documents)
  
• CD - (07 54 23_Roof Membrane –.060 TPO – Tan)
  
• Post Bid - (GAF EverGuard .060 TPO Membrane – Tan)
  

The idea is to give an appropriate description based on the amount of information known at a given time, and reference the Contract documents for the next pieces of information which may be necessary. This allows the annotation to always be correct, regardless of how much effort is put into the annotations, or if they never get updated past Schematic. I use phases as an example above, but I see phases as we know them disappearing to some degree with the growth of BIM. Because effort is recyclable in BIM, we can actually have detail views in Schematic Design that have merit. Standardized views can be moved from place to place within a template project, and only the annotations need be moved in order to create "Progress Drawings" at various phases of the project.

All in all, It's my belief that the concept of keynoting really only pertains to the drawings, which are ultimately viewed by the Contractor. With my background in General Contracting, I truly think that requiring them to reference information in a specification in order to get the BASIC information that they need to do their job to me is just plain LAZY! Drawings should follow the same CSI principles as Specifications (Clear, Concise, Complete, Correct) and the fifth C; Consistent. Keynoting makes incomplete drawings, as there is no single unified keynote structure, and there is no practical way to take into consideration EVERY possible component within a given specification section. It took over 1200 different BIM materials for a metal framing manufacturer to represent their Metal Stud offerings which consider dimension, yield strength, web depth and spacing.

Drawings are created before specifications, and BIM is the root of both. As information goes into the Model, it becomes a function of the drawing FIRST, and the attributed information becomes a tabular specification which can be used to develop a text based document. It is actually very simple (and very beneficial) to add the attributed information into the individual materials and components, as BIM provides not only the ability to TOGGLE between keynote, and annotation globally, but to actually concatenate attributes to create an accurate Callout.

The syntax for annotating a material goes something like this:

• Keynote Only: [MF Number]
  
• Keynote Only: [07 54 23]
  

• PP: [MF Number]_[Component] [Type]
  
• PP: [07 00 00]_[Roof] [as Noted in the Contract Documents]
  
• PP: [07 00 00_Roof as Noted in the Contract Documents]
  

• SD: [MF Number]_[Component] [Type] – [Material]
  
• SD: [07 50 00]_[Roof] [Membrane] – [As Noted in the Contract Documents]
  
• SD: [07 50 00_Roof Membrane – As Noted in the Contract Documents]
  

• DD: [MF Number]_ [Component] [Type] – [Material]
  
• DD: [07 54 00]_[Roof] [Membrane] – [Thermoplastic]
  
• DD: [07 54 00_Roof Membrane - Thermoplastic – As Noted in the Contract Documents]

• CD: [MF Number]_ [Component] [Type] – [Thickness] [Material] – [Color]
  
• CD: [07 54 23]_[Roof] [Membrane] – [.060] [TPO] – [Tan]
  
• CD: [07 54 23_Roof Membrane –.060 TPO – Tan]

• Post Bid: [Manufacturer]_ [Trade Name] – [Thickness] [Material][Type] – [Color]
  
• Post Bid: [GAF] [EverGuard] [.060] [TPO] [Membrane] – [Tan]
  
• Post Bid: [GAF EverGuard .060 TPO Membrane – Tan]
  

Because of this structure, I use ONLY the 6 digits of MasterFormat, with no following enumeration that corresponds to a construction or specific material. A keynote is great if a machine needs to read it, but we are not machines. We are humans who want to see the information that we need, not have to follow a path in order to reference a different document. The BIM database already does this for us, and by mapping the information in such a way that it is no additional effort to create the more detailed information, there is no reason NOT to use full text callouts. We are all collaborating on a project, and should consider the needs of the individuals who are actually using our deliverables.

I do understand that you can only put so much information on an E sized plot, however, with the on screen digital world right in front of us, changing scale, and creating additional sheets which apply to specific trades at a more detailed scale is a simple Duplicate w/ Detailing Command.

All of this information is searchable within the model, and allows for analysis, so by adding a few attributes to each material, an annotation is automatically created, and can be globally updated based on the status of the project, or who needs the information. Whether or not keynoting is relevant and useful is no longer an issue in my estimation; That ship has sailed already. I think the idea is how detailed the annotations need to be in order to suit the needs of EVERY member of the project. If BIM can automate the annotation and keynoting process by leveraging attributes from within the material, assembly or component, the bigger issue is the accepted taxonomy and structure for the information which needs to be managed.

No More Shared Parameter Confusion - Omniclass Table 49

There is a format in existence called Omniclass, that has been around for years without a practical purpose. It is a series of tables which organize information the same way MasterFormat™ does. In fact, MasterFormat™ is based on one of the tables in the series. For those using Revit 201 or newer, you may have seen references to Omniclass Table 23 embedded in the families. This is the table that organizes products into logical categories. I'm not going to go into great depth in this post on the value of Omniclass to the success of BIM, but I will say that it is THE most effective way to organize and homogenize all of the data that you are accumulating.

During its redevelopment and update (Which is still ongoing), a few active CSI volunteers and I, were responsible for updating Omniclass Table 49 "Properties". This table is a series of attribute names that are slated to become the standard naming convention or taxonomy for attributed data within Building Information Models. Upon finishing the update to the table, it occurred to me that the best way to implement this into practice was to create a Revit Shared Parameter File. I just finished the effort moments ago with tremendous success, as my custom Shared parameter file works like a charm.

A beautiful aspect of this file is that I customized the GUIDs (Globally Unique Identifiers) so that they align perfectly with the exact location of a parameter. Just as you drill in from Division to section to Part to Article using the CSI formats, This allows me to actually create similar Shared parameter files based on specific needs (one for SPie, one for Windows, one for Doors, one for Wall, one for HVAC, etc), so you can pick and choose which SP file you use without sacrificing data organization. One irritating point about shared parameters is that even if you name the parameters identically, they don't schedule together unless they are form the same shared parameter file. This is based on the GUIDs being different. if I enumerate them and keep the data organized. it should all work out nicely.

If you're interested in, or know someone who is interested in taking this Industry standardized 923 parameter Revit SP file for a test drive, reach out to me and I'll send you a Beta version.

BIM Content and File Size - 6 Points to Making a Faster Family

When Dealing with BIM Content, size is an essential element of its success or failure. While most look only at the overall size of the file, there is another type of size in this respect; computational size, or how quickly the software can load, process, and refresh the file. I have developed components that are 250KB that are slow as molasses on the load, and others that are 1.5MB and lightning fast on the refresh. Always consider BOTH aspects when determining which components you put in your project. Unfortunately, there is no way to quickly quantify and qualify what the computational size of a models is, there are a few ways to determine whether or not a piece of content will be fast or slow.

• Family Types vs. Type Catalogs - Each family type in a component requires Revit to churn through the regeneration process every time its loaded, changed, accessed or reloaded. I try to limit the number of family types that are pre-loaded into a model to five. Any more than that, the model bogs down trying to refresh. Type catalogs are the most appropriate solution as they make the models fast on the load/reload, give the user the ability to sort and filter through choices based on data in the model, and also allow ONLY the types that are needed to be placed in the model. This is a tremendous help when trying to stay organized within your model.
  
• Calculations - While helpful, they can slow down the speed of the model by forcing Revit to constantly recalculate when the value is more efficiently placed in a family type or type catalog. Calculations have their place though. Instance parameters are perfect for calculations. I wrote a calculation that returns if and in which zones a window will meet ENERGYSTAR based on the U Factor and Solar Heat Gain Coefficient that is inserted by the user. Since those values are determined based on which glass is used, it is better suited to allow the user to insert the values, else the type catalog can become unbearably large.
  
• Void Geometry - I'm not going to say not to use void geometry, but I will say to use it sparingly. for whatever reason, it seems that voids slow down BIM content. Avoid creating hollow solids where the inside of a component is not visible (Water is not really going flow though that pipe), and join multiple solids where possible.
  
• Really Small Polygons - This applies to both solid and void geometry; don't bother with the 1/16" just and jogs in the profile of a window frame. While this type of detail is great on Engineering drawings, nobody is going to export the family file for machining.
  

  Rule of Thumb: If you can't see it from 10 feet away in its installed position, think carefully about its relevance.
  

• Arrays - Again, use them, but use them sparingly. Arrays are a computational HOG. In many cases there is no way around them, but use simpler geometry, and array nested families instead of solids where practical.
  
• Nesting a Nested Nest - I am a true believer in the use of nested families, especially shared nested families. The streamline everything and allow you to create some powerful tools, but that is another blog entry. It's important not to nest items too deeply though. If you nest twice, three times or more, each step requires computation. If you nest everything into the host and align reference planes accordingly, you'll end up with a faster model with less fat, not to mention less chance of errors in forgetting to link parameters together.
  

Generally speaking, I like to keep content to roughly 600KB with a load/refresh of less than 5-10 seconds, unless its a very detailed component that's only being used once (Like a entire ice hockey rink in one family). There is more to content size than the number of Kilobytes it takes up. How quickly it computes is just as important as how big it is in terms of the file size. Many of these points speak to both file size and computational speed, so go forth and find that delicate balance between size and speed. It's a fine line, but it's important that we walk it.

BIM and Roof Systems

In developing a BIM roof system, it is important to understand that the actual materials are what determine the performance and construction of the overall roof. The type of roof covering used is considered based on not just aesthetics, but roof slope and local weather conditions. The secondary roofing materials are determined based on their individual merits as well; substrates are based on the building’s overall design, structural properties and locale; a vapor barrier is selected when or if certain moisture vapor properties merit its need; insulations carry specific R-Values important to the energy performance and code compliance of a building; the roof system attachment method is typically based on requirements of local codes. It is not necessary to understand how and why to use the specific materials when developing a BIM roof object. Realize though that the roof system is not just a slab that stops water from coming in. The appearance of the materials used in the roof system will determine how the details turn out. Use an appropriate surface pattern to convey the basic appearance of the upper most layer of the roof. Layers embedded inside of the roof will never be visible, and have little or no value to the model’s success. Cut patterns assign a symbolic appearance to various types of materials. The Uniform Drawing Standard (UDS) and National CAD Standard (NCS) have uniform symbolic patterns assigned to various materials. Using industry accepted patterns allows existing technology to be implemented into BIM technology without the need for reinventing a perfectly useable process. Each material has the ability to carry its own set of performance values which can be leveraged for model analysis and quantity estimation. A model calculates the length, area, and volume of a roof or roof material, but does not consider the unit by which the material is sold (Roll, Pail, Gallon, Cartridge, etc.) Where unit coverage rates are specified for given materials, an accurate estimate of the number of necessary units can be derived from the model, considerably decreasing the amount of time required to estimate a project. Later in this chapter, we will discuss in more depth the types of calculations that are possible from roof materials which carry a substantial amount of information. Roof System Components There are five main components that make up the basis of design for a roof system. In some cases others may be added and some omitted, but the primary components that should be considered for roof systems will allow others to be built from them and easily reused. § Substrate - The roof substrate is the structural component associated with the roof system. Functionally, it is the deck on which the thermal and waterproofing products sit. There are several types of substrates which may be used, the most common being Wood, Concrete and Steel. Unless the framing members are placed individually as described in chapter 28, roof systems should contain a material layer for the structural framing in order to consider the overall thickness for potential clash detection analysis.

*While the roof deck is arguably not a part of the roof system, it is not appropriate or effective to create one roof for the structure and deck and another roof above for the waterproofing system. It creates a conflict when placing components on the roof that are designed to cut a hole in the roof on placement.

§ Air/Vapor Barrier - Vapor barriers are very thin membranes typically placed between the substrate and the insulation. Even though the thickness is negligible, it is important to represent them in the model with a thickness appropriate enough to graphically display the material in a section view. Without giving the air/vapor barrier a thickness, providing call-outs or annotations of the material in detail section views is made more difficult.

§ Thermal Barrier - Roof insulation provides the thermal barrier between the building and the outside world. Just as a hat protects your head, since hot air rises, insulating a roof keeps the building’s heat from escaping. In some cases the insulation may be placed below the roof deck, and in other cases, it may be placed above the deck. In either case, its thickness should be easily adjustable and carry its R-Value in order to determine qualify the appropriate thermal protection used in a project. In addition to thermal properties, roof insulation may also provide slope, so the ability to taper the insulation independent from the roof structure is important.

§ Waterproofing Material - Shingles, membranes, metal and sprayed elastomeric coatings are all types of waterproofing. In most cases, this is the uppermost layer of the roof, and should carry some type of surface pattern to differentiate it from other roof types within the model view. Often, the roof covering is selected based on its appearance, and since there are so many options for roof coverings, it is important to have a good sample image swatch available for rendering the roof’s final appearance.

§ Roof System Attachment - Regardless of the type of roof, it needs to be attached in one fashion or another. Because it can affect how the roof performs or whether it meets the local building code’s requirements, it is important to add it as a layer in the roof system. Having it in the roof system as a layer allows the attachment method to be quickly called-out or switched if necessary.

The Ever-Evolving Specification

BIM has two main parts to it; graphics and information. It is the responsibility of the Architect to ensure the graphics are correct and appropriate for construction, and the role of the specifier to ensure the project information is correct on the behalf of the Architect. It seems only natural then to place the responsibility of BIM information management in the hands of the specifier. Over the years, the tools of the specifier have improved. Beginning with the pen, and moving to the typewriter, followed by the word processor. Once again, the specifier is experiencing a process improvement which inevitably leads them to the database.
Databases house the salient parts of a specification for easy and repetitive retrieval while maintaining the consistency of the final delivered specification. The “Office Master” is the most common example of this. Most specifiers and architects offices have guide specifications which are used over and over in order to simplify the task of specification writing this is a rudimentary, but effective method of making a database of project information for reuse. The shortcoming of the office master is that it needs constant maintenance as products, building codes and design requirements change over the years.

AIA MasterSpec, ARCAT SpecWizard and other similar online “guide specification” libraries allow for the simplified creation of project manuals on an individual basis, by providing ready-to-use formatted specifications which can be easily implemented into projects based on either required performance values, industry standards or actual products. Which type to use is dependent on the project delivery method used on a given project. These online libraries are giving way to the concept of integrating the information from a BIM model with the project manual by providing a single database where product information is stored for multiple products. Where a specification and BIM object are sourced from the same location, and driven by the same database, there is a level of consistency not easily attainable by other means.
The possibility exists to create a short-form or outline specification, a long form specification and a BIM component all using the same series of dropdowns. Rather than a printed document being the only deliverable of a specifier, consider just how critical the responsibility of selecting the most appropriate component for a given project is. If the ability to review and select products and systems for a project extended to formatting a BIM component based on the required performance and appearance characteristics, the final project documentation and specification would be simplified considerably.

The concept of a specification is to provide documentation of specific elements of a project. It expands upon what is selected to explain why it is used. If you think of a specification in terms of what it is designed to do, much of it is broken into pairs of Attribute and Value, where the attribute is the “what” and the value is the “why”. This is the baseline concept for creating a specification from a database. Some examples of attribute and value pairs are:

§ Color: Green
§ Length: 12 inches
§ R-Value: 19
§ Tensile Strength: 1000 ksi
§ Warranty: Ten (10) Years

While not all aspects of a specification can be broken into these pairs, it can encompass most if not all of the critical aspects of product selection and implementation. The balance of the specification can be formatted through development of a pre-formatted guide specification which would act as a form which the data would be filled into.

BIM and Specifiers

So it's been a busy spring, and between AIA, CSI and other speaking engagements I was roped into (happily I will add) I haven't had time to post. From these shows and engagements, I have taken away one primary point... BIM is experiencing the largest growth that it's seen to date. Everyone is at least looking at BIM, even if they are not ready to approach it. Architects, engineers and manufacturers are embracing it more and more every day, and surprisingly enough, specifiers are as well.

Two years ago, many specifiers viewed BIM as the technology that will put them out of business. Now, it seems, the focus has shifted on how BIM can improve their workflow and make them a more necessary component of a project. I will point out that there is a clear difference between a "Spec Writer" and a "Specifier". It's not a semantic difference. A Spec Writer is really more of an editor. With guide specifications and master specifications that automate much of the authoring of a project manual, the writing of specifications (Fingers to keys) has actually become the labor aspect of the specifier's role, which is often sourced out to someone else. The Specifier is the individual who is responsible for and qualified to make educated decisions on which product is to be used on a given project, in a given location under given circumstrances. In short, a spec writer can tell you what product is selected; the specifier can tell you why it was chosen.

Now what does this all mean to BIM? BIM is a technology that is driven by information, not by graphics, so the need for more robust information is going to become essential as more people adopt it into their practice. I am finding that there is a glorious lack of individuals with ehough knowledge of products that are involved with the development and creation of BIM families, elements, objects and systems, so the responsibility lies between the manufacturer (Who doesn't understand revit) and the A/E who doesn't have the time to research the information.

Specifiers have a great opportunity to step to the plate and embrace this opening, becoming the keeper of all things technical and informational within a BIM project. I truly believe that it is the right place for them to be, and with enough individuals involved, can start a movement which will bring the specifier's role to the forefront of BIM projects.

conTENT with CONtent?

Now that BIM has stared to become widely accepted, and viewed as a necessary component of the AEC communities, the responsibility of providing product models is starting to lie in the hands of the manufacturer. Just as a manufacturer must provide Specs and CADs today in order to be competitive, tomorrow holds the requirement of BIM models. So what does that mean, "BIM Models". Some providers may lead you to believe that simple images are all that you need, but from an expert in this field, the requirements of BIM are "expanding exponentially". Thus far, the "i" in BIM is largely unexplored by content providers and certainly treated as lower case and subordinate to the "M".

The bar has been raised by those who create "Super Families" that are not only high quality graphics without sacrificing modeling speed, but contain appropriate data and family nesting to allow for high powered scheduling and maintenance study and analysis. In my humble opinion, without appropriate descriptions, proper attributed data and takeoff abilities of a BIM product model, it's about as useful as socks on a rooster... while entertaining to watch, actually makes more work for everyone.

When looking for a content provider or creating your own, there are several things to consider. Below is what I believe to be the bare minimum tht should be contained within a BIM Object.


Graphics...

• Lipstick on a pig... Graphics need to be accurate and consistent with the intent of the model without slowing down the model's performance. If you put a $5,000 paint job on a Yugo, it still will only do 55, and if Kwik-Lube tunes your Ferrari.... well, you see where I'm going here. This delecate balance needs to be managed properly. Fixtures and fittings tend to be very graphic in nature with a lot of complex curves and angles. This level of detail detail can slow down the model if not done with some care.
• Size matters... Dimensions need to be accurate enough to consider tolerances and clash detection. Most electrical devices are created considering only the visual aspect and (Hopefully) the MEP connector, BUT, an electrical device has a box embedded in a wall thats about 2"x3"x4". Adding a simple solid behind a wall plate will allow that device to be considered a clash when a 3" DWV runs right over it inside of a wall.
• NO IMPORTS!!! - And no, I'm not talking about outsourcing graphics to Asia or South America... Imported CAD files converted into BIM files are large, slow and cannot be modified. Sizes cannot be modified, and proper rendering of these files is not for the novice or impatient.

Data...

• It's not you, it's me... Data needs to consider not only those persons placing the information in the model, but those using the model later. In addition to baseline information about the identity of a product, performance aspects are used for energy and structural analysis; product lifespan is used for future budgeting and sustainablility analysis.
• Fill in the blanks... This is an enormous pet peeve of mine that I see all the time. The description parameter is used for callouts. Materials or objects that have no description or one thet's too long or too short have a worthless callout. This is really irritating to the user when they need to go back and add this during the detailing phase.
• Tell 'em what they've won, Link - Links to useful information like code compliance, specs, product data, installation procedures and sales and marketing can really simplify the research aspect of product selection, by creating a singular point of reference to search from. NOTE - If the manufacturer cannot ensure that URLs won't change, data MUST be linked through a library that will.

Family Nesting...

• More than a simplified processes... Nesting families allows more than resueable components like door slabs and window sashes. It allows for option selection and more accurate scheduling and data management, especially for the FM folks.
• What are my options?... Nesting families allows multiple components of the same type to be selected as options. Doors may have hundreds of slab (or leaf) styles, but all of them come in the same sizes. The slab becomes a "Nested" component that can be "Swapped Out" by the click of a dropdown.
• Mother always told me to share... Shared nested families allow scheduling to be made more accurate and allow for mainenance components to be their own entity with their own attributes. Lets take a light fixture... The Housing of a Recessed light is a durable product with a lifespan of 20 years. the ballast and bulb are 2 components that are both components that will not only require replacement, but have options to select from. Nesting the ballast and bulb within the light fixture allows the ballast and bulb to have independant lifespans and installation dates for every light fixture installed. The FM team can see when every bulb and ballast was installed, and when they'll need to consider replacements.

Parametrics...

• No do-overs... This one's a no brainer, but I always find myself needing to say it... If I can't modify dimensions without going into the graphics, there is something wrong. Appropriate dimensions need to be made parametric so when updates need to be made, it's not back at the drawing board.
• More than dimensions and materials... can be parametric. Equations can allow results based on other attributes. Calculations that determine if and where in the country a window meets ENERGYSTAR are created based solely on the input of a U-Factor and Solar Heat Gain.

I hope this has been an informative post and can give some insight as to what you should expect... no, demand... from your content provider. Content is being treated as something like BIMs read-headed stepchild, but the bar is raising on the level of detail required in the model. The needs of the architect are beginning to demand that content developers step up to the plate and take their BIM content seriously. The main difference between man and other mammals is the opposable thumb, and most of us choose to use it. The difference between CAD and BIM is the data... Let's use it... Don't settle for less, and don't just be conTENT with CONtent.

The Devil is in the Details

So you have this great BIM Project that has solid graphics, a respectable level of data and attributes, and all-in-all has saved you time in design. What about the drawing sheets? How much detailing work are you doing manually, and how many of your termination, intersection and other construction details are from the ACTUAL MODEL? Seems like dumping dwgs of manufacturer details onto a drawing sheet is a common practice, rather than creating the sections and drawing in the linework. Why is this? Likely it's because of the lack of detailing that is done in Families and Objects, as well as the lack of attention to materials, which ultimately drive the callouts.

The Details...

This is another issue for my style guide. Detailing associated with families should be a part of the family, so that when it is placed within a wall, the linework in section views will show up appropriately. This in itself has its pitfalls and limitations. The window goes into a wall, and has no knowledge of the type of wall, so how can the detailing be done? There are detail families which can be imported into the project file, and plunked down on the Drawing Sheets which are a good idea, since the detailing really is only important on the drawings not in the model itself... Right???... Not so fast. Yes, the detailing is only viewed on drawing sheets, but the detail should be dependant of the window, not of the wall, since the window is inserted in the wall, the wall is not placed around the window. What happens if someone wants to make a new wall section at a window... You'd need to drop in a new detail family with it as well. An instance parameter of Type - Detail Family could be nested to allow different wall type connections (Wood, Metal Concrete, CMU) to be swapped out on the fly.
I'd love to create hosted families that are more intelligent, like opening family attributes which apply to all openings of Host Type (Wall, Floor, Ceiling, Roof), so if you punch a hole in a roof, it will intuitively place base flashings, or flashing tape associated with a window. These can all be created as "Families of Type" or "Material" Instance Parameters to allow products to be swapped out without swapping out the entire family.

For instance, a window manufacturer requires that Flashing Tape be installed around their windows. If a Material Parameter named "Flashing Tape" is created within the Window Family, you can swap out the type of material by updating the material name, or importing the material from a manufacturer of Flashing tape. This works well, gets the window specified, its installation specified, and opens the door for other manufacturers to be specified alongside the window. Taking it a step further, instead of a material parameter, a Family of Type Parameter can be added to insert an entire piece of graphics and layer of information which applies to the flashing tape. Basically, create a detail family for the Flashing tape, but add the attributes and values for the product itself. Let the detail family carry information as well as graphics for a product. This allows not only a Material to be specified alongside a window, but a Product to be specified. If a competitive product wants to be specified as an equivalent, their detail family can be loaded in the window family, and voila... new options to choose from.

Now this Brings me to Materials...

Materials are the Readheaded stepchild of BIM, and it irritates me to no end. Materials are the common ground of everything built, and every material has it's specific properties that make it what it is... nobody specified "Gypsum" or "Wood". They'll specify [5/8" Type X Gypsum Wallboard meeting or exceeding ASTM Somethingorother] or [3/4" FAS American Cherry S4S] even the finish on the wood or the paint on the gypsum needs to be called out, because Someone makes that product and there are more than one set of performace characteristics for a given product. That's where inferior and superior products come from. a BIM can't calculate the VOC levels of paint if they're not listed in the material... why would anyone want the BIM to calculate VOC's of Paint??? Because it can!

Representitive Modeling of Families

OK, so everyone thinks about BIM a little differently, but at the end of the day we have the same problems implementing... Managing Data and Creating Graphics... I've decided to develop a style guide to tackle the graphics aspect of things to try to give a sense of how much is too much, and the unnecessary creation of graphics.

Lets look at a company that makes plumbing fixtures. They make 400 tubs, 600 faucets, 125 toilets, 250 sinks and in total has 1500 products which they are trying to market. A difficult proposition if you as me... Is it necessary for them to spend in the neighborhood of $300,000 just to have their graphics created ($200 each), without the addition of product data? This content developer says no. Now I am sure that there could be some product redundancies that can be taken into consideration and handled with parametrics, but this is plumbing fixtures... every one is styled a little bit differently, so for argument's sake lets say there are 1000 unique products which need to be modeled... Still, $200,000.

Now that I've told you the problem... What's the solution?

Representative modeling... This is a backbone concept behind my BIM implementation strategy and has worked well for clients that are looking to get specified rather than have a pretty picture available. The products can be broken into categories... Tubs, Sinks, Toilets, Faucets, Shower Controls, etc. For Arguments sake, let's say there are 10 categories of plumbing fixtures. Within those categories, there are types of fixtures, such as Single control and Two control faucets, Freestanding, corner and alcove tubs, wall mount and tub mount tub controls, 1 piece, 2 piece, wall mount, elongated, and urinal toilets, and it goes on, so again, for argument's sake, lets say there are 10 types for each of 10 categories. For $20,000 his creates a total of 100 unique graphic models which have the ability to represent the INTENT of the model, rather than the appearance of it, which in the big picture of BIM, is far more important. so for a fraction of the cost of modeling all 1000 products, you can model 100 of them, and allow the data behind the models to drive the other 900 just by adding a "Version" or "Instance" of the graphic.

If you pay to have appropriate product data and information added, and every instance of the products taken into consideration, you might spend another $400 each, but done properly by a skilled content developer, it will perform as though it were the actual unit, noting the finish, construction, flow rate, MEP connectors, connection sizes and types, hole spread, and any other pertinent information abut that faucet.

The Downside...

OK, you just saved $140,000 on BIM modeling... At what expense? Well, when the architect renders the BIM for graphic purposes, the faucet won't LOOK exactly like the one they specified... Not important I say!!! The rendering ability of the software is not good enough to give you enough detail on a component as ornate as a faucet anyway, so the best way to see what it will look like is at the mock up in the Plumbing Showroom.

The Conclusion...

Developing Graphics for the sole purpose of appearance and rendering is a waste of money in the BIM market. generally, at that level of detail, architects are interested in the product data, not how it renders inside of the model at a 6"=1' scale, so save your money, and spend it on developing the data about products that is so desperately needed.

Data: The "I" in BIM

Manufacturers that are looking to develop BIM programs need to develop around what the user wants and needs, NOT what the “BIM Expert” tells them that they should do. The area of BIM data is where this becomes most critical. What (if any) data do you want to see in your BIM objects and systems? Do you only use BIM for conceptual modeling and graphics? Are you taking advantage of the product and performance data that can be added into the model?

No architect in their right mind would WANT to add the performance information into their product models themselves. Libraries like ARCAT.com are creating generic BIM product and system models with performance, lifecycle and usage data associated with the product that can be downloaded for free. While this is not the perfect substitute for manufacturer specific (proprietary) content, the manufacturers are catching wind of BIM and starting to not only offer BIM models, but put data into their models that designers can use. This is where the problem arises…

What Info Do You Put In A BIM Model????

BIM platforms are basically giant databases of infinite size which can handle as much data as one could offer, so why not add EVERYTHING into the model? The answer is “Organization”. If you have 500 parameters inside a family, you’ll have a hard time finding them when you need to actually use them. Yes, there are ways around this, like hidden shared parameters, but then you don’t even know the data is there unless you schedule it out or run a database dump. If BIM users let the manufacturers know what they need (and the manufacturers are listening) we may be able to come up with the level of information that they everyone can be comfortable with.

Three main things to consider when thinking about DATA…
- Who is using it?
- What is it being used for?
- How is it being looked at?
- Should data be in the model or linked to the model?

Who is using it?
Now the data that a specifier needs is different from that of the Designer and that is also different than that of the Contractor, Facility Manager, Owner… You get the idea. Development of data sets that are well organized, dynamic and most importantly, standardized, is crucial.

What is it being used for?
Data that is necessary for HVAC components differs from lighting fixtures, which differ from structural components which differ from architectural components. Knowing what is important about each product category can help determine what data should be held in the model.

How is it being looked at?
Is the data being exported to a database? Will the data be on a spreadsheet? Most projects have some sort of schedule associated with it, so what data will benefit that schedule? Setting up the data so it can work with export functions as well as be easily manipulated in the model and added to drawing sheets and schedules must be considered.

Should data be in the model or linked to the model?
Where the data resides is a factor of the last three questions… Data can be held in the model in the form of text, numbers, units, or other values, OR it can be linked back to a website, where it can be viewed. There are pros and cons to both methods.

Data in the model: Data that is in the model can be placed in schedules, tagged, exported, and modified. If, for instance, you need to have performance data about your windows on the window schedule, it makes sense to have it in the model.

Linked Data: If there is a substantial amount of information involved, you can bloat a BIM model very quickly. Properties windows can quickly get so large that it becomes very difficult to find anything. This is where linking back to a website can be very handy. Links to Product Data, MSDS, Specs, and other resources can prove invaluable to various parties involved with the BIM model.

Summary:
I’m calling this a summary, because I haven’t yet reached a conclusion as to how to organize data yet. The BIM technology just isn’t there for how I’d LIKE to do it, so I think throwing ideas out for comment might move us at least 1 step in the right direction…
Data is the heart of BIM. Without it, BIM is little more than 3D CAD with a few bells and whistles. If one party could insert a component into the model that contains links to data that apply to everyone else in the Integrated Project, no further research about products would need to be done. Think about what a single location where design considerations, installation instructions, maintenance information, handling guidelines, and lifecycle and warranty information were available. This could potentially turn a BIM model into a “Digital Owners Manual”.

The Specifier's Role in BIM

Since BIM is very much in its infancy, most architects are only scratching the surface of BIM. From what I have seen, it is primarily being used as a 3D modeling tool which speeds up the design process, but the data that can be captured and manipulated is not being used. Much of this is due to a disconnection between BIM and the specifier. Currently, the specifier holds no role in the development of a BIM model, and is “Left Out” of any Integrated Project Coordination which may occur. My goal is to bring that specifier into the BIM model, allow them to specify systems and products for the project and allow that data that is missed within the project to be harnessed BY the specifier FOR the designers, contractors, and owners. Essentially, the specifier has the opportunity to take on an additional role which will benefit not just the design professionals, but the Contractors, Facility Managers and Owners.

Currently, during the design process, most BIM projects are developed with generic products and systems rather than manufacturer specific components which carry data about a individual product’s performance, lifecycle, impact and efficiency. It is too cost and time prohibitive to require a Design Professional to update an entire project with manufacturer specific components after the design has been completed. If the specifier has the opportunity to specify through the BIM model in real time, Products and systems can be specified earlier in the design phase and could potentially streamline the bidding process by setting available and visible performance standards that bidders can access in real time.

First and foremost, the specifier needs to understand what BIM means to the built environment and the benefits BIM brings to their business and current workflow. Without understanding these basic concepts, there is no real reason to embrace this change and make the leap, especially for those who are later in their careers.