Service Based Costing masquerades as a dry ITIL accounting concept, but it’s secretly a powerful tool for driving high IT customer satisfaction. To attract and keep customers, most vendors focus on things like quality products, friendly service, and on-time delivery. Certainly, these are essential, but when I really want to win one of my internal customers’ trust and appreciation, I hand them an invoice.
Consider these two custom software development scenarios:
Scenario A: The vendor writes elegant code. Implementation goes smoothly. Then the customer gets a one line invoice for 3,000 hours of labor, twice the amount they expected. The vendor can’t explain the overrun.
Scenario B: The vendor’s code is fully functional but has some annoying bugs. Implementation is successful, after a bumpy start. Then the customer gets a two page bill for 3,000 hours, right in line with the original estimate. The detailed invoice itemizes the various services provided (analysis, development, project management, testing, training) and the cost for each.
Which customer would you prefer to be? Vendor A clearly doesn’t understand his costs and is headed for a lawsuit, whereas vendor B will retain a referenceable customer and a tidy profit.
Of course, profit is not the goal for government IT. We just need to cover our costs. Rather than pricing and billing mechanisms, cost recovery for government IT services is often either avoided entirely (IT is subsidized by administration), or takes the form of a crude chargeback formula (IT budget is allocated proportionally across customers on a per-PC or similar basis). Plus, many of us have a monopoly as IT provider for our own agency. With neither profit motive nor competition, there is little pressure to invest in accounting methods to support Service Based Costing. Yet, I would argue that market-style pricing and billing are mandatory even for public sector IT.
I owe my current employment, in part, to my predecessor’s failure to understand his costs. His internal customers were dissatisfied for a variety of reasons, but chief among them was their perception that IT wasn’t providing good value. They felt they paid a lot of money in chargebacks, but still weren’t getting their needs met. The CIO couldn’t defend his existing chargebacks to customers, so asking for more money to enhance service was out of the question. Unhappily for him, these failings created a vacant CIO position for me to fill.
During my second week on the job, I met the Director of Health and Human Services, my biggest customer. He expressed his dissatisfaction with his trademark southern passion. “IT is my million-dollar baby,” he said, “I pay over a million dollars a year in chargebacks. Where the hell does all that money go?” It quickly became clear that if I couldn’t explain IT chargebacks to his satisfaction, he was going to boycott central IT services and hire his own IT staff. That was the beginning of my journey toward Service Based Costing eight years ago.
At the time, I knew little about ITIL, and nothing about its emerging vision of Service Based Costing. I just knew I needed to justify my chargebacks. Fortunately, years of private sector experience in product management and technical sales led me instinctively to the same place ITIL was headed. I had to break IT’s budget down into services customers would recognize, necessary services like desktop support, file storage, and email. Then I had to show customers the linkage between those services and the chargebacks they paid. In other words, I had to define products, price them fairly, and sell their value.
That would have been easy, except that the budget I inherited was essentially monolithic. Expenses were highly aggregated into a few line items and most of the IT budget was in a single business unit. In other words, all IT services were blended together in one big bucket. The total cost of that bucket was allocated across all internal customers, apportioned simplistically according to the number of PCs they each had. There were no services defined, no association of costs to services, no linkage between who pays for a service and who benefits from it.
I immediately began spinning off non-core services. I created separate cost centers (business units in the General Ledger) for services that only benefitted one customer department, like a line-of-business database, so that I could group related costs and bill just that beneficiary directly. Then I broke outcore services like ERP, GIS, and telephones. Each service got its own GL business unit to group costs and an appropriate pricing model to fairly charge beneficiaries. The goal was always to tie price paid to value received, such as phone system costs allocated by number of handsets, or payroll system costs allocated by number of employees.
Within a couple of years, I had 25 separate IT business units, each representing a specific service or group of related services. A few years later, the costing model became a nested hierarchy, with internal IT services (like servers and storage) used as inputs to customer facing services (such as ERP). This hierarchy added complexity, but ultimately made budgeting easier and service pricing much more accurate. My team has recently helped me expand and refine our service based budget, so that it now reflects our entire service catalog, tracking the true cost of nearly 100 separate services so that I can defend the price of each individually.
The effect on customer satisfaction of running a service based budget was profound. Now I could show customers exactly where their money went. Even the former Assessor, one of IT’s harshest critics, couldn’t argue with the new system. I walked him through every line item in his chargebacks, after which he grudgingly admitted, “I still don’t like the total, but I can’t disagree with how you got there.” He might have preferred to pay less, but there wasn’t a single service on his bill that he was willing to live without.
The move to Service Based Costing is not trivial. It can take a substantial investment of time to develop the necessary accounting tools. But the payoff for our team was big. I no longer hear complaints from customers about paying too much. Instead, conversations are about exactly which services they want to reduce to trim their bill, or how much it would cost to add a new service they want. More often than not, we are expanding service rather than scaling back, and IT has continued to thrive even in lean budget years. Best of all, I love talking with my customers about their IT bill because I know the conversation will increase our alignment and boost their appreciation of IT’s value.