Confessions of a Reformed Bean Counter

Written by David Crouch

Dear Reader,

I’ve been a bad, bad boy! It’s true, under this calm exterior lurks the phantom of a former life – the menace of a pseudo-accountant who valued IT by counting the nuts and bolts. 

Like many people, I fell sideways into the IT profession. However, unlike most techies I know, I was never a tinkerer. I started in IT finance at a large university-hospital. To be completely fair to myself, I was never a CPA (though I did work with many fine representatives of that noble profession). CPA or not, if there was one thing my colleagues and I did well, it was counting the widgets – even if we didn’t know what those widgets did or how they fit together.

Counting Widgets

The widgets we counted consisted largely of the hardware and software that could be traced back to a recent invoice or to an expense line item in a monthly financial statement. In some respects, this was straightforward.

When it came to the bigger widgets – servers and blades, switches and hubs, PBXs, and even the mainframe (yes, we still had one of those!) – aggregating the upfront cost was barely science and far from art. These larger items often were intended to last for at least several years, and the calculus between cost and useful life meant they could be capitalized as assets and depreciated over time on our balance sheet.

Even the smaller items were eminently countable (even if we did not always know where they were located or who was using them). Printers and fax machines, laptops and monitors, desk phones and soundstations, were commodities that could be inventoried and expensed.

Software was shackled to its own set of nuances like licenses of varying types, difficult to track, though often subject to vendor audit. Depending on the size of the software, costs associated with upgrades and maintenance, while predictable, were not always known by Finance in time to budget appropriately.

The “Good Ol’ Days”

Salaries, in aggregate, were well known. Allocating them back to the appropriate functional teams’ budget, however, became increasingly difficult. In some cases, salaries were split amongst departments – a vestige of the so-called “good ol’ days” when in order to fund a new position, departmental directors horse-traded with each other and made back-room deals to share the salary expense of a new employee. (O.K. It wasn’t as nefarious as it sounds, but it makes for a great mental image.) In other cases, split salaries resulted from employees who performed cross-functional roles. For example, it was easy to allocate salary when only telecommunications technicians serviced telephone lines. But as VoIP technology was introduced, a combination of telephone techs and net techs collaborated to service the phone lines, the latter also working on non-telecom tasks.

What to do with secretaries who toiled for multiple departments and projects but whose time was difficult to appropriate? What about matrixed employees whose time was apportioned between operations and project tasks? At one point, my own salary was shared amongst so many different departments that my name did not appear as a line item under my own department’s budget but appeared, it seemed, everywhere else. This should have been as good an argument as any for a raise; but sadly, none was forthcoming. (For more on this, see my colleague’s article, Learning to Share.)

Ready to take this a step further?

Start laying the groundwork for your future IT Costing endeavors with our free templates!

Felicific Calculus and Black Boxes

