SharePoint Implementation Approach: Wave Off!

I’ve been promising to write this post for some time. I speak with a lot folks who are in the process of implementing or thinking about implementing SharePoint as their company’s intranet solution. First of all, great idea! SharePoint 2010-13 is absolutely the right solution for that project. However, I’ve heard about several approaches to the project which I fear will end in doom.

•  Doomed Approach #1 – Set up a Team site for each department and let them have at it. This will result in either a deafening silence, a knotted mess to support or a dumping ground for documents.
•  Doomed Approach #2 – Migrate all documents saved on network drives to a duplicate structure (network drive = SharePoint Library, same folders and subfolders). This will have users wondering about the point of the project.
•  Doomed Approach #3 – Create a single site template and structure, then push it out to all departments with no access to edit page design, or add libraries or lists. When the template doesn’t serve the users, they will simply cease to use it and go back to what they were doing.

Before making my approach suggestions, let’s consider what a successful SharePoint implementation looks like. Here are the characteristics:

  • Users regularly visit the company’s intranet for news and information about their work life.
  • Users interact with their team’s site to collaborate on projects, retrieve documents and find information pertinent to their jobs.
  • IT support only sporadically has to tweak permissions or sub-site/page design.

How do you get there? Well, first, serious attention and some level of resources must be applied to user adoption. I like the idea of starting with a core group that might be amenable to trying something new to resolve their team’s collaboration, communication and file sharing challenges. Then, TRAIN THEM! The more they know how to use the available SharePoint toolset, the faster they will convert themselves into power users.

When thinking about structure, don’t automatically default to departments and start planning. First, map the organization at a high level and see how the processes fit together. This tells you who might be accessing various sites to get their jobs done. Starting with departments tends to build silos.

BP Handbook D

To begin, get a group of users and support folks together and ask the question, “How does money get into the till?” Then work backward into the various processes that make that happen. This will give you an idea of the sites that will have the most impact. Individual teams will have an idea about their internal clients and what they might visit their sites to find.