SharePoint Best Intentions – Planning versus Reality
In my excitement for SharePoint 2019 two weeks ago I published an article on the 5 Things you Can do to Prepare for your upcoming SharePoint 2019 migration. Last week I covered the first step, Dig Deeper into your Farm in greater depth. This week I’m going to spend some time on the second step, comparing your current SharePoint environment to the plan you put into place when you created it.
I think we all agree that Mike Tyson is an American treasure. And while I’m not a big boxing fan I’ve always enjoyed his often quoted, “Everybody has a plan until they get punched in the mouth.” By nature, I like to plan things out, and this quote reminds me that while planning things is important, we have to be realistic about all the curveballs life is going to throw at us.
While I find planning and governance a little less fun than dental work, I recognize that both are important in the long run, so I force myself to suffer through them. And while I know that those plans will likely not be followed, they do serve as a blueprint of sorts. They’re like my car’s GPS, they give me a general idea where to go, but I pepper its advice with what’s really going on. If it tells me to drive through a barrier and off a cliff, I don’t.
Say Goodbye to Traditional PC Lifecycle Management
Traditional IT tools, including Microsoft SCCM, Ghost Solution Suite, and KACE, often require considerable custom configurations by T3 technicians (an expensive and often elusive IT resource) to enable management of a hybrid onsite + remote workforce. In many cases, even with the best resources, organizations are finding that these on-premise tools simply cannot support remote endpoints consistently and reliably due to infrastructure limitations.
My SharePoint governance documents are the same way. I try to map out how the farm should grow. These are farm architecture decisions like when we should create site collections as opposed to webs, how large we should let site collections get, how many site collections per content database, how large should we let content databases get, when do we add additional web front ends, when do we add additional Search servers, and so on. It also includes content architectural decisions like the use of metadata versus folders, when to require tags, where to require checkout, where to use workflows, etc.
These are areas that as a SharePoint admin you should have an idea what’s best for your environment. You should come to these decisions based on a few factors. You can start with your knowledge of the product. For instance, as a SharePoint admin we know that the larger content databases get, the tougher they are to deal with, so we should try to find a size that we can manage and try to move our farm towards that. We know that as lists get large their behavior change. If that experience will negatively impact our users, we should see if we can keep our lists below those thresholds. But we also must take our users into account. We need to have an idea how they use SharePoint and find the best compromise between the technical aspects of SharePoint, and the needs and wants of the people that will be using it each day to do their jobs.
So we take what the software can do, mix it with what the users want to do, and we make a plan. A good plan, dangit! We document that plan. We guide our users in the direction we want them to go. We believe in that plan.
Then we get punched in the mouth.
That punch can come from a few different directions. It can show up as a limitation of SharePoint that we didn’t know existed when we made the plan. This happened to one of my customers when SharePoint 2013 came out. After some testing, we decided to move our workflows from the built-in SharePoint 2010 workflow engine to the new Workflow Manager server that you could attach your SharePoint 2013 farm to. The separate Workflow Manager seemed to be the direction Microsoft was heading, and it had some nice options its SharePoint 2010 counterpart did not. The plan was made. In reality, we found SharePoint’s connection to the Workflow Manager server was unreliable and workflows would randomly not fire off. After months of fighting it, we changed the plan and started recommending users still with the SharePoint 2010 style workflows. Punched square in the mouth.
In other cases, that punch in the mouth comes from the users themselves. I don’t know about you, but as a SharePoint administrator, I’m a horrible SharePoint user. I don’t see the product from that side nearly as much as the users do. I might come up with a plan that looks great on paper, but the users may find a better way to do it as they interact with SharePoint every day.
When you’re preparing yourself for the upgrade to SharePoint 2019 it’s a good time to dust off that old Governance document and see how well it’s stood up to reality. Did you really scale with site collections the way you intended? Did you create too many site collections? Did that brilliant idea to force metadata on documents really help Search results, or did it just result in a bunch of non-sense metadata getting added to documents so users could get it checked in?
Hopefully, you’ve chalked up more wins than losses, but the losses are good too. They help you understand how your user base is using SharePoint, and they help you improve it for them when moving to SharePoint 2019. It also gives you the opportunity to tweak those policies and get your users started down the right path before SharePoint 2019 comes along. Any kind of work you do now, be it adjusting policies and best practices, or cleaning site collections and databases just helps future you out later on. We’ll cover that more next week when I talk about my favorite upgrade and migration advice of all, “Don’t upgrade crap.”