Content Categorization – Common Categorization and Grouping Mistake

Staying in alignment with my 10 Key Elements of Enterprise Information Architecture, this article will describe a common categorization and grouping mistake I see on a regular basis.

With regards to content categorization and grouping, a common mistake I see is storing and managing all documents of similar type, across ownership boundaries, in to a single site or library. This type of content grouping considers the consumer only, not the content owners or contributors. For example, I often see a site with a single library to store and manage all corporate policy documents. Using this approach causes many issues; including:

  • All policy document content owners, across department boundaries, must navigate to the policy site/library to add, edit or delete their owned policy documents. Doing this requires them to leave their departmental content domain.
  • Because all policy documents are stored in a single location, typically custom development efforts must be applied to ensure a consistent security model. Meaning, policy document owners can add, edit and delete only their own policy documents. Such custom development efforts can be very time consuming, dip deep in to your implementation budget and require on-going maintenance.
  • Again, because all policy documents are stored in a single location, typically custom new document provisioning, document edit, document delete, review and approval workflow must be developed.

05.03.01.01 - Aggregation for Consumers
It is important to consider the consumer of content. However, long before this, you must consider the content owner and contributor. One of the top factors for implementing successful Intranets is to consider the storage and management of content first. If we don’t simplify the storage and management of content, adoption and use will be minimized.

Duplicating the approach above, now your users will need to navigate to many different locations to manage their content.  Often, I see these business owners need to maintain many bookmarks to all the various sites where they manage content. This can, and will, become difficult to manage and can reduce solution adoption.

An optional approach is to store and manage the content as close to the point of ownership as possible. In the example above, policy documents should be stored and managed in the owning departments site. This eliminates many of the issues related to a central point used to store all related documents. Storing content as close to the point of ownership as possible has the following benefits:

  • Content owners and contributors don’t need to remember where content is stored.
    • They simply go to their department site (or sub-site) and manage the policy documents they own.
    • Security can be configured such that all departmental content owners and contributors can manage the policy documents as needed. These departmental content owners and contributors cannot change any other departments policy documents; and vice versa.
  • No custom coding is necessary to support a complex item-level security model.
  • Others changing content they don’t own is greatly reduced.
  • Single source of truth is maintained.
  • Higher degree of confidence and adoption will be improved.
  • There is no need for complex review and approval workflows. Most of these can be created using out-of-box workflows or SharePoint Designer.
  • Maintenance is significantly lower.

05.03.01.01 - Storage for Contributors
I would imagine your next question will be; How do I create a aggregate view of all corporate policies for the consumers of our organization? That would be a great question and it involves simple Information Architecture techniques.

Create a Policy Document content type and assign it to each departmental document library named Policy Documents. The only type of document that can be stored in the Policy Documents library are those of Policy Document. Once complete, it is a simple process to aggregate all documents, of type Policy Document, to a consumer site or page. The consumer site or page doesn’t have any content stored at all, it’s simply a dashboard displaying an aggregate view of all policy documents.

Using the content search or search web parts, the consumer aggregate view can be grouped by department and faceted filtering can be applied.

Using this approach, considering the content owner and contributor, should be the first on your list. Implement your solution using sound Information Architecture techniques, such as the one described above, and you do so much more with your corporate content.

Consider hiring a solid Information Architect next time. I promise the overall implementation time and costs will be lower and the value of your information use improved…

SharePoint 2013 Intranet Management, Design and Architecture Training

These ten elements are defined, in detail, in my SharePoint 2013 Management, Design and Architecture Training Course.  For those of you who recall my Information Architecture course for SharePoint 2010, this new course expands on all the new features of both on-premise and Office 365 environments.

If you are interested in learning more about how to implement a SharePoint 2013 Intranet solution, please register for our next class.

 

Bob Mixon

Senior SharePoint Solution Architect, Senior Information Architect, 5-year Microsoft SharePoint MVP (2006, 2007, 2008, 2009, 2010). Family man, father, grandfather and cook.

You can read my entire profile here.

More Posts - Website

Follow Me:
TwitterLinkedIn

Leave a Reply

Your email address will not be published. Required fields are marked *