Pro SharePoint 2010 Governance docx

These checklists are split up using the same conceptual framework used to structure the rest of the book: • Governance Planning Checklist • IT Management Checklist • Information Manageme

For your convenience Apress has placed some of the front matter material after the index Please use the Bookmarks and Contents at a Glance links to access them

Contents at a Glance

Contents vii

About the Authors xvii

About the Technical Reviewer xviii

Acknowledgments xix

Introduction xx

Chapter 1: A SharePoint Manifesto 1

Chapter 2: SharePoint Governance Overview 7

Chapter 3: Governance Planning 23

Chapter 4: Implementing Services 33

Chapter 5: User Training and Adoption 55

Chapter 6: Managing Content 77

Chapter 7: Managing the Server Farm 97

Chapter 8: Managing Operations 131

Chapter 9: Information Architecture Overview 151

Chapter 10: Information Delivery 161

Chapter 11: Branding the User Interface 187

Chapter 12: Customization and Tools 203

Chapter 13: Packaging Solutions 225

Chapter 14: Application Lifecycle Management 263

Appendix A: Online Resources 279

Appendix B: The Governance Plan 287

Appendix C: Governance Checklists 293

Index 303

■ INTRODUCTION

Introduction

Governance is the process of creating policies and rules and assigning roles and responsibilities to make

a system work properly Even if your attitude is “Good Government is Less Government,” very few of us would want to have no government In short, governance is the difference between order and chaos

In this book, we will explore the concept of governance as it applies to a business’s use of the SharePoint family of products It is assumed that the reader is familiar with the concepts of web sites, collaboration, and portals as they are used in SharePoint SharePoint provides a platform for creating,

storing, and retrieving information This information is generically referred to as content and it can take

many forms, such as documents, calendars, lists, and web sites The features of SharePoint allow users within an organization to collectively or individually create content and publish it for others to use By making this information quick and easy to find, categorize, and organize, SharePoint can provide a lot of business value SharePoint is also a very extensive product that contains many features that can cause problems if not used correctly

Who This Book Is For

This book is intended for anyone who will be involved in the governance of a SharePoint-based site This should include both IT and non-IT business owners, developers, administrators and, perhaps most-importantly, those who will represent the system’s users

The early chapters are non-technical in nature They cover the best ways to structure and manage the governance process We would encourage everyone on the governance team to become familiar with this information Later, there is technical information about the features and options available on the SharePoint platform Not everyone will need to be familiar with these details

coworkers, do ordain and establish this governance plan for the portal of our organization

First, an apology to the memory of Gouverneur Morris, the author of the Preamble to the US

Constitution The paraphrasing above is a modest attempt to make a point about governance The

purpose of the original Preamble was to describe the reason for the rest of the constitution and for the

government of the United States as a whole Governance is the process of creating policies and rules and assigning roles and responsibilities to make a system work properly Even if your attitude is “Good

Government is Less Government,” very few of us would want to have no government In short,

governance is the difference between order and chaos

To paraphrase another great American statesman, Abraham Lincoln, effective governance should be

“of the users, by the users and for the users.” The key to any SharePoint implementation is adoption If users don’t want to use the site, they won’t use it any more than is absolutely necessary To get the full

value out of SharePoint, it must be a place that users go to make their lives easier Good governance can help achieve that goal

Governance OF the Users

In this book, we will explore the concept of governance as it applies to a business’s use of the SharePoint family of products We assume the reader is familiar to some degree with the concepts of web sites,

collaboration, and portals as they apply to SharePoint SharePoint provides a platform for creating,

storing, and retrieving information This information is generically referred to as content and it can take

many forms such as documents, calendars, lists, and web sites The features of SharePoint allow users

within an organization to collectively or individually create content and publish it for others to use By

making this information quick and easy to find, categorize, and organize, SharePoint can provide a lot of business value SharePoint is also a very extensive product that contains many features that can cause

problems if not used correctly

Establishing a SharePoint Server 2010 environment is reasonably simple, but maintaining it and

controlling it in a way that maximizes its benefits to the users and the business is not SharePoint

consists of many interrelated subsystems and services such as Search, Content Management, Record

Management, PerformancePoint Services, and so on SharePoint also serves as a platform for integrating

CHAPTER 1 ■ A SHAREPOINT MANIFESTO

and delivering other Microsoft products such as Dynamics, Project Server, and SQL Server Reporting Services Additionally, there are numerous third-party vendors that provide SharePoint-based products

to provide solutions for backup and recovery, data archiving, image management, and many other things With all of these potential features available, it is reasonable to assume that not all of them will be appropriate for your environment

One of the most important decisions to be made when delivering a SharePoint-based solution is to determine which of the supported features should be made available to the end users and which should not The most common mistake made by organizations when they adopt SharePoint is to install the product and tell their users to “go ahead and use it.” This approach can cause many problems, but the two most common are the following:

1 No one uses the system because they don’t really know what it can do for

them

2 Users begin dumping huge amounts of data into SharePoint with no

organiza-tion or categorizaorganiza-tion

By governing the features available to users, the goal is not to prevent the use of certain features, but

to encourage the use of those features that are of most value to the organization

Governance BY the Users

If we are honest with ourselves, most of us have to admit that we do not like people telling us what we can and cannot do On the other hand, we like to be in control An effective governance team must include the people who will be using the system if they are to feel that they have any say in the running

of the system It must also include the IT professionals responsible for installing, configuring, and maintaining the infrastructure that supports it Finally, the executives and managers responsible for funding the system and insuring that it is returning value to the business must also have a seat at the table

Building an effective governance team is the first step in building a truly collaborative environment for end users

Governance FOR the Users

A SharePoint solution will only be successful if people use it This seemingly trivial statement is the key to understanding why governance is critical If your users consider the SharePoint services provided to be a hindrance to their everyday tasks, they will quickly abandon the system and it will fall into disuse Effective governance should include plans to drive adoption and training of users as well as ensuring that the system is meeting their needs and making their jobs easier In organizations that successfully adopt SharePoint, it quickly becomes an invaluable tool that grows to support every aspect of the business

In this book we will examine how to create just such an environment Everything you do in

governing the SharePoint environment should drive a productive, stress-free user experience

Finding What You Need in This Book

SharePoint governance covers a lot of ground because SharePoint is such an extensive product line Fortunately, not everyone involved in the governance of a SharePoint solution needs to be intimately familiar with the technical details of the platform This book is divided into different parts that are targeted to different audiences

CHAPTER 1 ■ A SHAREPOINT MANIFESTO

Part I: Establishing Governance

The first part of this book will introduce the concepts and processes involved in creating and

implementing a governance strategy for your organization Anyone involved in the governance of the

system should be familiar with these concepts These are general business concepts that do not include

a great deal of technical detail

Chapter 2: SharePoint Governance Overview

This chapter introduces the conceptual framework used throughout the rest of the book It will define

key terms and divide the process of governance into manageable pieces We will start by defining a set of terms and establishing what our goals are in creating a governance plan SharePoint implementations

often encounter similar challenges We will look at these and consider ways to overcome them Finally,

we will discuss the need to match the policies used in your situation to the purpose of the site and the

culture of your organization

Chapter 3: The Planning Process

This chapter covers the steps required to set the scope of the governance effort and develop a high-level governance plan This includes identifying the roles and responsibilities of everyone involved and

establishing a team to ensure that the plan is implemented effectively This team will need to include

management, IT, and end-user personnel to ensure that all plans are realistic, supported, and targeted

to the needs of the users

Chapter 4: Implementing and Maintaining Controls

This chapter covers the process of implementing a good governance plan This involves mapping the

services to be provided to the features of the SharePoint platform Creating a robust system requires

taking the end user’s goals and feedback into account before, during, and after deployment of the

solution Implementing a sustainable, flexible, long-term solution requires planning for security,

upgrades, enhancements, and any other changes that may affect the organization’s use of the system

Chapter 5: User Training and Adoption

SharePoint sites are designed to be very intuitive out of the box, but to fully leverage the power of

SharePoint, some end-user training is required Users can be classified into three distinct groups: casual users, power users, and site owners Each of these groups requires a different level and type of training

One of the most common reasons for failed SharePoint deployments is a lack of understanding on the

part of the end users People will not use features they do not understand or are not aware of

Part II: Information Technology Governance

This section covers governance from the point of view of the IT organization responsible for

implementing and maintaining the system IT Governance is centered on controlling the installation

