Essential SharePoint 2013: Practical Guidance for Meaningful Business Results (2014)
Part I. Planning
Chapter 2. Planning Your Solution Strategy
According to Microsoft market research, nearly 80% of Fortune 500 companies are using SharePoint.1 Adding educational institutions, government agencies, small businesses, and nonprofits means that a significant number of people who go to work have access to SharePoint. But what does that really mean? Are all of these millions of SharePoint users getting value from the investments their organizations have made in SharePoint? It doesn’t take too much Internet research to find that the answer to this question is . . . “Not always.”
1. http://technet.microsoft.com/en-us/magazine/gg981684.aspx
Our goal for this book is to help ensure that your organization can deliver value with your investment in SharePoint. One of the most powerful lessons learned from all of the previous releases of SharePoint is that truly successful SharePoint solutions have a significant user focus: from design to implementation to training to persistent communications. With SharePoint 2013, Microsoft has truly embraced this learning and has even overhauled the way it positions SharePoint. Instead of focusing on what SharePoint is, Microsoft is now focusing on what you can do with SharePoint. Understanding what you can do with SharePoint and what organizational problems you want to solve or scenarios you want to enable are critical inputs to business success. The most effective way to think strategically about SharePoint is to first make sure you have a good understanding of the business2 problem you want to solve. Start with an understanding of what you want to accomplish, and then evaluate the features and capabilities of SharePoint that are available to help achieve the desired outcome.
2. Note that within this book, we will use the terms business and organization somewhat interchangeably. We know that not all organizations are businesses (e.g., governmental agencies) and that SharePoint is just as appropriate in these environments—but unless we specifically make a point related to a type of organization, when we use the term business, we mean any type of organization.
While Microsoft would like to position SharePoint by talking about what you can do with it, we assume there are people reading this book who need to frame their strategy by better understanding what SharePoint is all about. We begin this chapter with a discussion of what SharePoint isand clarify its role as an application, a platform, and a framework. The remainder of the chapter provides a roadmap for framing your SharePoint solution strategy.
SharePoint: What Is It?
In the past, a great deal of the confusion around SharePoint has related to the difficulty in defining what it is. SharePoint has been compared to a Swiss Army knife—multiple tools in a single package. The Swiss Army knife typically includes a blade as well as other tools, such as a screwdriver, can opener, nail file, and corkscrew. Similarly, SharePoint has some built-in capabilities such as file libraries, calendars, task lists, Web publishing tools, and blogs that can be used to solve a variety of organizational problems.
Just as the Swiss Army knife is not the right tool for constructing a house or making a complex recipe, SharePoint is not the tool that you will use to solve all organizational problems. SharePoint 2013 is positioned as the “new way to work together.”3 This simple definition helps put an appropriate lens on the classes of organizational problems that are appropriate for SharePoint—and on a way to answer the “What is it?” question. As stated earlier, rather than focus on what SharePoint is, Microsoft wants to change the question entirely and focus on how you can use SharePoint to get work done.
3. http://sharepoint.microsoft.com/en-us/preview/sharepoint-benefits.aspx
What does that mean? It means that there are classes of organizational problems that are well suited to SharePoint’s strengths, and those classes of problems are those that require collaborative work—both directly and indirectly. For example, SharePoint can be used to
Share information with your employees on your intranet: because this is where you collaborate and communicate with your employees. Internally, the information that you share is about both people and content—and SharePoint enables both document-based and conversation-based internal collaboration.
Share information with trusted nonemployees on your extranet: because this is where you collaborate with your current partners, suppliers, and even customers.
Share information with your organization’s teams and communities: because this is how day-to-day work gets done.
Share individual documents securely with people on an ad hoc basis: because this is how to get some control over the myriad document-sharing methods that put your organization at risk.
Enable ad hoc and more permanent conversations: because this is how people develop relationships and learn from one another.
Organize the information shared in each of these solution environments: because this will make it easier to find information consistently.
Showcase key business data from operational systems: because this will enable individual and collaborative decision making.
Manage the life cycle of the information in your organization: because this will ensure that your content is compliant with the business rules and legal requirements of your organization or industry.
Discover enterprise information: because this is how you can ensure that your users can get work done.
Share information about your organization on your public-facing Web site: because this is the site where you collaborate and communicate with your external existing and prospective customers, partners, and suppliers. Of course, not all Web sites today are collaborative, but many of the most interesting and engaging sites have a collaborative component.
SharePoint includes features that make it particularly well suited to deliver information such as documents, videos, blogs, discussions, expertise, and even business data. But the overall goal for SharePoint solutions is to provide an environment in which this information can be used to solve organizational problems.
Not to leave the information technology (IT) community out of the conversation, SharePoint also includes capabilities for developers to use to build these applications and for IT professionals to use to manage the risk, cost, and time associated with the solutions that are enabled with SharePoint.
Is It an Application, a Platform, or a Framework?
In the world of information technology software, we often refer to the tools that we use as applications, platforms, or even frameworks:
An application is computer software designed to help a user perform specific tasks.
A computing platform includes a hardware architecture and a software framework that allow application software to run—for example, the operating system and programming languages.
A software framework helps facilitate software development by providing generic capabilities that can be changed or configured to create a specific software application.
Are you confused yet? Well, so is the entire SharePoint community! For a long time, there has been a great deal of debate within the SharePoint community about whether SharePoint is an application or a platform or a framework. SharePoint has a little bit of functionality that could allow you to argue that it is all of these. In the past, SharePoint was positioned as a platform marketed to IT for businesses to build on to create the “center of gravity” for collaboration. Key elements of functionality were referred to as “workloads” that could be brought together to build solutions. The “workload” terminology never really caught on outside of Microsoft and the SharePoint consulting community—and has added to the confusion about “What is it?”
One of the reasons that the debate has raged for so long has to do with how easy it is to customize and configure SharePoint to do pretty much anything you want—that is, to use it as a framework. Unfortunately, by making things so easy to customize—by abstracting the details of the software code required to configure SharePoint enough so that business users can create complex custom solutions—Microsoft unintentionally introduced risk into many organizations because some of those user-created software solutions literally “brought the house down.”
Another reason for the debate has had to do with a general dissatisfaction with the SharePoint “look and feel.” There is probably no consultant or internal IT person responsible for SharePoint who has not heard a business sponsor say, “We’ll use it, but make it not look like SharePoint.” No business sponsors that we know of have ever told their IT folks or consultants, “We’ll use Microsoft Word, but don’t make it look like Word.” Applying a custom look and feel to Microsoft Word would be a colossal waste of corporate money—and it’s just wrong for so many reasons. But pretty much everyone wants to brand SharePoint. When you can completely change the look and feel of a software product, it doesn’t “feel” like an application, especially because when you go from one company to another, you might not be able to easily tell whether the Web site you are using is based on SharePoint or not—until you look under the covers.
With SharePoint 2013, Microsoft appears to want to stop the debating and define SharePoint clearly as an application—but not necessarily as an application with a single purpose. Unlike the Microsoft Word application, which has basically one functional purpose—to create documents—Microsoft considers SharePoint a multipurpose application—one that can be used to create other, highly “personal” applications, one that can be used as is to solve some specific collaboration scenarios, and one that can actually be used as a delivery vehicle to expose other applications (apps within the app, if you will). For some business scenarios, such as your public-facing Web site, it makes good business sense to not just configure how you want to organize and manage your content, but to also customize the look and feel of SharePoint to align with your corporate identity and the purpose and intention of your Internet site. SharePoint 2013 makes this much easier than with any prior version by providing capabilities so that any Web designer or developer can design a SharePoint site without having to become a SharePoint expert. Web designers can create beautiful state-of-the-art Web sites using the tools with which they are already familiar—and SharePoint will convert their HTML files to work with SharePoint automatically. For other business scenarios, such as your internal team collaboration sites, it may make more sense to leverage SharePoint much as you leverage Microsoft Word—as an application for which you spend far more time configuring how you will use it and less time on completely rebranding the look and feel. Minor cosmetic changes to include corporate colors and logos may be sufficient to support internal branding.
What’s New in SharePoint 2013?
Planning a strategy for SharePoint 2013 starts, as it always has, with an understanding of the business problem(s) you are trying to solve. However, while the basic scenarios that SharePoint enables are still fundamentally similar, the features and capabilities of SharePoint 2013 are differentenough that you will need to consider several key new areas when you are planning your strategy:
Social collaboration
Cloud computing
Mobile
Internet
SharePoint 2013 includes a rich new set of social collaboration capabilities enabling expertise discovery, conversations, and content evaluation that were previously supported only with additional third-party tools. Your users may hear about SharePoint 2013’s new Twitter- and Facebook-style activity stream that supports familiar social capabilities like #hashtags, @mentions, following, and “likes.” If you had previously considered internal social collaboration features to be of limited value in facilitating key moments of engagement within your organization, you should reevaluate these capabilities. Now would be the time to consider if these new social capabilities, which extend far beyond blogging and simple status updates, fit into your business strategy. For some organizations, these capabilities may be significant in driving an upgrade decision. Another new feature is the ability to introduce “gamification” attributes in SharePoint 2013 discussion lists. This new capability allows users to build “reputation points” toward up to five achievement levels by performing activities such as creating a post, replying to a post, achieving likes or a star rating of 4 or 5 for a post, or having a post marked as the “best reply.” These features can be very effective in engaging users in some but not all scenarios, so it is important to think about the specific scenario you are enabling and the culture of the community in which the features will be leveraged.
Note
If social is in your future, you will want to pay particular attention to Chapter 7, “Planning Your Adoption Strategy,” and Chapter 15, “Planning for Social Computing.”
Microsoft has made an even bigger bet on cloud computing with SharePoint 2013, going so far as suggesting that some new capabilities may be available in the online versions of SharePoint prior to the more traditional on-premises versions. (For example, opening up a site collection for easy access by users outside your organization is a feature that is available only in SharePoint Online.) There may be very valid business and technical reasons why SharePoint in the cloud is not appropriate for your organization, but “cloudy with a chance of SharePoint” is a key theme of this release—and you shouldn’t act as if the cloud doesn’t exist—even if it doesn’t apply to your current strategy.
Note
For more information about how using SharePoint in the cloud (SharePoint Online) might fit into your strategy, refer to Chapter 11, “Taking SharePoint to the Cloud,” which covers the pros and cons and capabilities of using SharePoint in a cloud-based environment.
Another key area of enhancements in SharePoint 2013 is support for mobile computing. SharePoint 2013 provides new, optimized experiences for different mobile platforms. For smartphones, SharePoint 2013 offers a simplified view for navigating and accessing document libraries, lists, and Web Parts. SharePoint 2013 also includes the capability to define multiple device channels, which enables developers to render a single SharePoint site in multiple designs based on the user’s device. While users were typically able to access SharePoint sites from mobile devices in previous versions, SharePoint 2013 automatically enhances that experience in some instances and allows developers and designers to explicitly define the user experience for different types of devices to create an even more functional experience for users. The most important strategic consideration for supporting a mobile experience for your SharePoint users, however, is evaluating the specific types of scenarios that your users will want to enable on their mobile devices on a regular basis.
As an example, while users may want to read and review a document occasionally on their smartphones, detailed document reviewing and editing will rarely be a critical scenario for mobile users. On the other hand, one could imagine that looking up a phone number or quickly finding someone with expertise in a specific topic might be a high-priority scenario. For the occasional-use scenario, it may not make sense to design a specific mobile capability. However, for the people-lookup scenario, it might make sense to build a highly focused and targeted mobile application designed to run on a smartphone.
Note
For additional information on thinking about mobile solutions and SharePoint 2013, be sure to read Chapter 19, “Planning for Mobility.”
While many organizations developed rich and engaging public-facing Web sites using SharePoint 2010—for example, ConocoPhillips (www.conocophillips.com), Dell Financial Services (http://dfs.us.dell.com), and Ferrari (www.ferrari.com)—making the commitment to using SharePoint for externally facing Web sites previously required a very deep knowledge of SharePoint in addition to expertise in Web user interface (UI) development. SharePoint 2013 allows Web designers to leverage familiar Web site tools to design a SharePoint site. It also includes other capabilities that support public Web site development, including
Features that support capabilities to promote and recommend content that is relevant to and popular with visitors based on their activity
Significant improvements to search that enable sites to aggregate and present content in new and flexible ways
Improved capabilities to reuse content in multiple publishing environments with the cross-site publishing feature
The ability to organize navigation based on managed metadata terms rather than physical location
If you haven’t previously considered managing both your internal and external Web sites with the same technology tools, SharePoint 2013 makes that decision much easier. It may be time to think about moving your externally facing Web site to SharePoint 2013 so that you can consolidate around a focused solution set.
Note
For more information about using SharePoint 2013 for Internet-facing sites, read Chapter 14, “Managing Web Content.”
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.
Note
See Table 2-1 for examples of how SharePoint features can help address these business objectives.
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.
Take Action
Be inclusive rather than exclusive as you identify key stakeholders. It’s important to gather as much business user support for your solution as possible.
Be sure to include users as key stakeholders. At the end of the day, these are the people who will help make your solution successful (or not).
In addition to traditional department or business executives, try to include employees who may not have the title but who are influential in your business. These people tend to have broad networks across the enterprise and can help drive your success because many people trust them.
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.
Take Action
Identify three or four main features that will produce the most business impact and implement them exceptionally well.
Articulate, well in advance of launch, the long-term vision associated with your solution and how the first delivery sets the stage.
Set clear and reasonable expectations for business users—encourage them to focus on the business outcomes they want to achieve. In your requirements- (objectives-) gathering meetings, explain how you can accomplish the business outcomes using SharePoint’s out-of-the-box capabilities so that you can get a feel for whether this will be acceptable to your users. Use statements such as “This is how we might accomplish what you are asking for in SharePoint 2013.” Your goal is to rapidly deploy a first release of your solution so that your stakeholders can see the solution “in action” with their content. Develop and implement prototypes so that users can get a feel for SharePoint 2013, and alleviate any anxieties they may have about the new ways SharePoint enables work. You will probably find that it is only when users “meet SharePoint” with their own content that they can start to envision additional functionality that will add value to the business.
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 enablepeople to achieve business objectives, simply implementing the features in this table will not guarantee that you will achieve the desired business outcomes.
Key Points
Getting started with SharePoint 2013 means thinking about your strategy—not just your SharePoint strategy, but also your business strategy and the business outcomes that you want to enable with the SharePoint solutions you build. Remember:
If you want to build a successful SharePoint 2013 solution, you need a carefully defined strategy focused on business outcomes and features that enable business outcomes.
Identify and engage key stakeholders. Make sure they are involved as core members of your project team.
Ensure that the SharePoint solutions you develop have a clear connection to business goals and objectives. Create a matrix to map your solution elements to your business strategy to ensure that you are focused on the right things.
High-impact collaboration involves culture changes blended with the right technology. It is a small part technology and a large part business process change.
Software does not achieve business objectives—people do. Just because a feature can help achieve a business objective doesn’t mean it will.
Not all content needs to be stored in SharePoint, but all business-critical data should be accessible through your portal.
SharePoint 2013 provides a single application from which you can create modern, user-friendly solutions for many work scenarios, including intranet, extranet, collaboration, and Internet solutions. This allows you to engage not only employees, but also clients, partners, and prospects—the entire extended enterprise. A well-thought-out SharePoint strategy can make a significant contribution to enabling critical organizational results.