Conquering BIM: never do just one thing

Part One: Never do just one thing

In my first post about Project Info, I ended with this statement about automation and coordination:

“It’s an old ARCHICAD adage that if you’re going to see something more than once, model it. That’s how we maintain consistency across views. Good 3D leads to coordinated 2D. It’s the same with 1D, with text. If you’re going to write something more than once, automate and centralize it.”

Making sure our work shows up in multiple Views is important because it improves consistency. Equally important though is that making sure our work shows up in multiple places allows us to combat one of the biggest complaints about BIM: that it is slow, that at best it is no faster than previous methods. Arguments of BIM’s lack of efficacy are of course smoke screen for lack of skill, inadequate effort, inferior preparation, and misuse of the software. Slowness is not caused by working in a BIM environment; it’s a symptom of misusing BIM. If we want BIM to be faster than the old ways, we need to work in ways that utilize the strengths of BIM. We need to work like BIM, not like CAD. One of the fundamental concepts of BIM is accomplishing many things at the same time. With BIM we aim to always multi-task.

One by One or Ten by Ten

Pre-BIM methods of production are a serial endeavor. A single drawing is worked on at a time. BIM is a parallel method. Many—or all—drawings are worked on simultaneously. With serial production, one has a finished drawing sooner, but that drawing may be invalidated later by subsequent drawings. With parallel production, drawings are validated during the creation process by checking the results in other views, but finished drawings are delayed because work is spread around multiple drawings/views. Over a short time frame, serial production appears to be more advantageous than parallel production. But as the length of time increases, the benefits of parallel production become clear. This transition of utility is illustrated by the example below:

While it might take a hand drafter or CAD operator ten hours to complete one drawing, it takes a BIM user ten hours to create ten drawings that are twenty-five percent complete. Ten hours later, the CAD operator has a second drawing complete while the BIM user has fifteen drawings fifty percent complete. After another twenty hours, the CAD operator has four complete drawings and the BIM user has twenty five complete drawings. This is the triumph of BIM.

I like to refer to this extended period of incomplete drawings as the ugly duckling phase of BIM. We produce massive quantities of data, but it’s all hard to interpret by the uninitiated. Telling others to trust us, that it’ll turn out okay, is not a viable solution. A project benefits from having everything developed at once, but communicating the project doesn’t. A project is easier to describe using one complete floor plan than six half finished floor plans and fifty partial sections. Clients, collaborators, and bosses need to see work at all phases of the project. This is where pre-BIM proponents will claim superiority. A single legible schematic plan promotes ideas without the baggage of other documents providing conflicting or confusing information. The solution isn’t to revert to serial production methods similar to CAD or hand drafting, but to embrace BIM methodologies and think about multi-tasking through the lens of a project’s life. Figure out how the wall drawn on day one will be valuable for SD, DD, CD, and CA.

A plan produced with ARCHICAD looks unfinished during the early stages of model production and design because the View lacks uniformity of completion. Some elements are overly detailed—a Composite Wall showing all its layers or a Window showing all the detail of the frame—while others are schematic at best—an empty kitchen layout, a bathroom that clearly doesn’t work, or a trellis lacking proper structure. The answer to this mix of refinement is to manage the display of information, not to omit information from the file. We must design and document in the way that best suits our needs, and then alter element display to make the drawings uniform and legible. By controlling display to create a uniformity of completeness in our drawings, we can mimic the benefits of serial production: a drawing that looks complete, whether or not it really is. The following two posts cover the details of how to best do this in ARCHICAD:

My Intelligent Dumbing posts discuss how to apply predefined rules—Model View Options (MVO), Graphic Overrides (GO), Pen Sets, Renovation Filters, Layer Combinations, etc—to various Views. It is not enough to just make the graphics automatic on an individual View. We need to make those automatic graphics happen on multiple views simultaneously. We need parallel automation, not serial automation. By using global solutions that automatically apply the desired graphics to all selected Views, we fix the graphics of many drawings at once; we are multi-tasking. We must avoid the presence of any View Setting (or really anything in ARCHICAD) called CUSTOM. CUSTOM is CAD. CUSTOM is not multi-tasking. CUSTOM is inefficient. CUSTOM is local and not reproducible. CUSTOM is a roadblock and a speed bump. If you have the option to create something in ARCHICAD (View Setting, Element, Parameter), when given the choice, pick the solution that allows you to edit it in a manner that will affect all related elements/Views/Layouts/Parameters/etc. Even if you think you’re creating a one-off View, Complex Profile, etc. CUSTOM is a mistake. It forces you to manage that piece of data locally in an unautomated, non-multitasking way. CUSTOM in the View Settings is the equivalent of a dumb piece of text on an elevation. It’s a piece of view based data, disconnected from the greater whole. View based data does not support multi-tasking; Project and Element based data does.Inherent in developing all drawings/views in unison is a reorientation of our understanding of project development. We must look at the model first—at the BUILDING first—and the drawings second. We must focus not on getting a legible plan as our first goal, but a legible design. Schematic Design is complete when a building is developed to a certain level of detail, not when the plan looks ready. After all, with the proper display options (and sometimes a few judiciously used graphic data fixes), just about any plan, section, or elevation can instantly be made to look ready. What that means is when the design has reached the necessary threshold for sharing with the client we might have plans, sections, and elevations that are all usable. Or maybe we have none of those, just 3D views. Schematic is done when the design is ready, not when it is properly dressed up with wisps of smoke coming out of the chimney or squiggly trees in the background. In this understanding of project development, we begin to realize that notes and dimensions on a plan hold less worth than a complete series of text-less Views. Notes and text are for others, not for the designers. All that information, if it’s known and if it matters at an early stage, should be embedded in the elements, not the Views. The data can then be extracted and placed automatically when it’s needed. If you need/want to add notes early during SD or DD, the elements need to be labeled in a way that allows the text to evolve with the project. Always work with an eye towards the final product. Minimize time in SD on stuff that will be orphaned when the next level of detail is added. Make sure your multi-tasking is not just about getting data in the right Views all at one time, but also throughout time.

