Standards in multi-office firms

[dbaldacchino]

This question is really intended for those that work in large firms with more than one office.

Do you centralize your firm's content on one network path available to all offices, or do you replicate the content to each office individually? Do you have a dedicated server just for this and/or for Revit projects?

Thanks for sharing!

[sbrown]

We currently replicate but are looking into better library management solutions.

[dbaldacchino]

Thanks Scott. Do you mind sharing some of those that you're looking at?

We have recently decided to make the switch to 100% Revit (in theory) over the next couple of years. Since we have multiple offices and our resources will be scattered among them, we need to make sure we don't end up spinning our wheels and duplicating effort. I'm curious to see if anyone has attempted centrally locating content on a server path accessible to all offices or what other solution has worked or not.

[greg.mcdowell]

We also have an affiliate structure spread over several states.

One thing that we think is important (we the "users" that is) is to have Office, Project and Individual "standards" in addition to affiliate standards. Our CAD Managers haven't always agree but the reality of it is that each office, team and person does things a little different than another and we should work to identify systems that work to better that instead of deny it.

I think that where we will end up is to have Revit point to an office specific location for files that has links (shortcuts) to affiliate, project and user (though this last bit seems less important in Revit than it did in AutoCAD) folders.

The trick is to figure out how to disseminate the knowledge gleaned in one office, one team, to all the others so that the solutions can be improved and utilized by everyone... or not used if it is deemed inappropriate to the office or team.

As an example, I've begun work on a template file for our office to solve problems that I believe we'll have. I posted this to our affiliates and several of them seemed content with the template that our CAD Manager had created (which to my eyes was woefully inadequate)... and that should be okay.

[dbaldacchino]

Thanks Greg. We probably will not have a central "Cad Manager" in on eoffice but actual users as office representatives that will meet, talk about standards and work on templates, families, training, etc. I think I like it better as these power users will be also doign project work (in the trenches). With our first few projects we've accumulated a decent amount of knowledge and content/methods that should suffice for 80% of the needed content. If in the future we want to start using a product like E-specs, user created families wouldn't be a great idea as they will not contain the right information.

I might be wrong, but I'm of the opinion that if the content is easily available and works, users will tend to use it and not create their own. I created my own stuff because it was impossible to find something or it wasn't done correctly. I agree that there will be cases where the available families don't satisfy some requirement, but we're hoping that with power users in each office, we'll be able to maintain a good company "standard".

[DaveP]

We don't exactly have multiple offices, but we do have a partner in Malaysia that we share work with. (Management insists we're not out-sourcing - we're sharing work :roll: )

Anyway, we've got a Steelhead appliance from Riverbed Technologies that optimizes and replicates files on both ends. We do synchronize our families from our office to theirs, and we've experimented with a Central file located in our office that they work on. Haven't actually DONE a project that way, but our experiment showed about a 20% speed hit through the Steelhead.

We tried an AutoCAD project through the Steelhead, but AutoCAD (2002-based) is extremely chatty on the network & was far too slow to be usable. Revit was somewhat slower, but we decided it wasn't a killer.

[dbaldacchino]

Thanks Dave.

Do you have someone in charge of content creation/standards? I can see how it might be a problem if content is created/edited by users haphazardly in one location or another and those changes (some perhaps not expected) will get replicated everywhere...."bad" stuff could spread like a virus hehe. And oh, that's "collaboration" with another office, not outsourcing :roll:

[sbrown]

I'm not the one researching the options. I'll see if I can find out what they are working on. Archvision has a management tool that maybe the basis for a content manager.

[mccurdyks]

We've got a similar situation with "power users" in each office rather than a central CAD manager. We also have the steelheads mentioned above and have just completed a project as a collaboration between offices with a 130Mb file, with a site and structure model linked in, as well as about 50 dwg files. Lessons learned...

If you're going to centralize the library, keep one as the base and have that published to the other sites. We localized our library at one office and got bit when things went down at that office when we were working on separate projects.

