Sometime soon, if not already, there's a very good chance that you're going to be thinking about putting SharePoint 2013 into your organization. In what is the fifth major iteration of Microsoft's ubiquitous collaboration platform, there are a ton of juicy features in SharePoint 2013 that you and your business users are going to want to get your hands on.
Faced with so many great features there is a real temptation to roll these out immediately; however, SharePoint, "Swiss Army knife" that it is, is not suited to big bang implementations. In fact, there is no surer way for your would-be, glorious SharePoint initiative to be still born, than to try to cram in a bunch of capabilities up front.
A much better approach is to take the time to work out a roadmap for your SharePoint 2013 rollout. Your roadmap is a program of projects, prioritized to give you the most bang for your buck early on and with the projects scheduled in a phased approach that will give you optimal gains, with minimal change impact on the business.
Here's a 5 step process to put your SharePoint 2013 roadmap together.
1. Find Out What the Business Wants
Your plan needs to deliver on what the business wants. That means actually getting out to the business users and asking them what they need and want. You can do this with workshops, interviews, even surveys and you should make a point of talking to a wide range of users -- across, up and down the org chart as well as in different office locations, if pertinent. To make the later planning easier, requirements should also be given a priority by the users, with the understanding that the more important ones will be given higher priority.
This process is pretty obvious, I know, but you would be surprised how often I talk to customers where IT have decided to roll out SharePoint without actually talking to the business.
2. Identify Projects
For each requirement, identify projects that will address the need. Ideally, the projects should be in bite sized chunks that will allow you to delivery capabilities incrementally.
There are a couple of ways you can do this. The first is to break up projects around functionality e.g., providing departmental teams sites. That might still give you projects that will be overly large. To break these down further look to deliver the functionality to a subset of the total organization. For instance, extending on the above example you could deliver departmental team sites to groups of one to two departments at a time. In this way you can gradually extend capabilities out to your organization.
3. Prioritize the Projects
By following the above steps, you are going to have a long list of features that the business has told you they need. Before you can put these into some sort of roadmap you will need to work out a couple of things:
- Firstly, for each project, work out its value to the business -- who will benefit and by how much. Don't try to be exact here, you just need enough information to be able to see the relative merits of each project, so you can then rank them.
- Secondly, work out the cost for each project. This could include internal costs as well as the usual external costs, like products and consulting costs.
You may find it helpful to put the results into a cost versus value matrix chart -- a bit like a Gartner Magic Quadrant. Clearly, projects that fall into the low cost / high value quadrant are the "low hanging fruit" and should be considered for the first round of projects and, conversely, the high cost / low value projects should be done later or not at all.
4. Align with IT
Depending on the capabilities you choose to deliver, your SharePoint 2013 implementation will have dependencies on your IT infrastructure, for example, which Office version is in use, file storage capacity, WAN performance. Make sure you conduct a review of the current state of the IT infrastructure and find out the timing of forthcoming projects that will relate to SharePoint -- this information will impact on the timing of the SharePoint roadmap projects.
5. Design your Roadmap
Armed with the above information you are now in a position to create your SharePoint roadmap. There are lots of ways you can represent the roadmap. I generally use phase diagrams, which shows projects grouped by phase and a Gantt chart style view, which is a great way to show the relative duration and timing of projects (along with an IT project time line).
So there's your basic roadmap done!
There are a variety of ways you can augment the roadmap. For example, you could benchmark your current state. You would ideally cover various facets of your maturity, for example across organizational, functional and technical dimensions. A maturity assessment can give you great insight into your actual capabilities right now and later you can repeat the assessment to gauge your progress. To get you started with this I can recommend the open source ECM3 maturity model.
A business case section is a great addition to your roadmap, providing return on investment (ROI) analysis and other justifications for your plan that will help sell it to the executives who will authorise it. Because so much of the benefit of SharePoint relate to improvements in efficiency, time-savings will probably feature in your ROI. Just be ready for the hard questions about what you plan to do with the "five FTEs your roadmap will save the company."
Your plan should also touch on the critical success factors for your roadmap. A good governance plan will feature here, as should a well-considered change management plan, executive support for the roadmap and making sure adequate resources (SharePoint staff, funding, etc.) are made available.
Follow the above points and you're on the way to a SharePoint 2013 implementation that just might be an epic success.
Image courtesy of Howard Sandler (Shutterstock)
Editor's Note: To read more of Andrew's thoughts on SharePoint, check out When is the Best Time to Turn Your SharePoint Intranet into a Social Intranet?