and maintenance of the servers and software that make up the solution This includes configuring and

securing all of the services to be provided to end users Effective IT governance prevents the proliferation

of unmanaged sites and services and provides for a stable user experience

CHAPTER 1 ■ A SHAREPOINT MANIFESTO

Chapter 6: Types of SharePoint Sites

The level of governance required for a site depends on the purpose of the site and the nature of the information to be created and managed This chapter examines the common types of sites deployed in a SharePoint environment and discusses the policies and controls that are appropriate to each

Chapter 7: Services and Deployment

This chapter discusses the techniques used to deploy and manage services in a SharePoint

environment Services such as Search and Content Management are discussed in some detail We also discuss the use of asset classification taxonomies, security, and quotas to protect the system from chaos and outside intrusion

Chapter 8: Managing Operations

Once a system is deployed it is critical that it be monitored and managed effectively This chapter discusses the different types of SharePoint farm configurations along with the types of monitoring that need to be performed Planning for security and capacity requirements is also covered

Part III: Information Management

This section examines information management (also known as information architecture) as it applies to

SharePoint Information management is concerned with organizing the information stored within the SharePoint sites so that it can be used to generate the greatest value Concepts covered include

taxonomies, audiences, legal and compliance issues, search, site navigation, and the user interface The purpose of information management is to classify, protect, and deliver business data in a way consistent with the goals of the business

Chapter 9: Information Architecture Overview

Information architecture refers to organizing and categorizing the information stored in the SharePoint

content databases This chapter provides a primer on the concepts associated with designing and managing the information within a set of SharePoint sites Topics covered will include site hierarchies, metadata, and taxonomies

Chapter 10: Delivering Information

Once data has been created, classified, and stored in the site, the users need the ability to find and access that information This chapter discusses the features in SharePoint that support the creation of

metadata used for audience targeting and finding information with Search There is also a discussion of the social media features in SharePoint and a detailed conversation of security as it relates to

information discovery and security trimming

Chapter 11: The User Interface

This chapter deals with the presentation of information within SharePoint sites SharePoint content is organized into hierarchies of sites, each consisting of several pages and other types of content items

CHAPTER 1 ■ A SHAREPOINT MANIFESTO

Navigation controls (also known as Menus) are used to traverse this hierarchy Designing rich navigation and a pleasing overall site appearance often drives the user’s perception of the site This chapter covers the design aspects of branding sites including themes, master pages, and page layouts

Part IV: Application Management

While SharePoint comes with many sophisticated features, any major SharePoint implementation will

require some customization or enhancement This can include anything from minor changes such as

creating custom lists or color themes to extensive rebranding or code development Application

management allows the organization to control the way potentially harmful functionality is tested and deployed without threatening the stability of the system Applications to be managed can include

SharePoint itself, other Microsoft Server products, non-Microsoft SharePoint enhancements, and

custom developed functionality

Chapter 12: Customizations and Tools

Customizing SharePoint sites consists of many facets that all need to be managed From the branding

of the site to the introduction of new content and functionality, these updates must be created and

deployed in a way that maintains the look and stability of the system This chapter discusses several of

these tools and when they are appropriate Establishing policies and controls around customizations is

a key to proper governance

Chapter 13: Packaging Solutions and Sandboxing

When developing new functionality for deployment on the SharePoint platform, there are different means for packaging the artifacts involved This chapter discusses the best practices around deploying custom features to SharePoint and managing the updates to these packages One of the most important features involved in the deployment of custom functionality in SharePoint 2010 is the sandbox service that runs such code in a protected environment We discuss when use of the sandbox is and is not appropriate

Chapter 14: Application Lifecycle Management

This chapter discusses Application Lifecycle Management (ALM) as it applies to custom SharePoint

solutions We discuss source and configuration control as well as the environments used to develop, test, and deploy these solutions Topics covered include best practices for source control, test environments, issue tracking, and upgrades

Part V: Appendixes

The final section contains a set of resources you can use to jumpstart your organization’s SharePoint

governance effort This includes online resources, document templates, and checklists

Appendix A: Online Resources

This appendix contains numerous links to business, technical, and product information on the Internet Links to valuable sites and blogs devoted to IT, Information, and Application architecture on the

SharePoint platform are also provided

CHAPTER 1 ■ A SHAREPOINT MANIFESTO

Appendix B: The Governance Plan

This appendix contains an outline for a comprehensive governance plan that includes all of the concepts covered throughout the book You are encouraged to use this outline as a starting point for your own governance plan document This template can be customized to your organization’s needs by adding or removing sections as appropriate to your situation

Appendix C: Governance Checklists

This appendix contains a set of checklists that IT and business professionals can use to ensure that each

of the concepts discussed is addressed in the final implementation plan These checklists are split up using the same conceptual framework used to structure the rest of the book:

• Governance Planning Checklist

• IT Management Checklist

• Information Management Checklist

• Application Management Checklist

Summary

As you explore the concepts of SharePoint Governance, you need to keep in mind the goals the

organization has for adopting SharePoint in the first place These usually include ease of use, business efficiency, new capabilities, security, and legal and compliance issues You should strive to balance the need for control against the need for flexibility

In the end, the success or failure of a SharePoint system is determined by its users If the system makes their lives easier, everybody wins This is why effective SharePoint governance is governance OF the users, BY the users and FOR the users!

C H A P T E R 2

■ ■ ■

SharePoint Governance Overview

In this chapter, we will introduce the conceptual framework used throughout the book and define the

terminology used to describe and govern SharePoint solutions By the end of this chapter, you will

un-derstand the purpose and process of governance and, hopefully, where you fit in

What Will You Learn in This Chapter?

• Why you need governance and how it should be structured

• How the services provided by the portal are identified

• How to define the roles and responsibilities associated with controlling a

Share-Point solution

• How the segments of IT, information, and application management relate to one

another

• The purpose and general structure of a governance plan

• The common issues experienced in a SharePoint environment when governance

breaks down

The Purpose of Governance

Why establish governance over any human activity? Why not just let everyone do their own thing? Isn’t freedom supposed to be a good thing? For an answer, take a look at any country in the world where the government has failed and a new one has not replaced it right away It is not a pretty picture

Of course, failing to assign storage quotas on your corporate intranet isn’t likely to result in hordes

of crazed co-workers fighting to the death over the last of the copier toner More likely, the system will

just crash or be left in an unusable state Developing policies and standards and assigning ties to the appropriate departments creates a system that can support business needs without becoming

responsibili-an impediment Or maybe users shouting responsibili-angry slogresponsibili-ans while waving burning torches are a normal part

of your corporate culture?

The most important consideration in developing your governance strategy is determining the needs

of the users and adapting the governance plan to meet those needs as effectively and unobtrusively as

possible This requires an understanding of the users’ business processes, preferences, and working ture SharePoint is a widely varied product with many features that can be productive, useful, confusing,

cul-or annoying depending on the needs of the system’s users and how those features are leveraged

CHAPTER 2 ■ SHAREPOINT GOVERNANCE OVERVIEW

The two most common mistakes when establishing governance are to implement too much ance or too little

govern-There is no such thing as a SharePoint installation with no governance Anarchy is not a default; it is

a choice Even if an organization has intentionally avoided putting any restrictions on users, that is a governance choice SharePoint sites where users have absolutely free reign are all too common The re-sult is most often a site clogged with massive amounts of data, but very little useful information Users can’t find anything except the most recent content they added themselves Older data or content con-tributed by others may as well be on a floppy disk in someone’s desk for all the good it will do them Eventually, the site becomes slow and unreliable and falls into disuse

Too much governance, on the other hand, robs users of the opportunity to innovate and use their creativity to find new ways to do business If you have an inherently collaborative corporate culture, un-necessarily restricting access to SharePoint’s collaborative features such as team sites, document work-spaces, wikis, and social networking may cause that collaboration to shut down Alternately, team mem-bers may abandon the portal to collaborate effectively Overly aggressive security restrictions can also prevent users from finding valuable information they need to make important business decisions Too much governance, like too little, is likely to result in a system that users don’t choose to use

No one wants to live in total anarchy or a police state That’s why effective governance must take a

“Goldilocks” approach Not too little, not too much Not chaos, not prison You want users to be fortable using SharePoint It should be as natural a part of their work day as opening their e-mail Oth-erwise, they will seek easier ways to perform their tasks outside of the portal After all, Goldilocks didn’t stay in the bed that was too hard or too soft, but in the one that was just right

