CHAPTER 3

Determining Your SharePoint Features and Functionality

In this chapter, I provide an overview of the key SharePoint functional capabilities at a macro-level: collaboration, social computing, portals, search, records management, business intelligence, and composite applications. I devote my primary focus on the functional capabilities in SharePoint to discussing those new capabilities introduced in SharePoint 2013. From there, I offer strategies that you can use to plan for SharePoint features, and I share approaches that you might take to limit the SharePoint features you make available. Finally, I provide you with considerations on how you can map SharePoint functional capabilities to business value, and how you can plan to build these features onto each other and to enable additional features over time.

One essential concept that I want you to take away from this chapter is the expanding nature of SharePoint. Microsoft has designed the product to provide you with the ability to evolve and expand its features over time, as opposed to having to deploy everything all at once. I stress this idea throughout this chapter so you can see the deployment possibilities in how Microsoft designed SharePoint, possibilities that let a deployment enable additional features and capabilities continuously as it evolves over time. Ideally, this approach can help break down a deployment into manageable chunks rather than leaving you trying to accomplish everything all at once.

After reading this chapter, you will know how to:

• List some of the new capabilities in SharePoint 2013
• Describe the core SharePoint capability areas
• Plan for and limit SharePoint features
• Map SharePoint features to business value
• Enable SharePoint features over time

Understanding the Feature Evolution in SharePoint

SharePoint offers almost an embarrassing amount of riches with its range of features and capabilities. One capability in the product might be what initially attracts you to the platform, and then like a one-two punch, it blows you away with something else it offers. It has a broad range of features and capabilities, and they are getting quite mature in their depth of functionality. All these wonderful things can also make it hard to know which capability to start with, and the vastness of features can make it challenging for you to stay focused on doing your initial deployment well.

Along with the range of features, you might also feel caught up in the hype that builds around considering the different capabilities available within SharePoint, as well as the general hype from the industry around more generic terms that relate to some capabilities SharePoint can support. You might hear industry hype related to things such as social computing, enterprise search, records management, or for our purposes, governance. These are all buzzwords that I suspect you are familiar with, and SharePoint provides a platform that tackles these and other capabilities very well, but beyond the hype, how do they translate into business value?

Are you deploying and enabling features just because they sound cool or are popular in the blogosphere? Did you go to a conference and see a demo that looked promising, and then went back home to start planning how you could deploy the same thing for your organization? I have too; I bet we all have. I think it is easy to find myself caught up in the excitement of everything that SharePoint offers and its potential for an organization. I like having SharePoint fire me up, and I like having the excitement of what is possible carry me away. I find this keeps SharePoint evolving and adapting to meet new business needs. My next step though is to associate business value with whatever feature or capability I am considering.

It is perfectly okay to get excited about something and to want to try it out because it looks interesting; engineers are famous for this, and it is their curious minds that leads them to discover new opportunities or different ways to solve a problem. I am curious and creative in this way, and I enjoy exploring new possibilities to problems. If I want to try out something just for the sake of trying it out, I do it in a development or sandbox environment as a loose experiment or a proof of concept. I do this in a sandbox environment rather than jumping to slot it in as a project for the production environment without any business value associated to it. This helps me scratch that curiosity itch when I just want to experiment with technology, and it lets me do it without gold plating my SharePoint deployment. It also helps me explore new possibilities and prove solution concepts with low risk and minimal investment.

I will come back to this discussion on how to map SharePoint features to business value a little later in this chapter. I am only mentioning it here to put the idea in the back of your mind before we begin to look at the different features built in to SharePoint. This way, I hope you can resist the urge to go and turn them all on right away before you get to the end of the chapter and have read the discussion on associating features to business value or to a business case. Writing this chapter presents a bit of a chicken and an egg scenario for me, because I cannot assume you are familiar with the features SharePoint even offers, and it would be difficult to describe what business value those features offer without introducing them first. Yet introducing the features first contradicts the guidance I will provide later in the chapter when I encourage you to start with the business value and have that business value lead you to the features you need. In the end, I compromised and gave you a quick overview here of both before moving into a discussion on the features in SharePoint 2013.

Throughout this discussion on SharePoint features and capabilities, one thing I hope you will notice is how well they all work together and how they build on each other. I like to think of them as puzzle pieces, building on each other, connecting together, and eventually forming a grander picture. Or, perhaps they form a grandeur picture! You can incrementally build out your SharePoint service, and the beauty is that Microsoft designed SharePoint so that you can incrementally add features and capabilities over time and as you need them, rather than having to tackle them all at once. I come back to this idea toward the end of the chapter where I offer strategies on approaches that you can use to achieve a gradual deployment, after I have introduced the core features available within SharePoint and discussed how you might map them to business value.

I love the Williams quote I used as an epigraph for this chapter, and particularly in the context of this chapter as we look at SharePoint features. This quote comes from a book on writing and style I read and it was mentioned loosely in the context of how perfect sentences might be our ideal, but eventually we need to print and deliver. It resonates with me for this topic as well. I cannot stress this enough: repeatedly I see clients swept up in the vastness of what SharePoint offers, they go starry-eyed and end up consumed with wanting everything, and they want it all at once. It paralyzes them. That perfection is certainly the ideal, but if you want to deliver business value, you need to focus on getting things done. The best way you can do that is by getting things done regularly over time by continually adding features you have mapped to business value.

Now that I have all my disclosures out of the way, I can share my excitement for the tremendous range of features available in SharePoint. This has been true for as long as I have been working with the product. I liked the document collaboration capabilities that SharePoint 2001 offered, but it was SharePoint 2003 when I grew attached to the product. The move to Microsoft ASP.NET was one reason, and another reason that excited me was its architecture that the product team designed for scale. It opened the doors for many possibilities, particularly for me as a developer, where it provided a rich platform on which I could build solutions. I had found my niche around that time where I developed custom ASP.NET controls to help make other developers more productive in the applications they were building; so my transition to building web parts was very easy and came naturally. Everything I loved about SharePoint 2003 got even better in SharePoint 2007, and along with that came some enhancements I craved. In particular, SharePoint 2007 integrated web content management (WCM), added Windows Workflow Foundation, and made some exciting improvements with search, among other enhancements. Then Microsoft released SharePoint 2010 and they introduced of one of my favorite modern architectural designs in the product, Service Applications. SharePoint 2010 also offered a wealth of other enhancements, including the addition of PerformancePoint, FAST Search, and Office Web Apps.

SharePoint continues to evolve and build on its legacy, as it made leaps over the last decade or so with each release. It gave me more reasons to like it with each version, and SharePoint 2013 is no different. As I worked on SharePoint 2013 through beta versions while planning and writing this book, one aspect that struck me is how this release signals to me that it is a sort of maturing of the product. Maybe it is because I have been working with it for so long and watched it grow up, but this release feels like it comes with the fewest radical changes to the overall user experience for working with and administering the product. I have been involved with beta and early adopter programs on several versions of SharePoint so far, and on this version, I noticed it feels as if its overall experience remained consistent with SharePoint 2010. In contrast, other releases involved drastic changes to the user interface on the Central Administration pages and the Site Settings page. Other releases have also changed the model for sharing services, which has typically involved drastic architectural changes. Yet, for SharePoint 2013, it feels as if these aspects have finally matured and settled along with the core architecture for components like Service Applications and the administration model.

Having SharePoint 2013 mature in areas such as its administration interface and its service architecture can help make upgrading and migrating to this latest version easier for administrators and end-users alike. This is because the core experience is largely consistent and does not require a lot of retraining. Even still, the team managed to pack a lot of exciting new features in SharePoint 2013 that still gives it the wow factor for all the new functionality it offers, and so it still has compelling reasons to entice you to upgrade. So, what are all the enhancements that SharePoint 2013 offers? Let’s turn our attention to look at what’s new in SharePoint 2013.

What’s New in SharePoint 2013?

In Chapter 1, I introduced some of the new features and capabilities in SharePoint 2013 as they relate to governance. In this section, I recap a few of those features I already introduced and add on to the list as I point out some of the other new features that I am excited about inside SharePoint 2013.

With SharePoint 2013, we have some very exciting additions that enhance our governance capabilities, and they build on existing governance capabilities carried forward in the product line. Some of these new features are ones that I have craved since SharePoint 2003, and here we are ten years later where these things I imagined would be nice to have back then and would help make governance easier are now a part of the product. First is the managed navigation, resolving one of the commonest objections I faced against going with multiple site collections when I design and propose site structures for clients. This managed navigation feature enables you to base a site’s navigation on a term set within the Managed Metadata Service, but you still have the option to use a navigation based on the physical site structure just as you did in previous versions of SharePoint. Alternatively, you can use the managed navigation and have it automatically update relevant terms in the term store when the physical structure changes. I talk about this feature more in later discussions on site structures and information architecture in Chapter 15.

