Clipped or Un-clipped - That is the Question

The question asked: "Steve, should we leave our coordinate system icons clipped or un-clipped?"

My Answer: As we know, the Project Base Point (PBP) and Survey Point (SP) can be un-clipped. If they are untouched we'll find them clipped.

When these are clipped the symbols for each of these are attached to the coordinate systems they belong to. That means moving either while clipped will alter the coordinate system. If this is done unintentionally, or by someone who does not realize they have been adjusted intentionally already, the coordinate system(s) will be changed.

Therefore I'd say it is not unreasonable to leave these in their NOT clipped or un-clipped state at all times, especially after they have been adjusted intentionally to align models or survey data. If they are not clipped then accidental movement of these icons do not alter their related coordinate systems. It merely changes the symbol's position relative to their coordinate systems.

I regard these symbols as markers or annotation when they are not clipped. In this state they are harmless to our coordinate machinations. Clipped they pose a danger to our careful adjustments to align models and site information.

My opinion: Keep them Not clipped, un-clipped.

Shared Coordinates and Collaboration for Revit

I've not written anything about Collaboration for Revit (aka C4R) yet. It's a recent development that puts a project in the cloud to give a project team access to the project data regardless where they are.

When it comes to Shared Coordinates, the Publish Coordinates tool is disabled. Acquire Coordinates does work.

As I understand the issue, Publish Coordinates is the only time that Revit has to be able to write changes to a linked file. The current A360 and C4R infrastructure doesn't support allowing that to happen...yet. They do understand it is something we want and need to do.

Regardless I'd still use Acquire Coordinates on a source survey file within a Master Site file, as usual. Then I'd link any building files and position them on the site, just like I'd normally do. To cope with the loss of Publish Coordinates I'd put location markers (a unique family for example) that allow me to figure out how to link and align Master Site in each building correctly afterward.

As I just mentioned, in each Building file I'd link the Master Site model and move, rotate and elevate it as required. Then I can use Acquire Coordinates and pick Master Site. This will pull the correct Shared Coordinates into the building model. I'd repeat that for each building.

I'd do the little building position dance in Master Site even though I could probably figure out how to do the reverse (position Master Site in each Building) somehow. I'd find it a little easier to work out each building's relationship to the Master Site model this way, seeing them all together at the same time in Master Site. I think it provides for better context.

When other trades get going they just need to link the Architecture model using Auto - Origin to Origin and then use Acquire Coordinates, picking the Architecture model. It's a cascading nested understanding of the survey coordinates, using Acquire Coordinates all the way down.

SMEP-Models - AC from - A-Model - AC from - Master Site - AC from - Site Survey

When they return their files to the architect they just need to be linked using Auto - Origin to Origin too. Technically if they do use Acquire Coordinates using By Shared Coordinates would work but if they didn't Auto - Origin to Origin is reliable...as long as they understand it is important that they start out using Auto - Origin to Origin themselves, when they link the architecture model.

Spaces instead of Areas

Area plans have their quirks. They can only exist in their own special area plan views. They've got rules and quite often people want to break those rules. If we need to do that then we end up sketching boundaries a lot. Areas don't know anything about Rooms either. That means we're probably going to have to enter some data twice if we must use Areas pretending to be Rooms, all to document fussy Room area requirements

If that's the situation we find ourselves in...do we have access to MEP's Spaces? If so we could consider...this...

The plan in this image is an architectural model (yeah really simple mock-up). Is it obvious what I've done? I've got Room tags reporting area only as well as Space tags reporting a little different area value along with Room name and number. It also has a Color Scheme applied to Room departments.

It's also a separate model I called Area Calcs. I linked the Architecture model into Area Calcs. The Room tags I mentioned a moment ago are actually Room tags, tagging each room's area in the link. For Spaces however I opted to just sketch Space Separators over the linked model since I need to identify different parts of the room's boundaries to calculate area anyway. A Space isn't different from a Room when we rely on walls for their boundary, in how they calculate area at least. Sketching our lines gives us complete control over the results without dealing with Area Rules.

A Space Separator is a linestyle (like Area Boundary and Room Separator) and I changed the appearance to a much thicker burgundy line so it stands out against the linked file's plan. I ended up applying transparency to Walls too. Once I defined the boundaries I needed I used the Space tool and opted for Place Spaces Automatically. This creates a Space wherever one is possible within the boundaries I've created. This is done floor by floor, assuming there is more than one floor.

