The Thorny Issue of Identifying Problems

Emailer Steve responds to this Problem Management white paper and poses this question: what can you do if no Problems are actually raised by the Incident resolution teams? Steve specifically mentions a period of over 4 months with no Problems at all being raised. Steve’s teams are handling 2500 or so Incidents per week, has 30 or so staff on the Service Desk and a further 70 working in specialist teams like I’ve referred to in this post on escalation.

Firstly, for new readers you can find a definition of a Problem here. It’s one of the outputs from Incident Management into Problem Management.

My editorial brief for this blog is to provide practical suggestions and to avoid unnecessary jargon – so that’s what I’ll try to do. What follows is in no particular order, it’s just some ideas to check off.

  1. Shared vision and understanding. If Steve has a vision of how things should work, and the use of Problem Management is a part of that, that vision needs to be shared between the managers and the IT service delivery staff. This can be quite hard, as sometimes the focus of more technically minded staff is not on service management. One of the things I see time and again is where the management view is one thing, and IT staff another. Managers do sometimes have a tendency to assume that staff know what is expected, when the staff either don’t, take a contrary view, or simply don't care.

Having stated the problem, I’ll try to suggest some solutions. One approach is to have regular IT service meetings where issues like this can be raised, managers can be persuasive, and staff can air their views. In my experience a lot of organisations simply don’t have meetings like this. It’s beyond the scope of this post to write about how such meetings should be conducted, but avoid having groups that are too large (some staffers will feel intimidated from contributing), make sure you have a chairman or woman who knows what they are doing, have an agenda, and produce action points afterwards.

  1. Make sure your procedures are written down in a concise, usable form. This comes back to my point about managers sometimes misleading themselves about the understanding that others have. However, in doing this you want a concise document that is useful and is not like a legal document. At Serio we refer to this as an Operation Manual and have a template/example for customers to use.

  2. Ensure that your staff understand what a Problem is, as the actual meaning can be quite elusive to some people. The best way to illustrate this is to pick one or two Incidents, and explain in your meetings why these are Problems (be careful not to be seen to be critical in the early stages).

  3. You should have a Problem Manager, and everyone should know who that person is. This person owns all the Problems, and the Problem Management process. The Problem Manager should have a team. In all probability, this will not be a full time team, but will be drawn from the existing service teams so that staff have dual roles (we work on both Incidents and Problems). Pay particular attention to the composition of the Problem Management Team – choose from a good cross section of disciplines and Incident Management groups. These people can acts as advocates of Problem Management for you and as ‘spotters’ in the Incident teams.

  4. Make sure it’s really, really easy for staff to flag Problems (and I mean REALLY easy). For instance, you could define a Cause Category of ‘Unknown’ which is applied at resolution time and this could be taken by the Problem Manager as someone saying ‘this is a potential Problem record’. This would be my advice for Serio users. Make sure that whatever Cause code you use, it's meaning ('hey this is a potential Problem!') is understood widely.

  5. Make sure your ITSM tool is up to scratch. For instance, raising a Problem ticket from an Incident should be easy. Linking multiple Incidents to a Problem should also be easy.

  6. Enhance the role of the Service Desk in Problem Management by getting them involved in reviewing Incidents. Make a specific responsibility one of scanning for Problems.

  7. Ensure that the Incident Manager and Problem Manager have a good working relationship on all levels. If they sit next to or within earshot of one another you might find that this helps the Problem Manager be aware of issues coming through in Incident Management process that he has an interest in.

  8. Whatever your procedures are, make sure the Problem Management process does not slow in any way the ability of Agent to close Incident tickets – they might want to do this quickly for all sorts of reasons (see yesterday’s post). They should be able to flag Incidents quickly for consideration by the Problem team, and it should not slow their ability to close the ticket.