Why plan for metadata? Or, maybe is what the heck is metadata? Most, if not all (who are likely to read this), have some idea what metadata is. Just saying “data that describes data” is a bit too simplistic but is accurate. With any framework, metadata takes on new importance. It has moved from the back office to the front office and has gained popularity through the web. That Internet. Causes so many problems! Three aspects to consider with SharePoint:
- The users are really only concerned with Content types and the metadata associated with those types
- Too much classification can lead to a stalled implementation
- Dictated metadata leads to disuse and a failed implementation
So, if it is a lot of work, can easily be stalled and may not be adopted, why do it at all? So glad you asked…
Users…Content Types and Tagging
Why do people tag? I’m afraid I’ll have to defer to those of you who specialize in human behavior. I’m sure there’s a lot of reasons but the bottom line is tagging provides organization. Organization is the usefulness of metadata. Think of it. If you have a file cabinet with only one drawer and everything is simply organized by date filed, how useful is that? It’s by date, so you can narrow the search. What if someone else removed a document, made a copy then re-filed the old document plus the changed copy with the new date? You pull the old document not knowing that there is a new document. Result, you’re not out of synchronization.
Oops… a little far afield from strict metadata and more into versioning but it does illustrate the point. With only one dimension to search by, finding all documents by a specific topic (metadata) is difficult and very time consuming. Plus, you never are sure if you got all the correct documents.
Back to Users:
People love to categorize things. It helps us make sense of the input around us. Providing tools to allow for categorization in a business sense helps the business run more efficiently.
Classification? You can take your classification and…
Use it… I know, you were thinking, “take this job and shove it…” right? Here’s where it gets risky. Finding the right balance between the time sorted scheme above and the overly classified is as much art as it is science. But first you have to answer the hard question… with this be self (group) managed or single source such as managed by the Business Analyst. As the SharePoint guy or gal, you’d best start out by setting up some generic classifications. Can I give you a list? You just want to copy and paste? Seriously though, it could be by department (Accounting, Operations, Customer Service and so forth) or by function (Management => Review Process, Employee Counseling, etc.). Notice, no functional operational documents? Hopefully, you are a technical person and already have that covered…. How to log on, software policy…company picnic photos…
With SharePoint, content is going to grow. Classification and tagging need to grow with it. For ideas, look at the corporate employee handbook. Got some important Governance Ideas right there.
Now that there is a lot of stuff to think about, the risk of analysis paralysis comes into play. To get through this important process, time frames work pretty well. It’s better to have a few classifications to start with than to delay the project while waiting for the full and comprehensive list. Momentum is critical to keep up interest.
Dictation only good for computers…
You know, dictating a paper on your computer through a microphone? What dictation is not good for is, implementing metadata that nobody else has had input into. Any list you put into play will get some use (by any, I mean any list that has been thought out and planned) but will not necessarily be accepted. Not only that but you will loose the creative input from others. Why should Sam contribute to Sally’s list? She made the list. She published the list. Sam doesn’t want the confrontation and he had no part of the list to begin with. Contrived? Sure. Does it happen? What do you think?
Look at the open model of WIKIs. A lot of content has been added. Because it is a social model, a lot of correction has also taken place. Hopefully, this helps in strategizing for method or model that will help you build your own metadata construct to make SharePoint functional. Without rich metadata, the file system is sufficient and a tool like SharePoint really isn’t needed. Yet, even in the file system model, an attempt is made to classify and provide some metadata for each document. From File names to versions appended to the file names, metadata is added.
Plan for metadata – it’s a great tool for organizing a corporations data. As part of the plan, include as broad of a group as possible to contribute. The more people participate the more likely it will continue and thrive.
Classify, organize, construct – create a model of organization that fits the corporation’s<entity> model. Entity because it may only be a department. The scope of the SharePoint server may simplify the process by reducing the number of variables but does not reduce the importance.
Make it a party – no one likes to be told what to do. Share the wealth and share the responsibility of creating metadata. A lot of creative people will be happy to participate and more than happy to point out the flaws if they don’t.
Ok, this is enough Rah Rah Sis Boom Bah for SharePoint. Next blogs will be on the fun of putting it all together…