In this topic, I’m going to build on top of the foundation my colleagues set and provide a set of pre-migration project planning tips. As you’ve seen, Microsoft has made a lot of investment in Office 365 and SharePoint 2016, and it’s easy to get excited about the technology improvements. But let’s not forget what matters most: making a difference in the lives of the information workers we serve. As I travel the globe talking to customers, I continue to hear stories of troubled SharePoint deployments. This is not new to those familiar with the past few SharePoint versions. However, it’s surprising that organizations are repeating so many mistakes from the past when planning their SharePoint migration or update effort. “Does it really need to be so painful?” is a question that I often hear. In this article, I hope to provide some much-needed planning remedies along with some prescriptive guidance to ensuring your SharePoint 2016 transition is by far your most successful one yet. While there are many reasons SharePoint can be painful for organizations, I’ll focus on three reasons related to project planning:
Lack of vision
Poor adoption
No actionable governance
Why is SharePoint Painful? – No Vision The first step is asking whether you have a clear vision for SharePoint with specific, measurable goals. In other words, why are you using SharePoint and what specifically do you expect to gain by doing so? If your answer is a generic platitude like, “We are using SharePoint because we need to collaborate better”, you need to rethink this. With SharePoint, you’re expecting to take your organization from an undesirable current state to an improved one. Be clear on what that improved state looks like. Describe how you see this future world. How does information flow? What problems has it solved? How would employees describe how this has made a difference? And, very importantly, how do you know you’re improving? That is, can you measure it? This is where the goals come in. It’s okay if you describe your vision in several stages as phased deployments are best. When you think about the future state, know it’s not really a destination but a journey. You’ll continue to make optimizations to keep up with technology, evolving cultures (onboarding the Millennial Generation is a big one!), and remembering that the business landscape is always shifting. While I’ve written a fair amount on this subject as well, for additional reading, I’ll refer you to Paul Culmsee’s astute presentation The second reason SharePoint is painful is that project teams assume that SharePoint is finally good enough as a platform where issues like user adoption and change management aren’t that important. In SharePoint 2016 we have improved mobile support, a robust OneDrive for Business synchronization engine, unified search results, smart attachments (when also using Office 2016), and many other user-centric features. These are great, but are they really enough to change old-fashioned collaboration and file-sharing habits? Regardless of feature richness today or next year, workers must still be guided so that they create better habits, ones that are best for your organization. For example, do you have simple answers for basic file-management questions such as:
Where in SharePoint do I store this file?
How do I get users to tag their files?
Why can’t I find the file I’m looking for?
Some of these answers may involve using additional technology such as This step can occur in parallel with these three planning remedies. Indeed, they are interrelated as I’ll discuss. However, many skip over this planning altogether and focus on technology only. Resist this urge! As part of your migration plan, you will of course test drive SharePoint 2016. Sure this is the fun part, but as you’re doing this, be sure to test out features specific to the vision, goals, and use cases that have been established. If you already had a vision and goals from a prior SharePoint version, how do the changes influence these? For example, do the changes to Excel Services cause you to rethink your BI strategy? During your test drive, bring in information workers along for the ride. Have thoughtful conversations and give them structured demos. Please don’t assume. Take the time to understand their challenges and opportunities and tease out root-cause issues where possible. You must align SharePoint to the business, and if you don’t understand the business, you won’t be able to do that. Just be careful that you prioritize their concerns, manage their expectations, and make sure you fold input back into your three planning remedies. Reassess your workloads Now that you have a feel for the latest version, you need to rethink how and what workloads you’re going to deliver to your knowledge workers. While core document management features haven’t significantly changed in SharePoint 2016, changes to Office 365, Office 2016 (including mobile Office apps), One Drive for Business, and others will make you rethink what’s placed where. For example, does large file support (beyond 2GB) mean we should store our massive AutoCAD drawings in SharePoint now? Or, maybe these should now be placed inside Office 365 with its lower storage costs? Here are a few questions you should be asking.
Is it finally time to migrate file shares or other content sources into SharePoint 2016 to consolidate content management?
If I upgrade to SharePoint 2016, do I still need to be thinking about Office 365?
Even though I’m upgrading to SharePoint 2016, what content should I be keeping on premises and/or in the cloud?
Am I doing all I can to protect and preserve my organization’s content? Does SharePoint 2016 provide the data loss prevention (DLP) and robust information management features we need? Will these still need to be supplemented by third-party vendors?
Some people say Delve is a game changer for how people find knowledge and stay connected. Is this a new workload and how does this change how we’ve been handling this challenge?
Is my organization ready to for an electronic records management program? Does the SharePoint 2016 feature set give us what we need here?
Does the improved integration with Yammer mean we’re finally ready to adopt or transition our enterprise social platform over?
As others have simplified their custom-code investments and started to move away from full-trust code, is it finally time for us to rethink our legacy customizations?
Microsoft has moved away from using SharePoint as a public-facing website platform, specifically in Office 365. Does that mean we should be rethinking this use for SharePoint 2016 as well?
This is not a complete list, but enough to get you thinking. You’ll likely have questions that are unique to your organization as well. One recommendation is to note that technology changes will continue at an even faster pace. Where possible, design your workloads so they are not so tightly coupled, giving you flexibility to upgrade or reassign workloads without too much disruption. For example, you might decide today that It’s never a good idea to flip a single switch for all users on a new version of a platform as complex as SharePoint. This advice is not new to this version of SharePoint. Despite your best efforts in the three planning remedies (vision, adoption, and governance) along with your technology and workload assessment, you’re still going to be off the mark to some degree. It’s not until you get real people with real work using the platform for a period of time that you realize where tweaks are needed. Unless you’re planning on upgrading straight from SharePoint 2013 to 2016 without incorporating anything new, you can’t really get away with a wholesale upgrade. Most likely, you’ll build new farms (production and one or more pre-production farms) and transition users over gradually. Whether you do this by project, functional structure (like business unit or department), or some other grouping will depend on what works best for you. There’s no single best practice here. As part of this transition, remember the change management challenge: How quickly can information workers adopt these changes and incorporate them into daily tasks? In addition to rolling out incrementally to groups of users, where practical, roll out features/workloads incrementally as well. The pace will depend on:
Complexity of change
The degree to which you’ve prepared your users (remember user adoption)
The general speed at which your organization is able to adapt
For example, you may choose to have the basic SharePoint 2016 upgrade, which you use for your intranet first. You’ll then transition to team sites and document management. Next, hybrid integration with Office 365, which may also be done in a series of incremental rollouts. A table such as this one may be helpful for you:
Enjoy the Journey A SharePoint journey never reaches a final destination. It’s not really about SharePoint or the technology either. It’s about effecting a positive change that makes a real and measurable difference to the business or mission. As a service provider, put the business first by having a clear vision, planning for user adoption, and establishing an easy-to-follow actionable governance plan. Then, align the technology to the business and incrementally perfect the service as the world changes around us. No one wants to be part of a painful deployment. While I can’t promise your project will be pain free, by following these prescriptive steps, you can see and feel positive change with the least amount of pain. Best of luck to you in your journey. Next Steps If you have further questions about pre-migration project planning, what to consider before jumping to SharePoint 2016, or which path or structure is best for your business, ask us during our webinar, Start Your SharePoint 2016 Migration Today at 11AM ET on March 2. Register now to secure your spot!