In an effort to continue your journey to improve the
delivery of services your IT organization has decided that it needs to “do”
problem management. The first question I would ask is what does “doing problem management”
really mean? If you were to go by many standard definitions for the term it
would suggest that we are working towards determining root cause of incidents
to prevent any recurrence of some particular issue.
For most service management practitioners it is clear why
IT would want to implement a problem process. The benefits speak and frankly
can pay for themselves including:
Through fewer incident escalations to support
A reduction in incident volume and durations
Reduction of Costs
Less handling of re-work issues by support
Improved customer experience
Business sees less of the repeatable issues
(the “oh not this again”)
These are a few of the really obvious examples, however
the challenge then becomes whether we are in a position to be able to “do” (as
was suggested earlier) problem management properly? There are several pieces that
integrate with a successful problem process.
Always big on my list. You really need to have the
backing of leadership for this to be as effective as possible. Almost all
organizations will be behind fixing issues as a result of the incident process
but there seems to be challenges with regards to fixing something that isn’t broken….yet.
Despite the directive to “do” the process it should be understood what is
involved in making this happen from a day to day perspective. The results will
speak for themselves but seeing that value can take some time. Some patience
will be required.
You may have very efficient incident process, in that the
resolution of issues is quick and effective. The challenge for problem management
will be the gaps in the integration between incident and problem. For me the
challenge is always the level of information that is in the incident knowledge
record. After all, these “tickets” are effectively knowledge articles which the
problem process can leverage to dig into the root cause analysis. The old
saying goes “garbage in – garbage out”. For example if the incident impact was “application
slow” and resolution was “fixed issue” we are going to need to take a closer
look at the information that is collected during the incident and ways to
ensure that it is captured consistently.
Another key process to consider is Change management. After
all this is the vehicle to implement the fixes to our issues in a controlled
fashion. However if your change process is “fire, ready, aim” you may also have
challenges that will prevent effective problem management. For example if we
are performing several changes which are documented but not really reviewed or
discussed across the broader audience where it might apply we may also be setting
ourselves up for problems down the road where there were so many changes that
we are unable to pinpoint the areas for diagnosis.
These are only a few examples... remember you need to walk before you can run. Take a closer
look at how your service management processes work with your organization as a
whole to allow your business to operate.
Labels: ITIL, ITSM, Problem Management