SharePoint Governance 3.0
‘SharePoint Governance’ means a lot of different things to a lot of different people and for the most part they are all just a little bit wrong!
This post is the start of the global re-education of what ‘SharePoint Governance’ really is!
Governance in the SharePoint world is most definitely the ‘new black’, it’s what the cool-kids on Twitter are talking about, disagreeing with and almost fighting over!
But do they really know what they’re talking about?
Everyone has their own opinions about what Governance in a SharePoint context is and I believe that each of those people is looking through their own lens based on their individual anchor bias (a form of cognitive bias), some examples include:
- SharePoint Governance is about architecture, infrastructure, disaster recovery
- SharePoint Governance is about Project and stakeholder management
- SharePoint Governance is about Information Architecture and security
- SharePoint Governance is about telling the users what they can and can’t do.
Each view is perfectly valid, but is not the whole story and in some cases I would venture to state that focussing on just one of these ‘views’ is more detrimental to the business than ignoring governance completely!
Let me explain what I mean; firstly Wikipedia states:
The word governance derives from the Greek verb kubernáo which means to steer and was used for the first time in a metaphorical sense by Plato.
Based upon that definition, let’s unpack this using a sailing analogy, especially as I am SoulSailor!
If you have any appreciation of sailing you will realise that there’s a host of factors that influence your success in racing a sailing boat around a course, these may include:
This is not unlike designing, implementing and maintaining a SharePoint platform. But to be successful at sailing you have to focus continually on all these aspects (and more), so let’s look at what happens if you focus on only one of those facets?
I’m a great Sailor, years of experience – I’m sailing faster than the competition, but I’m sailing fast, in the wrong direction, I don’t follow the right course, I miss out marks, I get disqualified!
I’m an awesome tactician – Tactically I’m sailing really well, but I’m not looking at where the wind is and everyone is sailing faster than me and I didn’t notice that island… bump…sink…fail!
I have a fast boat – My boat is the newest, most expensive, fastest and is full of go-faster gadgets, but I don’t know how to sail very well, the sails are flapping and I’m not sure where I’m going…. the boat goes very slowly, I didn’t finish the race, I’m not a winner!
As you can see in sailing, just concentrating on one thing isn’t going to guarantee you success and in SharePoint land it’s exactly the same.
Very few people (in my opinion) are looking at Governance as a whole i.e. what is Governance in the context of the SharePoint Platform, what I’ll call for the purpose of this and future posts ‘SharePoint Governance 3.0′.
Based upon our experience and thinking on this, we feel that ‘SharePoint Governance 3.0′ is made up of five equally important elements in no particular order:
- IT Assurance
- Project Governance
- Information Governance
- Technology & Business Alignment
- Continuous Improvement.
[Note: this approach has evolved since my original blog post]
If we implement SharePoint spending equal amounts of focus on all of these elements, then we can truly say that our SharePoint environment is being effectively governed and is delivering measurable business value.
Let me take a few minutes to prove to you that these are all equally important elements of SharePoint Governance 3.0, by painting some scenarios where we’ve missed out one crucial element:
Scenario 1 – No IT Assurance
This one’s easy… Power-cut, no back-up taken for the last few weeks, CEO has lost his revisions to the annual report he is giving tonight.
Or what about poorly spec’d server farm, organisation is in rapid growth, system performance is poor and the users can’t do their jobs effectively.
So, we can agree we need IT Assurance – Check 1
Scenario 2 - No Project Governance
If there’s no project governance, and you don’t know what you’re meant to be delivering or why, then how will you know when the project ends and is successful? Upwardly cycling project costs, expanding time-scales and no measurable business value? Your boss is not going to be happy and just wait until Finance hear about the money you’ve wasted!
So, we can agree we need Project Governance – Check 2
Scenario 3 – No Information Governance
Your SharePoint project is successfully delivered (thanks project governance). The business stakeholders and end users are now let loose on the platform (in conjunction with the right level of change management and training). But we didn’t have time to define an Information Architecture, we haven’t been tuning the search results and everyone’s getting frustrated about the meta data they have to add to the content. We’ve tried to measure business value, but the results aren’t what we were expecting, content is all over the place, no-one can find anything and people just aren’t using SharePoint any more.
So, we can agree we need Information Governance – Check 3
Scenario 4 – No Technology and Business Alignment
Our IT department wanted SharePoint so they’ve implemented a new intranet on the platform, based on the features of the old technology solution, like-for-like.
We’re a growing business and our business model and working practices have significantly evolved over the last few years. Adoption of the new platform is poor, we can’t hit the ROI figures we presented to the board and some teams are complaining that they are less efficient.
So, we can agree we need Technology and Business Alignment – Check 4
Scenario 5 - No Continuous Improvement
Our project life-cycles are typical of many other businesses. Business problem identified and then wait a few months while we plan, gather requirements, design solution, implement and then we find that the requirements have changed…Business problem identified and then wait a few months while we plan, gather requirements, design solution, implement and then we find that the requirements have changed…Business problem identified and then wait a few months while we plan, gather requirements, design solution, implement and then we find that the requirements have changed…
This approach isn’t solving our business problems, it rarely delivers business value and the ROI of the SharePoint platform isn’t being met. The business aren’t bought into the IT changes we make, they don’t see the value of SharePoint and business cases are becoming more demanding each time.
So, we can agree we need Project Governance – Check 5
As we can see a SharePoint project is likely to fail, cause organisational issues, not deliver business value or require loads of financial investment to maintain if we miss any of those 5 essential elements, therefore it makes sense that Governance is very much like my sailing analogy and the reality is that in our context (SharePoint) is defined as follows:
The Definition of SharePoint Governance 3.0 is…
A guiding, facilitative and inclusive approach to implementing the SharePoint platform and delivering measurable business outcomes that support the organisational strategy by combining:
Now we have a definition can we just get on with delivering great technology that changes the way people work and facilitates organisations achieving their ‘Big Hairy Audacious Goals’!
This post was originally posted to the 21apps blog: