Well, here it is budget season for many. And for too many, it’s a frustrating game with little value added.
Meanwhile, I’m hearing a lot of buzz about the ITIL concept of service-based costing. Have we figured out the connection between that and an effective budget process?
For those few IT organizations that really understand and embrace service-based costing, budgeting is a valuable business planning and client negotiation process. But to make it work, they’ve had to extend the concept well beyond the limited view of ITIL.
Why Service-Based Costing Is Invaluable
With service-based costing, organizations calculate the full cost of their products and services. They propose a budget that includes not just the expected “keep the lights on” services but also the many things clients have requested and the many good ideas their IT entrepreneurs generate for better serving the business.
More by N. Dean Meyer
In the process of developing such a budget, the managers define their businesses and their service catalogs. They forecast business volumes, both assured and speculative. Then they plan how they’ll fulfill those business scenarios, defining the staff, contractors and vendors they will need; the direct and indirect expenses they will incur; and the capital investments required. They set aside time and money for business improvements, customer relations and innovation. And they determine their prices.
From there, budget negotiations become a matter of deciding what the organization’s clients will and won’t buy. It shouldn’t be surprising to learn that their clients step forward (without any “training” or preparation) and defend IT projects. Yes, clients defend the IT budget!
And afterward, everybody understands exactly what the IT budget does and does not pay for. Service-based costing solves the notorious problem of managing expectations, builds a perception of the value the business receives from the IT budget and engenders trust through transparency.
Furthermore, knowing the cost of products and services is prerequisite to any sensible resource governance (for example, portfolio management or demand management) process. Clients need to understand how much is in their “checkbooks” and what things cost before they can meaningfully manage their demands.
In addition to a budget for products and services, service-based costing produces rates based on the full cost of IT products and services. These rates are the ideal benchmarks for competitive (outsourcing) comparisons.
An added benefit that’s of great interest to many CIOs is the impact of the process on leadership development. Organizations that do service-based costing find that the experience of business and budget planning turns IT managers into real entrepreneurs.
What Service-Based Costing Entails
Let’s be clear about what it really takes to gain these benefits.
First, although ITIL tends to focus on the services side of the business, and specifically the processes that deliver services to clients, the concept of service-based costing applies to every nook and cranny of an IT organization. We need to know the full cost of all IT’s products as well as services.
Second, and again despite ITIL’s biases, the concept is not limited to products and services sold to clients. It’s equally important to understand the cost of products and services sold to peers within IT. In fact, unless you account for all your IT costs, it’s impossible to calculate the real cost of clients’ purchases.
Let me give you an example. Infrastructure engineers spend a lot of their time tuning, repairing, enhancing and otherwise nursing the IT infrastructure, which, in turn, is used to produce services like network connectivity, applications hosting and e-mail. But remember that infrastructure engineers also spend time on applications development teams. If you lump all the engineer costs into the cost of those services, you’ll overburden the services (making them look uncompetitive) and underprice applications.
Like the infrastructure engineers, most groups in IT serve others within IT as well as clients. All costs have to be allocated accurately to produce a clear picture of what an application or service costs. Shortcuts — like putting all indirect costs in pools and assigning them directly to client products and services — introduce distortions, which in some cases turn out to be quite significant.
Also consider that, from a leadership point of view, ignoring internal products and services makes many important people feel like second-class citizens and misses an opportunity to ignite their entrepreneurial spirits.
What “Full Costs” Means
All costs must be associated with products and services. If any are left out, prices will be artificially low. Meanwhile, costs that aren’t embedded in prices have to be covered by an allocation or core budget, defeating the purpose of service-based costing in the first place.
Direct costs (labor and vendor costs specific to a project or service) are straightforward to assign. But there are four layers of indirect costs that must be allocated to just the right products and services:
- Unbillable time: A person’s salary buys, say, 40 hours per week. But, of course, not all of those hours are available to work directly on the products and services. Time must be set aside for holidays, personal leave, training, administration, proposal writing, client relations, process improvement, innovation and so on. These are just examples of the many unbillable activities that are necessary to sustain the business but not directly billable to a specific product or service. The cost of these unbillable hours must be embedded in the price of each group’s products and services.
- External indirect costs: A group spends money on tools, training, rent and other expenses necessary to stay in business. These, too, must be spread across the group’s products and services.
Internal indirect costs: When one group within IT serves another, the costs of that service must be spread into the receiving group’s products and services. For example, the costs of help-desk support for infrastructure-based services are embedded in the costs of the various services. Computer time for development may be spread into the products and services of the applications engineering group.
There are myriad cases of one group within IT supporting another, each representing an internal indirect cost. Rather than simplistically pooling these costs and assigning them to client-facing products and services, the costs must flow through this maze of internal customer-supplier relationships to wind up within just the right products and services, and in just the right proportions.
- Overhead: When a group within IT provides services to all its peers, the cost of that service is spread into everybody’s products and services. Examples include the time the CIO spends supervising IT; the IT business office that does finance, procurement and HR for its peers; and IT’s use of services like e-mail.
Once indirect costs are amortized, three types of products and services remain:
- Client costs: Products and services sold to clients. These include services that everybody buys from IT, like desktop connectivity and e-mail, as well as products and services like ERP that are sold to consortia of clients. Client products and services represent the bulk of the IT budget.
- Subsidies: Products and services sold to the corporation as a whole. IT is funded to deliver these services for the greater good — things that its competitors (such as outsourcing vendors) don’t have to do. This category includes products and services like policy coordination, consumer report services (like recommending standard configurations of PCs), and non-IT activities like participation in corporate task forces and community-action programs. These products and services must be priced in their own right, never embedded in the cost of client services. Otherwise, they would make IT appear uncompetitive.
- Venture costs: These are budget items like capital for infrastructure that enhance the IT business, akin to loans from a bank. Clients should never be asked to pay for IT’s infrastructure; if they do, they’ll think they own the servers and networks that IT manages and will fight any attempts at enterprise capacity management. Instead, the corporation should fund infrastructure, and the depreciation should be embedded in the cost of client services that utilize that infrastructure.
Once an organization achieves true service-based costing, its prices can be compared fairly to outsourcing, clients can be empowered to decide what they’ll buy, and entrepreneurs within IT can manage their businesses in a sustainable manner.
Whew, That’s Hard!
Doing a great job of service-based costing isn’t easy, and there’s a steep learning curve. Fortunately, it’s not something you have to do all at once. You can take a step and then add to that success over time.
As explained above, it makes no sense to define a step as doing service-based costing for a subset of the IT business. In that regard, it’s all or nothing. But the process can be simplified by cutting back on the level of granularity across all products and services.
The Full-Cost Maturity Model (FMM) that I have developed and which I summarized in a prior column defines five levels of detail of service-based costing. While ITIL tells you what to do, FMM tells you how to do it.
For those organizations committed to ITIL, developing a service catalog and service-based costing are generally on the to-do list. Let’s recognize that these are not independent efforts; they’re two outcomes of developing a budget and rates for products and services.
Service-based costing — defined in the comprehensive sense, not limited by ITIL’s biases — deserves to be a high priority on that to-do list. As a change initiative, it addresses many critical objectives. Implementing a full-cost model is implementing ITIL. And activity-based budgeting. And governance. And a culture of entrepreneurship, customer focus and teamwork.
Knowing the full cost of your products and services is the basis for sensible business planning, budgeting, demand management, benchmarking and investment decision making. It’s fundamental to managing an IT business within a business.
You can read a version of this article on the author’s website with links to other Beneath the Buzz columns, relevant white papers, books and other resources. Contact him at email@example.com