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