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.
Read MoreChecklist: 9 Guidelines for Managing a Technical Support Team (Updated)
You don't necessarily have to be a "techie" in order to be able to manage a technical support team effectively.
Read MoreFITS 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.
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
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.
Checklist: 9 General Principles for Recruiting Technical Support Staff
Image by Terry Freedman via Flickr
You may have the opportunity to advise your senior management team on the appointment of technicians to support the educational technology provision in your school. Here are nine factors to consider.
- Decide on whether to recruit your own technicians or use agency or Local Authority (School District) staff. The decision will be based on considerations such as finances, and whether there would be enough work to justify the employment of a full-time technician.
- Decide on what sort of tasks you need the technician to do. If they require little technical expertise, such as changing printer cartridges, it may be better to hire or give additional training to a teaching assistant instead. Use Becta's technician job description tool to assist you.
- Decide on the level of expertise you're looking for. This is related to the previous point.
- Decide on the sort of person you need: a backroom person who will have little contact with staff, or a frontline person with whom staff will feel comfortable in approaching on a day-to-day basis.
- Decide on how many technicians you will need. Hiring too few may prove to be a false economy, especially if they leave and take their knowledge of the network with them.
- Ideally, there will be a budget to cover salaries. Bear in mind that for a network manager or technical team manager's post, you are competing in the "real world" market place.
- If the school cannot offer a commercial salary, you will need to sell the advantages of working in your school. For example, will the person be required to come into school every day during school vacations? In many respects, working in a school environment is more challenging than working in a small to medium-sized company. This is a potential selling point to anyone who wishes to acquire a wide range of experience in a short period of time.
- Advertise in the most appropriate place. For example, if people skills are more important to you than technical skills, it may be more cost-effective to send a letter out to parents than to advertise in a technical periodical.
- Make it a requirement that applicants be ITIL (The Information Technology Infrastructure Library) trained, or experienced in something similar (such as Becta's Framework for ICT Support, or FITS), or be willing to be trained.