Introduction

Over the past four weeks I have introduced you to the concept of Mind Mapping for SharePoint and how to use MindManager to build and document SharePoint projects including: Navigation; Project prioritization; and Early-stage brainstorming.

Next week I will show you how I use MindManager for one of the most difficult aspects of a SharePoint project: Building out the taxonomy of Document Libraries, Content Types and Metadata that will be used by a site.

In this week’s installment, you won’t see any Mind Mapping as I describe my approach to explaining the meaning and value of metadata to stakeholders (Site owners, content owners and contributors).

Metadata: What a concept

You are going to ask your users/stakeholders to tell you about their metadata, but they don’t know what that is. Explaining the concept clearly is difficult, and even if you do a great job, most people won’t really get it right away. Don’t let that stop you. Think of this as a process that starts at the edge of a target. Together with your stakeholders, you will spiral in towards the bull’s eye.

The Metadata Target

I have found that, quite often, one of the key drivers behind a SharePoint implementation is to clean-up the chaotic “S-Drive”. What the client often wants to do is create a new and better folder structure in SharePoint. If this happens to you, DON’T LET THEM DO IT! A deeply nested folder system in SharePoint is even worse than one in Windows because it is slower and harder to navigate.

The Metadata Workshop

At the Metadata Workshop, I explain that metadata is “data about data”. In the case of documents, it means information about a document that will help you to identify it later without having to open it. People use metadata every day without realizing it.

I start the workshop by reviewing something that everyone already understands (and probably hates), the folder based file system on the “S-Drive”, or whatever the shared network drive is called in the customer organization.

I explain that because the Windows file system gives you very little information beyond the file’s name, size and last-modified date, people use the filename itself to capture metadata like date, customer, document type and version. You will often see files with names like “IBM-Proposal-May-2008-Ver2aFinalFinal.doc”. All of that information crammed into the filename is really metadata.

The use of structured folder names is another type of metadata that people use every day. If you have a file structure that looks like the sample below, then you are using metadata to help you identify your files.

Sample Folder Hierarchy

The metadata is telling you that “file1.doc” is a Sales Document for the Year 2007; Western Region; Industrial Division for a Customer named BBN Inc. That is all useful metadata, but here comes some trouble.

Folder Pain

In workshops you may find that the stakeholders will tell you that they have a well structured and efficient folder hierarchy and everyone knows where to find the documents they are looking for. If you ask them what happens when someone new joins the team, they’ll tell you “Oh, that’s a mess at first; they put all sorts of stuff in the wrong places”.

Here’s a typical story: The intern we hired last summer dug down the hierarchy and could not find where to save files for CBS Inc. He knew that CBS is a national client (he didn’t realize that we divide all clients regionally by delivery location).

So the intern, taking some initiative, decided to create the CBS folder directly under the year. By the end of the summer, there were too many files in there and they were a combination of East, West, Industrial and Consumer files. It was going to take too much effort to fix everything, so we just left it. From now on, we have to remember that we have to look in multiple, non-intuitive, locations for sales documents.

Problems with the Hierarchy

An Alternative to Folders

Everyone is pretty much aware of the problem with folders. The solution is to identify the relevant metadata fields ahead of time and then assign the metadata values to the document at the time that it is saved. The documents can then all be saved in the same place. This means no more guessing about which folder to use (and how many layers down you need to dig).

In the following diagram, each column represents a piece of metadata:

Files with metadata

You can see that we have defined metadata fields for: Customer (Customer Name); Type (Invoice, Proposal, Contract); Division (Consumer, Industrial), Year and Region (East, West). Every time we save a new file, we are prompted by the system to enter values for each of these metadata fields.

By entering this data at the time the file is saved, we will be able to find, sort and filter our documents much more easily. You may notice that there’s a catch here: A bit of extra work has to be done every time you create a new file. For this reason, it is critical to keep the number of metadata fields to a minimum; otherwise people will find ways to get around the system (e.g. entering fake data). Research has shown that about six metadata fields is about the maximum that you can ask people to fill-out on a regular basis.

A great advantage of using metadata rather than nested folders is the use of views for filtering and ordering your documents. For example, if your boss wants you to pull all 2008 contracts from the industrial division in the East, you no longer need to hunt up and down the levels of folders; you just create a view that gives you only those files.

Files with metadata and a view showing a subset of the documents.

At this point in the workshop, If I’ve done a good job, some of the participants will “get it”, but most will be flirting with the edge of the yellow ring of the target. They still don’t get it completely, but they’re starting to understand that there may be a way to organize documents other than folders.

NOTE: This is also where I explain SharePoint versioning and Check-in/out. But those are topics for a different article.

Workshop Homework

At the end of the workshop, I give the attendees a spreadsheet to use so that they can catalogue the metadata that they will need for storing documents in their own SharePoint sites. The spreadsheet has a couple of relevant examples to help guide them through the process.

I don’t worry about telling them to limit the metadata fields to six. I want them to get as much information as possible. Later, we will work together to determine what is really essential.

Here is a sample of the spreadsheet that I give the users. In this case I am showing two quite different types of documents as examples. Normally, I tailor the example to the department that I am working with.

Sample Document Inventory Spreadsheet

Conclusion

In this week’s column I’ve shown you how I educate stakeholders about metadata and how to get them started on a document inventory.

This is only one possible approach that has worked quite well for me, but this can be a difficult process. I would be very interested in hearing about methods that have worked for you.

In next week’s article, I will demonstrate how to use MindManager to take the results of the document inventory and build out the taxonomy of document libraries, content types and metadata.

Author: Ruven Gotz

Ruven Gotz is a senior consultant with Ideaca, a Microsoft Gold Partner based in Toronto. For the past five years he has been focused on delivering award-winning SharePoint solutions (most recently, a Microsoft Impact Award for Information Worker Solution of the Year, 2008).

Ruven’s blog is at http://spinsiders.com/ruveng and you can follow him at http://twitter.com/ruveng.