Too often, many technical organizations have absolutely no business strategy when it comes to SharePoint. They simply have a small process added to their existing ones on how to request and create a SharePoint site. They may not even include any sort of governance around the site creation process, which can lead to a very large volume of site collections and eventually to a support issue.

There may be some basic conversation and education around the use of some of the larger concepts like site collections and Search in SharePoint. But the discussions of strategy can get very complicated. Because of this, many technical organizations simply decide to end their strategy at the site creation process. Instead, let’s start slow and with the basic key SharePoint features.

Who are your business clients? Are they the corporate technical team, your regional marketing team, or maybe the R&D team? As I stated earlier, SharePoint implementation is usually started by the infrastructure team and then it slowly trickles down into the business client population.

In some cases, your business clients will have already heard about SharePoint in a simpler context when they are considering some large-scale, key line-of-business application, which is where the second use of SharePoint usually starts. Without a clear business adoption strategy, it will be a very slow and arduous journey for the technical team to ensure that their SharePoint farm has the right amount of adoption and use.

In my case, most of the SharePoint sites that were already created when I was introduced to SharePoint were simply collaboration sites with large document libraries with very complicated and convoluted folder structures.

Some of the folder names were actually small sentences so that the team could understand exactly what types of documents were in the folder. There were no metadata tags, no content types, just simply documents sitting in folders.

The entire process of collaboration was the sharing of the actual documents. There was a single repository where everyone was able to share documents and that was the extent of the collaboration for the team. That is what the business client saw as the biggest value of SharePoint.

It’s no wonder that, when I started to speak with people at the business, their impression of SharePoint was unenthusiastic at best. Even some of my technical counterparts started to argue that we could save a great deal of cost if we simply purchased file shares to handle the files and the folder structures.

Many of the basic SharePoint features were simply not communicated properly to my business and to some extent even the technical team. They were sold on SharePoint as an amazing CMS tool with great possibilities to strengthen collaboration and innovation, yet the best we could come up with was file share.

During one of my first interviews within my business, I found out that the reason for some of the lengthy folder structures was to provide some level of structure for people to find certain files. The business was not even aware of the basic search capabilities of SharePoint, let alone following SharePoint best practices. I needed to find a way to engage my business clients so that they could not only utilize SharePoint in a more efficient manner but to also educate them on some of the real strengths of the platform.

Presenting a Better Business Case

Based on feedback from the above interviews with business clients, I realized that I would need to start all over with education. But based on the already large farm we currently had, how was I going to be able to “start over” when things were already moving forward?

Most of the sites were team collaboration sites with document libraries. So I decided to start with document libraries. I had one of my business clients agree to work with me and my team on restructuring their libraries in a manner that would allow them to minimize the folder structures while increasing the visibility of finding the right file that the user was looking for.

As we dug deeper into the structure of some of the sites, it became evident to me that the folder structures were actually data elements and groupings of the various types of files that the team was collaborating on. So I decided to start with a very basic—yet powerful—feature of SharePoint: Metadata tags.

I have always felt that one of the most powerful ways of educating any client on a technology was to simply develop some sort of POC. The issue with POCs is that they do have a cost impact. You have to be careful not to fully develop an application to only have the business decide it is not what they want.

In my case, the cost was minimal, but the value was potentially huge. I decided to take multiple document libraries, each of which had 20 or more separate folders, and recreate it as one document library with metadata and content types. Rather than try to explain content types, it was easier to showcase how using a content type could not only add to the data structure but also allow them to properly govern the additional metadata associated with a file.