SP Online Governance Plan

What is a SharePoint Governance Plan?

A SharePoint Governance plan is a set of rules that help to facilitate the use, maintenance and operations of your SharePoint. The plan helps set expectations and guidance for your team, as well as the end users.

The problem I see in most Governance plans is that they try to do, or to say too much. The result, no one reads or follows it and you’ve wasted weeks writing it. Why? Because most land on the TechNet section dedicated to SharePoint Governance.

I think the information Microsoft provided is amazing, however it has way too much content, which leads the person in charge of Governance to sometimes overdo it.

If a SharePoint Governance plan is 100 pages long, it simply will not drive anyone to read it or refer to it.

Using Enterprise Wiki for Building a Governance Plan

If you already have SharePoint, a fun way to start Governance is by using the Enterprise Wiki. This way, you can easily link your pages.

Start your Governance plan by topic, and tag each one with a Wiki identifying the “topic” pages.

Topics that Should Be Defined

There are certain things that absolutely need to be defined, but remember that it is not an inventory of your environment!

Typical example: The Governance plan should state what SharePoint environments will be used, with a short description as to what goes in it, or what it is used for.

Type	Description	Owner
DEV	Development environment limited to SharePoint developers.	Devs
INTEGRATION	This environment helps to test, to package and the integration of solutions.	Devs
TEST	Application tests and solution sign-offs from business users.	IT SP Team
PRODUCTION	Live environment with tested packages and solutions	IT SP Team

As you can see in my example above, I am not listing URLs or the number of servers, etc. That is not the role of the Governance plan.

Here is a list of Governance topics I make sure to have before beginning a SharePoint migration:

Topic	Description
Site Request	How does one ask for a new site and what goes into it.
Site Template	What Templates are available (including custom) and what are they used for.
Site Management	Definition of the allowed management of the site for the Site Owner. Is it free for all, slightly controlled or managed by an Information Architecture?
Unused Sites	What are they and what happens to them?
User Agreement	Whenever they get a new Site or Site Collection, Site Owners must agree to access the site.
Security	How is it managed?
Social Policies	Ratings, Tagging, Status etc… The My Site Profile privacy.
Multilingual	It's very important to explain what users should expect for multilingual needs in SharePoint. Variations, MUI or 3rd party tools?
Support Model	How is support defined? Who does the End User ask to get answers?
Naming Convention	Databases, Servers and Web Applications should be named using a designated convention.
Backups and Restores	What is the schedule for backups and when are restores tested?
Development	Define how thr development of new features will be done.
SharePoint Designer	Will it be used and if so, by who and how?
Archiving	Is there a plan for Records or will you just be eliminating old content over time? Link to a file plan if it exists.
Communication Plan	Constant communication with the End Users needs to be there to ensure the success of the project.
Training	Define what kind of training will be available for site owners, administrators and end users.
Etc.

The key to successful SharePoint Governance is to keep it simple. Every topic I mentioned above should stay very high level to help the business know what to do by referring to this document.

Keeping the Support Model Simple

Instead of getting into super complicated definitions of what the support model should be in your organization, use something like PowerPoint.

This way, I am sure everyone will understand the flow of support.

Don’t forget, if you chose to use a Wiki for your SharePoint Governance plan, it will be easily accessible from the Team Sites.

One effective way to do this is to add an option to contact support through the Site Actions menu.

Creating a SharePoint Information Architecture

I know what you’re thinking- Information Architecture? Wasn’t this an article on SharePoint Governance? Bear with me here. Information Architecture is like the best friend of a Governance plan, they complete each other!

Think of it this way- if you give a document that is so well defined that the developer, or whoever is building the SharePoint environment, can take it and create the sites exactly how you needed them; then you have an Information Architecture.

Whenever I create an Information Architecture, I want to make sure that everything is covered. Content types, Site Columns, Sites, Document Libraries and everything else required.

Using a combination of Excel and Word, I can list everything I need to the default value of a column in a Content Type. During a SharePoint migration, nothing is more important.

Of course, you could be using SharePoint migration tools to get the job done. But before you do that, you want to make sure you know what you are copying and where.

During a migration project, it’s the perfect time to restructure your Information Architecture. Many of us have learned over time what to do and what not to do, so there is a good chance that you’ll want to organize your Content Types in a similar way in SharePoint 2013.

The Tools I Used to Get Started

Information Architecture sounds fancy. Sounds like the kind of document you don’t want to oversee. However, it can be a lot simpler than you think, and the best person to do so is the one who already has a decent amount of knowledge on the ins and outs of SharePoint.

Here are some tools that could help you get organized:

• XMind
• Mind Manager
• Visio
• Book by Ruven Gotz – “Practical SharePoint 2010 Information Architecture”
• Balsamiq
• Excel
• Word

These are the tools I’ve used to kick start my SharePoint Information Architecture.

A good trick if you are just starting with Information Architecture, try to see what information you need on documents to archive them. This will give you a good starting point to identify document metadata.

In time, you will want to use tools like XMind or Mind Manager to organize this structure quickly. You’ll notice quickly enough, thanks to its easy interface, that many documents are similar in terms of properties or metadata.

You’ll find yourself grouping them together and forming “Content Types”. Once you’re finished, you’ll be ready to create a formal SharePoint Information Architecture.

It Doesn’t Have to Be Boring

You got into this project to work on SharePoint and now you find yourself having to build an Information Architecture. We’ve all been through it, and at first I felt the same way you are now.

My advice, take it one piece at a time. Go meet the teams and explain what you are doing and why, they won’t want to help unless you can show them how this will be helpful.

Don’t jump right into a 100 pages Word document, open XMind, start organizing some thoughts around it. Believe me; otherwise, you will be going back and forth into this Word document adjusting it constantly.

It can be fun; Information Architecture touches many things, including functionality design.

Navigation of the sites or site collections needs to be mapped and for that, Balsamiq does the trick. If there is a requirement to make an Events Calendar, someone must sit down and use Balsamiq to identify what it will look like. But most importantly, what information will be presented and where is that information pulled from.

Key Takeaways Before Starting a Migration Project

Although these can be applied at any moment throughout the timeline of your project, SharePoint Governance and Information Architecture are crucial steps in anticipation for a SharePoint migration.

What you need to remember before you start looking at migration tools, is that a solid Governance framework and a complete Information Architecture should be built. Otherwise, you will find yourself moving the same old problems and limitations to the new SharePoint 2013.

Start your Governance plan in pieces, don’t try to attack the whole thing at once, and forget about the complicated 200 document version.

Take it to the next level and make it an Enterprise Wiki. What’s important is to not get caught up in the little details and to really focus on providing a set of rules to help standardize the use, maintenance and customizations of your SharePoint environment.

The Information Architecture helps you identify what can be grouped together, and how it will need to exist in SharePoint. This document could technically be given to a SharePoint specialist outside the company to create the entire solution exactly as it is required. 

Better get cracking!