The Governance Plan

As we have discussed governance, we have frequently mentioned the need for planning. All of the various 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.

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 service. 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.

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, responsibilities, 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 SharePoint 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 update 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 constructive 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. 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 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 doing things. 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 standards. By creating page and site templates, you can encourage users to adopt a common style and structure 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 eliciting 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 reporting, fixing, and communicating these issues will help the users feel that their concerns are being addressed.
• 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.
• 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.