Benchmarking and Customer Satisfaction

If part of the purpose of your job is to spread the use of information and communications technology, it's a good idea to start collecting statistics in order to benchmark your performance.

This article looks at a fairly simple approach to benchmarking which does not take long to implement, but which can be extremely useful.

It is true that you could content yourself with collecting statistics on how many people are using the educational technology facilities, but I regard that as necessary but not sufficient. For a start, it tells you nothing about the quality of what people are doing, and it is more than likely that if you start to insist on high standards of work, or even merely that colleagues do not use the computer facilities as a fall-back when they don't have a lesson planned, you will start to see a fall in the amount of usage -- at least in the short term.

Furthermore, there is little you can do about increasing the usage until you know why people use or don't use the facilities. Hence, some deeper probing is required.

A very good "way in" is the customer satisfaction survey. If your school or organisation has a history of poor performance and bad experiences in this area, you may feel that to carry out customer surveys would lay yourself wide open to criticism, and therefore be the last thing you'd want to do. In fact, in those circumstances finding out what people like and dislike  about the service on offer is even more essential.

There is another dimension to this as well. In general, although people are often happy to criticise someone or something when in a crowd, and anonymous, they are usually much more considered when asked to do so in writing, and with their name attached to it. In one of my jobs, the IT service was constantly being criticised by Headteachers: not directly to me, but to my boss. As well as being upsetting for me, it was also upsetting for my team, who tried to do a good job and, from feedback they received whilst in school, thought that they were. Once I'd implemented the customer survey regime, my boss and I had a couple of the following sorts of conversation before the unwarranted criticisms stopped altogether:

Boss: At the meeting today, the Headteachers were complaining that your team take ages to respond to a call for assistance, and never complete the work properly.

Me: That's strange, because according to the customer satisfaction records we've been keeping, 95% of the schools rated our service as excellent, and the rest rated it as very good. Was there anyone in particular who was leading the complaints?

Boss: Yes, Fred Bloggs.

Me: Hmm, that's a bit odd. Looking at his last completed customer survey sheet, he said "An excellent service. The technician was really helpful and fixed the problem with no interruption to the school's computer network at all." Would you like a copy?

Now, there was no intention on my part to stifle criticism. However, I think that if you are going to criticise someone, especially when potentially people's jobs are at stake, you need to be very specific about what was wrong. The trouble with educational technology is that people have come to expect the same level of service as they enjoy from the electricity board. And so they should, but they do not always understand the wider forces at work. Thus it was that when an internet worm knocked out computer systems all over the world, my team got the blame! When things like that happened, the Headteachers would complain in their meetings with the boss that the IT service is useless, not realising what the real causes were. Given that on no occasion, as far as I know, did any of them contact him out of the blue to say "The IT service is fantastic today!", the impression the boss had was that we were not doing our jobs properly. The implementation of the customer survey approach counteracted that by being very specific, and by providing hard evidence of how Headteachers found the service in general over the long term, as opposed to how they felt immediately after the most recent virus alert.

OK, so how do you conduct a customer survey? I would suggest that you ask people to complete a very simple form, and sign and date it. Then transfer the details to a spreadsheet, which won't take long once you have created the spreadsheet in the first place. You will then be able to generate useful statistics.

The questions themselves will differ according to the nature of the service you are running, of course, but if you are an ICT Co-ordinator (Technology Co-ordinator) I would suggest the following items be put on the form:

1. Name of teacher
   
   
2. Class
   
   
3. Date
   
   
4. Subject
   
   
5. Was the room tidy when you entered it?
   
   
6. Was the system too slow/fine?
   
   
7. How easy was it to achieve what you set out to achieve? Very easy/very hard
   
   
8. Please add a brief explanatory note, especially if it was very hard.
   
   
9. Any suggestions as to how the facilities or service could be improved?

As you can see, a very simple form, which not only helps you to obtain some information in a consistent manner, but also indicates pretty clearly what your own concerns are --  the room being left tidy, for example.

I’d strongly suggest you assign numerical values to the responses (EG 1 = Very Good) and use a spreadsheet to collate and analyse the responses, because it is easier to calculate averages where necessary.

Run this for half a term, and see if you can spot a pattern emerging. If so, it will help you to prioritise future developments.

How helpful did you find this article? Please leave a comment. If you like the customer focus approach, you will probably find this article interesting too, and this one on the Framework for ICT Support.

