Article ID: PR035
Category: Process
Title: Operational Model for IT Support

By Noel Bruton

Noel Bruton is a UK based consultant and trainer, who since 1991 has been advising corporations on improving IT support. He is the author of the bestselling 'How to Manage the IT Helpdesk' and 'Managing the IT Services Process'. He has a worldwide clientele and readership and is acknowledged by the IT industry as one of the world's leading authorities on IT support. He is also heartily sick of the failed promises of ITIL and thinks it's time he did something about it. This article is part of that something.

The theme of this article is how to design Helpdesk and IT Support services on the basis of business cause and effect rather than convention. The model described in this table is intended to expose the roots of the commonest problems, constraints and impediments facing IT support. Not enough staff, falling salaries, lack of management understanding, customer and corporate confusion between helpdesk and call centre, lack of service ethos, waning motivation, low career and advancement opportunities, infrequent training, difficult users and so on and so on – these are all dealt with somewhere in this model.

The steps are co-dependent. You have to address them in order. If what you do at step 14 is beginning to resemble a pear, the chances are that it's because there's something in an earlier step you failed to cover adequately.

My intention is to develop these seventeen steps into documented practices. With good cause, I firmly believe that if the IT support manager does the below in the order described, the bulk of IT support management issues will be resolved and great service will ensue, in a satisfying and rewarding atmosphere for the customers and the IT support staff who provide the service.

There's one significant thing missing from this model – the most powerful of all – and that is the leadership of an enthusiastic and impassioned IT support manager. The point is moot however - I expect that anybody who truly takes a model like this on board and follows it through will be a natural leader anyway.

Why am I doing this? I've been toying for a couple of years with the idea of a helpdesk / IT support operational model. And I believe that is needed because there is nothing else. ITIL has never offered this and the so-called current 'Refresh' won't either. It is ironic that the department most affected by ITIL adoptions is the IT support department, when there is such an astonishing amount of important stuff missing from ITIL on the issue of IT support. If what you really want is to improve IT support, don't expect the answer to come from ITIL, because that's about the bureaucracy of uniform IT processes, rather than the really important issues of services, resource allocation, decision support, productivity, man management and customers.

That's why I'm offering this model – to start to really address those issues – I hope to flesh it out over the coming months. Comments and feedback are welcome. You never know, we might turn this into a proper standard.

