By Ryan Gachet
One of the great joys of attending the SharePoint 2008 Conference was the personal interactions with system administrators and end users. It was from one of these interactions that this latest blog post was spawned.
During lunch one day, I met with the collaboration program manager. He had a very simple question, but, as I sat down and talked to him about the question and possible solutions, I realized that not only was this one of the most common questions that I encounter as a consultant, but it was also a great example of how using available SharePoint features can lead to highly valuable solutions.
The question the PM posed was, "How do I get my end users to stop using folders and treating SharePoint like our old file server?"
Now, before I get into the meat of this blog, I of course want to say that there are valid business uses for file servers, and that not everything should be stored in SharePoint. For more information regarding file servers vs. SharePoint I would direct you to this blog post from Joel Oleson.
Okay, back to the question at hand. How does one convince a group of users that SharePoint can not only provide the same level of functionality of their current file shares (i.e., security, document storage, etc.) , but it can also dramatically enhance the way they manage and interact with their documents.
The first admission here is that giving end users a SharePoint document library and calling it good is generally a recipe for failure. The reason is that, though it provides them with the features they want along with additional benefits, all that has been provided is another place to store information. The trick is providing end users with a compelling reason to use the SharePoint document library. This can be accomplished by thinking out-of-the-box. By bolting together the already available features in SharePoint and encapsulating them into a basic dashboard, it is easy to build a compelling solution that will be accepted by end users and help drive adoption of SharePoint within your organization. To demonstrate how to do this, the following scenario will outline the issues and a simple out-of-the-box solution.
Scenario: Transforming a Project Management Folder Structure into a SharePoint Document Dashboard
As a SharePoint Site administrator you are approached by your end users. Their biggest concern with their file server is that they have a series of folders that contain project information, and they are struggling with:
- Documents being relevant to more than one project at a time. As a result, the end users are storing multiple copies of the documents in multiple folders.
- End Users often save "their" documents to their desktops to make them easier to find.
- End users are confused about which versions of their documents are the most current.
- End users are assigned review and approval tasks (through email) and they are unaware how many tasks they have, and when tasks are due.
I have no doubts that these are common issues that every system administrator has encountered. I'm also confident that these same system administrators have had numerous discussions on how a SharePoint document library would resolve most of these issues, and yet these end users have not adopted the new functionality in SharePoint. So now what?
Going back to the initial conversation I had with the program manager, the main reason these end users were not adopting SharePoint is that a SharePoint Document library, though the solution to many of their issues, is not necessarily compelling. As such, the best solution is to use the information gathered about their processes and pain points to design a simple, compelling, out-of-the-box solution.
The Solution
Here is the proposed SharePoint Dashboard.
As a quick summary of this Basic Dashboard concept, when an end user comes to this dashboard they are shown all the relevant document information for their specific projects. They are shown the documents that they are currently working on, what the status of those documents are, any discussions that pertain to their documents, Tasks that are upcoming, and finally Tasks that are due today.
The out-of-the-box features of SharePoint that were used to build this solution are:
The Blank Web Part Page
- Document Library Web Parts
- Custom Metadata
- Task List Web Parts
- [Me] filter
- [Today] filter
- Custom Views
The rest of this post will talk about how each section of the dashboard was constructed.
Basic Dashboard
Because all the data being used was already housed in a team site, the best method for displaying the data in a customized format was to use the Blank Web Part Page as the basis of this new dashboard.
Project Document Status
This area of the dashboard was built to specifically address the end users' need of visibility into the overall approval status of their project documents. This was built by turning on Version History and Document Approvals within the Project Documents Library, creating a custom view that only displayed documents Created By [Me] and grouped by Approval Status, then applying the custom view to the Project Document Library on the Web Part page.
My Project Files
This area of the dashboard was built to specifically address the end users' need to see all project documents over which they have ownership. This was built by applying custom metadata to the Project Document library (a drop down selection column called "Project"), creating a custom view that only displayed documents Created By or Modified By [Me] and grouped by Project, then applying the custom view to the Project Document Library on the Web Part page.
Project Document Discussions
This area of the dashboard was built to address the need to see all Project Document related discussions related to documents they have ownership over. This was built by applying custom metadata to the Project Document Discussion Board (a Lookup column that displayed the Titles of all documents in the Project Document Library), creating a custom view that displayed discussions created by [Me], then applying the custom view to the Project Document Discussion Board on the Web Part Page.
Tasks Due Today
This area of the dashboard was built to address end-user needs to see all of their tasks that were due Today. This was built by using the tasks generated by out-of-the-box document workflows (review and approval), creating a custom view that displayed all Tasks assigned to [Me] and with a Due Date of [Today], then applying the custom view to the Workflow Tasks list on the Web Part Page.
Upcoming Tasks
This area of the dashboard was built to address end-user needs to see all of their upcoming tasks. This was built by using the tasks generated by the out-of-the-box document workflows (review and approval), creating a custom view that displayed all Tasks assigned to [Me] and with a Due Date not equal to [Today], then applying the custom view to the Workflow Tasks list on the Web Part Page.
Benefits of the Solution
After this solution was built and deployed, end users had a greatly improved experience. Instead of using a file share to manage their documents, they now had a targeted interface that displayed all of their relevant document content. By employing the power of the [Me] filter, this one dashboard now rendered data specific to each user, even though all the documents for all projects were stored in one SharePoint document library. Also, by creating custom views and applying them to web parts, end users were exposed to other relevant data in one place (tasks, workflow, etc.).
Now, I'm not claiming that this is a panacea for the common issue of convincing end users to adopt and use SharePoint document libraries. My hope is that this demonstration will show how easy it is to create a rich, dynamic platform for interacting with data, a much more compelling solution for end users.