Parts&Families Management Rant

Robert::

Perhaps I am not interpreting your comments correctly, but I believe that a large amount of your complaint (#1) is solved in V8i with Family/Part Concatenation.  The screen capture simplistically captures concatenation where a part "CMU" exists in the family "Wall Leafs" at both the project and corporate level and the project settings over-write the corporate.  The blue "Wall Leafs" indicates that a part from that family is defined elsewhere, and the red "CMU" indicates that the part is being overwritten by a part definition at an other level.  If you are not familiar with this and would like me to elaborate just reply indicating as such and I will go into further detail.  

I hope this helps,

Travis

The problem is it is still too compicated  

The terminology does not even match educaton.  I never heard of a wall in any architectural school but I do know what a wall is and a wall assembly is.

I don't know what you think is too complicated?  Steps... 1. Copy part from corporate level  2. paste into project XML 3. make changes to part setting as needed  4.  Commit changes.

If you are being critical of the names of the families in the screen capture that is just one workspace (not Bentley's delivered workspace) and you can call them whatever you like?

I don't know what you think is too complicated?  Steps... 1. Copy part from corporate level  2. paste into project XML 3. make changes to part setting as needed  4.  Commit changes.

If you are being critical of the names of the families in the screen capture that is just one workspace (not Bentley's delivered workspace) and you can call them whatever you like?

I gues I am lost to a need for a project level unless you are looking for less parts to scan through.

Otherwise why not a growing group of parts that will evolve into something for all new projects.

Otherwise you spend time copying from project and recreating the wheel.

I have this need as some clients require client-specific deliverables (not just particular gov't clients, but others) AND they have model deliverable needs as well.  They don't want a jumbo-all-encompassing dataset of every part I've ever created.  They just want theirs.  

If all you have is a 2D or a PDF deliverable, your single growing-group parts may work.  In my world of multiple offices, synching part libraries, model deliverables, etc.   Project-based libraries are crucial and integral to the workflow.

Echoing Shawn's comment.  Firms that have any of the following: multiple offices, studios, divisions, or project types would want Family/Part concatenation.  There are certain parts that can be standardized for all project types and those would be your Corporate standard families/parts.  Then there are parts that are project type specific.  You wouldn't want the same parts for designing a hospital as you would for designing a manufacturing plant.  There are specialized wall types for prisons/institutional buildings that not everyone would want in a corporate mega-dataset.  There are also cases where 1 project might want to show data differently from other project for one reason or another, concatenation allows that.  In most cases, there will not be a single solution that fulfills every need.

-travis

I am aware to the concatenation effect, but I've had mixed results as to whether the correct "version" of a part is being picked up without glitching. A bentley consultant subsequently indicated it was a bad idea having two parts with the same name. So we switched to having general users looking at the local project parts only, and an "admin" user who could see both part libraries to copy / sync parts.

My real issue in the mixed ofice/project dataset is that when selecting a part there is no way to see if that part is an "office" part or a "project" part - seeing all parts is useful, but using just project parts is what I'm after.

If a user does select an office part it needs to be automatically added to the project library - perhaps with some sort of indicator showing whether it is in sync with the office version.

I ended up creating a "configuration level" between site and project where we have like-type project standards (what I call "Facility")  We load Facility above Project, and then load a Project Part Library at the Project level.  Project Libraries have the Project Code for that Project (usually the Facility name, not our internal number, which means nothing to the owner), and then we add the Project Parts as necessary.  Our template Facilities setup and our Template Project Setup are easily editable via an XML editor (like Notepad++).

Once the project is over, we scrub the Project library for content that should be "promoted" to the Facility, so everyone working on that type of Facility in any of our offices can benefit from the content.

Works for us.  Maybe something similar can work for you.