com-Services

The first concept we will introduce is that of a service In this context, a service is a set of features that the

portal provides to the community of end users In SharePoint, these services might include discrete systems like Excel Services or PerformancePoint Services, but they also include more general services like authentication and secure (SSL) site access A service is the basic unit of functionality to consider when planning the governance of your portal

sub-A service has a lifecycle that starts with installation and configuration of the service, also known as

provisioning the service Once the service is provisioned, it must be monitored and evaluated to see how

well it is meeting user needs When improvements are needed, the service may need to be reconfigured

or upgraded to meet new or refined requirements At some point, it may be decided to remove a service because it is no longer needed When a service is decommissioned, it is often necessary to migrate its associated data to another service or system

As shown in Figure 2-1, governing the lifecycle of a service is a continuous process that doesn’t end

as long as the service is in production This ensures that the service continues to meet the requirements

of the organization in a sustainable way This cycle of continuous monitoring and re-evaluation will be a recurring theme as you examine all of the processes used to govern a SharePoint portal

Figure 2-1 The lifecycle of a service

CHAPTER 2 ■ SHAREPOINT GOVERNANCE OVERVIEW

The first step for any SharePoint team is to identify the services to be provided These services can

be broken down into two general categories: mandatory and optional

Mandatory Services

Some services provided by SharePoint are mandatory in the sense that, just by deploying SharePoint,

those services are made at least partially available; they cannot be turned off completely These services provide the infrastructure on which the rest of the SharePoint site is built These services must be

planned before any SharePoint solution can be successfully deployed Some of the more important of

these services are

• Authentication: The ability to identify users on the site Even public-facing sites

that allow “anonymous” access must have the ability to identify certain users in

order to support updating site content By default, SharePoint users are identified

using an Active Directory domain Alternately, users can also be authenticated

us-ing claims-based services that use other types of credentials

• Authorization: The ability to control access to resources within the site

Share-Point uses an internal set of permissions, similar to file Access Control Lists

(ACLs), to control access to all of its resources

• Data Storage: SharePoint stores configuration, content, and other critical data in

a series of MS SQL Server databases hosted on database servers within the

orga-nization

• Farm Administration: SharePoint’s Central Administration (CA) web site is the

primary tool for configuring the services within the farm There are also

com-mand-line tools and scripting languages that can be used for administration The

end users of these tools are generally limited to the IT professionals tasked with

maintaining the portal

Each of these services must be installed, configured, and monitored to keep SharePoint running

well The key decisions to be made to govern these services are listed in the checklists in Appendix C

Optional Services

SharePoint contains a large number of subsystems that can be turned on and off by farm administrators

or other privileged users These are the optional services Depending on the edition of the SharePoint

product your organization is using, you will have different optional services to choose from Here are

some examples:

• SharePoint 2010 Foundation Services

• Business Connectivity Services

• Client Object Model

• SharePoint Designer Support

• Security Sandboxed Solutions

• SharePoint 2010 Server Standard Edition

• Audience Targeting

• Search

CHAPTER 2 ■ SHAREPOINT GOVERNANCE OVERVIEW

• Content Organizer

• Document Sets

• My Sites

• SharePoint 2010 Server Enterprise Edition

• InfoPath Forms Services

All of these services have different configuration options and security considerations Planning for the provisioning, monitoring, and user training around these services is a critical first step Once com-prehensive service planning is complete, the next step, provisioning (shown in Figure 2-2), should be fairly straightforward

One of the unfortunate truths to note about SharePoint, or any complex platform, is that it is often more difficult to upgrade or reconfigure a service than it is to initially deploy it This reprovisioning re-quires at least as much planning as the original installation We will revisit this situation several times later in this book

Service Monitoring

Monitoring a service involves collecting data about how the service is being used and how well it is ing its intended function Monitoring can take several forms, depending on the service The NT Per-formance Monitor (PerfMon.exe) can be used to collect a variety of metrics about the use of each server such as CPU, memory, network, and hard drive usage System event logs and SharePoint log files can be used to diagnose problems as they arise Finally, SharePoint’s built-in usage tracking features can be used to produce reports detailing how different services are being used in production

serv-Note: Don’t forget to collect data from the most valuable resource you have: the users! Help desk tickets, plaints, compliments, and any other form of feedback you can get are invaluable service planning information

com-Monitoring the services provided would be pointless without some way of using the data collected The governance team needs to periodically evaluate the data collected to identify services that are not meeting the organization’s needs for some reason These may include services that are not being used effectively due to technical problems, user unfamiliarity, or changes in the needs of the users Services

CHAPTER 2 ■ SHAREPOINT GOVERNANCE OVERVIEW

may also need to be reconfigured to provide better functionality Also, services that have not been

de-ployed may need to be considered for addition to the catalog of services provided

migrating, the data already present in the service to a new location or, at a minimum, archiving that data

so that it can be referenced later as needed Decommissioning a service should not be viewed as a

fail-ure, but as a strategic decision made for the benefit of all users and the organization as a whole

Once the necessary service changes have been identified, planning must begin for provisioning, configuring, or decommissioning services to meet the needs of the user community This closes the loop

re-on the service lifecycle and allows the system to grow and change as needed

Governance Segments

The next major concept to understand relates to segments Governance segments can be thought of as

the three dimensions of system management Each segment covers a set of activities that must be

per-formed to effectively govern the site These segments provide a useful means of categorizing these ties and understanding how they are related to one another

activi-As shown in Figure 2-2, the three segments are Information Management, IT Management, and plication Management Each service deployed in a SharePoint solution needs to be evaluated from the

Ap-point of view of each of these segments

Figure 2-2 SharePoint governance segments

CHAPTER 2 ■ SHAREPOINT GOVERNANCE OVERVIEW

IT Governance

Governing a SharePoint solution from an Information Technology perspective is probably the most vious segment SharePoint is a family of extensive, complex software products, after all The first interac-tions most organizations have with SharePoint are within the realm of the IT department

ob-IT governance refers to all the activities associated with installing, configuring, and managing the

SharePoint servers and product features In other words, this is how you keep the lights on A major ing of many governance efforts is that IT governance is only considered a concern of the IT department This is a very dangerous assumption, since the IT department is composed of a set of people with very specialized skill sets that probably don’t represent the needs of the end users very well This is why IT governance must be managed by the entire governance team, not just the IT department

fail-Another way of thinking about IT management is in terms of a service catalog As discussed earlier, a

service is a set of features that provide certain functionalities to the users IT management is concerned with implementing and tracking those services once they are deployed Together, these services form a service catalog that must be managed

IT management is also concerned with

• Enforcing policies for access and usage

• Managing the lifecycle of content in the system

• Classifying and delivering content assets

• Backup and disaster recovery

• Implementing and maintaining security controls

• Preventing rogue installations of SharePoint

• Updating SharePoint with patches and service packs

• Controlling custom component deployment

• Mapping proposed services to the features of the SharePoint platform

• Monitoring usage and providing data to the governance team

A good way of establishing and measuring IT management is through the use of a service level agreement (SLA) An SLA is an agreement between the provider of a service and the consumer of that service In this case, the SLA is between the governance team (not the IT department) and the end users

of the portal This agreement should cover issues such as performance and reliability targets, tion policies, storage quotas, problem reporting and resolution, and chargebacks to user organizations,

customiza-if applicable

Tracking system performance against an SLA and the other policies established by the governance team will allow the organization to focus its resources where they can do the most good IT Governance will be the subject of Part II later in this book

Information Management

The Information Management segment, also known as Information Architecture, is concerned with fining how the data stored in the portal will be turned into usable information Data must be structured and relationships documented before valuable insights can be derived These structures and relation-ships must be mapped into features within SharePoint to be leveraged by users in an effective, easy-to-use way Good information management is the difference between a valuable business resource and a pile of useless data

de-CHAPTER 2 ■ SHAREPOINT GOVERNANCE OVERVIEW

When defining the structure of information in SharePoint, it is important to understand the

distinc-tion between content and metadata

Content is a fairly simple concept for most people to grasp because they can directly see it Content items are the web pages, documents, announcements, and other pieces of information that are up-

loaded to or created on the portal site

Metadata is a more difficult, and correspondingly more important, concept to master Metadata is

usually defined as data about data When a user contributes a piece of content, SharePoint automatically captures certain information about that content This includes information like who created the content and when, what name it was given, where in the site hierarchy it was placed, and so on This data is vital for SharePoint to store and deliver the content Information architecture extends this information to