Another new feature in SharePoint 2013 that enhances how we address governance is the eDiscovery capability. The enhancements in eDiscovery overall provides us with excellent information governance options and possibilities. One of my favorite eDiscovery features is the retention policy that you can now set at the site level. This provides a much more feature rich user experience than the long SharePoint tradition of the Site Usage and Confirmation feature that would merely send an e-mail on a regular schedule to request the site owner to confirm that his or her site is still active, without any additional logic or sophistication. Now site owners can specify retention policies for the site and its content that their users create within it. These policies can add a level of sophistication that automatically declares content as a record after a certain period, or the process can trigger a custom workflow to run and take actions against the content.

Similar to records management in SharePoint 2010, SharePoint 2013 eDiscovery also exposes capabilities for designating a piece of content as a record with retention policies assigned to it, whether storing the content in place or submitting it to a records repository. The product team for SharePoint 2013 has enhanced and matured its records management capabilities, making eDiscovery one of the noticeable areas where the team made a large investment and significant innovation for this release. The discovery aspect of eDiscovery provides legal and compliance departments with a tool to locate particular content that relates to a case or an incident they are interested in discovering related content about. As Figure 3-1 illustrates, a user can discover content using query criteria based on dates, keywords, authors, and other metadata. They can run these discovery queries across multiple SharePoint farms and Exchange servers or target a particular site. One of its features includes the ability to set a rule to place content on a legal hold if it matches the search parameters, and you can decide to place a legal hold on content in place or copy it to another location. It provides a rich set of tools for managing and enforcing compliance, whether you are meeting regulatory requirements or responding to a legal case.

Apps for SharePoint also presents a wonderful new capability in SharePoint 2013 that provides reuse of services and applications across sites and farms within an enterprise, as well as for consumers from different organizations to procure Apps from the SharePoint Store in the Microsoft Marketplace. Apps provide functionality to a SharePoint farm or just to a site within the farm, yet they do not execute any custom code on the SharePoint servers in the farm and instead can utilize resources on vendor-hosted servers or from a cloud solution such as Microsoft Azure. This provides you with a consistent and low-risk way to deploy customizations and applications, because users can select the App from a centralized catalog and deploy it without affecting the stability of your SharePoint farm.

Speaking of the custom applications you use Apps to provide, you can still deploy your own custom developed functionality through SharePoint Solution Packages (WSP files), and those developers will find new support for debugging issues with the diagnostics available in the enhanced Developer Dashboard. The Developer Dashboard is not just for developers though, despite its name, as I often use it to review logs and page tracing when troubleshooting administration-related issues as well. The biggest change for the Developer Dashboard in SharePoint 2013 is that SharePoint displays the Developer Dashboard in a separate window now, and it has several tabs for activities, such as reviewing a trace of the ULS logs and filtering them for the particular request correlation identifier. You need to use PowerShell to enable the Developer Dashboard in a farm. Once enabled, SharePoint adds a button to the SharePoint pages, and when you click this button it will pop up a separate window containing the developer dashboard. The following PowerShell script provides an example for how to enable the Developer Dashboard.

$content = [Microsoft.SharePoint.Administration.SPWebService]::ContentService
$content.DeveloperDashboardSettings.DisplayLevel = [Microsoft.SharePoint.Administration.SPDeveloperDashboardLevel]::On
$content.DeveloperDashboardSettings.Update()

Figure 3-2 shows a screenshot of the Developer Dashboard enhancements. It shows the Developer Dashboard opened in a separate window, where you can see the additional tabs available for monitoring and diagnosing issues on your SharePoint 2013 farm.

SharePoint 2013 makes customizing the self-service site creation process as simple as setting the URL that points to your site creation form. By default, the self-service site creation form asks similar questions as it did before, such as the managed path to create the site, the site name, and optionally, secondary site owners. If you want to collect additional information from users seeking to provision a site, you could create an InfoPath form and update the self-service site creation settings to add the URL for your custom form, and then the process would continue to work by updating all new site links and references to use your custom form. This simplifies the task of customizing the self-service site creation process and it allows you to tailor it to fit the needs of your organization. For example, you could also collect information on the site’s expected lifespan and information to set an appropriate policy for retention, or you could capture metadata related to the business impact or sensitivity of the content the site will store.

SharePoint 2013 has updated site policies with the option to set a site to a closed state. With this option, you can have a policy to close a site after a period or a user can close it manually through an option on the Site Settings page. You can close or re-open a site by going to the Site Closure and Deletion page, as shown in Figure 3-3. You can find this page by following a link of the same name on the Site Settings page. With this new concept in SharePoint 2013, you can close a site and use this as a step before deleting it and disposing of its content. When you close a site, it no longer appears in places where web parts aggregate lists of sites, but users can still access the site’s content. You can also use the process of closing a site to begin a countdown to delete that site, or you can associate other workflows to the site policy to manage the retention, archival, and deletion of site content.

One of my favorite end-user features relates to the enhanced user experience for uploading documents. Now document libraries support dragging and dropping a file into the library directly without having to use the Explorer view or having to go through the upload form. For me, dragging and dropping feels like a more natural experience, and it feels smoother without having to switch to Explorer view. This more natural experience means that users will likely understand it easier, and in turn, they will use it more efficiently. It also speeds up the overall process of uploading a document from your desktop into a SharePoint document library.

Mobile users also gain an improved user experience in SharePoint 2013 with the enhanced mobile views in the different areas of the product built to provide a richer mobile experience. In particular, business intelligence visualization offers a rich mobile view with an interface designed for touch interactions when viewing reports and dashboards on a mobile tablet such as an Apple iPad or Windows 8 tablet. Executives can access scorecards and key performance indicators (KPI) on their mobile device, enabling them to keep their fingers on the pulse to monitor the health of the organization, and they can carry that with them whenever they are mobile. SharePoint 2013 has enhanced Excel Services, Reporting Services, and PerformancePoint for general mobile and iPad user experiences with business intelligence.

The social features have improved in SharePoint 2013 with an enriched microblogging experience within the MySite area. Microblogging features now include mentioning someone, such as a colleague, by using the “at” (@) symbol to signal the mention. For example, a colleague could use @stevegoodyear when he or she wants to mention me in one of their posts, and this experience matches how you mention someone on other social networking sites. In this case I used an alias as an example of how my colleagues can mention me in their microblogging posts, and this is the same alias that you would use on Twitter to mention me in a tweet. Your internal alias does not have to match your public social networking alias though, I just had it match here as an example to show the consistent user experience with other public social networking sites. In fact, SharePoint 2013 makes mentioning someone even easier than remembering their alias by offering a little popup when you begin mentioning someone so you can select the person’s name from a list of people. This list will include a list of the people you follow as well as a list of people imported into the profile database. You can also see how many posts other people have mentioned you in by using the consolidated web part.

SharePoint 2013 social features are also consistent with the tagging experience users already experience on public social networking sites such as Twitter. A user can add a tag to their post by combining a hashtag followed by the text of the tag. For example, to tag a post with a facilities tag, you would type “#facilities” in your microblogging post, as Figure 3-4 illustrates. When you tag your posts, you make them easier for users to discover them, but you also give users the ability to follow the tag so they can follow the larger conversation related to the tag. You can follow a tag rather than individual people, if you prefer, in order follow posts on a topic that interests you without having to follow all the different people and their other posts that might not interest you. This helps cut down on all the noise and it helps keep your newsfeed relevant to you and your interests. Therefore, in this example, users might follow the tag “#facilities” to keep up with posts from facility managers and real-estate planners for the company, where users may be interested to follow progress on plans to expand office space. They can also see other people’s posts related to the expansion process without having to follow all the individual people. In addition to people and tags, you can also follow sites and documents in SharePoint 2013.

One of the big changes for you to be aware of in the SharePoint 2013 newsfeed involves the change in security trimming. Now most posts are not security trimmed and are visible to all authenticated users. Automatic posts to your feed related to document changes and site changes are still security trimmed based on the permissions of the document or site, but other posts in the newsfeed adopt a more open model consistent with the open and public experience that users are familiar with using on Twitter and other public social networking sites. Retention of posts are no longer limited to 14 days like they were in the past, because now most posts in a microblog are stored in a microblogging list as part of a user’s profile and MySite. Some posts are not persisted in this microblogging list, particularly those events that relate to document or to site changes that post notifications of changes to the newsfeed of those users following the document or site. These events are stored in the Windows AppFabric cache, and the cache is not persisted beyond an application restart.

If your profile on your MySite and your microblogging posts on your MySite all make up the presentation of yourself to your company, then community sites are your presentation to a community of practice within your company. SharePoint 2013 community sites are site templates designed for collaboration and idea generation within a community of practice. A community site provides a forum for community members to gather to discuss ideas related to a particular topic. These community sites can serve as a place where people from different areas of the organization gather to share knowledge or to solve common problems, or they can be a place for a particular group or team to brainstorm ideas and cross-pollinate expertise among team members. Community site members can earn a reputation by contributing and actively participating in the community, through automated measures such as having their posts rated or selected as a best answer, or through badges that community managers give them to recognize their expertise or contributions within the community. Your reputation earned in a community site is per community site rather than as a global or enterprise reputation, and it helps present you within a community of practice as an active member, thought leader, or expert, depending on the type of community.

SharePoint 2013 search also includes features that are more social. For one, it now has the usage analytics included as part of the search service rather than as a separate standalone service. Including usage analytics in search provides features such as content recommendations to users based on their interests or activity context, usage counts, and activity rankings that capture how active a particular content is to correlate its activity with its overall relevance. The search analytics also uses social distance and social tags in determining relevance in search results, in addition to link and anchor text analysis, click distance, the number of search clicks, and deep links analysis.

Search offers multiple options for Result Sources to use and query for search results. The most notable Result Source for me is the option to select a Remote SharePoint index, which enables the local SharePoint farm to use the content in a remote SharePoint farm’s index without requiring the local search engine to crawl the remote content. Using a remote SharePoint index also simplifies the configuration and coordination of remote credentials on remote SharePoint indexes by establishing an oAuth trust between the two SharePoint search applications. Using an oAuth trust requires you to establish a trust relationship between the two farms in the same fashion as you would establish a trust to consume services from a remote farm’s service application. Remote SharePoint indexes can effectively allow you to set up an enterprise search portal on every SharePoint 2013 farm deployed in your organization. You can also set Exchange as another option for a Result Source, or you can return results from search engines that implement the OpenSearch protocol. Figure 3-5 provides an example of the SharePoint page for adding new Result Sources.

Service applications have largely maintained the same architecture in SharePoint 2013 as they did in SharePoint 2010, with some enhancements and a few new service applications added. You will notice one notable change if you are used to SharePoint 2010 service applications, and that change is that the Office Web Apps are no longer a service application within SharePoint 2013. They now are a separate server product, and the reason for this change is to share the functionality that Office Web Apps provides across multiple Microsoft server products without having a dependency requirement for SharePoint to host the service. Office Web Apps now provides Office file rendering capabilities for SharePoint 2013, Exchange 2013, and Lync 2013. This provides a consistent way for these products to render Microsoft Office content, and it provides capabilities to embed web views of Office content in other web pages as well. Separating Office Web Apps to its own server also provides new scaling options for very large deployments where, for example, you can allocate servers specifically for processing Word documents and others specifically for processing Excel spreadsheets. In short, having Office Web Apps as a standalone server product makes it easier to reuse its capabilities across the different server products while also enabling new scaling options.

This latest SharePoint release also expands Business Connectivity Services (BCS) to support OData, an industry standard for exposing data from a database, which allows for simple no-code solutions against an OData source. BCS also includes enhancements to support handling events triggered from an external data source. This event framework for external notifications also provides alert capabilities for external lists within SharePoint. The external data source must implement the necessary interfaces to raise events to SharePoint 2013 and it must send the event notifications as ATOM feeds or JSON objects. With these enhancements, external data masquerades itself even closer to the user experience of native SharePoint data, and this provides your users with a consistent experience as they interact with list items in SharePoint 2013 without having to be conscious of the differences between a native SharePoint list and an external list.

One new service application, the SharePoint Machine Translation Service, provides machine translation services for pages, documents, and entire sites. You can use built-in machine translation or you can configure a cloud-based translation service. You can also export the content destined for translation vendors in an XLIFF format, the industry standard translation format you would use to send content to translation vendors. You might send this XLIFF file to a translation vendor manually or perhaps as part of a workflow. You will find this service application particularly useful for portal websites that you need to publish in multiple languages. You will also find the translation service useful as part of your document management process when the document needs to be translated and distributed to audiences in multiple languages. One example might include press releases that you want to distribute in multiple languages to multiple news organizations and news wires throughout the world. In this example, you can create the initial press release in the language your public relations department uses and then use the SharePoint machine translation services to translate the press release into the other required languages. Figure 3-6 provides an example of the Machine Translation Service management page where you can select the different types of file extensions that you want enabled for the translation service.

Another new service application in SharePoint 2013 is the Work Management Service. This service application aggregates tasks for users from across SharePoint sites, Project Server sites, and Exchange mailboxes. SharePoint aggregates these tasks and caches them in a user’s MySite to provide a user with a centralized place where he or she can go to view and track their work and outstanding action items. This provides users with an efficient task management system that they can access and manage from a single view, and this saves them from having to hunt down the statuses of all their tasks from many locations. Better yet, tasks are less likely to fall through the cracks and end up missed because a user did not notice it or they forgot to check a certain disparate task list location. For example, rather than having to remember to check the status of his or her tasks in Outlook and then their tasks for a workflow in a SharePoint site, the user can see and prioritize all their tasks from this single view. Figure 3-7 shows the consolidated Tasks view in a user’s MySite.

Request Management is another new feature in SharePoint 2013, and it is a service that runs to route and manage inbound requests for a SharePoint web application. In contrast to using a hardware or software based load-balancing device that distributes the load evenly across servers, you can apply rules to the SharePoint 2013 request routing and configure an uneven distribution of requests. For example, you can use Request Management to balance requests based on hardware capabilities by providing a higher weighting for newer and more powerful hardware to respond to a greater portion of requests. The Request Management also monitors the health of servers in the farm by assigning them a health score, and it uses this to determine the optimum server for which to route a request. It can also prioritize requests that are more important based on rules you configure, and it can block harmful requests. You might also use it to allocate web front-end servers that you do not want available to respond to end-user requests for administration purposes, or vice versa.

SharePoint 2013 provides many new capabilities, some in new functional areas for the product and others as enhancements of existing functionality carried forward from previous versions. In this section, I have listed several of the ones that I am most excited about, but this is by no means an exhaustive list and I have only just scratched the surface of what these new features entail to whet your appetite for SharePoint 2013. I will come back to some of these features again as they come up throughout the book, and as they specifically relate to governance, but I wanted to digress a little in this section to look at what is new and exciting in this release. I hope this provides you with some context for SharePoint 2013 and for those features that have changed in the latest version. Now I want to shift the focus to a broader sense beyond just what is new and look at what are the core capabilities and functional areas that SharePoint 2013 offers.

Overview of Core Capability Areas

For our purposes, I am going to group the SharePoint 2013 core capability into seven general areas: collaboration, social computing, portals, search, records management, business intelligence, and composite applications. These are similar but not identical to how Microsoft refers to the capability areas within SharePoint in the different marketing material that they use. I am not trying to be different or discredit how Microsoft prefers to categorize the different areas of the product in terms that are more abstract; I just want to simplify them for this discussion so we can look at some particular usage scenarios.

The bread and butter capability of what SharePoint provides is its collaboration capability. This provides the foundation of SharePoint, and it is what I would consider as its core strength. Of course, SharePoint offers so much more than collaborating on documents, but this is where SharePoint found a stronghold and it is still a common driver for organizations to adopt SharePoint. We can trace practically everything else in the product back to collaboration, or at least we can probably find a link from a particular feature area and trace that back to how it builds on and how it complements collaboration. As a result, SharePoint makes the idea of collaborating to share ideas and to create or access new information ubiquitous throughout the product, whether we are participating in community sites, we are viewing slices of data in a business intelligence report, or we are working together to produce new documentation. Collaboration continues to be at the heart of SharePoint and it touches all the other feature areas.

