SharePoint Governance Stream of consciousness
I love the whole open mic concept when talking with SharePoint people. For one, our community is full of incredibly funny people. In fact, it could be detrimental to your health to be sitting in the vicinity of Seb Matthews, Bradley Geldenhuys, Tracy Van der Schyff, and Alistair Pugin. I found myself in that lineup last year, and hurt from laughing (mostly at Alistair’s expense). It seems like every time I walk up to a small group of community members at a SharePoint event, I learn something.
At an event early last year, there was a conversation sparked by an attendee’s question of "What is governance and is it important?" It kicked off a heated discussion, and I thought it would be interesting to follow up with some of the participants of that discussion via email. Weighing in on the topic were Paul Swider from OnClick Solutions (@pswider), Chris Riley from CloudShare (@hoardinginfo), and Ant Clay from Soulsailor Consulting (@soulsailor).
[Chris] Governance is a must. The trick I’m finding with pitching this to the market is there is a general lack of understanding of “what” governance is, “who” is responsible for it, and “why” put in the effort. I believe that the definition of governance is in the process of changing. Governance used to be a task of write, publish, forget. The way governance should be treated is as a collaborative process of building guidelines that make SharePoint meet and exceed goals during implementation phase, and ensure adoption is successful and appropriate in the production phase, and looking into the future extended into other applications. To me, governance is just as important a part of a SharePoint project as project management or requirements documents. They are all a part of the blueprint for SharePoint success. Spend the right amount of effort upfront, save effort and stress later.
[Ant] I always think back to the Latin definition of Governance, which is ‘To Steer’. Just like sailing, you have a starting point and a destination. Governance is the course you sail (very rarely straight-line and unaffected by external influences) to get to your destination (goal). My view is that you will for 9 out of 10 projects end up with ‘SharePoint Celery’ without an appropriate level of ‘governance’ throughout the lifecycle of the technology project, i.e. covering the technical assurance (make sure the IT platform is running), the business reasons (What & the Why) the project itself, and then the ongoing running, maintenance and, of course, continuous improvement back into more projects.
[Paul] Governance might be one of the most overused terms in the SharePoint community. Governance exists at many levels in different organizations. There is corporate governance, legal governance, project governance, system governance and many more. SharePoint governance might fall under system governance. It is a small piece of what might be a much bigger effort. Most often SharePoint governance discussions are a sub-topic of system governance, specifically one of many systems in our organization. We can begin to break governance issues down to small efforts.
[Christian] This topic is really starting to mature in the SharePoint space. Paul, I agree that governance is overused and many times applied generically to anything that has to do with administration, optimization, and the ongoing management of SharePoint. I agree with the idea that this is just another facet of a broader, company-wide governance policy. Your corporate, legal, project, and system governance models have absolutely nothing to do with SharePoint, but SharePoint governance should be traceable back up to the higher-level initiatives. The specific governance activities are much more targeted than your corporate initiatives, of course. Yes, there is governance in place to manage our ERP system, but how that is managed – and the specific policies and procedures adopted by the stakeholders – may look very different than what is adopted by the SharePoint team and its stakeholders. Maybe we’re just arguing semantics here, but I do believe that SharePoint governance – as with the individual governance strategies surrounding every system – should have a direct relationship with the overall strategy, including end user adoption.
[Paul] I am not in the camp which believes governance drives user adoption. Some believe If you don’t take time to create a plan for user adoption, you may not be successful in getting users “on board” during a SharePoint deployment. I might submit this enabling process is more a requirements gathering and training effort. I am not convinced it is a good idea to combine requirements gathering and training plans with a SharePoint governance document. If training and adoption require governance I might make this part of my overall project governance as they are requirements of many successful projects of any type. Organizations tend to confuse process orientated artifacts like implementation plans, project plans, user requirements and training plans with governance. Take a moment to Bing! “project governance –SharePoint”, “corporate governance –SharePoint” to see examples of each. If a SharePoint deployment project fails due to lack of governance it is often a failure to control project governance, not SharePoint governance itself, which leads to failure.
[Ant] I agree that Project Governance (in my mind, working out what the business want, and then creating and delivering that solution) is the key, but SharePoint Governance — if it’s around site structure, IA, meta data, security, site creation, etc. — can still make a successful project fail in the long run.
[Paul] An interesting exercise might be to Bing! your governance topic without the word SharePoint. For example “taxonomy governance –sharepoint”. If you get lots and lots of good information, examples and third party systems, then it probably should have it’s own governance separate from SharePoint governance. This may be confusing as you may implement your taxonomy using the SharePoint platform however others might consider taxonomy to be a ubiquitous system or business process as it spans many levels of the company. Another good example might be Bing! “business intelligence governance –sharepoint”. Ask any large financial company if their business intelligence governance falls under SharePoint governance. You may be surprised at the answers you receive.
Of course you should plan and document SharePoint governance as needed. I believe this process can be as simple as identifying responsibilities and roles to maintain uptime, performance and compliance. Like a content type governance should be hierarchal. We inherent governance attributes from our corporate, legal, and system governance then simply add the SharePoint structure. The tricky part may be identifying these existing governance artifacts and processes. You may see others in your organization use different titles for governance, like business process model, system planning, corporate strategy, etc.
Ideally, your SharePoint governance document will be very concise and clearly stated for executives and information technology workers. Remember if you can’t enforce a governance process perhaps you shouldn’t
document it. Don’t make your company liable by creating a detailed governance plan that can’t be enforced. Don’t get paralyzed in this governance process. Do it and move on. It will require the least of your effort and, of all the tasks you perform during a deployment the governance document is the easiest to change.
[Ant] I agree that a Governance document is easy to change, but I/we don’t see governance as an end-point document, more of an on-going force (with some deliverables, but not the core focus).
[Paul] If you don’t have corporate, project and system governance why would you consider SharePoint governance? Have the “powers that be” focus on these efforts first and when they finish add your bit about SharePoint down at the leaf level. Structuring corporate governance around any software product seems ineffective at best.
Know the organization, understand the existing business processes and existing governance and then provide a solution that empowers the organization to compete. If governance doesn’t already exist then don’t delay the need for a swift effective solution with bureaucratic governance which most likely can’t be enforced anyway.
[Christian] I agree with this – do what makes sense for your organization. Don’t roll out governance for the sake of having governance marked off on a checklist. More policy and procedure and bureaucracy makes sense only when the demands of the platform require it.
[Chris] I also agree that Governance for the sake of Governance is not the goal. This is the old definition. The new definition does incorporate sustained user adoption etc. For example, a recent governance plan I wrote had a topic on super users. How to train them, how to get them to promote use of SharePoint, and use them as first line of support. This is something that far extends a published plan. To me the objective of governance is less about the written documents, it’s more about the exercise of critical steps to achieve success. The document only serves as a record of those decisions, and a starting point should something be address. Paul, what I hear you saying is that it’s a big waste, and to me this is the fault of the people creating the plans, not the methodology. While making SharePoint conform to the organization as it is today would bypass the need for some governance, the problem with this is the organization is modernizing bad processes without even understanding their value. Instead, I see SharePoint improving business processes. The other aspect of governance that cannot be ignored is how it plays into compliance, and legal issues. Having a plan, being able to justify a system is the biggest battle that must be won when an organization is in the face of litigation, compliance or an audit. The governance plan documents how a system is setup, how it needs to be, and how an organization adheres to that system rather than chaos.
[Ant] A good quote from Wikipedia is “…IT governance is about the stewardship of IT resources on behalf of the stakeholders who expect a return from their investment…” So intrinsically any governance should be tied back to the business.
Governance is the facilitation of the measurable business outcomes the organization needs to deliver to meet its strategy and vision and the alignment of a solution (Culture, People, Process & Technology) to those outcomes and the subsequent delivery and on-going continuous improvement of the solution to the (continuously evolving) organizational strategy, vision and associated business outcomes. Assurance is the People, Process & Technology aspects of keeping the technology platform delivering the IT service that the ‘solution’ requires in order to deliver its measurable outcomes. Governance and Assurance are like ‘yin and yang’ you need both for harmony and success.
[Christian] It is easy to get caught up in the language surrounding governance. There are hundreds of books written on the subject, and no shortage of opinions on the web. At the end of the day, every organization needs to come to an agreement on how they define it, and then to stand behind their definition as they build out their top-down strategies and their bottom-up requirements. I don’t believe there is a "right" answer to what governance is that can be applied to every company, but the fact that the topic causes organizations to do more thinking about their systems, and then to put into action plans that are more holistic as to how people use those systems — it’s a good thing.
