How to manage SharePoint Implementation

This particular topic seems to be the #1 struggle by many organizations looking to get going with SharePoint/Office 365. Simply put, where to start with SharePoint implementation and how to manage and sustain this very complicated project? So with this article, I would like to share my approach, which has proven itself quite well on a number of SharePoint implementations with organizations large and small. I have published a number of blog posts on related topic already, however, this article kind of puts it all together and explains in great detail the actual approach to SharePoint Implementation.

Having a formal project management background (I am a PMP certified project manager) really helps, as it allows me to approach each client’s SharePoint implementation as a project, break it into manageable components and prioritize accordingly.

Before you proceed with this article, I strongly suggest that you read this post from May 2015: How to implement SharePoint in your organization – Best Practices. In it, I give practical tips on how to approach SharePoint Implementation and break it into manageable mini-projects. I never advocate large scope projects. They are overwhelming to everyone, your team (and consultant) will be stretched thin, it will be expensive and it might be a year before you go live. I typically like to see clients up and running (go live) within 2 months of starting SharePoint Implementation. It is very much possible if you follow advice listed in above article.

So once you have chosen your first mini-project, you need to have a plan. As such, let me present to you…

Greg’s 7-phase approach to SharePoint Implementation

Below is a diagram that depicts the 7 phases I go through on every SharePoint Implementation project.

They appear to be running serially, however, in reality most occur in parallel (we live in an Agile world). Let me explain each phase and provide more context on each.

Phase 1: Education Phase

The objective of this phase is to educate yourself and stakeholders about capabilities of SharePoint. You cannot really decide what and how to create in SharePoint, without seeing what it is capable of. I, for example, use this time to demo to client ways to organize documents, build sites, navigation, show off some cool features, etc. This not only creates excitement on behalf of the client and stakeholders, but also makes my job easier as it helps client visualize future SharePoint site(s). This phase is a necessary first step as it makes the team more educated and knowledgeable in the subject matter and adds value to the success of the overall project.

Phase 2: Analysis & Requirements Phase

The objective of this phase is to gather high-level requirements to better understand the use cases and business processes around SharePoint sites, libraries and functionalities requested. This does not necessarily mean that you have to create a detailed requirements document (remember, we live in Agile world, detailed requirements documents are things of the past). There should be enough information to understand the requirement that will allow you to proceed with follow up phases. I usually do this in a form of interactive web meeting, with lots of back and forth Q&A.

Phase 3: Information Architecture Phase

Based on high-level requirements gathered, an Information Architecture design is created. I do recommend that you document this. I typically create a formal Design Document for my clients. This is where you would detail an overall taxonomy, metadata parameters, web parts, security configuration, navigation, site hierarchy, etc. The document will essentially serve as a step-by-step guide for the configuration stage of the project. It is also a great idea to constantly update the document as you go along with future projects, as it will help the novice understand how your particular SharePoint is structured.

Phase 4: Data Mapping Phase

This particular phase is not always applicable, but might be, if you are migrating existing documents (content) to SharePoint. This could be a document that maps your current file share folders to new sites or particular folders to newly defined SharePoint metadata properties. The mapping document will serve as a roadmap for the migration phase of the project.

Phase 5: Configuration Phase

This is the exciting part. This is the phase where SharePoint is configured based on requirements and design document. Sites and libraries are created, metadata and views are setup, navigation is built and security groups are provisioned.

Phase 6: Migration Phase

In this phase of the project, documents and other content are moved from file shares or older versions of SharePoint to the newly setup SharePoint sites. Remember Mapping Document from Phase 4? That’s where you need it.

Phase 7: Training Phase

Big mistake many organizations make is that they end the project with phase 5 or 6. “Build it and they will come” approach does not work with SharePoint. If you did a good job building intuitive and easy to use sites, you might not need to train all end users. However, if you have specific business processes you want everyone to follow, or you have power users, content owners and site administrators – they all need training. I, for example, include training in all my services as a standard. Read my previous blog post on why training matters. I am strong believer in training playing vital role in success of the project. Don’t skimp on training with your SharePoint Implementation!

So, here you have it, my 7-phase, Agile approach to SharePoint Implementation. Hope you found this useful.