The Robert Test

"The Robert Test"

 

First of all, I'm getting the big confession out of the way. This idea is stolen shamelessly from Joel Spolsky's famous "Joel Test" for rating the quality of a software team. As he's a programmer and I'm a system administrator, it may not come as a shock for you to hear that I've knocked out a test based on his idea that is designed to rate the quality of an "IT Support" function in an organisation.

I'm not as strict as Joel however, 8 out of 12 is a passing grade on the Robert Test and over 10 is a good score. Less than 8 however, and you've got big problems. If this is a job you are interviewing for then run, don't walk, away. In case anyone is interested, I score my current place of work at 10 out of 12.

 

I hope this is useful to anyone considering a job in a new place, or who already works there and wants to make some improvements, or maybe to people who wonder if their IT Support team can actually fix computers or not.

 

• Do you have a "Service Level Agreement" with your users?
• Does the IT Support dept. have a "board level champion" who will support causes for the IT Department, and also listen to board level feedback about support issues and pass it on?
• Do you use a call logging / management system?
• Can you track call history through this system and analyse trends in support issues using this system?
• Can 1^st line support staff easily communicate with 2^nd line support staff, and vice versa?
• Does someone in the team (preferably the person in charge) actually talk to users to find out what their needs are?
• Do users get notified at all times who "owns" their call so that they know who is responsible for helping them solve their issue? And would they how to contact their call owner?
• Does your second line support team have a quiet working environment where they can concentrate on problem solving in peace?
• Do you have a "stock control" database that lists all assets you are responsible for?
• Do you provide the tools your team needs to do their jobs?
• Do you encourage and support your staff's continuing professional development?
• Does everyone on your team know why everyone else on the team is there? Or at the very least, where they themselves fit in?

Now I've told you what the 12 points are, I want to look at each one in more detail.

 

• Do you have a "Service Level Agreement" with your users?

A service level agreement is one of those boring documents that no one in their right minds would ever read.  But that doesn't mean you do not need one.

 

SLAs are designed to do two things. Firstly they tell your users what they can reasonably expect from you, and secondly they tell you what you can reasonably expect from your users.

 

This is the place where you can point out to your customers that you will respond to their calls within a certain amount of time, and that some calls will always be fixed within a certain time, and some calls where it is impossible to predict a time to fix will be guaranteed a response but not a fix.

 

For example, calls that require development work such as expanding the scope of a major database should be taken "out of band" from the helpdesk, treated as a proper programming project, and therefore given their own spec and schedule. If a request for this kind of work is raised via the helpdesk the user who made the call has a right to a response in a reasonable time, but a fix (e.g. the development work completed) is not within the scope of a helpdesk call.

 

A SLA should be fair to both parties and should be a tool to help users and their support staffs understand each others needs and pressures. It should not be something that's designed to allow one side to continually beat the other over the head.

 

• Does the IT Support dept. have a board level "champion" who will support causes for the IT Department, and also listen to board level feedback about support issues and pass it on?

To some extent, this should be self-explanatory. The IT support department has to be able to enforce rules and policies across all areas of your organisation, and to do this effectively requires backup in the board-room. I can't say it clearer than that.

 

This person should defend the IT department to the rest of the board, they should "lead by example" and encourage other directors to do the same, and lastly but perhaps most importantly they should of course be receptive to any IT problems that get raised at board level and ensure these problems are dealt with as efficiently as possible.

 

• Do you use a call logging / management system?

Joel Spolsky said it best in the article that inspired this one, except he was talking about a bug tracking database. But then what are helpdesk calls about, if not bugs in your network?

 

"I don't care what you say. If you are developing code, even on a team of one, without an organized database listing all known bugs in the code, you are going to ship low quality code. Lots of programmers think they can hold the bug list in their heads. Nonsense. I can't remember more than two or three bugs at a time, and the next morning, or in the rush of shipping, they are forgotten. You absolutely have to keep track of bugs formally.

LOR: black; FONT-FAMILY: Georgia">Bug databases can be complicated or simple. A minimal useful bug database must include the following data for every bug:

• complete steps to reproduce the bug
• expected behavior
• observed (buggy) behavior
• who it's assigned to
• whether it has been fixed or not

If the complexity of bug tracking software is the only thing stopping you from tracking your bugs, just make a simple 5 column table with these crucial fields and start using it." - Joel Spolsky

I could write something similar to this, substituting "Helpdesk call" for bug, but you are all smart people, you'll figure it out.

 

Actually, I've looked at FogBugz from Fog Creek Software (Joel's company) and in addition to being a fine programmer's bug tracking tool like it's supposed to be, I'd also recommend it for anyone wanting to start a small helpdesk team who needs some call tracking software.

 

• Can you track call history through this system and analyse trends in support issues using this system?

If you can't do this then you cannot track how your network is developing over time, how problems are dealt with and if they are systemic. If you can't do that then you are not managing your network. You are just fighting fires on a daily basis and that's not the same thing at all.

 

