Every loadable family exists as "[name]_TYPE" and "[name]_INST"-company stategy

[pipapongo0909]

Hi Forum,

In order to explain the difference between Type and Instance to my users i created an example of a structural column family.

The first is named "structColumn_rect_INST" and is has a width and height parameters setup as Instance parameters.

There is only one type in this family since it can be changed by the instance parameters from the properties browser

The second is actually a copy of the first wher i changed the parameters to be type based. i created several types e.g. "20x20cm" ,"25x25cm" ,"20x30cm",.......  

This gives the users the advantage, that if they need to change only one individual columns dimensions, they change it to the "structColumn_rect_INST" family and edit the parameters.

Actually i do not want every user to mess with "edit type" because this could lead to

• changing all the already present columns in the project if they change it and forgot to duplicate first
• unconsistent naming "200x200mm", "25x25cm"
• or even with unconsistent families concerning name and dimensions where the dimensions where changed but it was not duplicated nor renamed.

unfortunately this logic is only apliable to loadable families, so with the system families they need to do it themselves or my phone will be ringing constantly.

So we setup a bunch of rules:

1. Use the company's families only ( actually we prefix all our families and parameters with the company's initials)
   if there is none: call and we will provide it.
2. do not use "Edit Type" with loadable families and no not enter the family editor --> call and we will provide it
3. if the type you need is missing from a company's system family
   • duplicate it
   • set the parameters
   • use the SAME naming convention that was used for the other types
4. if you really really need the family and create/duplicate it but PREFIX it with your initials ( unique)
   this gives the possibility for the person in charge of family management for checking it and providing it afterwards as a company approoved family

Actually this is the current strategy for making sure that we will be able to deliver a good project and to create an approved family catalog with time

What do you think? 

is this too strict?

Please share your opinion, i can load an xx_INST and xx_TYPE family up when i am back in the office

thanks a lot

[Joris.vd.Meulen]

Hi pipapongo0909,

Too strict? In my opinion it is. Mainly because I sense a lack of trust towards your people / unable to explain the difference between type and instance properly (read in a positive way plz). (don't know the amount of people in your company)

Explaining the difference between type and instance isn't done by providing families but by word / paper / examples. If people understand the difference working with them isn't a big deal. Understanding when to use instance and when to use type is way more important.

- Providing several families: yes! The more the better. and the more you have the more you know its quality is awesome.

- type ones AND instance ones: sure if needed

So I (we) do have instance families AND type families which are used as they are best suited. For example: we have a kitchen with a instance length and a family which has a type length. In de preliminary design we just want to show a kitchen: instance. If we have to create a shopdrawing (or so) we go type. But again: heavily based upon project / purpose.

If we -as an architect- place a column and the structural design isn't set yet: we use and instance generic column. If things are known: we replace them with the type-specific-ones (or the structural design is a seperate model 🙂 ).

- Naming them in certain way: yes!

- if people come with nifty families / better ones: embrace those ideas. 

- let people use edit type. but DO explain the need of doing it properly (changing a wall's thickness means changing its description, type name etc).

- create a way to control your data. Clashing / testing / creating special 3D views. IF people make mistakes (and we are all people), you want to be able to check and correct.

(we use solibri model checker for example)

[pipapongo0909]

Hi @Joris.vd.Meulen,

 If we -as an architect- place a column and the structural design isn't set yet: we use and instance generic column. If things are known: we replace them with the type-specific-ones (or the structural design is a seperate model 🙂 ).

- Naming them in certain way: yes!

- if people come with nifty families / better ones: embrace those ideas. 

- let people use edit type. but DO explain the need of doing it properly (changing a wall's thickness means changing its description, type name etc).

- create a way to control your data. Clashing / testing / creating special 3D views. IF people make mistakes (and we are all people), you want to be able to check and correct.

(we use solibri model checker for example)

thanks a lot for your reply. I really appreciate your honesty.

You are absolutely right that "the lack of trust toeards my people" is not a very good starting point. The reason for this is that the project is technically ( all software used, deliverables = [model.rvt; model.ifc, Sheets] ) way over what we were used to do so far. Meaning that the BIM Handbook is still in production. The modelers ( and myself as well) are not really experience with Revit so my fear is that somewhere on the way things get out of control.

For long term this is not the solution, but for now i think i will need to this strategy until there will be time for propper training.

---

- Naming them in certain way: yes!

- if people come with nifty families / better ones: embrace those ideas. 

- let people use edit type. but DO explain the need of doing it properly (changing a wall's thickness means changing its description, type name etc).

---

I totally agree.

How do you deal with "Oject styles" and "Materials"

Object styles are a no go for the users and i put a material lib. on the server and the users shall only use this. If thy need something they call and it will be added to the project and template. I am about to introduce Worksharing as a standard so the person in charge can always add/change familes on a locol copy and as soon as the users synchs it will be available.

thanks again for the response

have a nice day

[Joris.vd.Meulen]

---

How do you deal with "Oject styles" and "Materials"

Object styles are a no go for the users and i put a material lib. on the server and the users shall only use this. If thy need something they call and it will be added to the project and template. I am about to introduce Worksharing as a standard so the person in charge can always add/change familes on a locol copy and as soon as the users synchs it will be available. 

---

Well. 

On family level: we NEVER define materials. Objects are either defined in subcategories (if needed) and by a material-parameter.

On template level: we define the basic materials (masonry 3 types to get things started, glass exterior, glass interior, concrete, sidings, etc. etc.) Those materials are used on the template elements like walls, roofs, etc.

Loading such a family as mentioned above ensures that:

- you don't import a material defined in your family (getting rid of typos, capitals, spacing etc). "Masonry", "Masorny", "masonry" etc.

- your template can define subcategories which are used by multiple families and therefor gives you lots of control.

- your family's material parameter can overrule the 'object styles' 'subcategory' material. You need yellow glass: no problem. 

Roughly how 'we' do it. Oh and we do have large 'library projects' containing 'not so often used walls, roofs etc' so your 'company style' can be pretty controlable.

Regarding the 'education' of people etc. if you are familiar with autocad (or as I: having worked with it for 10 years or so), changing to Revit is quite a leap. Not only do you have to change a 'layer' to change the appearance but a heck of a lot more. Not a biggy, just another way of working. And people have to understand it, and embrace it (eventually).

The quality of your model is important. Whát did you deliver besides the 2D-output. Is everything correct. Does it contain the information you agreed upon or does it lack some (or even worse, does it share false information). 

(Example, we don't use thermal / physical info in materials. If needed we use specific manufacturer walls).

Cheers.

[RDAOU]

@pipapongo0909

Standards and protocols to control Quality are always a must; the question is how adaptable to various projects are they. They are company standards fine but one still needs to ask or consider:

1. What kind of organization (Projectized? Functional? Strong/Weak/Balanced matrix?)
2. How big is/are your team(s)? Per project or department 
3. what skill level and qualifications do they have? 
4. What scale of projects?

Then comes the question; is it a one off standard which you want to apply regardless of the circumstances? 

I won't comment at each of the details you listed...in my opinion, in general it is nice but for a small scale project for instance, it is too strict and for a large scale too lean...whatever standard or literature you set for BIM management in general and/or content management needs to

1. take into consideration how much you would spend implementing it,
2. how feasible the implementation is and how feasible is it for the team to adapt to it; 
3. Project scale, LOD req., contract req., team structure, team members personal skills, ...etc
4. Consider that Such standards requires resources, time and cost 

Besides; if everyone ends up calling, and people tend to make it a habit easily, you will be spending more time managing the content than the actual time required to model the project