The first step is to identify who will be involved in the process and assign roles and responsibilities to them. For the initial implementation you should involve as few people as possible so that the tasks can become familiar with minimum impact on the day-to-day workload. Assigning roles and responsibilities will depend on how you provide technical support currently and who is involved already.

After you have assigned roles and responsibilities, it is important that those participating understand what is required of them. Use this reference material as the basis for your preparation for FITS accreditation.

Setting a start date for the process to 'go live' is important to focus those involved and to mark the changeover to new methods in the team and for your end-users. Make sure that you allow enough time to do all the other preparatory tasks beforehand.

Communication must take place within the implementation team to agree plans, schedule dates and so on, but it is important also to communicate externally and inform the end-user community of the new process. The implementation of a process can be seen as a change, just like the upgrading of a server, and the impact on the user community should be communicated to them clearly in advance of the change.

Before you can go ahead with the implementation, you will need all the materials required for the process. Make sure that you have downloaded the templates you need and that everyone involved has access to them.

A good way to test problem management is to record and log one problem and manage its progress through to resolution. Review the test problem and discuss any issues. When you are happy that everyone understands the requirements and that all roles are fulfilled adequately, you can 'go live' with the process, but you should feel free to complete as many tests as necessary beforehand. You should have implemented FITS incident management before FITS problem management and if you have done so you will find that the processes are very similar.

The main difference between these processes is that problem management does not have the urgency and frequent end-user communication characteristics of incident management. Provided that you fully understand the concept of incidents and problems and are comfortable with the difference between the processes, you may feel a pilot for problem management is unnecessary.

Because problems are often identified during the course of incident resolution you should implement FITS incident management before FITS problem management. This is also true because incidents must be dealt with before problems, to provide good customer service.

Having a service desk will help you manage problems more effectively but if you have implemented incident management you should have dealt with this at the same time anyway.

FITS Change Management is also a prerequisite process, because by definition a problem will result in a change. You can implement a problem solution without the change management process but you could significantly increase the risk of introducing new problems if you do.

Problems are also identified as a result of network monitoring and preventative maintenance, so to gain the full benefit of problem management you will need to implement the FITS Availability and Capacity Management process. It is not a prerequisite though, and can be added at any time. You might find it helpful to build your problem management slowly, by dealing with only those problems that result from incidents to begin with, and adding other proactive input from network monitoring and preventative maintenance gradually.

A problem may be identified in one of the following ways:

• As a result of incident management – an incident may have an underlying cause that requires repair
• As a result of network monitoring – monitoring activities may identify failed or faulty equipment
• As a result of preventative maintenance – maintenance activities may identify failed or faulty equipment

In every case they will be identified by someone technical involved in the above processes who will record details of the problem.

Using the problem record template, the person logging the problem creates a problem record for each new problem, filling in the first part of the form ('Part 1 – problem details'). The table below guides you through each field.

When the details have been recorded, the problem logger gives the problem record to the problem manager, who will enter the details in the problem log.

Using the problem record template, the problem manager creates a problem log and records summary details of the problem for tracking purposes. Each new problem is added to the next line of the problem log. The table below guides you through each field.

It may be that the root cause of the problem has already been identified as a result of an incident investigation, in which case details should have been provided on the problem record. If not, the problem resolver is responsible for investigating and diagnosing the problem. It may be necessary to review full details of an incident in either case. Full details will be found in the corresponding incident record.

When a problem has been diagnosed, the problem resolver should complete the following fields on the problem record and report the information recorded to the problem manager for tracking purposes. If the problem resolver does not provide this information they can expect the problem manager to contact them and request an update.

The problem manager should update the problem log as follows, and proactively seek this information if it is not forthcoming.

After diagnosis, the problem logger will raise a request for change to implement the solution.

In order to resolve a problem it will be necessary to make a change to the affected equipment.

Example changes include: the replacement of a faulty hard drive, the installation of an operating system patch, the installation of additional memory and so on. Such changes should be planned and executed in accordance with FITS Change Management, by creating and approving a request for change form.

If you implement your change without using a suitable change management process, you run the risk of introducing new problems.

When the request for change form has been created, the problem resolver should complete the following fields on the problem record and report the information recorded to the problem manager for tracking purposes.

The problem manager should update the problem log as follows.

When preparations are complete, the problem resolver will resolve and close the problem.

The solution can be implemented when it has been approved through the change management process. Any work-arounds should be removed and loan equipment returned, as indicated in the problem record.

When a problem has been resolved, the problem resolver should complete the following fields on the problem record and pass the information recorded to the problem manager for tracking purposes. If the problem resolver does not provide this information they can expect the problem manager to contact them and request an update.

When it has been completed, the problem resolver passes the problem record to the problem manager so that they can update the problem log and file the problem record in the configuration management database.

On receipt of the completed problem record, the problem manager should update the problem log as follows. The problem manager should monitor the problem log and proactively seek the completed paperwork if it is not forthcoming.

The problem manager files the finished problem record in the configuration management database. (This can be a folder for paper records.)

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.

Satisfaction surveys are an excellent method of monitoring customer perception and expectation and can be used as a powerful marketing tool.

However, to ensure success you should address several key points:

• Decide on the scope of the survey
  
• Decide on the target audience
• Clearly define the questions
• Make the survey easy to complete
• Conduct the survey regularly
• Make sure that your customer understands the benefits
• Publish the results
• Follow through on survey results
• Translate survey results into actions.

Also bear in mind the following points on measurements:

• Do not set targets that cannot be measured
• Ensure that customers are aware of what you are doing, and why
• Establish a baseline before discussing formal service-level agreements (SLAs) with customers. (See FITS Service Level Management)
• Maintain measurements of what is necessary and viable. For instance, if your staff think that they need feedback on response times, then measure them!