include additional fields that give more context about the item This might include information such as the department the item is associated with, compliance requirements for the item, or the roles of users

to whom the information is likely to be of interest

A good example of familiar metadata is found in Microsoft Word or any of the Microsoft Office

products Word provides a large number of predefined metadata fields that can be set on the backstage

page as shown in Figure 2-3 SharePoint has the ability to use these metadata fields, as well as others, to automatically categorize and deliver information to users based on their interests and context within the site The key is to define these fields and ensure that they are populated consistently This establishes the organizational context or taxonomy of information in the site

Figure 2-3 Microsoft Word metadata

Information management is also concerned with structuring the user interface for the sites and

de-signing the site hierarchy This generally involves creating a series of high-level wireframes that define

the regions of each type of page and the site navigation that will be used to traverse the various sites

CHAPTER 2 ■ SHAREPOINT GOVERNANCE OVERVIEW

Some of the more mechanical aspects of the site also fall under the heading of information agement These include versioning of content, determining appropriate levels of access and control for various types of information, and handling other user interface issues related to the presentation of data such as branding and sites that use multiple languages These are often some of the most complex issues

man-to be managed because of the large amount of redundant information that can be created

Part III of this book will cover information management in much greater detail We will also ine managing complex information sets in SharePoint including search catalogs, social media features, and document and records management

exam-Application Management

The third and final segment of effective governance is application management An application in this case refers to any programmable components added to the SharePoint platform These components may come from Microsoft, other vendors, or software developers within your own organization Governing the deployment, use, and maintenance of these components is important because these types of components are the most likely to contain bugs or incompatibilities that can undermine the stability of the system This doesn’t mean that deploying such components is a bad thing or even par-ticularly risky It just means that extra care should be taken to ensure that changes are tested and de-ployed in a managed environment

SharePoint is designed as an extensible platform for deploying highly-scalable intranet and net portals When developing new functionality to be deployed in a SharePoint environment, it is nec-essary to understand where the application components fit within the SharePoint stack Figure 2-4 shows the design layers within a SharePoint solution Each layer is built using the features exposed by the levels beneath it

Inter-Without getting into too much technical detail at this point, the bottom layers are composed of the same components used by any web-based application on the Windows platform: the NET Framework and ASP.NET MS SharePoint 2010 Foundation is an ASP.NET application that is installed on top of this set of components The MS SharePoint 2010 Server products contain additional features that are built

on the SharePoint Foundation Additional application components are then deployed at the top layer of the stack

Figure 2-4 Application layers in SharePoint

CHAPTER 2 ■ SHAREPOINT GOVERNANCE OVERVIEW

It is not necessary to understand the deep technical issues associated with each layer in order to fectively participate in governing a SharePoint site However, it may be helpful to understand where a

ef-proposed application or enhancement fits into this stack The issues that the governance team must dress involve the policies that will be used to determine which components are appropriate for inclusion

ad-as services in a particular portal This includes limiting the tools that are allowed and the testing that is

required

There are several tools that are commonly used to develop SharePoint solutions These include

• SharePoint Designer 2010: This application is used to create content and data

structures within SharePoint It can also be used to customize business process

workflows and the user interface

• InfoPath Designer 2010: This tool is used to create intelligent forms that can be

used on the site to collect and present business information

• Visual Studio 2010: This is Microsoft’s primary software development tool With

Visual Studio, professional developers can create enhancements to SharePoint that

can be as sophisticated as needed to provide whatever functionality is required

• Microsoft Office 2010: In addition to creating documents and content for

Share-Point, some office applications, such as Excel, Access, and Visio, have their own

macro languages SharePoint also contains server-based services designed to host

applications written using these programs

Part IV of this book is devoted to Application Management This section will cover many of the nical considerations that go into protecting a SharePoint environment from unwanted instability from

tech-poorly-developed applications Standardizing procedures for developing, testing, and maintaining custom applications, as well as packaged solutions, is an important part of a complete governance strategy

The Governance Team

In the preceding sections, we used the phrase governance team several times What exactly do we mean

by this? In a larger sense, this could refer to anyone in the organization with an interest in making the

portal successful Specifically, however, we are referring to the group of people responsible for making

this success happen

Note The governance team is also sometimes called a governance committee Unfortunately, the word

com-mittee has such a negative connotation in most organizations that the term team better reflects the cooperative

nature of what you are trying to accomplish

The purpose of the governance team is to establish and maintain the policies, standards, and

re-sources needed to make the solution successful for the business over its entire lifetime It is the

govern-ance team that will identify requirements and services, evaluate feedback, and see that needed changes are implemented

An effective governance team needs to have the following:

• Representatives from each group of stakeholders with the authority to speak for

those they represent

CHAPTER 2 ■ SHAREPOINT GOVERNANCE OVERVIEW

• Enough members to adequately represent all of the stakeholders of the system,

but no more

• A stable membership Members may come and go but not so quickly that there is

no focus or long-term commitment to the effort

• A wide variety of perspectives on the business requirements and value of the

system

Figure 2-5 illustrates the major categories of members that should be represented on the governance team Each of these groups brings a different perspective and insights to the management of the system Leaving out one or more of these groups is a common and often fatal flaw in many governance plans

Figure 2-5 The governance team

Business Leadership

The governance team needs to include leaders from the various business areas to ensure that the system

is generating real business value This may mean having your CIO or CTO on the team or it may mean having a member of their staff that has been designated with the authority to speak for them Other business leadership positions that need to be represented include many of the common functional areas found in most companies These will include Human Resources, Legal and Compliance departments,

CHAPTER 2 ■ SHAREPOINT GOVERNANCE OVERVIEW

Finance, and Marketing and Sales All of these groups need to be heard if the system is going to remain

viable and be successful

Authority is the key here If the members of the governance team do not have the authority to make decisions, the team cannot accomplish anything This doesn’t mean that the team makes decisions in a vacuum It simply means that once the governance team has collected the necessary information and

considered its options, it is capable of making a decision that will be supported by all stakeholders

Business leaders help the governance team determine the best ways to make the portal pay

divi-dends to the organization in the most efficient ways They also bring the resources necessary to invest in the hardware, software, and services necessary to deploy and upgrade the system over time

It is very common to get commitment from business leaders early in the planning process, given the need they see for a solution and the expense of creating that solution Once the system is in place, it is

common for executives and other managers to lose focus on the ongoing maintenance of a SharePoint

solution The governance team needs to find ways to keep them engaged without requiring too much of everyone’s time Losing the input of these team members may lead to a loss of support from manage-

ment as the system fails to meet their expectations

IT Staff

The second major set of stakeholders is the IT department staff responsible for the day-to-day operation

of the portal The two general categories of technical staff associated with most SharePoint installations are administrators and developers

Administrators are responsible for installing and configuring the SharePoint product on the servers They monitor the system and fix problems as they occur They are usually the first line of support for end users when they experience problems As a result, administrators value stability and predictability above all else The person sleeping next to the pager has a vested interest in seeing to it that the pager does not

go off

Developers are responsible for implementing new services and maintaining existing services

De-pending on the organization and the nature of the services provided, this may include writing code, ating business process workflows, creating InfoPath forms for data entry, or creating other types of com-ponents that provide functionality to the users Applications coded to run under SharePoint are gener-

cre-ally deployed using “solution packages” and are activated as features Developers create these artifacts

and provide support and maintenance for them once they are in production

There are additional roles that IT staffers may play in governance for the portal IT Project Managers are well suited to leading and coordinating the processes of the governance team Even if a project man-ager isn’t leading the governance team, they will need to be involved in any non-trivial implementation

store logic as content We generally think of end users creating content and developers creating logic

(that is, programs) In SharePoint, there are situations where logic and content get blended together

For example, is an InfoPath form content or code? InfoPath form templates and completed forms

are stored in SharePoint libraries, just like documents, so they would seem to be content items On the

other hand, they may contain complex business rules and even NET framework code The need to test

and version form templates is also critical This would seem to suggest that they are code elements to be maintained by developers We will discuss these issues in later sections of this book, but for now, just be

CHAPTER 2 ■ SHAREPOINT GOVERNANCE OVERVIEW

aware that these types of issues will need to be addressed The only strategy that is sure to fail when erning these types of situations is not to address the issues

gov-Knowledge Workers (Users)

