The buzz word, SharePoint Governance, sure has become bigger than it actually has to be. It can almost be compared to the burden of carrying the ring in Lord of the Rings if it is assigned to you. When starting your SharePoint project, you keep hearing about how having a SharePoint Governance Plan is crucial for success, but no one tells you how to build it. Granted, Microsoft has released a lot more help on the matter than back with SharePoint 2007, but I think it’s important to have a real world example and explanations rather than just templates. So I decided to write this series of articles to help you build this SharePoint Governance Plan without over complicating things.
What is a SharePoint Governance Plan and who writes it?
Let’s get some definitions out of the way. If we want to build a Governance Plan, we first need to understand what it is exactly and what purpose it serves. When I start my document, after the title and main presentation page, the first thing you will see is a summary and the objectives of the plan I am writing. Essentially, the summary is the definition of a Governance Plan:
The SharePoint Governance Plan is a guidebook outlining the administration, maintenance, and support of X Corporation’s SharePoint environments. It identifies lines of ownership for both business and technical teams, defining who is responsible for what areas of the system. Furthermore it establishes rules for appropriate usage of the SharePoint environments.
Recognize the text? It comes from Microsoft’s sample governance plan but is a great way to start off ours as well.
But then, who should be in charge of writing this important document? The question I am often asked is "Should it be done by the Business or by IT?" and my answer is simple. It should be done by whomever is most knowledgeable on the SharePoint Platform and in most cases, that's IT.
SharePoint Governance will vary based on company maturity
Back in the days of SharePoint 2010, I had written an article on SharePoint Governance that can help you get a head start while I build this article series. The article stresses how important it is to build a plan, but that it doesn’t have to be a complicated one for it to be successful.
We’ve established that a SharePoint Governance can be made out to be very complicated or as we saw in my article above, simple. The thing is, this will vary based on the company’s maturity with SharePoint, and often its’ size. Larger enterprises will not have the same needs as a smaller or medium-sized company.
Therefore, you need to take this into consideration while you read this article, not everything will apply to you. The goal of the article is to help you get started with your SharePoint Project and setting up a Governance plan to help make it a success.
The famous « We want to Collaborate » at the beginning of the project
In an ideal world, you know exactly what SharePoint does and what you plan to do with it. Whether it is to build an Intranet with the Publishing Feature or Team Sites to facilitate collaboration with very specific goals. Unfortunately, it often isn’t what we are facing when talking to either our customers or management. Here is what I hear sometimes:
« We want to collaborate and we already have SharePoint licenses » and with Office 365 this is becoming even more of a reality. The problem in this case is that, we do not even know how SharePoint is actually going to be used and it is therefore almost impossible to build a Plan that will Govern this platform.
You need to know what you plan to do with SharePoint.
Again, this article is meant to be as close to Real World as possible by sharing some of my experiences. And as you probably have already been thinking, it is hard to tell the person hiring you to go back and do his homework on SharePoint and know which specific business need they intend to solve with the platform. You should, of course insist on helping them figuring this out. After all, that’s why you are in charge of this, but it is not always that simple.
What I recommend to those wanting to « collaborate » using SharePoint as a platform is to start with a Team Sites deployment. This should help them get familiarized with SharePoint and available features to perhaps eventually build more. However, when you do start this way, there is an even higher probability that they will keep coming back with « changes » as they realize what can be done. And this leads me to the purpose of this article, you will need a Governance Plan and with it, a Governance Committee.
*Note: When I say deploying Team Sites, it does not necessarily mean the Team Site Template
In this article series, I will assume the company wants to deploy « Team Sites » to « Collaborate ». Vague isn’t it? Then I again, I did say this would be Real World example. *grins*
Start a SharePoint Governance Plan by defining Roles and Responsibilities
Yes, before you even start building a Governance Committee, start by identifying Roles and Responsibilities for your SharePoint project. Identifying Roles and Responsibilities helps set boundaries and responsibilities to each and everyone in the SharePoint Project. In all honesty, it is a little political but I guess that’s how it works.
It’s important to define these, even if you do not have anyone yet assigned to that role, here are some examples.
The Governance Committee: This is probably the most important role on the list. And it’s not about it being difficult or harder to do, it’s really about backing you and the SharePoint team from the inevitable politics that will be played in the future.
Let’s take a break for a second and fast forward three months into the project after you or your superior presented the first pilot showcasing cool things that could be done. Without them really being ready of course. What’s next? People in other business units start demanding features and asking for things not in the roadmap. Of course, initially you say no and explain that your team does not have the velocity right now to deliver what they need to and add these changes. The thing is, they then go to their superior, the VP of « enter a department name here » and suddenly you need to do it. Unfortunately, this becomes a routine until the SharePoint team is stuck in an endless cycle of never finishing or releasing anything. And SharePoint becomes disliked by the organization.
The Governance Committee is there to back you up and protect you against this. We don’t ever actually say it’s a purpose of the committee and of course it’s not the only one, but it is an important reason to have it.
Because now, that person that wanted new features will see their superior or VP, which will be part of the Governance Committee that makes decisions on:
Features in the Roadmap
Evaluating the objectives
Defining Rules and Processes
Assigning roles and responsibilities
Producing a report for the Management Committee
This Governance Committee meets only every quarter or every 6 months depending on the organization, to evaluate any requests for changes, new features, etc… That means that our friend will be told by his superior or VP the same thing we would have told him.
The first time you build the Governance Plan, there will not be a Governance Committee formed just yet, but the role and its’ responsibilities will be defined within it. Perhaps even a few members might already be identified as well. But it all really comes together once you finish the first draft of this evolving document. They will meet, knowing the overall organization’s direction for the next couple of months, which allows them to make better decisions on SharePoint should be used and what should be done with it based on these priority.
It goes without saying that your Governance Committee should consist of higher management. But again, it will vary based on the organization. If you make a committee who's decisions can be overthrown by almost anyone in the organization then don’t bother at all.
*Edited: The Committee isn't just made up of higher management. Essentially, you want someone to be able to present the Plan and the reasoning behind some of the propositions as well as being able to estimate the feasibility and effort required to do something. You will then need people with decision power, to make a decision on requests that have been made or changes needed since the last meeting.
Other Roles and Responsibilities: There are obviously going to be many other roles and responsibilities to define in your SharePoint Governance Plan. The best thing to do is to create an easy to manage table with three columns.
Even if you do not yet know whom will be assigned to each role, it is still crucial for you to name the role and what its’ responsibilities are.
Here is an example:
Server Farm Administrator
Governance Compliance Officer
Development Team Leader
Developer / Analyst
Remember, this is just an example and depending on your organization the roles may be different. But do not try to create roles based on who you have in the team! A common mistake is to create the roles for our existing SharePoint team, instead of creating the roles the organization needs for SharePoint. Remember, even if you do not have someone for Training does not mean there should not be a « Trainer » role in your Governance Plan. It may simply not be assigned to someone yet or the same two or three members will be assigned to multiple roles, until someone else fills the spot.
Demystifying the SharePoint Governance Plan
I hope this introduction helps you start building your own, but also help understand what and why we are actually doing. The templates you will find on the internet are great, but if you do not understand them then it they might not be so useful. My goal is to show you that you can make your own Governance Plan without it being difficult. In the coming weeks, I will continue building this document by going over things like:
Site Management and Control
Site Templates definition
Site Retention and Deletion policies
Object Naming Conventions
Communication and Training Plan
As you can see we still have a lot to cover, but hopefully once it is done it will no longer feel like you are carrying the burden that is…SharePoint Governance.