• Can 1^st line support staff easily communicate with 2^nd line support staff, and vice versa?

I've worked in some places where the junior and senior levels of support staff were discouraged from talking to one another, except through a couple of carefully controlled and defined channels, anyway.

 

I've also been a customer of places that work this way. Their service sucked simply because you spent all day being bounced from one place to another instead of being helped. An arrangement that looks pretty on the org chart is not the same thing at all as an arrangement that leaves your customers feeling that all your team are there to solve their problem.

 

• Does someone in the team (preferably the person in charge) actually talk to users to find out what their needs are?

If your department doesn't listen to what the users need, they won't take you seriously. If you tell them they cannot have something they need then they'll either complain about you all the time and rightfully so, or they'll get creative and find ways to get around all the rules in order to buy what they need themselves.

 

Then one day you'll realise that you have 100 more SQL servers on site than you realised, and the reason you found out will be because of a new version of the slammer worm infecting these servers you didn't know about and bringing your network to its knees. And that'll be your fault too… remember users expect us to be omnipotent?

 

I should add at this point that the person who talks to the users to find out what they want from the IT Support department should understand the difference between "Want" and "Need". And they should make it clear to the users that they understand, too. If they are really smart, they'll even understand that sometimes you have to say yes to a "want" too.

 

• Do users get notified at all times who "owns" their call so that they know who is responsible for helping them solve their issue? And would they how to contact their call owner?

File this one under plain old good manners. But it's a bit more than that. If a user is kept in the picture about how a call is progressing then they feel reassured because they can see something is being done. Even if the "something" is the call being escalated from one level to another without any tangible fix coming back to them, they still feel good about it because they can tell you are taking their call seriously.

 

In most helpdesk software, it isn't difficult to include an email notification to a user when the person in charge of a call changes if you don't want to impose on your staff to have to spend time composing personal messages to customers or to make phone calls all the time. If possible you should consider also allowing the users to review all the notes you hold about their call, but this might involve some re-training of helpdesk staff and some tidying up of your current database.

 

• Does your second line support team have a quiet working environment where they can concentrate on problem solving in peace?

Knowledge workers (and top level support staff qualify for this title even if you think entry level ones don't) need peace and quiet to work on in-depth problems. Tom DeMarco covers the costs of interrupting knowledge workers who are 'in the zone' quite well in his book, "Slack", so for more reading I'd suggest hunting down a copy of this book and having a good read.

 

In a lot of small to medium sized companies, and even quite a few large ones, the 2^nd line support team for an area is also at least partially also the planning team for future work and expansion in that area. Even if you don't accept someone working on a support call needs peace and quiet, it must be obvious that someone working on an important expansion plan that requires a lot of disruption downtime and capital expenditure should be given the peace and quiet they need to concentrate on getting it right!

 

• Do you have a "stock control" database that lists all assets you are responsible for?

If you don't even know what you are responsible for, how can you possibly be responsible for it? Would you even know if an asset was stolen if no one saw the thief take it? Are people throwing away old broken down kit without tracking it's disposal? Do you have an electrical safety testing schedule that you should follow but you can't because you ain't got a clue what stuff you own?

 

If a "No!" to any of the above questions describes your department, then Robert the fortune-teller sees auditors, arguments, disciplinary proceedings and pain in your future. If you can't bebothered to do this to give your users decent safe equipment then do it for yourself so you don't get fired when things go wrong.

 

• Do you provide the tools your team needs to do their jobs?

Can your staff get things like TechNet or O'Reilly books purchased if they need them? And no, I don't mean buying it themselves. Nor is it ok to make them shop for books in their own time all the time and claim the cost back in expenses that take 3 months to come through. With the wrong amount on them.

 

Ok, what about tools like LAN analysers and security testing tools, if they can demonstrate a need for them that is. If you don't give your staff the tools they need to do their job, don't be surprised if they struggle to do their job, or even fail outright. And providing they made you aware of their needs that would be your fault, not theirs.

 

• Do you encourage and support your staff's continuing professional development?

If your organisation plans to expand or at the very least stand still, which is about the same as expanding in today's economy, then the IT Department will need to grow to meet new challenges. In order for your IT Department to grow, the people need to grow.

 

Worried that someone will take all the training and experience you give them and then leave? Well then, your problem isn't that you trained them enough to get a job elsewhere; your problem is that you have another issue in your workplace that's driving them away. Are people comfortable? Are they happy? Do they think their opinions matter? Or maybe this is your problem…

 

• Does everyone on your team know why everyone else on the team is there? Or at the very least, where they themselves fit in?

If people don't understand how their job works, how it relates to others around it, what their chances for a career are, what their responsibilities are, then they won't be happy. And if they don't understand how the overall organisation works and how the IT function fits into that, they won't be able to deliver a great service to the users.

 

And if they come into work every day, don't have a clue what they are doing because no one ever tells them anything, and if they get yelled at by users because they don't understand the simplest things about the users' requirements then they will get pissed off and leave. It's not rocket science is it?

Top