Office 365 and SharePoint: Document Management System Analogies

Analogy: a comparison between one thing and another, typically for the purpose of explanation or clarification. (Oxford Online Dictionary)

I have always found that analogies have been an extremely important feature of my Consultancy Toolkit, as 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, and 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 is by firstly letting your audience know that although it sounds like a technical word, it is something that they are already using every day.

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

The analogy can work with any kind of transport that was taken that day e.g. 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, but the fact that I have arrived on time to my client in London rather than get lost in another city proves that I have been able to effectively use metadata, and it has helped me rather than be 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 (which I will not name 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, and it is these labels that define all the different metadata for the individual goods e.g. 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.

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, and that 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 an organisation.

General documents are those that just get generated over time for a variety of differing reasons and 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, and it is that document type that I use 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, and once a supplier is selected 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 as 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, so do 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, and 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, with 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.

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) and 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) which is 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, and 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. 

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, although sounding technical & different, are already likely being used in everyday life.

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

I look forward to hearing more analogies in relation to the great platform that is Office 365, so please do share your ideas with me.

Want to discuss this blog further? Thinking of delivering a SharePoint and Office 365 project within your environment? Thinking of taking your first steps to move to Office 365 and SharePoint? Need training to be delivered to your teams?

Please get in contact and we can help you deliver a successful journey.