At a recent event I was asked about the way the incident
and problem management processes were managed. Should they be managed
simultaneously with the same people or should they be operated separately. Like
a true throwback Thursday, this question still gets asked and likely will for
To get to the root of the question I would ask “What is
the real reason that you need to have these processes run in that manner?”
Generally people will say we can’t get addition people or
time to do problem management effectively so how can we get around that?
My answer is that it is all about marketing…
You are probably wondering how I got to marketing from
incident and problem, but its really something that IT as a whole hasn’t been
particularly good with for some time so it’s a skill we need to really work on.
Quite often the service management team and some of your operations folks will
see the value in having a formalized problem process in an effort to reduce
incidents which likely have resources attached. So selling the idea to them is
easy, but they may not be the one you need to convince.
The real challenge is that we are always looking at this
from the incident perspective, hence the marketing. For example if we were able
to apply the same effort to permanently reducing incidents rather than having
people fixing them with regularity we may not need additional people at all. To
clarify, if we spent 6 hours on a weekly basis to restore functionality to a
service, what would happen if we allocated those 6 hours to problem
investigation. Doing the math, instead of 468 hours of service impact per year
we may be able to spend a fraction of that determining a fix or a workaround or
potentially even a way to replace the service to improve perception. This is
the way we need to market reactive problem management.
Assuming we can clear that hurdle and allocate resources
accordingly, the next challenge is managing the incident and problem activities
at the same time. In my opinion these are two different processes which have
two different objectives and should be managed as such, and this can get tricky.
Without some real focus most often the incident side will bully problem into
the shadows and you could be right back where you started without doing any
real problem investigation. This slide back into the shadows creates its own negative
marketing (there’s that word again) that problem is not as valuable as
incident, which is not the case.
Remember that despite keeping the two processes separate
by focusing on what they aim to achieve, you still need to connect them
together with regularity. This will ensure you are getting a big picture view
of where services need improvement and can adjust accordingly.
You might ask me next, “Well that’s great, but what if we
don’t have people to do this in the first place?”
Again I come back to marketing and suggest that in the
end we are looking to achieve some business outcome. As such we want to ensure
that these supporting services enable the business to achieve their goals. If
we market the processes based on their merit and what specific value that they
add, is it possible that your operations teams could leverage the process to
perform incident and problem activities. The touch point may be a regular
operations meeting to review the state of services as they relate to incidents
In summary we need to keep these activities separate, but
they cannot exist in isolation. That we market the value of them not only
within your service management teams but also to your IT department to ensure
that we are all working to the same goal – excellent service delivery
me on Twitter
@ryanrogilvie or connect with me on LinkedIn
Labels: CSI, Incident Management, ITIL, ITSM, Problem Management