Defining a SharePoint 2013 IT Strategy Part II

By Danielle Arad - March 1, 2013
7 min read

This is part two of the Defining SharePoint IT Strategy article. If you have not read the first part, please see this first.

Q: Who needs to be involved with the process?

A: A variety of organizational personnel will be involved in the development, execution, and analysis of any IT strategy at different times. The key to success is the input from IT and business management who have the ability and authority to assign resources to the project, and to authorize business initiatives as they relate to SharePoint.

Because a strategy is not a single project, there generally is not a single business sponsor, but rather senior members from both the IT and business sides of the organization. To increase the chances of success, these individuals should be involved from the beginning of the strategy defining process. The business sponsor is responsible for communicating the overall objectives they seek to accomplish with the assistance of IT. During this dialogue, the IT sponsor is responsible for understanding the high-level feasibility and risk as well as the desired functionality; this is the Risk Registry. Once these items are understood, the IT sponsor will need to come back with the proposed IT strategy to meet these goals. It is the IT sponsor’s responsibility to understand the resources required to ensure successful execution of the IT strategy. Initial resources to consider may include IT personnel, operational personnel, and helpdesk personnel.

Your advocates may come from various disciplines. A good place to start would be the management teams of those individuals most likely to benefit from the prioritized list. However, do not forget resources that help to drive the adoption and solicit feedback once your solution is live. If you work in the IT department, you may witness continuous requests for IT resources or initiatives with the SharePoint platform for business users. This is good, because they see you or your department as a strategic asset that can help them solve problems. If this is the case, then some of these requestors should attend the SharePoint workshop or at least see the post-workshop findings.

If you work in the IT department and the business community in your organization does not make requests, then there is a chance your department is not viewed as a strategic asset and you may be even viewed as an operational cost. If this is the case, the workshop is an opportunity to bring perceived value to the business.

Q: Do I need to get the CEO involved?

A: A typical IT strategy does not require the CEO’s hands-on involvement. However, an IT strategy, at the end of the day, truly serves only the corporate strategy. Ultimately, there is really only one true strategic player in the organization: the CEO and his or her counterparts on the board. All the other officers of the corporation must use their respective departments to help the CEO execute the company’s strategy. Most business units align their activities to the corporate strategy and similarly, IT must wrap its strategy around the business’s. Therefore, by all means, share your finding with the CEO to demonstrate that your department is supporting the corporate strategy. Most CEOs care about dominating a market or increasing sales and not necessarily whether or not you have a deployment plan for any product. So the last thing you really want is a non-technical person being very influential with an IT strategy that they don’t understand.

Q: Why is a SharePoint strategy different than other IT products?

A: It is because SharePoint is a platform. It can be difficult to define the functionality that has or could have been deployed to the business, so the milestones/endpoints are different than those for a typical application such as a CRM system. Also for a SharePoint strategy to become a deployment reality, there are several dependent technologies that SharePoint relies on, which need to be in place and set up correctly for the initiatives to work. For example, user profile synchronization needs to be configured appropriately with Active Directory in order for the organization chart in My Sites to work.

You will read “SharePoint is a platform” endlessly throughout this book. So what does this mean? A platform has multiple functionality that can be applied to different applications such as search, workflow, document management and content management, and .NET development, which takes time to configure and deploy within an organization.

An application is like Microsoft Word, a program that is very clearly defined for the single purpose of writing documentation. As stated many times in this book, SharePoint is a platform for web applications to be developed on. This is why SharePoint can be difficult to define and describe to people. Another term you will hear is that it is the Swiss Army knife of Microsoft’s web offerings, because the tool has many blades. Microsoft will often explain SharePoint with the pin wheel.

Given SharePoint’s broad functionality and its potential to be used by any employee in an organization, defining a strategy can be a challenge. This is unlike a Customer Relationship application where generally only the sales and marketing departments are involved and processes are already defined.

Another reason why defining a SharePoint strategy is unique is because employees may have had an experience with SharePoint at a previous job, and want to repeat this experience again. What they often do not realize is that their previous experience may have consisted of a customized SharePoint environment, or one augmented with third-party components. These employees end up surprised and disappointed when their expectations don’t comply with the current deployment.

It is essential to educate the user community about SharePoint if you really want to leverage its functionality. It is important to gauge the level of interest and time that business users have and are willing to spend on SharePoint awareness.

Q: Why do we really need an IT strategy?

A: In short, the strategy will help prioritize IT efforts to support the business requests. The key aspect of an IT strategy is to manage expectations of both the business and IT department so that both parties know what to expect and when.

In the first figure of the article, there is a clear roadmap of SharePoint deliverables for the business so budgets can be defined and resources allocated. The details of how this is done do not necessarily need to be agreed upon in the strategy meeting. In fact, given that the budget is not defined at the workshop, some initiatives may not be feasible.

By having an IT strategy for SharePoint, return on investment can be identified with some effort and initiatives being approved and prioritized.

Without a strategy, there is normally a passive approach to a SharePoint deployment, where initiatives are not coordinated among departments and low value processes are used with SharePoint, such as fancier and more expensive set of shared drives rather than a usable ECM system with findable information assets.

Research by AIIM stated that half of SharePoint implementations proceed without a clear business case (which shows lack of direction from the start); only 22 percent of the organizations provide users with any guidance on corporate classification and use of content types and columns; one third of the organizations have no plans as to how to use SharePoint, while one fourth of the organizations say IT is driving it with= no input from information management professionals.

Q: Any final words of advice on this?

A: Rushing off to “the next big thing” after completing a phase or a project of the first phase of the strategy road map is a bad idea. But even in the most successful projects, there are usually items still remaining. Additionally, after a few weeks or months “in the wild,” the people using the fruits of your labor may have some great and often simple-to-implement ideas for improvement. However, the project is complete, deployed to the specified scope, and your resources are working on another project.

This problem often happens with SharePoint projects, when phase II functionality is urgently required to meet business expectations and perhaps prevent an initiative stalling, yet the additional resources and perhaps an already large investment of time and money is allocated to other projects.

This is typical of SharePoint projects partly because the end user actually knows what they really want, once they realize that they have to use SharePoint and experience what they requested.

In short, a small additional effort can have dramatic effects, accelerating and amplifying results. Therefore, you may want to factor in a six-month revisit on projects and should not be afraid to move projects out of phases, or even eliminate them if the business value will be trumped by a phase II project.


This article is an extract from the book: Microsoft SharePoint for Business Executives: Q&A Handbook co- written by Peter Ward