Serio Blog

Monday, 03 Sep 2007

This is a follow-up to last week’s post about basic Helpdesk/Service desk call handling. In this article, I’m going to discuss some strategies and approaches you can take if you simply don’t have enough staff to handle incoming call volumes.

Just to recap, the situation I’m addressing is a chronic shortage of Helpdesk or Service Desk staff to actually answer the telephones and deal with customers – and no budget with which to expand the team.


Making sure the phone is answered is arguably  the most important, visible and (for customers) easily discernible functions of the Service Desk. So it makes sense on the face of it to transfer staff from other functions into this customer facing role.

I am aware this may be greeted with resistance, particularly in organisations which are organised along hierarchical rather than project (matrix) lines. Staff can object because posting to customer-facing teams, and away from technical roles, because they see it as a demotion, or dare I say it seems like rather hard work, or because their focus is narrow and they don’t see the need.

If you anticipate resistance, I can suggest a few things to try:

  • Make the secondment period a fixed interval of no more than one month. My personal preference is something like one to two weeks.
  • Ensure all staff, including managerial staff, take a turn  - even of it’s for a shorter period. This is usually a very effective ‘neutraliser’ of staff disquiet.

A word of caution. Don’t second staff without proper training first – and that training should include some test calls. I’ll also advise you to have a Script – which I’ve blogged about here, and here.

Staff Hours/Lunch Rotas/Start Times

One of the things the telephone statistics I mentioned in the last post will tell you if there is a problem with your service times. For instance, if you get calls at 7:30am but your Helpdesk/Service Desk starts work at 09:00 you may need to look at adjusting your service times accordingly.

One thing I’ve noticed is that whilst many organisations (particularly in the UK public sector) have introduced flexible working hours, the impact on essential support services has not always been thought through fully.

As a normal response to this I’d say ‘produce a costed proposal for increased service times’, however as this post was prompted by someone with no extra budget, the only thing I can suggest is to try to re-negotiate start times – possibly by offering something like an earlier start/finish, skipping Friday afternoons – anything to make the prospect attractive.

Make sure also that there is a clear rota in operation over lunchtime, giving you the maximum possible cover. Again you may find that some staff will trade a shorter lunchtime interval for an earlier finish.

Define the Role of Front-Line Staff Carefully.

Are your front-line staff trying to ‘first-time fix’ or simply take and make calls? If you go for attempting fixes for some or all calls, then naturally the amount of time each calls takes is likely to rise. Make sure staff are clear on what you want them to do, and remember you can vary what you do at different times of the day.

If you really are thin on the ground, it makes most sense to me to concentrate primarily on call taking, with resolutions attempts limited to the most simple of things such as password resets. 

Wednesday, 29 Aug 2007

I’m prompted to write today by a customer who doesn’t have enough staff on their Service Desk/Helpdesk taking calls from customers, and who is looking for any strategies to help cope with this. The business is both outbound and inbound sales order processing, with a user base in excess of 500.

My first response, naturally enough, is to suggest recruiting more staff. However, our customer is adamant that there is no budget for this.

So where do you start?

First of all, you need to understand what your current position is – just how understaffed on the front-line are you? You can normally find this out from your telephone statistics (yes, if you ask the right people you can get statistics from your telephone system).

There are a few Key Performance Indicators (KPIs) you need to look at in this regard:

Number of rings before pickup. My opinion is that anything below 6 is OK, anything above 10 is poor. Look at the average and standard deviations. Ideally you’ll get this in graph form. This is because incoming call activity for Helpdesks and Service Desks exhibits natural spikes of activity at different times of the day and week.

Call Abandonment Rate. This is the number of calls where the caller has given up, and not surprisingly it’s linked to the number of rings before pickup. You can think of this as the number of unhappy and dissatisfied customers you’ve had, and is a major KPI.

Voicemail cleardown. If you use voicemail (for instance, it kicks in if all lines are busy, or picks-up after a number of rings) then this can muddy the waters somewhat. What you need here is the number of voicemail messages left, and the time taken (again displayed in graph form) to delete a message (deletion usually being an indication that the message has been actioned). The reason I say that it can muddy the waters is that is either replaces or distorts the Call Abandonment Rate KPI I mentioned earlier.

