Using & Teaching Educational Technology
FITS for the purpose
By Terry Freedman
Tue, 17 May 2005, 00:32

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.

It 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

Set out like that, the list does seem somewhat daunting. This
feeling is at once reinforced when you visit the FITS website
(see bottom of article), where there is voluminous documentation,
plus all kinds of tools and pro formas for your use. But, just as
the best way to eat an elephant is one bite at a time, the best
way to approach the FITS programme is through the Pocket Guide,
which summarises the processes in a lively and succinct manner
which makes the whole thing seem do-able. Alternatively, start
with the case studies in order to get inspired straight away!

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!

References:

The FITS website may be found at:

www.becta.org.uk/leaders/technicalsupport

The FITS Pocket Guide may be downloaded from:

http://www.becta.org.uk/corporate/publications/publications.cfm?c
urrentb

Three case studies may be downloaded from:

http://www.becta.org.uk/corporate/publications/publications.cfm?c
urrentb

© Terry Freedman Tue, 17 May 2005