An earlier version of this article was published on 16th September 2008.

31 Days to Become a Better Ed Tech Leader -- Day 27: Review Your Technical Support

A task a day for 31 daysIt stands to reason that people aren't going to use the technology if it's unreliable (or reliable only in the sense that it is certain to go wrong), or that getting a problem sorted out takes ages.

Therefore today, I have just one question for you: what is your technical support like?

It shouldn't come to this...In my opinion, the best technical support is that which is completely invisible. Things tend not to break down because only the best was purchased in the first place, and because the technical support folk are proactively monitoring and maintaining all the systems in use. When, in the unlikely event a piece of equipment does go on strike, it's replaced within hours, or even faster.

Is that a counsel of perfection? Is it pie in the sky? I don't think so; in fact, I know it's not the case because I've seen ordinary, urban, working class area schools achieve exactly that. Yes, even primary schools.

So again, I challenge you: what's your technical support like? What would you like it to be like? What needs to happen in order to bridge that gap?

Check out the References section for other articles which may be useful to you on this topic.

Photo by Linusb4.

FITS For The Purpose

If you had to think of one aspect of the development of information and communication technology (ICT) that is either not addressed, or which is addressed as an afterthought, you'd almost certainly
come up with the answer "technical support". Yet a moment's reflection is enough to make anybody realise that achieving the government's aim of embedding ICT in the curriculum would be impossible without a robust infrastructure and hardware set-up to support it. And that is, if you think about it, a fairly mundane aspiration. Once you start to consider the more visionary aspects of ICT in education -- building schools for the future, the classroom of the future, the Every Child Matters agenda and the
education, e-learning and digital strategies -- it surely becomes apparent that without a rock solid foundation, all such dreams will remain just that: dreams.

There is another wayIt has long been the case that the teacher in charge of ICT has been expected to keep everything ticking over with virtually no budget and very little time -- especially in primary schools.
Part of the reason is that the true cost is often hidden: such is the professionalism and dedication of teachers that they will often work before and after school -- and through their lunch break -- sorting out problems such that colleagues often seem to assume that the systems run themselves.

To add insult to injury, it's a truism that nobody ever picks up the phone to say, "the network was working great today!", and they don't make those sorts of comments in the staffroom either.
So, whilst the ICT co-ordinator is slowly but surely driving herself into the ground, the word on the street is that the systems are unreliable and the ICT co-ordinator is useless.

It doesn't have to be like that.

It's generally assumed that technical support is a purely technical matter. However, like any other aspect of school life there is a management side too. Whilst reliable equipment is obviously an important factor in the smooth running of the ICT facilities in a school, it's not the only factor. Indeed, in certain circumstances it is not even the most important factor.

There is a law of physics which states: nature abhors a vacuum. This adage applies just as much in human affairs as it does in the physical world. In short, if you don't have proper systems in place for ensuring that technical problems and maintenance are handled efficiently, a system will develop anyway. And it might not be the one you would willingly choose.

For example, how do staff let you know there's a problem with a computer? Chances are, they will grab you in passing in the corridor and tell you. Their faith in your powers of memory is truly touching, but the only outcomes of this so-called "corridor culture" are wrongly prioritised jobs and disenchantment.

For example, you fix a printer jam and put the little matter of the network crash on the back burner. And then, when you forget to act on one of these chance encounters, you start to get a reputation as someone who does not deliver.

A variation of the corridor culture is the senior manager syndrome: exactly the same scenario, but with a deputy headteacher pulling rank. That's how the deputy's colour certificates for the ping pong championships somehow get printed before the SATS revision material is uploaded to the school's
intranet.

In the long run, of course, the same problems occur time and again because nobody has the time to step back and look at how often particular problems occur, or in what circumstances. Basically,
there is no planned system, and no strategic overview, just constant reaction to one near-crisis after another.

There is another way.

Becta has devised the FITS -- Framework for ICT Technical Support -- programme to address all of the problems mentioned, and more. 

Taking a system that has been developed and refined in industry over twenty years, Becta has come up with a set of systems which can be implemented in a school methodically and even reasonably quickly.

There are ten FITS processes altogether:

• Service Desk
• Incident Management
• Problem Management
• Change Management
• Release Management
• Configuration Management
• Availability and Capacity Management
• Service Level Management
• Service Continuity Management
• Financial Management

