Planning Your SharePoint 2013 Solution Strategy

This chapter is from the book

Essential SharePoint® 2013: Practical Guidance for Meaningful Business Results, 3rd Edition

Learn More Buy

This chapter is from the book

This chapter is from the book 

Essential SharePoint® 2013: Practical Guidance for Meaningful Business Results, 3rd Edition

Learn More Buy

SharePoint Strategy Roadmap

There are several key questions you need to address as you plan your SharePoint strategy. We discuss the first three steps of the SharePoint strategy roadmap in this chapter and focus on the remaining topics in subsequent chapters of the book. The key questions are illustrated in Figure 2-1.

Figure 2-1. A SharePoint strategy roadmap

• What are the key business objectives or scenarios that you want to enable? How can SharePoint address these key business objectives? If the answers to these questions are unclear, the project should not proceed.
• Who are the primary stakeholders for these scenarios? These may include the CIO, the chief knowledge officer (CKO) or the person or team responsible for knowledge management, or business leaders in areas such as corporate communications, marketing, and human resources, among others. The stakeholders may be very different for different types of business problems.
• Which capabilities of SharePoint 2013 are relevant to the business problem?
• How will the organization measure the business success of the SharePoint initiative? In other words, which key business goals does the SharePoint solution address? Remember, technology solutions are not successful just because they are free of software defects. Successful solutions must be designed to have an impact on business objectives. The topic of planning how you will measure success is so important that we have given it a chapter of its own in this book. See Chapter 8, “Developing a Value Measurement Strategy,” for an overview of a practical approach that you can use to measure the value of the investments that your organization has made and will make in SharePoint.
• What processes are needed to ensure that all of the SharePoint users are aware of and accept their roles and responsibilities with regard to the SharePoint solution? This topic is discussed in Chapter 4, “Planning for Business Governance,” and Chapter 5, “Planning for Operational Governance.” It is important to consider the type of technical resources, infrastructure, and overall IT support you have and what you will need to learn to implement the new technology and migrate your existing environment. You may want to consider getting outside help or at least make sure that your existing staff has adequate training to plan and support the new SharePoint 2013 environment.
• How will you plan for both the design and ongoing maintenance of the content in SharePoint? Accurate and relevant content is the foundation of your SharePoint solution. Your strategy needs to include a plan to ensure that content remains relevant over time. This topic is also discussed in Chapter 4.
• How will you launch and deploy to ensure successful adoption? What types of communications and training do you need to provide for users? How will you ensure that your solution is adopted? Your rollout strategy needs to prepare both users and content for the new SharePoint solution. The strategy needs to include a communications plan to make sure that users are aware of and, ideally, eagerly anticipate the business value of the new SharePoint solution or solution capabilities. In addition, the strategy needs to include a plan for launching the new solution and training users. These topics are discussed in Chapter 7, “Planning Your Adoption Strategy.”

What Is the Business Objective?

In the Wizard of Oz, Glinda the Good Witch says to Dorothy, “It’s always best to start at the beginning.” This advice is not just appropriate for starting out on the Yellow Brick Road; it also applies to SharePoint. The first step on the road to SharePoint success is making sure you have a good understanding of the business scenarios that you are trying to enable—and how important those scenarios are to the organization. In successful SharePoint implementations, business and IT stakeholders carefully frame the SharePoint project with clearly defined business goals and objectives that are used to guide the decisions that need to be made during the solution design and ongoing operations. More often than not, the key issues influencing the success of a SharePoint solution are organizational and political. Technical issues rarely derail a SharePoint project. As a result, it’s particularly important to document why you are building the SharePoint solution in the first place and to ensure that all key stakeholders agree on the objectives.

Every organization has a strategic plan, though some may be more formal than others. It is often extremely helpful to start your SharePoint planning effort with that documented plan because it can help guide your understanding of the relative importance and business value of the scenarios you can (or should) enable with SharePoint. Earlier in this chapter, we discussed the types of business scenarios for which SharePoint is particularly well suited. The relative importance of these business scenarios is different for different types of organizations and organizations of different sizes. It’s worth reviewing your organizational strategic plan because this document will provide the clues you need to understand how to position SharePoint strategically in your organization. Why is this important? Because your goal should be to tie the specific objectives for your SharePoint solution to one or more strategic objectives of the organization. Doing so enables you to ensure that your SharePoint project stays front and center in the organizational agenda and to minimize the risk of becoming number 11 on the organizational top-10 priority list. In other words, you want to avoid becoming the project that gets done “in our spare time,” pretty much ensuring that the SharePoint project is not a career-making experience for the people working on it.

In addition to the business objectives and scenarios described earlier, there are other common business drivers that encourage organizations to consider SharePoint. Some or all of the following business objectives will probably resonate for your organization. If you can tie these specific objectives to your overall enterprise strategic objectives, you will be in even better shape to ensure that the right amount of attention and focus is directed to your SharePoint project. Sample business objectives include:

• Provide an organized “one-stop shop” for information by making it easier to find authoritative information.
• Provide easier and timelier access to the information employees need to get their work done.
• Improve the ability to share and exchange information across the organization by providing an electronic publishing method that is easy for users to leverage and assures “one version of the truth” for shared documents.
• Improve the ability to find and leverage expertise.
• Improve organizational learning by providing easier access to critical information and organizational memory.
• Improve the “time to talent,” the speed with which new employees become productive.
• Reduce training costs for enterprise applications by providing a consistent user interface to all applications.
• Improve time to market for proposals and contracts by providing easier access to reusable assets.
• Improve decision making by providing an easy-to-use interface from which to review key business metrics.
• Improve project execution by providing an opportunity for work teams to collaborate and to electronically store project information in fully searchable, organized team sites.
• Maximize the reuse of best practices across the enterprise, enabling the organization to replicate successful business practices in all geographies.
• Provide more effective mechanisms to move work between business entities, such as self-service for customers or partners or enabling outsourcing by providing business partners with access to a collaboration environment or business data on an extranet.
• Improve customer service by providing direct access to the information customers need.

