SharePoint Governance Plan: A Journey, Not A Destination

Over recent months, I have written a number of columns and articles about SharePoint governance. I’ve also spoken at numerous events and to hundreds ofcustomers about SharePoint governance, including my recent presentation at the Australian SharePoint Conference, where my keynote address laid out aTwelve Step Program for governance.

As I’ve evolved the way I communicate with customers about governance, there’s been one message that has seemed to resonate with a lot of folks.

The bottom line is that it’s generally not feasible to lay out your governance policies and SLAs for SharePoint in a vacuum, without the context of thespecific business solutions you are trying to attain with SharePoint. Therefore, it’s something of a folly to expect that you can fully and richlydefine all of your policies and SLAs in one fell swoop.

Governance isn’t a project, it’s a process. And it’s therefore critical that your governance plan define or at least account for how you will manageyour portfolio of solutions, and how you will learn and evolve as you progress on your SharePoint journey. This week, I’ll discuss this concept indetail.

What Real Governance Is

It’s folly to rehash the details of my theories about and tools for SharePoint governance in a short weekly column, but I’ll emphasize that realgovernance encompasses strategic and political considerations, project management, change management, operations, and interfaces between each of theseprimary elements.

Governance should define—among other things—exactly how SharePoint delivers business value (functionality and service levels), the resources that theservice requires to successfully deliver that value (money and people, for example), and the processes by which business needs are transformed intosolutions, deployed, and maintained.

Central to the above “nutshell” of governance are the concepts of business value and business need. It all starts with requirements driven by thebusiness—of course.

With some services, business needs don’t change significantly over the lifecycle of the service. Take email for example, with Exchange as an exampleplatform. The business need is to communicate both internally and externally.

Email provides a proven and well-understood mechanism for doing so. It might actually not be the most efficient service for supportingcommunication across all workloads, but in the context of broad requirements that might include “universal” availability (both internally andexternally), and minimal cost for training and support (for a well-understood tool), email and Exchange often ends up being the service of choice.

When you deploy Exchange, you understand the requirements of the business, which might include a certain amount of email traffic, archiving ande-discovery, calendaring, shared contacts, and resource scheduling. You can architect a solution that supports projected needs.

And experience has shown that most organizations maintain a relatively static Exchange service for many months or years. Business needs—other thanperhaps sheer quantity of email—don’t change much.

SharePoint is Different

SharePoint is a very different beast. Whatever business problem you deploy SharePoint to address, it’s never going to “sit still.”

If you deploy SharePoint to improve collaboration within teams and projects, six months later someone will be asking you to expose data from back endsources for business intelligence purposes, or to deploy social networking features, or to extend search, or to migrate the legacy intranet toSharePoint. And as soon as that project is finished, the next one will come along.

SharePoint itself is a work in progress, rather than a static service.

When you deploy your first solution—let’s use team sites as an example—you can and should evaluate business requirements to architect a solution thatoptimizes all requirements. (Note that I use the term “solution” in the generic business sense, not in the technical sense of a “SharePointSolution”--.wsp package.)

Notice I said “optimizes” not “meets” requirements. Very few projects can meet all requirements, in my experience, because the businesstypically wants “everything”, “tomorrow”, “for free.”

Something has to give. Choices—often difficult choices—have to be made. One choice you have to make is related to service level agreements—uptime as anexample.

You might choose to support a 95 percent uptime for team sites, which allows for 18.25 days per year of downtime—less than two days of downtime formaintenance per month.

Guaranteeing a 2-nine (99 percent) uptime (3.65 days per year of downtime) or 3-nine (99.9 percent) uptime (8.77 hours per year of downtime) areexponentially more expensive to provide, and so a choice has to be made to optimize service levels and cost.

That’s all fine and dandy. Governance—project management and solutions architecture, specifically in this case—should provide mechanisms for makingthese decisions.

Now it gets tricky when the business comes to the service with the second (or third, or fourth…) request. Each subsequent request must be evaluatedwithin the context of the existing service, and all previously deployed solutions.

For example, let’s assume that the business wants to support a workload related to responding to Requests for Proposal (RFPs). And, let’s assume thatthe level of business criticality for this workload is high—the business relies heavily on this workload and revenues are at risk if anything goeswrong. Therefore, high availability is required.

Governance—again, project management and solutions architecture in this case—should account for the state of the existing service, which supports onlya 95% uptime. Decisions will have to be made about whether, or how, this workload can be supported on the existing farm.

Perhaps the farm can be scaled with additional web front ends, and by migrating the SQL database from a stand-alone server to a cluster. Or perhaps youwill decide to host this workload on another farm. Either of these approaches or any other method for raising SLAs carries costs, which must befactored into the cost of the new workload.

You must also evaluate the impact that the new workload will have on the currently deployed solutions. Will the new workload adversely impact theservice’s ability to continue to meet the requirements of the existing solutions?

You can see, through this simple example, that it’s critical to build an inventory and an understanding of what you have done and what the service isdoing. We’re talking about one of the fundamentals of portfolio management. You have to know what you have in place.

And you have to know what you agreed to do with each of those solutions: what were the requirements, the agreements, and the metrics for success? Onlywith this information can you confidently begin to layer on additional solutions for new workloads.

One of the other things that will happen, inevitably, is that you will make mistakes, and you will learn. You must be prepared to incorporate lessonslearned, decisions made, compromises reached, risks assumed, and costs accepted into an evolving and ever-developing set of governance policies andprocesses.

Governance is a Journey

So what is a governance plan then? In my opinion, it is not a blueprint or a set of policies for what SharePoint will look like forever.

Rather, it’s a definition of how you will move forward, how decisions will be made, how solutions will be built, deployed, and maintained, and how therequirements for and lessons learned from each solution will be incorporated into the next step forward.

A governance plan is a plan for evolving a service, not a specifications document. As each solution is brought—by governance processes—from businessneed to deployed solution, the requirements and specifications of that solution become part of the service.

So over time, the service certainly evolves a technical reference of policies, procedures, and specifications. But those details come out of therepeated journeys through the process, rather than from some massive “governance project” before the service is deployed.

Governance defines the journey, not the destination. Requirements (of each solution) determine the specifications and policies of the resultingservice. Happy journey’ing!