Analysis–The Implied BIM Use

One of the promises of BIM is the notion that Analysis comes pretty easily (cheaply) after you have a model.  For certain type of information this is definitely true.  Net Room/Space Area (Not Gross), Numbers of unique instances of items, Very basic 3D Coordination i.e. (yes things are indeed clashing).

While there are a few wins the vast majority of analysis you might want to do on a building is much harder to achieve.  The difficulty comes from software capabilities, standard work processes,  and other issues.  The biggest failing I see with the industry as a whole is the lack of Systems Thinking.  I want to build a virtual building and then ask it questions.  Right now there are a lot of uni-task features in software.

Just as a quick exercise here is the list of the types of analysis that came across my desk last week.   To be clear these are not unachievable, but given the current state of software they are far from automatic.

• Gross Envelope Area to floor area of early building massing divided into Parapet, Below grade and other for a 900,000 sf new building
• Gross/Net by department of a 300,000 sf new building
• Quality Assurance across 3 different BIM based quantity takeoffs done by 3 different parties
• Daylight and Electric Light analysis from BIM instead of purpose built model
• Detailed program to actual analysis of hospital projects. “The rooms is supposed to have a ventilated door…is the door in the model ventilated?”
• Across that last X number of hospital projects what is the average Net/Gross for Clinical spaces..by what measure.
• How to perform GIS like Network analysis of an Urban Design project for metrics such as walkability, connectedness, but working in a design software.
• Then of course we have the eternal frustration of BIM to BEM (Building Energy Modeling)

So what is the solution?  Should we stop trying?  The answer is 1. Complicated and 2. No  

For me the challenge opportunity and frustration is that we have so far to go.  My point of view is that the current AEC market needs an outsider.  Not a new software company but a totally new point of view.   Their goal can’t be to sell more software, but should be the realization that a design = data and data has a value and a use.

I mean that in the most abstract sense possible. I could mean anything from the simplistic QTO type discussion, but could mean something as soft as…”How comfortable/productive will or could a person sitting in this particular seat be?'”  

This sort of question has 10s if not hundreds of interconnected relationships and would require a complete rethink of software based analysis, but imagine the day when this question could be answered. 

What AECO needs a BIG DATA provocateur, not “BIG BIM” but “BIG SIM”…maybe even  BIG BIM SIM…BBS .has a ring to it …gotta’ love acronyms made of other acronyms.

That’s my current view of the world on this Sunday….

Look forward to your thoughts and comments.

(Building) Programming

 

Finally…..sorry for the delay.

So Programming.  Depending on your point of view that might mean anything from deciding how big a single space in a building should be to doing client interviews or researching clinical treatment to determine how to best take advantage of the latest and greatest current and future technology.

That being said “Programming” as a BIM use is a starter term to collect all of these ideas under one umbrella.  Internally we have started to understand that there are several examples like this, one BIM use that can have several types of implementations. 3D Coordination is another good example.

 

As of now we have a  soup of terms when we talk about Programming

We have;

• Integrated Program Management – The glossy words term to talk about managing the program in an integrated way
• Programming (Project Validation) – This is really our focus when we are talking about the most basic use of BIM and is part of our BIM Certified objectives.  Using the model to validate the program

Finally we have the other terms that we have began to think about that start to address and define the other kinds of programming.  I don’t “Program” for a living so right now these are mostly my take on the process and not necessarily what others think of what they are doing.

• Building Program – New from Strategy
• Building Program – New from Standards/IP and or  Experience
• Site, Master Plan – Airport, Campus
• Program Design – Layout to Program
• Test fitting – “This is what we can get”
• others…

One last thing I will talk about before getting into the tools is the connection between the broad set of tasks and BIM.  The simple answers is that some have stronger connections than others.  The point I’ll make on this is if a BIM is truly a virtual building then you just have to think a little more broadly to see how these other tasks could be informed by a model.

 

Why dRofus?

As I mentioned our current focus is on Programming (Program Validation).  If you think about basic services that Architects provide (In the US at least) this is simply an extension of a tradition process.  It’s really just using a tool to hold the program and compare that with the model.  At its most basic level it’s simply checking the net planned or programmed area against the net design area.

It took us a long time to decide on the best tool for us to use but at long last we chose to use a Norwegian tool called dRofus.

