Top tips drawn from experience
To create an project or programme information hub, you could do a lot worse than setting up a SharePoint team site as suggested by Dux Raymond Sy’s definitive book on the subject. If SharePoint is already used in your organisation, it’s virtually a no-brainer.
SharePoint document libraries represent a great way to share documents across teams, giving you features like metadata classification, automatic version control, and more efficient document management. Julian Maynard-Smith outlines the benefits of a proper document management system in this great post.
However, there are some things that I have discovered for myself over several years of creating and using project management libraries on SharePoint sites that I would like to share with you.
1. Set up document libraries using reference data and standardised views.
- Set up lists of reference data you want to be available throughout your site (e.g. project name, project stage, document type, document status, etc.).
- Create a customised document library template containing fields that “look up” this reference data
- Create a consistent “family” of useful library views that use this data, such as:
- All documents (grouped by project, then document type)
- Draft documents (grouped by project, then document type)
- All documents grouped by Governance body and then status, sorted by review/issue date (for when you want to check what was reported three SteerCos ago)
- All issued documents, by project and then document type
- For more on how these approaches are useful, see my tips post on SharePoint Registers
2. Set up views based on metadata (and maybe folders)
- People are used to storing files in a shared network drive using nested folders. This works, but locks you into categorising your documents by just one hierarchy. Consider a document library containing contact details could be organised like a paper telephone directory, with folders arranged in counties, then towns, then business/residential, then sorted alphanumerically by name.
- This is fine if you want to see records for all the businesses in Bedfordshire, as this complies with the filing structure’s hierarchy.
- But what if I want to see all the residential records across Bedfordshire and Buckinghamshire, sorted alphanumerically by name but excluding those beginning with Z and P?
- That’s where metadata comes in. By assigning document metadata (information about the documents, aka “tags”) you can:
- Filter documents, much as you would in Excel®. So you can “slice and dice” the documents any way you like.
- Group documents by expandable/collapsible category headings that behave and look a bit like folders.
- Set up and save your own views, and look at documents differently from other users at the same time.
- Disadvantages include:
- Users often don’t tag files with metadata on uploading, even though they subconsciously do it in a file share by choosing which folder to put a file in. This could lead to many unclassified documents. The Programme Office (PgMO) could tag documents of course, but to do it all is a lot of admin and the document owner usually knows the document content better than the PgMO. You can of course require users to add metadata, but this can cause problems when the available tags don’t quite fit (so the PgMO needs to add new values to the field list), or a user is unsure of what metadata to add (PgMO needs to educate users).
- File grouping can only go two layers deep, so you have to apply grouping thoughtfully, and use sorting or filtering below that.
- An option that works for both philosophies (kind of) is to set up libraries with a standard set of folders, but also set up views that ignore the folder structure, using metadata instead. That way, people can find information using the approach they are the most comfortable with. And the point of a document library is to enable people find the information they seek, faster.
3. Use check-out and versioning
- OK, so this is covered in Dux Raymond Sy’s book, but it’s so important, I want to highlight it here.
- Using this feature:
- Prevents the absurdity of “who saves last wins” (when two people are working on the same document, making competing changes, and saving the document with the same name)
- Enables you to “permalink” to the latest version of a document (so that the URL you issue for a document always points to the latest version)
- Enables you to see all the previous versions of a document (along with who created them when) and reinstate any one of them as the current version.
And why wouldn’t you want all that?
4. Create document libraries from your template
- To determine how many libraries to create, think about how people will use the documents you store in them.
- One library per project might make sense; a separate library for sensitive documents (e.g. contracts, quotes, invoices, resourcing plans, etc.) definitely makes sense (to appropriately manage access to sensitive content).
- Creating new libraries created from your template means that the new libraries will already contain all the document fields and views that you put into the template.
5. Set access permissions at library level
- Although you can assign permissions at folder and even document level, this can cause confusion as it is possible to assign access to a document, but not the folder that contains it.
- This means the user can access the document if they are directed to it (e.g. from a hyperlink). However they cannot browse to the document location, so they have no sense of “where” it is.
- There is effectively a permission “wormhole” to the document that doesn’t pass through any intermediate locations. So the poor user will know the document exists, but it will be virtually impossible for them to find it again without the hyperlink(!). To get an idea of what that looks like, take a look at this.
- Also, SharePoint is not great at showing you how you have set these exceptional permissions, so it is hard to know who has access to what.
- Setting access at library level with inherited permissions makes this much easier to handle.
6. Set access permissions using groups
- Name groups according to who they contain rather than the type of permissions assigned to them. A group created to assign read permissions to library X and called “Lib_X_read” may later be used for another purpose for which that name would become confusing. It would be better to call the group something like “Project Managers” or “Business Analysts”, and assign appropriate access permissions to the group.
- Although you can assign permissions to individuals, it is better if you assign permissions to groups, and manage permissions by amending the users in these groups.
- If you accidentally delete all users from a document library, sub-site or (heaven forbid) an entire site collection, then it is much quicker to restore access if users are already in a group such as “<SiteName> All Members” than it is to manually restore access for each and every user or to put each and every user into a group as they really should have been in the first place. Trust me. I know.
So that’s my list of productivity top tips for SharePoint document libraries, learned through the experience of getting it wrong and coming up with a better way.
This article covers only the document library tips that I could explain in a compact form without the need for diagrams or examples. It doesn’t include many other conventions that I use when creating and managing SharePoint team sites to improve efficiency or usability, otherwise this article would have been more like a book (it’s already pretty long)!
If you would like to have the benefits of a document management approach like this but prefer not to have to worry about this sort of techy stuff, why not talk to us about taking care of it all for you on your next big project or programme?
® Microsoft, SharePoint and Excel are either registered trademarks or trademarks of Microsoft Corporation in the United States and/or other countries.