Problems are inevitable in running an
organization. No one can avoid it even you. It’s always good to know how to
deal with problems in a structured way and not by throwing every solution you
have at a problem.
actionable techniques for ITIL Problem Management. In ITIL,
problem management is a separate process altogether, which is why we have made it
into a separate module.
that most service desk technicians face, having to separate incident and problems. The
confusion is quite obvious, because these two processes
are related and sometimes overlapping.
Now coming back to the question of
Things to Know Before
Before talking of techniques for problem
management, you need to understand a few things:
- How problems and incidents are related?
- Understanding the nature of problem
- What is problem management life-cycle?
- Known Error.
How Problems and Incidents are Related?
A symptom is anything that is caused by a
problem. It tells that a problem exists, and when the final cause is figured
out it is called the root cause.
Imagine, you are having a fever, and you
went to a doctor. What is the first thing he/she asks? Obviously, the doctor
will ask you about the problem, and when you tell, he/she will record it as a
symptom because nothing is conclusive at that point.
The doctor will attach a WHY to every symptom you tell so they can
create a list of problems. When asking why fever, it can be the sign of having an
infection. The doctor asks you to do a blood test so he can drill down further.
After the test, he concludes that you have malaria, which is the root cause.
In the world of ITSM, incidents record the
symptoms and a problem records the root cause. Sometimes, there could be
multiple causes behind symptoms.
Understanding the Nature of Problem Resolution
It’s not always that incident records
contain symptoms and problem records contain root causes. In order to
understand this, you need to understand how problems are handled.
There are two types of problem resolution:
A proactive resolution is like a
pre-emptive strike on a cause that may lead to a problem. For example,
replacing a hard-disk of a server which is about to get full. The cause may be
ascertained from symptoms in the form of an incident. In the above example, it
can be an event incident warning about the disk getting full. After finding the
cause, it is recorded as a problem where a resolution is planned.
In a reactive resolution, the
problem has already occurred, and the technicians are fire fighting for a
solution. For example, the failure of a power supply. Here, the related
incident can be used for recording both symptoms and the root cause, and no separate
problem may be created.
The above two examples are indicative and
should not be treated as an absolute rule to separate symptoms and causes.
What is Problem Management Life-cycle?
ITIL Problem Management follows specific
steps to resolve a problem. Steps such as:
- Problem Identification
- Problem recording
- Problem investigation
- Problem resolution
What is a Known Error?
According to ITIL, a Known Error is a
problem that has a documented root cause and solution. In case there’s no
solution then a workaround has to be there.
In ITSM, a Known Error problem is marked
and related to the problem record where the root cause and solution is
Here’s a simple formula to identify a known
P + RC + S = KE
P = Problem, RC = Root Cause, S = Solution,
KE = Known Error
ITSM provides a robust Known Error
5 Actionable Techniques for Problem Management
There are numerous techniques out there to
manage problems, but I have selected five that will fit perfectly in the ITIL
Problem Management framework. Let’s take a brief look at those techniques:
It is one of the many ITIL techniques that
relies on common sense. In this technique, a technician works backward in time when
the problem first came to notice; all symptoms and activities are pieced together
across a timeline.
The process forces structured thinking
rather an ad-hoc approach. This technique is great for:
- Identify scope for proactive resolution.
- Identify recurring issues/incidents.
- Enriching the Know Error database.
Pain Value Analysis
Not all problems are the same. Some problems
are important some are not. You need to learn, what to prioritize and what not
Pair Value works by ranking problems based
on their impact to the business. When defining impact consider the following:
- The criticality of the business process that the problem
- Number and nature of relations of the impacted process.
- Cost to the business.
- The number of impacted people.
Once you rank the problems, you will know which
problem to record first.
Once a problem is identified and recorded,
it’s time to come up with a solution. Brainstorming is a collective effort that
is both creative and effective.
The first step in doing a brainstorm
session is to create a team. Before beginning the sessions, you should keep the
following things in mind:
- Prepare a list of questions to tackle.
- Involve a round robin discussion so everyone can
- Record ideas that are being generated during the
- Create a review plan to select the best idea.
- Prepare an action plan which will be the solution.
Kepner-Tregoe Problem Solving Method
Also known as the KT Method, it is a model
that tries to disconnect the problem from the decision.
This model is a thought process that has four
types of analysis:
Analysis: Tries to define what has happened. When
you meet a symptom try to understand the situation. For example, when received
an incident that says the website is down, try to understand the situation
whether routine maintenance was going on or not.
- Problem Analysis: Tries to answer why it has happened. Attach a WHY to all of your symptoms and drill down to a cause.
- Decision Analysis: Tries to define how to act. Create an action plan for resolution.
- Potential Problem
Analysis: Tries to anticipate whether the problem
will reoccur. Initiate a proactive resolution to make sure the problem doesn’t
It’s a prioritization technique that
assists the service provider to focus on problems with the greatest impact.
It’s based on the idea that 80 percent of
incidents result from 20 percent of the issue caused. The method allows
handling of problems in the order of best return. When coupled with the Pain
Value Analysis, it can be a powerful technique.
The success of Problem Management comes in
taking the time to execute the processes and utilize some or all the methods
Making time for Problem Management may
detract the time spent resolving Incidents. The irony is that in the event you
do not make time for Problem Management; you may only have time for Incident
Management, which can consume considerable amounts of resources.
Problem Management is not a resource
hungry. However, it demands special devotion and cares to see it triumph.