Getting a handle on IT costs by eliminating chargebacks?

A recent article on CIO.com listed recommendations from Gartner analyst Ken McGee on cutting costs and improving the tracking of the expenses that remain. In all, McGee outlined 16 items:

1. Measure IT projects against the CEO’s priorities and see if they match.
2. Look at how the company makes money and compare that to the projects that IT is working on, and terminate support of projects that will not improve the income statement.
3. Abandon CIO priorities that do not directly support the CEO’s priorities. The CEO’s priorities are predominately revenue-related, where CIO priorities are mostly cost-related. An example might be a CIO who is focused on improving technical infrastructure, versus a CEO who has set a priority of being more open and collaborative with customers. McGee’s advice is “to end those discrepancies.”
4. and 5. These two are combined: Stop recommending IT mega projects. “You don’t have the money,” McGee said. Instead, discover the weaknesses in the existing portfolio and where investment is needed, he said.
6. Make people accountable for IT spending. Have business units acknowledge, with a signature, the ongoing cost of an IT service they need.
7. Terminate applications that aren’t delivering value. Gartner estimates that operating expenses can be reduced by 20% by 2014 by decommissioning applications.
8. Stop the practice of putting all enterprise spending within the CIO’s budget. It obscures the IT cost of business units. “The CIO ends up being a pinata for the entire organization,” McGee said.
9. IT organizations need to create processes that prevent “surprises,” which disrupt the business model. McGee introduced this point by showing the cover page of the Borders Group bankruptcy filing. It took that company three years to respond to Amazon’s Kindle, he said.
10. Eradicate ” cloud -a-phobia.” The number of organizations that will deliver 100% of their IT services internally is over, said McGee, but there remains a stalling phenomenon.
11. Abandon level 1, 2 and 3 tech support, where the more complex the problem the higher the skill level sought to address it until it reaches the people who built it. Calling a high level of support is like calling an automaker to pull the person from the assembly line who built the part to fix the problem. “This is what we do every single day in IT,” McGee said. Most application staffs are oversized to compensate for the interruptions, and operations staffs are undersized because of their co-dependency.
12. Cancel most IT chargeback systems, which take an extraordinary amount of effort and expense to charge back what is a small amount of revenue.
13. Stop seeking competitive bids. Most companies keep their existing vendor. “The number of people who absolutely terminate their network services contract, for example, and go to a new carrier is a very small universe,” McGee said. The multi-step RFP (request for proposal) process is ineffective and time consuming. Instead, users should reach out to a consulting firm or to their peers for insights into the competitive landscape.
14. Stop holding onto unfunded projects and send them back.
15. End discrimination against behavioral skills and social sciences. Social networks and contextual computing will require training and people with new skills to augment IT skills.
16. Abandon IT’s unbalanced support between the front and back office, which might lead to a “back office CIO” and a “front office CIO.”

While there’s a wealth of debate in that list, I found item 12 interesting when compared to the others highlighted above. How does one balance costs and benefits after killing the system that allocates those costs out? Item 2 contains two obvious fallacies: first, I’m fairly certain that support of the payroll system doesn’t “improve the income statement” (yet who’s willing to propose killing it?) and second, without being able to accurately identify costs of initiatives, how do you calculate an accurate bottom line? Item 6 has the same problem; how do we have a business unit acknowledge their costs if we do not quantify those costs? Item 7 suffers from the same issue as well. I’m all for retiring applications that have outlived their useful life, but without hard numbers on the costs, how do you determine your savings? For item 14, if we’re not charging back for projects, when we have an unfunded project, to whom do we “send them back”?

I’ve saved item 8 for last. I heartily agree that having all IT spending in the CIO’s budget will make it extremely difficult to determine how much of the costs of IT are attributable to the various business units. One way to alleviate this problem might be to have those business units budget for their needs and then have the provider (internal or external) bill them. Of course, that might break down when you kill the system which actually bills the business units. I am at a loss for how someone could put those two items in the same list.

One of the best reasons for charging back IT costs is stated in a January 2007 CIO.com article by Mark J. Denne:

If IT is to be perceived as valuable, it has to have a price. Usage-based chargeback is the best way to build a price-to-value relationship for IT services, and it is one of the cornerstones for running IT as a business within a business. As long as IT has a solid understanding of its operating costs, it can use pricing as a strategic tool for improving alignment with the business by giving executives better understanding and control over IT resources.

McGee’s item 6, acknowledging costs, is insufficient. Having the business units actually bear the cost is key. When the business unit is actually paying for services received, it becomes invested in getting value for its resource usage. Project cost overruns that affect your own bottom line are much more likely to get your attention than when they impact someone else’s budget.

Another advantage is making IT services fungible (within the limits of the enterprise’s architectural standards). Although this may not sound like an advantage at first blush, in the long run it works in the favor of the internal IT organization. It forces that IT organization to become both customer-focused and cognizant of the need to provide demonstrable value. When the business is put in the position of choosing an internal IT provider rather than being forced to use them, then the relationship dynamic changes. Both parties then have a vested interest in working as partners.

But Chuck Darville says chargeback helps him run IT as a business. “We look to see if someone can do IT better, faster and cheaper,” says Darville, technology planning director at Southern Co., a consortium of five power utilities in Atlanta.

…

Southern’s approach is driven largely by IT’s desire to offer market-competitive products and services. IT managers benchmark products against those of third-party vendors to “ensure that our internal IT offerings are the best deal for the company,” Darville says.

For example, the cost and quality of a network service performed internally would be compared with outsourced services available from providers such as AT&T Corp. or Sprint Corp., he says.

(from “The Chargeback Conundrum”, Computerworld 2/14/2005)

What you want to avoid is passing on costs without any sense of control on the part of the user (emphasis added):

Ultimately, chargeback is meant to prod users into changing their behavior. If a chargeback system fails to accomplish that, it’s a failure, no matter how good the accounting is. Chargeback is wearily familiar to Keith Kaczanowski, vice president of process improvement at Brady Corp. of Milwaukee, a manufacturer of signs, labels and associated printing equipment. “If all you do is reshuffle costs within the company, then chargeback probably isn’t worth it,” he says. “But if you think that people will make better decisions by being forced to confront the cost, then there is value.

“We used to charge $X per person per year, but found no one changed any decisions,” concludes Kaczanowski. “Instead, they just grumbled about a perception of low value. So now we don’t charge out at all.” It was, he adds, “pretty much a consensus decision. A lot of our IT expenses turned out to be for enterprisewide activities, servers, WANs and enterprise applications. Taking it back does a better job of matching where the decision is taken to where the costs are.“

(from “Budgeting – Chargeback for Good or Evil”, CIO.com 3/1/2003

McGee’s rationale for ending chargebacks is that they “take an extraordinary amount of effort and expense to charge back what is a small amount of revenue”. However, over a third of his points involve getting a handle on costs so as to manage them more rationally. This would appear to be an argument for improving systems to capture costs rather than eliminating them. Automation, which an IT shop should be familiar with, should reduce the expense. And while it costs money to track expenses, at the end of the day, attempting to run an organization (IT or otherwise) on intuition rather than information may well turn out to be the most expensive option of all.