Problem management: starting small with recurring incidents

Problem management is the discipline of finding and removing the cause behind recurring incidents, so the same problem does not keep happening. Where incident management is about resolving as fast as possible, problem management is about preventing you from having to resolve it again next week. You do not need a heavy process to start. This article shows how to get from recurring incidents to a workable problem record, small and without needless setup.

The difference with incident management

An incident is a disruption you resolve. The user can get on, the ticket closes. Problem management looks at the pattern behind those incidents. If you get the same ticket five times a month about the same crashing application, you resolve the incident five times, but the cause remains. A problem is that underlying cause.

The distinction sounds obvious, but in practice problem management almost always disappears under the pressure of the daily work. There is always a new incident, and the time to look at the pattern never comes. That is exactly why the trick is to start small and keep it light.

Why problem management is different from proactive work

Problem management often gets lumped together with proactive work, but it is more specific. Proactive IT support is broad: monitoring, shift-left, bringing knowledge closer to the user. That whole broader story is covered in from reactive to proactive IT support.

Problem management is one concrete part of that: the discipline of systematically finding and resolving the cause of recurring incidents. It is narrower and more tangible. You do not need a culture change for it, just a few agreements and the discipline to keep them up. That makes it a good first step towards working more proactively, precisely because you can keep it small.

Starting small: look at your own tickets

You do not have to build a problem management process to start. The first step is simply to look at what is already there. Your ticket history holds the answer to the question of which problems cost the most work.

• Count the recurring incidents. Which topics come back most often this month? Often a large part of the repeated work sits in a handful of causes.
• Look at clusters, not individual tickets. Five tickets about "printer not working" on the same floor are probably one problem, not five.
• Start with the biggest. Pick the cluster that produces the most tickets or the most frustration. Removing one cause immediately saves visible work.

This approach ties into how you keep ticket quality up: if you log incidents well, the patterns become visible on their own. How to keep that logging light is covered in ticket quality without admin burden. Without a minimum of quality in your tickets you will not see the clusters.

A workable problem record

Once you have recognised a recurring problem, you want to record it somewhere. That does not have to be a separate system or a heavy process. A problem record can be as simple as a list of known problems, each with a short description, the status and who is working on it.

What you want to track at minimum per problem:

• What it is. A short description of the cause, in plain language.
• Which incidents fall under it. So you see how much work it causes and the gain becomes visible when you resolve it.
• The status. Being worked on, waiting on something, or cause removed.
• A temporary fix, if there is one. A workaround that lets the service desk handle the incident faster while the real cause is not gone yet.

That last one is practically gold. A known problem with a recorded workaround means every next incident of that type is handled in a fraction of the time. Record those workarounds in the same knowledge base the service desk already uses. How to set that up so it actually gets consulted is covered in building a knowledge base people use.

Keep it light

The biggest pitfall with problem management is that it turns into a separate process with its own meetings, its own roles and its own reports. Then it becomes bureaucracy and fizzles out. Small and pragmatic works better.

A few principles to keep it light:

• Work on one or two problems at a time. Picking up more in parallel means nothing gets finished. Actually resolving one problem delivers more than half-investigating ten.
• Reserve a fixed, small block of time. For example an hour a week in which someone looks at the patterns. Without reserved time the daily work always wins.
• Measure the gain. When you remove a cause, count how many incidents disappear as a result. That makes the value visible and keeps the energy up.
• Only add process where it pinches. Start with a list and an hour a week. Expand the approach only when you notice it getting too light, not because a framework prescribes it.

This is service management without ITIL dogma in practice: you use the idea of problem management, but not the heavy setup that theoretically comes with it. The gain sits in removing causes, not in the process around it.

What it delivers

A light, sustained problem approach slowly but surely changes the service desk. The stream of recurring incidents drops, the team keeps time for work that genuinely matters, and the things that do come in are new instead of the same question for the tenth time. That is exactly achieving more with the same people: not working harder, but removing the causes that keep creating the work.

Frequently asked questions

What is the difference between incident management and problem management? Incident management resolves a disruption so the user can get on. Problem management finds and removes the underlying cause, so the same incident does not keep returning. Incident management is reactive and fast; problem management is structural and prevents repetition.

Do you need a separate system for problem management? No. You can start with a simple list of known problems, each with a description, the related incidents, the status and any workaround. Most ITSM tools have a problem object, but a light record in what you already use is enough to start.

Where do you start with problem management? Look in your ticket history at which incidents come back most often, group them into clusters, and pick the biggest cluster first. Removing one cause immediately saves visible work and makes the value of the approach clear right away.

How do you stop problem management from becoming bureaucracy? Work on one or two problems at a time, reserve a fixed small block of time, measure the gain per resolved cause, and only add process where it genuinely pinches. Start with a list and an hour a week, not with a framework full of roles and meetings.

Want to get rid of recurring incidents without building a heavy process? book a call and we will look together at which causes cost you the most work. For support with a pragmatic approach, see our service management services.

Further reading

• Problem management (Wikipedia)
• What is problem management? (Atlassian)
• ITIL (AXELOS)
• IT service management (Wikipedia)