How to deal with major incidents or major problems

A major incident or problem can be classified as one that causes serious disruption to the computer service in the school. This can include:

• a virus outbreak or threat
• closure of internet services
• file server failure
• partial or total network failure
• building problems ­– for example, fire, smoke, flood or frost damage
• software problems affecting over 30 per cent of computers.

Major incident process

• Service desk to field all calls and reschedule planned incident responses
• Technician to be notified of the major incident
• Technician to identify the extent of the problem before taking any action
• School to allocate an additional person to help the technician
• Additional person to be responsible for communication between the technician and users and to provide ad hoc help to enable the technician to deal with the incident
• Technician to discuss with the school leader the extent of the problem and a planned response (the school leader needs to know how to reschedule the planned work that involves the affected computers)
• School leader to ensure that the technician has the necessary resources to deal with the problem including time
• Technician to decide how long to continue with trying to fix the problem before calling on the school's 'disaster recovery' option

Notification of a problem

It is either the single point of contact at the service desk or the technician who will decide if an incident is really a problem. The user will notify an incident in the usual way using the incident form. When the service desk receives the form it will be checked. With experience, service desk staff will know if this is to be passed through Problem Management. Otherwise they will pass it to the technician in the usual way.

When service desk staff check the incident sheet, they may notice the following:

• The same type of incident was reported on several other computers in the last few days
• The same type of incident was reported on this computer in the last few weeks
• This is yet another regularly recurring fault on the same computer.

Staff can do these checks by looking at the call log or by using simple searches using a ‘find’ function to spot certain words or phrases – for example 'network card', 'pc24' (if this is a computer's unique reference) or 'printer jam'.

The single point of contact (SPOC) at the service desk may record this information on the incident sheet and inform the technician when placing the call.

Requesting technical support

If the service desk has decided that this is a problem, it must be passed to the technician and no further diagnostic work is required by the service desk.

The technician is informed in the usual way about the call and the person on the service desk will advise why they think it should be treated as a problem.

If the school has 'swap-out spares' that a competent person in the school can install, the technician may advise doing this before any further work is done to the faulty equipment. The benefits would be:

• time saved waiting for the technician to attend to the call
• reduction in the time that the equipment is unavailable
• an opportunity for the technician to investigate the problem without being under time pressure.

Problem analysis

Problem analysis uses common sense, asks lots of questions and should not be too far-fetched with the final theory.

Technicians should remember that using phrases like 'power line glitch', 'infrequent reset phenomenon', 'intermittent random fluctuating memory address' and other such odd-sounding phrases do not impress the user. If you are not sure what is happening then say so.

Honesty is the best policy. As long as you have an answer ­– which may be to replace the equipment or that a purchase is required – this is fine. (See problem analysis tools in the Problem Management toolkit)

Produce theory

From the evidence, analysis and experience, produce a theory for what is happening – or what has happened. Then use the theory of 'what went wrong' to produce actions to resolve the problem. Your first theory may not always be correct and you should try to show why this is. Avoid theories you can't explain!

Produce resolution

Pause before taking action. Write down exactly what was done, and the outcome. Do this for all actions you took – even if it consisted of just one line of a system set-up file. The step-by-step actions should be able to be traced to find out what the technician did to resolve the problem and therefore help in resolving future problems. Problem management is a huge learning curve, and although it is time consuming, making notes is very important.

Results of resolution

The results of the resolution may affect many systems in the school. If a plan is to be drawn up to replicate the actions across other systems, this must be done using the process described in Change Management.

Problem closure

Update the incident diagnostics sheet and the incident sheet and pass them to the service desk. The service desk performs the usual call closure operations.

Problem-analysis tools

A range of tools exist to assist problem analysis, but it’s worth remembering that you need to be familiar with using the tool if it’s going to produce results, and there is a cost associated with the time spent on problem solving, so reserve problem solving for expensive issues!

Root cause analysis

This is the process of finding the real cause of a problem and dealing with it rather than simply continuing to deal with the symptoms. It seeks to identify the reason for the failure by asking lots of questions and determining whether changing an event early on in the chain of events could have prevented the failure. Ways to implement the change are decided and actioned through the Change Management process.

Error code look-up

This is where you find out what a displayed error code means. Often the user manual or technical manual cannot be found or it does not detail the error codes of the software. Using search engines you can look up the error code, the model of the equipment and the operating system to get a filtered response that may guide you towards the reason for the error.

Fishbone diagrams

This diagram, also referred to as a cause-and-effect diagram or tree diagram, displays the factors that affect a particular quality, characteristic, outcome or problem. The end product is typically the result of a brainstorming session in which members of a group offer ideas on how to improve a product, process or service. The trunk of the diagram represents the main goal, and primary factors are represented as branches. Secondary factors are then added as stems, and so on. Creating the diagram stimulates discussion and often leads to increased understanding of a complex problem.

Technician’s forms

The technician forms are designed to aid technicians in doing their job. It is always useful to record events as they occur, as this helps to ensure that you leave nothing out. If your records are not comprehensive – which may happen if you don't complete the form at the time – you may omit a seemingly obscure piece of information that later proves to be the key to resolving the incident or problem.

Problem management checklist:

• Do you spot problems before an incident occurs?
• Do you record resolutions for future reference?
• Do you resolve known errors before they become an incident?
• Do you minimise the adverse effect on users when an incident occurs?
• Do you analyse incident trends to prevent further incidents?
• Do you allocate enough time for problem management and do you review the allocation periodically?

We have provided a technician’s diagnostic sheet in the Toolkit section

Analysing reports

The measurements you have gathered are similar to those for incident management and, like incident management, they are the starting point for helping you to understand what is happening in problem management in your school. They do not provide any answers, only the questions you must ask.

Look carefully at the statistics and then find out their causes. Identify trends and ask questions, look back through problem records, talk to problem management staff. Dig around for the root cause. It is important to identify and resolve issues with the process to ensure that it continues to operate effectively.

Problem management reports should identify where isolating problems from incidents has provided benefit.