How to build a successful SharePoint taxonomy

Avoid common pitfalls and build a SharePoint taxonomy that will last, with core business functions as the foundation.

Taxonomy, frequently referred to as the information architecture of your site, is often the most visible and most important method for SharePoint users to locate information. But SharePoint implementers often rebel against that fact because SharePoint is considered to be a top-notch search platform. 

Why should users rely on a site map and menus to locate data when search is faster and more reliable

The reality is that many users do focus on the site taxonomy first and use the search capability second—if at all. Because of that, taxonomy plays more than one distinct role in SharePoint governance. In particular, taxonomy addresses site taxonomy (navigation) and content types (data). Your governance plan needs to cover both. 

A SharePoint governance plan should treat taxonomy very seriously. When building out your SharePoint taxonomy, consider that site taxonomies typically serve the needs of these two core business principles: 

  1. Permanent departments and business functions
  2. Ad hoc collaboration

Of course, there’s no such thing as “permanent” business these days, but there are core business functions in every organization. If your company doesn’t know its core business, focus on that before jumping into SharePoint. 

Ad hoc collaboration taxonomies provide a site map for a wide range of project types. Some projects are short in scope and duration, lasting a month or two. Others are long-term projects that run a year or longer and involve multiple departments. Let’s consider when and how to use each in a SharePoint installation.

Permanent departments and enterprise business functions

Many companies begin designing their site taxonomies by printing out the current organizational chart and then proceeding to create a SharePoint site taxonomy based on that chart, mapping each box on the org chart to a SharePoint site. This is a mistake. 

There is a lot of useful business intelligence in an organizational chart, and some of it will help you create a good taxonomy for your SharePoint environment. However, there is also a good deal of misleading information in the company org chart

Org charts are frequently out of date, sometimes political in nature and change quickly. How can a Share- Point administrator tell the difference between a permanent department or business function and a transitory superficial department? 

You know your own company best, but consider these general rules and examples:

  • Human resources. Every company has an HR department. This is a clear choice for a permanent department and a first-class member in the site taxonomy. 
  • Finance. Every company sends invoices to its customers and pays bills to its vendors. So it almost always makes sense to create accounts receivable and accounts payable sites and promote them to first-class status in the site taxonomy. Many times, the top tier in the taxonomy would be “Finance” with accounts payable, accounts receivable and possibly other sites underneath.
  • Products. Just about every company deals in some sort of product, so that, too, is a great example of a core business function. Yet there is rarely a product department. Instead, Product in the taxonomy would be a high-level container for the company’s efforts at product development, production, support and the like. The details will vary from company to company, but the core concept remains the same. 

A transitory or superficial department doesn’t have the staying power of a permanent department like human resources or a business function such as finance. They are often obvious from the org chart, and common sense will weed them out. 

However, like weeds, they can reappear over time. Often, the members of a sub-department, such as product marketing for a specific product, feel their role in the company is so important that their organization should be accorded the same first-class treatment and location in the taxonomy as the finance and HR departments. 

Personalities can drive this more than real business need. A well crafted governance plan that explains and justifies the taxonomy goes a long way toward preventing this kind of hijacking attempt. 

The core objective of this part of the SharePoint site taxonomy is to provide an intuitive, clear path for employees to follow when they are seeking information. Aligning your taxonomy with core business functions and permanent departments will go a long way in achieving this objective. 

In the scheme of SharePoint governance around site taxonomies, defining and managing the permanent parts of the taxonomy are fairly straightforward and represent, for the most part, a one-time effort. Core business function taxonomies require relatively little care and feeding over time and provide a regular real-world aspect to the taxonomy. Long-time employees will know exactly where to go for information, and new hires will quickly learn the ropes of your organization by navigating around your SharePoint environment. 

Using ad hoc site taxonomies 

Ad hoc collaboration is another matter. Assuming you’ve determined your core business functions and aligned your site taxonomy in support of those functions, answer this: Where would you add a project in SharePoint that focuses on streamlining sales expenses for a new product that requires a great deal of support from the technical services department? 

This is just one example of projects that vary from day to day, department to department and that cross business boundaries. As a result, they don’t fit well within the core business functions taxonomy. 

The answer is to embrace these kinds of projects in the site taxonomy and to make “Projects” a first-class member of site taxonomy. 

This addresses certain real world issues: 

  • Security. Projects that span departments require unusual security in the sense that it’s specific to any particular project. A project whose members come from finance and manufacturing can’t use finance’s security model or manufacturing’s security model. By separating projects out from either finance or manufacturing, you create a clear separation of security that is unique and easily managed for that project.
  • Turf wars. Using the above example, one could ask: “Who owns the site? Finance or manufacturing?” This could lead to a clash of personalities. Avoid that problem by creating a separate tree in the taxonomy just for projects. That way, no department owns the project in “its turf.” 

It’s difficult for guidelines to go much further than separating projects from core business functions. However, you will almost certainly want to refine this part of the tree. Consider refining it down into short-term and long-term projects. 

Don’t be one of those companies that builds out a SharePoint environment, then gets the user community on the hook and then finds itself a year later with a creaky, inefficient and frustrating site map that doesn’t make sense to anyone except the SharePoint implementation team. 

Build your site taxonomy around core business functions, but prepare yourself to welcome inevitable growth. Core business functions serve as the foundation for your SharePoint taxonomy. Ad hoc collaboration sites for projects and other temporary needs allow the system to let off steam and grow in a controlled manner without being overly controlling. 

About the author
Paul Galvin is a Microsoft SharePoint MVP and a SharePoint solutions architect at EMC Corp. He has worked in the IT industry for more than 15 years in areas such as software development, consulting and SharePoint solutions design, where he works with clients to create business solutions using the SharePoint platform. Galvin contributes to the SharePoint community through MSDN forums and his blog.

Dig Deeper on Enterprise SharePoint strategy