Despite the trials and tribulations, all in all, we made tidy work of our felicific calculus of Accounting, Budgeting, and Costing. Through the magic of our modern-day philosopher’s stone, our ERP system, we could document most expenses and transform them into timely reports. On the budget side, we could have done a better job of predicting (we were probably too conservative in some areas and too optimistic in others. Costing and chargeback were relatively simple but subject to questions of fairness. Is the business being charged the right amount? Are costs shared appropriately amongst business units? It is also the case that we probably did not fully capture our costs plus inflation plus growth. Even so, we were still “in the black.”

The big issue was showing value to the customer. Being “in the black” was just not good enough. To our customers, IT was all too often a “black box” of unintelligible costs – until something broke, of course. Then there was agita over spending money to fix it.

The business wanted alternatives. They would ask us — How much does it cost if we do X instead of Y? That’s if they even knew alternatives existed. Our funding executives would ask, is IT efficient? What value does IT bring to the business? Does IT have the right amount of technological capacity to meet business demand? Enough staff to support critical systems? How much is software really costing us? Why is the Security budget so high, and is it even appropriate to question it? In an environment where lives are on the line (healthcare) and privacy is paramount (higher education), our answer to these questions was often a resounding “No. We don’t have enough of anything.” Nobody wants to assume the risk of under-capacity, under-performance, and security vulnerabilities.

The truth is we didn’t always know whether we had enough of any given resource or how much any particular offering really cost. On one occasion a senior business officer at one of our colleges asked me to break down network costs per capita for her school. I could certainly tell her what IT was billing her school for Networking. But I was hard-pressed to give her an honest or accurate answer in terms of what Networking really cost. The best answer I could give was my best guess. In order to give an accurate answer, I needed to know the head-count of the school in question. That was easy enough to obtain. I also needed to know the full cost of the Networking Service. We had a Network Service department and corresponding expense reports and budget. So, at some level, we made an attempt to aggregate costs. But did we really capture all the costs associated with Networking? We could be reasonably certain that our hardware and software costs were accurate. But what about those servers that were slated to be retired? Did that ever happen? Then there was that fiber run that supported three schools on the same campus. Remember those net techs who also work on telecommunications support and the secretary who supports four directors and six functional departments? How do we account for their salaries?

To paraphrase my colleague, Andy Rivers’ blog post, Show Me the Money, when IT simply shows the costs of the components complete with a prodigious “Other” category, the conversation between business and IT is a nonstarter.

Dear reader, I confess, our felicific calculus was not so happy after all. There must be a better way!

Beyond Components: Comprehensive IT Service Costing

Does all of this sound familiar? The preceding sections could have been titled, “A Primer in Cost Accounting.” In our case, we did well to gather most of the beans, but we still had no stalk (soup? Note to self: I’m totally killing this metaphor). While cost accounting is a good start and certainly better than no accounting at all, it does not accurately capture all the costs associated with IT. Moreover, it does not describe how much a service costs. We need to go beyond the ABCs (Accounting, Budgeting, Costing) of Component costing and learn the science and art of comprehensive IT Service costing.

Comprehensive IT Service Costing is far more than adding up all the costs associated with the hardware and software components. It is the total cost to deliver a service. This includes all the direct and indirect underlying technologies, the salaries of people who support these technologies and the process involved in delivering the service, facilities, and any other “overhead.” If it is required to deliver the service, it should be included in the service costing model.

At first glance, this description sounds like a more complete version of component cost accounting. What makes Comprehensive IT Service Costing different (and ultimately more valuable) is that services are defined around customer business value. A service is an activity or set of activities that helps the business customer to accomplish a goal or outcome. For example, “E-mail and Calendaring” is an IT service that the business can understand because e-mail and calendars are very tangible elements of any business professional’s daily life. In fact, it is difficult to imagine surviving a day without these. The business customer does not know or care about all the “widgets,” and staff, and process it takes to deliver “E-mail and Calendaring.” But they do care about the ability to send e-mails and make appointments. The “Email and Calendaring” service, in turn, could roll-up into “Unified Communications Services” along with other offerings like “Conferencing.” (The roll-up and categorization depends on what makes sense for your business).

Typical steps to take to develop a Comprehensive IT Service Cost model are:

  1. Work with the business to define vital business services that are supported by IT. 
  2. Trace all the hardware,software, and infrastructure components used to deliver that service. 
  3. Calculate the cost of all these hardware and software components (sometimes this might be an estimate or percentage allocation, especially when components are shared amongst business services).
  4. Determine the staff who directly support the service and aggregate the cost of their salaries.
  5. Determine staff who do not directly support the service or who support multiple services (e.g., secretaries, matrixed employees who spend part of their time working on projects).Allocate portions of their salary to the service based on a best estimate of how much time they spend supporting the service. 
  6. Determine other overhead costs required to deliverthe service (e.g., facilities, light, cooling, rental space, etc.) Allocate portions of the overhead cost to the service. 
  7. Estimate maintenance and upgrade costs of components, hardware replacement costs, salary increases, inflation, and any mark-up you intend to charge customers.
  8. Determine whether there are multiple tiers of the service (e.g., bronze silver, gold) and develop associated Service Level Agreements. Develop corresponding pricing based on the level of effort required to deliver
  9. Agree with business on reasonability of offering and rates. Publicize the service to business customers.
  10. For vital business services, conduct an annual health check to ensure that the service is still valuable to the business or whether any changes need to be made to the offering or the price.

Comprehensive IT Service Costing is not an easy process, and it can take a lot of time. Given the difficulty and upfront expense, many organizations give up before starting. It is worth the effort since IT can ultimately offer the business services it understands, sees value in, and actually needs. It also is a starting point for understanding how much a service really costs, where financial savings and opportunities can be realized, and how to create fairer chargeback models.

In subsequent posts, we will delve deeper into the anatomy of enlightened IT Service Costing, learn more about executing on the ten steps above, how to address infrastructure, salaries, and other shared costs, chargebacks, and much, much more. So, dear reader, please stay with this humble ex-bean-counter as he follows the road of redemption and enlightenment.

Looking for help with your IT Service Costing and Financial Management? We’ve got a team of consultants who can help. Learn how.

Originally published April 04 2017, updated January 01 2019