Serio IT Service Desk & Helpdesk Blog

…or put another way, ‘How to Survive and Prosper when your Working World is turned upside down’.

I suppose it’s possible that some readers of this blog will have had a happy, or at least not unpleasant, experiences whilst working in IT and their company is the subject of a takeover or merger.

I have to say that in my career this hasn’t been the case, nor do I know anyone who who hasn’t found the experience troubling or stressful. At the root of the problem is a simple fact: your working situation can be changing radically, and you usually have little or no power to influence things.

Survivors Guide

1. Survivors Know Who is Actually Calling the Shots.

In a take-over (your employer is sold to another company) it’s obvious – the managers from the purchasing company have control. Mergers are more tricky. Even when mergers are said to be ‘of equals’ in my experience there is usually one of the pair that is simply absorbing the other. Try to find out which is swallowing the other. You can assess this usually by looking at the Directors and senior managers, – who is keeping their jobs (implies the one doing the swallowing) and who is taking the ‘new and exciting roles’ (implies the one being swallowed). Other clues might be the change of office (my place or yours) and whose brand survives.

2. Survivors are Cheerful and Stupid.

In a situation where you are maybe feeling stressed or nervous about the future, it’s easy to fall into the trap of getting cross easily, viewing the other company as enemies, and being over-sensitive. Being Cheerful and Stupid means simply never assuming the worse, being slow to see insults, and avoiding alienating your new or existing co-workers. Even if your new colleagues do something you don’t like, or you feel that undermines your position, ignore it.

True story: Many years ago, the company I worked for was taken over by a large multinational, at a time when I was running the product development team. A guy showed up one day, and without introducing himself to me asked our receptionist for my and my team’s CVs. My reaction was to very nearly punch this guy’s lights out. This made me feel a little better but served no useful purpose at all. Cheerful and Stupid would have been a better approach: ‘certainly Mr Secret Squirrel – here you go!’.

3. Survivors Know that it is Every Man (or Woman!) For Themselves.

It’s a bit unseemly, but a merger or takeover can be like a big scramble for the life boats on a sinking ship. Your best policy is to look after yourself – don’t expect your boss to do that for you, regardless of how well you know them.

4. Survivors Make Friends.

It’s easy for an ‘us and them’ mentality to develop, and it can be hard to even be civil at times. This attitude though doesn’t do you or the company any good so try to make friends, particularly with ‘the other side’. Try to connect with their social networks – for example, if they have a sporting team try to join it, if if there is some other social grouping try to become a part of it. If they plan LAN Computer games after work ask if you can be part of it – but remember, be Cheerful and Stupid if they say no.

5. Survivors Don’t Take any Holidays for the First Six Months.

I have no hard statistical evidence for this, but a lot of people seem to be fired or made redundant after returning from holiday – it just seems easier to do when you are not around. As the period after a merger is a scramble, it doesn’t make any sense for you to not be around as things start to settle down.

6. Survivors Know How Expensive They Are.

It isn’t just a merger of cultures and people you get. Sometimes when companies merge or are subject to takeover you get a merger of approaches to salary and remuneration. Try to find out where you stand. If you are paid substantially more than a similar worker in the company that has taken you over, it might be that you’ll be shown the door regardless of what you do. In this case, you might be able to negotiate a better severance package – but regardless, it’s information you need to know.

A good source of information might be by looking at any recent recruitment advertisements the other company has placed over the last six months. Another tell tale sign is the number of empty vacancies that the other company has – a high number is sometimes indicative of lower than average salaries.

7. Survivors Constrain Their Personal Expenditure.

Part of the deal with mergers is the stress they cause. My view is that most of this comes from people being subjected to sometimes quite radical change in their jobs, and having absolutely no way to influence or control that change. Another source of stress is the more prosaic ‘how will I pay my bills if I loose my job?’. A way you can reduce this stress is simply taking an axe to your outgoings (not literally). If you’ve recently bought a new car, see if you can get rid of it without taking too large a hit, if you were taking a holiday see if you can cancel and get most of all of your money back (see also point 5).

Reducing your expenditure will make you feel less dependent on your monthly pay check. This will reduce your stress level, and allow you to more easily make friends and be Cheerful and Stupid.

8. Survivors Engage With Customers.

