![[identity profile]](https://www.dreamwidth.org/img/silk/identity/openid.png){kind=small}
byh.livejournal.com posting in ![[community profile]](https://www.dreamwidth.org/img/silk/identity/community.png){kind=small}
techrecoveryThis is not a rant. Repeat - this is not a rant.
A few days ago our Very Big Boss decided IT department in the company needs more control and supervision. So here he comes and asks us to create some efficiency criteria we could report so higher management would estimate how well IT department works (if it actually works at all), is the department effective enough to address current issues, etc.
Any ideas?
A few days ago our Very Big Boss decided IT department in the company needs more control and supervision. So here he comes and asks us to create some efficiency criteria we could report so higher management would estimate how well IT department works (if it actually works at all), is the department effective enough to address current issues, etc.
Any ideas?
![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
no subject
Date: 2007-10-08 07:54 am (UTC)no subject
Date: 2007-10-08 08:04 am (UTC)no subject
Date: 2007-10-08 08:02 am (UTC)no subject
Date: 2007-10-08 08:11 am (UTC)As for fix time - in no way.
no subject
Date: 2007-10-08 08:17 am (UTC)no subject
Date: 2007-10-08 08:44 am (UTC)no subject
Date: 2007-10-08 09:02 am (UTC)no subject
Date: 2007-10-08 01:17 pm (UTC)I recommend a survey system, if they're looking for metrics. Even though I have issues with survey systems, and ways to get around THAT, I do agree that it's overall the best way to get out of a sticky situation. My company does things like ask questions (how was the service? How was the professionalism? Would you recommend $COMPANY?), and has three possibilities or general categories: "Very pleased", "Pleased" and "Not pleased". I don't agree with that, and would prefer a graded system; put up some questions with a 10 point scale. This way, you can get an average as to how your techs are, can reward those at the top and work with those near the bottom, and handle any wild fluctuations.
no subject
Date: 2007-10-08 08:05 am (UTC)Then perhaps look at what *might* happen if you were to move all internal IT work to a zero cost centre method. I.E. all work is billed internally meaning that there should be no budget directly allocated to IT per se, but all cost should be recovered via internal journalling.
You could then judge the efficiency of the department against the SLA (even if you made it up yourself) and the cost effectiveness against the zero cost centre.
no subject
Date: 2007-10-08 08:59 am (UTC)no subject
Date: 2007-10-08 03:32 pm (UTC)That is a good point though. The problem isn't what IT spends, it's that IT isn't spending it on toys for itself but on services internal to the company.
"Before you can find out where you're going, you have to know where you are."
You could start by breaking down tickets by urgency vs. department/user as a measure of where all the IT resources are being spent. These are the kinds of metrics your CIO/CTO needs to make, but I'm assuming you don't HAVE one of those, nor a professionally trained department head, nor even someone whose primary job is "Boss of the department who deals with all the paperwork and not the techinical day-to-day stuff" except you.
Hmmm - Try
That is a good point though. The problem isn't what IT spends, it's that IT isn't spending it on toys for itself but on services internal to the company.
"Before you can find out where you're going, you have to know where you are."
You could start by breaking down tickets by urgency vs. department/user as a measure of where all the IT resources are being spent. These are the kinds of metrics your CIO/CTO needs to make, but I'm assuming you don't HAVE one of those, nor a professionally trained department head, nor even someone whose primary job is "Boss of the department who deals with all the paperwork and not the techinical day-to-day stuff" except you.
Hmmm - Try <a href-http://www.cio.com/topic/1406/Metrics> HERE </a> for a starter if you're going to try to do this. There are NO easy answers to this.
Also <a href=http://downloads.techrepublic.com.com/abstract.aspx?&q=metrics&docid=173305&promo=110000> THIS </a> is a free download about HelpDesk metrics.
Good Luck!
no subject
Date: 2007-10-08 03:33 pm (UTC)no subject
Date: 2007-10-08 05:11 pm (UTC)Yes, it is definitely not my job to get through all of that but our head of department does not have enough experience in this stuff either so he kind of asked for help. Too bad I can't simply direct him to these resources because he does not know bussness and technical English well enough. Plus a lot of adaptation to our specifics will be needed.
Although there is an advantage in the complexity. I am more than sure that the main point of raising such questions is an attempt to save some money cut from IT bugdet (pays mostly). So costs of implementing such monitoring may be impressive enough to give up the whole idea as it is. :)
no subject
Date: 2007-10-08 09:56 am (UTC)I mean really, this is your bosses job, not yours.
There's a whole bunch of metrics for my company but I'm SOHO onsite, so it works a bit differently.
no subject
Date: 2007-10-08 05:12 pm (UTC)no subject
Date: 2007-10-08 11:00 am (UTC)no subject
Date: 2007-10-08 12:09 pm (UTC)**************
They are trying to outsource your department. Which has seldom done any good for most support, and virtually ALWAYS costs more then keeping it inouse.
Group the basic "types of jobs" you do, with an estimated cost of outsourcing the job. There are certainly several companies in your area that do this sort of thing. Remember to include additional down time while you wait for them to show up.
no subject
Date: 2007-10-08 01:03 pm (UTC)IAWTC. Many, many times I've seen bosses come and ask for things like this and every time somebody gets the axe. Polish up that resume and start looking — just in case.
no subject
Date: 2007-10-08 04:07 pm (UTC)no subject
Date: 2007-10-08 04:04 pm (UTC)...
Although it were the meetings which helped me to finally setup ICQ on my mobile - and when I did setup it meetings become much easier to attend except those moments when CEO felt like asking me a question and I never heard it.
no subject
Date: 2007-10-08 11:32 am (UTC)no subject
Date: 2007-10-08 12:13 pm (UTC)no subject
Date: 2007-10-08 01:54 pm (UTC)no subject
Date: 2007-10-08 02:23 pm (UTC)In order to compare the team as a whole versus other techsupport teams, you really have to compare the working environments, and the vast majority of the variables which affect this are controlled either by IT policy or corporate management. Everything from how often the incoming hold message or IVR voice clips are reviewed and updated, through to how much control there is over the user experience (inhouse has more than a specialist app team which has more than a public ISP), what the hiring and staff review policies are, HR policies in general, remuneration compared to other local employers, staff turnover etc.
If the employer is hiring experienced techs, providing quality TS tools, and has a total employment 'experience' which makes people want to stay longer than three months, then they're going to have a more efficient team. Especially if they let the lower levels of said team either set certain corporate policies or at least be able to have a good chance of improving them when they need improving.
And yes, someone is trying to outsource you. Depending on the politics at the upper levels and who's pushing for it, this will often mean that even if you can provide solid gold proof signed by the Pope and Joss Whedon that your team is more efficient, effective and cheaper than outsourcing, you will still be outsourced. Usually because the person pushing it thinks that they can use the resulting confusion to fiddle the numbers and get a promotion or bonus out of it.
Basically, find out whose agenda it's on. If it's the CEO or one of their favorites/relatives, you're boned. Get out now and make sure your name is on a lot of stuff so that you can sell yourself as a specialist consultant to whichever third party is handed the contract.
If the CEO isn't pre-sold on it, make a pre-emptive strike. Put some business-sounding numbers together (money, money, real costs and budget blowouts of other outsourcing attempts in the same industry, articles from Wall Street about re-insourcing, bottom lines, money moolah and cash. Bonus points if you can scrape up outsourcing disaster stories from their golfing buddies) and book ten minutes on their schedule so you can personally hand them the "project outcome projections". Tell them that there are some interesting results that you weren't expecting, and that perhaps they'd better look at it themselves. Don't label it 'good' or 'bad' - if you summarize it, they won't need to read it. And update your résumé anyway.
no subject
Date: 2007-10-08 03:54 pm (UTC)However you are right - when upper management comes with ideas like this then trouble is looming. In our case I think they are going to try and cut expenses on salaries in IT dept by means of fines and other sanctions. So far IT department is one of few that has stable income no matter what while the most other departments sometimes suffer fines and pay cuts when things get bad and they are unlucky enough to be blamed.
no subject
Date: 2007-10-09 04:24 pm (UTC)no subject
Date: 2007-10-08 05:11 pm (UTC)Its not too hard, especially in large organizations to show how any metric involving ticket numbers is very bad. As anyone in IT knows, one ticket is not a unit of work, or even average unit of work. The closest we've been able to manage is reporting against ticket number by tier responsibility, because that roughly breaks tickets out into similar levels of time and difficulty. Ticket numbers are also incredibly susceptible to people gaming the system. Is a ticket 1 customer contact? Does each question from a user become a separate ticket? How do you keep the potentially time consuming tickets from being avoided by some team members?
I think the way to go is focusing on SLA for high severity tickets, backlog numbers (tickets open more than a week), customer surveys for satisfaction, and escalations due to customer temperature vs ticket difficulty.
no subject
Date: 2007-10-08 09:04 pm (UTC)We do not have any metric monitoring yet but still we already suffer from gaming and techs tossing potentially problem tickets from one to another. Too bad we do not have enough of them to build teams but perhaps we'll figure something out.
no subject
Date: 2007-10-08 06:08 pm (UTC)Whatever you measure (and consider good) you'll get more of. The way you get more of it might not be to your advantage. (E.g. when a company started giving debuggers bonuses for each bug found and fixed, there were shortly a lot more bugs found and fixed. The code didn't get any better, rather there was a black market in bugs.)
Informal hard-to-measure criteria like "are the users happy" and "does the software help the company make money, or does it get in the way" work. Assume that the techs are going to game whatever your measure is.
no subject
Date: 2007-10-08 09:10 pm (UTC)We know it too well.
Reminds me of a period when techs were substantially rewarded (could easily get 150% their monthly pay) when they were willing to resolve issues during weekends (while normally company does not work on weekends). And then they'd get a day off for each weekend.
All of sudden there were so much critical issues requiring immediate attention that almost every tech got double pay and they were missing half of working week taking their earned days off. Not that quality of service really improved though.
no subject
Date: 2007-10-08 08:13 pm (UTC)Jobs in per week
Jobs fixed [where user & tech say it's fixed] per week.
If the second is approximately the same as the first, it's a good week!
Although you might want to keep a tally of number of jobs called inper week by user, and how long they last. Because of the 80/20 rule... ie 80% of the work is caused by 20% of the users.
Allows you to identify which users cause the most work, and then you can do something about them. [either work to get rid of them or try to identify why.. although about 90% of the problems are not so much what, as whom.]
no subject
Date: 2007-10-08 08:56 pm (UTC)Identifying problem users would be especially useful.
And if they'll want more sophisticated analysis I'll give them something I figure out from the clever stuff from comments above.
no subject
Date: 2007-10-08 09:19 pm (UTC)But you'll find that some people only take quick jobs and get a metric ton load of 5 minute jobs done.. while others prefer the meaty complex problems, so don't get as many done but generally have a higher rate of customer satisfaction [because 9 times out of 10, they'll have been through all the others first and will be quite fed up.]
And if you can't blind management by your brilliance, befuddle them with bullshit, MBA types like lots of pretty graphs.
no subject
Date: 2007-10-08 11:11 pm (UTC)You should be able to work out some rough guidelines to response times - Very Low = XX days up to High = X hours. SLAs are a good base for this, when you mix it with ticket priorities, you can get a good idea of whether or not people are pissing about with the stupid shit when the big shit needs doing...and cover your arse when they go "Why wasn't XXX's mouse replaced for a week???" "Uh sir, if you recall, the comms room had exploded at the time...."
And if anyone mentions "user feedback surveys" stamp on their heads, quickly.
no subject
Date: 2007-10-09 01:50 am (UTC)The satisfaction of your customers. However, you can only meaningfully track that with a valid statistical sample of the work you've done for them. Naked user satisfaction surveys don't work, you get too much feedback from people who've had very little work done and too little from people who've had tons.
So the first thing you need is for your ticket system to be meaningful. EVERYTHING goes in it. If somebody sends you an email that you have to actually do some work to answer, you need to stick it into a ticket; and you need to make sure the customer sees that ticket, because it may come back to him later.
Then you do TARGETED customer satisfaction surveys. You pull a random sampling of the tickets, you contact the customer, and you find out if it was completed to his satisfaction.
Any measurement of the time tickets remain open isn't part of this; it's valuable internally to your manager to make sure people are closing their damn tickets, but what matters is that the customers think they're being helped. Whether or not they actually ARE getting good service matters only to the extent that it contributes to them thinking you are; the fact that they think they're helped or not is what keeps your job yours.
This is what your manager does anyway when he pays attention to what people tell him about your department; this is just a matter of formalizing the process, 'cause an anecdote ain't a metric.
no subject
Date: 2007-10-09 03:42 am (UTC)At the same time, it's up to you in the IT department to commit to a series of process and procedures. That's not to say become procedure Nazi's -- but canned fixes for particular common problems can alleviate a number of problems with different techs having different methodologies.
That said, document everything and either hire, promote, or elect someone to represent your team to upper management. This person should be responsible, and should NOT -- under any circumstances -- be on either side of the fence. If the person is a corporate yes man then everyone is screwed, and if the person is 100% loyal to the IT group and not to management then the result is the same (however slightly more fun.)
Finally -- talk to your users. When you're creating or improving your processes, make sure the users are getting a good experience out of it. A lot of times, it helps to trim the fat off of the processes. However, don't bother with after call surveys. They're just worthless. Instead, offer regular opportunities for users to comment on IT in general.
no subject
Date: 2007-10-09 09:30 am (UTC)When the issue is resolved, likewise cc the original submitter their supervisor for short-term accountability, and periodically compile the empty bottles to justify IT's budget with verifcation from other departments built in.
no subject
Date: 2007-10-09 07:50 pm (UTC)If you're in an environment where work primarily comes in asynchronously via a ticket system, there are some particular metrics you want to track, for example: the amount of time between when a ticket comes in, and when a tech picks it up; the amount of effort (in terms of tech time) spent working on a ticket; the amount of time a ticket sits idle because nobody's working on it (while there are techs available); the amount of time a ticket sits idle because there are no techs available to work on it. To do this, you also have to keep track of how your techs spend their time - for instance: the amount of time spent working on tickets; the amount of time spent on "administrivia" (in meetings, in required training, etc.), time spent on professional development (taking certification classes, etc.), and other miscellaneous non-billable time. And of course, your techs will resist this, that's to be expected - it's a pain, and (especially if you have problems with gaming on the clock, and things like that) it puts them under a microscope that they'd probably rather not be under. But you need this information to draw meaningful conclusions about how much time tickets langish because there's no one available to work on them, and you can actually use this kind of info to lobby for more resources, headcount, etc., if you're chronically overbooked.
You also want to keep track of how much time it took to close tickets of particular severities, and how often tickets were closed beyond a reasonable/agreed amount of time for tickets of that severity. An SLA is really helpful here - not only to define your goals in how long it takes to close a ticket of a particular severity, but also what the severity levels actually mean. That way, when someone enters a "high severity" ticket because they want their keyboard cleaned or something, you say "Does this affect more than a hundred users? Or does this impact more than five digits or so worth of revenue? No? Then sorry, it's not high severity - end of discussion..." If you don't document your severity levels in an SLA or something, then the severity level means whatever any random user decides it means...
no subject
Date: 2007-10-09 07:53 pm (UTC)