SharePoint V3: When To/When Not To Use Content Types

Content types allow you to structure documents and list items in a SharePoint portal. They give the functional ability to define and enforce uniformity throughout a portal. There is no question that content types greatly enrich SharePoint as a content management product. However, in determining when to use content types in a portal, there are several considerations.

Desire
Is there a knowledge management champion who can coordinate the effort of unifying a business unit or entire company?

Executive Sponsorship/Authority
Do the resources who have the desire to standardize content also have the authority within a department (or broader scope) to make descisions and execute changes (or the backing of an executive sponsor)?

Culture
Is there a sense of unity amongst business units or are they segmented?
Are the business units of the organization integrated in their nomenclature (or even individuals within a business unit)?
How easy is it to communicate ideas accross business units or within a buisness unit?

Resources Allowed for Design
Does the organization have the people and intellectual bandwidth, and focus to figure out how to categorize document and list types, provide name for content types, determine format of each content type?

Governance
Is there a system of checks and balances, perhaps a design committee, in place for change management to ensure that pros and cons have been properly weighed prior to making design changes?

Organizational Adoption
Will the producers and consumers of the content accept a consistent structure for their content, or will they shy away or complain about it?
Will the users understand the content if it is categorized?

Skill
Are the content producers and their supporting power users familiar with SharePoint enough, and trusted enough by peers to create content types, associate templates, and add the content types to libraries?

...these represent some of the overarching ideas that come into play when trying to determine when to use content types.

Here are some of the technical considerations:

Site Structure
Does the portal design include one site collection or many?
Do the content types span accross site collections?
Content types work well within a site collection. But, when your content types span several site collections then it becomes a little tedious keeping the content type definitions in synch with each other.

Portability
Since templates and site exports (.cmp) can rely on content types, which means you need to set up the content types on multiple site collections.

Orphaned Data
Custom List or Document Library W/Multiple Content Types + DataSheet View + Unique Columns on View = Users can apply values to metadata columns that don't actually exist for a content type, and the metadata actually gets stored (no hard damage, just not clean)

Benefits of Content Types
* Allows you to name types of content
* Makes consistent metadata structure for each type of content
* Allows you to associate a unique document template
* New button shows the name of the content type instead of generic New Document or New Item
* Allows you to define parent/child relationships, allowing you to create a logical tree structure for taxonomy design
* Allows you to easily provision a new custom list or document library, the columns are already defined in the content type, just add the content type
* IE Script Error (mentioned above)
* Orphaned Data (mentioned above)
* No easy way to synchronize accross site collections (can use PowerShell to export/import)
* No security gains, not able to secure content types, still done at item or library level

Site Columns Without Content Types
* Great middle of the road, save time by predefining columns in a site collection, but avoid some of the technical issues with content types
* Limits you to one document template per library (back to the generic new button)
* Limits you in that all items or documents in a list or library now must have the same columns as each other