SharePoint as a Document Management System – A Real World Story

Introduction

“Out of difficulties grow miracles”, Jean de la Bruyere

The purpose of this article is to talk about SharePoint as a Document Management System (DMS), using a real world scenario as a use case. It will cover some of the features available by default, what you can do to extend these features, and the main challenges ahead.

Document Management System Context

“Your big opportunity may be right where you are now”, Napoleon Hill

As mainly document-oriented, this organization was an early bloomer on the digital information age. Several servers were deployed to support Active Directory, Outlook, Lync, File Shares, Intranet Portal, Backups, and others. Devs, IT Pros, and Helpdesk became an absolute everyday requirement. There are averages of 800 incident calls per month which need to be handled by first line of support, and due to European legislation, all systems were implemented and maintained in-house.

Using SharePoint as a DMS felt right within this Microsoft-oriented ecosystem, but this may not always be the case, so it is definitely advised to research other alternatives that may fit the scenario at hand. There are a few interesting discussions on this topic.

The next sections will focus on technical concepts. For an overview of these concepts, consider taking a look at the TechNet article on Document Management for SharePoint 2013.

Challenges

“The best and most beautiful things in the world cannot be seen or even touched – they must be felt with the heart”, Helen Keller

This agency has around 400 people, some of which may be working through a VPN connection, which means a lot of people to support and serious problems during downtimes, even after core work hours. Being tightly linked to the European Commission, requirements come directly from the before mentioned, as well as from internal stakeholders, project managers, and others. As a result, one of the constants is of course, “change”. When building any new system, we need to leverage scalability, security, disaster recovery, user adoption, among others.

The first challenge is the platform. As previously stated, it might not make sense to choose SharePoint for every given scenario. If you do choose it, you should understand what you get with both Foundation and Server versions. While not “advertised” as a DMS, SharePoint has built-in Document Management features. Some are available on SharePoint Foundation, others only on the Server version:

  • The Microsoft Office Document Management namespace provides features such as location-based metadata defaults (the ability to inherit properties of a parent item into its child items)
  • Managed Metadata provides a central location for hierarchical collection of terms
  • Content Organizer allows routing documents to specific locations according to pre-defined rules. In order to be able to use this feature, one must have the Server version and a required, single value property on the chosen content type
  • Versioning will allow users to view previous saved versions of their documents
  • Office Integration allows users to open their documents in the Office client applications
  • Security provides means to restrict access to documents
  • Content Type Hub centralizes content types and columns
  • Document ID provides a unique ID for each document within a site collection
  • Document Sets allow grouping collections of documents into a single common container
  • Workflows help sending the document around for reviewing, approving, etc.
  • Records Management is also available, but only in SharePoint Server

Check here for a full list of feature availability.

Having the above features doesn’t necessarily mean that SharePoint is a DMS or it will work as an efficient DMS out-of-the-box. The next big challenge is, therefore, planning. Many unsuccessful DMS implementations are due to lack of proper planning and deficient farm implementations.

Here is a brief list of concerns:

  • Architecture

Planning and setting up the architecture is where we should apply the most effort, backed-up with proper research. Define the number of web applications, site collections, and sites; define how and where documents are saved, and the security policies applied; leverage the usage of document templates; define metadata and taxonomies; setup service applications; etc.

Should we or should we not follow the organizational structure? Some may say it is a no-no, but there is hardly a consensus. What is your take?

  •  List View Threshold

Even by separating our architecture in different databases and site collections, eventually our libraries can face the 5k threshold. It is imperative to think about this beforehand, and understand what it is and some of the techniques to overcome it.

  •  Concurrency

We have several users editing the same documents at the same time. In some scenarios, this can raise issues or even software limitations (e.g. Excel co-authoring).

  •  Conventions

ESPC call for speakers 2024
We seem to only worry about these later in the game, but they are imperative:

a)      Have a naming convention for variables, columns, sites and pages

b)      Use friendly URL names, avoiding %20 which will often fail when forwarding emails

c)       Avoid having multiple features and/or solutions with similar names

d)      Comments and self-explanatory methods are a must

e)      Avoid having_00x20_in columns’ internal names due to spaces being used

f)       Should the Document Information Panel (DIP) be opened or closed by default? May be problematic on small screens.

g)      Should documents open in the client application or in the browser (limitations apply)?

  •  Office Client

The “Office Upload Centre” can be dreadful. Users tend to pick up their laptops and with their documents open, go to a meeting, and meanwhile someone else updated the document. When they connect to the network again they will find themselves with a local, outdated copy. This copy can be deleted and the backup functionality of upload centre disabled.

  •  Drop Off Library

Content Organiser is an interesting feature of SharePoint Server. In a nutshell, it enables us to route a document to a destination according to some criteria. The problem is that quite often, users find a way to miss or close the part where they setup the metadata, which means that the document will be “stuck” in the DOL. Although it can be handy in some scenarios, make sure you are not creating a bigger problem.

  •  User Adoption

Another big challenge – not limited to DMS systems – is user adoption. It is quite often a reason for failure, and usually not related to the quality of the architecture per se, but its visual appeal. There are many options to cover branding for SharePoint: custom development, turn-key solutions, or frameworks. If you don’t have the time or the budget to implement something yourself, you can take a look at BindTuning or the Bootstrap for SharePoint at CodePlex. Also, the SPInterface project is a lightweight CSS approach for small customizations with little or no master page editing (can be used with AlternateCSSUrl).

  • Leverage 3rd party tools

Although being a fan of “do-it-yourself” kind of stuff, in a big organisation with big goals, we need to keep our head in the game. If budget allows and it makes sense, it will save a lot of time or simple help users, to use third-party software. Solutions like Harmon.ie for Outlook, or DocAve from AvePoint will help both users and developers. The first allows users to drag-and-drop documents and tag metadata without moving away from Outlook, while DocAve allows us to batch upload hundreds, or even thousands or files on our local file shares, over to SharePoint, with the proper metadata.

Conclusion

“We can only know where we are going, if we know where we came from”

Before digging into a project, it is absolutely necessary to take a step back and check your options. SharePoint might not have everything you need, or everything you need built-in, in comparison to full blown document management solutions. Once you have decided, try to gather up a team of experienced people who really know what they are doing, and setup a proper implementation plan. A good DMS implementation is one that is intuitive, scalable, and survives time.

About the Author: Tiago Duarte is a Software Engineer from Portugal. He is actively involved in community forums, events, andTiago Duarte technical blogs (having one of his own). His field is mostly but not limited to Microsoft Technologies, specially SharePoint Branding and Development. After developing themes for SharePoint whilst on Bind, he is now an independent consultant, working for the European Centre for Disease Prevention and Control (ECDC). He is a certified MCPD and MCITP, and has been speaker, article writer, or otherwise attendant on technology events in Portugal and Sweden. He also has a few side-projects were he develops his own ideas.

Blog: http://ftduarte.blogspot.com

Twitter: https://twitter.com/tduarte85

Website: http://about.me/tiagoduarte

Share this on...

Rate this Post:

Share: