SharePoint Document Management System: What to Avoid
Having delivered numerous SharePoint Document Management Systems (DMS) to a variety of clients, both large and small, I have learnt to consider a number of key points. These are always shared with my clients to improve the outcome of the DMS project, and now I would like to share them with you all.
Lift and Shift. “I have migrated all my files to SharePoint and The Cloud, I now have all this extra functionality! Right?” – WRONG. I could take all the rubbish out of the office bin and neatly align it on the office shelves, but it’s still rubbish! Take the time to review and cleanse your data, this is perhaps the first time in many years that you have had the chance to make these improvements, so take advantage.
Long document naming. SharePoint will control the Version Number, Created Date, Modified Date and Created By etc… Therefore, a document that was once named “SharePointProject_v1_200318_SteveG” can now just be named “SharePointProject”. Let metadata handle the rest.
No Folders. Grouping and metadata is a great feature and should be used majority of the time, however, don’t just expect your employees to never use folders again. Some documentation is best structured in folders with a minor amount of metadata, and if this is efficient for the end user then use it. You can always create views that show documents outside of folders – so you get best of both options.
Long folder names. As SharePoint is an online system, there are limitations on URL length, therefore, the use of short and meaningful folder names (including acronyms) free up space for those document names that cannot be kept short.
Deep Folder Structure. Due to the URL limitations and to avoid users getting lost and irritable, it is best to keep the folder structure minimal. This is a website and should be managed against KPIs and metrics. Therefore, users are going to be put off if having to click numerous times to get somewhere.
Minimal input from the organisation. It would be nice to provide a perfect solution to all departments with minimum input, however only the users who work with the documents and data are best placed to understand them and their team. Therefore, department representation (Document Champions) should be included within the project from the very start.
Jumping straight to live. As with all projects, it is recommended to generate a Proof of Concept that can then be extended into the full solution. This enables a showcase to be fed back to the business and enhances learning and development.
Confuse Site Columns and Metadata Meaning. If you tag a Document as a “Contract” then is that because it is a contract? or because the word “Contract” appears within the document? This is of great importance if using a form of auto tagging or OCR software.
Rely only upon the content of the document. Documents will contain a lot of references to improve tagging, however there are some types of metadata that can only be provided through the knowledge of the person performing the upload – it is advised to not ignore this knowledge.
Ignore Mandatory Fields. Some Site Columns (Metadata) will be extremely useful for end users, which means that they should be mandatory. However, some users may complain as the upload of documents may take a few minutes longer than they are used to. Do not just switch this off to appease the end users, instead keep it and “sell the benefits” of why it is needed.
For example, spending 2 additional minutes now may save 30 minutes trying to find a document or answer emails from people requesting to know where it is.
Mandatory Field Overload. So don’t ignore them, but, don’t expect that every piece of metadata is mandatory. Users should be empowered to enter the core metadata, and have the chance to go back and improve this with other properties at a later date.
Throw all Documents in one place. SharePoint Document Libraries can handle a great deal of documents; however, this does not mean that it should. It is likely that each Site would have 3 – 5 libraries (or more) that can separate documentation for improved usability.
Metadata Overload. Metadata has its benefits to assist users in locating documents, however too many will then cause confusion. It is common that 6 – 8 additional metadata fields are used per Document Library (some libraries may have required more, but this should be for exceptional circumstances). If using Office 365 then only 6 “Managed Metadata” field types should be used per library.
OTHER! (and related terms). Provide an “Other” selection within a set of Metadata and users will likely select it always, as it avoids the need to think how best to store a document. Terms like “Other” and “General” should be avoided.
Ignoring Metadata Grouping. As we do not want to overload a user with metadata, it is best to group metadata when possible or use synonyms to catch a specific tag. For example, “Engine Type” and “Engine Model” could live together as “Ferrari-A123” as opposed to needing two different fields. This tag can then be provided to users whether they search for “Ferrari” or for “A123”.
Interchangeable Tags. Ensure that the tags are all unique and cannot cause confusion due to them being interchangeable. For example, do not give a user the option to tag “Meeting Minutes” and “Meeting Outcome” as they would be the same type of document.
This blog post was written by Steve Glasspool – Senior SharePoint Consultant at AMT Evolve.
Thinking about introducing Office 365 and SharePoint into your organisation for Document Management? Looking to migrate data? Or already working with the solution, but finding it inefficient. Please reach out so that we can discuss this further.