Wednesday, September 03, 2008

Sound advice ...

I'm a great fan of Dennis Howlett and his no nonsense approach to finance and IT. In his lastest post he talks about a number of practical activities that professionals should offer to tide a business through the current economic strife. One of the activities he mentions is to kill the IT budget and endeavour to move from capex to opex.

Now as Dennis mentions this means considering software as a service offerings, however this shift from capex to opex has some surprisingly complex management issues.

Many years ago, I started using worth based development techniques and utility charging mechanisms for client projects. To demonstrate this and the problems it caused, To explain this, I'll use the example of a web based sales system.

As the provider of the service, I didn't charge for building and delivering the system but instead provided costs for the design, build, maintenance and hosting. Since I had experience of running numerous web properties, some of which were successful and others less so, I was able to create methods for calculating the cost per user and a risk profile for the likely number of users.

Using this information, I could offer to provide the system on a per user basis with no upfront costs. Naturally, I was taking a risk should the system be unsuccessful but this was balanced against the potential upside of a highly successful web service.

However, this information created a problem. I could tell my clients what the service was going to cost per user, but in many cases the clients had little idea of what the user was worth to them. In the past, web projects had tended to be capex rather than opex, so the idea of calculating the actual worth per user had rarely been considered.

If my clients created a marketing plan to grow the system, I could calculate the additional cost due to growth. All my costs were variable and this was light years away from the fixed budget world of large lumped sums and it was this that caused significant management issues.

For example, on one project I helped the client determine the end value (in this case revenue) of the user and showed that this vastly exceeded the cost. For every $100 of calculated sales, I would in essence be charging $10. Whilst the system was growing we were all doing rather well. Unfortunately, whilst the growth in users created more value (the $100 bit), they also created more costs (the $10 bit). A problem then occurred when it was realised that the total cost would exceed the original fixed budget constraint.

Now, amazingly, it is not that unusual for a value generating activity to be terminated because it has been too successful and the cost has exceeded the constraint. This usually occurs because no-one has been able to identify the value. However, you can also find yourself sitting there pointing out that every $10 of cost means $90 more gross income and yet still hear those dreaded lines:-

"we only budgeted a $100K for this project, we can't exceed that."

So I agree with Dennis on the shift from capex to opex, but I'd be curious to see what sorts of problems this then causes.