The final set of governance team members is easily the most important to success These are the users End users are the reason the portal exists, after all Ironically, users are the group that is most often ex-cluded from governance because they are often seen as “an IT thing.”

When selecting users for the governance team, remember that they will need to represent the ests of all of the system’s users Ideal candidates will be middle -to senior-level subject matter experts (SMEs) in the various business areas the system will serve They should be willing and able to act as user advocates within the team and mentors for users within their own part of the organization These team members will be on the front lines driving adoption of the solution and collecting feedback for the gov-ernance group to evaluate

inter-When describing users, it is helpful to categorize them by their level of familiarity with the product and the features they routinely use

The first group of users consists of casual users Casual users see the portal as nothing more than a

web site They open a web page, navigate through the site to find information and then shut their browser window down They are strictly information consumers They don’t generally have or need a detailed understanding of how information on the site is structured or maintained

The next group comprises the contributors These users contribute new information to the existing

portal site structures This may include uploading Office documents, creating events and ments, maintaining calendars, or publishing information through blogs or wikis In a well-run, highly-collaborative portal you want most of your users to be regular contributors This is the type of user that adds value to the portal year in and year out

announce-The final group of users is indispensible for a successful portal announce-These are the power users A power

user has a solid understanding of how to create and maintain content within the portal In SharePoint, power users create and customize sites, lists, and libraries They post helpful information for others and act as mentors

When looking for users to put on the governance team look for users with the skills and desire to come power users Contributors can also give useful insights when usability issues arise since their more limited understanding of the system may better reflect the average user

be-The Governance Plan

As we have discussed governance, we have frequently mentioned the need for planning All of the ous decisions made by the team should be documented in a central location This document, or set of documents, is called the Governance Plan The plan should be created early, revised continuously and referenced frequently To paraphrase an old aphorism, plan the governance and govern by the plan

vari-In Chapter 3 we will go into some detail about the ways that organizations have found to plan the governance of SharePoint For now, we will consider the general outline of the planning process and accompanying documentation

Figure 2-6 depicts the process to follow when developing and implementing your governance plan You may notice that this diagram looks very similar to Figure 2-1, which described the lifecycle of a serv-ice This is no accident A service is one of several types of items that you will apply the planning process

to As a result, its lifecycle will mirror the processes used to govern it

CHAPTER 2 ■ SHAREPOINT GOVERNANCE OVERVIEW

Figure 2-6 Planning process flow

Before you can deploy any hardware or software for your portal, you have to establish why you are

building it and what you hope to get out of this process You will gather requirements and resources for the project You need to identify and involve the stakeholders This is the project initiation phase where you begin building your governance team and strategies

Once the team is assembled and you have a good idea what you are building and why, it is time to

begin detailed planning for the initial implementation of the portal The planning phase is generally the longest initial phase of a successful SharePoint rollout In this phase, you establish the roles, responsi-

bilities, rules, and standards that will guide the implementation of the system You identify and prioritize the services that the portal must provide and begin mapping those services to the features of the Share-

Point product line or other related components

The plan you have created should be detailed enough to allow you to produce a set of procedures

and checklists that will make the initial implementation of the system, if not exactly simple, then at least smooth and predictable A difficult initial implementation is a sure sign that not enough effort was put

into planning As a result, the governance plan will tend to be incomplete Always take the time to

up-date the governance documentation with as-built information collected during the actual deployment of the system

Just as you saw with service planning, it is important to plan for change Any portal that is being

regularly used will naturally need to be updated, enhanced, or changed in some way This is a tive process that should continue for the life of the system Begin by collecting feedback from the system and the users You will use this data to find areas where the system is not meeting the needs of the users and try to improve it You may find new services that are needed or old ones that should be eliminated

construc-This effort is best viewed as a lessons-learned or continuous-improvement cycle rather than a series of

crises to be managed Always remember that changes must be planned just as vigorously as the initial

implementation was or the system will quickly become unmanageable The governance plan is a living

document that must be regularly updated in order to remain relevant

Chapter 3 will dive into the details of planning and creating the governance plan document Here

we will discuss a high-level outline for the types of information that should be included

Vision and Goals

The first decisions to be made will involve the purpose and goals of the system to be governed These are the framing decisions that will guide the rest of the governance effort Normally, these are stated as a

vision and a set of goals

The vision statement is a general statement of purpose or intent for the system The content of these vary widely from one organization to another even for very similar implementations The vision should

convey the value that the portal will bring to the users and the organization

The goals of the portal are a set of intended results to be achieved These are more specific than

the vision but are broad enough to be applied to the system as a whole In Chapter 3, we will discuss

CHAPTER 2 ■ SHAREPOINT GOVERNANCE OVERVIEW

goal-setting using the S.M.A.R.T methodology SMART goals are designed to be stated, measured, and evaluated in a concrete way

Together, the vision and goals established early in the project will provide the guiding principles on which the governance team can base its future decisions They establish a pattern of preferences that will support accomplishing the goals laid out and achieving the stated vision

Roles and Responsibilities

One of the most important items on the team’s agenda will be to establish the roles and responsibilities

of the team members

Each member brings a unique perspective and skill set that should be leveraged Each role should

be laid out in detail along with the responsibilities that accompany it In later chapters, we will describe some of the common roles and responsibilities that need to be considered in a SharePoint governance environment

Policies and Standards

Another of the governance team’s main functions is to establish policies and standards These words are sometime used interchangeably but not in this context There is an important distinction between them that must be understood and maintained

A policy is a rule that must be enforced by the system, the business, or the users It is not optional

In fact, policies are not generally created by the governance team but rather identified by them For example, protecting a list of customer credit card numbers from unauthorized access is not just a good idea, it is required under the law The Healthcare Insurance Portability and Accountability Act of 1996 (HIPAA) requires that private health information be stored and protected in certain ways The Security and Exchange Commission (SEC) requires certain documents to be retained for a given period of time SharePoint has facilities to help implement many of these controls Setting appropriate policies within your governance plan will help to protect the users and the organization from civil, criminal, or other severe penalties

A standard, on the other hand, is more flexible Standards are best practices or preferred ways of

do-ing thdo-ings While the system should encourage compliance with standards, it is recognized that there may be cases where they do not apply User interface design is an area that is often handled using stan-dards By creating page and site templates, you can encourage users to adopt a common style and struc-ture within the portal

Ongoing Maintenance and Planning

As mentioned previously, the governance plan should be a living, changing document just as the portal

is a living, changing system In this section of the plan, you establish strategies for handling that change The procedures detailed in this section are generally concerned with communicating with and elic-iting feedback from the users Here are some of the items to consider including:

• Problem Resolution Process: No matter how well planned and implemented the

system is there will always be issues that come up A low-stress means of ing, fixing, and communicating these issues will help the users feel that their con-cerns are being addressed

report-• Content and Functionality Requests: Users need a way to request new sites, access

existing sites, or enable new functionality This process often goes hand in hand with problem resolution, but it may take other forms as well

CHAPTER 2 ■ SHAREPOINT GOVERNANCE OVERVIEW

• Communication and Adoption Plan: This plan sets out how users will be educated

and trained in the use of the portal Without an appropriate adoption plan, most

portals will fail to become an integral part of the business

• Governance Plan Updates: This plan describes the process that will be used to

change the plan This includes new services, standards, policies, and anything else

covered by the plan

• Upgrades and Enhancements: This section details the strategies to be used in

updating the system hardware and software including custom and third-party

components

Common Pitfalls in Governance

We have discussed a number of good governance practices and we will discuss many more throughout

this book Let’s take a moment to understand the types of problems to avoid through good governance The Goldilocks Approach

At the beginning of this chapter, we described the Goldilocks approach to governance: not too little, not too much As you move forward you need to remember that the users of the system are real people who value their freedom and their contributions to the organization

Each organization has its own culture and sometimes multiple cultures Seek to understand the ture of your organization and fit your governance practices to the culture Do not expect users to do

cul-things your way just because you control the system they use to do their jobs Their attitudes and habits have been formed over long periods of time and will not change overnight

When trying to determine the level of governance to use, remember that productivity and business value are the goals, not centralized control Give users as much freedom as is consistent with the needs

of the organization, but not more

Engaging Users

SharePoint is a user-friendly product in most situations, but it can seem complicated to new users In

our experience, a new SharePoint portal that is deployed without a sufficient user adoption plan results

in one of two situations: users either love the system to death or they hate it

