Creating Your SharePoint Governance Plan

Unlike a few years ago you now have sample governance plans you can look at, there are articles describing the kinds of things that you need to make sure are in a governance document, and a governance resource center on TechNet.

The goal of this article is something slightly different. The other resources available describe what to create, in this article I'll focus on the process for creating the plan based on the engagements I've been a part of. Rather than a specific step-by-step process, what appears here is a rough framework that you can and should tailor to your unique situation. In the following you'll also find some insight as to the psychology of putting a plan together as well as the aspects of how we as humans learn and process information.

The underlying assumption to this process is that you have an expert available. Whether you're contracting that expert yourself or using one of the Microsoft programs like SharePoint Deployment and Planning Services (SDPS) to get the resource, it's assumed that the time estimates below are your time with an expert.

Phase I: Orientation
The first phase of a typical governance project is an orientation phase. This is, generally speaking, a single day for a mid-sized organization but can be broken into multiple two half day sessions which are spaced close together (within one-two days). There are three major objectives for this phase:

• Verify a clear definition and objective for the governance
• Educate the consultant on the organization, industry, and special factors which may be working on the organization.
• Educate the client on some of the features of SharePoint which may be appropriate to consider as a part of the governance process.
• Walk through the high level decisions related to governance.

The key to any successful project is to clearly understand what the objective is. Generally we start the day with a conversation about what governance means including some alternative thinking on what governance is, and reaching agreement on what definition we're going to use for governance as well as what we'll define as success for a governance process.

