Eventual Consensus, Iteration, and Being Manic: A Map to Building an IT Financial Model: TBM Part 9

I hope the first eight parts of this series have started to make the case for providing cost transparency for your IT services. I believe this is essential for harnessing the technology differentiators that make a company competitive, shifting the conversation to be data-driven and about value, and act as a catalyst for overall business transformation.

In this article I will summarize the top 10 answers I have provided to others of this common, two-part  question:

"How do I get started, and what advice do you have after going through this process yourself?"

Find the Right People to Build Your Model

I can't stress how important it is that you dedicate time to this effort and find someone who is analytical, tailored to work with numbers, and who embodies the same spirit you have for spearheading this effort. It is critical that this person likes to pay attention to the details, can present well as you explain the model down the road, and is driven by finding and fixing inefficiencies from the data. This isn't likely a large team, yet I would argue that it is best if they can be 100% dedicated to this effort, your results will improve dramatically if this is their sole focus. As a reference, I have 1.5 people assigned to our initiative at AOL, they own the entire model and are a tremendous help with education and ad hoc data analysis.

Partner With the Finance Team

This likely goes without saying, your job gets immensely easier if you have the buy-in and support of the CFO. Your job gets frustratingly harder if you foster an adversarial relationship with the finance team. In our case at AOL, we have fantastic finance partners who leverage our model to make their jobs easier as well. It's possible that your work changes accounting policy or the overall finance rules and you will need their support. Better to have a strong relationship here at kickoff.

Begin with a CMDB

You have to have a foundation for the data to begin the model. I would strongly encourage using a CMDB where you can rationally start to formulate the groupings that are right for your business. In our case, each product and service at a GM level is logically defined. This is a whole level below our typical company segments, yet it was necessary to allow the data to be granular enough to find areas for improvement. The CMDB should contain the genetic makeup of your products and services, it will serve as the logic, overall, for the consumption based data and the rules of your IT financial model.

Document Your Service Catalog

You have to produce an inventory of the services you provide. When you are doing this work, think about the meaningful categories you would want to show on a monthly invoice for each business unit. In our case, our service catalog maps to our serpentine model, and are the line items that show on the monthly chargebacks to our GMs.

Start with Basic Metrics

You should start simply, for your own sanity and for those that you bring into the fold as this progresses. There will be plenty of time to improve each rule as you advance,  it is important that you simply begin. I like to suggest that you divide your entire all-inclusive IT cost by the number of servers you have as the very first step. This is a highly rudimentary way to begin, yet it is the perfect starting point. So much of your future model will still depend on server count, and it establishes the initial baseline of costs per server each month.

Iterate, Iterate, Iterate

It is far too daunting a task to think that you will fully map out every bit of data and the rules for unit consumption of every service you provide. Each month as you analyze the data and receive feedback from consumers of your model, you have the opportunity to correct and improve your initial assumptions. We spent 12 months in this phase, and we created many, many iterations of our rules. In some cases we opted for a far simpler approach to a rule. We made this decision by comparing a month's result of a rule done multiple ways. For example, it turns out that database table size was as good a proxy to our database support costs as rules far more complex that took into consideration transaction rates and data size. Rules do not have to be complicated, they should simply be trying to represent the costs of the real world scenario. If you try a rule definition one month and you hear or discover other ways to define it that are a better representation, change the model.

Eventual Consensus

This is a phrase I coined to give you permission to charge ahead without the need for 100% buy-in for every rule. If you work in a large organization, waiting for a democratic approach to a rule definition will cripple you. We took this 4 step approach:

1. Define a rule that you could explain the rationale for and put it in the model
2. Stay vigilant each month and see if the data trend makes sense
3. Share the result with GM's that consume this service and explain the definition
4. Inject the feedback you receive into the model (iterate)

There may be resistance to rules that have little to do with your logical definitions and a lot to do with what the results might be saying about the product or service it depicts. Hold the line if you believe the definition is reasonable, the audience will need a little time to adjust to a data-driven metric.

Provide Data Analysis, Not Just Model Output

This is certainly important in the early phases with each GM. You will get the most benefit if you can provide some level of analysis of the model results for that business unit. This is the "teach a man to fish" moment. The desired result is that you don't need to do this as a full time job, but that you are demonstrating the value of your model early, and the GM will see why taking this responsibility seriously will have positive impacts. Look for trends in the data, month-to-month, and also validate that changes in your services are accurately reflected in the expected model output.

Educate In Small Groups

I've discussed the need to educate and evangelize previously. I like to do this in small groups, with the GM, finance, and technical leads of a product. You should certainly discuss the overall model and the rules that it contains. You should also bring real-world output from the model for that particular business unit. Sample data or examples from other areas of the business will not have the same impact. Don't mail it in here, this is critical.

Be Manic About Delivery Dates

Finally, once you have defined a sufficient amount of your rules and your model is ready for an internal road-show, you MUST deliver the model output at a predetermined time each month. Never miss this deadline. It is essential to demonstrate how seriously you take this work and how critical it is that your audience do so. If you are going to stay in good standings with your CFO, delivering financial models on a schedule is one sure fire way to get their appreciation. No excuses here, be maniacal about your model's output dates.

I've written a fair amount about a financial model for IT in this series. While a model is critical, it is not the end of the journey of IT business transformation. I'm going to shift focus for the remaining articles. Coming up, we still need to talk about your organizational talent and how changing culture is the hardest part of this journey. Thanks for reading.