Over the past nine years, I have observed that the uses of SharePoint at most companies come in one of two basic scenarios.
These sites are generally created from the Team template and contain one or more document libraries which can have very complicated folder structures. There is very little use of content types, metadata tags, or workflows. The sites are fully supported by the business unit, whose members have no formal understanding of SharePoint and have not embraced the “Power User” role. The site was created by the infrastructure or support team who can quickly generate a site from a simple help desk request ticket.
Usually, these are much larger sites with a much larger audience: Corporate intranets, corporate HR, and corporate IT sites are the usual candidates for this type of SharePoint usage.
These projects usually start out with great direction and expectations. They are sold as a low-cost alternative to many of the high-end, expensive content management systems (CMSes) the business has already investigated. Then as the project moves along, the requirements morph and become more complicated. It needs more custom code, which eventually becomes complex enough that supporting the code becomes an issue.
From here things usually spiral out of control. The development team has given up on the premise of staying with out-of-the-box (OOTB) functionality with a limited code base. Instead, they have a fully customized approach, ranging from fully customized Master Pages to possibly a provider-hosted app (PHA) or—as they now call it—a provider-hosted add-in.
I can already hear the sighs and see the eye-rolling. “Tony, these are perfectly valid utilization approaches.” “We have both of these and our users love the sites and we have no issues supporting them.” I am in no way claiming that either of these methods are wrong, nor that one is advantageous over the other, but I do believe that both approaches simply miss the opportunity to fully utilize what the SharePoint platform has to offer.
I further believe that these two models result in the business feeling like SharePoint is way too expensive for what they use it for, or that the IT department feeling that they could have simply developed the same functionality through web servers and HTML pages or a canned CMS cloud solution. Either opinion leaves both the business and IT feeling like SharePoint does not appear to the be the right tool for their needs.
In order for us to better understand where we are, we need to step back and review how we got here.
I am going to take you back to the simple question of “How did you hear about SharePoint?” From my personal experience, and the experience of many other IT leaders whom I have spoken with, SharePoint as a technical platform was introduced to the company from the infrastructure team with the assistance of their Microsoft Enterprise advisors.
Usually, the first SharePoint farm is a sort of test bed that is given to the company as part of their Enterprise Agreement with Microsoft. At this point, most companies engage a business client and deploy their first site collection with a single team site. The business client loves the document libraries and the ability to collaborate and share documents and so starts to use the site as part of their business processes.
This may sound perfectly acceptable to many of you and, in all honesty, can be a viable use case for SharePoint. But once you delve into SharePoint a little deeper you realize that it is so much more than just a platform that the infrastructure team implemented and supports: It’s a robust application space that requires the tight collaboration of the infrastructure, enterprise architecture, and application teams.
I am not an “anti-infrastructure” person or someone who is politically opposed to the infrastructure team, but without the collaboration of the correct partners from the very beginning, you run the risk of not understanding the full scope of the SharePoint platform and therefore are unprepared for the appropriate business strategies and utilization plan. This situation is not unique to the SharePoint platform and points to a much larger issue of proper collaboration and strategy, one that is facing many IT departments.