Order	Stage
1. Market assessment	Know your market – count your customers and where they are. Note differences in service needs between groups of users and locations – not everybody wants or needs the same sort of service. For example, not all customers are IT users but still need an output – e.g. managers needing statistical reports.
2. Business risk assessment	Examine customer groupings in terms of their importance to the business. Be realistic – for example, not all organisations have pure business motives, some are political – accept this and reflect it in your assessments. What does the organisation stand to lose on the basis of the service you will, or fail to, deliver?
3. Design services and service levels	Note that the service is designed on the basis of the business risk and the customer demography and NOT on the basis of what skillsets the technical staff may have or what technology is to be supported. The services must meet the business, not technology needs. Technology serves the business, not the other way round. So for example 'fix my printer' actually means 're-enable me to print, with a level of convenience appropriate to my immediate needs and within reasonable affordability'. Think broadly – just because there is a convention, does not necessarily mean it must be followed. Like all businesses, yours is different.
4. Identify key service level statistics	Note that this is done on the basis of the above-identified risks, which is a product of the business need. Too often, service level statistics are a product of convention or borrowed from a hardware maintenance contract that was ditched years ago, which is why we see so many meaningless '4-hour response' service levels. The service levels should be calculated, not plucked from the air. If a user is not served for four hours, what does that cost and is it more or less than having the staff to service the need?
5. Get business acceptance	Get agreement from the business on your assessment of the customer demography and consequential services and service levels. Note that if you don't get it at this point, it will be extremely difficult to get it later because only here is the business benefit clear. Part of the agreement should be a documented consensus of the relative importance of one user group over another (and the same for your services). You'll need this later for workload prioritisation. If you don't have this, your prioritisation is either guesswork or categorisation, no matter what your helpdesk software calls it.
6. Design the process to produce the services	You've done the market assessment, you know what products to make and what they are worth to your customers and you have a commission in principle to manufacture those services. Now you have to build the production line for that manufacturing. The process should take into account the various process elements and the relationship between them including the protocol by which they communicate. Identify the points on the process at which you add value to a production unit – for without this, you can't later identify your operational statistics.
7. Conduct a process risk assessment	What if the process fails? What are the critical paths? Which services will suffer the greatest impact and how does that influence the business risk? What alternative routes and methods are there?
8. Identify key operational statistics	These are a consequence of the key service level statistics and the production line risks. These are the statistics that rarely, if ever are covered in helpdesk software – they are the ones you must monitor to ensure the end targets can be reached. They are about productivity internal to the support process, not that as a consequence of it. Service level statistics tell you whether you met or missed your service level targets. Operational statistics tell you why.
9. Identify necessary skillsets	Skillset identification for IT support staff is often limited to technical knowledge applicable to the corporate IT. For customer facing staff, customer service skills may also be included. We must also take into account the types of skills dictated by the process we have designed in order to make the service products that our target clientele needs. The mistake we can sometimes make is to do this the wrong way round, namely hire an individual with a requisite technical and try to make him or her fit into the process. If they don't have the skills, or more specifically aptitude, that will have difficulties such as incomplete jobs, paperwork not done, solutions not documented etc.
10. Identify types and quantities of staff	Once the needed skillsets are identified, the anticipated quantities of (essentially cost-justified) work, and the service levels at which that must be delivered, can be factored in to arrive at the first real estimate of the necessary number of staff. More often, IT support does this the wrong way round, waiting for the demand to build beyond capacity and knee-jerkingly hiring staff. By then of course, the service is already failing.
11. Get financial investment	The risk to the business of poor support has been identified. The services to defeat that risk have been designed, along with the processes to produce those services. A realistic anticipation of the workload exists and the necessary skillsets can be priced against the market. Funding should now be straightforward. Often, IT departments make the mistake of trying to fund against headcount rather than against service value – which is why IT support is repeatedly underfunded and service levels often so low.
12. Set up monitoring regime	Critical operational benchmarks – staff numbers, delivery failures, protocol/handover failures, skills shortages and redundancy, team resilience in general, backlog stability (some backlog is necessary for resource efficiency)Critical service level benchmarks, most measured against business risk (why is it a four-hour fix? Why not two or three-and-a-quarter? The number must come from somewhere or it is meaningless – "it's four hours because I say so" isn't enough
13. Staff development programme	Anticipate changes in required skillsets, especially technological. Ensure each skill is mirrored to cover for temporary absences or service demand aberrations.
14. Project tasks management programme	Where reactive jobs turn into projects or mini-projects, have a methodology for running these. Set milestones, timescales, allocate resources formally and check progress. Do this by ensuring every project, no matter how small, is formally commissioned, broken down into measurable tasks and goes through a management process as it progresses. Without this, project work can damage service levels by eating into the manpower needed for reactive work.
15. Workload Planning	Don't just react. Use Monitoring (Step 10) to anticipate typical workloads and allocate resources accordingly, making sure all services designed at step three have the necessary manpower to produce them. Mix in other drains on time like unofficial absences, specials, projects, training etc. Ensure all expected outputs are catered for.
16. Communications regime	Crucial, crucial, crucial. I can count on one hand the number of IT support groups I have encountered in the last five years that actually do have a formal communications policy. Users need to know and be constantly reminded what to expect. The protocol between the various factions of support must contain sufficient information to ensure that handover has taken place and that responsibilities are uniformly and universally understood. Reporting formats and purposes most be agreed, because these too are designed to hand over responsibility thus incurring action elsewhere. Staff need-to-know boundaries must be drawn. Channels must be in place.
17. Operational Change	As a consequence of monitoring or to mirror change in the business; to cope with staff departures or arrivals. Particularly to meet aberrations in operational or service level statistics – a failure to meet a target needs a next stage to do something about the failure, even if the something is to adjust targets or benchmarks to make the new state more acceptable.

For more information on on Noel Bruton's services, either call +44 (0)1239 811646 or email noel@noelbruton.com.