Occasional rantings about Dynamics CRM, Power BI, SharePoint, Office 365, Power BI and the application blocks in Azure. Intrigued about how people collaborate and data driven decision making. Taking the first small steps in machine learning. Putting all of the above in practical use to help companies "embrace" their customers

Wednesday, September 02, 2009

SharePoint Governance and best practices, some thoughts

I just finished a number of SharePoint governance workshops and so I wanted to share a number of thoughts on the subject.

1. The terms SharePoint governance and best practices are hugely overhyped.

I have had a couple of experiences now, where I have been called in by clients who have the typical SharePoint chaos. Things have gotten out of hand and as a result, key stakeholders started to lose faith, and the project team really felt the pressure from the powers to be. There were strong undercurrents of desperation to get things sorted, like… yesterday. Under these circumstances, they asked for help on “governance”. They needed “governance”, they must have “governance” and they spoke about governance as if it was something that a pizza driver can deliver to their door (and if it was not there in 30 minutes, it was free).

2. SharePoint is not a silver bullet and if you use it wrongly no governance plan can save you.

Project managers which are assigned the task of managing a project implementation which uses SharePoint will typically ask questions like “What do you mean SharePoint is not a BPM platform?”, or “How do I integrate SAP and SharePoint?” or “How do I do contract management in SharePoint?”. As you see the questions can be quite diverse. And the problem is, that the are answers will be quite diverse as well. There are a lot of design decisions you need to make - all with certain tradeoffs. You can start with out-of-the-box, add a layer of customization or even proceed to some serious SharePoint development. And then there is a huge amount of third party tools out there.

SharePoint is not targetted at a specific vertical or horizontal and if your company’s strategy is to always choose for best of breed and is able to support an enormous variety of platforms and applications – SharePoint is probably not a good solution. If your business really needs a 99% percent match for all of their requirements and can’t live with trade-offs – there is no other choice then greenfield development.

SharePoint is all about reuse and platform capabilities. Aim at leveraging the out-of-the-box functionality and when there is not match with the requirements try talking about the processes which created the requirement in the first place.

3. When talking about SharePoint governance and best practices make sure that your audience has a basic (to intermediate) understanding of SharePoint fundamentals

There is a lot of best practices regarding SharePoint infrastructure setup on TechNet and MSDN. So you can always point to those as a reference. It is however necessary that people understand concepts such as WFE’s, SharePoint web applications, site collections, etc … It is not that because you know SQL Server inside out that you also understand SharePoint inside out (allthough a thorough understanding of SQL is definitely a good thing). You really need adequate resources within your company which are sufficiently trained to support a SharePoint implementation.

4. Yes, … you will probably need some third party tools

People are always amazed by the fact that they will actually need some third party tools to make SharePoint meet the requirements of their users. Also when you look at SharePoint from a manageability and operations standpoint you will notice that there are some gaps that are filled in with third party tools (or other Microsoft products) – some questions you should probably ask yourself:

Did you think about antivirus when doing a SharePoint implementation?

What about backup and restore?

Did you take a look at the standard usage statistics. Are they sufficient for your needs? Remember that you need a feedback cycle to measure the success of your deployment so you will probably need some more elaborate statistics then the ones which are provided by SharePoint.

What about monitoring?

5. Keep the organizational culture in mind when thinking about governance

One of the best postings I read about this is Make SharePoint governance plans plain and simple which talks about companies which are considered icons and examples within their industry (or even accross industries). In his posting he translated some internal guidelines from PCL Construction – called Pool’s rules into relevant SharePoint specific statements – here are my 2 favourites:

Give encouragement and show appreciation … Providing encouragement and showing appreciation is especially important for fledgling SharePoint environments; participation and adoption are paramount to success. It’s also critical for ongoing success; consider your own population and develop a program that continuously provides encouragement and support to all communities involved. Make sure that you actually encourage Knowledge Sharing – for some thoughts on this topic – see Knowledge is power! So why share knowledge …

If you don’t have the funding, time, human resources or the budget to effectively create, deploy and maintain a SharePoint solution, don’t start one.

3 comments:

Re: point 4 - all those items are things Administrators would normally concern themselves with. The users will have different (unrelated) requirements - and yes, they're amazed that they might have to buy a third party product or pay for some development.

Good list of points, though - they're all very familiar to what I see.

SharePoint becomes an extension of the organization and its practices. If you place it into an organization with little structure and/or standardization, it will grow unstructured and non-standardized, and 3rd party tools become so important to control growth and implement standards.