Just in case you weren't aware of this already, a linked file has a Room Bounding option.

If this option is selected then Place Spaces Automatically creates Spaces wherever Revit finds Rooms and valid boundaries even where there aren't any rooms (note my interior design comment later). Since I need to define room area differently that's not going to help me now. It's intended to speed up the process for engineers while they are preparing their project to start work.

Now that I've got Spaces I can take advantage of a separate tool called Space Naming Utility (SNU). It is crazy that this tool is still a separate installation but it is. At least it isn't locked away in subscription only access anymore. I keep hoping it will show up inside Revit in the next release.

Sorry I digress, it (SNU) will read (from the linked file) each room's name and number and pass it to the equivalent Space's name and number.

One risk here is Revit might not figure out which Room is supposed to be related to a Space. However, if we examine the properties of a Space we'll see right away whether Revit can see a room relationship or not. Plus any Spaces that don't update will be a clue or at least identify a Room that hasn't been filled out with information properly yet. I'm hoping to apply the 80/20 rule here and win.

If I want to use Fill Patterns too, like below, I can create a separate view that only shows a customized Color Scheme that applies Fill Patterns instead of a solid color fill. Then I just stack (overlay) this view on top of the other floor plan on a sheet. I just need to make sure the view is using Wireframe so it doesn't mask the floor plan.

I can even add a separate Color Scheme legend to the other view that's stacked over the floor plan.

Choosing this route might come down to how I answer these questions:

• Do I have Spaces? (Are they part of the Revit version I use?)
• Which is worse, sketching Space Separators or Area Boundaries?
• Which is more fun, using Space Naming Utility or manually updating Area data to match relevant Room data?
• If I know a Dynamo/API programmer then maybe I can improve the Room to Area process instead?

This popped into my head last evening while I was mulling over a client's email. I've suggested using Spaces in the past to help deal with linked interior design models so this time around it didn't seem quite as crazy to me as it did the first time.

Want to poke around the files (Revit 2015) I used for this post?

Area Plans
Area Calcs

Your mileage may vary...

Justifying a Revit Manager

Imagine...you work for a firm that doesn't have a dedicated Revit Manager. There are nearly fifty of you toiling away with Revit now, things are busy, business is growing. That's great!

Still, management isn't interested in having a dedicated Revit Manager. The current solution is to divide up the things that person would do across three power users in the office. A year or so ago when there was about thirty people it didn't seem like a problem, as much.

Can you help your firm justify a Revit Manager?

Full disclosure, I don't usually get involved in this kind of discussion with clients since I tend to focus on user's work, a Revity task and strategy bias. It's not a normal part of my work but I am comfortable with wandering into conjecture, to offer my thoughts. How would I approach this if I am the one in this person's situation? I want my firm to recognize a need for a Revit Manager (or if you must...BIM Manager, I'd prefer Design Technology Manager personally).

I'd want to find out how my firm's management makes decisions about staff in general. When do they decide they need another office secretary, assistant, architect, intern or anyone? What factors, what numbers are they crunching, considering when they do that? How much analytic effort is put into it? Who are they entrusting with the decision to do something ultimately?

Let's say in this situation, we have a full time IT person. How did they decide that was necessary? I'd want to know why they consider that different from a Revit Manager (or Design Technology Manager). This is software that so many people rely on for 40+ hours a week to do billable work. I think that makes it (the software) important, which in turn makes the role as important to the firm as the IT person is to keep computers functioning well and securely. If they really don't recognize that, then I'd want to understand their logic, if possible. Then I could counter their thinking with more data, more examples.

It is also important that they (management) appreciate they ARE already paying for this person. They are currently paying other people to do that person's work (the three people mentioned earlier). Hopefully they aren't so distracted to think that's not the situation at hand. Each minute they are not directly billable is that person's time.

As such they need to quantify how much time and money that effort, spread across three people, really costs. It's quite easy to ignore money trickling out the door when they don't have a security camera focused on it to help them see it. How is it affecting them being billable, providing a greater income and return for their effort than the internal work that is distracting them.

Chances are good that, lacking a specific support person, there are even more indirect costs that are not getting tracked well (or at all) because those three are not really covering everything that arises. Nor do they have time to plan ahead or deal with office wide implementation effectively enough. People tend to struggle for quite awhile before they ask for help. The three are busy so they aren't free enough to just check in on people and catch them in a problem.

If I'm hitting a brick wall, can't get them to agree there is an issue then I'd suggest a study (oh NO...going academic now). Doing one demonstrates being willing to substantiate a claim and having enough patience to research it, to remove all doubt.

We make all sorts of decisions and many of them as much emotional as analytic. We call it hindsight when in two years we look back and agree that it was obvious we needed to do something...either we did and we are patting ourselves on the back or we didn't and are expressing regret. In the skeptical mind, we hear..."oh, it's a delay tactic...putting off making the right decision we think it is". It's quite likely that we need to measure things that are probably not now. A study could help this along, help everyone recognize the problem for what it is.

For at least one month we should carefully track activities, much deeper than we've done before. Ideally it should be for a few months. This allows us to gather more data which can help rule out any peculiar things that happen during the study's run which could skew the conclusions, like one project running off the rails due to external problems that end up distracting the firm excessively. To do this really well ALL of the staff needs to be involved (everyone this person would influence/support). It needs to be easier to identify how the lack of this person IS influencing everyone's productivity.

Anything that is not directly billable to a client's project is assigned to other cost categories. If accounting is pro-active then they've already got a variety of chargeable codes to use on time cards. If not then they need to start there so it is possible to see where the money is really going. We need everyone to be comfortable with keeping close track of their tasks carefully for this to work, no fear of recriminations if they get caught being not billable as much as we expected.

I would not be surprised if the study also flagged other issues that might be every bit as interesting, apart from the purpose of this post. The quote attributed to Peter Drucker is, "If you can't measure it, you can't improve it."

Once we've got data we can see how much time is spent away from billable tasks. Then we need to compare the cost of one person dedicated to doing those things for them, instead of them, everyone. This allows for a comparison with their effort (the three) being entirely billable instead (to the extent that any of us are entirely billable, never truly 100% if they are tracking things realistically).

We're looking to establish that the company can put at least two of the three back in the fully billable category, generating income instead. Maybe the third person (me, it's me, I want the job!) really wants to do this job and can become entirely assigned to overhead, which in turns should help to ensure everyone else stays closer to fully billable status.

The numbers should prove that it won't cost the company more money to do so...if we are are correct. If we are correct we'll probably discover that we'll be in a better position, and not just financially. It is also possible that we discover that things are better than we think, for the moment, and the current situation is doing right by the firm. To be fair we need to be open to that result too...as long as the numbers are examined well.

There are also less tangible (not just $$) things like happiness and confidence, firm status (reputation) with regard to other consultants (and clients) and using Revit/BIM, reduction of redundant activities (like everyone making doors), setting priorities, standards, training, quality control and others. These all contribute to firm's culture, being productive and happy to show up at work in general.

If the study's results don't support creating this role then its possible that the issue is more emotional, maybe a staffing issue or just how the firm's attitude or message is received by everyone. I've seen situations where a project manager is very concerned about problems only to learn that he keeps overhearing his power user complaining about things he wishes could be improved. Those thoughts get interpreted into my project has a real problem and that can escalate quickly.

Then again, maybe someone is not in a role they'd really enjoy more. If that person is the one that believes the firm needs a Revit Manager...me for example...then I've got some soul searching to do. The firm doesn't seem to need that role yet but it's what I want. I can wait it out, maybe the firm is still growing? I could also find a larger firm instead that offers an opportunity to pursue the role I want.

Working through this sort of business problem and doing it well might just be the proof your firm needs to recognize you have greater potential than they might have initially considered.

Wish me Luck! I'll wish you luck!

Survey Point - Post 4 - Acquiring Coordinates and View Orientation

The bias of the last three posts has been on creating a Master Site file and linking building models to site. That's moving buildings on a fixed site versus moving the site under fixed buildings. The earth doesn't go anywhere, we put buildings on it, so to speak. That bias feels right to me, the ways things really work.

These are links to the three preceding posts.

Survey Point

Survey Point - Post 2

Survey Point - Post 3 - Five Minutes with Shared Coordinates

If you choose to take the reverse approach, link the site to a building, you have to adjust the survey information to align with the building; since its harder to move the model elements around than the survey file. In this example, I've started in a Floor Plan view assigned to Project North.

At this point is doesn't look much different than images early on in the other posts. The building is oriented conveniently for putting in on sheets. I need to move and rotate the survey DWG into a better orientation. I'm using the same preferences I had in the previous posts.

