This is just a hypothetical example of a document library design required for a centralized bid management document library. The team looking after this process may separate from the Project Management Office and the Project Team.
By using this layout, you can keep adding metadata as required but it also helps to identify the commonality of metadata to different types of content.
In this example, all content types require the Recorded metadata. This could possible be systematic of a company wide policy that all important documents have a physical copy (old school I know). In this case I would create a base content type at the site collection (top level site) containing the Recorded metadata column and then have each of the content type required for this library created in the libraries sub site, inherit from the base one in the site collection. This has the advantage of allowing any future changes to the company wide policy to be automatically incorporated into the content types that derive from it.
In this case, it was deturmined that the Change Request content type would also be used in other sites even though the metadata requirements may vary across sites (processes) there are some company mandated requirements for any type of change request (I guess they have been burnt by this in the past ;-)
The next step is to decide from our identified metadata, which ones may be common to other document libraries/lists (processes) in other sites. Metadata that can be reused should be created as Site Collection Columns. Metadata unique to this process (as used in libraries or lists to support this process) should be created in this sub site.
But why define and capture this metadata in the first place?
Diagram of document lifecycle inserted here