CIOs and IT managers have been told many times they have to run their departments more like a business. Brian Chan is about to help them with the hard part: charging for their services.
As the vice-president and CIO of human resources consulting firm Morneau Sobeco, Chan says he has considerable
experience developing “”chargeback”” systems during his previous roles with two Canadian banks and within the Ontario government.
This fall, Chan will lead a two-day course on cost allocation best practices offered through the Canadian Information Processing Society, which will also include presentations from CCL Industries, TD Bank and University Health Network.
Chan spoke to Computing Canada recently to discuss some of the issues surrounding chargebacks and how he’s handling them in his organization.
COMPUTING CANADA: Why do so many organizations seem to struggle with developing an IT chargeback system?
Brian Chan: A couple of banks I worked for went through very elaborate processes, and it’s debatable that all the complexity was worth it. Then you’ve got
the model of the government, for example, where the IT budget is just a budget and then you spend a budget. The challenge is there’s no relevance to the business. The dollars you spend, you may not be able to go back to which line of business that IT expenditure is attributed to. My personal belief is there is a balance between the two extremes.
CC: What’s the best way to get started?
BC: Take Morneau Sobeco for example: Our IT chargeback process starts with our IT investment plan. The IT budget is just one of the byproducts of the investment planning process. In the plan it defines operational components — a good chunk of our business is in outsourcing, so a good chunk of the budget is our operating budget where we don’t get an additional dollar of new revenue, but we still have to keep the current customer base happy. So there is that base budget, and then you get into the more variable aspect, which is the project aspect.
Projects would range from getting a new client and maybe doing an implementation. In the context of a bank, for example, it could be a new product that would attract new revenue. You start from dividing those projects into what are the revenue-generating ones, what are kind of process improvement ones, and what are longer-term, strategic projects.
CC: Is it easier to do chargeback on the revenue-producing projects?
BC: Not necessarily. I think they’re all equally challenged by how you measure the benefits accruing from these projects. This is basically project cost accounting. You have to be able to fairly and equitably attribute the costs to that project, so in the end the benefits could be measured, whether we originally estimated what the project’s going to cost from an IT perspective.
CC: Is the problem that the industry hasn’t been doing a better job of determining the return on investment for IT projects?
BC: I think the mechanical tool, whether people use something as rudimentary as a spreadsheet or some sophisticated chargeback system, is probably less relevant. Most companies don’t go after measuring those benefits and claiming those benefits.
If you take, for example, a project that promised a two-year or three-year payback with certain benefits that made the business case to start the project, nobody goes back and sort of makes the line of business accountable and tells them, “”OK, we have to take this out of the budget,”” or that they expected this much of an increase in revenue. At most of the companies I’ve worked for, two or three years later, management changes, and people forgot about their projects and they would just write it off. There was a common flow in the project environment where, when the project’s finished, everything is forgotten.
The approach I advocate normally — though it’s difficult to implement, and I can’t say we’ve done it perfectly as yet — is to do a sort of revolving project costing, on a 12- to 18-month basis.
CC: So doing chargeback on a project-by-project basis or sort of a standard policy built into the way the business runs?
BC: Well, for it to be fair, you have to do both. I used to run a point-of-sale, credit card technology business, and there used to be lot of projects to improve the business, but there was also a major chunk of the costs related to the transaction process. That was the operating budget. One approach is to begin super-simple and embed all of those costs and just have one chargeback mechanism by a certain unit. I think splitting it is more relevant, because you know exactly what is charged to the operating asset. Otherwise you have no way of measuring how efficient your operation is.
CC: But if you’re working in a business that has never worked like that before, how do you make that transition relatively smoothly?
BC: What we’ve done at this company is we started introducing a full recovery kind of model. When the IT budget comes out of the planning process, we figure out a simple mechanism of charging back to the line of business to recover the costs. We started very simply, so that you don’t need to be a cost accountant to understand how we’re charging back.
In the last two or three years we started evolving that so it becomes more and more equitable, and each one of the charges has more relevance to the line of business. I think we’ve done it in the last three-and-a-half years to the point where it now is a truly user-pay kind of model, so that when a line of business chooses to go after a piece of business and spend a lot more on IT, we can basically tie it back to the revenue they generate, or the cost reduction or cost efficiency/ improvement that they gain.
CC: Would you recommend that for other firms?
BC: It works for the size of company we are. A lot of the larger organizations have a lot more complex tools to manage the IT budget and the chargeback process. In the end, they spend a lot of human hours feeding that chargeback system and increasing the costs of the IT department.
CC: Is there a way to strike a balance in this situation?
BC: The more time you spend on it, the more complex it becomes, the more difficult it is for the consumer of the IT resources to understand. Then you can generate a lot of resistance from the user community because the more complexity, the stronger the feeling that there’s no transparency in the IT budget. I’m a true advocate of running the IT department as a glass bubble. At the end of the day you’ve got to account for what you spend, and the only way you can gain support from the people who consume the resources is that they understand they’re being fairly charged and that you’re not playing favourites with other parts of the business.