I was recently looking in an online service management tool
forum site and I saw a post entitled “Problem Management = Fail”. The caption
obviously caught my eye and I looked to see the number of responses. There were
48, which isn’t a bad amount of feedback so I decided to see what the topic was
about exactly as well as what people were commenting on.

The person who posted this said that while the problem management
functionality was easy to implement from the tool perspective that it was not
producing the results that their company was looking for. The first response in
the timeline of comments asked if they had a process in place or if they were
simply looking to have to tool do the work (which is a question I too would
ask). The person said “that a process was in place and that they weren’t really
getting results before hand and were hoping that their old tool was
contributing to the problem.” They went on to elaborate in saying that now they
were getting more problems created but not improving the reduction of incidents
which they thought might happen.

Looking through the 48 responses I broke categorized the
feedback as such:

While this categorization was simple it illustrates that
many service management teams may be looking at problem in the wrong way. For
me it is all about what your scope of problem management is and what its
overall goal is. In short, improve the delivery of service through a reduction
of incidents.

Going back to the breakdown of the forum post 23% of the respondents
said that they treat problems like incidents. This is a prime example of
missing the scope discussion for problem management. If we are spending our
problem efforts similar to incidents, we will likely just be following incident
management process with the information being filled in a different record type.
Keep problem efforts separate.

Problem does not need to be like a unicorn, although two
people in that discussion would beg to differ. The reason that Problem sees
issues in use or adoption, which encompassed the other concern points, is that
we are not looking at the big picture.

Here’s an example, a company has an application which has
an issue once a week for several users which has an application hanging for
five minutes. After that the application works again. Since no root cause was
identified a problem was created and people look at this issue each week. While
this might seem like a good candidate for a problem, to some it might not have
the value as something else. Your organization might not even be concerned with
issues like this and when we report on what we are accomplishing it might look
like an anthill despite the impact to some users and incident stats. On the
other hand you might have a more visible issue that needs to be addressed and
when we review with leadership we can see the value more clearly.

Having a balance to the issues under investigation is
important to ensure a great customer experience.