Menu
Menu
How to make IT allocations work

How to make IT allocations work

Why have allocations at all? And if we do have them, how do we make them work for IT instead of against it?

"Allocations are killing us," a CIO friend recently said to me.

I knew what was coming, but nonetheless I asked why. He responded with the usual three complaints:

Number one: Every year, clients complain that IT costs too much. They claim that their share of the allocations is unfair and that they're subsidizing other business units. (They all say that. Go figure the maths). Occasionally, they demand benchmarking or outsourcing studies to try to prove they're paying too much. Countless valuable hours are lost justifying why IT costs were apportioned as they were.

Number two: Clients attempt to micromanage IT and tell my friend how to run his business. It's completely understandable. Allocations are, essentially, taxation without representation. We fought a war over that, didn't we?

Of course, nobody likes being unable to control costs, especially in this finance-conscious megacorporation. Naturally they attempt to gain back some degree of control. They examine IT's overhead and challenge every investment in innovation and infrastructure.

Perhaps the worst example of this behavior was when my friend attempted to establish an account-executive function to improve client relationships and IT's strategic alignment. Clients fought it, saying they didn't want to pay for it in their allocations. Imagine telling your vendors that you want them to take the cost of their sales force out of the price they charge you!

By the way, those same clients expected regular account reviews. And they complained that the IT department didn't understand their businesses. But they didn't want to pay for the account reps who would do exactly that. Sadly, this issue became so politicized that my friend postponed the initiative.

Number three: Clients didn't understand what their allocation bought them. They knew it was something to do with desktop computers, network services, applications hosting and so on. But the details were fuzzy.

Their response was to be expected. "Hey, we gave you all that money," they said. "Now we get to ask for anything we can dream of all year long. And it's your fault, CIO, if you can't deliver infinite products and services for a finite price! We paid for desktops-why are ours three years old? We paid for e-mail-why are we limited in storage capacity? We paid for applications hosting-why can't we increase transaction volumes by 20 percent?"

The IT department had implemented service-level agreements (SLAs) with the hope of limiting IT's liabilities (a.k.a "managing expectations"). But despite a bureaucratic dance every year that produced piles of paperwork, clients went on expecting lots more than IT could possibly deliver.

So the question is, why have allocations at all? And if we do have them, how do we make them work for IT instead of against it?

Why Have Allocations?

Why do people impose allocations, when they invariably lead to such troubles? The reason generally cited is cost recovery. The corporation wants to associate all costs with the various business units to measure their respective contributions to profits.

From an accounting point of view, this might make sense. It might even make some sense to spend lots of time and money working out a complex formula to try to make the allocations more accurate by relating them to business units' utilization of IT's products and services.

These allocations are not chargebacks or fees for service, where charges result directly from specific purchase decisions. Allocations are high-level formulas that distribute cost pools, and trying to make them accurate is like trying to make a silk purse out of a sow's ear. Nonetheless, to whatever degree of accuracy people wish to pay for, allocations do succeed at the accounting objective of assigning IT costs to business units.

From a governance point of view, however, holding business unit leaders accountable for their bottom lines and then imposing a tax they can't control is begging for a fight. Of course they're going to quibble about costs and attempt to micromanage the CIO. Their bonuses are on the line! Meanwhile, allocations as "taxes" don't encourage either IT or its clients to reduce IT costs or align technology spending with business strategy.

The bottom line so far is that allocations make the accountants happy while costing a lot of effort and creating a lot of controversy, with no positive effect on actual costs or IT alignment.

How can we make something positive out of a mess like that? It takes a mind shift, followed by a change in the mechanics of calculating and managing allocations.

A New Mind-Set

First, the mind shift. The usual way people think about allocations is as a price paid for a bundle of products and services. But despite all the efforts to define SLAs, the exact content of that bundle isn't entirely clear. What's more, business strategies are dynamic, and clients' requirements change during the year. Getting too specific isn't the answer, because it can damage the IT organization's agility and alignment.

Instead, think about an allocation in an entirely different way: as a prepaid account-money put on deposit with IT at the beginning of the year in order to buy products and services throughout the year.

Viewed as a prepaid account, an allocation creates a checkbook owned by clients, albeit on the books of the IT department. Using the money in that checkbook, clients can decide which products and services they'll buy. True, much of that checkbook may be used up right off the bat when clients agree to annual SLAs for specific "keep the lights on" services. But they'll understand where their money is going. They'll feel in control. Indeed, they'll be in control.

In this new paradigm, allocations no longer look like taxation without representation. They're simply a way to introduce predictability into clients' IT spending. But if clients want to cut back on their allocation, they're free to do so. Of course, then they'll have a smaller checkbook to manage, and they'll have to decide what they're not going to buy.

Treating allocations as a set of checkbooks, rather than the price of a fixed bundle of services, gives clients real control of what they buy from IT. Allocations resemble chargebacks, but without going as far as turning the money over to business units to spend as they please on corporate IT or on alternatives such as decentralization, outsourcing or trips to the Bahamas.

The impact is profound. Giving clients meaningful control of their money wipes away much of the controversy. In fact, when this new paradigm is implemented, I've heard of clients saying, "My allocation is too small!"

New Allocation Mechanics

To make this paradigm shift work in practice requires two mechanical changes:

First, IT must calculate its rates-the full cost to shareholders/taxpayers/donors of each of its products and services. Full cost means not just direct costs but also a fair share of all indirect costs, just as vendors do in their pricing.

This means submitting a budget that forecasts the cost of proposed products and services, not expense codes like travel, training, licenses, etc. A budget by deliverables (in ITIL, it's called "service costing") helps clients plan how much to put in their budgets for their IT allocation. It also means extracting from the numbers in the budget a set of rates (a price sheet) that tells clients the real cost of their requests.

Second, IT must implement some form of checkbook accounting. I say some form because this can range from very simple to very complex.

On the simple end of the spectrum, annual SLAs can be deducted from the checkbook at the start of the year or in equal monthly increments. Projects can be subtracted from the checkbook balance at the planned rate, without costly time cards and infrastructure utilization accounting.

If you want more accuracy, you can pay for more sophisticated utilization metrics, an invoicing system and the integration of clients' checkbooks with the general ledger. As an organization evolves in this direction, it readies itself for true chargebacks. But it doesn't have to go that far. Allocations may be retained, since they still provide predictability and reduce accounting and administrative costs.

Take a Step at a Time

If this vision intrigues you, I encourage you to take a step at a time. The first step is to know the full cost of your products and services. This alone will do a lot to build understanding and trust.

The second step is a simple form of checkbook accounting.

Then, over time, as clients learn to trust IT and its cost calculations and to better manage their checkbooks, more dynamic governance processes and greater accuracy in invoicing can evolve.

Take a step at a time, but first, get the direction straight. Remember, an allocation is a prepaid account, not a bill for a predetermined bundle of services

Join the CIO New Zealand group on LinkedIn. The group is open to CIOs, IT Directors, COOs, CTOs and senior IT managers.

Join the newsletter!

Error: Please check your email address.

Tags costallocations

Show Comments