SharePoint Governance, Part 1
Robert Bogue
11/27/2006
Printer Friendly Version
Microsoft SharePoint technologies offer an immense amount of power for an organization, and harnessing this power is the goal of every business that installs SharePoint.
But adoption of the SharePoint technologies can get out of control without proper governance. In this two-part article you'll learn what governance is and learn about some
of items that you should consider for a SharePoint technologies governance plan.
Before delving into the details of the specifics of SharePoint governance, it's important to clarify meaning and to understand an overall approach to governance that works well for organizations of all sizes.
Governance is defined as "a method or system of government of management" (Dictionary.com). It is also defined in part on Wikipedia.org as "… focused on information technology systems and their performance and risk management." Governance is managing the deployment of information technologies. Managing, like project management, is concerned with the risks, the costs, and the usefulness of the solution once it has been created. Thus when we define governance we are attempting to manage risk, cost, and adoption.
We must strike a balance between these goals, seeking to find a manageable path which is neither overly loose nor overly tight. We can not exercise no governance and have broad adoption without manageability nor can we exercise heavy governance which eliminates adoption.
Now that we understand the purpose of governance it's time to review categories that may be important in your SharePoint governance. They are:
Project and Operational Management
Development and Configuration
Infrastructure
Operational Concerns
Education and Training
Navigation, Taxonomy, and Search
The following sections drill into the details of each area and describe the specific items that you may want to include in your governance plan. Each section contains a table which indicates a name of a general grouping for the activities and decisions, the specific actions ("What to do") and the reasoning behind the actions ("Why to do it"). The objective here is to provide you with both a practical guide for creating your governance plan as well as to enlighten you on the background for the items so that you can identify additional, organizationally unique, items that should be a part of your governance plan.
Project and Operational Management
Project and operational management encompasses traditional project management concerns as well as those concerns which may be more formally described as operational management - as they refer to the ongoing management of the platform and not to the project management associated with the initial construction. In this section we are concerned with the initial construction and those operational items which need early decisions to promote consistency.
| Project and Operational Management |
| Item |
What To Do |
Why To Do It |
| Communication |
Establish a communications plan that includes:
1. Who will do the communications
2. When the communications will occur
3. What each communication will contain
4. How each communication will come (i.e. email, hard copy document, newsletter, etc.)
Create central points of contact for those who are not directly involved in the governance.
|
Establishing an expectation as to what communications will happen will help users understand how to contact the project team and what they can expect the communications pattern to be. This improves the perceived openness of the process and facilitates adoption |
| Deployment Process |
Define a process which will be used for in-house developed and third party software to be deployed to SharePoint platform or platforms.
|
Defining the deployment process creates a clear understanding for development teams on what to expect if their software is to be installed on the platform. This eliminates last minute problems during deployment and reduces the number of variations thus reducing management costs.
|
| Change Management Process |
Define how changes will be tracked, cataloged, and approved
Decide what repositories will hold older versions of configuration, code, and compiled components of the solution |
Maintaining a high availability is essential to adoption. Solid change (configuration) management processes create better availability. Consistency in approach, approvers, and responsibilities encourage ownership and better stability. |
| Cost Allocation |
Decide whether you will be allocating costs back to business units or not
If not - Consider where the costs should be centered, often this is with costs associated with email.
If so - Consider what metrics you'll use for the charge back: users: number of sites, amount of storage, amount of activity, etc.
|
SharePoint governance in general, and SharePoint technology platforms in particular cost money. Governance in most cases implies a centralized platform. Finding the funding to pay for the centralized platform is an essential and sometimes difficult task. |
| Sponsorship |
Establish a SharePoint Governance board to review adoption and controls.
Solicit executive champions to create the right management attention to the value of the initiative.
Encourage business evangelists to share the power of SharePoint with other business leaders. |
SharePoint technologies have the potential to radically redefine the way software is developed and projects are run - for the better. However, if the management team doesn't understand this and the users don't feel excited about the possibilities that SharePoint brings then the prospects for success are not bright. |
| Roles and Teams |
Define clear roles and responsibilities for the initiation of the SharePoint technologies platforms as well as its operation.
Define strategic teams to address strategy issues.
Establish cross-functional problem resolution teams to address complex issues which arise. |
Clearly defining roles and establishing formal teams to address both the specific tasks which arise and to evaluate cross functional problems creates the structure necessary to complete the initial development of the central platform and to resolve issues that arise quickly. |
| Site and Platform Classification |
Create a classification by number of users and longevity: enterprise, departmental, team, project, and personal.
Create a classification by type of use: portal for communications, application for tactical results, and collaboration to facilitate team operations. |
Create a common understanding for the types of SharePoint solutions the organization knows how to do well and a vocabulary for speaking with parts of the business about what is needed. |
| Service Level Agreements |
Create a service level agreement around the length of time and approvals necessary to create a site.
Establish service level agreements for problem resolution through the help desk
Negotiate performance service level agreements for the first load of a site, subsequent loads of a site, and performance at remote locations |
Establishing service level agreements drives the understanding of the organization as to what to expect. Service level agreements are a commitment upon the part of the core team that the systems will be available which can in turn drive adoption. |
Development and Configuration
SharePoint technologies significantly blur the line between what is development and what is configuration. This section covers the items which are either software development or are configuration. These are essential parts of the governance plan so that the solutions implemented on the platform are consistent.
| Development and Configuration |
| Item |
What To Do |
Why To Do It |
| Branding |
Establish templates for what the SharePoint sites will look like
Determine which types of sites may be modified and which may not
Define which parts of the template may be changed by site owners, and which may not.
|
Establishing a core brand will not only make the site seem to belong to the organization but will promote better navigation and organization. Defining which areas can and can not be changed creates the flexibility necessary for adoption. |
| Customization Tools |
Define what customization tools will be allowed.
Communicate what actions will be allowed and not allowed in the tool. (i.e. unghosting) |
Nearly every business unit within the organization will want to place their stamp on their site. The challenge is controlling this so that their need for individuality doesn't hinder maintainability. |
| Site Definitions and Templates |
Establish guidelines for the development of site definitions and mechanisms for coordinating ID usage.
Communicate policies for site template deployment such as the requirements for a globally installed template. |
Site definitions and site templates have their own unique challenges with regard to how to manage them in a large environment. Clear communication and decisions up front can improve the ability to manage input from multiple groups. |
| Source Code and Build Control |
Determine if a central repository will be required for all code installed on the platform.
Establish standards for building components either on a centralized server or as guidelines for building software.
Communicate expectations as to reference documentation (compiler generated) and warnings (whether they are allowed)
|
Source code is the essence of your organizations enhancements to SharePoint. Establishing a common set of expectations and rules around the development of code will make the maintenance process easier and will lead to a more stable system. |
| On-going Source Code Support |
Describe the responsibilities of business unit for ongoing code support. |
Defects will be found in code, sometimes long after it's initial deployment - understanding who will address those defects is essential to the long term survivability of the platform. |
| Development Standards |
Establish guidelines for which assemblies may be installed to the Global Assembly Cache and which may not.
Establish rules about the use of the AllowPartiallyTrustedCallers attribute. |
The security of the site is determined by what code is allowed to run and with what permissions. .NET's code access security and the implications of GAC deployment are important to maintaining a secure system. |
Infrastructure
While most infrastructure items can honestly be considered implementation details there are a few which will have a significant impact on how you implement SharePoint and what the features will be available. The infrastructure items outlined here are important for inclusion in your governance plan because their impact on the way the solution will be used.
| Infrastructure |
| Item |
What To Do |
Why To Do It |
| Firewalls |
Establish and communicate rules for outbound connections from the web servers for use by the Content editor web part and RSS Viewer web part |
Best practice is to not allow servers to access the web directly. Further including content from a third party site through a content editor web part or through the RSS reader web part creates exposure for cross site scripting attacks. Controlling what sites can be linked to from these tools is a security and operational concern. |
| Load Balancing |
Decide upon and communicate the load balancing settings related to session stickiness. |
Developers must know if they are expected to handle situations where a single session is transferred between servers. |
| Environments |
Define the environments which will be used to develop and test solutions in SharePoint.
Describe the actions which are expected and those which are prohibited in each environment
Communicate policies for site template deployment such as the requirements for a globally installed template. |
Defining the environments helps business users and developers know what resources they have available to test changes without impacting production. |
Tune in later this week for Part 2 of this article, where I'll cover operational concerns, education and training, and navigation, taxonomy, and search.
Printer Friendly Version