James Vandezande did a little write up about our resent trip to Norway during which time we visited them and attended a few other events here.

For the single task of checking a room’s program area/ design area dRofus could be seen as overkill.  But when you think about the big picture of collecting, tracking and reporting on requirements for complex projects we realized that we needed a tool that;

• Is robust and can handle huge projects
• Fosters collaboration between the client/design team and contractor via the internet
• Has a strong Revit connection

I put together this graphic that began to show the capabilities and hint at whether the underlying technology was easy or difficult to develop. From the existing tools that were on the market in 2009/2010 and even still today clearly the Web and collaboration features are the hardest for any tool to develop.  As dRofus already had them it was the right way to go.

The underlying curve hence forth was called the “Schleusner Curve” by our CEO who has the MacLeamy curve to his name…I must say I’m most likely the only person that remembers that, as Schleusner is much to hard to say.

 

dRofus Features

dRofus is loaded with features, so many that we are still learning how to best take advantage of them. A few are still being translated to work with non-Norweigan building coding systems others are traditionally outside our scope, but that’s not to say we aren’t planning on getting value from them

This main list is as follows;

• Condition survey (Norway)
• Punch-lists system (Norway)
• Admin system
• Functional programming
• Rooms and Room Data Sheets
• FF&E planning and costs
• Finishes
• Procurement & delivery
• Technical database (TIDA) (Norway/Scandinavia)
• Revit Connection
• IFC Connection
• Direct Database Connection
• Existing Equipment
• Room Validation against FFE

From the list you can see there are a huge number of tools and features. I won’t go into them in detail in this post but the more and more we use it, the more we find and get the benefit from. 

I’m going to stop here for now.  I did an early presentation on dRofus and programming at the NYC RUG in August that was recorded and is hosted here.

In some ways this topic is not as sexy as other model based processes, but as I talk about it in future posts I hope you’ll begin to see the possibilities and benefits of the BIM use called Programming.

Is Collaboration a BIM Use?

 

With the public visibility of  of VEO, the market for Cloud Sharing and Visualization BIM tools has grown by one.  If you look at the market today there are really three main competitors in this space.  Horizontal Systems (Autodesk), VEO (M-SIX) an another that’s not quite visible yet but also by a major player.

 

If you lump on the Rendering group like, Autodesk Cloud Rendering, Vimtrek, and others you end up with a smorgasbord of  socialized BIM tools.

One of the questions that we have been struggling with internally is what is the cloud worth.  I don’t think anyone can argue that visibility of information and access aren't good things, but is there a difference between daily web meetings with models and a cloud tool. 

From a technology standpoint there is clearly a difference.  We  are also pretty certain that the cloud will provide instant benefits when it comes to having nearly immediate access to files and the other offerings each of these tools uniquely provides.

So what's missing?

 

I’ve been thinking about this one for a while and I really think its the model being the center of collaboration.  More specifically its currently not. 

The best example that comes to mind is the forever promised link between specifications and models. The technology to make the link exists, but I have yet to see and or hear this conversation….  Architect #1 “What glass did we spec for the South East Façade?”  Architect 2# “I don’t know, lets go check the model/Model Database.” –

So why doesn’t this happen?

1. Model Ubiquity:  Most, if not all, BIM Authoring software's are way to slow to deliver a simple and fast model viewing experience conversely the fast tools usually require you to manually export from the authoring tool before you have a fast experience.  Cloud based tools that help automate this process should go a long way to solve this issue.

2. Model Data Connect:

Codes!  Is that the best we can do?  I’m standing on an island when I say it, but for the most part I think coding systems are a hold over from a time before computers. Of my opinions this is the one that will take the longest to explain and the longest to defend so I will leave it at this.  Unique/Type ID’s are needed, and they could be human readable, but I don’t think people should interact with them.

Along with codes there are very few tools that care about connecting documents and data to objects in the model during the design.  You often see it as a deliverable, but not part of the design process.  This one is less cloud, more software and process design, but new thinking to the problem will hopefully bring some new ways of thinking about the issues.

3. getting sleepy…more to come

I’ll keep looking into this one, but I think the notion of the model being the center of collaboration is going to be the biggest challenge for the whole industry.

Greg