In my first article in this Governance series, I described how defining the initial steps of governance can be related to a parking lot. This generated some interesting e-mail discussion, and I thank those of you who took the time to write me. Many enjoyed the comparison, and one person in particular said that she explained it to her boss who “finally got it.” This article continues to build on the foundation with some suggestions on how to define policies within your organization.

First and foremost, it is of critical importance that management (or at a minimum the Project Manager) understands the three sections into which governance is divided: IT governance, information management and application management. You can think of these as the categories from which you will be creating your policies. This understanding will help to explain, gather, and delineate ownership and requirements once they start coming in. From a management perspective, these categories refer to different areas of the business or department that need to get involved.

IT governance refers to the level of control around the services that are being offered through SharePoint. These items may be at the software or application level in an effort to manage what happens inside your SharePoint environment. This group defines the offerings of the services, as well as the policies and controls contained within it in order to meet the business needs of the organization.

One of the most critical pieces of the IT governance section is the creation of a Service Level Agreement (SLA). This is always one of the more contentious yet necessary pieces of your governance plan, since the business and service teams will have to agree on the appropriate service levels. Some of the items within this SLA can include availability, service windows, support and training.

When you create your policies, remember to be reasonable with your instructions and the ramifications for those who do not comply with them. You do not want to have a Wild West governance plan in place, but you also don’t want to constrict people to the extent that it inhibits them from doing their job.
The reverse is obviously true. For example, I know of an organization that instituted a strict “no attaching of documents” policy. If a document is to be referenced, they must include a link to the file. This policy was put in place for many reasons, namely to control document versioning and to reduce server space, which accumulates from e-mail inbox expansion. Like any policy, controls must be put into place to ensure people are appropriately reprimanded. This is where compliance is measured.

The company decided that, for each attached document, the “offending” employee must put 10 cents into the virtual swear jar. At the end of the year, the company tallied the jar, matched the amount and donated it to a local charity. Though this may seem unconventional (since the number would be reduced over the years as people no longer sent attachments), the company pledged to donate the original amount, plus the donations from the year to the charity.

Information management is the area of governance that includes the data layer of SharePoint, also referred to as information architecture. This is the content that is housed and managed by SharePoint, including lists, websites and documents. You can think of this as any data that has been created, surfaced through or interfaced with SharePoint. When it comes to governing this information, the questions are how should it be managed, by whom, and at what intervals?

When creating policies, the first decision to make is whether to have a tight or loose structure. Tightly managed information is the content that is heavily tagged with structured metadata. Loosely managed data is uploaded with little or no metadata and is therefore difficult to search for, or is categorized into lists. Given that this business decision is a policy unto itself, you can continue to build on the tight structure with policies on version history, intended audience, data presentation and term source, to name a few starting points.

In the application management realm, governance is implemented based on the level of control surrounding applications that are developed for the environment. An application in this sense is a piece of functionality built specifically to perform business functions, and likely includes workflow or automation of a critical business process. As you create policies for the applications in your environment, be sure to define which development tools should be used, who will be responsible for the code (and where it will be backed up), what branding rules should be followed, and guidelines for updates and customization.

Next month, in my third and final article in this series, I’ll address some of the considerations in creating a governance team for your organization. These are the people who become your compliance and enforcement “soldiers,” so ensuring the right corporate buy-in and staffing is critical to your long-term success. I’ll also discuss some strategies for adoption and compliance.

Eric is the EVP of Systems Integration for Concatenate, a software firm focused on maximizing SharePoint through product innovation and systems integration based in Toronto. You can reach Eric by e-mail at or on Twitter at @rizinsights. Read his other SharePoint thoughts on his blog at