Transfer pricing: Behind the numbers

For a change of pace, I inserted my answers following each question in this letter from a reader we’ll call Troubled by Transfer Pricing. – Bob

Troubled by Transfer Pricing: Dear Bob, I’ve been enjoying your diatribes about transfer pricing (the practice formerly known as charge-backs) for ages now, and also routinely read chapter 9 (or was it 10) of your latest book where you talk about it. I completely agree, and my company is the poster child for dysfunction when it comes to the havoc that this transfer pricing model can wreak (and referring to your users as “clients”).

Bob: It was chapter 10 of “Keep the Joint Running: A Manifesto for 21st Century Information Technology,” and thanks for the opportunity to give it a plug.

[ Also on InfoWorld, Bob Lewis suggests there’s a bright side to transfer pricing in “Stuck with charge-backs, but not necessarily drawbacks” | Get sage advice on IT careers and management from Bob Lewis in InfoWorld’s Advice Line newsletter. ]

Troubled by Transfer Pricing: A few things I still stumble on, that I’m hoping you can help with. I know there is an answer, and it isn’t transfer pricing, but I would lose a debate should one occur with our finance people because I don’t know how to respond. Can you distill this?

— Only one business unit (BU) in our large enterprise uses the transfer pricing model, but from their perspective, everyone else is deficient. One common comment I hear is that every BU has the same basic costs for commodities like providing a user account and mailbox … but in the other BUs, those costs are just buried in the mix. The BU that uses the transfer pricing model provides a way to very clearly show how much the business spends on IT — that is, from a reporting perspective it is much better and provides more insight to the executive.

In a sense, I guess it’s true that the other BUs might not be able to say that they spend X amount to provide user account and mailbox services, because it just all comes from one big pot in each BU’s IT budget, so I’m not sure how to argue against them on this point.

Bob: To be more accurate, the transfer pricing model shows how much money they’re transferring from one corporate pocket to another, labeled “IT spend.” Whether it reflects what the company is actually spending is an entirely different matter, one that depends on how accurately the pricing analysts have done their work — which won’t be accurate at all, either. The way these things are always done is to allocate fixed overhead in some semi-arbitrary manner that distorts how actual costs behave by pretending that fixed costs are variable costs so as to facilitate their allocation.

If the executives want to know how much their information technology costs the company, the same analysts could answer their question by producing a report that shows them the answer, without adding the further expenses incurred by actually transferring money from one pocket to another and without building up the company’s silo walls — the main result of transfer pricing.

Troubled by Transfer Pricing: I also know per the above that it is an illusion that the amount the one BU charges for user accounts and mailboxes is just “the same, but visible.” I know they charge waaay more for them than the other BUs do. I guess this goes back to your points from the book about treating your users as “clients” — it ends up jacking up the price, but I don’t understand why that in and of itself would be the case?

Bob: Just a guess: They have to add in the cost of their pricing analysts. They also have to add enough margin to cover the possibility of guessing volume wrong, because once IT institutes transfer pricing, it has to break even. It isn’t a cost center anymore because it has revenue, but it can’t be a profit center because that would mean it’s overcharging. Thus, it has to find the exact, delicate balance, with just enough padding that it doesn’t come up short but not so much that it makes more profit than the company’s profit-making divisions.

However, I have heard of a case or two where corporate IT is the single most profitable entity in the enterprise. Draw your own conclusions.

Troubled by Transfer Pricing: In your book, you talk about how the answer for projects should be “no” or “when.” On the surface, this seems like something that is very hard to do in practice in a big company. IT in this company went through a phase where they constantly told the users no when they’d requests projects. The executives told them to stop saying no, so now there’s an elaborate and utterly dysfunctional queuing and prioritization system in place. That’s dumb, but I can also understand why it makes the executives uncomfortable. If the PMs have a finite amount of resources to work with, and they decide to say no to everything that they know they don’t have resources for, then almost everything will get a “no.” So how do you reconcile the two with the business that will just see IT as a roadblock?

Bob: Ah, I see the problem. IT has no business saying yes or no (or no or when) to anything. These are business decisions, and the business leaders should be responsible for deciding no or when for whatever projects are proposed.

Look at it this way: Every one of these projects describes not software to be delivered, but a business change to be instituted. If IT makes the decision, the CEO has delegated responsibility for deciding the company’s business change priorities to the CIO, which in my book means delegating company leadership.

That’s a strange decision to make.

Troubled by Transfer Pricing: Finally, you mentioned the U.S. military as an example of a huge organization that doesn’t use the transfer pricing model. So that I can dig into it more granularly, are there any case studies for this or for other businesses that are set up in similar fashion? The main view I get from people here is that you can run small businesses this way, but large, publicly traded companies can’t be. I know this isn’t right, but I can’t prove it.

Bob: To be more precise, I imagined what it would be like for the military to use the transfer pricing model to wage war. In a sense, the military does use it for provisioning, in the sense that it outsources a lot of this to firms like Halliburton instead of handling things with internal staff.

As for studies, if there are any, I don’t know of them, other than studies like Jim Collins’ Good to Great research, which make no mention of transfer pricing as a common factor in how great companies operate.

I’ll also say that large enterprises that try to simultaneously operate as holding companies while centralizing administrative and support functions like IT probably do have to use transfer pricing as a governance mechanism: By definition, holding companies make their individual business units the point of optimization and not the whole enterprise. As organizational models go, it’s something of a hash. In general, a shared datacenter can make sense under these circumstances, and maybe a shared corporate network (although different business units probably have different bandwidth, latency, and service level requirements). So far as application support is concerned, though, a shared applications group makes little functional sense, since it should be the business units that determine application priorities.

So what companies like this are trying to do is to have all business units “outsource” IT to an internal shared services provider so as to gain the economies of scale appropriate to their size; avoid the need for margins that an external outsource would require; and still accommodate the separate priorities of their business units without enterprise oversight.

Troubled by Transfer Pricing: Thanks in advance.

Bob: You’re welcome.

This story, “Transfer pricing: Behind the numbers,” was originally published at InfoWorld.com.