This is the last article of the SharePoint Governance Guidebook series, released during the European SharePoint Conference in Barcelona in May 2014. The two first articles entitled “Strategy & Business Drivers” and “The Managed Systems Catalogue” have explained the foundation for building an effective SharePoint Governance practice and detailed one of the most important components of the SharePoint Governance Framework. Now, the last article will cover building policies to governing SharePoint and using controls as a tool to stay in compliance.
At the time when you start thinking about building policies, you are already quite far into building a SharePoint governance practice. You already know at least some of the systems you need to worry about and give special attention to, as you have found out that these specific systems have an impact on the capabilities of your SharePoint service to deliver on business requirements. Hopefully you feel that this is well thought through. Do you? If you do not, maybe you should go back and read the first two articles in this series once more. Because if you do not have a very solid foundation to build on, the policies that you will create will not be effective. First of all because the will be governing areas and functionality that are probably not the most important ones to your users, and because the content of them is likely to become “fluffy” and not specific, as you do not know what they really mean.
However, let’s assume that this isn’t the case. I just wanted to mention it, because I have seen this quite often elsewhere.
SharePoint Governance Policies
So let us talk about Polices. Those things are the rule sets you provide around any given Managed System. IF you have followed the SharePoint governance Framework methodology, you will have a catalogue of Managed Systems – we call it the Managed Systems Catalogue – consisting of the Business Applications, Platform Services and Managed Processes that are important to your business. Each one of these Managed Systems must have a policy attached to them. This is the reason why we have made this object a managed system in the first place. We need to govern it, meaning that we cannot just let it live its own life and grow – or not grow – without our supervision and control.
So let us say that the Managed Systems you are about to build a policy for is “My Sites”. This is a common Managed System. Based on the work you have done earlier, it will be fairly easy for you to decide what kind of rule set you need to have in place for MySites. You can look into the definition of the foundational service – what we call the Service Definition – as “MySites” is probably described in there as a part of the foundational infrastructure and platform design. So I guess choosing MySite for a start is a good choice; as it is most of the time not implemented in a very complex way, and it is (or probably should be) a part of the foundation service definition, so IT have already made some clear platform boundary decisions that you can use to scope your work.
In addition, there is the Service Description. This document is a description of how Mysites work in a language that is understood by the broad community; users of all sorts. In most cases, you will identify many good areas to create standard or rules for, when reading what the specific system is supposed to do for users – and for the business in general. So go read the Service Description for MySites. If you don’t have one, ask the Owner of the MySites Managed Systems to provide one. But hey – since you are writing the policy for MySite, there is a good possibility that the Owner is yourself. Therefore, you can start off with the Service Description.
The usage of a policy
When you build a policy, you need to think about how it will be used in production. Many policies are written as Microsoft Word documents and the usage of them have not been decided from the beginning. Therefore, they ended up as Word documents and the truth for most of these are, that they are not read by most people. Since your policy for MySite probably is relevant for every SharePoint user in your company, you have a challenge.
How can you provide rules that can be applied to all users? In addition, what does it really mean to “apply” a rule in this case? Going through that thought process will be very helpful for you when you get to the point where you actually need to come up with rules. Not all rules are useful to know about for everyone. So providing all rules in the same document will simply not work – at least not in the case of a Mysite rule set. The only person that will be interested to look through the entire rule set together is you – as the owner of the policy and/or Managed system. Users are primarily only interested to know about the rules that are directly relevant to the specific task that they are doing – and at the time when they need to know about them. So if we can divide our rule set into different personas – all related to the Managed system – we have a much higher possibility to be successful.
One way to do this is by thinking about “Operational rules” and “Usage rules”.
Operational rules are rules that are applied to the operation of the Managed System – in our case, MySites. You may have a rule that defines a specific quota per Mysite or a rule that says that a certain percentage of all users should have Mysite provisioned at any given time. These are operational rules that are relevant for the people delivering the Managed Service. They will be responsible of running frequent controls of these rules and report the status; and subsequently to establish some kind of process to meet requirements and stay in compliance.
You can also have a rule that says that any users must have their profile updated with project experience, competences and contact information. You can always argue that User Profiles are not necessarily a part of MySites, but since users are updating profiles through Mysites this is a structure I see a lot. And it works, because it is the way users see the system. This is a Usage rule, as it needs to be applied to the individual usage of the system – and therefor the individual users. A very different audience than the other rules.
If – at all – possible, you should consider ways to automate applying rules. When a user is provisioning Mysite, there is no reason to why we should not automatically send out some introduction materials, which includes the usage rules for which users need to comply. In addition, we could automatically add a recurring task into the user’s task list, to verify that the profile is updated if we have identified this as being an important rule for the company to comply with as a whole.
Most of these types of integration of governance rules and controls are easy to implement. Especially with some of the tools that are available from third party vendors like Nintex, AvePoint and others. Remember that these tools do not deliver the governance practice, but can be extremely helpful in delivering the adoption of rules and staying in compliance in the long haul.
When running SharePoint Governance Master Classes, I always encourage people to uses the SMART method to build their policy rules. I have changed the meaning of SMART a bit, to make it even more relevant, but here it is. When you create a rule, make sure that it is;
Specific – targeting a specific feature, process or role and that is does not leave open questions
Measurable – enabling you to measure clearly if a system is in compliance or not at any given time
Assignable – can be assigned to a specific person to own and control
Realistic – actually something that we are able to live up to, under current conditions
Time-related – that it can be controlled and reported on frequently and on a schedule defined clearly
Staying true to these principles in your work with policies and rules, will help you make them relevant and drive adoption.
The anatomy of a SharePoint Governance Policy
There are no single right answer to what a policy should look like, but sometime a template can be a good help to get started. Especially, if this is the first time you are doing this. Let me just list some of the thing I think is important that you have in your policies. It is probably not everything that you need to put inside your policies. Nevertheless, this will get you started.
– Clear name: Readers should be able to identify what this policy is for
– Scope: A sharp definition of what this policy is covering, both from a functional, process and role perspective.
– Managed Systems: Obviously you need to clearly state what Managed Systems the policy is controlling. Sometimes a quick overview of the concept of the governance model will help reader understand these relationships.
– Risk Impact: You need to define how big of a risk it will be to the Business Driver (through the Managed System) if this policy fails. Remember, that a policy can fail based on the individual rules inside it fails or that the policy is not updated and validated in a timely manner.
– Ownership: The owner of the policy is usually the same as the Managed Systems owner. There should be very good reasons to except from this principle, as it will only create complexity and raise the risk of issues falling between chairs.
– Escalation model: State clearly what the path of escalation is, in the case of a dispute. This ensures that someone who may not agree with a rule cannot just go around you to a manager and get approval there. The final escalation point should always be the Service Owner for the entire SharePoint Service (and I really like this to be the CIO)
– Exception: If – for some good reason – someone is excepted from a specific rule in your policy, it should be written in the policy itself. Often this is done as specific rules, but sometimes people choose to have a special list for these exceptions. The important concept here is that an exception is only valid until the next validation of the entire policy. Then the exception should be re-evaluated and therefore no exception can be open-ended.
– Mandate: Since the individual owners of policies and Managed Systems – from my experience – can be challenged on the mandate they have to enforce policies, it is important to state clearly, who has given you this mandate. This is essentially the end of the escalation path – the Service Owner – who therefore also need to be informed of every change made to the policy.
– Validation frequency and last validation: For the policy as a whole – and for the individual rules in the policy (both are important) – you need to document what the validation frequency is. A good recommendation is using Daily, Weekly, Monthly schedules, as this makes it easy to extract a global task list across the SharePoint Governance practice, but it can be anything that fit your needs. Also, note the date when the last successful validation was, so you can automate creation of tasks inside your calendar – or the calendar of the people who will control individual rules – as this will be a huge help for you to stay compliant.
This is the end of the Polices & Control article. You should now be ready to start building an operational SharePoint Governance Practice. The principles and tools I have told you about will be helpful to you, but try not to start too big. The most important thing is to get the practice going, and then add more systems, policies and controls when you have a consistent practice and are able to uphold the level of quality you are aiming for.