Well, here it is budget season for many. And for too many, it's a frustrating game with little value added. But there's hope.

ITIL version 3 references the concept of "service costing" or "service-based costing." For those few 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 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.

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 afterwards, 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 (or from allocations), and engenders trust through transparency.

Furthermore, knowing the cost of products and services is prerequisite to any sensible resource governance (a.k.a., 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.

And added benefit that's of great interest to many CIOs is the impact of the process on leadership development. These organizations find that the experience of business/budget planning turns IT managers into real entrepreneurs.

What Service Costing Is

Service-based costing solves numerous governance and client relationship problems. But 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 of 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 email. 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 over-burden the services (making them look uncompetitive) and under-price 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/services makes many critical people feel like second-class citizens and misses an opportunity to ignite their entrepreneurial spirits.

Full Costs

To be meaningful, 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 that project or service) are straightforward to assign to products and services. But there are four layers of indirect costs that must be allocated to just the right products and services:

1. 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/services. Time must be set aside for holidays, personal leave, training, administration, proposal writing, client relations, process improvement, innovation, etc. 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 list is available to readers on request.) The cost of these unbillable hours must be embedded in the price of each group's products and services.

2. 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/services.

3. 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 is 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.

4. Overhead: When a group within IT provides services to all its peers, the cost of that service is spread into everybody's products/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 email.

Once indirect costs are amortized, three types of products/services remain:

Client: Products/services sold to clients. This includes mass-market services that everybody buys, like desktop connectivity and email, as well as products/services like ERP that are sold to consortia of clients. These represent the bulk of the budget.

Subsidy: Products/services sold to the corporation as a whole. IT is funded to deliver these services for the greater good -- things that its competitors (decentralization and 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 imbedded in the cost of client services. Otherwise, they would make IT appear uncompetitive.

Venture: Budget items like capital for infrastructure which 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 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 which utilize that infrastructure.

Once an organization achieves true service-based costing, its prices can be fairly compared 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 is hard. Sure, the payoff is huge. But it takes lots of effort and a steep learning curve.

Fortunately, it's not something you have to do all at once. You can take a step, and then build on 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 its granularity.

What's Next?

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/services.

Service-based costing 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/services is the basis for sensible business planning, budgeting, demand/portfolio management, benchmarking, and investment decision making. It's fundamental to managing an IT business within a business.

Abstracts Free library

Books Speech abstracts

NDMA coaching/consulting services

UP.... NEXT PAGE....