You might consider what the issues with collaboration are as they relate to governance, and you may consider whether you need to address any or make any decisions to govern them. This may range from how open and permissive your collaborative environment is, to how closed and restrictive you need to make it to lock it down and regulate it. Do you want to let the people who are collaborating make their own decisions for how permissive or restrictive their collaboration experience needs to be? Or, do you want to decide this for them? I do not think there is one correct answer that will fit everyone, but it is worth taking a moment to decide where your organization fits on this scale and what approach you want to take to govern the collaboration aspects of your SharePoint environment.

As a capability closely related to collaboration, I want to highlight social computing as another core capability within SharePoint 2013. Users could maintain MySites and their company profile for several versions now; and as in past versions, users can browse an organizational chart, maintain a list of colleagues, or conduct a people search to discover other people within the organization. Users can rate or flag content they like, add comments associated with content, and share links. Other users can discover new content or other types of information through activities of what different users are rating or commenting on simply by being each other’s colleague or sharing common interests. Where collaboration allows people to come together, where each can contribute to the process of creating new content or ideas, social computing overlaps and extends this concept by enabling people to discover information through other people and to use those other people to filter its relevance.

Social computing also presents a continuum scale of how permissive or how restrictive you want to make social aspects within SharePoint 2013. Your decision on where you fall on that scale might rest with your degree of trust in your users and the type of content you expect they will post. Your degree of trust might reflect your comfort level with how much you might worry about whether a user will abuse the system, or your confidence that users will mostly act appropriately and that other discipline policies will address them when they do not. Do you care what type of picture your users upload to their MySite or what they decide to write in their profile text? Some people do care and they will want to micromanage this, while others do not and leave it open for the users to manage. Yet other people might fall somewhere in between. You can address this by deciding where you fall and what your tolerance is for social features, and then take the actions of enabling or disabling them.

While social computing can help people discover relevant information, some information could potentially be less social but still important to publish to users. Users need a centralized hub for this other type of information, a portal where content such as organizational announcements, policies, forms, and the like which the portal publishes and makes available to users. A portal might also serve as an entry point for users to initiate processes and workflows, including activities such as submitting their timesheets, status reports, or a performance review. Portals can exist for a specific department, such as a knowledgebase portal, or they can represent the entire organization; and these departments or organizations often brand their portals to give them a branded user experience.

Portals can involve many governance decisions, including who can publish to the portal and who is the target audience for the portal’s content. They also involve other governance aspects, such as how to structure them, what are their branding standards, and what are the appropriate types of content. I discuss some of these portal governance issues and more throughout this book, and in particular, when I discuss customizations and information architecture topics in Part IV.

Users typically find content within the portal by clicking through a set of navigation menus and other links, or by searching for content by using keywords related to what they are looking for. An enterprise search can provide users with the option to search within a particular application, such as a portal, or they can use it to search across the enterprise and across content repositories. Users can search for other users, for content that others have generated, or for processes, such as forms that they need to access in order to initiate a workflow process. Users can use search to find specific content quickly from large repositories without having to know the directory structure, such as content stored in a large records repository where a typical user would be unfamiliar with the file plan structure.

As we looked at in the previous section, records management and eDiscovery stands out as a big investment area and a core capability for SharePoint 2013. Once users generate content, some of that content can become critical to the business or have legal compliance responsibilities associated with it. Records management provides additional steps in managing the document lifecycle, as well as the lifecycle of other types of content. It also provides a means for records managers and legal resources to monitor the organization’s compliance and to respond to legal cases. One of your governance decisions for records management involves determining if you need a centralized records repository, or if you want to store records in-place within individual sites. Another decision involves deciding how formal you want to make the compliance and retention process and whether you need to enforce any metadata requirements for classifying content.

Besides monitoring the organization’s records in a records repository, other monitoring can involve monitoring trends in data, scorecard or performance indicators, and other types of analytical reports. The business intelligence capability within SharePoint 2013 provides this type of monitoring, a capability with services such as SQL Server Reporting Services, Excel Services, and PerformancePoint Services. Users use these services to support decisions and have the services alert them to changing conditions. They may view these reports through a portal, a mobile device application, or through a client application such as Microsoft Excel. Your governance decisions related to business intelligence involve determining who has access to the data, what data you will make available, and how users can request additional reports on the data.

I use the term composite applications as a sort of catchall category that encompasses custom developed applications such as integration solutions that expose data from external systems through Business Connectivity Services, enterprise process solutions that use InfoPath Forms Services and Windows Azure Workflows, or a custom component coded using C# and the SharePoint API. I also consider this category to include those solutions where you provide your own capability to SharePoint by developing it yourself or extending one within SharePoint. These applications can make your SharePoint service shine as they help tailor it to address specific needs.

Governing composite applications and custom development can involve many considerations, and as such, I return to discuss this topic in more detail in Chapter 14. For our purposes in this chapter, you are considering whether you want to enable some or all these capabilities. You might consider what aspect of composite applications you want to enable, whether that includes the Apps from an internal catalog or from the SharePoint Store, user SharePoint solution packages, SharePoint Designer customizations, Business Connectivity Services, and so on.

I hope I have illustrated how all these capabilities provide a specialized set of features and functionality, while also showing the interconnection among the capabilities, as Figure 3-8 illustrates. I wanted to show how they relate to each other, and how they complement and build on each other’s capabilities. I find in considering how broad each capability’s feature sets are, it helps to illustrate the complexity and size that any one of them entails, not to mention what all of them together entail. For the most part, I consider these capabilities as buzzwords that represent many interrelated concepts and many underlying features. I try to avoid saying things such as “we should implement social computing,” because I do not find that perspective to be a valuable one. SharePoint has a bunch of functionality within the product that I grouped into a capability under a common term, but that on its own does not solve a particular business problem, and instead it would leave you chasing features. This idea of chasing features reminds me of the saying where you begin to treat SharePoint as your hammer and you begin to look at everything else like it is a nail. For me, I like to have my focus be less on what capability I am delivering and more on what the outcome will mean for the organization. I achieve this user and business-oriented perspective by mapping SharePoint features to business value, as we will discuss next.

Mapping Your Features to Business Value

Before you can map features to business value, you need to to define what business value is. For my purpose here, I consider business value as some degree of benefit that an organization derives from a change or an initiative that I take. You might measure business value using productivity indicators, such as an amount of time saved in a process, or dollar indicators, such as an amount of cost reduced or revenue increased by a process. You might use other factors based on improvements to goodwill, employee morale, or web page click through rates. On the other hand, you might use whatever else is an important measure of value for your organization. For some categories of business value, you might be able to use a precise measurement, while for others you will have to be satisfied with an imprecise measurement.

You do not have to translate every measure of business value into dollars and directly compare the value to the cost required to achieve it, although you might for some measures. Instead, you will look at the business value outcome, whether it relates to dollars or something less concrete, and from there, you need to decide how desirable this outcome is and whether it is worth the cost. I cannot offer you a simplified formula, unfortunately. This process depends on your priorities and how desirable you find a particular outcome is at a given moment. The key place to start is to determine what you want to measure and then determine the actual measurement you need to capture.

A few years ago, I noticed a popular slide that sales people seemed to include in the presentation deck they used to try to sell an enterprise search solution. The slide included a statistic that claimed something that sounds somewhat ridiculous similar to “the average knowledge worker spends 45 minutes per day searching for the information they need.” Can you imagine? Picture yourself running a department where each of your people spend almost a tenth of their eight-hour day lost, aimlessly looking for content. You would think they would remember where they saved the documents they were working on the day before, but apparently they come in each day and have to relearn where things are. Perhaps I am too quick to judge, but unless you work in a research role where your actual job involves constantly searching for content, I would expect things to be reasonably constant from day-to-day and that you would be reasonably adept at locating the routine things you work with. I concede that during your first few days, you would be going through a learning curve where you do spend a lot of your time searching for content, but this is not average. What I am getting at is to make sure your numbers match reality and they are not based on some sales stratagem designed to sell products and services.

So, what do you base your numbers on? I find the commonest answer is typically money. How much money can an organization save by using a particular feature? How much extra revenue can an organization earn by using a particular feature? That makes it pretty cut and dry, but not every organization is driven solely or even principally by money. Some simply want to communicate their ideas, such as an environmental activist group whose primary objective is to persuade people to reduce their harm on the environment. Others may want to process as many contacts with clients as efficiently and quickly as possible, such as an outreach-nursing unit delivering a flu vaccine. If you do not have an immediate need and want to be proactive, I find a good place to start is to look at what are those primary business drivers, those that are crucial to the operation of your organization and its goals. Then I look at the outcomes of a feature or even an entire solution, and I consider those outcomes from the business’s perspective. Is this feature something that meets one of those business needs that I am trying to solve? Will it have a positive impact on the organization? From there, I try to quantify the positive impact.