Table 2-1 Mapping of General Business Objectives to SharePoint 2013 Features

Who Are the Stakeholders?

Who are your key stakeholders? As in most cases, the answer is that it depends on the specific business scenario you are enabling. Clearly, the executive for the sponsoring organization is an important key stakeholder. This individual will likely be your project sponsor. For intranet solutions, this is often the director of marketing or internal communications but can and should also include the executive in charge of knowledge management or quality or human resources. Including stakeholders from business groups outside communications will ensure that your intranet is not just about communications but will also effectively enable your collaboration strategy. For extranet portals, the stakeholders may also include key executives from an operational business unit. When you look to identify stakeholders, recognize that there are different types of stakeholders, all of whom should be included in the development of your solution strategy and ongoing governance model. Business executives should be included in the stakeholder community to provide overall direction and validate that the SharePoint deployment is critical to achieving business objectives. IT managers should be included to ensure that the solution meets IT standards for operations and development. Content providers should be included since great content is the key to valuable solutions of pretty much any type. Users should be included to ensure that the SharePoint solution rollout addresses more than just executive objectives and concerns.

Remember that while the executive sponsor may have the “grand vision” for the solution, the solution’s users are critical to its ultimate success. Users need the solution to be easy to use in the context of their work and need to be able to see “What’s in it for me?” For example, the key stakeholders for an intranet project to support a university should include administrators, faculty, and students. If the solution is externally facing, the “customer” community might be represented by examining the perspective of applicants or prospective students.

Keep in mind that if you choose to enable the social computing functionality available in SharePoint 2013, everyone in the organization, and even potential guest users in some scenarios, is both a producer and a consumer of information. Social features provide a rich and engaging opportunity to improve the ability to break down organizational silos and enable expertise location scenarios. However, enabling these capabilities requires a greater understanding of your organizational culture and user stakeholder community than if you are not leveraging these capabilities.

As you think about your key stakeholders, it’s important to acknowledge the partnership that IT and the business will need to have in order to be successful with SharePoint. Because the success of SharePoint solutions is critically dependent on business user adoption, it is imperative that business stakeholders take an active role in solution design and governance planning and that IT staff fully understand how the solutions they build address business needs. A successful implementation often includes both process reengineering and culture change. A well-coordinated business and technical approach is essential to adoption.

In many organizations, the IT group is separated both physically and “emotionally” from the organization it is designed to serve. SharePoint projects provide an important opportunity for IT and business owners to collaborate.

One way to ensure that your SharePoint project will fail is to have IT build the solution without engaging a broad spectrum of potential users. In the past, technology projects were primarily driven by IT organizations. Many of these early solutions failed to gain user acceptance because they were essentially IT-only projects—driven by IT with limited user input. Today, more and more SharePoint projects are driven (and funded) by business users, though they are clearly dependent on IT. Many intranet projects are sponsored by the corporate department responsible for internal communications (though this may have the not-so-positive impact of the intranet being too communications-focused and less about enabling getting work done). One or more business units may fund and drive an external or customer portal or Web site initiative. As a result, it is critically important for IT to work with the sponsoring business unit as well as all key stakeholders to ensure that the inevitable trade-off decisions that will be made during solution design and development are made in favor of the business stakeholders as often as possible.

IT managers who fail to take advantage of this opportunity put their projects, and potentially their careers, at risk.

Which Capabilities Are Relevant?

It is critically important to document business objectives at the start of your SharePoint initiative and to keep these objectives top of mind as you design and build your solution. Use the business objectives to guide your decisions about which features should go in each release of the solution and which features might not be relevant for your organization. Ask stakeholders to prioritize their business objectives so that you understand how to make trade-offs between alternative design approaches.

Stakeholders often have a very difficult time articulating requirements for SharePoint solutions, especially solutions that enable new ways of working together such as the capabilities enabled in the new SharePoint 2013/Yammer Newsfeed. This is because it is virtually impossible to envision how the solution will help solve business problems until users see the solution with “real” data or try the solution for a personal scenario. When users do express requirements, they may express them in very specific ways, which could require a significant amount of custom coding. However, if you understand the objectives or outcomes users are trying to achieve, you may be able to accomplish them using out-of-the-box or minimally customized functionality. To accomplish this, you will need SharePoint experts, both business analysts and developers, who know what you can and can’t do easily. You may also need to create a small demo of some specific capabilities or features that you can show your stakeholders as part of the discussion about business scenarios. You really can’t gather user requirements for SharePoint solutions the same way you do for a traditional software development project. Instead, solicit and try to understand business objectives. You can then, as a design team, derive requirements based on the business objectives and outcomes, and based on the feedback you get from providing a demo of the capabilities that are particularly important. It is critical to ensure that you understand the strategic objectives for the organization, the business objectives for SharePoint in general, and the specific business scenarios for the solutions you will enable with SharePoint.

For each possible business objective, there are numerous SharePoint features you can implement to help enable that objective. Table 2-1 presents some of the features of SharePoint 2013 that you can leverage to explicitly accomplish your business objectives with indications where a feature is either new or significantly enhanced from SharePoint 2010. Use this table with great caution, however. Just because a feature can help achieve a business objective doesn’t mean it will. People achieve business objectives, not software. While well-designed software solutions can enable people to achieve business objectives, simply implementing the features in this table will not guarantee that you will achieve the desired business outcomes.