​Creating a SharePoint information governance plan can seem like an overwhelming task, especially when you take into account all the areas of your organization that might be affected by SharePoint.  As well, it can become mired in internal politics and endless debate.  But many would agree that it can be so important to managing your organization’s information and collaboration infrastructure with a well-defined set of guidelines and processes.

Many of us have seen great presentations about how important information governance is to enterprises, with high level reasons why it’s so strategic to good collaboration, user adoption and information sharing.  However, how do you go about actually creating a governance committee, actually creating and documenting a governance plan and then sharing it with your organization to that its adopted, used and evolved over time?

It is important to keep the process of developing a information governance plan practical, with well-defined phases to the project, details around the topics of concern for the organization and measurable objectives.   As well, there are some key areas to focus on that relate specifically to common issues seen with SharePoint security and governance, and these areas can provide an organization with a place to start.  I like to say that “more information helps enterprises to make better decisions” and in that sense having some information governance established for a few key areas can be much better than none.  The key areas I like to start with when developing a governance plan are the following:

• Define Roles, Responsibilities & Authority

Defining the roles and responsibilities related to SharePoint up front allows you to document very clearly the appropriate contacts within the organization that can impact the SharePoint environment, and therefore your corporate information, in very specific ways.  As well, it allows you to define owners for other portions of the governance plan as the process evolves.  This process literally means creating a large table that lists the various roles that might be needed for your SharePoint environment, assigning both a primary and secondary owner (that’s 2 people’s names) to those roles and for each role defining a description of the responsibilities and the permission which that role will require within the environment.  The roles included typically relate both to network administration of the SharePoint environment, and SharePoint specific capabilities.  These include: SharePoint Farm admin, Active Directory Admin, Database admin, IT support, license administrator, setup/update admin, site collection administrators, lead architect of the environment, lead SharePoint developer, site owner, site designer, etc.  They can also relate to specific corporate level functions, for instance: the corporate record administrator, the owner of corporate wide HR or benefit information available within SharePoint, corporate communications related to a SharePoint intranet, privacy officer, knowledge officer information security officer and the overall owner of the SharePoint vision for the organization.

• Define Information Architecture, including a Metadata Taxonomy

This process allows you to determine how and where information within SharePoint will be stored and accessed. It involves making decisions like: we’re going to have a site collection for each department or one for each team; each project team is going to have a subsite with specific lists and libraries; these keywords are really important to us when searching for information; and we’re going to have users tag information with the following keywords.  It often results in a documented site map of the SharePoint environment.

As part of this process, I highly encourage organizations to develop a metadata taxonomy – that is deciding which keyword fields and terms are important to the business when tagging information and will be used in a standard way across most or all of your information.  Metadata taxonomies typically come in 2 flavors, global and departmental.  Most organizations end up with both a global taxonomy (a small number of metadata fields that will be applied to all content) and a departmental taxonomy (metadata fields important to each specific business unit or department).  I do not recommend trying to develop 1 global taxonomy which encompasses the needs of every department.  These simply end up too big, take too long to get agreement on, and typically change rapidly.  I do recommend that a global taxonomy includes a ‘sensitivity’ or ‘classification’ metadata field which allows users or systems to define the security sensitivity of each document.  Such a field, with a small number of labels like ‘confidential’, ‘public’ and ‘internal use only’ greatly help end users understand when they are working with corporate sensitive information and how to handle it.  Defining metadata taxonomy for an organization can itself be a large process, so it’s important to also keep this process practical.

• Define Rules for Site Creation, Management & Decommissioning

One common problem with many SharePoint environments is site sprawl, where sites are created, used for a period of time, forgotten and sites grow out of control.  This can cause many governance and compliance issues as SharePoint is adopted and usage grows, with forgotten sites, information that no one can access or sensitive information that is too openly available to the user community. 

Defining rules for site creation up front means having in place processes that help prevent site proliferation and ensure that sites are created judiciously to meet specific corporate needs.  This process means defining who is contacted when an employee needs a new site, who reviews the request to determine if an existing site can be used instead of creating a new one and what information must the requestor provide when asking for a new site.  A requestor should at minimum provide information like the site name, description, primary and secondary site owners and which groups internally should be granted access.  As well, organizations should consider using automated site policies to manage sites.  A site policy defines the life-cycle of a site by specifying when the site will be closed and when it will be deleted.  Various site policy options are available that help this process to be either manual, automatic or to send email notifications at preset times after a site is created or closed.  Closing a site is a new concept in SharePoint 2013, and when you close a site, you specify that the site is no longer used so that it can eventually be deleted according to a schedule.

• Define Security Controls related to Groups & Permissions

Another common issue with many SharePoint environments is the management of permissions.  Permissions within SharePoint are used to grant or remove access to information.  If permissions are not applied consistently across a SharePoint environment, or are applied with the appropriate oversight/approval for sensitive information, this can cause serious security, governance and compliance issues. 

Defining security controls and processes for permissions and group management involves making decisions that can have a wide ranging impact across the entire organization, for instance: where does the responsibility lie to approve if users or groups will be granted access to information; will granting permissions be restricted to groups or is granting access directly to users permitted, will Active Directory groups or SharePoint groups be used; will permissions be centrally managed by an IT team or delegated to site owners across the organization; will breaking permission inheritance be permitted or discouraged; will permissions be monitored or reviewed on a regular basis and how; etc.  This process can also include determining if specialized security measures are required for corporate sensitive information.  Defining these processes up front can help prevent compliance and governance issues related to sensitive information being too widely shared internally or leaking out of the organization.

• Define Training Needs; Determine How to Educate your Users

SharePoint is typically new to many end users.  Many organizations are moving from network file shares or other knowledge management systems to SharePoint.  In these cases, many of the concepts transfer over to SharePoint, but how users access information or accomplish a task can be very different.  As such, lack of training can negatively impact adoption of SharePoint across the organization. 

Determining a plan up front for how the user community is educated and how ongoing training can be provided will greatly benefit end users and enhance adoption of the SharePoint environment.  Training is not just necessary for new employees, but it may also be required as users change roles in the organization or occasionally as a refresher program.  As well, training does not necessarily need to mean formal training classes.  It can include tools like short videos available from the corporate intranet, on how to accomplish a very specific task in SharePoint.  It can also include a power user program, where end users across the organization who have shown a key interest in SharePoint and have completed a power user training course, can act as a go to person or first line of support for other end users.

An information governance plan is typically an ideal place to document the corporate training program for corporate collaboration, information management and SharePoint.

There are many other aspects of information governance that a plan can and should cover, from user adoption programs, to site page design, to records keeping, user management, legal holds, etc.  Every organization is different and every information governance plan is therefore going to be different.  However, starting with some of these key areas when developing an information governance plan can help to avoid some of the most common governance, security and compliance issues seen with SharePoint.  As mentioned earlier in this post, “more information helps enterprises to make better decisions” and I do believe that an information governance plan focusing on a few key areas is much better than having no plan at all. 

   -Antonio