There are no magic bullets to solve this challenge of mapping features to business value; SharePoint does not have a fixed set of business value deliverables because Microsoft designed the product to be flexible enough to fit a wide range of needs and environments. Every organization has different values and priorities, and so the business value SharePoint delivers to one organization might mean very little to another. I do not have a definitive list for you, as you have no doubt noticed through this discussion on how to map SharePoint features to business value. The process involves analyzing the priorities of your internal customers or analyzing what would add value to their job functions, and then projecting where SharePoint features could deliver some of this value. There are several models and processes available for you to use as tools to help build your business case and define your business value, but for our purposes, I will focus on one in particular.

The tool I use to create business cases is to build out a usage scenario that highlights how users will derive value from a particular feature. To do this, I create a use case that describes the task or objective the user wants to accomplish, and then I describe the outcome they derive from going through the process and using the feature. In the use case, I also try to associate what value or benefit the feature adds to the process so that it becomes a narrative about a particular function that a user preform, one that highlights the purpose of the function along with the value derived from the outcome and how the feature contributes to that value. This gives me a usage account from the perspective of the business and it focuses on answering how and why the business would want to use a given feature. I can repurpose this information when I communicate with intended internal users on things such as why they would want to adopt a feature and how it will benefit them.

I love use cases, but on their own, they do not typically quantify the business value. A quantified measure of business value might be the amount of money saved, amount of extra revenue produced, number of person-hours saved, amount of turn-around time reduced, and other measures of organizational benefits. You might not use a financially related measure though, and instead you could use measures such as increased satisfaction levels with using a system, reduced frustration levels in a process, and the like. Use cases provide a basis to start with determining a measure of business value.

Using use cases, I like to capture the as-is state of the process and take that away to reflect on what the opportunities are. I feel business analysis and solution architecture roles both involve more than simply asking the business what they want; I am the expert they rely on, and my job is to understand their business and then help them understand the possibilities around where the technology can have a positive impact on their business. In sales, I often referred to this as the difference between a glorified order taker and a professional sales resource. A form on a web page can replace an order taker, the same as it can replace the business analyst who only knows how to take orders from business users without understanding or digging into the nature of the business. I try to be the asset who adds value by providing expertise and solutions that solve problems, rather than simply an order taker. After I have captured the as-is state of the process and where users perceive problems with it, I can go away and start to think about where the opportunities are and I can begin to imagine a solution that will have an impact and add a benefit.

It almost feels like a cliché: start with the business problem or business opportunity, and build a solution to address that rather than looking at technology for technology’s sake. I mention it though, because it is a step that delivery teams constantly seem to miss or skip or ignore. You need to analyze and understand the business, and then you can identify where the users benefit from a particular feature or an entire solution. You then need to articulate those benefits as outcomes from the perspective of the business and its users. After you have those benefits from the perspective of what the outcomes mean for the business, you have mapped a feature to some specific business value.

Clearly, I am not revolutionizing the process here, as there are other great books written on use cases and business analysis, including the one I mentioned earlier. My hope is not to state the obvious and fill pages with facets of common sense. For those who are experienced, I hope this only serves as a gentle reminder; and for those who are new to the process, I hope this is useful information that points you in the correct direction. I have included this discussion because it is important to mention and it seems easy to miss in the excitement of all the marketing jargon that can distract people when they are looking at SharePoint. Sometimes the hype that builds up around SharePoint can create an illusion that all you need to do is simply turn it on, and as I discuss again later in the chapter, the licensing costs are only a fraction of the total costs involved with operations and support. As useful as a feature might seem, and as easy as it might be to turn it on, my preference is to try to map it to business value first to assure myself that I am not gold plating the SharePoint service and merely driving up costs and complexity.

I feel like this section should not be groundbreaking or one of those tell-all secrets that shocks you, particularly if you have any previous experience working on technology projects. There is no magic, no smoke and mirrors behind the scenes, and nothing different about SharePoint from any other technology project in this sense. I am afraid I do not have a cheat sheet or shortcut or easy button, because the value will be unique for each organization based on their priorities and their unique situation. You can figure out the value though, and you can quantify or articulate value derived from a SharePoint feature or a SharePoint composite application by analyzing your business processes and modeling them using use cases. I hope this discussion has helped you understand how, and perhaps considering an example will help make this more concrete.

One of my favorite examples of quantifying value derived from a SharePoint composite application involves a project to move expense processing from a paper-based system into a SharePoint workflow. I find this is an easy example to relate to, because often with SharePoint, we are replacing paper-based systems and this illustrates an approach to calculate value for those types of projects. At one company I worked for, we introduced an online system that processed employee expenses and their related approvals. Building a use case to understand the process and analyze the steps involved, we could identify the number of people who physically had to touch the paper expense report and receipts, and where someone had to type in data related to the expenses in different systems, such as systems for customer billing and employee reimbursements.

With the use case, we could highlight redundant work and we could capture the total time duration required for different segments in the process. The result gave us a clear picture for how an expense report took an average of three weeks to complete the process of approvals and issue the final reimbursement to the employee. Using the use case with the time durations associated with each step, we could also calculate the cost to process an expense report based on all the cost factors we identified, including the amount of time an individual resource spent working with the expense report. On average, the expense reports cost about $27 each to process and issue a reimbursement. With the new online expense report system we designed, we projected through all the system integration and automated workflow steps we designed and modeled in our to-be use case, that an average expense report would cost around $7 and take only three days to process if everyone was prompt in conducting their reviews and approvals.

I like this example of moving from a paper-based system to an online expense report system because it highlights business value in two ways: the real dollar cost saved by implementing the online system, and the influence it can have on employee morale by providing a quicker turnaround with the reimbursement of their expenses. It also transforms the process so that it now offers one centralized place to go and check the status of an in-process expense report. Those real dollar costs can add up too. The company in this example has about 100,000 employees and contractors, but only about 10,000 of those employees process regular expense reports. On average, those 10,000 employees would process two or more expense reports per month, which gives us a nice round number to work with. If the company processes 20,000 expense reports each month, and expects to save around $20 per expense report, the total projected savings each month would be $400,000. Although this was an expensive project, and one that included significant development costs to integrate a SharePoint application and the set of workflows with enterprise legacy systems, its value was still apparent and easily mapped to this business value. With numbers like this amount of dollars saved every month, it does not take many months for the benefits in savings to add up and outweigh the costs of developing the system.

Although there are no hard and fast rules about mapping features to business value that you can use as shortcuts, I can offer some general guidelines or trends in the following discussion and I summarize some sample considerations in Table 3-1. As you may have noticed in my expense report example, for InfoPath online forms and workflow applications, a good approach is to chart the existing process and calculate how much time and overall involvement it includes, and then translate that into the real dollar costs for the process. Your projected timesaving with the online system can then translate into a projected cost savings similar to how I calculated mine in the expense report example. Document management processes can often follow this pattern as well by calculating the amount of time saved for things like collating the versions or the gains from tracking and managing an approval workflow in a single location.

Records management can build on this document management process and factor in the storage costs for paper-based storage locations in addition to having the workflow history married to the content. For records management, I also like to factor in regulatory and compliance related costs and risks. For example, how much does it cost to prove or audit your level of compliance in the existing paper-based system versus in the online SharePoint system? In addition, I like to consider the exposure risks involved and associate a cost to them as well, such as identifying the potential liability costs an online system can prevent by monitoring and indexing the content, and then alerting relevant resources if it detects something that is out of compliance.

I have already poked fun at common business value metrics for enterprise search that I see in the market, and it is probably typical of something you might have come across. Although I question the validity of the numbers sometimes, the concept and approach feels logical and correct. You could calculate how much wasted productivity you can save by using a more efficient and more sophisticated enterprise search engine, but I often find these numbers suspect and can vary depending on the day and the task. For example, today in my office, I am writing about mapping SharePoint features to business value and core SharePoint capability areas – a topic I am very familiar with and do not need to do much extra research on because this is often my primary job function and a process that is fresh on my mind. Yesterday, on the other hand, I was writing about all the new features in SharePoint 2013. Although I have been using the beta for a few months now and explored many of the new features, I still wanted to cross check my references with the Microsoft TechNet documentation to ensure my understanding aligns with the official documentation. I spent much more time searching for information yesterday than I will today.

