Budget to Live v Total Cost of Ownership - BTL v TCO

One of the things that never ceases to amaze me in IT organisations is the way they treat support so differently from projects. Often these two pieces are contained in completely different parts of the organisation with different objectives and measures, unbelievably often the architects and project managers from the "build" side don't have to know anything about the existing systems, or indeed the impact of project issues on that existing IT estate.

It also creates one of the most dangerous things in IT from a cost perspective namely the focus on "Budget to Live"(BTL) rather than Total Cost of Ownership (TCO). What I mean by BTL is that a project has a budget to spend to get the project live and that is what they will spend to go live, thus demonstrating how clever they are and why they should all get paid more money.

And time after time I see the following behaviours

• Testing cut short to "get it out the door"
• Testing only positive scenarios
• Taking coding short-cuts that "are a bit messy but its quicker"
• Allowing "code first" design (and I don't mean TDD)
• Excluding existing systems from question of "how to build this"
• Deliberately hiding problems
• Claiming "live" going to the pub and saying "its a support problem now"
• "It was fine when I left it"

This is often exacerbated by the "architects" within these companies who practically aim to be ignorant of the challenges of actually deploying and managing a solution. Thus the architects are there for the first few months and then leave it to the lowly designers and implementers, and when it goes wrong.... well it isn't their fault the architecture was fine, and of course those massive maintenance issues for this "optimal" architecture are down to the lack of sophistication in support.

All of this means that projects store up a whole load of hidden costs that are only realised after the project goes live. In many organisations there is a "hand-over" between the two groups and no cross fertilisation of resources, so operations doesn't get to be involved in the project to point out the issues they just have to deal with the problems. The problem is that the project will be seen as successful, whereas the support will be seen as expensive. The project will take the plaudits and operations will carry the can, this isn't an effective way of delivering a decent IT organisation.

So what I'd recommend is that architects be made to learn the existing estate and be measured on the total cost of ownership for their area, their bonus should come from them delivering on the promises that they made at the start of the project. A project managers bonus should be split 20% go live and 80% 12 month TCO to make sure they focus on the bigger picture. Most importantly of all however the accountants should recognise where cost should be assigned, namely against the project budget that created the mess. By making these changes an organisation can start to think in terms of TCO not BTL.

If you aren't considering support in the same breath as new spend then the odds are you are doing BTL, and your IT is much more expensive in total than it should be.

Technorati Tags: SOA, Service Architecture