Lessons from AOL's TBM journey: TBM Part 7

Up to this point I've pitched the benefits of adopting a progressive approach to transforming technology organizations, the benefits of discussing IT value, and the notions of Technology Business Management. Understanding the general concepts of running technology like a business are one thing, but what happens when one tries to implement these ideas in the "real world"? In this week's installment I will share some of the lessons and surprises I learned over the past two years while implementing our TBM approach at AOL.

To lay the foundation, AOL, like many companies, have historically viewed central technology as a cost of doing business, one without offsetting revenue targets. Managing costs are clearly important to a business, yet must be balanced with the value the services provide to an organization. You may recall from an earlier article, what happens if technology costs stay in a never ending cycle of pressure, leading to service failure, loss of key personnel, and the inability for the company to deliver goods and services.

To help break out of this cycle I drafted a strategy to increase focus on customer service and create a fully data-driven financial model for each of our services. The model work and initial analysis were done as a department level goal, allowing us the freedom to explore and create a comprehensive report before sharing with business units and our CFO organization. The initial work was done by a small team of data and financial analysts. The lessons I outline below were captured from the moment we began sharing our model with general managers, the larger finance organization, and the rest of the central technology organization.

One last note before we get started. Remember one of the goals of creating this model was to move from emotional based decisions to data-driven decisions. Some of the observations I'll share clearly come from individuals making this transition and adjusting to the new approach we were introducing. While the dialog may differ, undertaking this important work will introduce change to the organization and you should expect to spend some time continuing your education and evangelism push, as outlined in the article about the IT model flywheel.

• "Great, Now we have to be concerned with costs"
  This one still makes me smile. This comment was given at the conclusion of an overview of our financial model with a classroom sized group of folks in my own organization. It may seem obvious that everyone should have an eye on costs, just out of common sense. My observation is that in many companies this responsibility usually lies with the management chain by default. You could argue that decoupling cost concerns from the individual contributors allows more creative freedom. I'd counter that I've seen lots of creative solutions that cost far too much make it well along the path before being vetted with a financial eye.
  
  Everyone should have some basic idea of costs, and this should be a factor of the design when building solutions. Our financial model doesn't make a determination if something costs too much, it simply presents the costs as data, providing an often missing input to the final decision maker.
• Resistance to change
  We all encounter this, over and over again, and it is not just when talking about a financial model. People aren't always receptive to changes, it's part of our nature. I've found the most effective solution is to provide the context for the change and the value we expect to derive from making the change. It doesn't always win someone over, yet it is hard to argue with this as a consistent approach. Asking questions that uncover the specific reasons why there is resistance can often lead to more insightful discussions. Maybe the real root of this resistance is something you should be addressing openly rather than waiting for others to also voice their concerns?
• The data is wrong
  We knew we were going to find errors when we started this work, what we found was amazing. Here are the highlights:
  - didn't have data for some services at all
  - data was based on a report that hadn't been updated in over a year
  - the general ledger had duplicates or missing asset costs
  - installed equipment was incorrectly listed under decommissioned projects (where were those costs going?)
  
  Each of these are opportunities to improve your data quality, and thus, the quality of your model.
• Results not expected
  What happens when you spend time gathering the data, creating your model rules, and even after several rounds of validation, the results are not what you expected (or wanted)? This can happen, in fact, you should want it to happen on occasion. This means that the prevailing view you had on that particular service was wrong. Maybe you've been making unknown poor decisions that have driven the costs up or the utilization down. It is not until you fully give way to the data driven model that these insights appear. If you find one of these, be sure you don't fall victim to this next observation…
• Define rules to "game" the system
  We rely heavily on the subject matter experts of each service to provide the definition of the metrics of consumption for each of their services. The inputs might be database size, number of tickets, host count, etc… Once we have these definitions and the monthly metrics all together we do a bit of analysis ourselves. This usually can catch definitions that aren't truly representative of the cost drivers. Usually this is not a matter of intent, and through iteration we improve these definitions until we are satisfied it represents reality.
  
  Sometimes, however, we find that definitions are provided that intentionally obfuscate the true cost drivers and are there to incent a behavior that might be outside the scope of a financial model. If you agree that these rules should be data-driven, then don't allow arbitrary rules to be introduced into your model, it will create a caveat that will confuse and reduce your overall effectiveness in the long run.
• "Tax" terminology is entrenched
  One particular story stands out for me here. We had finished an hour long discussion of our model, an in depth review of the consumption metrics and invoice for a month, all specific to a single business unit. It had been an engaging meeting, with lots of great questions, and we were feeling particularly happy with the results. At the end of the meeting, as we were packing up, one of the stakeholders thanked us for our time and asked if moving forward we will see this "tax" on their P&L each month. Oh well, you can't win them all on the first try.
  
  To solve this, you will need time and patience. As my friend Gill would say to me, "Stay strong". It's worth the effort to remove the unfortunate connotation that your organization is a "tax" on the business units.  Repeatedly talking about your service catalog, units of consumption, and the value your team provides will win in the long run.
• "It might expose just how expensive our service is"
  This is my very favorite lesson learned of all. This comment is so innocent, and yet really demonstrates why it is so important to create a financial model of IT. If the team providing a service is worried they are too expensive, then chances are, they are. Your company can't afford to allow pockets like this to exist. Work with the team to evaluate their costs and challenge them to reengineer, this is a success story waiting to happen, and one of the reasons you started down this journey.

I hope sharing these lessons learned and observations provide you with a bit more confidence that this journey is worth taking. You may find pockets of resistance and uncertainty, yet keep your eye on the end game, all of this is solvable. I've focused the past few weeks on the IT financial model because it is such a central figure in the overall strategy of managing technology in today's landscape. In the next article I'll share my observations on why the model is not the end game and how you can leverage your great model work to truly transform your company.