A BIM manager for a large concern should would work closely with the information system programmers to manage the “i” in BIM. My personal preference for managing Revit type catalogues would be through a database programs like Microsoft Access.

SQL Server and Visual Studio may also be used.

However, in practice, the go-to program is Microsoft Excel. Most people know how to use it, but it does not set up a relational database, and it makes managing data a little more challenging in that the user must be pedantic about keeping the structure of the spreadsheets correct.

Type catalogs may be useful in a variety of circumstances, but primarily I will focus on the need to schedule costs associated with updating or replacing components within a Revit (BIM) model.

• Large retailers typically redesign and update their stores once or twice a year. This may apply to hundreds of stores.
• Large project may have to be updated with pricing as time passes.
• An existing design may have to be priced at any one time.
• A plan view can be used to position rudimentary families but information can be extracted presently through the use of shared parameters. Later the geometry in the families can be updated while the information stays intact.

It might be tempting to share in other families and to tally them in schedules

• Because of the sheer number of shared families the primary family may balloon in size.
• The physical model will correlate to that which is scheduled, but there may also be the need to schedule components that were not actually modeled (fittings and labor).
• It is not possible in Revit to infer the host of the nested families, and this may be important to someone that needs to mine the data.

While an argument may be made that the information should rather be managed in Autodesk Navisworks, neither the software licenses nor the skills may be immediately accessible.

One of the instances where Revit type catalogs would prove troublesome is where costing is managed across a number of phases (across which prices for similar components may vary). A solution to this is to create families for each phase so they may be priced separately.