Office 365 and SharePoint: Document Management System Analogies

I have always found that analogies have been an extremely important feature of my Consultancy Toolkit. They enable me to easily explain and clarify concepts that are featured within Office 365 to users who will be new to the system, and would have likely already built up barriers to change.

I have used these and adapted them over the last 5 years. They have helped me deliver successful SharePoint implementations to over 150 different clients of all sizes and industry types. Therefore, I thought I would share my top 3 sets with you . . .

Explaining Metadata

The key to explaining metadata … First, let your audience know that although it sounds like a technical word, it’s something that they are already using.

My first analogy relating to metadata is linked with my journey to the client that day. I needed to use lots of metadata to make sure that I was able to arrive at the right place, day and time to deliver my consulting services to the client.

The analogy can work with any kind of transport that was taken that day. Be it planes, trains or automobiles. However, for this example we can imagine that we have taken the train to a client.

– Question: How did I know what time the train was departing? Answer: Metadata.

– Question: How did I know what platform I had to board from? Answer: Metadata.

– Question: How did I know what stations I needed to change at? Answer: Metadata.

– Question: How did I know what destination I was travelling to? Answer: Metadata.

There are lots more examples that can be used on a journey. The fact that I arrived on time to my client in London rather than getting lost in another city, proves that I was able to effectively use metadata. It helped me rather than being a hindrance.

A second analogy that relates more closely with the use of metadata for document management takes us on a journey to our local supermarket. No particular supermarket… I will not name any as no sponsorship deals have come my way yet!

Imagine that when you enter the supermarket you look at your shopping list and see that you need to buy some tins of beans. Heading to the aisle you are met with hundreds and thousands of plain silver tins each identical to the other. How do I find my beans? The only real answer is to open them up and check inside. However, unless you are an expert baked beans connoisseur, you are unlikely to know if you have got the right brand or the one which is 20% less salt etc…

I can relate this analogy to documents, as they can be thought of as our products. In real life all our products are labelled. These labels define all the different metadata for the individual goods. For example, brand, price, calories, vegan, vegetarian, ingredients and much more. It is for this reason that we can find what we are looking for without opening the item. Therefore, in the world of document management, it is much more efficient to easily find what we are looking for using metadata (the documents ingredients) without needing to open multiple folders and documents to find the right one.

Why analogies? Whats the point?

These are just my go-to analogies on this subject. BUT, they can be adapted to a multitude of day to day activities like booking cinema tickets, loaning a book from the library or travelling on the tube. The key to this analogy is that is simplifies a word that gives end users anxieties and nervous twitches and makes them sit back and realise that this is something they use every day. They already know how to work with it. Therefore, how much are they really changing?

Explaining General & Formal Documents

I use the terms General and Formal to define differing types of documents that can be commonly found in organisations.

General documents are those that just get generated over time for a variety of differing reasons. They can essentially be labelled as “stuff” as they are not business critical. Whereas formal documents are core to the business and have a key requirement to be kept e.g. legislative or regulatory.

A common document that I refer to as being formal is a contract. I use this document type within this analogy to explain the difference between the two types of documentation.

Imagine that you are looking for a new supplier, perhaps to buy some new furniture for the office. This project and process will generate numerous documents that can be classified as general. For example, price lists, brochures, letters, deal sheets and analysis documents. These are all general documents as they are not critical to your business. Once a supplier is selected, they would not be worth keeping in storage as they just become clutter. It is these documents that you would likely keep within a well-structured folder setup. The relevant personnel would know how to get to them for the length of time they are needed.

When the supplier is finally selected you will be provided with more formal documentation, such as an invoice and contract. It is these documents that I would label as formal documents, as they are critical to the business and you would need to keep them to be referred to in the future. It is these files that you would keep within a fuller featured SharePoint Document Library, as you would benefit from using metadata to be able to sort the documents and search through them. As an example, you may want to show all contracts that you are the owner of and have them ordered with the nearest to ending being at the top, helping prioritise workload.

Once again differing examples can be used, the core message to be provided is that you do not need to overcomplicate your document storage by using metadata for every single type of document and you certainly do not need to keep everything. Moving to a new document management system gives you time to get rid of the clutter and cleanse. Take advantage of that.

Explaining Intranet Site Structures

There are occasions when I explain features and functionality of SharePoint using analogies, and then find that other personnel from the client, who form part of the project team, also begins to add their own into the mix. Admittedly some I find are better than others. When I hear them, I add them to my own repertoire. This is one of those examples.

Within my role I talk a lot about the different levels of permissions that are assigned to site collections and documents. The majority of this information being put together to form a large Intranet platform. Therefore, we would usually utilise a structured approach in which an organisation would have an Intranet (Hub Site Collection) and then would have both a Public Team Space per department and a Private Workspace per department.

Public and Private?

The public space is an area where the team can modify the documents, but everything is available to the rest of the organisation, like a mini team intranet. As an example, users would navigate to the HR Public Team Space to find published policies and procedures. The private space would still be edited by the team/department members but would not be available to the rest of the organisation. Think Data Protection, GDPR and Personnel Records. Therefore, it is at this stage where you are starting to move away from an Intranet and become a working area.

So now for the analogy.

Imagine you are walking down a busy high street (the Intranet). You can see lots of different restaurants (the public team sites) which you can enter and peruse as you would like. Once you are settled you would begin to view the menu (the public documents) and see what is on offer. Whilst this is all happening, the chefs (the team/department) are busy preparing all the meals within the kitchen (the private team sites). These are not accessible to the clientele. In this analogy the Intranet is being used to give access to a multitude of different places that are owned and ran in a slightly different way. However, there are always areas in the background that are not accessible and remain private to passers-by.

I felt that this analogy easily summed up the way that our defined site structure works. It clearly demonstrates that there are areas that are presented to users, areas that are accessible to users and private areas where only some users can access if they have the right permissions to do so.

Summary

In Summary, the use of analogies allows me to simplify SharePoint and Office 365 functionality. It enables me to show my audience that the items I am discussing are already likely being used everyday. Even if they sound technical and different.

It is common that users build up barriers to change, however this is usually due to fear. Therefore, the act of normalising and simplifying the changes allows for my audience to become more accommodating of them. They leave their sessions with a thorough understanding of the what, why and how in relation to these subjects.

This blog post was written by our Senior SharePoint Consultant, Steve Glasspool.