Despite SharePoint’s astounding success for almost a decade (largely attributable to its integration with Office and its attractive licensing options), Microsoft has always presented inconsistent messages about how to “correctly” use the platform. This extends to SharePoint’s positioning and marketing of each successive version.

In 2001, SharePoint was a souped-up document filing system; in 2003, it was a web-based collaboration suite.  When SharePoint 2007 was released, the focus was “enterprise-level features” like the Records Center and Business Connectivity Services; SharePoint 2010 tried to address web publishing and classification deficiencies which trumpeting the “no-code user experience” of composites. Now in 2013, Microsoft has switched the focus back to the cloud and to developers, placing 3rd party “apps” front and centre. They also removed significant parts of previous end-user facing customisation capabilities such as the “Design View” in SharePoint Designer. 

While each previous incarnation’s features are (mostly) retained, they are often poorly integrated and generally get treated as “legacy features” that evolve little between versions. It’s no wonder that people are confused about how to get the most out of SharePoint!

Worse, many of the changes made in each version of SharePoint place the emphasis on different and largely incompatible approaches to electronic document and records management. At this point, SharePoint really consists of four different products which just happen to share a common codebase. 

The SharePoint experience for your end-users will be far less frustrating if you recognise which paradigm you are working in and don’t try to force incompatible “features” on them when they are working towards a different end goal.  The four paradigms can be summarised as:

Document and records storage – “we need a place for our important stuff” 

First delivered in SharePoint 2001, this approach prioritises formal review and approval processes for document versions, and the use of metadata for search and discovery. The addition of the Records Center in 2007 enhanced the concept to incorporate retention, review and disposal over time.

Collaboration – “we need spaces to work together”

Originating in SharePoint 2003, this approach is used for ad hoc, mostly short term spaces to share documents and other unstructured information. Sometimes supplemented with small structured information stores such as calendars, contacts and to-do lists, making it easy to contribute and share is more important than long-term retrieval or high quality content.

Process management – “show me what I need to do my job”

Process management in an EDRM system is all about two things. Firstly, bringing together what I need to make my next decision, and hiding everything else. Secondly, providing tools to make that decision, record it, and then communicate the decision to the next person in the process. This makes metadata-based views and strong workflows essential, something that existed for a long time in SharePoint, but only truly matured in the 2010 edition, when content type hubs and managed metadata was added.

Web application publishing – “I need professionally designed and controlled content” -

Web content management (WCM) platforms must not only provide powerful ways to import and aggregate documents and information, but rich and highly customisable user interfaces for presenting that information. SharePoint has always been good at the former, but historically terrible at the latter. With the switch to an app-based extension model in SharePoint 2013, Microsoft is attempting to provide tools for professionals to efficiently adapt and extend the SharePoint interface. It remains to be seen how successful it will be in this task. SharePoint’s heavy reliance on Visual Studio and .NET will still limit its appeal to any organisation who doesn’t have a lot of money to spend on consultants and developers.

When you understand these different paradigms, some of the more baffling design decisions in SharePoint begin to make sense. For example, why have folders and views? Because folders and Explorer View provide a simple, intuitive mechanism for group collaboration, while extensive mandatory metadata and views makes sense when there are multiple participants in a process flow.

Managed metadata

Similarly, managed metadata classifications are powerful, but there’s no out of the box way to select a term “and all subterms” in a view. Why? Because managed metadata was architected to enable document browsing and rich search using Microsoft FAST, not to support process work.

It also explains a pet peeve of mine: that the “Blog” template was only designed for use in collaboration sites, not in web publishing sites. It appears that even Microsoft’s teams pursue these different design goals internally, despite the fact that they never really attempted to communicate the dividing lines to SharePoint administrators and users. If Microsoft has ever had a consistent message about SharePoint, it could probably be summed up as “SharePoint can be anything and everything you want it to be”. Ironically, that is probably the one demonstrably false thing Microsoft could say about SharePoint, since conflicting needs of the different paradigms are inevitable and mostly irreconcilable.

Putting it another way – unless you have decided what you don’t want SharePoint to do for you, there is a very good chance that you are, indeed, using it wrong. 

Stephen Bounds is founding director of knowquestion Pty Ltd, a specialist information and knowledge management consultancy http://knowquestion.com.au or follow Stephen on Twitter @smbounds.