Without customers, most businesses will shrivel up pretty quickly. Being engaged directly with customers, and having a direct and valued relationship with customers, immediately elevates your standing within any company. It doesn’t make you indispensable, but it does give you something extra.

If a customer is particularly pleased with something you’ve done, don’t be afraid to solicit the customer sending an email of praise about you to your boss.

9. Survivors Have Their CV Up To Date.

Everyone needs a fall back position, so now is as good a time as any to bring your CV up to date.

In doing so, avoid developing a negative attitude to your employer. See points 2 and 4.

10. Survivors Sell their Office Supplies on Ebay

Aside from providing Scott Adam’s Dilbert with hundreds of strips, you may find that everyone is too busy focusing on CVs, making friends and watching their backs to notice that the premium envelops keep disappearing (warning: this may not be legal in all jurisdictions).

Something two of our customers have started recently, and been kind enough to share with me, has been the placing of Test Calls on a Helpdesk/Service Desk. I’ve used their comments to prepare this Blog post (so thanks!)

By Test Calls, I mean that a number ‘fake’ or ‘manufactured’ calls are placed anonymously and a number of aspects of the call analysed.

For me what is interesting is that I’d not encountered any company that regularly placed Test Calls up until two years ago: since then there has been quite an upswing.

The reason is an increased value being placed on intangibles – stuff you simply can’t measure directly with normal metrics, and a desire to more fully understand the customer experience. You’ll find more about this below, but by intangibles I mean clarity of communication, courtesy, and so on. Whilst at the moment I’m seeing this in the ‘paid support’ world, it probably isn’t long before it crosses over into the in-house support function.

Some Tips for placing Test Calls

1. Announce What You Will be Doing. Make sure everyone knows Test Calls will be made, and from what date they can expect them (but there’s no need to tell them on what days, or announce them beforehand).

2. Keep it Legal. If you are recording the conversation, you will may need to advise staff of this – check the legal situation regarding disclosure of recording in your country. Regardless of the legal requirement, I think you should advise of recording as a courtesy.

3. Set your goals clearly. Make sure you are clear about what ’success’ factors you are looking for in your test call. Success factors might include:

• Courtesy
• Speed of answering (if you don’t have independent statistics from your telephone system)
• Ability of the Service Desk Agent to speak clearly. For instance, did they control the call? If they are using headsets, is the mic correctly positioned? Was there an excess of background noise?
• If you have a script was the script followed?

The closer you can get to a scorecard you complete at the time of the call the better. Try something that allows a simply 1-5 score to be recorded against each call aspect, along with and caller’s notes.

4. Keep the call simple. Your best bet is not to make a call that involves something elaborate, but rather something simple – maybe a password reset, or a printer problem – something you might hope would be dealt with well.

5. Make Sure You Explain Why. Be clear about why you are placing the test calls – for quality and training purposes. Be clear that poor results will result in training as opposed to dismissal.

6. Create a Test Call Calendar, so that your Test Calls are placed at different times of day, and at reasonable intervals, and ideally when different members of staff are taking calls.

7. If something unsatisfactory is detected and a follow-up required, make sure you do this within 24 hours of the test call being placed.

Technorati Tags: ITSM, IT Service Management, Customer Service

• Incident Management – how good are you at taking calls?
• Incident Management – how good are you at taking calls? (cont)

This is a follow-up post on the subject of start-ups and acquisitions, which was posted in the middle of July.

That post looked at what happens of your support operation is suddenly faced with the appearance of a new company (which I called NewCo), and some of the questions you can ask if you are trying to make sense of how this new organisation might affect your IT support service.

This post will address the question

‘how do I incorporate them [the new company] into our support system?’

…which is the question our support service gets asked most often in connection with this. So before continuing, you might want to go back to the other article and re-read the questions listed – hopefully they will add a little perspective.

1. Do you need to add the new company at all, or do anything? This might well be the conclusion you draw, so don’t feel compelled to make any changes or additions to your ITSM system. It might simply be the case NewCo set’s up it’s own completely distinct ITSM system, and everything continues as before.

2. Add the new company NewCo as a Service Team. As mentioned in the earlier post, the issue here is one of control. Adding the IT support staff of NewCo as a Service Team (like your existing first line, network or other teams) is perfectly OK but it does imply control within the existing IT management framework, in as much as Incidents can be assigned to them, and they will be subject to the same expectations, SLAs and metrics as other Teams.

