In recent months I have had a lot of conversations both internally and externally with clients and peers on the importance of setting strong SharePoint objectives from the onset of your project. The discussion takes a number of twists and turns along the way prior to an agreement on what is “most important” in that process. It is very much a chicken-and-egg discussion about what should come first, what should be implemented second, how it should be communicated and adopted across the organization, and so on.
One of the things that jumped into the forefront of this conversation is that you must align your project with your organizational road map before taking even the smallest step forward. Your organizational road map is (hopefully) an established document that maps out the life cycle for your business critical systems and policies for the next three to five years.
With that alignment and commitment to SharePoint and line-of-business systems in place, you can begin setting some of your objectives. This is where I have seen organizations fail. Failure to set your objectives doesn’t necessarily mean that you have created something that is “wrong”; rather, it means you have created objectives that your organization simply can’t meet, or, moreover, will not bring the concept of enterprise SharePoint forward.
For example, Company X deploys SharePoint to their organization, and months later it polls their users to get a sense of what features they’re using and where the system has been effective for them. Their findings indicate that the company is solely focused on using SharePoint as a document-management system. No one in the organization has been using its portal or collaboration features, or its workflow or BI capabilities. This has executives shaking their heads, as the company implemented SharePoint brilliantly, migrating thousands of documents and decommissioning its legacy system per the specifications of their project schedule.
Furthermore, the move provided the internal ROI expected when the company shut off the legacy server and freed up people who happily went on to other projects. They even had a party to celebrate their success.
The problem is that even though they implemented SharePoint effectively, they are not getting the enterprise benefits of the system.
Did Company X meet their objective? Yes. Did they implement it based on Microsoft’s expectation of an enterprise system that is used across the organization? No. Why? The company inadvertently implemented a non-enterprise application (silo) for a single department without consulting other business units or enabling the enterprise features that can only improve the overall business and their bottom line. The failure is in not setting the correct expectations and gathering enterprise requirements that align with those expectations, as well as not assessing their data needs and analyzing the critical business processes they should have been trying to create in SharePoint.
Why is this a bad thing? For many reasons, beginning with frustrated employees who were expecting a more robust working system that provided automation. It’s also frustrating for the advanced user who was hoping for integration and the ability to surface up working data from other systems. These issues bleed to user adoption and training problems, which can be debilitating and near-impossible for a business to overcome, not to mention the fact that decision-makers don’t have the information they need to make business-critical decisions.
This leads me back to setting the objectives you need for a successful enterprise implementation. What is important to your organization are your data and the critical business processes that make you stronger, better and faster than your competition. To begin any implementation or conversation about an implementation, start by identifying relevant structured and unstructured information from whatever disparate database or system it has been derived. Next, find out what data is being surfaced or accessed by your staff and investigate whom it is being made available to in a consistent and trusted fashion. Remember that you must look at both who accesses data and who has access to the data, as they can be two very different lists.
With these two foundational business systems and practices in place, you are now prepared to define and automate your critical business processes so that the organization’s core competencies are being performed with the same level of excellence that the organization demands, regardless of whoever creates a process. If they are not, the variances will be obvious to management.
Notice that in creating the above objectives I did not once use the words “functionality,” “SharePoint” or “design.” The reason is because, at the onset, these components do not matter. What matters are the data that you have, the data you want to enter and how they will interact with your existing systems and staff members.
By following these initial objectives, you can be certain that you will have a resulting solution with the vital information that decision-makers and knowledge workers need to manage the organization, make appropriate decisions, and constantly determine whether the organization’s operations are continuously aligned to strategic objectives.
Eric Riz is the eExecutive vVice pPresident of Concatenate, creators of the RealTimee suite of products, based in Toronto. A SharePoint MVP, 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 and catch his sessions at SPTechCon San Francisco April 25-28, 2014.