These three statistics will give you your current position in terms of call volumes.

I’ll post later about strategies for dealing with this, but before I do that I just want to issue a word of caution. There seems to be a tendency amongst Service Desk Managers to play-down the importance of telephone statistics (‘they can log it through the web, so what's the problem?’), but I think this is a bad attitude. If you offer a telephone service it should be ‘fit for purpose’. In addition to this, some users prefer to speak to someone particularly if the Incident is important to them.

In the case of the customer who prompted this article, it might be a front-line sales advisor who needs to earn commission on sales, but is having problems with their IT system and wants to speak to someone. Whatever the situation, customer perception will be damaged no matter good other service provision might be.

Monday, 27 Aug 2007

This week, I’m going to look at how you go about creating your first Change Plan Template. Before that, it’s probably time for a recap.

I’ve been blogging about Change Management recently. The recent posts have covered subjects such as Change Management Definitions, Change Management Scope and Change Management Process, all in an effort to ‘set the scene’.

The Change Plan Template I mentioned above this the name we give to the whole process you enter into Serio – it defines the tasks, what is meant to happen when, standard times, exception handling – everything you would expect to be included in a standard Change. As always, for full information and documentation, please consult the HowTo guide which is distributed with Serio products – you’ll find an entire book there documenting the Change Management subsystem.

There seems to be a temptation to simply sit down in front of the Change Explorer in Serio and try to ‘create a template’. This is not the right approach! Before approaching the tool, you need to have a clear idea of what process you’ll be following, what will be involved, who is participating, what your reporting will be, and have some agreement with colleagues.

In reality then, you should have something written down before approaching the tool. This might take the form of a simple flowchart or a textual description. Whatever you decide upon, it will be something you can visualise before approaching the Change Template editor.

Working with Affected Teams

One of the big challenges facing a Change Manager is the fact that he or she might be changing the way that individuals and teams work both with themselves and with each other. The most obvious example of this is when there is no Change Management process in place at all, and so staff that have been able to entirely control whatever tasks they perform suddenly have a process ‘imposed’ on them, causing ill-feeling and conflict.

It’s usually advisable for the Change Manager to work with affected teams. My advice to customers is to avoid working with the team as a whole, but to select one ‘Champion’ or ‘representative’ to work with the Change Manager in developing a process, who can make decisions on behalf of their team (my experience has been that large groups are not good at decision making).

In summary, Change Managers have to be able to work effectively and communicate well with different groups, and handle situations calmly where people don’t see eye-to-eye. It’s not something you can do isolation (though I know some that have tried).

I’ll post later in the week about the key parts of a Change Plan Template.

Tuesday, 21 Aug 2007

This is a follow-on from last week’s post on the subject of Change Advisory Board (CAB, or sometimes Change Board for short) meetings. This post is going to be on the subject of the meetings themselves, and concentrate on some of the pitfalls and look at some ideas I’ve used.

Firstly, the meeting needs to have an effective chairman or chairwoman – ideally the Change Manager. Except to have to spend at least a few hours beforehand preparing, and be clear about how you wish to handle the meetings. If you are new to the role, ask colleagues to allow you to role-play before your first ‘actual’ meeting.


People will be more willing to attend CAB meetings if you develop a reputation for strict timekeeping early-on. Be punctual – if the meeting is for 10:00, book the room from 9:45 so you’ve got time to clear the laggers out who may still be there at 9:50, giving yourself time to be ready to start at 10:00.

Work out a timed agenda. For example, if you have 20 Changes to examine, and 60 minutes in which to do this, it means that each Change warrants 3 minutes. You can also use a grading system, where more complex Changes get 5 minutes, and more simple or straight-forwards were allocated 2 minutes.

My approach was to have variable length meetings, ranging from 1 to 2 hours. 2 hour meetings had a built-in break at the 1 hour interval. When invites were made to the meeting, I stated the duration (the actual duration being driven by the number of Changes under consideration). I also had a clock which I brought into the meeting and placed on the table in front of me.

My own feeling is that no meeting should go over 2 hours. If for some reason the work could not be concluded within two hours I’d adjourn for another day.


Some companies routinely minute Change Board meetings. I’ve never felt the need for this, but if you do want minutes make sure that someone is there whose sole responsibility it to take and distribute minutes – don’t assume that it’s the job of the Change Manager (something I have recently seen at a customer site). The Change Manager will have enough to do.

Recording Outcomes

If you are going to have any chance of sticking to your timetable, have simple outcomes to the consideration of Change: Accept, Reject, Defer. In each case you’ll want to record notes and comments from your colleagues (particularly in respect to scheduling). Deferment simply puts the Change into a ‘holding pattern’ for the next CAB meeting.

Some companies use a formal sign off document. I’ve tended to go for something less formal – giving each member a tick list, with a description of the Change, an Accept/Reject/Defer tick box and a small space in which to write comments.


It’s normal and healthy to have the membership of the CAB meeting alter during the meeting, as different members step in and out according to the Changes under consideration (which you would have streamed accordingly beforehand).

If people don’t get up to leave when they should, remind them with a gentle ‘thanks for coming, that’s all for you’. Smaller numbers, with relevant interest, will help you hold a successful meeting.

Before the Meeting

Send a summary of what is going to be discussed, and your forward schedule of Changes due to be actioned over the next month (or so). Don’t expect everyone to read it – some will pay great attention, others won’t look at it until the meeting starts. You can usually guess how it will be for different groups, and so is something you can factor into your time estimates.

Have spare print-outs ready for everyone.

Stick to the Agenda

Be ruthless in steering conversation away from this week’s hot issue to the items on the Agenda.

After the meeting

Send a concise summary of the outcomes reached, and estimate when the next meeting will be. 

Friday, 17 Aug 2007

What you save on the swings might be lost on the licensing roundabouts writes Tracey Caldwell

Hardware and software are getting divorced or at least having an open relationship if the excitement around virtual environments anything to go by. For believers, the benefits of virtual environments are anything but intangible. For the uninitiated, if there are any left, virtualisation allows computers to run multiple operating systems simultaneously in different partitions called virtual machines. A single server can replace several and software tasks can be moved around from one server to another.

The possibilities seem endless for IT teams: running different operating systems on one machine, making backup copies while trying out different scenarios and installing patches, backing up employee PCs. Support teams meanwhile are shuddering in horror at the flipside of unregulated and constantly shifting software environments causing havoc with hardware and networking set-ups.

Sceptics might also think that hard disk manufacturers must be loving the explosion of interest in virtual environments but the Ethernet savvy can even run an entire virtual SAN. Collect green points too for switching off the power to multiple real world servers and running multiple virtual servers on one hardware platform.

Virtualisation company VMWare is hot property at the moment as parent company EMC issued 10% of VMWare as shares on the New York Stock exchange on Tuesday. The shares were reported to have shot up in value 76% in one day. Intel and Cisco have already grabbed a slice of the action with six figure injections of cash into VMWare announced in July.

In this virtual world Macs can become PCs and VMWare launched the VMFusion virtualisation product for Apple Macs at the beginning of August against the market leading Parallels Desktop 3.0 for Mac product which was promptly put into beta. VMWare is not the only player in the virtual world of course, with SWsoft’s Virtuozzo, Microsoft Virtual Server and open source Xen generating much real world interest.

Every silver lining must have its cloud though and there have been rumblings, mainly around the idea that the costs saved on the swings are lost on the licensing roundabouts. Security is an issue too with some commentators pointing to improved security through virtualisation while others throw their hands up in dismay at the thought of securing multiple free ranging operating systems.

Computer Weekly’s Cliff Saran has highlighted licensing issues in his blog, pointing out that some companies like Oracle and IBM don't recognise software partitions in their licensing, meaning licences have to be bought for each virtual server.

The licensing issue also threatened to get in the way where companies are buying into hosted software as a service. VMWare has just ticked that box by publishing a licence model for hosting companies to offer services based on the company’s virtualisation software. It will charge a monthly fee, as an alternative to the model that forces hosted service providers to pay the same rate for virtual servers, regardless of how many are operating at any one time. 

Thursday, 16 Aug 2007

My post today is on the subject of the Change Advisory Board (CAB). For many involved in IT the name alone is enough to send people running to hide under their desks, conjuring up images of Sir Humphrey-type obfuscation and bureaucracy.

Of course, it can be exactly that – if you don’t plan it correctly, or have an effective chairman. Approached with a little planning and common sense most of the pitfalls can be avoided.

I’ll start by discussing it’s role, and then discussing if the work of the CAB should be on-line or in a meeting over tea. I'll post next week with some ideas for how to host the meeting.

In my earlier post, I described some of the things that might constitute a Change Management process. One of these involves the Change Advisory Board. The basic function of the CAB is to bring a business and user focus to IT Change by involving users in the approval, prioritisation and scheduling of IT change.

In Person or On-Line?

I’ll start by a trend I’ve noticed here amongst our customers here at Serio – using web collaboration to execute authorisations and rejections of Changes. For Serio Service Desk users, this means enabling the authorisation of Changes through the web. In this scenario, the CAB never actually meets. Instead, when Changes require authorisation the members of the CAB are emailed, they log-in and either authorise, reject or defer Changes.

The advantages are clear: if frees up time in people’s calendars, work can be undertaken at times that are flexible (as opposed to a meeting which is more rigid) and offers the potential for things to happen more quickly (because we aren’t always waiting for the next meeting).

Despite all this, I nearly always advise customers that I am working with the have old-fashioned, sit down, face to face meetings if at all possible. My reasons for this are that it encourages better inter-disciplinary and inter-departmental relationships, and it gives people a chance to air concerns off the record, or informally, that interaction through email or a system like SerioWeb does not. Also, if gives the Change Manager (who will normally chair the meeting) a chance to gauge mood and understanding (end users can sometimes be reluctant to say ‘I don’t understand this’).

Of course, you may also get free tea, coffee and cakes in a face to face meeting.

If your volumes dictate that On-Line is the only option, try streaming your Changes into something like ‘routine’ and ‘significant’. Allow routine Changes to be done on-line, whilst reserving the significant Changes for meetings.

As I said, I'll post next week about the meetings themselves.

Monday, 13 Aug 2007

This is another in my series of Change Management posts. The last one is here.

If you are trying to get your Change Management (CM) process ‘kick started’ you’ll probably be looking for help on getting started.

As always, if you are introducing a new ITSM process you’ll need a process owner – someone who has responsibility for the process itself, and its efficient running. This usually means a Change Manager. Having made your appointment, he or she will help to produce the basic steps in your CM process.

If you are sitting down to create a Change Management process for the first time, the best advice I can give you is to keep it simple. There seems to be something about flow charts that has an intoxicating effect on some people, to the extend that the basic Change Management process is a labyrinthine complex of twists, turns, loops and special cases. If this is what you’ve created I’d advise you to visit it again.

I’d expect to see some or all of the following

  • Initial analysis and filtering
  • Business case
  • Allocation of Priority and Initial Assessment
  • Creation of Impact Assessment, Back-out plans & Resource Estimates
  • Submission to Change Advisory Board (CAB) for authorisation, approval and comment. This is something I’m going to discuss in later posts.
  • Test Build or Implementation
  • Live Build or Implementation
  • Review
  • Update CMDB

Let’s take a look at some of these in more detail.

Creation of Impact Assessment, Back-out plans & Resource Estimates

This is a very valuable stage in any CM process. You simply examine the Change to see which services we offer to customers will be affected, or could be affected – in many cases you’ll be concerned with risk. The Back-Out plan is related to this – if things go horribly wrong, or at least don't behave as we expect, how can we roll-back or undo the Change quickly? It’s worth considering this early-on because it usually affects the things that technicians have to do prior to the Change.

In some organisations, I’ve seen these things produced during the CAB meeting. My personal preference is for as much as is possible to be produced prior to the CAB meeting for the simple reason it makes the meetings easier to chair, quicker, and less subject to diversions. You’ll certainly need this information during the CAB meeting however.

Business case

For Changes that are simply to make business improvement, you need a summary of the improvement you hope to make, along with any cost savings. If the Change is a response to one or more Incidents or Problems, you need information on the business effect (and ideally costs) of these.

Test Build

Some organisations (though by no means a majority) maintain Test Infrastructure – usually grouped together in a Test Server Room. This is where a copy, or mirror image, of live infrastructure and systems are kept – for the sole purpose of testing Changes before promotion to live systems. Although this is off my main subject, both enterprise level and desktop Changes can be handled in this way.

If you don’t have such a facility, it might still be possible (and is usually something worth doing) to perform testing on a platform specially created for the Change. In some organisations, depending on the nature of the Change, this takes the form of User Acceptance Testing.

Friday, 10 Aug 2007

The ingenuity of the home programmer is baffling writes Duncan Davidson.

Last night, I met up with a couple of friends. After talking for a while, I pulled on a flame thrower and went looking for trouble. Within a couple of minutes I’d incinerated a bunch of guys sat in a jeep, and moved on somewhere else with my ‘crew’ in tow, fanned-out in a line army style.

In case you aren’t quite with me, I was playing an online computer game – and all of my victims will live to fight another day (or until tonight anyway). The game in question (PC Halo, very popular with Serio staffers) is one that allows you to work with other players as a team, talk to them, and devise plans and strategies together. Although the media image is of the solitary gamer, modern games allow communication and interaction between real people in a way scarcely imaginable 10 years ago. My crew includes a leading Veterinary researcher, a Serio colleague, a toolshop owner, a computer programmer (me) and a Danish construction worker.

As we moved off to engage the enemy across a barren landscape, we were all picked off by single shots to the head from great distance – something that requires great skill to do.

Closer inspection revealed that our assailant was using what is called an aimbot – an aiming robot – that can be used with devastating results. Removing any elements of skill and spoiling the experience for the legitimate gamer, aimbots infect online gaming, defying efforts by companies such as Valve and others to stamp them out.

Unusually, the source code for the Halo aimbot is available online, although I’ll provide no link to it. Examining this code has taught me never to underestimate the skills of the teenage code bodger - the ingenuity shown is simply baffling.

The aimbot’s author had de-compiled the Halo game executable. I’ll explain what this means. Programmers like me use programming languages like C, C# and Delphi to write programs. These languages are human readable, use words like ‘if…’, ‘for..’ and so on. These statements (which run into many thousands of pages) are then transformed into machine code, which the computer executes. This stuff runs into millions of pages of numbers, and is unreadable to humans… or so I though.

The aimbot author had managed to work out where the game’s authors stored the position of each player. Think about that for a second. With millions of bytes, millions of numbers, he had somehow discovered the array in memory that contained all of the player details. What’s more, for each player, he had discovered what the player data meant – so he knew what direction you were facing, what your speed was…and he know how to access this from another process under Windows – no mean feat.

Computer games like Halo suffer from ‘lag’ caused by network latency – where you ‘see’ something is where it was a fraction of a second ago. To counter this, the aimbot has a system that looks at each player’s network performance and direction of travel and automatically adjusts the aim accordingly – with the impressive results I described at the start of this post.

The author of this software was, apparently, spurred by a comment from the game authors Bungie (now owned by Microsoft) that an ‘auto aiming cheat was impossible’. As I know I’m going to get hammered again tonight by this device, I wish he’d kept his mouth shut.

Wednesday, 08 Aug 2007

This is a follow-up to Monday’s post about Change Management.


First of all, I’m going to discuss the typical scope of Change Management (CM) – the types of things that might be subject to a formal Change Management process. This might include Configuration Items such as:

  • Computer hardware, such as server and desktops
  • Operating systems and other server software such as database servers
  • Routers, bridges, hubs and other types of network infrastructure
  • Documentation, both internal documentation (how to restart your CRM system for example) and end-user documentation (such as user guides and training materials)
  • Application software

Recall I mentioned in the previous post that Configuration Management and Change Management are linked? Each supports the other, but there is also a relationship in content as well. If asked what types of thing should be put into the CMDB, I usually reply ‘Items that should be subject to Change Management’. It works the other way as well – ‘All of the Items in the CMDB should be subject to CM’.

There is one other useful concept of scope – production and development. Things that are in development are, of necessity, not subject to the same control as Items that are in production (and therefore have users). If you consider these kind of development Items are subject to project Change Management -–in effect, subject you your project management disciplines before going into production.

Cost/Benefits Justifications

It can be difficult to produce objective cost and benefits analysis for Change Management (no different really from many other ITSM disciplines). The reasons are obvious – it’s impossible to quantify the value of improvements you might identify in the future, or the costs of Incidents you’ll avoid. One thing you can be sure of is you’ll pick-up additional costs as you develop a CM process, create a Change Manager role, create a Change Advisory Board (CAB), and so on.

If you are asked to justify costs, here’s an approach you can take.

First of all, set some benchmarks for the costs of introducing Change Management – in much the same way you’d cost any other project. Estimate the number of hours that will be spent, assign typical hourly costs, apply any capital expenditure, and produce a cost estimate for establishing Change Management over something like a 2 month period. I’d limit myself to the costs of getting to the point where we have a CM process for the simple reason that those costs are more easily identifiable, and that the ‘running’ costs are likely to be moderate.

Next, examine your Incident records for Incidents that have been caused by Changes that have been executed incorrectly in some way – something I’m aware that might be somewhat easier to write about and describe than it is to do. Ideally you’ll have been flagging these at the point of resolution for some time, so the ‘set’ of Incidents you’ll work with is easy to come to.

For these Incidents, estimate a very rough cost. You can do this by using downtime as a guide, and looking at one of my previous posts about the costs of unavailability.

What you can then do is compare the costs of the problem with the costs of the cure. I’ve seen someone try to quantify (in monetary terms) the value of future improvements but have never supported this approach as you may as well use a random number generator – it’s not objective in any way.

I’ll continue these posts later - either this week or next.

Monday, 06 Aug 2007

This is going to be the first in a series of posts about Change Management. I’m going to be writing for those that currently have either no Change Management process, or those that do but feel they could do things better. I’ll also be branching off from time to time to look at different aspects of the Serio tool.

Changes come about as ‘outputs’ from Incident Management or Problem Management – or quite often simply because we want to make improvements in our IT infrastructure to better serve the business.

Purpose of Change Management

The purpose of Change Management is:

  • to minimise the impact of Incidents upon the business that might occur through Change implementation
  • to have a standard, effective, repeatable way of assessing and managing the implementation of Changes to IT services and infrastructure
  • to seek business benefit and improvement

Your Change process will (most likely) have some of or all of the following:

  • an assessment of risk
  • an impact assessment
  • communication with business stakeholders and/or user communities
  • assessment of resource requirements
  • cost and benefit analysis
  • business opportunity assessment

Change Management and Configuration Management

I’ve blogged a lot about Configuration Management and the Configuration Management Data Base CMDB (search the blog for CMDB and you’ll find them). The two processes are linked. It’s something that I’ll probably come back to in more detail in later posts but if you consider for a moment something like an impact assessment, you need to ask yourself how you can do that without the level of detail and documentation that a CMDB provides. For instance, without a CMDB you may simply need to ask someone (usually a tech guru) about impact – but where does your tech guru get his information?

So, if you are thinking about implementing a Change Management process, you might also find you need to consider a Configuration Management process as well.

Prime Movers for a Change Management Process

My experience with customers has tended to show that the main driver for more formal procedures is a feeling that Changes cause too many Incidents – in other words, Changes are not planned carefully enough, tested enough, and are implemented too quickly.

It is a shame that this is a key driver because it makes it is easy to overlook Change as a vehicle for delivering business benefits, something I usually try to advise customers to ‘build-in’ to their process by having specific (usually small) focus groups that have as part of their remit to be outward looking and to be agents of innovation.

My next post will look at what should be covered by Change Management, and cost benefits/justification.