The concept of a centralised IT department working towards a common goal remains a pipe dream.  Noel Bruton argues that the culture  of promoting support staff to managers, our continued reliance on ITIL and fear of challenging other departments to improve their service is stopping us from delivering technology the business needs.  

I’m grateful to an attendee of one of my support management training seminars for the title of this piece.  It highlights a repeated support problem.

I’ve been giving a lot of those seminars recently.  I’m doing another in June (fully booked) and another in July (details at the end of this article).  One question that always comes up, and I expect it will be raised in those too, is what you do as a servicedesk manager, if the other departments in IT do not react with expected alacrity to the support calls you allocate to them.  The second- and pointlessly named third-line departments who refuse to offer an estimate as to when they will resolve that escalated assignment, the refusal to speak to the user, the tendency to put their own priorities before those of the technically-impeded user, the repeated failure to complete the call documentation to a standard that provides information that will historically be more useful than the single word “fixed”, or the well-meaning but useless “fixed, customer happy ok”.  It seems a ubiquitous problem, appearing in public and private sector, small and large organisations.  Actually, the reasons it happens (or the excuses given) usually differ with the size of organisation, but the effect is the same.

Incident manager? No thanks

So what should you do if it’s happening in your organisation?  Here’s what you shouldn’t do – you shouldn’t implement the incredibly naïve and organisationally immature recommendation of ITIL, namely to appoint an ‘incident manager’.  At least not unless that appointee as an individual has, and will happily use, the power to fire or at least confidently censure, anybody below the rank of CIO.  That’s the first requirement of that authority.  The second is that the incident manager must be utterly dogged and persistent in his or her pursuit of offending departments and individuals.  Am I overstating it a bit?  No, I am not.  Because that is what it will take.

The paradox is, that it is only because of the glaring anachronisms and flaws in ITIL that would make it look like an incident manager is necessary.  In an organisation where professionalism takes precedence over everything else, the incident manager would be superfluous.  The converse of that is, of course, that if you think you need an incident manager, then somewhere in your map of resolving agencies, professionalism can be called into question.

This perennial problem makes my blood boil.  As a servicedesk manager, you have a right to expect a service from those ‘resolving agencies’, but if it doesn’t come, all you can do is complain to higher ranks.  If the responsibility is genuinely theirs but they do nothing about it, and offer you no explanation for that decision, then the end of my previous paragraph may apply.

Delegation

You have been told by those above, or by de facto practice, or because ITIL says so, that if a call comes in of a content that is by design outwith your service desk’s area of expertise, then you shall send it to the IT department that owns that expertise.  It is then perfectly reasonable to expect an appropriate response and action from that delegation.  But it doesn’t stop there.  If that is your instruction, then it is safe to assume that by the same token, the delegate department in question has been told to expect support calls.  Therefore, it would be professional and right of them to create internal procedures for handling those calls.  But then, it doesn’t stop there either.  Because it also means that the resolving agency also counts a proportion of their budget as funding the resource to deal with those calls.  Put simply, not having a process to deal with requests is merely amateurish – but taking corporate finance to fund a service and then not providing it, could be construed as actually dishonest.

When I was a career helpdesk manager, my patience with departments who would not deal with servicedesk calls just because they didn’t feel like it, was rather limited.  Nowadays, I’m more even tempered.  It might just be bad management – there is a lot of it in IT, as technicians are promoted beyond their level of comprehension and don’t grasp the concept of ‘management’ sufficiently well, to realise that it imposes on them the responsibility to design mechanisms and deploy resources to demand.  More often than not, the reason why second and third line departments are unresponsive to support calls contains more than an element of that lack of understanding.  But it’s safe to say that it is often also to do with the attitude of some second liners that they have been promoted somehow beyond the necessity for support work, so they see it as beneath them.  But then that too is a man-management problem that their head of department should have recognised and dealt with.

Sharston Baths

When I was a kid in South Manchester, like so many nippers in the area, I’d often get wet at Sharston Baths on a Saturday morning.  The designers specified Sharston’s pool to be ‘Olympic-sized’ – but forgot to allow for the width of the tiling.  The pool ended up just that bit too short for competitive swimming – so it never reached its design goal.  They knocked the building down in the 1990s.

Bless ITIL.  It came up with the idea of ‘IT services’ to distinguish the function from ‘development’.  Great idea, but just like Sharston Baths, they didn’t go far enough.  They could have designed-in end-to-end user support, but instead, they allowed for some services to be delivered under subcontract by parts of IT that were outside the influence of IT services.  It was a problem that could have been solved by a ‘framework’ such as ITIL, but all they did was document common practice in 1980′s mainframe data processing departments and because of the installed base, they’ve never had the bottle to recommend a better way.

Of course departments that are involved in the design and creation of IT systems like business applications and networks, will prioritise that function over support calls.  This pestering by the servicedesk is an interruption to them, a misdirection from their key function.  Which is more important?  New systems development to keep the corporation abreast of its customers’ and masters’ demands, or restoring productivity to users impeded right now by a present IT failure?  The two sides of IT will argue differently.  I’m in user support, so I say present productivity puts food on the table today, so that comes first.

Radical

The ultimate fix to this problem is a radical shift in the design of IT, which I’ll be writing about soon.  There is, however, scope for an interim fix – but you will need a basis of decision that goes beyond and takes precedence over the internecine politics of various IT factions.  For me, that decision basis is the financial value of the productivity lost while a support call remains outstanding.  This is far more powerful than a mere statement of how long it takes to fix a call.  You can calculate the productivity as the corporation’s annual turnover divided by the aggregate hours worked by its employees over the same period, then portioned down by a factor describing the overall average dependence on IT.  Multiply that pound figure by the number of hours the call remained open for – then represent that in a table comparing all the resolving agencies’ performance, including the servicedesk.

£Millions

As you will see from that table, the company productivity lost by resolvers “not getting round” to fixing calls will probably run into millions of pounds.  Now there’s a report that will get read at board level – but don’t send it there first.  Show it to your immediate boss.  Now you can ask for service improvements from the other departments.

Don’t be scared to fight for better service for the users.  They are holding you responsible for the poor service.  So they should, ITIL also says it’s down to you (ITIL’s wrong about that too, by the way).  The users don’t know, nor do they care that the slowness is because of other parts of IT.  So if you’re being held accountable, it is your right to find a way to influence the quality of service from those parts of IT to which you subcontract part of your workload.  Make no mistake about this, anybody to whom you insource work – be it networks, development, whoever – when it comes to user support that department works for you.  Behave like it’s true, because it is.  They are your resources, no matter how many grades higher may be their job than yours, no matter how much closer to the front door than you they are allowed to park their car.  And because management is about the orchestration of resources – manage them.  It is your right and duty.

Noel Bruton is a UK-based consultant and trainer, who assists organizations in a wide range of industries in the practicalities of IT support management and improvement. He is the author of best-selling books on all aspects of IT support service delivery. See more on this topic and others at his website, www.noelbruton.com. 

His next one day workshop, called Moving From IT Technician to Manager: a one-day mindset-&-practice breakthrough workshop, runs in central London on Wednesday 4th July 2012, 1000-1600.

Its purpose is twofold; to provide the promoted technician with the new philosophies and priorities necessary for management; and to describe, in some detail, the specific tasks of the manager’s working day.  Click the link above to learn more and book your place.