Cost of Software: Calculating this metric is can be dependent upon how you have calculated your cost of operations. If you included the costs of help desk software and network monitoring software, accordingly, in your operational service cost, then you won’t be allocating here. However, if you choose to focus operational costs solely on non-technological resources and allocate all software costs in this bucket, then you will need to track the allocation of a percentage of all software used to deliver a particular service to the TSC.
It will probably simplify your life if you go with the former approach over the latter since it will be a burden to track the entire software dependency tree for all services you deliver. In this case, the only software costs you will be required to track is new and renewal of licenses, training, etc. for software costs directly related to the delivery of a service not captured in the delivery of any other service.
Note the value of service boundary modeling in this equation. If it turns out that two services should rely on the same software, then you have the option of building and packaging a service around that software and centralizing the costs for it there instead of attempting to manage discrete allocations. Also note that we are describing the packaging and delivery of the software as a service—this is focused on the usage, SLA and metering—not delivering software services—software with an exposed API.
Cost of Risk: Now that you are delivering an economically measurable entity—the service—you can assume that there’s a cost associated with that service being down, breached or exposed. While you can avoid including this cost in your projection for your TSC, if it should occur, then your overall costs for delivering the service could skyrocket. This is a bit like letting it ride on black on the roulette wheel. As long as you don’t hit red, you’re ahead, but one red can wipe out all your gains. Certainly risk projections can have a significant impact on your TSC, but over time, the accuracy of your TSC will become respected by the business as a reliable metric they can count on to run the business.
Billed Usage: Through billing we get to focus on the expected value of all of the above costs to the business. Determining an appropriate unit of billing may require the assistance of others outside of IT, like marketing, sales and accounting, which is a great opportunity to socialize what IT is doing with the business in a way that is inclusive of their input, but not specific to their needs (which means they’re working with you not looking at you as a hurdle). Obviously, your unit of billing should be relative to the overall value of the service and incorporate the aforementioned costs.
For some, this billing may be accounted for through a chargeback mechanism, or as some like to note “funny money”, but the importance of having billed usage as a metric should not be undervalued. For one, say your company wanted to acquire this capability from an outside service provider, this metric would allow executives to compare the costs of providing it internally over acquiring it externally. Additionally, this metric will tell you if your service is being valued and used by the business. If you’re running a service in the red, then you should re-think the purpose and approach for delivery of this service.
Here’s quick example that illustrates that even if you outsource all the above costs, the TSC will give you an accurate picture of what it cost to deliver the service and help you determine in a normalized way the optimal Cloud solution for your organization.