I don't intend to go though all of these processes in any detail -- there is hardly any point in attempting to replicate what Becta have already so admirably done. But it is worthwhile picking out one or two elements in order to give you a flavour of what's involved.

The important thing to note at the outset is none of these processes is a technical one, even though some of them involve technical aspects. They are all management systems.

Another point to make is that the systems you implement don't have to be hi-tec. Let's face it, a paper record of what equipment is in which room is infinitely better than no such record, and a way for staff to report faults, involving a form and your pigeon-hole, is far better than the corridor culture discussed earlier.

Finally, these processes are for the most part a menu rather than a sequential list. For example, your school's financial management for technical support may be perfectly sound, but change management may be non-existent.

Having said that, there is an inherent logic in the order, or at least parts of it. For example, you may think that setting up a service desk in the school office would not be as useful as hiring an extra technician to cope with network glitches, but in one school the helpdesk now deals with 60% of the calls that would have previously landed in a technician's lap (assuming they were sitting down long enough for it to land there).

Another example is the distinction between incident management and problem management. In essence, if a particular incident keeps occurring often enough, you've got an underlying problem. That much is obvious, but how does an incident get escalated to a problem?

I had an interesting example of this during a school inspection. One of the computer rooms was generally regarded as unreliable because the network kept crashing in that room alone. I asked the
technician what he was doing about it and he replied that he deals with it by rebooting the system. That is, to say the least, a short-term solution; but nobody in the school had actually gone much beyond recognising that there was an underlying problem and working out what its causes were. There was no plan in place to actually do something about it, and no doubt in ten years' time the technician will still be rebooting the network every couple of days.

The emphasis in FITS is on service and systems. Past attempts at dealing with technical support have focused on the question of how many technicians are required to provide a good service. Depending on how you work this out, it could be none or, more realistically, one, if you have a managed service; two or three, or, for a large comprehensive, an army of twenty. The truth of the matter is that any such estimates, which are based on the equation of how many computers a single technician can support,
are doomed to failure because the better the service, the higher the level of expectations: in short, you will never have enough technicians if you adopt this approach.

However, a deeper analysis suggests that a more profitable approach is to change your paradigm or world view. Once you stop thinking about technical support as a matter of dealing with hardware and infrastructure like cables and hubs, and start to view it from a customer perspective, the concepts of a service desk and a service level agreement suddenly don't seem quite so strange.

It is not often that I wax lyrical about the ideas which emanate from our official bodies. However, having seen five out of six schools transforming their technical support facility by implementing parts of the FITS programme (the sixth one did nothing for various reasons), I would say that FITS works, and that you should definitely look into it.

Unless you enjoy being harassed in the school corridor of course!

The FITS website may be found at:

http://www.thefitsfoundation.org/

An earlier version of this article was first published on 17th May 2005.

Checklist: 9 Guidelines for Managing a Technical Support Team

You don't necessarily have to be a "techie" in order to be able to manage a technical support team effectively. These guidelines explain how.

• Recognise that output is more important to most people than input. In other words, what matters is not so much how long or how hard the technical support team works, but whether the systems are reliable and functioning well most of the time.
• Most technical support problems have non-technical causes, and therefore non-technical solutions.
• If you have just started in the role of managing a technical support team, undertake a fact-finding exercise, to determine what the technical support experience is for various groups of people in the school -- including the students. I have undertaken this work for schools on several occasions, and the findings often come as a surprise to the technical team.
• Introduce reporting and measurement procedures. How many faults were reported this week? How long did it take, on average, to resolve them? What has been done to reduce the risk of the same fault occurring again?
• Insist on the proactive involvement of the senior management team. In the work I've done with schools, a consistent message has come through that a passively supportive attitude, while better than an unsupportive one, is not enough.
• Invite the network manager to your department or curriculum meetings, both to listen to what's important to you and, perhaps either briefly every time or, say, once every 6 weeks, to give a report about the network and any matters of concern.
• If you are the educational technology co-ordinator or manager, work towards having the line management of the technical support team taken out of your hands. The technical infrastructure and support of the school ought to be regarded as a maintenance function, not part of a curriculum area.
• In the meantime, allocate some of your budget for training purposes for the technical support staff, especially if they will be asked to implement or manage a new network system, say.
• Ensure that there are clear guidelines for responsibility in place. The role of the technical support team is to advise, implement and maintain. It is your role to ensure that learning takes place. When new computer facilities are being planned, both parties will need to be fully involved in the discussions from the outset.