Who Pays? Decomplexifying Technology Charges

Simplicity is a great virtue but it requires hard work to achieve it and education to appreciate it.

—Edsger W. Dijkstra

By Chris Hennesey and Phil Le-Brun, AWS Enterprise Strategists

As a CIO or CFO, have you ever questioned how IT costs are allocated within your business? Ever been overwhelmed with the complexity and lack of transparency? This is one of the pet peeves we frequently hear about as AWS Enterprise Strategists. With organisational complexity growth far exceeding business environment complexity, the shell game of moving money around internally can add to the burden. A combination of non-technologists seeing technology as a dark art and rising investments in technology provokes demands for “spend transparency.” The resulting technology accountability, or cost allocation model, prompts a fundamental question: who should pay for IT? Should those requesting technology work be held financially accountable for their investments to drive the right behaviour, or should the technology team massively simplify its cost allocation by holding costs centrally as many finance and marketing departments do?

It’s a “rock and a hard place” quandary in many organisations. And there aren’t many options for how to organise costs. The two go-to models for technology are charge-back and show-back.

Charge-back methods apportion costs based on how resources are consumed purposefully for business gain. Taken to the extreme, though, the charge-back model would require a team using an Amazon EC2 instance provided by the infrastructure team to pay for not just the AWS instance charge, but the CTO’s organisation’s labour, monitoring tools, and even the amortised one-off cost for initially creating the EC2 configuration, for example. No wonder this approach gets viewed as an “IT tax” imposed by an internal monopolistic service provider. This charge-back approach can create resentment while discouraging cost optimisation within IT. The ensuing debates waste time when speed is key. Corporate consumers of technology services either reluctantly pay IT or sneak off and create their own (often worse) solution.

The show-back model, on the other hand, keeps costs in IT, reducing overhead and debate and creating consumption patterns that can help the entire enterprise beneficially use technology. However, this doesn’t make it immune to poor behaviour. Holding costs within IT can encourage a free-for-all with requests. Why wouldn’t a business function ask for their latest brilliant but poorly researched idea to be made real if they aren’t paying for it? Similarly, why spin down that test environment if it’s on IT’s tab? Decoupling requests from costs can reduce accountability spending money wisely, especially given that nearly half of functionality developed is never or barely used. Fixed headcount and change request–driven contracts force IT to prioritise these requests, creating a different kind of resentment. With IT taking orders of increasing cost, this situation makes for uncomfortable budget season conversations.

Putting aside some of the complexities businesses can face due to legal, contractual, or external billing reasons, a dollar spent is a dollar from which you expect a return, regardless of which charging model your company uses. So how can we simplify our thinking on IT expenditure so that we maximise value and minimise bureaucracy?

We believe it is critical for IT service consumption to be fully visible and accountable. At minimum, organizations must ensure that the various products and businesses they invest in are viable by understanding their full P&L—beyond just IT. Consumption data can help inform how to price products for customers and clue you in on which businesses are thriving versus barely surviving. We both have experience with simplistic consumption-based modelling as well as more convoluted models. Striking the right balance of incentivising the right behaviour while minimising complexity can be a challenge.

What we offer here are some tips on how to address the discussion of cost allocation. These are based on three principles: transparency of spend and value, accountability for outcomes, and maximising time spent on competitive activities.

It Starts with Education

If you accept that the aforementioned financials models are meant to promote the right internal behaviour, debating them needs to start at the top of your organisation. It’s easy to lose this audience by slipping into confusing details and terminology. It might be tempting to rely on simple explanations and analogies, but often, such explanations obscure the fact that technology is pretty complicated. C-suite discussions should cover how and what technology charges today, how technology spend alone does not drive an ROI, and the importance of experimentation and data to drive continual, visible value delivery rather than jumping straight into multimillion-dollar investments informed by hunches. Explain how the cloud and agile methodologies enable the C-suite to have more control over their organisation and empower them to manage costs in line with ROI.

