ITFM Cost Allocations: The Basics

[Bryan Blackburn]

Summary

It can be argued that IT Financial Management is an allocated view of IT’s cost base.  Costs are assigned to those activities that generate the costs, i.e. a cost driver.  Some costs are easy to assign using a driver whilst others can be difficult to determine.  In some instances, the cost driver data may not currently exist.  None of this precludes setting up an IT cost model. In fact, it may help IT get its house in order and understand what activities are undertaken that drive expenses.

Cost allocation matters as it determines the total cost of a business or service.  If wrong, the service could be under- or over-costed resulting in poor decision making.

Key Findings and Recommendations

Organizations allocate costs for a number of reasons, but primarily it is to calculate the fully loaded cost of offering a service or a product to enable better decision making.

In an ideal world, consumption and usage data are the best allocation drivers as these are based on fact which makes a cost model defensible.  However, we don’t live in an ideal world where one can use consumption data. Therefore, other allocation strategies have to be developed.

Cost allocations are complex, so don’t be afraid to use a simple allocation method such as an equal spread, these are more commonly used than one might imagine.  They provide a starting point to test the structure of your cost model and can be replaced over time as better allocation data becomes available.

When assessing cost drivers, certain principles can be applied when designing the model, these will determine how the costs will flow. 

It is recommended that the following should be considered when evaluating a cost driver:

1. From and To – Determine where the cost is flowing from and where it is going to.  This will help determine the appropriate cost driver, for example, accommodation costs could be allocated by the space occupied by each team.
2. Materiality – Consider the amount that needs to be allocated if it is a small percentage, then a simple approach may be sufficient.  The benefit of obtaining a valid cost driver may be outweighed by the effort required to secure the data.
3. Rationale – What is the reason for the cost driver?  Is it to provide cost transparency or change behaviors. There may be more than one suitable cost driver, which one is used depends on the desired outcome.

These three principles will help guide IT financial managers to select the most appropriate and defensible cost driver, but most importantly, explain why.

Analysis

There are only a number of ways costs can be allocated, each has their advantages and disadvantages.  No single cost model will use one single method but a mix.  As more data becomes available as time progresses, the cost drivers used in the initial cost model will change.

The simplest of all cost allocations is to even-spread the costs over a number of items.  This is a basic calculation and requires very little data.  For example, the total cost of servers is £1,000 / month, of which we have 100, therefore the monthly cost is £10 per server.

This uncomplicated approach does not reflect the actual utilization of each server.  Each server regardless of its size or power has the same cost which in reality is not the case.  Whilst this may not be the most accurate allocation method it does provide a solution when no data exists and allows a cost model to be built.  Too many even-spread allocations will render the cost model ineffective as there will be no reflection of actual resources consumed, so use sparingly.

More often than not, tribal knowledge of the machinations of IT exists.  These individuals will have undocumented information in their heads or in spreadsheets or on sticky notes dotted around.  Using these less formally documented facts an IT financial manager can allocate the costs using percentage allocations.  For example, based on many years of experience, some organizations have no formal data to assign servers to a business application.  The cost of servers could be evenly spread across all applications.  This might be appropriate to get a cost model up and running but in the medium term, it doesn’t support decision making. 

However, more often than not, service managers will know which servers support the applications they own.  If one server supports one application, its costs should be 100% allocated to the application it runs.  In some cases, a server may host more than one application.  If there is no application consumption data for the server, each application could get an equal share of the server’s costs.  For example, if a server runs both email and an instant messaging solution.  An IT Finance Manager could manually allocate each 50% of the server costs.  This approach could be replicated for all servers where service managers have this information.

This is a step along the data maturity path.  Whilst not perfect it will allocate the costs using local experience and knowledge making the allocations easy to explain and more defensible than an even ‘peanut’ butter spread.

Due to software audits, an organization may have a detailed understanding of its software costs and what software is used.  The licensing data allows an accurate allocation of all software costs to the relevant application.  As the data is robust it could be used as a substitute, even if temporary, to allocate server costs whilst the underlying server data is improved. Costs can be weighted using either other allocated costs or by data associated with the receiving cost object.

Another approach is to use the recipients as a weighting.  For instance, help desk—if seen as a service—can be weighted by the number of people in each Business Unit.  Another allocation strategy could be to apportion the help desk costs based on the total cost of a service.  This approach has the benefit that you are using the results of existing allocations.  However, by using the recipient approach it is assumed that the costs follow the same logic, which may not be the case.   

In this example, the help desk costs are effectively an overhead.  Everyone in each Business Unit is charged a fee regardless of how often they call the service.  This is not an uncommon allocation approach for help desk costs.  It allows colleagues to use the service as often as they want without any financial penalty.  This may enable IT to identify incidents or problems before they occur. 

If the total cost of the service is used to do the apportionment, then the service owner has a cost which they

If the total cost of the service is used to do an apportionment, then the service owner cannot easily target this component of their service’s costs.  Any savings made by a service owner would result in a smaller slice of the cost being allocated, but the size of the pie may not change. In this scenario, this would result in other services being charged more to compensate for the reduced share.

Finally, consumption and usage data, these are arguably the best allocation and the most defensible data to use.  Actual data takes out the emotion and noise that can be created by even-spreads and manual allocations.  Allocations are based on what has happened not what individuals think has happened.  These whilst the best are also the hardest to obtain and sometimes to use.

For example, an organization has a sales application.  The sales team has twenty identified users, each uses it a few hours a week to log their activities.  The marketing team has five users that are constantly utilizing the application to identify market opportunities.  How should the application costs be split?  Should sales pay 80% of the costs and marketing 20 %?  Sales could argue this unfair as they are light users of the application. 

Conclusion

All allocation methods have their advantages and disadvantages.  From the simple even-spread to the arguably more defensive consumption data.  What matters for each allocation rule are the three principles:

1. From and To

2. Materiality

3. Rationale

There is no right or wrong allocation method.  What is appropriate is determined by the desired outcomes and the current data available.

Once you know what cost allocation data you have and importantly don’t have then you can create a data roadmap.  This can be achieved by:

• Defining the desired end state
• Identifying the key data gaps between the as-is and the end state
• Ranking the data gaps
• Consider any dependencies
• List the tasks required to close the gaps
• Demonstrating some quick wins while progressing toward the eventual end state

The desired state will differ from organization to organization so when talking to your peers don’t be alarmed if they are using masses of usage data and you are not.  In the end, what matters most is do the allocations make sense for your cost model?

By: Sanjiv Sachdev