Some weeks ago I was talking with a customer about components of a SharePoint Governance concept. Most elements are clear to most people on a general level. When I mentioned, that also commercial aspects should be considered, my customer was surprised, why it should be included. It is not the first time I had such a conversation.
In my Governance thinking commercial factors is an element in my five piece SharePoint Governance Kit.
So what are the reasons to include commercial factors in a SharePoint governance concept and what are those factors?
By the way such kind of Governance aspects are not limited to SharePoint, but to all kind of enterprise information systems, where you may have the need to govern the lifecycle.
So what aspects should be included?
- Cost allocation
- Service Level Agreements and Operational level agreements
- Build or buy decisions
- Contractor selection
Basically five areas from my point of view, so let me introduce them one by one.
Who pays for the whole thing or is it free?
Depending on your companies strategy, you may provide SharePoint services for free or charge your internal customers.
If you charge you customers, you need a proper cost allocation plan. This plan should give clear guidance what you charging plan is based on, whether it is based on site collections, web applications, content databases or something else. You can also use this tool to level wanted and unwanted elements and techniques just by price.
You also want to make sure that your internal customers will not out smart your system. So when you make them pay for each site collection, watch out for departments in your organisation that tries to run everything in a single site collection. In that sense make sure it plays well with all the other parts of your governance and please make sure your commercial governance rules fit your architectural decisions.
Service Level Agreements and Operational Level Agreements
SLAs and OLAs are important contractual documents you need to run your IT, no matter if its SharePoint or something else. You may want to make sure your customers know under what conditions they can rely on the service you are offering. But always keep in mind there will be situations, when your SLAs or OLAs does not reflect certain aspects or are in conflict.
What could be done here, is to create an overview and give your customers information, how certain action might influence SLAs. For example you may want to limit use of SharePoint Designer in your environment, but are not willing to turn it off globally because of some special requirements. So you can allow people use SharePoint Designer on their teamsite, but that would come with a degradation of SLAs. Make sure everybody understands that.
What ever you define here might influence your SLAs, sometimes tradeoffs are necessary. With such a properly designed rule set, you can make exceptions, but still have full control and confidence.
Build or buy decisions
Sometimes it is a good idea to build your own tools, sometimes it is better to buy them. Sometimes you like to buy or build something, that is already there, maybe only in a slightly different flavour.
By creating criteria, when to buy or to build things, you get more control on the evolution of your platform. Even if you do not want to come up with fixed criteria, yo may at least want to implement some kind of decision making process.
Licensing can be somtimes a critical issue. You may have provided SharePoint Standard licenses to everybody and Enterprise licenses dedicated only to certain groups or areas. In this section you lay out what licenses are used, what customization is possible and when the boundaries of a license is exceeded.
For example a small list for an online flea market for all employees is easy to create and cheap. If somebody comes up with the idea to enhance it with a small InfoPath form, this small and cheap thing suddenly requires an Enterprise license for eveybody in your organisation. Make sure those license based limitations are known by at least every site manager. Otherwise you may need to cut off functions.
Last but not least if you do have an enterprise size SharePoint deployment, it is very likely you also have some customization or custom development.
Everybody who does customization on your platform should understand your concept, architecture and governance rule set. You also want to make sure a certain level of quality.
You may also have some preferred, approved and already assessed contractors to do the job. So providing a list of approved contractors to your internal customers, may prevent your customer from hiring some guy to fix or build something and you will hopefully not end up with a whole bunch of contractors, messing around your platform.
So those are my reasons to include commercial factor in a governance concept. Even if you don’t think you need it, at least actively think about it.
Do you include commercial factors in a Govenance concept and what are those?