Do you hate SharePoint? Part 1 of 4

Article
01/12/2012

If the answer is yes, could your hatred be caused by your local implementation? In this blog series we look at four common problems with SharePoint implementations and how you can address them.

SharePoint is one of those tools where the line blurs between the developer and the administrator, much like SQL Server and much like SQL Server, SharePoint is everywhere! So even though this post is not about coding for SharePoint, I thought it had some great information that many of us could use when dealing with SharePoint implementations, either as a developer supporting an implementation, or even as an end user (did I mention I use SharePoint at work? Hey boss, you reading this?). A huge thank you to Neil McIsaac, SharePoint trainer extraordinaire, (bio at the end of the blog) for putting this together. Happy reading!

SharePoint is an interesting platform and as it grows as a product and with its already incredible adoption, it is an important cornerstone for many organizations. But ask the people that work with it, and you will find a divided love it or hate it passion for the product.

Why hate it?

It’s my experience (which dates back to the site server/dashboard days), that many customers have difficulty handling the product and I mean this a number of ways. Here’s the issue:

SharePoint will amplify your problems.

So why do we hate it? I would hate anything that made my problems larger. But did SharePoint create the problem? That would be like blaming the carpenters hammer for building a crooked house. The problems are our own doing in the majority of cases. In my experience, the most common problem SharePoint seems to amplify are the following;

Information Management
Project Management
Information Security
Business Intelligence

Without a doubt, this is not a definitive list of problem areas, but from my experience, these are the key ones that help make or break your experience with SharePoint. So let's take a look at them.

1. Information Management

In my mind, this is the biggest problem area and by a considerable margin. Why? Well, if you think about information management, it really encompasses all of the other areas. It is a really broad topic. What is surprising is as an industry whose core revolves around titles such as Information Management and Information Technology; you would think that we'd be better at it. Let's look at an example: The shared documents library within the default team site is fairly widely used by organizations. At face value it seems like a perfect solution for the sharing of documents. After all, it is called the 'shared documents' library.

When I was a kid, I remember going to the library. I am talking about the real one that had shelves and shelves of books that you couldn't carry around in your pocket. I won't refer to those times as 'the good old days' because they simply weren't. What fascinated me was the organization. I had the power as a kid, to walk in to the library and find various books on a topic that interested me, and to browse some additional information about each book before ever finding the book on the shelf. You might be thinking that I am referring to the ability to sit down in front of a computer and search, but I'm older than that. I'm referring to the cataloguing system called the Dewey Decimal system.

That's right, no computers. Yet I could search amongst a huge amount of material systematically and rapidly (for the times). 135 years later, and I'm watching organizations fumble with taxonomy and metadata like new borns driving a car.

So what's the problem?

If we look at the shared documents library like a real library and a document like a book, if you let your employees simply start saving their document in the library it becomes almost the equivalent of having a library where you open up the front door, and chuck your book into the building. Imagine trying to find that book a week later. For the first hundred books or so, you might be ok, but what about the first thousand? Every time you see the default shared documents library being used, you should picture a real library, with nothing more than a mound of books in the middle of the room and people frantically trying to find things in the pile. The first thing that might come to many peoples mind is that "Well that is what we have Search for!" No we don't. Well, not exactly. Search doesn't organize our data for us; it makes the retrieval faster in larger systems. If you don't believe me, do an internet search for a topic such as Shakespeare and tell me what the most current and correct material is on the subject. So how do we go from a pile of books on the floor, to nicely organized books on the proper shelves? The answer is 2/3rds metadata, and 1/3rd taxonomy.

Metadata is data that describes data. In the case of the Dewey Decimal system, that data helped to organize books into categories such as fiction or non-fiction, and provide additional tags such as animals, psychology, religion etc. so that you could much more easily identify basic keywords that described the material. In the library system, that information is collected, identified, and then recorded when the book is first brought into the library so that the material can be properly placed as well as be identified within a cataloguing system to be more easily retrieved. Do your SharePoint libraries behave like that?

Taxonomy is the organization of metadata. In the example of the library, who determined that fiction and non-fiction should be one of the primary organizational metadata to categorize books? Why not hard cover and soft cover? Within your own organization, the determination of metadata and the taxonomy surrounding it is purely yours. It needs to reflect your organizational goals, which is why companies like Microsoft can't exactly make that an out of the box feature. YOU have to address it, and unless you like sorting through a million books, you need to address it yesterday.

If you haven't already addressed it, let me help you with a few tips.

Focus on process

Data is a byproduct of process. Data simply wouldn't exist if it didn't have somewhere to go or something to be done to it. Knowing and understanding the key processes in your organization is a must. What can be more difficult is the identification of key areas where your processes will likely change, or where you would like to change in the future. The reason we need to identify this as best as we can is so that we can better lay the ground work now. In other words, after we know what the current process is, we need to ask "What is likely to change? What additional information might be needed to identify problems or opportunities that we could leverage to further improve the process?" As an example, if we examine a simple project management site where we record change requests and have their statuses updated, could you easily identify the total amount of time it took to go from request to resolution? Could I easily identify the chain of events that happened after receiving a change request? And is either of those 2 details important to me or will be important to me in the future? Questions such as those will help take you beyond simply recording a change request and marking it as 'resolved'. Better metadata = better taxonomy = better processes.

Have Multiple Taxonomies

Taxonomy is fairly simple in concept in that it is leveraged metadata. I think I've already established the importance of having some type of taxonomy. Although what I am about to say is really two versions of the same thing, for the sake of the SharePoint argument I am going to separate the taxonomies into 2 types; Navigational taxonomies and categorical taxonomies. The reason for the separation is so they can be planned according to their primary usage in that users are either finding the data they need, or working with the data to make decisions. By focusing on their usage, we can hopefully make a better taxonomy.

With navigational taxonomies our focus should be on the Use Cases that you have established for the project. By focusing on what people do with the site, we can streamline their access to their data. You won't be able to establish that unless you understand what people do with your site, and Use Cases are the best way to establish that.

You should also support more than one navigational taxonomy since there isn't only one way to complete a task. The goal of the menu navigation should be task focused, so how do we add a second navigational taxonomy? By adding more menus? No. In SharePoint, we can add these extra navigational taxonomies through the introduction of a Site Directory focused site, and/or through the use of custom search pages and results. Both of these options are relatively easy to implement and will allow your users a second and or third way to find a location in your growing architecture.

Categorical taxonomy can be a bit harder to implement since it deals directly with content. We need to collect metadata on content to better describe it, but what should that metadata be? How should it be best structured? Great questions and the first answer lies within understanding the various processes surrounding your data. How it will be used, what decisions need to be made on it, etc. The metadata from this is typically well understood and most organizations have little trouble in establishing what the metadata is rather they have trouble in establishing how to best implement it within SharePoint.

Let me give you some tips in establishing categorical taxonomies;

Use Content Types

Content types are a way of establishing a common structure that can be shared amongst lists and libraries. Use them if you want to establish some consistency.

Use the Managed Metadata Service (MMS)

You can think of the MMS as a place to store the common vocabulary for your organization which can be used and shared in a number of ways. Another advantage is that you can disseminate the administration of the terms to the people that use them and not IT. Be aware that the MMS interface within the Document Information Panel is only supported within Office 2010.

Support Views

Views are a great way to change to look and organization of a list or library. They work by changing the display of the data, such as sort order, which columns are shown etc. Good views require good metadata.

Support Soft Metadata

Hard metadata is metadata that directly fulfills a business requirement. In other words, it really needs to be there and usually in a very structured way where we control the terms and their usage. Soft metadata on the other hand is metadata that doesn't have a direct business relationship but can offer some insight to the content. A good example would be in the way that we tag photos. Quite often we will need some hard metadata such as the date that the photo was taken and the location, but we want to support soft metadata so that users are able to tag the photo with open terms, such as 'wildlife' or 'Christmas Party'. But why do we want to support this? To which my answer is 'Do we really want to turn away free information?' Granted there is a minimal support cost to this. In the end, we have content that is simply more usable, and with any luck, could be leveraged one day, so I often tout that the support costs are minimal with a potential for much gain, so why not. SharePoint 2010 can implement this many ways including using keywords, and/or open MMS term stores.

Do you hate SharePoint? Part 1 of 4

1. Information Management

Focus on process

Have Multiple Taxonomies

Use Content Types

Use the Managed Metadata Service (MMS)

Support Views

Support Soft Metadata

Archive

Additional resources