As the title suggests, we’re going to discuss a few key topics that if implemented correctly can greatly improve the success of your project. This is going to be more of a lesson’s learned portion of this session in that I’ve identified these topics based on our own lessons learned. As I said earlier, I have had the opportunity to be part of two fairly successful IPD projects over the last couple years. However, by no means does that make me an expert on the topic. What is does mean is that I’ve experienced my fair share of wrong turns, learned from them, and as a result gained some valuable knowledge along the way. The biggest mistake you can make is going into this venture called IPD and expecting perfection on the first try. We are still at the cutting edge of this process, which means it is not the norm just yet because we are all pioneering it. Not all of the pitfalls have been clearly marked and not all of the best known methods have been sufficiently documented. Projects will have vast differences from one to the next and offer new opportunities to learn and grow as designers, contractors and with any luck, clients.
Roles and Responsibilities
So what are some keys to the success of a IPD project? Let’s start at the beginning, the core: Roles, Responsibilities and Expectations. Establishing what everyone’s roles are throughout the project team and throughout the project life cycle will serve as a foundation that everyone can stand on and as a result feel confident in their position within the project team. It is important to identify and document, in detail, these roles and post them where everyone in the project team can see them; on a shared drive, sharepoint, thumbtacked to a conference room wall, a Revit schedule, whatever you need to do so that there is no confusion.
Let’s take a quick look at a role that we identified a need for. It’s a role that incorporates a lot of responsibilities that were previously being dispersed across the entire design team. As a result we saw a lot of inconsistencies in how the tasks were being executed which resulted in a lack of consistency in our drawings, trade coordination processes and schedules. We titled the role that we came up with as Fabrication Coordinator. This person can now be responsible for a fairly diverse set of tasks that all play into the success of the fabrication drawings effort. It incorporated the roles of a routing coordinator, ambassador to construction, and some BIM coordinator roles. It allows for one person, or a group if the project size requires it, to ensure that there is consistency across disciplines and design teams. It frees up designers to do what they do best and instills a greater level of confidence amongst our trade partners. We came up with the need for this role because we took a step back and identified all of the roles and responsibility involved in creating fabrication drawings and recognized the magnitude of that list and how by spreading it around we were setting ourselves up for chaos.
Process Workflows
Before you can establish what everyone is responsible for, you’ll need to establish what there is to be responsible for in the first place. This can be done by creating detailed workflows for every process in the design and construction phases respectively. Remember what I said about IPD being cutting edge. By being so, there aren’t road maps or trails to everywhere we need to get to just yet. We’re in the woods, we know where we want to go, but there isn’t a blazed trail to get there, so we have to start bushwhacking and start blazing trails for future endeavors. Design for construction follows the same principal, we know what our end result needs to be for each process but we don’t always know all of the steps to get us there…yet.
Start by identifying the projects goals and work backwards from there. By working form the end to the beginning it will make it easier to identify internal and external milestones of the process along the way. Some examples of project goals that would involve me as a mechanical designer would include P&ID development, design model development, issuing IFC drawings, issuing fabrication drawings, submittal review, and final construction punch lists. That’s a pretty high level view of the project lifecycle that in itself could be a central workflow that other sub process workflows could stem from. This is a great place to start, establishing a high level workflow of the entire project lifecycle. Doing this holistically as a project team will ensure that all the major milestones to completion are identified. From there specific areas of expertise can break off into smaller focus groups to develop their specific sub process. For example, in my high level workflow I mentioned issue fabrication drawings, which has an intricate sub process within itself and has its own set of sub processes. The issuance of fabrication drawings is close coupled to issuing IFC drawings because with Revit, the model content is the same for both sets of documents. Allow me take a moment to underscore that, the model content that you develop for your design will be the very same model content on your fabrication drawings.
By creating workflows for all the processes involved in a project you will have effectively flushed out most if not all the little scheduling gotchas that tend to crop up. Now, I’m not saying that the workflow should go to such great detail that launch Revit and open project file are steps in the design process workflow. Make it a logical level of detail that makes sense for the team involved in the specific task. A good rule of thumb is to ask, is there a handoff involved at the end of a task or is anyone but me going to be interested in its completion? For example, is there an external advancement or handoff when I finally get that massive Revit project open? No, but now I can finally start getting some work done. Is there an external advancement once I get the schematic routing of a pipe modeled? Yes, my design engineer or trade partner can now review it, so there is a hand off at the end of this process and should therefore be included in the process workflow. Below is an example of our current fabrication workflow process. It demonstrates the milestones that need to be reached during the 60% development phase. Each of the processes in the workflow below have sub processes and supporting documents of their own.
Developing workflows of this magnitude may seem like a daunting task in its self, but it will only get easier from project to project. Don’t assume that just because the workflows you used on the previous project will apply to the next either. Take the time to review them and adapt them to new project dynamics. Players may have changed. The job site will most likely have changed. Where the design work is being done in relation to where the construction is being done may have changed. You may need to add processes like uploading drawings to an online collaborative site because you are working remotely which means you will need to identify whose responsibility it is to do so among the project team.
Point Clouds and Existing Conditions
They can be your best friend or your worst enemy and in some ways can make or break a project. When do you scan? How much do you scan? Do you employ a small army of junior modelers to turn the point scan into model elements? This is an extremely subjective topic and needs to be reviewed not only on the project level, but also on the scope level. Over the last couple of projects we’ve tried a number of different approaches and had success and failures with each of them when applied to certain scenarios. Unfortunately there is no one size fits all process when it comes to point scan implementation. So I’m going to share a couple of them with you, talk about the good, talk about the bad and hopefully help you make the right decision on your next project.
For our pilot project we took the scan everywhere, model everything approach. For the level of detail we were trying to get to get to, we were convinced this was the best way to get the job done. The main area of focus of this project was a retrofit of a 35,000 square foot section of an operating semiconductor facility. To accomplish this, we had a team of modelers working through the point scans of the facility bay by bay modeling everything, ducts, pipe, unistrut racks, cable trays, everything. Well almost everything, but we’ll get to that. For the designers on the project, we thought this was awesome. We could just cut out sections and 3D views and get down to business. Clash detection and mitigation was straight forward. Flying around in navisworks and impressing the client was a breeze. It did created a false sense of security though, as we soon realized that there were elements missing because they weren’t clear in the scan or decided that they weren’t important. Conduits were being modeled as pipe because there was an “as long as it takes up space mentality” amongst the modelers. Everything was oddly symmetrical, parallel or at right angles. Which is fine for modeling design content, but the real world isn’t built that way, so by modeling existing conditions that way, we would find that even though the first cross section of a pipe rack would be spot on, by the time you go to the other end 200 feet away, the cross section could be a foot off its mark. The result was a really amazing looking existing conditions model that was nice to look at, but not so nice when you’re trying to prefabricate construction elements based on the design model. This is not to say that this was not the correct approach for this project, but it required more back checking, skilled modelers and ultimately a lot more time that the effort was given.
The next approach was to go to the opposite end of the spectrum and not model any existing conditions, only specific isolated areas if specifically requested. This was another valid approach as it cut out the entire budget-devouring existing conditions effort. To do this, our designers were required to model design content against point clouds rather than existing model content. To maintain performance we linked the point clouds by scope area into Revit “wrapper” models. The wrapper models could then be linked into the design models instead of directly linking the scan files. This can also be done to improve performance when dealing with 2D cad content. It allows Revit to natively deal with the nonnative content. It also provides a higher level of content management for areas with numerous point clouds so that the end user can manage multiple point scan files by loading or unloading one linked Revit file. The linked Revit projects can also be placed on individual worksets to reduce loading and unloading. All of this allowed us to hit the ground running, so to speak, much earlier than the previous project. However, this presented its own set of issues. Clash detection proved to be very difficult, time consuming and hit or miss. Even though navisworks is capable of clashing model elements against point cloud elements, the process still requires quite a bit of refinement to be ready for mass production. The cloud only approach also presented a problem when trying to review designs or create sections and elevations to convey design intent. By not having model content, it was very difficult to grasp the design concept. For client reviews, large point clouds had to be temporally cashed on laptops and then deleted afterwards to free up space. So again, very mixed results with this approach. On the other hand it provided a greater level of confidence in the accuracy of our designs because it eliminated the model translation step of tracing the point cloud.
If your project requires that all existing conditions be modeled, then do it, but make sure that there are mechanisms in place to ensure quality and accuracy. If you don’t have any reason to model existing conditions, make sure you take measures to maintain performance to support all of your design team working with point clouds. My advice is to find a happy medium between these two. Identify routing or areas of scope early. Refine them as needed and review with your construction counterparts prior to scanning. Scan only what is necessary then have a skilled existing conditions team, not your junior team, model a specified envelope around the design area. This way only the areas that have direct interaction with your work will be included in clash detection and client reviews. If external areas need to be reviewed for move in paths or accessibility, the point cloud can be referenced as needed or the area can be reviewed in the field. This method does require a certain amount of coordination very early on in the project, so early trade involvement is critical and be sure to include this in your workflow as necessary milestones.
Design Model Content
The question of whether or not to model everything isn’t limited only to existing conditions. This is IPD, this is design build to the next level. The design model is the construction model. So, just because modeling the little brackets that stiffen your support strut aren’t critical for your scope to be built doesn’t mean it’s not critical for another discipline to be aware of when modeling. It may appear to be open space for electrical to squeeze a few small conduits through, but once in the field the conflict may force the conduits to be shifted into an area where some expensive, prefabricated, high purity stainless steel piping is slated to be installed. Now, what was initially a seemingly minute detail has resulted in a very expensive design miss. This is probably seems like a very extreme and unlikely case, but you get the point. If you’re not going to take the time to model the details, then don’t bother taking the time to detail off of the model. Conduits are a great example of this and have caused a great amount of rework for us in the past. Traditionally, conduits under 2” don’t get modeled and understandably so. That’s a lot of conduit to model, for everything from lighting fixtures, to convenience receptacle to small equipment. But that’s my point, that’s a lot of conduits and a lot of potential conflicts. If the conduits are not going to be modeled individually, I would suggest establish electrical no-fly zones or conduit banks and identify them with model elements that can be clearly seen and clashed against. You can use something as simple as ductwork. Create a duct type that designates it as a conduit bank or electrical routing zone. Another option is to use a generic family as a clearance zone, but ductwork is easy to model and manage because it maintains connectivity through Revit systems.
Utility hangers and supports are another “model everything” that can be overlooked. It’s easy to identify and model supports for large bore utilities that clearly require large support steal members and means of attachment. But it’s quite another to convince design teams that trapeze hangers for half inch pipes are required. The truth is that is takes just as long to model a 24” pipe as it does to model a 1/2" pipe and the same goes with the supports. Pipe hangers and Trapezes both require all thread rods that extend to beams and inlays. These extensions need to be accounted for as they can extend directly though a critical routing zone and have equally cascading effects as missing brackets and small conduits. Something we deal with in the pacific North West is seismic codes which require lateral seismic restraint kickers. These are diagonal restraints extending from the pipe attachment point to a laterally offset point of connection to reduce or eliminate movement of the support in the event of an earthquake. As you can imagine, these are particularly troublesome when not modeled during design.
Not modeling wall, floor and roof penetration openings is another pet peeve of mine, but I think you get the point. If you are going to construction level detail in your model, then everything that takes up space needs to be modeled. If you are not going to model everything because construction doesn’t need it to be modeled, then at the very least model something that appropriately takes up the space so that other disciplines can coordinate accordingly. You will thank yourself in the long run and it costs a lot less to model something seemingly superfluous than it does to make corrections during construction.