ECM Governance - Post 3

Guiding Principles continued

Hi Everyone (or me, myself and I, not sure if anyone reads this...) sorry for the delay in this next post, I having been busy doing and not spending enough time writing about it.  In my post 2, we examined the idea of guiding principles and how they are used to set a foundation for our ECM.  We identified several categories or "Areas of Impact" that these principles could be separated into and this week I would like to start by detailing the intent of each of those categories.

General Principles

The general principles are principles that do not fall into any other category, they are usually the least specific (or most general) and often refer to governance rules and policies and how you intend to use them.  A good example of a general rule is the scope of the governance plan or how we intend to apply principles as a general rule.

For example, we want consistent governance across the entire solution and exceptions need to be recorded whenever a site or site collection does not follow the set of policies defined.  In that case, we can create a general principle to define that need:

Governance Scope
Principle
All governance principles, policies, standards and training are tied to the scope and intended purpose of the entire solution. Governance applies equally to all sites and all site areas.

Implication
While some policies will be enforced across the entire organization, others may be determined by each site owner. The Governance document is not intended to define the site specific policies, but is intended to provide the foundation for all sites. Deviation from the governance policies is by exception only and should be recorded and approved by the steering committee prior to implementation.

Security Principles

Security Principles deal with the need for security and how we plan on using security in our solution.  We address things like the security architecture, the use of roles, external access and permission management as security principles.  It is important that we keep security principles as general as possible, to allow for better granularity at the policy and configuration level of the solution to meet the organizations security needs.

As an example we can look at a principle that is common to any governance plan, the use of roles to manage permissions within the solution.  Again the principle is defined and then the implications to the way the solution will be used are outlined.

Role-based Security Model
Principle
Use of a Role-based security model will govern access control and permissions to the SharePoint Portal.

Implication
Users may have different permissions on different sites or areas of the site, which has an implication for both governance and training. This permission is based off the roles that are assigned at any given level. Direct permissions should not be used; if it is found that direct access is being provided, the roles should be reviewed to determine if a GAP exists in the role structure. If a GAP exists, a new role should be defined to prevent the future need for direct security permissions.

In my next post, I will go over the remaining principles Document Management Principles, Publishing Principles, Collaboration Principles, Business Process Principles and Esthetic Principles. Also if you want to learn more in person, I will be presenting on governance at the SharePoint Summit Vancouver 2013, October 28 & 29, I hope I see you there!