Practical SharePoint - Lessons learned from living the daily SharePoint experience (part 1)

Forward: Please note that this post (which I intend as Part 1 in a multi-part series) relates mostly to my background with SharePoint, what our implementation of the product is like, and initial personal and coworker impressions. The next post in this discussion will delve into the lessons learned from our deployments. Feel free to skip to the next post (link will be added here when complete) if you are looking for a quicker read.

As a relative SharePoint novice as of four years ago, I have transformed into my company’s resident expert. I have been the driving force for two successful SharePoint roll-outs/reimplementation/adoptions; I know my coworkers are smiling at the “successful” adjective, but it is true. From the initial statement of purpose, the design of individual sites, the migration of company projects, site administration, the troubleshooting of user experiences, writing a multitude of SOPs, and even small-scale coding, I have had a crash course in living the SharePoint reality.

The first question I typically get when I speak about SharePoint is “What is SharePoint?”. To me, SharePoint (on its most basic level) is an information database presented in a webpage format. All data entered into SharePoint occupies a field and is assigned an ID. For example, a calendar on a SharePoint page may contain information such as date, time, and a body of text. Each of those items mentioned are stored as individual entries in the database that is the calendar. If you have multiple entries in a SharePoint calendar, you in fact have rows of data (each row being a separate entry) with columns of data that equal the values that you have input (date = column 1, time = column 2, and body of text = column 3). The calendar itself is a visual way for you to see your entries in relation to one another. If you look through the ribbon menu (the oft-hidden menu in the top-left corner of most SharePoint online pages), you can change the view of those calendar entries into something else; examples include a Gantt chart and a simple list. Continuing this thought process, everything in SharePoint (from task lists, announcements, discussion forums, etc.) contain rows and columns of data that make up the overall database. SharePoint itself is the visual representation of all of this data in a way [hopefully] meaningful to an end-user.

For our purposes, SharePoint started out as a way to share information within and between separate departments (remediation, due diligence, human resources, accounting, etc.), to centralize company-wide communications, to assign work, to provide approved document templates, and to track drafting & field projects. After two years of using SharePoint for these purposes, the decision was made to expand our investment in the product to include the management of individual projects and to store all project information. If you have experience in the environmental industry, you will understand that this involves thousands of projects (active and inactive). To move to this next step in SharePoint implementation, we conducted the following tasks:

• Invested in Office 365 company-wide. This is a subscription product from Microsoft that includes SharePoint Online;
• Migrated all active project data from an internal server to individual SharePoint team sites;
• Configured individual computers to interact with SharePoint based upon best management practices (BMPs) that were discovered/worked through; and
• Trained staff on the power and usage of SharePoint.

For anyone that has rolled out a new software package either at your business (or even in your own home), you know that it almost never occurs free of tribulations. This is the exact reason why most businesses stick with well tested hardware and software; Windows XP/7 and Office 2007/2010 are both excellent examples. My first SharePoint rollout (SP 2007 if you are curious) was like this to an extent, but my second rollout (SharePoint Online/2013) was definitely more challenging. Moving our projects to the platform has required a broad change in company culture, required more hands on computer training, and exposed weaknesses/shortcomings in the technology that we use every day (including SharePoint itself). On the other hand, we are moving towards a more collaborate, connected (internally and externally), and technologically-savvy business. After working through the initial deployment, a long phase-in period, and an ongoing period of troubleshooting, we have reached (in my opinion) a plateau of stability. Factors such as internet speed, SharePoint “quirks”, interaction between SharePoint and different desktop software packages, and user training continue, but overall we have found how to make SharePoint work for what we need it to do.

As a conclusion to this initial post, here are a list of positives and negatives to SharePoint based upon my experiences:

Pros

• The product is very stable. We have had many more issues with power, internet access, and computer hardware than SharePoint itself being offline.
• Information stored on SharePoint is accessible 24/7 from any device with an internet connection.
• SharePoint is infinitely customizable, and includes a lot of built-in options to store and display data.
• SharePoint Online is relatively low in cost. As a part of an Office 365 subscription, you may be able to spend as little as $5/user/month. Please keep in mind that this includes a certain base amount of storage. Additional storage space may be purchased at any time for any amount.
• SharePoint allows for real-time collaboration on Microsoft Office documents. For example, you and your entire project team can write a report together at the same time.
• You may create and maintain outward facing sites for you and your clients to populate and exchange information with.

Cons

• Direct help from Microsoft has not been easy to come by. Most of the troubleshooting I have done has involved getting information through third-party sources.
• SharePoint speed is largely dependent on internet speed, hardware, software configuration, and internet browser of choice. Getting the right mix of the above has taken time and effort to fully realize.
• SharePoint is infinitely customizable. While largely a pro in my opinion, this is also a failing. For example, the ability to change the view for a data set (make a calendar into a task list or a Gantt Chart) or even move around the order of columns, is something the majority of our users either don’t think of or don’t know how to do. This can be solved with continued usage and training, but that comes with time. The default view of any piece of data can be tailored to that information and to the needs to the user, but most people want SharePoint to just work. That has been shown to not really be the case.

An additional point to consider is that Microsoft’s current software solution for syncing data between SharePoint and your computer is substandard. To solve the inherent speed difference between accessing (sometimes large) documents through a website as compared to a local/network file, Microsoft has an application (OneDrive for Business) that downloads a copy of SharePoint-based files to a user’s computer. This is a great idea. You receive all of the benefits of a cloud-based document storage solution, but you maintain the speed and ease of use of working on files locally. Unfortunately, the current implementation is flawed to the point of being unusable. Imagine working on a file and not knowing if you are working on the most current version. Imagine if you worked on a document, but your changes didn’t sync back to SharePoint. That is the current OneDrive for Business reality. Microsoft is actively trying to fix this. They recently (December 2015) released a new version of this application that fixes these syncing issues, adds in the ability to selectively sync individual folders (rather than entire document libraries), and removes the limit on the number of files that can be stored in one library. Unfortunately, this application only works with data stored in a OneDrive for Business account and not for data stored on SharePoint sites. This obvious product shortcoming will supposedly be rectified sometime in 2016. For now, there are third-party syncing solutions or other methods of accessing SharePoint-based data.

In a follow-up post, I will detail what I found out about SharePoint during our roll-outs and data migrations as well as what has worked to make the daily experience workable for our needs.