For example, early reports out of Microsoft indicated that when SharePoint was first deployed nally, most employees loved the ability to create their own content and sites This is not surprising, since Microsoft employs so many engineers and IT professionals Within a few weeks there were tens of thou-sands of sites and no way of finding anything As a result, the system probably became unstable and dif-ficult to use The users loved it to death

inter-Other implementations have gone the other way Giving a portal application to a large group of technical users and giving them the order to “use it!” is not effective in most cases Users can sometimes

non-“use” SharePoint for months but have no clue as to the full power at their disposal This is both good and bad It is good because the system was easy enough to use that they didn’t need in-depth knowledge It

is bad because there is no way for the business to fully leverage the investment that has been made

Frustration is often the outcome of this situation Users feel that the system should be easy to use but it

is not because they don’t understand the basics

As mentioned several times before, users are the reason the portal exists The governance team

must find ways to engage the users There are many ways to do this and we will discuss some of them in later chapters The most important strategy is to create a user adoption plan that lays out how the sys-

tem will be promoted and the types of training that will be provided for end users

CHAPTER 2 ■ SHAREPOINT GOVERNANCE OVERVIEW

Roles and Responsibilities

One of the key goals of the governance process is to establish roles and responsibilities for everyone volved in the solution Failure to clearly define these can cause the system to rapidly degrade

in-Unclear lines of responsibility can result in political fights and finger pointing within the tion SharePoint has features for delegating authority and responsibility for different parts of the site to different groups of users Failing to use these correctly can cause a lot of confusion

organiza-Another common problem comes down from management A SharePoint portal is never a “fire and forget” project Management must buy in to the idea that this is a product that will be maintained and upgraded continuously throughout its lifetime

Implementation

The last category of common pitfalls that befall many SharePoint installations are problems of mentation This refers to all of the processes that go into creating and delivering a solution to the users Insufficient hardware infrastructure is a very common cause of problems SharePoint is designed to

imple-be highly scalable The product can run on a single server up to a farm containing dozens of servers pacity planning is vital to getting in front of the demand users are placing on the system The lead time generally needed to provision new servers and storage assets can be lengthy, so predicting hardware requirements ahead of time will help to keep users happy with the portal’s performance

Ca-Redundancy is also of critical importance The ability to keep running after hardware failures, cover lost data, and perform disaster recovery are the difference between a reliable system and an ap-proaching catastrophe

re-Insufficient IT staffing is also all too common when running SharePoint As the users become more comfortable with the portal, they will place greater demands on the IT staff to support and upgrade the servers and deploy new services

SharePoint is an extensive family of products that provide a vast array of functionalities Often, SharePoint is deployed with all of the bells and whistles turned on for users This leads to unsupportable areas of functionality and frustrated users This is why service planning is so important By planning and deploying only those services we are prepared to support we can eliminate the need to fix problems caused by overenthusiastic users who have “discovered” services on their own

When looking to add services that aren’t directly supported by the SharePoint platform, avoid venting the wheel There are many good third-party products that enhance SharePoint’s standard fea-tures Before performing large-scale customizations, check out Microsoft partners for workflow, image management, data archiving, backup/recovery, disaster recovery, and other features There are also many good web sites (such as SourceForge, CodePlex, and the like) where prebuilt customization can be downloaded, often for free Last, if development is not your organization’s core competency, outsource it

rein-Summary

In this chapter, we have

• Introduced the concepts of SharePoint governance including segments and services

• Learned to identify services in a SharePoint environment

• Discussed the importance of establishing roles and responsibilities within the

governance team

• Described the segments of IT and information and application management

• Introduced the ideas for creating the governance plan and governance team

• Examined a set of common pitfalls experienced in SharePoint installations where

governance is not handled appropriately

the governance team Do you establish your vision, goals, and scope before building the team or as part

of forming the team? Questions like these can best be answered by considering the culture of your nization Don’t assume that the process outlined in this chapter is the only process that can work

orga-What Will You Learn in This Chapter?

• How to get started with SharePoint Governance

• How to establish the portal’s vision and scope

• How to build an effective governance committee

• When to begin the process of communicating with the rest of the organization

• How to structure the governance team’s outputs into policies, standards, and

procedures

• How to document these procedures so that they can benefit the users going

forward

• How to create feedback mechanisms that will enable the end-user community to

provide ideas for improving the site and its governance

Getting Started

So your organization has decided to deploy a SharePoint-based solution You are looking at hardware,

software licenses, networking, and all of the other technical details that go into deploying SharePoint At this moment, there are many non-technical issues that you should be considering, but they are probably not at the forefront of your mind, perhaps because they seem obvious or they appear to be someone

else’s concern These include

• Who is the executive sponsor for this project? This is another way of saying “Who

is paying for this?”

• What are you trying to accomplish?

CHAPTER 3 ■ GOVERNANCE PLANNING

• How will you maintain the system once it is in place?

• How will you make sure the system provides the services the business needs? How

will you be able to tell if it is not providing value?

These questions all lead to the need for governance Unfortunately, answering them won’t get the system up and running any faster, and failing to answer them won’t prevent the system from going into production This is why so many sites are deployed without an established governance plan and, conse-quently, why so many fail In a way, SharePoint’s relatively inexpensive startup costs and easy setup are major contributors to this problem No business would consider implementing a multimillion-dollar data center without a very clear idea of what it will be used for and how it will be managed

Ideally, the executive sponsor should be the person initiating the governance of the system This is the person who is providing the funding for the project and has the authority to control the require-ments to be met The sponsor therefore has a vested interest in seeing that the system is well-managed and returns value to the company Often it is an IT manager who is tasked with creating the SharePoint environment by someone else in the business In that case, they should immediately identify the execu-tive sponsor and engage them in the governance effort Without the sponsor’s involvement, effective governance will not be possible since there will be no authority behind it

The next task is to establish the site’s vision This is a statement that describes why the site is being created and what value it is expected to return to the organization There are many references available for writing good vision statements and many ways to write them Here are a few suggestions to keep

in mind:

• The statement should be written as though the system already exists and has

achieved all the goals set for it

• The statement should be one or, at most, two sentences

• The vision should be general enough to cover the entire purpose of the system but

specific enough to guide later decisions regarding its implementation

• The statement should describe the portal’s role within the organization and the

value it is intended to provide

The vision statement will be different for an intranet, an extranet, or an Internet site It will vary pending on the reach of the portal across departments, divisions, or the entire company The vision should reflect the most important features that will provide value to the company without dwelling on the obvious A vision statement describes what the site aspires to achieve on behalf of the business

de-In addition to the vision statement, this may be good time to consider creating a mission statement The mission statement is similar to the vision statement in that it helps guide future decision-making

The difference is that a mission statement describes what the system is going to do, whereas a vision statement is about what the system is going to be It may also be more appropriate to consider the mis-

sion statement right after the governance team is established

Once the vision and the mission are defined, you need to understand the scope of the governance effort This goes hand in hand with the scope of the system to be governed For example, if the site will serve as the intranet for one division within the company, the governance effort will focus on the needs

of that division The scope allows you to say what is and is not relevant to the project, allowing you to focus on what is most important

Start Communicating

Communication between the governance team and the rest of the organization is the key to a successful portal At this point in the formation process it is a good idea to begin opening the lines of communica-tion Formal communication and education plans will come later but, for now, just get the word out

CHAPTER 3 ■ GOVERNANCE PLANNING

• Ask for volunteers for the governance team

• Ask for proposed content and functional requirements

• Ask for any and all ideas that might add value to the portal being developed or the

governance effort around it

Establishing a Governance Committee

Now that you understand what you are, and are not, trying to accomplish, you need to bring together a

group to lead the governance effort This group will be the governance committee Do not let the word

committee get in the way If your organization’s culture views committees as bad things, call it

some-thing else Some common alternatives are steering committee, leadership team, center of excellence and

so on Whatever its name, this group will set the policies and standards that make the system work

Identify Stakeholders

In Chapter 2, we considered the types of people that should make up the governance team These include

IT, business, and management leaders Specifically, you need to determine who the system’s stakeholders are These are the people and departments with a vested interest in seeing the project succeed

In searching for the system’s stakeholders, consider these questions:

• Who is paying for the system?

• Who is accountable for the success or failure of the system?

• Who will be using the system?

• Who will be impacted if the system does not meet the business’s needs?

• Who will spend time implementing or maintaining the system?

• Who will be responsible for defining the information architecture of the system?

• Who will provide and consume the content of the system?