Part Two: Don’t do too many things

Last year I designed a bathroom remodel that was all of 90 sq ft and I also did a remodel for a chiropractic office. I used 3D tools for both projects. I peeked at the 3D, but I didn’t show it to the clients. And I never modeled what wasn’t seen in plan. It wasn’t necessary. The models didn’t do enough to help in either project. It wasn’t needed for the level of design I was doing. The clients didn’t need it to understand what was going on. It wouldn’t have been multitasking to get the model developed beyond what was needed for the documents. It would have been wasted energy.

Always Multi-task, but…
remember not all multi-tasking is valuable

Not wasting effort and knowing when to stop are important components to good mutli-tasking. We can’t claim super methods of design and production by counting phantom or false benefits. When working in ARCHICAD, make sure that the secondary benefits are real. If we are working on a project that won’t have a demolition plan, managing what will be demoed using Renovation Status might be a waste of time. If we are not keeping track of cost, we shouldn’t include that field in our schedules. More is not always better. Analyze everything we do within ARCHICAD and question how many benefits there are from it. Find out how to extract more value from what we’re doing and be vigilant against falling into traps where we are doing more but getting nothing extra out of it.

I can tell you a variety of techniques to efficiently model every stick of lumber in a single family home. It makes for beautiful drawings and impressive models. But what’s the point?

BIM is about more than just geometry and data. It’s also about people and money. We need to think about multi-tasking from both those perspectives. Money is at the root of all of this. Are we doing something that wastes it? Or are we doing something that makes us more of it? Multi-tasking as it relates to people though is more interesting. How are our decisions affecting the various people connected to the project? Are we creating linked data to help the designer or the model author? Or is it to help the contractor and client? Good decisions help as many stakeholders as possible.

Be wary of single beneficiary decisions. Don’t agree to do something (without additional fee/time) if it’s only helping one stakeholder. If the contractor wants to know how many square feet of drywall are in the project, make sure it’s to benefit him and the client before you spend your time figuring out the answer. Or make sure knowing that information is valuable to you (because it’ll improve your design or make you more money because you’re charging hourly for the answer). This requires a shift in perspective. If you learn how to calculate quantities in ARCHICAD to a degree that offers benefits to others, make sure you learn how to make that information valuable to you as well—through additional services to your clients, better design via the conservation of resources, or better collaboration with other contractors on future projects. Just because we can find out any piece of information from BIM doesn’t mean we should or have to.

Single beneficiary decisions are often without merit, but they can occasionally have utility. Sometimes we have to do things to make just one stakeholder happy. The bigger danger is when single beneficiary decisions are really zero beneficiary decisions. These are modeling and data creation choices that are often made for the glory of the designer, or in pursuit of a greater BIM truth. Don’t waste your time doing things that not only don’t support multi-tasking but don’t offer any additional value. Don’t create every interior elevation or call out every detail if no one needs that information in the field. Don’t add unnecessary information to your model because you think all BIM files need to have X or Y data in them.

Part 3: You Knew This Was Coming

BIM shifts drawings from a serial endeavor to a parallel process. Parallel processes allow multi-tasking and in turn speed up work over anything but the shortest time frames. Throughout this article we have been focusing on individual projects. BIM and the benefits of parallel processes are exponentially more beneficial when we look not at a single project but all projects. Automating the graphics of a drawing is good. Working so that all drawings in a project have their graphics updated in unison is better. Setting up systems so that all current and future projects benefit from the automated, multi-tasking graphic standards we develop is the best. Using a template transforms work from a single project to all projects. A template turns the creation of projects from a serial process to a parallel process. It allows us to make another leap in efficiency, similar from that of CAD to BIM. Templates are how to make BIM even more profitable.

In this article I’ve mostly focused on graphics and output. The benefits of multi-tasking of course should be extrapolated to all other tasks within ARCHICAD and BIM. Are you following Graphisoft North America on Twitter? Click Here to keep track of all the latest ArchiCAD News in North America (and beyond).

BONUS: years ago I wrote an article for the now defunct ArchiMAG on parallel teams vs serial teams in ARCHICAD; it’s worth a read.

1 Comment

  1. Marin Racic

    Great article, Jared!!

    Reply

Submit a Comment

Your email address will not be published. Required fields are marked *