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.