What other measures can you use for SharePoint search besides speeding up a knowledge worker’s access to information through the search results you provide? I like to think of scenarios and different ways to use search. Sure, it provides search results that help your knowledge workers to find information quickly; but what if they do not know what to search for or if they are unaware that some content exists? Search features have other options to provide business value to knowledge workers, such as the recommendations feature that can recommend content that a knowledge worker might be interested in but would otherwise be unaware of. Information discovery and people discovery certainly add business value, although their value can be difficult to quantify and measure.

I also like other applications for search, such as a dynamic navigation based on a given context to help connect users with relevant information, possibly even in a self-service scenario. One example of a self-service scenario I have developed includes using search as the initial step in a service desk ticketing system. When an end-user submits a ticket, the search engine could parse the request as a search query and use that to search the knowledgebase; it could then ask the user if any of the top results would resolve their problem. The business value derived from this solution would include the faster ticket resolution for the end-users who can resolve their ticket using the knowledgebase, and it would involve the cost savings from not requiring a support resource when the self-service knowledgebase provides a resolution instead.

Search, like all the other features in SharePoint, does not have a magic formula to map to business value. You will find its value is solution specific and you can capture its value by analyzing the solution from the perspective of the business for a use case in the solution. I use this same process for any of the features and capabilities in SharePoint. How formal you make these use cases depends on what you are comfortable with and how much detail you need to document. I vary in my own degree of formal use case documentation depending on the project and the client, and it can range from rough whiteboard drawings to Visio summary diagrams to documenting detailed and descriptive use cases. I leave this decision up to your discretion, and I encourage you to experiment with them all to determine which technique or combination of techniques work best for you and your organization.

After you have mapped your SharePoint features and other composite applications to business value, you are no doubt eager to make haste and start delivering this value. In Chapter 2, I discussed some of the risks involved with losing control on the scope and having your project delivery unravel as it gets more and more features added on to its scope. I find staying focused on the business value helps redirect attention back to the outcome you are trying to achieve with the project, and that outcome is to deliver the planned business value. By maintaining this focus, I avoid having the project unravel into excessive gold plating activities with all the features the team or other project stakeholders can easily get distracted with in their excitement and enthusiasm for what is possible with SharePoint. As a result, this approach involves limiting features you make available, and having a plan for limiting those other features can help your delivery stay focused.

Planning for and Limiting Features

I hate to beat a dead horse, but as I already mentioned, I like to build a use case for major features and have this as my primary planning tool for new features. When I need to analyze business problems or understand the baseline to forecast business value, I like to create as-is use cases; and when I design a solution or plan an implementation, I like to create to-be use cases. This, of course, is a best-case scenario. Not every client will buy in to this process and they might not be willing to fund my time to utilize me in this manner. This does not mean I scrap this step altogether, it just means I scale back on its formality and depth. As I mentioned in the previous section, sometimes my use cases are simply rough drawings on a whiteboard.

As far as planning tools go, understanding how users will actually use a feature will help you set boundaries for it and to understand what it depends on. It also helps you ensure major features you are planning to deploy are features you map to business value. So you have a feature, you know how users will use it, and you mapped it to business value; now what do you do? From here, I also like to consider what a feature depends on. It is fine to say you want to enable a discrete feature, for example something like retention policies. You have a use case that describes how users will use it, and on its own, it does not seem to be overly complex, until you begin to list the dependencies. For something like retention policies to work well, you need to classify the different types of content and identify the retention policies of each. Then you might need a repository to retain content within and you may rely on other forms of enterprise metadata and workflows. On top of all that, you may have a host of other requirements related to enterprise search or the content creation processes. Right away, you can spot some potentially big dependencies on the Managed Metadata Service with an enterprise taxonomy defined, a records repository, and a content type hub with enterprise content types defined. You might find using a roadmap helps you with planning features so that you are enabling them after you have already implemented their dependencies.

A part of planning for the features you want to enable also involves planning for those features you do not want users to access. You may have any number of reasons why you want to disable features or prevent users from using them. One of the big reasons relates to what I have already pointed out, where you might want to control the release so it does not overwhelm the support team or the users themselves. I have also seen organizations that want to block features because another system already provides similar functionality and they do not want to confuse users or pollute their data strategy. Still other reasons I have seen are as simple as things such as the stakeholders are worried that the users will not understand how to use a feature or that they might abuse a feature.

Whatever your reasons for deciding, the reality is that you will most likely enable parts of SharePoint and leave other parts disabled. My primary strategy for achieving this is through administering and restricting permissions. If I want to enable one aspect of SharePoint and it involves several other features I would prefer to have disabled for whatever reason, I investigate whether there is a permission I can set to block usage of those other features. In many cases, there are permission settings to achieve this, and typically, I can set the permission as a web application policy to deny specific rights or I can control the permission settings through the permission management settings of a service application if it offers permission settings, such as the User Profile Service permissions shown in Figure 3-9. This is not always the case though, and sometimes I have to get a little more creative.

For those larger features, I might disable it completely by disabling the service, as long as another feature I deployed does not also depend on that service. If the features are a part of a service application I want to provide to one web application but not to others, I exclude that service application from the default group of service applications, and instead associate it with a custom group for the desired web application. Ideally, I can find a permission setting or a configuration solution such as the ones I mentioned here to limit or disable features. I never like to hack the user interface, as this usually becomes a maintenance headache down the road, but sometimes this is the only solution.

If I do need to block features at the user interface level, my first approach is to see if custom actions will achieve the goal. Custom actions are XML instructions that add or remove items from a menu and you deploy them using the SharePoint feature infrastructure. For this reason, I like them because they are easy to turn on and off, and it reasonably decouples them from the user interface, making them more manageable and maintainable over the product’s lifecycle. You can use custom actions to add or remove menu items from locations such as the site actions menu, the site settings menu, central administration menus, list and library menus, and the ribbon.

As a last resort, I modify user interface elements programmatically. I try to avoid this for performance and maintenance reasons, but sometimes I face strict requirements from clients that call for these types of modifications. I admit that I believe when it gets to this point it is probably easier to just plan for enabling the feature rather than get sucked into the quicksand that developing hacks to prevent them can quickly turn into. Notice I said I accomplish this programmatically, usually by adding a control to the page to make changes during the page’s runtime, and never by modifying system files.

Eventually you might want to enable some of those features as you progress in your roadmap and some delivery capacity becomes available. This is the beauty of SharePoint, because you can add to it over time, and you can add to it largely without having to rework previously deployed components or without much interruption to the service. Often this is as simple as turning a feature on. I have a couple of approaches I use to enable features over time I share in the next section, but they largely build on the concepts we have already discussed throughout this chapter.

Enabling Features Gradually

The first step to enable a feature might be as simple as reversing the approach you took in the previous section to limit it. This of course only addresses making the functionality available, but for some features, simply making their functionality available might be your approach. I call these the soft launches, because they occur where I release the new functionality behind these features but I do not broadcast the availability to my user base. This gives me time to ensure everything is stable and the feature is not causing a negative impact, thus avoiding ending up bombarded with support calls or user requests. Some users will naturally discover these released features by fluke or through exploring, but for the most part the initial adoption will be limited. From here, I may invite some early adopters to begin using the new features and monitor their success. Once I feel confident and ready for a larger audience, I may broadcast the availability with some training resources and usage scenarios.

In contrast to a soft launch where I gradually onboard new users, I may have a hard launch that encourages everyone to visit and use a particular feature. These more widely broadcasted releases are typical for scenarios such as new corporate portals or an enterprise search engine. It is expensive to run two systems in parallel while you do a gradual cut over, so these cases often become candidates for a hard launch and a complete switch over. Whatever your launch strategy is, in both cases you ultimately enable the feature and onboard users. This addresses the mechanics of enabling features, but now let me switch gears and share a game plan I typically use when I approach the decision around which features I want to tackle.

I like to build momentum by focusing on continuous and incremental improvements. Sometimes I need to launch a feature set that I would consider a new delivery rather than an expansion of an existing feature area, and I would call this a breakthrough improvement rather than an incremental improvement. The initial delivery of SharePoint in an organization is a breakthrough improvement, and introducing a wildly different capability area might be a breakthrough improvement as well.

Despite the occasional need for breakthrough improvements, my preference is for smaller, incremental improvements. Even when I do need to deliver a breakthrough improvement with a new delivery or distinct feature set, I try to limit the size so that it is not so big and radical. For me, the smaller the change, the better. This then allows me to evolve the rest of the feature set using incremental improvements, which ultimately helps me remain in my comfort zone where I can minimize risk while I am constantly delivering value.

