You cannot assume that users will know where their information should be hosted in your SharePoint environment. Without communicating a corporate-wide set of expectations about where information goes in SharePoint, users will be left to make the decision on their own and you’ll find that each one will have a different idea as to where their own information should reside. For example, should customer project collaboration information go under the Customers site or the Projects site? Should new product information go under the Research or the Products site? Should extranet information be shared with internal users or not? These examples illustrate that users will not have clear choices about where their information should reside. Placing this burden on them to make such decisions, especially in the absence of any deployment-wide information architecture, is a bit unfair to the average user.

If your organization can’t bring itself to make core governance decisions like this, then conflict is bound to erupt based on the lack of direction for your SharePoint deployment. Because users will decide where their information goes, they will necessarily end up negotiating where they will collaborate within SharePoint. Turf wars will likely happen with organic coalitions that form out of conflict and compromise. Users will spend cycles and energy resolving differences when their focus should be on collaboration and decisions.

Someone in your organization needs to make some high-level decisions about where information will go and who will manage it. These decisions need to be communicated and then enforced if you plan on avoiding conflict surrounding where information goes in SharePoint.

In most organizations, there are different kinds of information with different security levels. For example, payroll information is often highly secured, whereas public Web site information is generally less secured.

When users are developing information within SharePoint, they cannot be assumed to know how their information should be managed. For many, the prospect of managing and securing their information is a new task; in the absence of direction, they’re bound to violate some unwritten rule or expectation. Best practice is to have an organization-wide information architecture from which document-type definitions can be described and then implemented in SharePoint.

For example, how should the site administrator that hosts the organization’s payroll file manage that file? To whom should the administrator give permissions to that file? How should the research and development team manage new research information? What security level should be given to this information? How should it be described? When does information in your organization become legally compliant and publicly available?

These types of questions relate to how information is managed. In the absence of clear governance for how information should be handled, conflict will likely occur and some information security policies might be violated. Best practice is to map out your information types and then communicate how these types should be managed within SharePoint.

Tradeoff: Mitigating Conflict Through Governance Planning and SharePoint Design

We routinely work with customers who have been charged with replacing their file servers with their SharePoint Server 2007 implementation. There are a number of problems with this approach, not the least of which is that such a mandate inherently places several groups in the company in a position where conflict is likely to erupt.

For example, consider the tasks that will need to be performed in order to undergo a bulk migration of documents from a file server to a SharePoint Server 2007 platform, illustrated in Figure 2-1.

Figure 2-1. Process flow of the tasks necessary to import documents into SharePoint Server 2007

In order for the documents to be findable, they need to be accurately described with global keywords that are pre-defined for the organization. These keywords need to be highly discriminating and communicated to the users so that the users can use them to quickly and easily find the documents. Simply uploading hordes of documents into SharePoint will not make those documents more findable, especially if hundreds of thousands or millions of documents are uploaded into many different libraries.

This process also involves several groups of people and requires them to work together in ways that they never have before. The opportunities for conflict are obvious. The groups are as follows:

• Librarians need to create global keywords and metadata fields, mapping them to content types and then mapping those content types to sites and libraries.

• Developers may need to create the content types into features and have them deployed either through STSADM or through solution deployments so that end-users need not be tasked with manually creating content types that are shared across many site collections.

• Farm administrators and power users will need to create a plethora of site collections, sites, and libraries with a predetermined set of site and library names that will be both intuitive to the end-users and compliant for the SharePoint farm deployment.

• Site owners will add the content types to the libraries.

• IT team members and/or power users will need to populate the libraries with the documents. Using third-party tools, metadata can be applied at the time the documents are checked in to the library.

• Farm administrators ensure the documents are indexed.

• Trainers will need to train end-users on the keyword meanings and how to use them to find the documents they need to find.

• Users need to be informed about the unique metadata field names that should not be used as site column headings or in new metadata field names for new content types.

• Users use the keywords to query and find the documents.

As you increase the number of documents in SharePoint, you’ll find that the same words will be used for very different meanings, rendering a syntactically correct result set increasingly irrelevant. Keyword searches on content cannot help a user express meaning in a keyword search. And getting all of these groups on the same page regarding the meaning of keywords and metadata fields that are attached to documents can be the source of conflict. The conflict can be avoided by regularly communicating project goals and keyword meanings and by ensuring that key stakeholders are informed of the process and are in agreement with ongoing decisions as the project moves forward.

The tradeoff decision is to invest resources into laying out the information architecture groundwork upfront versus just moving the documents into SharePoint Server 2007 and hoping that by indexing their content, the documents will be findable enough and that you will have avoided conflict altogether between these groups.

At the core of your governance plan is the need to decide who can make decisions within your SharePoint implementation. A myriad of configuration settings are available for manipulation at four basic levels: farm, Web application, site collection, and site. Generally speaking, SharePoint farm administrators will manage the options at the farm and Web application levels, whereas power users with advanced training will manage the options at the site collection level. Nearly everyone in your organization who is involved with content creation or management will manage configuration values at the site level.

Your governance plan needs to specify which people and positions will be able to make decisions and commit changes at each of these four levels. Planning this out before you deploy SharePoint Server 2007 is the optimal method of ensuring success for your SharePoint deployment.

By default, site administrators and site collection administrators have broad powers to make decisions and affect configuration changes within their scope of influence. The breadth and depth of influence is often not fully understood, but a quick look at the administrative options in Site Settings tells the story better than nearly any other method we can think of. Consider Figure 2-2, which illustrates the options that are available to a site administrator for a team site template with the publishing features activated. Take a moment and look at all of the configuration, security, and customization options that are under the purview and authority of the site administrator.

Figure 2-2. Site Settings page for a default team site

Site owners can do things like create content types, enable and disable features, set permission levels for users and groups, and create e-mail–enabled lists and distribution groups (assuming this feature is enabled at the farm level) without ever having to loop in a System Administrator. Site administrators can break permission inheritance from parent sites and can customize the navigation for their site. Site administrators have significant authority and ability to pervasively manage their sites. Unless their configuration abilities are explicitly allowed or denied by a governance plan, it is highly likely that some might engage in administrative activities that you might not want them performing. This will cause conflict that is difficult to resolve because the conflict occurs within a scenario that lacks overall direction.

Figure 2-3 illustrates the additional responsibilities of the site collection administrator in a site collection with the publishing features turned on. What is important to note here is that once My Sites are opened to the end-users, when they create their My Site, they become both a site administrator and a site collection administrator. The My Site site collection administration matrix is somewhat different than that which is illustrated in Figure 2-3.

Figure 2-3. Site Collection Administration Settings

By default, site collection administrators can create and configure the search scopes that appear in the search Web parts, keywords and best bets, and language variations as well as turning on and off features that have been applied at the site collection level. Site collection administrators have access to all content stored within their site collection and can manage permissions throughout the collection. In addition, site collection administrators can implement collection-wide auditing, work with the Recycle Bin, rearrange the hierarchy of sites (when the publishing features are turned on), and configure the cache properties.

Both Figure 2-2 and Figure 2-3 point to the strong need to thoroughly train your users on the proper administration and maintenance of a site and/or site collection in your environment. Best practice is to not allow your users to use the SharePoint technology without first receiving training on the proper methods of use and administration of a SharePoint site.

In addition, because site collection administrators have both pervasive and robust administrative capabilities, it is imperative that the organization either explicitly support their role or state where they want the site collection administrative activities reserved for the IT staff or the SharePoint farm administrators.