Blogger: Craig Roth
Larry Cannell recently mentioned a case study of a corporation that had created a chargeback system for SharePoint. It fostered some good internal debate that I have captured in this posting. This large corporation used a chargeback system for SharePoint in which fees are assessed per SharePoint site and rolled up by department. This was considered a big improvement since it forced measurement and understanding of usage. But IT wound up granting a lot of exceptions (the article doesn't say why) so they are thinking of charging by storage volume instead.
Larry Cannell commented previously in this blog about how a chargeback system drives (distorts) user behavior. For example, charging per site discourages creation of subsites, but charging per GB of storage encourages moving files to other storage systems. The ultimate impact is that people expend energy consolidating sites or moving files around to save money and the total cost of ownership for the SharePoint installation is hobbled. Also, subsites are very easy to create and may not take many resources at all, so a fixed fee per subsite could be way out of sync with actual costs incurred.
Bill Pray commented that the exception granting process is very important. Organizations should define an exception process because rigid application of chargeback rules in every case can be detrimental to the growth of the system.
My advice has always been that, especially during the critical early phase of rolling out a tool that thrives on network effect (portals, collaborative workspaces, social software, IM, etc.), you don’t want to disincent usage. In the case of a portal, that means you don’t want to charge per site set up or by the amount of content being stored. If you do that it causes squirreling behavior – carefully watching your usage, using free siloed systems where possible, or having a shadow presence that links to off-site content that won’t be shared.
The correct approach in my opinion is to charge a fixed fee based on number of potential users or something like that, regardless of usage. It’s accordingly been called a “tax”, but the result is to encourage usage since you’re paying for it whether you use it or not and may as well get your money’s worth. And the more an organization uses it, the more value they get for their tax, hence encouraging usage rather than discouraging it.
Once the system is well established and network effect (aka snowball effect) keeps it rolling on its own momentum, an organization could potentially change the chargeback mechanism to go from tax to usage, although I would probably set thresholds that indicate abuse (like dumping multi-gigibyte multimedia files into the Sharepoint repository).
I should add that we recently completed a set of interviews with clients about how the recession is impacting their approach to communication, collaboration, and content systems. One discovery was that the companies we spoke with that were very successful with their chargeback systems also had barriers (generally legal and regulatory) that prevented business units from going around IT or forcing them to compete against outside providers. In cases where business units can write a check to an outside collaboration provider as easily as they can to IT, chargeback systems have to be approached with much more care (e.g., subsidized, regulatory conformance policy for external alternatives, rates that change over time due to externalities).
Internal markets for services follow many of the same rules of economics that an open (external) market does which should be addressed when designing chargeback systems:
- Increasing price (or adding a price for something that was formerly free) decreases demand for your product and could increase demand for substitute goods. All too often, e-mail is considered a free substitute for blasting out information, exchanging documents, and having discussions.
- With a product that gains benefit from network effect (e.g., online gaming, a dating service, trading cards, collaborative workspaces), decreasing sales decreases demand since each customer will have fewer peers with which to utilize it.
- Just like in a real market, when the central authority (e.g., federal government or central IT) tries to shape behavior by adding rules and regulations, this often distorts behavior as participants shift usage patterns to exploit inefficiencies in the regulations (e.g., edge cases, loopholes, misalignment of incentives).


Comments