Cutting costs is an all too familiar requirement, but the article argues that you can do so without reducing staff numbers or sacrificing quality.
The question of reducing support costs is a seriously touchy one with big implications. Merely to consider it puts jobs at risk, which can damage morale and department stability. Questions arise about the effect on service quality and so the wider impact on the corporation as a whole. In all, the entire cost reduction issue is a bed of hot coals covered in tripwires. Nevertheless, in the present climate, it is one that most managers – especially, one might argue, in the public sector – must at least be seen to have addressed, even if it is only to affirm that the department is lean, slick, running at maximum possible efficiency and meeting all business IT support needs for reasonable cost.
The pressure on costs is purely financial. It is not about service but value for money. A core truth is that most IT support costs are already justified, or your department wouldn’t exist. All we have to find out is ‘by how much’. Therefore, the cost reduction programme must have two outputs. The identification of excess expenditure is one, but that itself is only an arithmetic product of the main output, which is the accounting justification of the necessary costs.
Note I said ‘accounting’ justification – namely, what actually is the delivered monetary value of the services provided by IT support. Most IT departments don’t know that number, or where to look for it. This is why they often have difficulty convincing those who think only about money to invest in IT support. If you want to convince a bean-counter, talk about beans, not ‘service benefits’.
Your next decision is whether you wish to increase, maintain or decrease service quality. It’s OK to think about decreasing it by the way – once the target level of quality has been identified, any residual over-delivery is a waste that legitimately can be eliminated.
Ultimately, there are really only two ways of reducing the cost of IT support. One is to push the charge onto another cost centre and the other is to reduce resource expenditure. For the first of these, the other cost centre may be internal, for instance where ‘user self-support’ pushes the support cost back onto the users. The financial result is that some of the costs of IT support leave the IT budget and land instead in the budget of other departments.
However, unless this move is accompanied by a deliberate strategy for also reducing resource expenditure, then rather than change the costs of IT support, it simply transfers them elsewhere. Ultimately, the organisation as a whole still bears the costs.
In addition, this mere transferral carries with it considerable risks. Because the costs are now distributed among various centres, the total is now masked and effectively cannot be measured. Thus it may rise invisibly and thus uncontrollably. Furthermore, IT support responsibility has been passed to functions that do not specialise in this area – so there is a risk to quality. Incidentally, this is why, in any consideration of support costs, you should also look at all those private support desks hosted and paid for by users, even if they don’t report to you. It’s still all support cost, after all.
Another form of support cost transferral is outsourcing, as an attempt to force the costs onto another company entirely. In fact, this is ultimately an internal transfer as well, as the organisation still has to pay the outsourcer. Furthermore, that external provider now has an even bigger challenge than you had – namely to produce at least as good a service as you did, but also make a profit on what you pay him for doing it. Of course, he can only do that by spending less to produce the service. So either he must be supremely more efficient than you were or the service must be reduced in terms of scope and/or quality.
Outsourcing can also be a false solution overall. One of the main pitfalls with this option stems from quantifying the support in the first place. There is a very strong possibility that an inefficient support service has no accurate measure of the actual amount of support work to be done. This is because poor support causes users to find other, more reliable ways of getting IT support, so not all the work ever reaches the official channel. But when this is outsourced, all that demand may go to the outsourcing company, and because of the original statistical inaccuracy, the demand is unexpected. So the charges go up.
The irony is that the accurate workload and demand measurement necessary for outsourcing would be the first step in any service improvement, for cost reduction or any other purpose. Which brings me to the second way to decrease support costs, namely reducing resource expenditure. In other words, the work necessary to prepare for outsourcing, may make outsourcing itself unnecessary.
When the programme starts, don’t be taken in by software companies suggesting you buy their product to save money in the long run. That’s as may be, but at this stage it’s a distraction. Find your procedural and structural waste first. You can cement it with new tools as appropriate later.
There is a simple rule of thumb I like to use. To find cost savings and efficiency improvements, the first place to look, in any organisation, is in the functions whose activity and output are least effectively measured. In the first line, unlogged calls is a good place to start. In the second and third lines, unquantified projects and query resolution times are rocks that can be interesting to lift. Across support, activities that produce a recognisable result but are not formally identified as services, can also look very different under closer numerical scrutiny.
In the search for the smoking gun of waste, you have to do this looking behind the cupboards, at least to eliminate various suspects from your enquiries. This can be extremely difficult as the work in some support sections may not be of the ‘McGregor Theory X’ type and so cannot easily be quantified. How long and how many people does a ‘project’ take? How do you compare the delivery of an installation with that of a user training course? But of course that’s just detail. You’re looking at bigger pictures, so what you need here are patterns rather than mere units of resource consumption.
One problem I’ve sometimes encountered is resistance to measurement. This can take numerous forms – rarely is it active defiance, but it can manifest itself as fear or ignorance. Soldier on – you can’t ignore it just because it’s difficult. Sooner or later, somebody will probably whisper the dreaded pejorative ‘Time and Motion’. Of course this is just a cliché that people often use without fully understanding. It comes from an industrial environment and an era before knowledge was a common product, so it’s not universally applicable to IT support. You may find yourself having to explain this to some of the more fearful of those potentially affected.
As W E Deming said and I paraphrase, “if you cannot measure it you cannot manage it”, and by extraction it therefore lies outside your control and may thus be running up costs that are not necessarily justified. Any inefficiency is also costing in terms of service quality to the end users, while perturbing and confusing managers. You have to get these costs out into the open, even though you may thereby disturb the comfortable niches of some who have hitherto had no cause to take into account the cost-justifiability of their function. If you can’t identify the costs, you can’t justify them.
The fear can often make it extremely difficult to find the objectivity essential to any such exercise. You may be asking managers who have never measured their departments to produce statistics by which their cost value may be judged. Even if they want to help with the exercise, they may simply not know how, and their objectivity may be clouded by the apparent or imagined risk to themselves or their departments. This casts doubt on the accuracy and usefulness of the answers you may get. For real objectivity, you might have to call in external assistance from one who has the techniques, expertise and experience to measure and propose cuts while understanding and maintaining IT support services, and no political or historical crosses to bear nor job of his own to protect (who might that be? Give me a ring and I’ll tell you).
One thing you can be sure of is that in the end, everybody benefits from a cost-measurement exercise, despite the possibility of heartache while it’s happening. It’s more gratifying for the staff to work in a well-honed support service. Where the exercise finds unpleasant truths like waste and protectionism that serves the self rather than the organisation, take pleasure in eradicating them, because that is a success, not a failure. At the end, the users are happier, because the service is slicker. You are indeed producing the best service you can for the investment made in it and you can prove it because you now have two figures – the cost of your department and the value it brings to the company, and the latter is decidedly and satisfyingly greater than the former. It’s a relaxing feeling to know that on the bean-counter’s list, your department’s name has a tick of completion against it.