Serio Blog

Friday, 04 Jul 2008

I'm asked to address the subject of how you measure the performance of Helpdesk/Service Desk Teams and Agents - something that can be both useful, vexatious, misleading and controversial (and possibly all of these at the same time).

If you are asked to look at this subject, you need to be clear about what aspect of performance you want to look at - saying 'I just want to look at standard reports' usually means you haven't thought clearly enough about what you wish to examine, or what problem you are trying to solve. For example, are you concerned about a Team that seems to take a long time to resolve Incidents? Or a Team that seems to re-assign a lot of tickets that are assigned to it? Do you just want to get an overview?

Let's take a look at some different aspects of Team and Agent performance. You'll see that these are mostly subsets of overall ITSM service delivery performance.

Type of Ticket - Are you looking at Incidents, Problems, Service Requests or Changes? Or all four? You might find it helpful to consider each individually.

Rate of Resolution - Now by this I don't mean speed, I simply means out of how many tickets logged or assigned to a Team did that Team actually resolve? This may not be appropriate for all ticket types and for all teams - but for some it will be. The most obvious is a first line support team, and instances where you are trying to improve the number of tickets resolved without being passed to other teams. It might be hard to determine what the 'right' or 'acceptable' number is, so try looking at the figures over something like a 3 month period.

