The art of SharePoint governance

Many organizations plunge into the deep end when it comes to SharePoint. And while its basic functionality, once learned, is pretty easy to deploy, wise organizations pause and consider how they want their SharePoint garden to grow. Without a few guidelines, rules and boundaries, SharePoint can quickly become a weed-ridden mess in which it’s hard to find what you need. Here are some governance document starters that should put you on the right path.

Goals and objectives

Why are you implementing SharePoint? A clearly stated objective and detailed description of what an organization expects to accomplish with its rollout of SharePoint acts as a necessary compass when deciding what will and won’t be deployed. Here are some reasons organizations have deployed SharePoint:

• To make documents easier to locate and access
• To facilitate collaboration and sharing of information
• To save money on server storage and maintenance or “one-off” application
• To improve business processes through improved workflows
• To distribute responsibility for maintaining and securing content.

Governance team

Three different sets of roles and responsibilities should be included in a governance steering committee structure, at a minimum. The information technology folks, who are tasked with keeping systems available, are an integral part of your team. IT is keenly aware of space limitations and system performance. You may want to upload every engineering drawing your firm has ever developed, but very few people will be able to do anything else in SharePoint if you do. IT can help here.

The governance team should include someone whose primary responsibilities center around internal controls and information security. While this role may also be in IT, where possible, it should be independent. This allows for objective action when functionality that can be technically deployed also happens to compromise compliance.

The final role is assumed by the end user. It might be someone who will act as an individual subsite administrator, the managers of areas that will use SharePoint to facilitate their business processes, or the people that have key input into how their team’s site is deployed. A library structure may be technically elegant, employ the proper content and retention controls and be completely unusable by the very people it was supposed to benefit.

There may be additional roles based on the size of your organization and number of users, but these roles and responsibilities should be established and have representation on a steering committee or other team charged with keeping SharePoint in shape.

Access control

There are two baseline approaches to access control from which an access control structure grows. First, allow everyone to read or read and contribute, then lock it down in the individual subsites. Or, allow only to read and contribute at the top-most level and deploy each additional team site locked down to only that team. If your objective is focused on sharing and collaboration, the latter may seem like a good idea until access administration and managing permissions becomes a nightmare. Neither is wrong, nor right. Just ensure it aligns with your goals and objectives.

Content

What will you allow in SharePoint? Will business records be created and stored there? How long should content remain in lists and libraries? Should certain types of documents be restricted (contracts, artifacts, images)? Deciding this early will help build a SharePoint training and awareness program, creating a team that helps you maintain SharePoint as a useful and well-managed tool for your business.