In this article…

Introduction

It has long been the case that the teacher in charge of education technology 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 person in charge of trying to encourage colleagues to use the education technology facilities is slowly but surely driving herself into the ground, the word on the street is that the systems are unreliable and that person is useless.

It doesn't have to be like that.

The corridor culture

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 ed tech 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 VLE.

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.

It’s a management issue, not a technical one

There is another way, which involves setting up a process whereby faults are logged, and dealt with efficiently.

The important thing to note at the outset is the process is not a technical one, even though it may involve technical aspects. It is a management system.

Another point to make is that the system you implement does not 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. You might even consider setting up a service help desk in school, perhaps employing a retiree or a parent on a part-time basis.

Now, 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 help desk dealt 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).

Incident management versus problem management

It can be useful to draw a distinction between incident management and problem management. In essence, if a particular incident keeps occurring often enough, you have an underlying problem. That much is obvious, but how does an incident get escalated to a problem?

I had an interesting example of this in a school inspection I was involved in. 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.

An incident, in other words, is a one-off or a short-term occurrence. For example, the printer in room 12 suddenly stops working, and displays an incomprehensible error message. Rather than spend a week trying to work out how to fix it, with the result that nobody can print anything in room 12 in the meantime, you take the easy way out (for now) and put a different printer in place of the non-functioning one. That gives you time to look at, or get someone else to look at, the printer.

Now, if the “new” printer goes wrong too, then there’s an underlying problem. Maybe the network connection in room 12 is misconfigured. Maybe the teacher in room 12 keeps making a mistake. Notice that the focus has now changed from “what’s wrong with the printer?” to “what is going on in room 12 that keeps causing printers to fail?”.

You need a system

The emphasis here is on service and systems. Many 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 clouds, 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.

What to do

Firstly, set up an easy way for colleagues to report faults. One way would be to create a Google Form that everyone can access. That will enable you to include tick lists of common faults and room numbers, making it fairly painless for teachers to fill it in without spending ages doing so.

Secondly, use the setting described in the article linked to in the foregoing paragraph to create a spreadsheet.

Thirdly, by using the filter option in the spreadsheet, you will be able to see very quickly if a particular fault keeps occurring, or if things keep going wrong at particular times in the school day or in particular rooms.

Finally, this approach will enable you to prioritise which jobs get attention first, and in what way.