How Revit Helps Manage and Support Both Premeditated and Unanticipated Change (Part 3/4)

Of all the industry pain-points and problems I have referred to in past articles, design and documentation inputs that seem to exist in a constant state of change are personally the most frustrating. So much so that I am sure many of you could echo very similar sentiments. With that said, I want to be careful to avoid broadly painting change as an issue in need of an absolute solution. While there is such a thing as unnecessary, “fee-eating” change, I would say that most revision is arguably essential and does not directly represent an industry-wide problem. Production inefficiencies and team-wide frustration begin to rear their heads when entirely appropriate change is mismanaged or poorly approached. This observation reveals the core problem that does definitively need to be dealt with – namely, how can themed entertainment teams prudently equip themselves to absorb and manage this inevitable change when it comes? Just as the need for intentional project coordination, as discussed in Part 2, cannot go away in the context of complex multi-disciplinary projects, project change – which takes on many different forms – cannot be altogether eliminated. On the contrary, it seems that change should be intentionally encouraged and, to an extent, celebrated throughout the course of any project since painful shifting conditions are the main impetus for project improvement across the board. An individual’s first attempt at something, creative or otherwise, will very rarely be their best and should certainly not be their last. Divorcing intensely creative and incredibly complex projects from their designer’s essential desire to change or improve is only foolhardy, markedly so since the issue at hand is absolutely manageable.

As was the case in my previous articles, I aim to present Revit here as the tool best-equipped to manage our problem. In this particular case, Revit cannot eliminate all of the heartache commonly associated with project change, nor should it be expected to. While Revit is a powerful tool, adding an extra scene to an attraction or deleting five floors out of the middle of a skyscraper at the cusp of an impending deadline will certainly still generate some discomfort. In my estimation, when dealing with novel or complex projects, this eventuality is unavoidable. Ultimately, our goal here is to use Revit and its strengths to minimize any displeasure typically experienced at the hand of change and to do so with realistic expectations. In the interest of concision, it is pragmatic for us to subdivide the general topic of change into two smaller categories. Namely, we have both premeditated and unanticipated change, or more simply put - planned and unplanned change. As anybody could reasonably assume, it is much more challenging to manage the changes you cannot or did not anticipate versus those much more routinely encountered and therefore expected. In each of these two subdivisions, designers often face three specific subtypes of change. For our purposes, they can be described as presentation/documentation (2D) change, design intent (3D) change, and data/informational (4D) change. Each of these three types can exist within both of our previously mentioned categories. The remainder of this article will cover examples of each and how Revit is specifically poised to offer more profitable ways to approach them.

This animated gif shows a powerful example of two-dimensional change. Each still-image was taken directly out of Revit from the same exact view. All that changes between images is the visibility of specific automatic groupings of 3D modeled components and the value of a simple parameter that controls where the floor plan cut-plane is located vertically. The resulting linework is drawn and updated automatically dependent on these two user inputs, all in a matter of seconds.

Since we have established that anticipation is the most influential component of appropriately managed change, it follows that planning and strategy should exist in cooperation with the design decision-making process. This idea applies broadly to projects on both the macro and micro-scales. In the pursuit of enabling increasingly uncomplicated and painless “revision implementation”, designers should, regardless of their chosen tool or practice, stay in the habit of asking themselves and their teams the following two questions:

1. Do I expect this particular design component to change in any way over the course of this project?
2. Generally, how can this project or feature be expected to evolve over time?

The answers to these questions - and others like them - should serve to point towards the technique best suited to maneuvering the task at hand. I think the secret here - if I can sensibly call it that - is to anticipate and plan for as much change as can be expected to occur at any point in a project’s lifespan. In essence, this leads teams to undergo critical task-by-task risk-mitigation reviews. Our question in these situations becomes: Is it comparatively worth it from a resource management perspective to “build-in” the ability to more-painlessly implement potential revisions when it is not clear whether they will actually be necessary? After all, doing so demands time and money be spent in potentially unproductive ways that may not provide discernable returns. In my opinion, the time and cost savings experienced as a result of preparing for alterations that sometimes do not occur are much greater than the savings experienced under any assumption of a no-change environment. This seems accurate since such an assumption is often faultily made, and when eventually proved incorrect results in resources spent on frustrating and inefficient rework. The counterargument applies only when a project genuinely experiences minimal change or revision, which only happens in limited applications and is unlikely within the context of themed entertainment.

To expand some, let's picture two conditions that differ in scale - one at a broad project-wide level and another at a much narrower, element-specific level. Generally, perhaps our project is a large sports arena situated on a restrictive site. It would be reasonable to say, answering the questions I posed earlier, that the project as a whole in this circumstance will likely not grow in total square footage by any substantial amount. If our site is suddenly much less restrictive though, a programmatic element – maybe a team training facility or museum exhibit – could reasonably be added during design or as an expansion post-construction. If it is feasible for either change to occur, it makes sense to at-a-minimum approach the design with this potential in mind. I think that most designers are adept at handling the concept of change management to this extent. After all, as I implied earlier, design and change are attached at the hip, and I think designers are certainly used to that. What is not practiced enough is the systematic selection of process implementation techniques, not just design strategy and approach, in direct response to these potential changes.

