Ask not what your support provider / technician can do for you, but what you can do for them.
I know that will sound very wrong to some people … putting the onus back on schools rather than the techies but when I am working with some schools who buy in their support from outside companies, whether for technician time, for support on a particular solution or as a managed service, I can often find that the ‘ownership’ of all things under the broad umbrella of technology gets thrown over to the support provider / techie.
It is one thing for a company to say “we will deal with all your technical worries!” but unless the school leaders have some ownership themselves they lose the ability to plan and make strategic choices.
My recent response to a few schools is to make them think about their relationship with their techie and how to get a better balance of ownership and direction. So, I have a very simple 3 point plan that can be used with or without FITS (ok, it is actually part of FITS but no taken in the usual order) and applies to both school and techies.
1 – Inventory
How do you know what needs to be supported if you don’t know what you have got? How do you know when it is likely to need replacing? How much do you need to invest over the next 3-5 years? All pretty pointless questions unless you know what you have … and how you are presently using it / plan to use it in the future. Here are my recommended things to have in your inventory.
- Serial Number
- School Asset Number
- Purchase Date
- PO Number
- Disposal Date
This would be the bare minimum required for insurance purposes but there are other fields that many will add in.
- Asset name (which may change during the lifetime of the asset)
- Hardware Specification fields [CPU, RAM, screen size, etc] (all of which depend on how much you use the asset register as a trueinventory)
- Principle User (which may vary, could be a department, could be whole school or could be a specific user)
- Software Specifications [OS version, installed software, etc] (you could tie this into your software inventory and remember that you licences are actually assets too!)
This will give you a basis to look at investment using tools such as this.
The people that need to be involved in this are the Bursar / Business Manager, the ICT lead and the support provider / technician.
2 – Routine Maintenance
This is one of those areas that is open to negotiation. Realistically there are some things that will require a regular look at or regular action and others which can be reactive. This is where those who have had a long look at FITS can see things like change management, release management and patch management … but what does it mean to everyone else?
a) Software patches – These tend to boil down to 2 areas … those needed to fix problems or stop problems arising (eg security patches) and those which will change / improve functionality. Sometimes you will get both. Now what you have to decide is when to install these … and since we know that people like Microsoft tend to release their patches on a particular day it is not too hard to plan around this. If you are using particular solutions such as RM’s CC3/CC4 then you know that they will check and release versions of these for you … security patches get a priority of functionality patches … mainly because if you change functionality then you might want to prepare people for it … so the school can help by deciding when are the best times to look at releasing security and functionality patches.
b) Backups – you know that each school will have its own requirements for this based on what systems they run, the number of servers and users … lots of variations here. But one thing is surely needed … a log of when backups are done *and* tested. A school should be able to pick up a sheet of paper, look at an online chart and be able to answer this for any piece of data you store. The sticking point for some schools may be that there is not a backup policy (what is backed up, how frequently, how is it restored, etc) but even a basic policy can be generated quite quickly.
c) Hardware maintenance – Many items of hardware need a checkover on a regular basis. PAT testing can fit into here, cleaning out of filters on projectors, airdusting / vacuuming the debris that can collect in servers depending where they are, the same with desktops & printers … and let us not forget that this can include the cleaning rota for keyboards and mice.
d) Anti-Virus / Anti-spyware – I see a mixture of schools who have a centrally managed system where it is really easy to see what updates are pushed out to computers and also reports of viruses appearing on systems (and hopefully cleaned off too), and then we have schools which find that it puts too much cost on and just have a client on each machine. Either way you need to set some standards for checking that it is up to date or being updated on a regular basis. This needs some periodic checking and recording.
e) Purchases – This might seem a strange one to include in here but how many people have been frustrated to find out that they have run out of toner or ink for printers, that the few spare mice they had have all been used up, even things like stocks of paper for printers have been used up. This links in with the inventory really … so is down to school need, but supported by the techie.
This is by no means an extensive list but a good starting point. Larger schools might include in here regular meetings with key staff to help identify needs and issues which can be used to help plan maintenance and future plans too.
3 – Communication
This is the bit where we can see that it is aligned to FITS more clearly. In FITS we see things like a single point of contact (the helpdesk) but for many schools this could be a log book where teachers put problems and the technician picks them up when they come in. The downside of this is that the technician may find 8 problems since they were last in but has to go to each teacher to get more information to try and decide what needs to be done first (and how many of us have pushed to get *our* problem as the number one task because *we* are more important than anyone else!), but that can leave the techie in a terrible position.
There are a couple of things that the school can do to make life a bit easier all round and they all centre around communication. Having a single point of contact between the school and the technician is a good thing, but don’t let it be a purely impersonal item such as a log book / job sheet. Where possible make it a person … someone who can manage IT and the support contract. Set some ground rules … things like priorities. Something affecting the whole school is the most important and this does not have to be that the server is down … it can be things like an update is require for you MIS. Without it then you cannot complete school activities such as attendance, termly returns, etc. Whilst this might be difficult to explain to some staff in the school as long as the senior leaders and the designated member of staff who is going to manage things (manage … not do the work I should add!) then it should be accepted by other staff. Clear information about the progress of jobs is handy too. Put a framework in place so that if the technician is in one morning a week then at the end of it the member of staff managing the IT support can clearly see what has been done and what is left to do. Some larger companies might have an online ticket system for this, but often the job book will be just as good. Again, this is not an extensive list but a good starting point that I would expect to see in schools.
So there you have it. 3 simple and basic targets that I would expect in each and every school, no matter how your IT is supported.