Best Practice: Shared Parameters

[cboggild]

Hi all

These days I'm wondering about some Best Practice regarding Shared Parameters.

As some projects might request project-specific Shared Parameters, I'm thinking whether to have project-specifc SP-files or going on with one, single file - perhaps with groups for each project and common parameters to be used in general? I'm in the middle of implementing Revit in our office (150+ employees), and as more and more stuff will be done in Revit, things might get kind of messy with only a single SP-file. Furthermore this could become an issue in regards to archiving and doing backups.

I'd love your oppinion on this.

Christian

[jsteinhauer]

The most important thing to do is to get all of your standard parameters(SP) identified and placed into one SP file. These would be any firm wide parameters that you use for scheduling and tagging. You can divide up the shared parameters file into different groups. This is helpful for people building content, so they know, 'Hey I need to load all of the parameters under the Door Group into my door family'. But, they may also need to understand, 'I may also need to load parameters from the General Group as well'.

We have one large SP file that was started by our reseller. We have added parameter groups as needed for the way our firm works. We then put this file out on our network, in a location that staff can read, but not write to. If parameters need to be added, there are two people here that have write privileges to that file. If a team needs custom parameters, they are encouraged to review the standard SP file first. Then if they can't find a parameter that will work, they can create one in their project specific SP file.

It's better to get this done correctly then quickly.

I hope this helps,
Jeff S.

[DaveP]

You're going to run into big trouble if you try to have project-specific files.
Sooner of later, someone is going to create a parameter with the same name in two different projects. And before long, both of those are going to end up in some other project.
Once you've got two different parameters with the same name, it gets REALLY confusing.
Plus, if you ever need a parameter from one project added to a different one, it is possible, but dangerous.

[cboggild]

The most important thing to do is to get all of your standard parameters(SP) identified and placed into one SP file. These would be any firm wide parameters that you use for scheduling and tagging. You can divide up the shared parameters file into different groups. This is helpful for people building content, so they know, 'Hey I need to load all of the parameters under the Door Group into my door family'. But, they may also need to understand, 'I may also need to load parameters from the General Group as well'.

We have one large SP file that was started by our reseller. We have added parameter groups as needed for the way our firm works. We then put this file out on our network, in a location that staff can read, but not write to. If parameters need to be added, there are two people here that have write privileges to that file. If a team needs custom parameters, they are encouraged to review the standard SP file first. Then if they can't find a parameter that will work, they can create one in their project specific SP file.

It's better to get this done correctly then quickly.

I hope this helps,
Jeff S.

Thanks for your input.. that seems reasonable.