Building a SharePoint Governance Plan Before Migrating

Building a SharePoint Governance Plan Before Migrating

by

SharePoint Governance has become one of the biggest buzzwords when talking about SharePoint migration. You read everywhere how important it is to create a governance plan for your SharePoint, but no one explains how you can get started and what tools you can use.

The same goes for a SharePoint Information Architecture.

In this article, I will try to give you some of the tools and examples I have been using throughout my past SharePoint migration projects.


Articles in this Series
1. SharePoint 2013 New Features: Should You Move?
2. Migrate to SharePoint 2013 - Supported Upgrade Paths
3. Designing a SharePoint 2013 Architecture
4. How to Build a SharePoint Migration Plan
5. Building a SharePoint Governance Plan Before Migrating
6. Predicting Post-SharePoint 2013 Migration Issues


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.

SharePoint 2013 Support Model

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.

SharePoint migration Governance and Information Architecture
SharePoint migration Governance and Information Architecture

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:

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!


NEXT ARTICLE IN THE SERIES
6. Predicting Post-SharePoint 2013 Migration Issues

Benjamin Niaulin
Benjamin Niaulin @bniaulin

Well known as the SharePoint Geek, Benjamin has been helping people all around the globe reach their goals by simplifying SharePoint solutions. You haven't met Benjamin yet? Look for him at SharePoint conferences and events!