Differentiate Fixed and Variable Costs

HR typically doesn’t charge a per-person cost for HR services, nor are utilities such as electricity typically allocated to different departments. Similarly, IT needs to be recognised as having a fixed cost of providing services when charging for individual or prorated costs causes unnecessary complexity. “But what if Jonny deliberately breaks his laptop?” you might say. Well, you don’t charge Jonny a facilities fee to discourage him from damaging office furniture. Incentivising the right behaviour comes down to culture and data visibility, not creating complex, burdensome rules to protect against the few potential bad actors.

If there’s a business demand to portion out these fixed costs to business units, find the simplest, fairest metric possible to allocate spend and determine when this metric will be reevaluated. Think through the intended and the unintended behavioural consequences of each model, striving to align cost with value. For instance, costs can be allocated based on the percentage of revenue a business unit generates, their headcount, or unit of consumption such as number of factories or restaurants. We’d argue, though, that sites or headcount don’t directly relate to value and would be harder to justify fairly.

Allocate variable, true technology costs (such as compute power and storage) to initiatives in an automated, timely manner with an advertised unit of consumption. Additional direct costs of providing this service such as support should be included, but avoid adding periphery costs such as “management” or hiding the cost of an existing overpriced contract across multiple products.

Contextualise Costs and Benchmarks

Regardless of the allocation model, there will always be pressure to prove an investment’s value to the organisation. Internal service conumers may balk at the sticker price of of a ready-made solution like an AWS program and choose to create their own, not realising that building software from the ground up is often more expensive and hides costs. If a customer buys a hamburger from a McDonald’s, they don’t pay just for the raw ingredients. They also pay for other overheads such as power, labour, and marketing. And customers have a choice of where to buy food, creating competitive pressure on pricing. It’s critical to have transparency about costs and why they are necessary, regardless of who provides a service. It’s also a good idea to provide benchmarking information to show how IT helps improve specific aspects of the business. Offering multiyear guidance on peripheral costs helps creates certainty, as well as its own pressure to continually optimise spending.

Contextualise costs when possible. Compute charges that have doubled in a month will provoke an unfortunate knee-jerk response. But show that business revenue has tripled and the compute costs are necessary to maintain the pace of progress, and suddenly IT’s a hero. Adding to this advice on what internal customers can do to reduce costs further, or what IT is doing to achieve this, creates further confidence.

Are You Worth It?

Inherent in this advice is a need to honestly assess the value of your services. IT may love their single sign-on (SSO) service, for example, but at what point does the cost outweigh the value? We’ve seen situation where charging models become a shell game. A service may not provide value so costs are shifted to other products because, after all, who wants to reduce their headcount or contract values? Be a business leader here, not a defender of silos and their budgets and the breakdown in trust this creates.

Make Doing the Right Thing Easy

One of the Amazon philosophies is to treat dependencies as defects. Dependencies are removed so product teams can be autonomous and create velocity, not slowed down waiting for others. Similarly, with costs, be clear from the C-suite down about what is a mandatory standard and why, such as security guardrails. It might be tempting to turn every IT program into a must-use service. In some cases, such as an SSO service, mandatory use helps create a great customer experience. In other cases, it is inefficient and consumes increasing amounts of technology resources, thus limiting the ability to go after higher value-add activities. By all means, make services available, but think deeply about which need to be “mandatory.” For nonmandatory services, internal customers will either learn that building and maintaining equivalent services is no cakewalk and hence come back to IT’s service, or they’ll come up with a better service, one that IT can adopt and provide to the broader user base. It’s a win-win scenario.

Strive to make the complex simple for your organisation with a focus on spend efficiency and effectiveness. There is a time and place for both allocation models in the life-cycle of enterprises. Customizing for the specific needs of your organization as well as focusing on simplicity, clarity, and driving the right fiscally responsible attitude is critical.

—Chris & Phil