This is where the momentum comes from, because many small deliveries of functionality will translate into many frequent successes. I find I generate momentum best by building it on a series of successes, and I build those successes through a process of continuous improvement. The Japanese word for “continuous improvement” is Kaizen. It comes from two words: Kai meaning “change,” and Zen meaning “good.” This philosophy fits well with how I like to work, as I am constantly trying to stay aware of opportunities to make small improvements; and making small improvements fits particularly well with how I like to deliver and evolve a SharePoint service.

I love the ideas and concepts that Kaizen encompasses: gradual, unending improvements based on many small changes rather than radical transformations. For SharePoint, this means not getting bogged down with trying to implement everything all at once. I have seen a ridiculous number of project delivery teams experience a bizarre twist of paralysis and quicksand that consumes them because they wind up consumed with chasing too much and casting too wide of a net in their SharePoint delivery. I imagine you have also seen a few or could go to any SharePoint user group meeting and hear stories about this experience (assuming the resources are not in denial or they are not afraid to admit that they got caught up in this scenario). This comes up frequently for me, either watching a project team sink or coming in afterward to try and get them back on track, and I have seen it so often that I can usually sense when a project is heading in that direction. You can sense it too if you watch for the signs. Ask yourself whether there is a general commitment toward incremental improvement and small changes, or are you heading toward breakthrough improvements and radical changes.

These are good theoretical concepts and I like how I worked Kaizen into the conversation, but how do you apply all this to SharePoint in practice? I like to use an example of a type of engagement that I have repeated with a few clients. Through this engagement, I began with the breakthrough improvement where I introduced SharePoint. This first step was really to get it installed on some servers and enable its core functionality with some team sites or maybe a generic portal. I did not add any customizations or even any complex configuration settings just yet, as I simply deployed an out of the box web application with basic services. This gave me a baseline foundation to build on and extend; yet, at the same time, it delivered working value to the business. For the next phase, I incrementally improved on this service by adding search capabilities. To add search, I created a search service application and crawled the content. Bam! Now the SharePoint service has search and I have not interrupted the users or caused a drastic change. This delivered more working value to the business. Following on this, I thought, it sure would be nice to search for people. I created a User Profile service application, configured an Active Directory connection, and scheduled profile imports. Just like that, I enabled a simple people search. From there, I looked at improvements I could make in the profile properties for advanced searches, and then eventually I looked at enabling MySites.

These features all build on each other and they offer a natural progression. At this point, I could consider improvements in the branding and user experience, or improvements in search properties, or even improvements in different social features such as introducing community sites. For a couple of customers, I worked with them to take the existing physical office location number attributes associated with a user profile and plotted them on a floor map that I displayed in a web part. User profiles included location information and the facilities department had digital floor maps for each of the corporate buildings, so I could make an incremental improvement by developing a web part to add a visual floor map to the public user profile page. I got this idea from some of my former colleagues who developed a similar solution for their SharePoint deployment. The result: I could improve people’s experience incrementally with MySites and people profiles, because in addition to finding their digital location on the corporate network quickly using the people search engine, people search users could then visually see how to find people’s physical location as well.

Incremental improvement is not limited to configuration settings within SharePoint and it can include custom development solutions just like my custom developed floor plan web part that visually plots the location of a user’s office or desk. It can also include integration solutions, such as those enabled through Business Connectivity Services. This might be as simple as connecting with a database containing a list of all the organization’s customers and making that available as external lists for sites to use to tag content.

The trick is to think about these features as things you can introduce over time. I find thinking about them with this perspective helps me work in a mindset of continuous and incremental improvement. My main strategy for this is to run my SharePoint service delivery as a program rather than as a project, especially for the initial delivery. A project has a beginning and an ending; it will live once and then eventually (hopefully) you will complete it and put it to rest. A program on the other hand consists of a series of projects, and so I find it easier to maintain the scope of the individual project streams when they are within a program rather than if they wrap their delivery in a single project that may or may not consist of phases. It may seem like a slight diction difference, but I find this wording can make all the difference with expectation management from project stakeholders and delivery team members.

If we consider the approach that I describe throughout this chapter, those project deliveries within the SharePoint service program each contain a delivery cycle. For each project and for each feature set within a project, I cycle through a set of activities and project phases. I like to work using the Microsoft Solutions Framework (MSF) at the project level, where I go through the five MSF phases of envisioning the solution, planning the solution design and approach, developing the solution, stabilizing the solution, and releasing the solution. For each business problem I am addressing I also go through a conceptual continuous improvement cycle, as Figure 3-10 illustrates. I analyze the problem or opportunity, create the as-is use cases, design a solution, create the to-be use cases, and deliver the solution.

In short, my best SharePoint delivery success strategy consists of running the delivery as a program with a series of small and distinct projects, each concluding with a frequent delivery to production, and each offering a small incremental improvement.

Deciding Which SharePoint Features to Enable

In this chapter so far, I have described how to map the features you need to measures of business value and I have provided you with some strategies to limit features and enable them over time. This still might leave this question unanswered: Where should you start and how do you pick what features you need to get started? This can be problematic, because it drives the focus on features rather than on business value, and it can lead you into a situation where you are looking at a shopping list of SharePoint features rather than focusing on a business opportunity.

I have noticed this shopping list approach can be a popular one where people look at a shopping list of available SharePoint features and then they try to determine which ones they need. It can also resemble writer’s block: where too many options or future tasks distract you to the point where your writing stalls. In a similar fashion, your SharePoint delivery can stall when you torment yourself with all the different features, and you end up stuck wondering how you can have it all despite your limited delivery capacity and your scarce resources. Perhaps I can coin a new term for this: SharePoint solution designer’s block. When the emphasis is on SharePoint features, I find it near impossible to prioritize a service delivery, and this lack of an effective prioritization process stalls me. It leads me to experience SharePoint solution designer’s block!

When the business drives your priorities, you will naturally find the best place to start, and this will lead you to the features you need. If you start with the business case that will deliver the highest amount of value or address the greatest need, you will identify the features you need with ease. So the question of what features do you need is answered by identifying what features are required to fulfill a given business case.

There you have it; we have come full circle in this chapter. As great as all the features are, they are not that great if they are not adding business value. Start with identifying the business value, and your decisions around the features will follow.

Consultant Comrade

This section is a little difficult, or more precisely, a little delicate for me to write. I too am a consultant, so I understand you have conflicting priorities with the approach I presented in this chapter and your consulting business model. Specifically, I am referring to the idea of Kaizen, where you focus on continuously making incremental improvements and small changes rather than going after the breakthrough improvements and radical transformations. Everyone seems hungry to land the big fish, and I have no illusions that a sales representative is motivated to land the big fish most of all – a sales representative who probably receives a bonus based on the amount of revenue sold. Why would they ever scale an opportunity back to deliver small projects and only make small changes?

One typically would not design or incentivize a consulting services business around encouraging smaller projects. From this perspective, I expect the approach I discussed in this chapter to be a non-starter for most SharePoint consulting services organizations, especially those more transactional ones who simply want to plug a hole with a resource for as many hours as they can possibly sell. In all likelihood, your SharePoint consulting practice is in business to make money, just like my consulting practice is in business to make money, and it makes money by billing resources out to clients. We are not on different pages though, and I am not throwing a wrench in your business model. I am merely sharing approaches that have worked for me in my own SharePoint consulting practice, and approaches that have worked for me when I worked for other consulting practices.

My approach is to focus on treating a SharePoint delivery as a program, a program that consists of a series of small projects that each delivers incremental improvements. You can still get commitment for those bigger fish by selling a program. Perhaps part of the program you sell can involve advisors where you embed some of your consultants on your client’s team to advise and influence the program. I can keep mentioning this approach until I am blue in the face, but if you are not the decision maker on how your engagements are structured, then I am probably preaching to the choir, and you might feel that there is little that you can do with this information. I run my SharePoint consulting practice and I structure my own engagements, so in that sense it is a little easier for me because I am the decision maker as well as the consultant. What do you do when you work for a consulting firm who will not run their delivery with projects structured in the way I propose? There are many reasons for this, and perhaps it relates to fixed bids or the types of Requests for Proposals (RFPs) your firm gets involved in pursuing. Sometimes your client wants to make a big bang with a huge launch, and you have to align yourself with their vision if you want to win the business.

