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
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 Aligning SharePoint to Business Goals to learn more on this topic. Why is SharePoint Painful? – Poor Adoption 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 AvePoint Compliance Guardian, which helps address the first two bullets. Despite the great technology here, let’s not make the mistake of assuming that technology alone will solve the problem. Even with SharePoint 2016 and third-party solutions, investing in change management is as important as ever. For more on this, see my friend Jasper Oosterveld’s IT Unity article titled 10 Tips to Drive SharePoint User Adoption. Why is SharePoint Painful? – No Actionable Governance A third reason why SharePoint can be painful is that most organizations lack an actionable governance plan. I know what you’re thinking: “Oh, please. I know all about that. I created a governance plan last time and it sat on the shelf. What a waste of time!” Hold on a minute. If it sat on the shelf, you went about it all wrong. Was it actionable? Did you incorporate it into training and user adoption? Did you have an easily digestible version of it? In other words, did it help users answer some of these file-management questions and others like it? You see, governance isn’t just about boring policy and procedure. It’s about guiding information workers to do the right thing. It’s about helping them see the value and making a difference in their daily tasks. It’s about ensuring collaboration is done in a unified way so that knowledge sharing is not an empty promise. I beg you to rethink governance in this way. You don’t have to call it governance. Give it a better label and align it to the specific goals you have established. See the whitepaper SharePoint Governance: A Definitive Guide, written by Jeremy Thake, Richard Harbridge, and me for a thorough discussion on how to do this. Test Drive SharePoint 2016 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 Office 365 Planner is a great way to go to manage project plans and assign tasks. But, later you realize that Project Online is a more complete offering and decide to switch. Start SmallIt’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!