Ultimately the goal is to collaborate on the creation of a governance process and plan. In order to do this there are two different sets of domain knowledge that need to be transferred. First, the consultant needs to get from the client information about the organization including background on the industry in general (if the consultant isn't familiar with the industry) and any special factors for the organization that may make the governance process and plan difficult, different, or "interesting."

Second, the consultant needs to educate the client on the parts of SharePoint that are applicable to their situation. For instance, the quintessential feature is the Quotas feature. This is a part of nearly every governance plan. However, conversely, the SharePoint Single Sign On feature rarely is a part of a governance plan. The consultant will tailor the information communicated about SharePoint to those parts of the product which are most necessary to reach an agreement.

The final step is to walk through a high level discussion of governance. The objective is to review a set of questions that are useful for the creation of the plan. Frequently these questions are based on the two SharePoint Governance articles at IntranetJournal.com [Part 1 and Part 2] or the SharePoint Deployment Guide and Checklists. The goal is to sort the questions into three piles: definitely govern, don't govern, and discuss. We don't generally discuss the "discuss" items during this day because there isn't time. The good news is that the items that end up in the definitely govern category are relatively easy to develop guidance on and can be started without outside help -- although there are often cases where a review of these is appropriate.

Generally this process more than consumes a day's worth of time and really just starts the process rolling. It doesn't in itself create a governance plan and in some cases it stirs up more questions than it seems to answer. This is normal. The objective of the day is to get the process started and get the right questions being asked.

Phase II: Initial Plan Generation The next phase of the process which generally takes one-to-two days is to work through the issues associated with creating a plan. Ideally this should happen no sooner than two days after phase I and no later than 2 weeks after phase I. The reasoning is because people need to have an opportunity to think through the materials and discussions from Phase I. In organizations with a dedicated team working on SharePoint with the time to dedicate to the process two days seems to be appropriate. For organizations where the resources aren't dedicated it seems like 1-2 weeks is optimal. More than two weeks doesn't provide enough urgency and generally too much time is spent reviewing what was covered in Phase I.

In general the process for Phase II looks like this:

• Level set including explaining the impact of governance on adoption and engagement and how governance should be approached in order to balance the need to evangelize the platform and control risks.
• Work through the list of "discuss" items from phase I.
• Discuss other successes and failures with different governance approaches.

Before we start the process of writing the initial plan we review what a plan should look like. This is approached from the thinking that should be in the mind of the authors (Governance or Guidance), the specific language definitions that should be used so everyone is clear on how flexible the governance is, and keeping the size of the document down (Generate development documentation with the inclusion by reference method).

We also cover the idea that Governance is a process and not just a plan. There are two aspects of this. First, is the aspect that there will be continuing requirements to execute the plan like solution reviews, and change control. There's also a second order effect to the creation of the plan itself. By creating the plan you've improved your understanding of the situation. That improved understanding is often more important than the plan itself. (See "Creating artifacts -- what you don't know.") By developing the plan you'll not only understand the end guidance but also the thinking that went behind it.

The next step is to start working through the "discuss" items from Phase I. This generally alternates between a discussion of the organization's unique needs and situations and how SharePoint works and what has worked at other organizations.

It's important to note that the one-to-two days of time mentioned above is the time to meet and discuss with the expert. This doesn't include any time for creating the plan document or routing that document for approval.

At the end of this phase it's possible to deliver an initial plan that should cover the core needs of the organization. As we'll see there will be another phase to kick start the governance process for revising and enhancing the plan.

Phase III: Information Architecture, Taxonomy, and Navigation
One of the closely related topics to governance is the topic of the organization of the information that will be added to the platform. Whether this topic is identified as taxonomy or Information Architecture (IA), the guidance on how to organize information in the platform is generally closely related to the governance of the platform. However, where governance is about creating a set of guidelines, creating an information architecture is about analyzing the information to be managed and providing a categorization structure that can facilitate findability of information in the organization.

The information architecture discussion generally takes one to two days to get started. The conversation consists of:

• Definition Review including a buzzword to English translation guide
• Review of SharePoint features related to search, taxonomy, and organization
• Exploration of the impact that search has on findability and metadata
• Discussion of the difference between storage and retrieval of information -- said differently organizing for the creator vs. organizing for the consumer.
• A Card Sorting or similar organization exercise

Just as governance isn't just a plan it's a process, so too must you expect that your information architecture will evolve over time. Because of that the objective is to expose the team to the key concepts in information architecture and to walk through exercises designed to illuminate key approaches to organizing information that may be useful in the organization.

The definition review part of this phase is designed to link the terminology used in the industry, such as taxonomy, to concrete topics that make sense to everyone like creating a filing system. We'll connect metadata to the sticker that might be found on the tab or on the outside of a folder. Instead of vague concepts you'll be able to connect with concepts you already inherently know.

The SharePoint feature review is similar to what happened in Phase I where specific features were reviewed as they applied to how you would govern the platform. Here, however, the focus is on information management so tools like site directories, navigation components, site columns, and content types will be reviewed.

Next is a discussion about what all of this means. Once you understand the objectives (to find information) in detail and you understand the tools that SharePoint offers to you it's time to see how those tools may shape your design. This discussion includes the limitations of leveraging search to find information (the delay between creation and index) as well as other issues such as distinction. This discussion also generally includes how to leverage search to bring common types of documents together such as providing a consolidated view of forms.

With the objective, tools, and techniques behind you it's time to learn more about different organizational structures. We're all familiar with the dewy decimal system and how library card catalogs work. We'll look at how this system works as well as the balance between making items easy to store vs. making them easy to retrieve. Finally, it's typically to run through a couple of techniques, such as card sorting to show effective ways to elicit feedback about how to organize content from an audience that may not be able to clearly articulate the ways that they organize information.

Phase IV: Systematizing the Process
I'm careful to make the distinction between a static document which sets upon a shelf and a living process which grows and evolves over time. Governance planning cannot be just the governance plan. It cannot be a once and done type of project. Governance is a process that at some organizations will need to be reviewed quarterly. At other organizations it may need to be reviewed annually. Using the information from the process of developing the plan it's possible to create a roadmap for how frequently the plan should be revisited as well as the type and frequency of meetings for the various groups.

The final phase is generally establishing these schedules and identifying what situations or events should cause the roadmap to be redesigned. The process generally takes a day or two and involves mapping out the intervals, project pipeline, and organizational needs.

Summary
In most organizations a governance plan -- including a basic information architecture - shouldn't take man-months of effort. If you realize that the objective isn't to create a huge document that no one will read but is instead to create a plan and process that's minimally sufficient for managing the organization's risk with the platform. By carefully walking through a process you can create a plan with one-to-two weeks of outside assistance and a few weeks of internal time to document the plan.