You can have any number of legitimate reasons why you might have to go with a large project. For example, I have found it difficult to set contracts for consulting using agile practices such as scrum or extreme programming, as the typical consulting business model struggles with adapting to these delivery methods. Adapting to fit Kaizen is no less of a struggle. I think Kaizen closely fits with agile practices, particularly with the principle of delivering value early and delivering value often. My history working in agile software development environments might be the reason I like Kaizen so much and why I try to embrace it in my life. However, I have also worked in waterfall software development environments where we have a fixed ship date for the next iteration several months out, and the team is only focused on marching toward that date rather than any sort of iteration or quick delivery. I have also worked for consulting firms who deliver large projects in a similar fashion where I do not have any control over the structure of the project or how I deliver; they merely deploy me and I have to run with it.

My most prized approach allows me to adapt to these types of large projects and still feel close to my comfort zone. In my prized approach, I have found that the sooner I can deploy a staging or sandbox SharePoint environment for the team and the stakeholders to interact with, the better. I have been on a few large projects where they are streaming along within the bounds of the contract, yet I have the sense they are not as successful as they might have been if they had adopted the Kaizen approach. In my retrospectives for those projects, I have found a common element that could have helped improve our success, and that common element would have been to deploy SharePoint early for a limited audience of stakeholders and to get these people using the software. If we develop a system of treating this staging environment as our Kaizen-like delivery environment, and we deploy updates to it frequently with subtle changes that the stakeholders can try out, then we can still realize those Kaizen benefits that I like.

A caution though: deploying an unexpected SharePoint staging or sandbox environment does have the risk of pulling you down into a rat’s nest as it adds unbudgeted scope to your project. I keep this addition very simple. First, I sell the idea with my clients that they need this environment deployed as early in the engagement as possible. I am actually a little relentless with encouraging them to get this in place, and I simplify the burden it would have on my time by proving them with a checklist to get everything prepared and ready so we can be up and running with a default install in a minimal amount of additional unplanned effort. That checklist includes actions such as a server list that they need to provision, service accounts that I will need, URLs they need to create DNS hostnames for, and the install media. With all this in place, I can usually walk though an install with one of the client’s server administrators in a relatively short period.

Having this staging environment also gives the client’s server administrators a chance to walk through the install with me early on. Often times, they have not received any SharePoint training or they have only recently been introduced to the product. In those cases, the hands on experience is invaluable for them and it helps set their expectations early about what managing a SharePoint environment will be like. Even if they are experienced SharePoint resources, I can provide them with a significant amount of knowledge transfer in a short period while we go through the install process, both from my pointing out details on configuration settings and from conversations on my experience with other clients.

Once you have this staging environment set up and accessible to the project stakeholders, my next recommendation is to build a schedule for frequent and regular deployments of your deliverables to this environment. I like to deploy these deliverables in a working state, but they may not be feature complete. I try to have a discussion with my project stakeholders about alpha and beta software builds so they know we are continuously going to evolve this deployment on whatever schedule we establish. Personally, I like to deploy to a staging environment every week or every two weeks if possible. Because I am using this to insulate and hedge against the risks involved in a large project, I prefer to have short beta release cycles to get feedback on our progress and to experience the momentum from our deployment successes. Having shorter release cycles also keeps my client’s project stakeholders involved in the project delivery, much as they would be in a Kaizen process. This process also fits well with the development team processes I prefer, which include frequent integration builds and regular automated testing. I return to this topic in Chapters 14 and 16 where I describe my preferences for a successful development and release process.

I cannot stress this enough: break your project down into small chunks and then deliver those chunks to your clients frequently. Whether the contract includes this process or not, and whether you are delivering to production or to a staging environment, I have found the potential for success increases remarkably with this approach.

Inside Story: Notes From the Field

Years ago, I worked for a company and my focus was on expanding our SharePoint service to meet more needs in the business. I was new and did not have a lot of experience supporting a large number of users, so of course I just wanted to turn everything on and make features available for my users. My manager Micki, thankfully, was a little more experienced and she gently guided me in the correct direction every time I suggested we introduce a new feature. She would respond supportively and ask me to create a business case for it first, and then we could look at going ahead. My first reaction was that the feature was free, or at least it was included in the licenses we already purchased; all I had to do was turn it on – how much more of a business case would we need?

As I learned, licensing costs are not the only costs involved with providing software as a service to the organization. My largest operation costs typically related to support activities, and if I turned something on willy-nilly without foreseeing potential issues, then I could quickly find myself in a support nightmare. Worse yet, if I turned on features that did not offer enough business value, I would then have only managed to add to our budget pressures without adding any value to my internal customers. Finally, without any vision or strategy behind the features I enabled, I would have no plan for how they all work together and how I should prioritize them. If I was unclear on the purpose of a SharePoint feature, then my customers would surely feel hazy around what they should use it for, or why they should even use it.

My internal customers constantly faced time pressures: they had tight deadlines and could not afford any diversions that would pose a risk against meeting those deadlines. The organization measured them and gave them bonuses based on shorter-term cycles and immediate targets, typically within the next year, and they did not have much incentive for longer-term strategic initiatives. I think their focus was typical of many workers in the way their incentive measures how they deliver immediate results and immediate value. Everything beyond that is certainly nice to have, but detrimental if it came at the expense of delivering any of the required immediate value. So the potential business value for them was two-fold: how can I support and speed up their delivery of immediate value, and how can I remove any barriers or blockages that impede their progress?

Time was the biggest business value I could deliver to them. They would find saving money nice, but for them time was much more important. If something delays them in their delivery, their potential revenue loss would be orders of magnitudes greater than the little bit of budget I might save for them. They needed procedures streamlined and automated; they needed technology to naturally fit with their processes and bare some of the load so they could focus their attention elsewhere. Saving them time was the ideal business value to map features to, either by speeding up turnarounds or by automating tasks for them wherever possible.

Often saving budget or increasing revenue is what dominates the activity of mapping features to business value, since for-profit organizations are usually in business to make a profit. In the case of my example, my internal customers were attracted to saving time because it led to greater revenues and ultimately a better profit performance, so their case was no different. However, many organizations do look beyond profit in their measures, particularly those not-for-profit organizations, and they might measure other metrics such as increases in the number of people serviced or increases in the mass-communication of an idea. In this case, I mapped features to the amount of time the features saved, and I used this as the primary measure of business value I delivered.

In this case, I needed one version of the truth in a spreadsheet that supported editing with high concurrency and without the risk of overwriting each other’s changes. Rather than e-mailing multiple versions of an Excel spreadsheet around and requiring a resource to collate them all once everyone added their input, I could offer an online and centralized location where everyone edited the same copy. Rather than host the spreadsheet in a file share where one user could unknowingly overwrite another user’s edits, I could offer the check-in and out features in a SharePoint document library to control the editing of a single shared spreadsheet. I could provide a real-time and single version view into the state of a team’s progress with testing, and provide a controlled manner for editing. However, this became problematic because each tester on the team preferred to have their version of the Excel spreadsheet opened all the time while they worked, which earlier versions of SharePoint document libraries did not handle well.

They were used to storing the spreadsheet on a file share and using a feature in Excel to allow multiple concurrent editors. The file share did not solve the problem either, because user changes could sometimes be lost or overwritten, and hence where my initial focus on checking spreadsheets out for edit rose to address that surface-level need to protect their edits. Once I met with the team and understood the underlying use case, I could focus my business value questions on the real problem: how much time did an average tester waste by double-checking to ensure their changes were not lost, or how much time did they spend merging their changes with multiple versions? If I had SharePoint 2013 deployed, I could map the features in Office Web Apps to this amount of time saved as the business value. In addition, I could map value to how providing a web version of the spreadsheet would allow multiple testers to edit and see each other’s edits while they all kept the web version of the spreadsheet open.

Wrapping Up

In this chapter, I looked at some of the new features in SharePoint 2013 and what its core capability areas are. I also discussed how to plan for and limit features, and I shared some approaches that you can take to map features to business value. Finally, I discussed techniques you can use to enable features over time by continuously introducing small changes and incremental improvements.

Now that you have looked at the different features and capabilities that SharePoint 2013 offers, and how to expand your deployment to enable those features over time, I will build on these ideas as I look at how you can ensure coverage and support for these features. In the next chapter, I discuss all the roles involved in a typical SharePoint deployment and I use this list to offer guidance on how to map these roles to specific responsibilities that the SharePoint service requires to support its operations. I also provide a sample RACI chart with some common roles and responsibilities, and then I provide you with considerations for adapting the sample to fit your needs. Finally, I discuss how to ensure you have end-to-end coverage supporting your SharePoint service and what approaches you can take to formalize your communication process.