It is unlikely that all of the stakeholders will be able to commit the time necessary to actively pate in the governance effort Instead, each area should appoint one or more representatives to partici-

partici-pate These representatives should have the experience and authority to make binding decisions for

their respective groups

These team members will become mentors for users and advocates for the system within their part

of the organization Be sure that anyone to be included in the governance team is committed, both in

time and interest, to the effort

They should also be rewarded and recognized for their contributions Participating in this type of

activity can be very time consuming when it is done well It is important that this time be factored into

their overall workload and career plan Asking anyone to perform this type of work over and above their normal 40-hour-a-week job will inevitably turn this into a low priority task for them

Set the Objectives for Governance

Like any project, the governance of a SharePoint portal needs to have a set of well-defined goals or

ob-jectives Just as with vision statements, there are many ideas about how to set goals One of the most

common approaches is to use the S.M.A.R.T approach:

CHAPTER 3 ■ GOVERNANCE PLANNING

• Specific: Objectives should specify exactly what is to be accomplished

• Measurable: Objectives should be quantifiable and concrete so that progress,

suc-cess, and failure can be judged objectively

• Attainable: Objectives should never be set in such a way that they cannot be fully

achieved Setting a goal that is hard to reach is good Setting a goal that is out of reach is pointless

• Relevant: Objectives should always contribute to the achievement of the mission

and vision of the project

• Time-bound: Objectives should come with an expiration date An open-ended

ob-jective is of little use since it never actually has to be met

When setting goals for a SharePoint portal project try to remember why the project is being taken The objectives should move the organization closer to the achievement of the vision while provid-ing a measuring stick for gauging that progress

under-Objectives for the governance of a portal often map to the value to be provided to the business These may include things like reducing the total cost of ownership (TCO) for the system and establishing standards and policies for the organization As we discuss in Chapter 4, these objectives are met by de-fining and implementing services within the portal for business users

Another consideration when establishing goals for governance is creating a balance between bility and control As emphasized in Chapter 2, good governance requires a balanced approach Too little control can cause a lack of focus and a waste of time and resources Too much control can stifle innovation and cause the system to fall into disuse One of the objectives of the governance effort should

flexi-be to strike this balance effectively

Assign Roles and Responsibilities

One of the primary purposes of governance is to ensure that everyone involved understands what is pected of each member of the team This process begins by establishing the roles of each person or de-partment and then assigning responsibilities to those roles Table 3-1 describes some common roles associated with SharePoint governance

ex-Table 3-1 Common Governance Roles

Role Description

Executive Sponsor This project “champion” is usually associated with the part of the business

providing the resources for the project

Project Manager This person drives the project forward and is often in charge of facilitating

meetings, ensuring deadlines are met and communicating with the tion on behalf of the team

organiza-Business Owner This is usually a manager or senior staff member from one of the business

units that make use of the system Business owners help to establish the quirements for the system and provide a channel for user feedback

re-User Mentor (Coach) The mentor or coach is committed to helping users get the most out of the

system and may perform formal or informal training, write blog posts, swer questions, or do other forms of mentoring as needed

an-CHAPTER 3 ■ GOVERNANCE PLANNING

Power User This person is proficient with the design and implementation of new content

within the portal and may or may not be technical, depending on the type of content they help to author

IT Manager IT Managers provide direction to the administrators and developers

associ-ated with the system

Application Developer Application developers create new customized functionality for the portal

This may include new Web Parts, workflows, InfoPath forms, etc Developers perform highly technical customizations beyond the scope of power users

System Administrator System Administrators install, monitor, and update the servers associated

with the portal

Support Support resources are available to answer questions and solve problems

when they are reported by end users

Information Architect This person helps the business owners define the metadata, workflows, site

structures and other components that control the organization of information

in the portal

Web Designer This person helps to establish the look and feel of the site in conjunction with

the Information Architect and also assists the developers and power users to implement the web site design

Site Owner Each SharePoint site has one or more owners who control access to the site

Site Designer The site designer controls the creation of lists, libraries, and other content

within the site Often, the site owner and site designer are the same person

Site Contributor A site contributor adds new or updated content to the site

Defining responsibilities for the preceding roles may be as simple as creating the list and assigning the responsibilities for each role It is often the case that while one role may be responsible for a task,

other roles are also involved A convenient way to record these interdependencies is to use a RACI chart RACI defines the contribution of each role to a task as either:

• Responsible: This is the role primarily responsible for accomplishing the task

• Accountable: This is the person to whom the responsible person is accountable

This is also sometimes called Approver or Authority

• Contributor: This is one or more additional roles that are involved in the

comple-tion of the task, sometimes called Consulted

• Informed: These are the roles that have an interest in the task and must be kept

in-formed as to its status They do not have any authority over or make any

contribu-tion to completing the task

CHAPTER 3 ■ GOVERNANCE PLANNING

There are numerous variations on the definitions of these terms, but the general idea is the same A

common way to document these tasks and responsibilities is to use a table (Table 3-2) that has tasks

listed down the left column and roles listed across the top row Each cell in the table reflects the

respon-sibility of that role with respect to the task

Table 3-2 Sample RACI Chart

Task Executive Sponsor Project Manager IT Manager App Developer System Admin

New Feature Development

As your governance effort begins, the list of tasks will be fairly short As your system grows and

is-sues arise, the list can be expanded as needed to ensure that everyone is comfortable with the roles of

all involved

Develop Governance Planning Documents

The governance team’s purpose is to set standards and policies and communicate them to the rest of the organization To do this, some documentation will be necessary In this section, we will describe com-

mon features and layouts for this documentation Of course, the needs of your organization will require

variations to the document set described here This discussion should be viewed only as a starting point

Common Document Features

Before getting into the details of the documents, let’s look at some best practices

• Revisions: Each document should include a revision history that allows readers

to know what parts of the document have been updated from one version to the next This alleviates the need to reread the entire document each time a version

is released

• Publishing: Each document should be posted in a known location on a regular

basis This allows the documents to be found quickly and easily when needed

• Feedback: Each document should explicitly request feedback and explain how to

provide feedback to the author This can be an online form, e-mail address, and so forth These are living documents designed to help readers, not encumber them

CHAPTER 3 ■ GOVERNANCE PLANNING

• Sign-offs: Documents should be published only after they are officially approved

by the governance team This is not to say that drafts should not be circulated

They definitely should! But users must be able to find the official documents

when needed

The purpose of these documents is not to get in the way of productivity They are meant to be read and understood to help everyone in the organization get the most out of the governance process and the portal Never fill these documents with boilerplate text that adds no value for the reader Try to make

these documents long on detail and short on description Lists, tables, and figures can often be used to

provide the same, or better, understanding of a topic than large amounts of text These documents

should be as long as they need to be, but no longer

The Governance Plan

The most important document created by the governance team will be the governance plan This plan

will document the decisions made by the governance team in a way that allows them to be easily

refer-enced and used by the team and others affected by those decisions

Here is one possible outline for a governance plan:

• Responsibility (RACI) Matrices

• Content Policies and Standards

• Uptime and Performance Goals

• Outage Planning Procedures

• Support Requirements and Schedules

CHAPTER 3 ■ GOVERNANCE PLANNING

• Customization Policies and Standards

portal and governance effort For example, these decisions may include items such as the following:

• Publishing will be preferred in sites at the department level and above

• The use of My Sites, personalization, and social media will be supported and

en-couraged throughout the portal

• Copyrighted material will be stored only in specially designated sites

• No customer personal information will be stored within the portal

• Versioning will be used whenever practical

• Large media files will be stored outside of the portal but accessible within the

por-tal using Remote BLOB Storage (RBS)

The preceding decisions may be technical in nature when necessary, but more often they will be lated to business requirements such as compliance and security considerations These will be among the first decisions made by the governance team They will shape all of the decisions made later These prin-ciples should be chosen to help drive the group toward fulfilling the group’s vision and mission

re-Roles and Responsibilities will document the roles as described earlier in this chapter Additionally,

this section will grow to contain additional tasks and the responsible roles for those tasks The ment of individuals to roles can be included in this document or referenced in another location (such as

assign-a Shassign-arePoint list!)

Content Policies and Standards cover the creation and management of content within the

Share-Point sites in the portal The items in this section are described in detail in Part 2 of this book

Technical Policies and Standards cover the management of the servers that support the portal

These are the IT Management questions covered in Part 3 of this book

