On the heels of my three-part series on governance, I thought it timely to write something on adoption, the logical conduit between SharePoint governance and implementation. It would be difficult for me to count the number of times we have consulted on projects with adoption issues—seemingly perfect implementations that failed to have the functionality adopted enterprise-wide. These conversations and consultations typically begin the same way, with clients asking us to identify or specify why the implementation was not adopted with the review of some documents and a snap of some fingers.
This is not a simple task where we can thumb through a manual and proclaim something specific that failed. It is never about identifying something specific; many times the analysis develops into more of a systemic issue than an individual item. By systemic, I mean something across the enterprise that was not seen as vital to end users but was supposed to drive the adoption.
Naturally, it is very difficult to identify a specific reason why something did not occur as planned. Additionally, it’s a politically complex task, as many are reluctant to admit any type of failure with their shiny new SharePoint system, particularly when you are speaking to the owners of the system, or to the department that was responsible for bringing it into the organization.
When the conversation begins, we start asking the normal questions you would expect: What were the original parameters of the implementation? What were the expected deliverables? How did you gather your initial requirements? Recently, we have started asking questions that are focused more on strategic vision and alignment to the business or IT road map, instead of the potential pitfalls of Web Part configuration or things promised that were not delivered.
With these recently added questions in mind, I shifted the conversation and perspective on its axis. What would happen if SharePoint was rolled out as planned, but people came to the realization that it was not implemented against a core set of values or in alignment with the organizational strategy? Could this ever happen to your company? It certainly can.
What we have seen recently is a change to the normal implementation of document-management, portal and search functionality. Businesses are pushing the limits of SharePoint to greater heights and depths; they are demanding a more inclusive system that operates as the go-to place for information, and one that also operates as the central hub of line-of-business systems. If users want information, they should be able to go to SharePoint and have any data surface.
This is specifically what Microsoft’s Business Critical SharePoint (BCSP) program is designed to do: challenge and change the common perspective. And it’s just one of the reasons why SharePoint may not have been adopted. As a member of the BCSP program, we have seen these perspectives change in recent months, and we have changed our methodology to accommodate this shift.
With this article, my challenge to you is not just to identify any missed elements in your adoption (which could have been the result of any standard reason), but more so to extend your perspective and align yourself strategically. The risk you run is not just an issue of an implementation not adopted, but one that may end up having to be completely redesigned from the ground up.
For example, take an implementation that focuses on replacing your aging “H” drive (you know, the archaic system that is long-overdue to be tossed in place of a workable, searchable system). A business that stood up SharePoint as a document-management replacement in order to facilitate search and to decommission the H drive may have made a considerable error in its setup.
The risk is foundational, like a building. The foundation of your SharePoint system has to be created with equal depth and consideration in order to scale and build accordingly. If the files were simply pushed over with no attention to taxonomy or metadata, you will not be able to build on top of the system when it comes to designing workflow and business processes.
On the strategy side; be sure that the original strategy was effectively laid out when the project was initiated. Your SharePoint vision should align with your IT strategy and road map. There should be logical connection points between the business need and functionality that has been or will be rolled out.
Finally, get together with the different business units involved and ask the tough questions needed to either vet your successes or change your direction. Letting SharePoint “exist” in your organization is not the goal here; the goal is to implement a system that will change the way you perform your business responsibilities on a day-to-day basis. If this isn’t the direction of your system, it’s time to make some changes.
Eric Riz is the EVP of Systems Integration for Concatenate, a software firm focused on maximizing SharePoint through product innovation and systems integration based in Toronto. You can reach Eric by e-mail at ericr@concatenateinc.com or on Twitter at @rizinsights. Read his other SharePoint thoughts on his blog at www.ericriz.com.