Problem is you take the same risk with the central file itself when working between the offices on a single project. When there are server issues where the central file is (which is always not where you're at), folks in the other office are out of luck. Another related issue is when people don't relinquish, you can't just go over to their machine and do it for them. You're at the mercy of the other office, which can be bad in the night/weekend crunch. Look carefully at how you might break the project into separate models at each office to avoid this.

Coordinating save to central times is crucial. The file will not be happy if multiple users in different offices try to save at the same time.

Links will be an issue if you don't actively link a central repository of linked files. The relative path will always be wrong in the "other" office where the file wasn't initially linked. Another good reason to cut the cord with Autocad.

There are others. But these are the biggies.

[dbaldacchino]

Another related issue is when people don't relinquish, you can't just go over to their machine and do it for them. You're at the mercy of the other office, which can be bad in the night/weekend crunch.
Well this shouldn't be difficult because you can get to the central file with the offending username and relinquishing (the user will lose their changes). But I think with some planning this shouldn't be an issue. I'm using a simple directory structure right now:

Folder "Revit" with two other folders in it: "Central file - DO NOT OPEN" and "Local Files". In Local Files you would have each team member's folder titled with their username. The local files would then be projectname_username.rvt and the central would be projectname_CENTRAL FILE.rvt.There's less confusion and even local files are always backed up and on the server. If someone forgets to relinquish, we can open their file with their username and STC. Then we'll put a bounty on their name :)

[Steve_Stafford]

Fwiw, put the local files on the user's PC's not on the server. Put them in a folder anyone can log into like C:RevitProjects. This way you can access their local file if they didn't relinquish properly even though you log in as yourself. Files that are in My Documents can't be accessed unless you have adequate network permissions.

There is no real strong benefit for putting local files on a server, only detrimental performance issues. They don't need to be backed up nightly because between the backups the central file creates and those the locals create you have redundancy coming out your ears...T

The only compelling argument I've heard for putting them on the server is if the servers actually are so high end that the PC can't dish out the data quicker than the server, but that isn't very likely often and more than likely the PC's won't process the data fast enough to make it tolerable?

[dbaldacchino]

Steve, you have an absolutely valid point....no real need to back up the locals. Here's my reasoning for deciding to put them on the server....

The fact that we set a user folder in the project folder means everyone knows who's working in that project in Revit at a glance. If someone does forget to relinquish, it's easier to just get in their local from your own PC or wherever you might be. We set the backups of locals to a low number as it's not necessary to keep a lot of them.

The second reason is that IF the central corrupts and we're in a bind, all of a sudden the latest local becomes a potentail new central. And yes, it's difficult for a all user's PC disk to fail at the same time, but you never know which one and we don't want it to be the one with the latest local.

The other reason we 're currently doing it this way is that Revit is unique in the way it works with central and local files. We don't want users to use this as an excuse ("I got confused") to put project graphics on their drive, or Excel sheets or whatever other software file. The C drive is a dangerous place to be. We've had an instance where the entire spec of a project was on the C drive and a few weeks before the project goes out, guess what? Yep, Murphy's law....and we lost it all.

So while your points are very well taken, I think there are other not-so-direct reasons for opting to put locals on the server. Thanks for your point of view....keep them coming as they help us test our decisions!

[cstanley]

currently in our office, we've created a "community" folder within the delivered content. in other words, we have placed the community folder directly in the imperial library, and within that folder is the imperial directory structure duplicated. this is where our built/modified/custom content goes. the rest of the imperial library has read only access for the users.

we had tried having project-specific content located within the project, but that's a content-maintenance nightmare, plus no one knows where to get what, and we end up with a crapload of duplicated content.

now, all offices can reach and develop one main content libray, while maintaining the integrity of the original files. perhaps not the best way, but it'll be easier to adjust later if it's all in one place instead of trying to cobble together the most correct versions of content spread all over the network.

[dbaldacchino]

Thanks Stanley. I think we're going to try have a central location where a group of people in a committee/council will be in charge of content and then we'll replicate this folder to the other servers on a set schedule. Centralizing content is essential because you can control part of the project quality by having accurately built components (for example toilet stalls with all accessories and required clearances etc.). This becomes paramount I think if integrating spec software such as E-Specs etc.

[gdasher]

I have our content, OOTB and custom, setup on a central server in the corporate HQ. I have the content folders secure and can only be added to by myself or a handful of users capable of reviewing content to ensure it is correct.

As for the replication, we use Storage Server 2003 which handles our content replication between offices.

[luigi]

Man.... I got sucked in this "revive the old thread Game"....

ouch!


In my office we keep the local file on the C: drive. I wouldn't have it any other way. just my 2 cents...

[gdasher]

Man.... I got sucked in this "revive the old thread Game"....

ouch!


In my office we keep the local file on the C: drive. I wouldn't have it any other way. just my 2 cents...Sorry, I was searching and in a hurry, so I did not look at the date. Guess you could say I got sucked in too.