Customization Policies and Standards provide guidance on the creation of content or logic that is

not native to SharePoint This may include user interface elements such as page layouts and themes or user-defined logic such as workflows, InfoPath forms, or solution packages These techniques are de-scribed in Part 4

General Procedures are those processes that allow users to get things done This is typically a list of

“How-To” articles Each article describes how to access help and resources provided by the portal and the governance team This is basically a high-level frequently asked questions (FAQ) list for the users These procedures may also be posted directly on the portal to make them easier to find Some examples

of these procedures include

CHAPTER 3 ■ GOVERNANCE PLANNING

• How to get support

• How to find training materials

• How to provide feedback to governance committee

• How to request a new site or site/content access

• How to report a problem or request a new feature

• How to request new site collections

Your organization will determine its own needs for the contents of the governance plan More ideas for the governance plan can be found in Appendix B of this book Appendix C contains a set of helpful

checklists that can be used to establish and organize your governance plan

Additional Planning Documents

When creating the governance plan it is often useful to create a set of subordinate plans to support it,

similar to Table 3-3 Each plan is still part of the governance process but is often maintained by one

de-partment or set of individuals because of their limited audience

Table 3-3 Additional Common Governance Roles

Plan Description

User Communication

and Training Plan

This plan will describe the techniques to be used to communicate with the end-user community This will include maintenance and support schedules and procedures It will also include resources for user training to help users get the most out of the system See Chapter 5 for more details

Operations Plan This plan will describe how the system will be monitored, updated, and

pro-tected This should include backup and restoration plans, disaster recovery, usage and performance monitoring, bug and issue tracking, etc The opera-tions plan is described in more detail in Chapter 8

Application Lifecycle

Management Plan

This plan will describe the processes to be used to create customized tions for the portal It will detail items such as source code control, sandbox solution policies, release scheduling, etc These processes will apply only to customizations that are centrally created and deployed Policies for end-user customization should remain in the main governance plan document Appli-cation Lifecycle Management (ALM) and application management in general are described in Part 4 of this book

solu-Closing the Loop

With the governance team assembled and the initial documents and processes established, it is time to move into action As the project moves forward you will want to perform regular reviews, collect user

feedback, monitor feature usage data, and track bugs and issues As a team, the governance committee

should look at all of this information and plan future services and upgrades

CHAPTER 3 ■ GOVERNANCE PLANNING

In Chapter 4, we discuss the process of designing and managing services in the portal Keep in mind the service lifecycle described in Chapter 2 and shown in Figure 3-1

Figure 3-1 The lifecycle of a service

Summary

In this chapter, we have

• Described the process of getting started with SharePoint Governance

• Discussed how to establish the vision and scope for your SharePoint site and the

governance effort that supports it

• Looked at the process of establishing a governance committee

• Considered the need for early and effective communication with the rest of the

organization

• Described the governance policies and standards documents that need to be

created

• Explored the types of feedback mechanisms that can be used to enable the site’s

users to provide ideas for improving the site and its governance

What Will You Learn in This Chapter?

• Why portal functionality should be divided into manageable services

• How to identify and categorize services for governance

• How to prioritize the services for implementation in the portal

• How to plan the implementation of a service

• How to plan for the monitoring of a service after deployment

• How to plan for the maintenance and upgrades associated with a service

• How to plan for the eventual decommissioning of a service

• How to divide and conquer services

Let’s take a moment to review the concept of services introduced in Chapter 2 A service is a discrete

set of features that the portal provides to the community of end users By aggregating the features of the system into services, you divide the governance of the system into manageable pieces

■ Note Remember that in a governance context a service is a conceptual collection of features SharePoint

con-tains many subsystems that are also called services, such as Excel Services or PerformancePoint Services Point services may or may not map directly to governance services A governance service may contain one or

Share-more SharePoint services, or none, along with other features that are not part of any SharePoint service The ices described in this chapter are governance services unless explicitly noted otherwise

serv-CHAPTER 4 ■ IMPLEMENTING SERVICES

Recall that a service always has a lifecycle (Figure 4-1) Start by identifying and planning for ance of the service Then the service is implemented and released to the user community The govern-ance plan will include monitoring the usage and performance of the service You then collect feedback from the users to plan future upgrades and changes to the service

govern-Figure 4-1 The lifecycle of a service

Try not to think of service planning as a one-time effort The governance team will be involved in monitoring and reevaluating each service continually over time This allows the system to grow and evolve as needed without becoming clogged with unused or unusable services that no longer provide the value they should

Identifying Services

The services to be implemented in a SharePoint portal will fall into one of three categories The first and most common type of service is inherent in the SharePoint product line, such as Publishing or Perfor-mancePoint Services (We will discuss some of these later in this chapter.)

A service can also be built around a third-party product that provides features on top of SharePoint Common examples of this are data archiving, workflow, and image/document management systems These products require separate licensing and configuration beyond that of the SharePoint server itself When implementing this type of service, be sure to evaluate the vendor’s upgrade practices If the ven-dor publishes patches and interim versions (point releases) between major releases, these release schedules will need to be integrated with the portal’s maintenance schedule Some commercial add-ons also require special hardware such as storage or networking infrastructure

A third source of services may be your own Information Technology (IT) department Custom-built applications built on SharePoint can provide an excellent return on investment because they can pro-vide value to the business that cannot be achieved in other ways A custom solution might be as simple

as automating a business process using a set of InfoPath forms and workflows It could also involve nificant NET Framework programming to implement new Web Parts, event handlers, workflow activi-ties, or background processes (timer jobs)

sig-Other sources of solutions for SharePoint are open- or shared-source sites such as CodePlex.com CodePlex is sponsored by Microsoft and, as of November 2011, contains almost 1,700 open source pro-jects for SharePoint These projects include Web Parts, best practices, site templates, management and administration tools, and so on These projects are provided on an “as is” basis and are not supported by any vendor Therefore, from a governance point of view, these should be treated in the same way as in-ternally created custom solutions The advantage to using open source solutions is that much of the work is already done

The other way to categorize services in SharePoint is as mandatory or optional Mandatory services

are those that must be present at all times in order for the system to function We will describe some of

CHAPTER 4 ■ IMPLEMENTING SERVICES

these later in this chapter Note that the mandatory services described are required for technical

rea-sons Your organization may have regulatory or compliance needs that will require some otherwise

op-tional services to be made mandatory For example, a portal that is hosting corporate records subject to Sarbanes-Oxley regulations may require SharePoint’s records management features to be available

Optional services are those that are deployed because they provide value to the organization Some

services will depend on other services in order to function properly For example, to use SharePoint’s

automated content deployment mechanism, you must also be using the Publishing features While it

may be tempting to lump a group of interdependent features into a single service, remember that the

goal is to simplify governance of each service Combining features with different audiences,

require-ments, and monitoring capabilities into a single service will make that service more difficult to manage

Establish Mandatory Services

In this section, we will describe the most important mandatory services that the governance team needs

to be aware of These services should be evaluated and planned before any servers are installed

Infrastructural Services

The infrastructural services form the foundation for the rest of the system

Hardware Infrastructure

When planning the hardware for a SharePoint environment, the governance team in conjunction with IT

will need to perform capacity planning Capacity planning involves creating a profile of how the system

will be used and the level of performance to be expected Much of this information may be laid out in a

Service Level Agreement (SLA) between the governance team and the user community

When developing the hardware plan for a portal, consider the following:

• User load: How many users will be using the system at one time? Which services

will be most heavily used?

• Storage volume: How much data will be stored in the portal, including old versions

and all types of documents?

• Storage type: Will all content be stored on a single SQL Server, Network Attached

Storage (NAS), or a Storage Area Network (SAN)? Will any data be accessed using

SQL Server’s Remote BLOB Service (RBS)?

• Network bandwidth: How much data will be sent and received by the portal?

• Network routing: Will a network load balancing appliance be needed? What about

new firewall settings?

• Server tiers: All SharePoint portals require one or more web servers and one or

more database servers Does your portal need separate search query and indexing

servers? What about other application tier services such as Excel Services, Access

Services, or PerformancePoint Services? These services can be hosted on the

front-end web servers, but this can cause performance to degrade for front-end users

Even the best capacity plan is never perfect As time passes, content tends to become larger If your portal is successful, the addition of new services and more active users will increase load on the servers When the farm is initially deployed, collect a set of performance and usage metrics These will form

a baseline that can be used for comparison later As the system’s load and storage size increase, these