Goals of an IT Financial Model: TBM Part 5

In the first four articles of this series I've talked about the necessity of building a complete financial model of IT that depicts as accurate as possible the true cost to support products and services. It should be based on consumption, mapped to a service catalog, and 100% defensible.  In today's installment I'm going to move from concept to practice, sharing the specific goals I outlined as I began this effort at AOL.

Goals of AOL's IT Financial Model

1. Most Financially Transparent Organization at the company
   I lead with this goal to be provocative, it is always the first goal I talk about when I introduce this model to new people. For an IT department to begin the conversation with this goal sets the tone of how serious we are about delivering the model. Of course the finance department should also be transparent, the desire is not to offend the corporate finance team, but rather to open the door to challenge my bold assertion. Stating this so plainly forces an attention to detail and accuracy that will be the foundation of the model, namely, realistic and verifiable data.
2. Represent The Real Cost of Technology
   You might think this is redundant to the first goal, however, I think it is important enough to emphasis in a totally separate goal. When you first introduce people to your model you will have the additional burden of convincing them this is all based on accurate data. Data they can see and manipulate, put through the same formula you did, and get the same result. You should expect, and even encourage, challenges to your model. In fact, often times you'll find ways to improve it from these dialogs with a business unit general manager or finance team.
3. Provide Value
   You want a model that is concise, can be tied back to product and business decisions, and ultimately can be used as a mechanism to make better decisions. You want to avoid the piles of metrics you may have that do not support these goals. The purpose is not to overwhelm with data, it is to deliver the key metrics that a non-technology decision maker can understand and influence.
4. Map Costs to a Service Catalog
   Your service catalog should be an inventory representing the services you provide back to the business. In AOL's case we defined 21 specific service lines (examples: Offline Storage, Security, and Public Cloud). Each entry in your service catalog will be a consumption based service that you can then invoice back to each business unit based on their usage. You will need to identify the metric(s) that will be used for the rules of the model for each service entry.
5. Be 100% Data Driven
   The rules inside your model should be based on data. Avoid the tempting yet arbitrary divisions of cost often used to split a shared service among business units. Identify the consumption based metrics for each service in your catalog, even if they seem rudimentary at first. You can always modify your model as you progress and you will avoid the pitfalls of making arbitrary divisions of cost.
6. Limit Caveats
   You should strive for a simple explanation of your service catalog and your model. The less you need to add caveats about how the model works, the rules that make up the consumption, and any exceptions — the more easily your model will be embraced. We learned this lesson the hard way. Initially we had some large caveats given the way assets were mapped to cost centers. Until we solved this, we introduced confusion and we wasted a lot of time clarifying this point over and over again. It is best to solve the underlying reason for the caveat rather than carrying around the explanation.
7. Hit Your Monthly Deadlines
   Once you've established a rhythm to your invoicing or showbacks, it is paramount that you hit the target each month. If you slip, you are sending the message that this isn’t as important as you initially made it seem. Just like your corporate finance team have timelines for closing the monthly books, now you do too.
8. Drive Accountability
   After all this is really why you started down this path. You want decision makers to have the right data to make better business decisions, leading to better products and services. You are arming them with crucial data. You ought to plan to do some analysis of the data initially as well, to demonstrate the value and find some wins that would have been missed before you created this model. In our monthly invoice, we show the delta for each service from the previous month's usage.

Setting goals and defining the reason you are building a complete financial model of IT will ensure you keep focused, provide guardrails to check your model against, and provide good talking points as you introduce others to this work. Also, as this Forbes article points out, writing down your goals is good practice anyway.

In Next week's article, part 6, I'll continue the practice focus and show you AOL's conceptual model and a sample output that represents our monthly invoicing.