2 ways to design SharePoint Taxonomy for an organization

Organizations brave enough to venture into the world of structured content and metadata-based content organization face an important decision in the early stages of SharePoint implementation. How to properly design and develop the company taxonomy? Should the metadata be developed internally (in-house) or should the taxonomy be acquired from 3rd parties and be specific to the industry? There are two ways to design and roll out a taxonomy for an organization. Below, I would like to list both options and explain pros and cons for each.

Option 1: Top-down design

The obvious way to implement and take advantage of structured taxonomy would be to implement a company-wide taxonomy from day one. This requires that you develop metadata and content types plan across the whole organization before you start using your taxonomy. While great in theory, this is very challenging and in practice. Development of company-wide taxonomy requires company-wide participation. That means that all departments need to be involved in the development of company metadata and content type strategy. The challenge with this approach is quite obvious. Getting everyone together is a challenge by itself. Moreover, the whole concept of metadata and content types is almost always new to most in early stages of SharePoint implementation. So asking departments to categorize their content, develop metadata tags and content types might seem like learning Greek to many.

To mitigate this challenge, you may purchase or acquire industry-specific taxonomies from various taxonomy vendors. While this will sure get you ahead on the development of your Term Store, and will give you lots of great ideas on the potential structure of your data, this will not help you with the development of content types and categorization/tagging of your actual content.

Option 2: Bottom-up design

The other way to develop company taxonomy in SharePoint is to use bottom-up approach. Essentially what that means is that you develop your taxonomy as you develop your sites and migrate content to SharePoint. If you have read my previous posts, you are then familiar with my Agile/phased implementation approach. This bottom-up taxonomy strategy follows the same logic. Say, you are migrating Human Resources content first. As you develop the sites and document libraries, you create metadata. Some metadata will be local or department specific (i.e. HR document types), while some will be company-wide/global (i.e. Department Names). Both might end up in the Term Store and will be the first steps to company taxonomy. As you continue to roll out other sites (say Finance, IT or project sites), you might take advantage of the company-wide/global metadata already created previously. And so on. You get the idea. At the end of the day, you will end up with your company-specific taxonomy that can be used and reused by various departments and types of sites.

Recommendation:

Being a strong proponent of the Agile approach, for most cases I recommend the bottom-up approach. It makes the most sense and is easy to “wrap the head around” and implement. Acquiring industry-specific taxonomies from metadata vendors might make sense for very structured or regulated environments (i.e. medical research), but at the same time requires that the whole company is on the same page regarding content categorization and structure. Factors like company culture and company size factor into the final decision as well.