Now I just need to shift the survey down since the contours are at their actual elevations and the building model is at an arbitrary ground floor elevation of zero.

I used the same 22 feet for the ideal ground floor elevation I chose in the other post.

Now I'm ready to use Acquire Coordinates. I opened up both the floor plan and site plan views so I can see the change occur. I used Acquire Coordinates in the floor plan: Level 1 (that's significant...in a moment).

Since there are few possible combinations of actions, let's imagine that I used Acquire Coordinates a little differently. In this case I Acquired Coordinates in the floor plan view: Site and I wasn't observant enough to notice that the view is assigned to Project North which ordinarily wouldn't make sense to do, to me at least. It's easy enough to overlook because at this point the building orientation is technically the same as it is in other views assigned to Project North.

After I Acquired Coordinates I noticed the view didn't change so I realize it needs to be assigned to True North. I do that and the model rotates to show the orientation based on the survey's coordinate system, as I expected initially.

Now a little time passes (we're pretending). I find it necessary to use Reload to update the linked survey file, maybe I cleaned up some of the layers to make it a little lighter in our model. When I click Reload this happens. The survey spins out of alignment.

The cause is subtle and simple: it is IMPORTANT to respect the Orientation parameter setting used, in the view that's used, when Acquire Coordinates is used. If you change to the opposite setting and then Reload the link the orientation of the link will change undesirably; regardless of the view you happen to be using during the reload process.

To restate the cause and effect, I used Acquire Coordinates in the Site view while it was assigned to an unnatural orientation setting of Project North. I then changed it to use the more logical True North but AFTER I already used Acquire Coordinates. This means I have to remember to change it back (to Project North) EVERY time before using Reload on the Linked survey file... Or I fix it, which would require resetting the coordinates so I could Acquire Coordinate again with the better settings in place.

I believe this is another good reason to use a separate Master Site project file. The survey is linked and moved into position but it isn't rotated to reflect True North because UP is North already. The quirk I've described only affects the links rotation and there is no need to rotate it in the Master Site strategy.

Survey Point - Post 3 - Five Minutes with Shared Coordinates

I created a video that goes through the process I described in the previous two posts. It is set to a four and half minute song by Michael Lee Firkins called "The Window". If you've never heard his music I believe you owe it to yourself to check him out, very talented and unique sounding guitarist and song writer.

Survey Point
Survey Point - Post 2

Survey Point - Post 2

Yesterday I ended the post with a list of steps that I'd take to create a relationship between my building project file(s) and the Master Site file. I started another pair of projects that I'm calling Tiny House A and B (inspired by Sean's Tiny House project). I can start a project with or without site context. Revit's bias is making the project easy to document, forget about True North initially. It is trivial to resolve that in the Master Site file once it is ready, regardless if it is created before or after the tiny house models are started.

Here's how far I took the design of Tiny House A before I decided to work out its location on site.

I closed Tiny House A's project file. I opened up my Master Site file and linked Tiny House A using positioning: Auto - Origin to Origin. The choice for positioning at this stage really doesn't matter since I'm going to move the file to another part of the site anyway; have to pick something so I just let the default option reign. In the following image you can see Tiny House A is sitting at/near the Master Site's origin, marked by the Project Base Point icon.

Now it's time to move Tiny House A into position. I moved it and then aligned it with the East boundary. Then I was careful to put it at 8'-0" from that boundary. I then made sure the closest corner (wall) of the house to the North boundary was also at 8'-0". Being fussy about this isn't particularly important, I'm just being fussy.

Now I want to make sure the house is at an appropriate ground floor elevation. I created a section view so I could see the site's contours and the floor of the house. I can see here that the house is buried under a fair bit of the site.

I decided that raising the house to 22'-0" feels good. I used the Move tool, and typed 22 into the temporary listening dimension that appeared.

I think I'm ready to deal with Tiny House B now. It's really just another project file saved with a new name. I was too lazy to make another design. If this was a real project I wouldn't be able to get away with that. I decided that this house has to be no closer than 8'-0" to the North boundary but I've also made the North end of the house parallel to the boundary.

I learned while reading the development's covenant and zoning requirements that these houses can't be closer than 15'-0 to one another. I decided to put Tiny House B 18'-0" from A. I heard that A's owner is a drummer so those extra three feet might help keep B's sanity. I also decided that the ground floor elevation for B should be 20'-0", a little bit lower than A.

Now that I'm satisfied with the positions of Tiny House A and B I'm ready to use Publish Coordinates. This tool will PUSH the site orientation information to each house's project file. Revit will use this information to shift the house's Shared Coordinate system to align with the Shared Coordinate system of Master Site. In yesterday's post, the Master Site was manipulated to be in alignment with a linked DWG file's WCS (the World Coordinate System in AutoCAD to be precise) through the use of the Acquire Coordinates tool.

When you successfully select a linked file to Publish Coordinates the Location Weather and Site dialog appears. This give us an opportunity to provide a meaningful name for the location we're creating for that model. I clicked Rename... and typed Tiny House A Location 1.

It's significant to appreciate that I could now create a copy of Tiny House A in Master Site and place this copy in another location. I could then use Publish Coordinates on this copy which would allow me to use Duplicate... and use another name like Tiny House A Location 2. In the Tiny House A project file I can now choose between these two named locations and make one of them current. Revit will reorient everything to show the building correctly for this location, all without really changing anything  in the model. It's pretty clever and powerful; actually doing it is something I'll save for another post.

I used Publish Coordinates again but on Tiny House B and used the name Tiny House B Location 1 when the dialog appeared. I'm ready to return to work on my Tiny House A design. I clicked Save so I can close the Master Site project. The following dialog appears twice, once for Tiny House A and the second time for B. This is confirming that I want to commit the location and shared coordinate changes I made while using Publish Coordinates. I clicked Save each time (2x), the top option in the list.

It is necessary to make sure others are not working on the Tiny House A or B now. The Save will fail if someone is working on them. Just ask them to close the project for a minute. When worksharing is involved the same is true but it is a bit more forgiving. Either way, if an error message appears you need to ask others to stop working on these files briefly; they need to Save and close them. Once my Save is completed they can get back to work.

When I open Tiny House A I find that the Site plan is oriented to True North. I changed the Orientation parameter to True North earlier (noted in the image at the beginning). All plan views in the stock templates are assigned to Project North, including the Site view. Changing it meant that I'd see the results of using Publish Coordinates immediately, or at least as soon as I bother to open the Site view. The reality of this is that the project is NOT altered materially, no physical change to any geometry, it is just oriented correctly based on my actions in Master Site. This trivializes the task of re-positioning a building on site, if that becomes necessary.

Taking things a little further, each Level type has a Type Parameter called Elevation Base. It can be assigned to either Project Base Point or Survey Point. When I change this to Survey Point I find that the levels are reporting elevation values based on how much I raised Tiny House A in the Master Site file.

Now I've decided I want to be able to see Tiny House B here too, for context, but while working on Tiny House A. I linked Tiny House B into Tiny House A using positioning: Auto - By Shared Coordinates. This is possible because I used Publish Coordinates, from within Master Site, on both Tiny House A and B. Their shared understanding of their position in Master Site makes it possible to link either file into the other using Auto - By Shared Coordinates and they land in the correct spot relative to each other.

I can also link Master Site into either Tiny House A or B and use Auto - By Shared Coordinates too. They all understand their relationship to each other because of Publish Coordinates and the work I did in Master Site to put them into the proper context with each other. Here is Tiny House A, with Tiny House B linked in. I also created a Toposurface and Building Pads for each house in the Master Site file, then I returned to Tiny House A so I could link Master Site in using Auto - By Shared Coordinates as well.

A Few Notes

• Master Site is in CHARGE of positioning
• Only move models in Master Site
• Do not move linked models when viewed in other related project files
• Acquire Coordinates created the relationship between Survey and Master Site
• Publish Coordinates created the relationship between Master Site and Tiny House A and B
• Respect this order and it is easy to maintain
• It is technically possible to manipulate the relationship in either direction, DON'T.
• You must Resist the temptation!

Multi-Discipline Comments:

• Trades link the Tiny House A and B models into their projects using Auto - Origin to Origin, nothing else.
• Do NOT start work without a preliminary model of the Tiny House. If you do, be prepared to move your work into alignment manually.
• It is only necessary to use Acquire Coordinates on Tiny House A or B (whichever house you are designing for in your project file)
• It is only necessary to use Acquire Coordinates IF there IS an expectation that your data must align in 3rd party software like Navisworks
• The Tiny House projects will link your models using Auto - Origin to Origin too

Use the Front Door

I find myself looking for metaphors as I help people learn Revit. We rely on them all the time, work them into our speech without even thinking about it. Lately I've settled on another to describe the various ways Revit lets us do things. There are usually at least a couple ways to start something or solve something in Revit, like life.

I'm frequently asked which "way" is the best or the correct "way". It seems to me that Revit provides any number of "doors" to access information and tools.

Let's take the notion of working with materials. I have a desk and I'd like it to have a specific material. These days I can select the desk, click Type Properties and, assuming the person who made the family provided a parameter to manage its material, I can click on the material value, which exposes the sneaky "Browse" button. This is a "side door" that lets me select and possibly alter material settings. If I don't find a material I want I can make one while I'm here, click my way back out of the dialog and have a desk that looks great (hopefully).

In the past, if I didn't like the material and there wasn't one listed that sounded like one I wanted I'd have to bail out. Once out of the family's Type Properties I'd open the material dialog and create it. Then I could go back to the desk and assign the material. They created the side door access so we could avoid that inefficient back and forth process.

I run into people that think the side door is the only way to create materials. That's how they learned to do it and they keep doing it that way. The "front door" for materials is really on the Manage tab, the checkered globe button. This front door is the administrative task minded entrance while the side door is more the "spontaneous task" minded access point.

Another example is changing the number of a sheet. We can select the sheet view name, right click and rename. We can open the sheet view and select the title block family which in turn let's us select and edit the sheet number. We can select the sheet number parameter in the properties palette too. Then again we can deal with it in a schedule instead. Keeping count? That's four "doors", a front, side, back, and "secret" door to accomplish the same task.

That might seem like too many options, which one should I use? Easy, which one is the closest to you? Where are you? In the back yard? I'd pick the back door then. Not in a sheet view and needing to renumber a bunch of sheets? I'd pick the "secret door" and use a schedule.

Nearly everything you need to do has at least a front and back door, and very often more. Pick the one that best fits your circumstance. When one door closes another opens...or something like that...

Projects with Shared Details

These projects typically have "standard/common/shared" details AND "specific/custom" details. It's a pretty common question, "How do I manage the shared details?". In an earlier post I wrote about the Insert Views from File tool that Revit added several years ago. The overall strategy I like boils down to this list:

• Do all the detailing that they share in "one" project
• Do all the detailing that is shared in Drafting Views, not model "live" views
• Use Insert Views from File to pass them to the other projects.
• This allows for local view referencing of callouts/sections etc
• Do all shared detailing in the "master" project
• Only worry about keeping the sheet and detail numbering updated between all sheets
• Don't bother to update the details in each other project, the views could be blank for that matter (except for a piece of text, has to be something in the view)
• Print all shared details from the master
• Strategically use a separate sheet numbering scheme for shared details so they don't compete with project specific details.
• Only necessary to manage sheet reference and detail numbers during the course of the project and add new shared details if they arise.
• Easiest when detailing is done in later stages of documentation naturally

I think that it's easy to miss that it isn't really necessary to put "finished" details in all the other project files to keep them "up-to-date". The only thing we need to keep "up-to-date" is the sheet number and detail numbers, assuming that detail sheets are printed from the master project instead of from each individual project. That's why I suggest a separate sheet numbering scheme for these shared details, so they don't compete with the rest of the set.

Is a Single Model Viable?

I have a couple clients that have done this with some varying opinions on how successful it was.

Pros:

• Great to have live interaction between trades
• Issues were much more obvious and forced resolution sooner.
• Less linked file updating issues Helped minimize copy/monitor and redundant content

Cons:

• Plot day conflicts between trades, arch printing for meetings and MEP trades printing offset and difficult to have teams "stop working" long enough in advance to freeze development of the model so trades could "catch up" with design.
• Performance...fairly obvious...file sizes became an issue so only really feasible on modest sized buildings
• More worksets required, more views etc... browser became difficult
• Warnings increased because everyone had to "see" other trade warnings

One outcome from attempts was the less obvious choice to merge A and E models, they shared one model for Arch/Elec because so many devices were "redundant" in separate models. This put A/E staff in the same model so they could share lighting and devices etc. Kind of obvious logical pairing but not as obvious to think of initially.

A truly single model can work but project size and the way teams interact can greatly affect how much "fun" it is.