There will also be a degree of information sharing, as usually NewCo will usually be able to see shared information like your CMDB, Knowledgebase documents and ticket pools. Usually this kind of information sharing between teams is a good thing, but consider if there are any confidentiality issues to address.

3. Add the new company NewCo as a Supplier, and use Supplier Management (you’ll find lots of articles about Supplier Management in this Blog).

Setting the NewCo IT support function up as a Supplier is useful if you have no control over how they operate (in other words, they are like a black box) but you still need to be able to pass Incidents, Service Requests and Changes between the two in a structured way. Setting-up NewCo as a Supplier will also allow you to collate supplier related metrics, like the number of tickets currently assigned, or assigned in the past month. Generally this kind of approach can side-step the politically sensitive issues alluded to in the earlier post.

Technorati Tags: IT Service Management, ITSM, Helpdesk

• Acquisitions and Start-ups from an ITSM perspective
• Making a Start with ITSM Reporting
• Getting Started with ITSM

This post is for anyone who has ever been a bit confused about IP ports. Whilst most people I deal with have no problem understanding what they are and what they do, there have been a few cases recently where it would have been useful for me to refer to a post like this for background.

If you want to read about layered networks or IP in detail there are loads of resources – like here for example. I’m just going to deal with some of the practical aspects folk who work in IT support have to deal with.

TCP/IP is what is referred to as connection-orientated. That basically means it’s for connecting computers together…

…except that this is not quite true. It’s really for connecting applications running on computers together. And computers have more than one application running, which is one of the reasons that we have Ports.

Starting at the Beginning

You will have seen IP addresses – 123.42.1.234 for example. You also probably know that machines have names, and that names ‘resolve’ into IP addresses. For example ‘ping zephod’ might resolve into ‘ping 123.42.1.234′ (there is usually a server sitting somewhere on your network that takes names and returns IP addresses by doing a simple look-up from a list).

You are probably also familiar with either using an IP address to ‘connect’ two applications together. You might do this for example when you set-up your email client software to read your emails at home – one of the things you specify is the Name or IP address of the email server. Get that right, and the chances are you can access your email.

This IP address allows your email client software to ‘talk’ using TCP to your email server, allowing the two to exchange useful information because the email server is ‘listening’ for requests from email clients, and returning useful data back.

Ports Connect Applications

But consider this problem. That email server whose IP address you entered doesn’t just run an email server. It almost certainly runs a web server as well which is also listening for requests from clients (browsers), it probably also has a database running called MySQL that also is listening for requests, and so on. In fact, if you count all of the different applications listening it may well count over 20, with the possibility of having even more.

So this begs the question: when your email client program wants to send a request to the email server application running at the IP address you specified, how does it avoid sending the data to the web server instead?

The answer is Ports

Imagine a large high-rise building with 120 flats (apartments). The address of the apartment building is 100 High St, Livingston. If you want to send a letter to a Mr Joe Bloggs who lives there, you’ll need more than ‘Mr Joe Bloggs, 100 High St, Livingston’ because the postman won’t know which of the 120 mailboxes to put the letter into. The correct address is ‘Mr Joe Bloggs, Flat 25, 100 High St, Livingston’. In this example, the 100 High St part of the address is equivalent to the IP address, and ‘Flat 25′ is the Port number: the final piece of the jigsaw. If you don’t specify a flat, or specify the wrong flat number, the chances are your letter will not be delivered.

Why don’t I need to specify, or know, the Port number when I enter the IP address into my email client software?

The answer is because of convention. By convention, certain types of programs always use the same Port. So email programs typically know what Port to use. Some common standards are below:

20 FTP
22 Secure Shell
23 Telnet protocol—unencrypted text communications
25 Simple Mail Transfer Protocol (SMTP)
42 nameserver
53 Domain Name System (DNS)
57 MTP, Mail Transfer Protocol
79 Finger
80 Hypertext Transfer Protocol (HTTP)
110 POP3 (Mail)
161 SNMP

What about Ports used for Sending Data?

Ports are also used for sending data, but unlike applications that listen for data (like server applications of all kinds) the send Port is usually not significant. The reason is simple: when you send your request to the server application, you will send both your IP address and the Port you send the data from, meaning it’s easy for the server to send a reply using this information.

(Thanks to DuncanD for his help with this)

Technorati Tags: Technology, TCP/IP