Specifically in Revit, but likely also in other software packages, it is possible to achieve the same outcome using any number of different methods. For example, modeling something as simple as a cube in Revit can be done in at least ten different ways. For your benefit, I will not explicitly list each out here, but it should be clear that many additional methods become available once we consider elements more complicated than cubes on the expanded scale of an entire project. The key here is that each method has inherent positives and negatives that maneuver the eventuality of change differently, and each with different timeframes required to implement. While there is no inherently perfect method when it comes to process selection, there is likely always a comfortable middle ground that balances time-to-complete with resilience-to-change appropriately. Narrowly, let's picture the individual chairs included in the expansive seating bowl of our arena. The seat count, placement, spacing, and design are all very likely to change as the entire design develops. Many different variables come into play here – sightlines, budget, aesthetics, life safety, ergonomics, accessibility, etc. Since I expect each constraint to change regularly, the technique I use to design and document these elements should allow me to adjust as much as I like with minimal effort. There is no need to start from scratch whenever these changes occur - unless of course you are ill-prepared to implement them in the first place.

Like the previous gif, this image shows another example of two-dimensional change. Once again, the same view was used to extract each individual image. But in this case, what changes between each view is object visibility, as before, and object visualization. This should illustrate that, upon setting up a handful of rules and constraints within the project, objects can be drawn and redrawn automatically with varying visual styles.

Premeditated change is the most straightforward to manage of the two categories, especially when we consider using Revit as the primary design and documentation tool for our projects. Revit allows you to powerfully control scores of small characteristics in your project from the start. Beyond this, it enables you to enhance its base functionality by introducing variables that did not previously exist and give them predefined relationships and constraints that govern their behavior when change occurs. I understand that this is admittedly a rather complex explanation, so let me offer a handful of examples. 2D change comes into play in our projects quite often, with an example being when your client or project lead requests that every cut element be shown with a poche. As BIM-enabled 3D software, Revit has a fundamental understanding of which components are cut by each view in any portion of the model at any point in time. This is pure out-of-the-box Revit behavior. To meet this request, I merely tell Revit to select all cut elements and display them with a solid black poche. Every selected view that shows a cut element will display those elements precisely how I have specified, regardless of view complexity or orientation. If I was mistaken in choosing a solid black poche, and my client wanted dense blue diagonals instead, updating could take as little as a minute to accomplish. Achieving the same in a program like AutoCAD involves a notably laborious, multi-tiered process. To implement, I must first have a perfect understanding of exactly where elements are being cut since it is my responsibility to draft each hatch boundary unaided by the software. I then have to place each hatch in the proper location in each view, in every xref. Such an effort could easily take days, and if I at any point used the wrong hatch type or boundary, I would have to go through the process again to make sure that each is appropriately updated and consistent with the design intent. Days of effort to make drawings a bit more legible can be reduced to mere minutes using Revit.

Similarly, planned-for 3D and 4D changes can be very straightforward to accommodate when using Revit. For instance, if we know that an architectural column needs to have a particular position within a building, but we do not know what size the column will ultimately be, we must take steps to determine the best way forward. When using tools similar to AutoCAD, teams may opt to bite the bullet and update the entire design manually if and when it becomes necessary. With Revit, we can model the column with assumed dimensions but include design parameters within that modeling to allow the user to flex the column's geometry when necessary. Certainly, it can take considerable skill and knowledge of the software to build in this flexibility properly, but the time invested, as stated above, will regularly pay significant dividends. Many complex relationships can be created using this technique, and the results are often remarkably effective and serve to save countless design and production hours. The sheer power behind this technique becomes apparent when you consider the project as a whole alongside the context of Part 2 of this series. Instead of there only being one column, more likely your project could have several hundred - none of which you know the proper size of. You need only model this column with built-in flexibility once, to be placed in the correct locations throughout the project again, only once. Revit will now perfectly display each of these columns in any view, at any orientation, taken from your 3D model.

The kicker is, when these columns inevitably change as we have anticipated, each project view will know to update automatically to reflect the new design. Now we no longer have to hunt down each location where a change is appropriate every time one occurs. The status quo, IE working with AutoCAD, requires an unbelievably large commitment to tracking those changes and ensuring prompt and proper communication with your team. Instead, we can rely on Revit to quickly and effortlessly complete this search with utmost precision, entirely in the background. This is a hugely compelling implication that lets designers actually focus on the design and not on 2D drafting micromanagement and revision tracking. We must inevitably lean heavily on this implication when dealing with unexpected change, the more troublesome of the two categories. Even though some rework may be required in these circumstances, we still know that we only have to make the two or three-dimensional change once, with Revit taking care of ensuring your model and resulting drawings stay consistent everywhere else. While incorporating unexpected changes within your project may ultimately still be uncomfortable, Revit helps by nevertheless reducing the total amount of work to be accomplished by several orders of magnitude.