Dick Nolan and Dave Norton, founders of their eponymous IT strategy firm in the 1970’s were the first people we knew who talked of IT as being a business within a business, when CIOs began to seek seats on the Board, but as they pointed out, CIOs often lack a language to talk about their business.
Operations could talk about throughput, efficiency, quality, investment and maintenance; HR could talk about turnover, pay, management succession, and compliance; Finance could talk about cash flow, the P&L, and tax, and so on. But when the CIO talks of incidents and upgrades and operating systems, the room goes silent. What CIOs need, said Nolan, was an “IT Chart of Accounts” that would allow them to describe what they provided.
When fully worked through, this comprises scorecards and targets in respect of things worth measuring and improving and which (internal) customers can find relevant – Products and Services.
The one fundamental aspect of any IT chart of accounts is the Financials, which informs all the others and is where we start.
It has become commonplace to say that it’s hard to manage what isn’t measured, and in any other business, not understanding the costs, or the drivers of costs, would be a serious impediment to running it effectively. It is no different with the Business of IT. Most CIOs will claim to know (with some degree of accuracy) “what things cost” but most have no clear structure of how those costs should be represented. They often amount to little more than departmental budgets, expressed in terms of staff costs, with other costs allocated to big ticket items like depreciation, asset renewal, and third party spend.
At worst this is just a laundry list, and does not provide a good basis for the CIO or his customers to make rational economic decisions. It doesn’t need to be perfect, but the chart of accounts has to support these decisions, in terms of both the running costs of the desired outcomes, and the costs of achieving them. Knowing your costs isn’t just knowing an aggregate budget number. It also means understanding the cost structures and levers.
The appropriate IS cost structure is a matrix, not a list; because we own (or buy) resources, and perform activities which use them. The resources – people, hardware, software, facilities, networks and so on –are distinct from the uses to which these resources are put – the activities which produce the products or services you provide. If you don’t know how the cost matrix is built up, it will be harder to answer some basic questions about how to change the costs. The important thing is the activity, not the resource, which is just the means to an end, (and can therefore be bought cheaper through applying good procurement practice).
The activities, the things you do in order to create the products or services you provide - development, maintenance and enhancement, operations and so on - should be broken down by application, or application grouping, and some additional segmentation - desktop and desk-side support, help desk and customer management should be undertaken as well as costs for management and administration.
If your business falls into natural segments it is usually helpful to have a set of nested matrices, one for each segment, which will enable comparisons to be drawn, and best practice to be adopted.
It may be hard to get this level of detail when much of IS has been outsourced, as the resources the outsourcer uses to deliver the services may be hidden and in any case, they are in one sense, literally none of your business. However, unless you understand the elasticities of the outsourcer’s cost model, you will find it harder to predict the cost of any changes you may want to introduce.
If you are considering outsourcing, not having this kind of information will put you at a disadvantage, and you will be forced to gather it as best you can quickly.
CIOs and their customers may value their applications and the services, but they cannot know whether they are worth what they are costing, if the true cost is not understood. Managing an applications portfolio is hard enough, but not knowing - specifically – how the costs are generated is hugely disabling when it comes to helping the business make decisions.
Some apportioned costs may not be saved when, for example, an application is turned off, so the chart of accounts will not tell you what the dependencies are, but it will help to look for them.
Although gathering the costs in this matrix and keeping them up to date may not appear to add much value, it is extremely helpful to running the Business of IT because it provides a much better insight into your activities.
Here we concentrate on the other concept – value, because comparing the one with the other is the beginning of wisdom.