Case for Project Parameters Addendum

Daniel Stine sent me an email to offer these additional thoughts regarding my Project Parameter post the other day. Rethinking that post I should have given it the title "A Case for..." instead of "The Case for...". It's really just one example of a decent reason to take advantage of Project Parameters.

Daniel writes:

Project parameters are set as either Instance or Type. This can limit your options later. For example, we have some families that have HP as a Type Parameter, but others (for flexibility) are set to Instance.

Project Parameters trump the Instance/Type setting of the same parameter (if one exists) in the family. I have seen this a few times, where the family has a parameter set to Type, and when it is loaded into the project is becomes an Instance parameter.

We have several Project Parameters for cost estimating in our template, they are assigned to all categories. This ensures all content, no matter where it comes from, will have those parameters. We do limit the number of Project Parameters for the reason you mentioned, that irrelevant information shows up for some families.

I am not sure if you mentioned this before, but it is really great that we can hide Shared Parameters in the project environment using the “visibility” toggle in the SP file.

My reply: Thanks! I thought I've mentioned this (hiding a shared parameter) before but I don't find a post specifically about it. I guess I need to add one or point to someone else's post about it instead at least. It isn't common knowledge so using the technique can really damage a person if they are struggling to figure out why it doesn't show up in their project.