Number Resolved - This is probably the ultimate blunt instrument, so use with caution (yet bizarrely it's often the first measure managers look at, especially for Agents). The reason it's a problematic measure is that those Teams and Agents having more complex workloads and tasks will usually have a much lower rate of resolution than those with simpler tasks. One useful thing you can deduce from this is if a particular Team or Agent is being put under increasing stress by increasing volumes. You can also investigate issues where ticket closure figures are low for one or two Team members - but remember it might simply be they are doing other things, or handling more complex cases.

Churn - Here I'm referring to an overview of incoming tickets, the number resolved, the number outstanding and the number on-passed to other teams. You'll find a report in SerioReports that shows this, and can be used to get a view of how Incidents move between teams.

I'll post the rest of this article next week. In the meantime, I've made a companion spreadsheet to our Service Desk Metrics White Paper which contains some actual examples. Search this site for downloads and you'll find it.

Friday, 06 Jun 2008

In case you have been sitting on a desert island recently (and if so, lucky you), you'll have noticed that Microsoft have announced Windows 7. The public and press reception is probably summed up by the word 'underwhelmed' as shown here and here.

What caught my eye was Steve Ballmer saying 'Vista isn't a failure'. Oh yeah? I think even having to say that tells it's own story...

As someone that works for an ISV (Independent Software Vendor) I can tell you than new Operating Systems are like Acts of God like floods, typhoons or earthquakes, but with advance warnings - there's no point in moaning about it, you just need to prepare as best you can.

It's just that, with Vista, it was really hard to see what it gave anyone that was extra. OK, it looks much nicer, but it needs a relatively big, beefy computer to run it, and in many aspects (such as networking) it doesn't interoperate well with XP or Windows 2003, and most importantly doesn't run a lot of applications (derisively called legacy applications by Microsoft) that users want to run.

It seems most of you agree. Here at Serio, only our smallest customers have taken-up Vista, and for these it's not so much a choice as it is what came pre-installed on their newest computers. For companies with more than 300 computers it seems like Vista offers nothing in return for the considerable cost and time in upgrading. What evidence we have for actual use of Vista is discussed here and it's not particularly good reading for Microsoft.

So what about Windows 7 then? Well as far as we can tell it's all about touch - rather than exclusively using a mouse to interact with a computer, you'll directly interact with the screen as you do with devices like the Apple iPhone. We've been here before though, as we blogged about over a year ago.

Personally I take touch screen with a pinch of salt. For a start, it takes a good deal of energy to hold your arms directly in front of you (go on, try it), particularly if your company's health and safety police have moved your screen to the optimum distance away from your face. I can't see users doing this for more than a few minutes before they reach for the mouse again.

Secondly, a lot of people eat at their desks. Muck that is currently sitting on keyboard and mice will end-up on screens as well where you have to look at it.

I have to say that, right now, it's hard not to feel underwhelmed by the prospect of another desktop Operating System. I see Microsoft's need to release one (investor pressure) but I can't see a corresponding user need just yet. 

Wednesday, 04 Jun 2008

This is a follow-up to this earlier post which focused on some of the downsides of running in extended hours. This post however will take a more positive stance, with some of the things that can help ameliorate some of the points made in the earlier post.

Examine your budget, because it probably isn't enough. Lots of factors will come into play such as

  • Recruitment Agency Fees (if you use them). Negotiate a realistic rate and refund period, and plan for higher than usual churn.
  • Training budgets. Inevitably higher staff turnover has a double-whammy effect: it reduces your call throughput (less experienced staff), and increases training charges.
  • Don't spend your budget exclusively on bonuses and allowances, it might not be getting you the best value.

"We under-budgeted, or rather budgeted like it was 2 x 9 to 5. The project suffered for months as a result."

Consider the practicalities. Some staff, those without cars, find travelling at unsociable hours difficult. Whilst at the start of their employment in the bright summer months standing waiting for a 10:00pm bus sounds OK, it might not be so nice in the middle of December. See if you have the funds to offer assisted transport - taxis, minibuses and the like. This can help to reduce staff fatigue and churn.

"The change having the free minibus made on the 6:00pm till 11:00pm shift was significant. It was particularly appreciated by women who no-longer had to travel on late night buses, well worth the £6k a year it cost us."

Check how you are selling the jobs. There's no point in painting an overly-rosy picture. If shift working is unavoidable don't make it seem otherwise. If you are using an agency make sure you understand that your objectives and theirs are not necessarily the same - so make sure you have seen how the positions are advertised. If you like, make a test application to see if potential recruits are being soft-soaped.

Offer a career path. This is closely linked to 'how you are selling the job' above. If you offer this as a lure to fill shift-based you need to be seen to deliver this quite quickly (but remember it's a process rather than an event).

"Setting aside some time for training, and having a structured approach, is key. Training for actual qualifications (technical qualifications like MSCE or ITIL) is useful if you can afford it. The worse the job is, the more you've got to have this. Don't forget it's useful as well because you end up with better-qualified people talking your customers."

Flexible working. It's easy to see flexible working as another complication, but it can help in service delivery as well.

"Having had constant problems with retention, we created a pool of staff. We agree to give them a minimum number of hours each month, and I can then call and ask them to come in at different times. So it might be someone's week off, having worked 12 hours the previous week, and I say ' can you work tonight for 5 hours'. If they can they say yes, if they can't they say no. Then there are others who work longer and more regular shifts. I mix the two up to get a full rota.

It's been useful for women trying to get back into support or customer-service type roles after having children. They like the extra income it gives them, and makes childcare less of an issue if they are working evenings. Some people employed this way have been with us over two years. It was a great innovation".

Thursday, 29 May 2008

If you are asked to set-up a 24-hour support operation, where do you start?

I'll leave Service Level Agreements aside for now, and assume they are in-place. What I'm going to focus on here are staffing issues and staff costs.

There are really two different cases to consider: greenfield site, and an existing operation moving from a more normal 9 to 5 or 8 to 8 to a 24-hour or near 24-hour (for want of a better expression, I'll call this a brownfield site).

Out of these two, the greenfield site seems to easier - you can recruit staff who understand what they are getting into, rather than trying to persuade existing staff to change existing shift patterns. Except, it's not as easy as that, as the comments below make clear.

As part of the preparation for this post, I called a few service delivery managers with 24-hour experience (2 running genuine 24 hour operations, 2 having once run near 24-hour operations, all running Mon-Fri only), to ask what their issues had been, and are currently. Not scientific, but useful none-the-less.

Support staff morale and 'burn' was reported, not surprisingly, as the biggest problem. Some of the comments made are as follows:

"Even when you advertise that the job is shift work on an IT Helpdesk, it doesn't seem to sink-in for a lot of people what it actually means. They just see the 'IT Helpdesk' words and see an opportunity for a career change. Some people are just fine, but others get cranky within a couple of months and start to talk the job and the company down. You're better off letting these people go in my opinion."

"Money is a rotten motivator. Extra cash for working on Wednesday to Friday only works for a couple of weeks, after that sick leave goes through the roof."

"My most important time is still 9:00 to 17:00 but moving support to later and longer hours degraded the service for the core times as well, because the most experienced people left within the first 6 months."

"My biggest mistake was the budget. I had budget to include salaries and a bonus payment based on unsociable hours, and that was it. But each time I recruit someone my agency fees are well over a thousand pounds, and their refund interval is short. My company had a corporate agreement with these guys so I was stuck with them."

"New staff were recruited by our HR department and sent to me 'to save my time'. The new starts became belligerent within the first weeks. It turned out HR was downplaying the shift work element from 'this is a shirt-work job' to 'some shift-working may be required'. This allowed them to tick their box and left me looking like a chump."

"In my case training became a difficult as the people capable of giving the training we not working shifts, but the trainees were. I could devise no solution to this problem."

"In my case we bid for the contract at too low a cost. It was like running a marathon with a broken foot from day 1. Horrible."

I'll follow this post with some of the remedies that have been successfully applied, asking if their were any positives from the experience, and expand this topic buy considering budgets.

Monday, 19 May 2008

Well we've finally got Release 5 out. For those of you who haven't noticed, the Serio Release 5 Website is here. If you've not yet received a download email please contact Serio support – it probably means we have the wrong admin contact on file.

I'm pleased to report that the upgrade process seems to have gone very smoothly for those who have told us they have upgraded. The only problem reported so far has been by a customer who had made their own modifications to the Serio schema – something we tell customers not to do for that very reason (your upgrades will fail). Even then, we've been able to fix the problem.

The feedback has been extremely positive, with the Service Explorer being by far the most popular addition, with PocketSerio-i coming a close second. On the subject of PocketSerio-i, it seems the most popular use for this so far is out of hours support, for engineers on call. Customers log tickets through SerioWeb, and these are then picked-up and worked on through PocketSerio-i whilst at home, in the pub, or at a restaurant. As someone explained to me: 'it means I can do out of the house and do normal things, but still handle any issues that come up and still collect my out-of-hours fee'.

Release 5.1

We've already started work on Serio 5.1, which we are planning to be a smaller upgrade (5.1 has yet to have any kind of date fixed yet). A lot of Diary changes are planned or have already been completed – for instance, Diary changes are now audited, you can colour-code Diary entries, and we are probably going to move the Change Plan Diary and some other items into there as well, giving you a lot of control over what you see. We've also added Diary support into PocketSerio-i (a great, great addition).

We really would like to hear your feedback and thoughts on how we can make the Diary even better.

Aside from the Diary, PocketSerio-i and SerioClient Express will (probably) be the focus for Release 5.1.

A number of you have asked for more customisation options on the Service Explorer (such as customisable colours like in Incident Management). We are going to try something along these lines, so long as nothing detracts from the ease-of-use of the Service Explorer.

Friday, 25 Apr 2008

Sorry for the break in posting, everyone here has been focusing hard on Serio Release 5. It's looking pretty good and will be released on Monday. The Release 5 website is here.

Wednesday, 19 Mar 2008

One of my favourite new features in Serio Release 5 is the Service Explorer. It takes all the data you have in Incidents, Service Requests, Problems, Changes, Items and so on and presents the whole lot in a collapsible tree form.

The best thing is to show you a few pictures. Service Explorer 1

Figure 1 - Browsing Active Incidents in Service Explorer

For of all, Figure 1 showing me browsing to my Active Incidents using the Service Explorer. Notice the graphical columns as well - these are there by default, you don't need to customise them in. One of them shows SLA time to go as a 'progress bar', going from grey to amber to red as deadlines near.

You can display Incidents, Service Requests, Problems and Changes either separately or all together.Service Explorer 2

Figure 2 - Incident expanded in the Service Explorer

Whatever you are working with, it's expandable. Figure 2 shows what the Service Explorer looks like when you expand an Incident. Notice that some key items of data are expandable -like SLA, Item and Customer. This is so that you can easily 'drill down' and get to more data... as shown in Figure 3. Service Explorer 3

Figure 3 - Expanding an Item with the Service Explorer

Here you can see that by expanding the Item, I can see all the tickets we have on file (open or resolved) for Desktop Computer D10001. As these as themselves just Incidents, Service Requests, Problems and Changes they can be expanded as well - revealing their own Change Plans, Checklists, links, documents and relationships.

Service Explorer 4One of the unexpected benefits, for me at least, is that the Service Explorer makes the process of querying and drill-down easier. It offers many different ways of looking at tickets, as you can see in Figure 4 where I can see we've got just a single High Priority ticket open.







Figure 4 - High Priority ticket open in the Service Explorer


Extended Data

Another new feature is what we call Extended Data.

These are additional fields you can attach to tickets of any type. The data is structured, meaning you can have strings, checkboxes, drop down lists and so on, defaulting each if you so wish. As a test, I defined Extended Data for Incidents that is a food survey. Figure 5 shows you me actually entering the data, and Figure 6 shows what the data looks like when you view the ticket in the Explorer.




Figure 5 - Extended Data Editor


Service Explorer 5

Figure 6 - Extended Data field expanded in the Service Explorer

Friday, 07 Mar 2008

With any luck the long awaited Key Element Guides for the ITIL® V3 lifecycle are due out very soon.

Supposedly these “pocket” books are likely to make understanding the lifecycle a little easier…if you have had trouble with Service Strategy (and you are not alone in that I can promise you) I have been told that the Key Element Guide (KEG) on this topic brings it down to the level of mere mortals like myself.

Another TSO publication that helps with understanding the new stuff in ITIL® V3 is the new “Passing your Foundation Exam” book. This is a nice cheap volume and brings the new theory down to a practical level. If you still want more have a look at the Official Introduction. If you haven’t had enough after all that then look at the rather more expensive and technical Core publications. In my opinion, unless you are planning on taking advanced ITIL® qualifications, stick with the more general books.

ITIL® V3 is almost a year old now, the dust is starting to settle and now that the understanding is growing among industry professionals I think there is some good guidance contained therein. I will admit to having been a bit skeptical about the value of V3 after plowing my way through the core books when they were released last May, but the lifecycle approach grows on you and the structure does make good sense.

If you want to get copies of any of the books I have mentioned, they are available through the TSO bookshop or through your local ITSMF chapter. 

Thursday, 21 Feb 2008

It's easy to overlook training.

I can think of a few occasions in my career, particularly during spell I had of short term contract work, where I'd show up for work on a Monday and the Service Delivery Manager would seem quite surprised, usually muttering something along the lines of 'I thought you weren't due till next week'.

Out of a handful of contracts, the average training time I received was 4 hours (a morning usually) and included in that was the dull and often pointless company induction video or a presentation by the HR department. I was usually on the phones dealing with customers before the end of the day.

And it showed. On the whole I think I coped quite well (but then I would say that), however the fact is customers were aware they we speaking to 'the new guy' - and often took the time to explain things carefully to me.

There are many things wrong with this approach slap-dash approach. Here are two of them.

Firstly, it is bad for customers because it's hard for the new start to understand what the problem might be (and sometime understand the specialist terms they are using), it's impossible to resolve the Incident first time and often impossible to ask the right questions for 2nd line support. There's a negative effect on quality that ripples right through service delivery.

Secondly, the new start can't but help to have a poor initial impression of his new manager and employer. Chances are they'll say 'my boss is an idiot' if asked.

So, long before you recruit anyone you need a training and induction programme for the Helpdesk/Service Desk person you are recruiting.

The form this takes will vary. For instance:

  • A training course on the products you support, if you are supporting a single groups of products or services - including sending the new recruit on your customer-focussed training course (even if this is days rather than hours in length).
  • Whatever you do, don't just say 'have a play with Product X' if for whatever reason no training course is available. Instead, set measurable goals that will test learning and understanding.
  • If you are engaged in more general IT support, make sure the new recruit is aware of the services you are supporting and has access to your Service Catalog.
  • Don't expect the employee's call handling and customer handling skills to come complete and perfect. These skills can be honed, as I've mentioned here.

A really good idea is to consider role-plays before any customer exposure. Take 5 or 6 typical cases ranging from easy to difficult, go into another room, and make the calls. This will also help to test how well they can use your ITSM tool.

Most importantly, add training time to the budget allocated for the new employee. It will help you understand what you are losing if staff aren't sticking around for very long - something I'll write about next week. 

Tuesday, 19 Feb 2008

Don't Oversell Availability, warns Peter Warren.

You've maybe never heard of S3, but the chances are you've used a website that uses it either wholly or in part in the last month.

S3 is Simple Storage Service - web content hosting on steriods, and is provided by Amazon. It is used by services like the excellent Twitter, Smugmug and Pownce, and thousands more. It's key selling points are its low cost and high availability - and at the end of last week it suffered a fairly substantial amount of downtime.

As a user myself, I've been surprised by the reaction of the S3 user community who view this like it is the end of the on-line world as we know it. In fact, the service was down for less than 3 hours.

Many users seem to have taken the marketing speak about "ensuring that the data will always be available when you need it" and the reassurances about redundant copies of data on different servers (the much hyped 'cloud') at face value - and have taken 100% uptime as the minimum that they should expect.

Personally I always view these claims in the same way as claims like 'this ship is unsinkable' - it always seems companies lack the imagination to understand where the critical weak-point is. In this case, S3 may (according to some rumours) have suffered a good old-fashioned Denial of Service (DoS) Attack - its authentication server got a gazillion requests and could not keep up. The 3 hour downtime was how long it took Amazon to create extra capacity.

My complaint is really about the way Amazon dealt with this, and I think this might be what is at the root of some customer ill-feeling (some customers seem to be downright unreasonable though).

I got a call in the small hours of the morning to say our website was down. Working from home it was clear that some important files hosted on S3 were inaccessible, but there was nothing from their Helpdesk that I could find on the support site to say either that Amazon knew something was up, or if they did know when it would be back.

This meant I had little of value to say to our own customers.

It took a note on the user forum before we got any word from Amazon. Frankly that's not good enough.

Many users are now asking for service status information. I hope they provide this soon.

I guess the moral of the story is: don't oversell availability, practice your customer response for when the inevitable unavailability occurs, and be very open. After all, I have Service Status pages, why don't they?

Peter Warren is a guest blogger.