After listening to the Hacking Business Technology
podcast I was thinking a bit more about Problem Management.
Typically the discussion sounds like this:
IT Leaders: “We want to reduce incidents and improve
IT Support: “OK, we will look into that”
Wait for the deafening silence.
While all people in IT are
looking at each other and shrugging shoulders they are already working towards
this goal. The trick is that we may not have enabled them with the capability
to actually achieve this goal.
Regardless if you have a formalized way at looking at
problems or not you need to have the right components playing into problem
analysis to actually be able to make the service improvements you are looking
for. It’s like having a two or three legged table. It might balance for a while
but overall it is not going to work as well as it could.
I like to look at problem management like a cocktail. For
it to taste just right you need a myriad of ingredients. Here are a few of my
favorite inputs and why.
There are two components where these can help you
identify areas where issues arise. The first as it pertains to failed changes
which cause incidents. I have said it before, sometimes the incident records
and changes are not linked in a way that will clearly show continuity. So this
documentation will connect some of those dots. Look at the ones you have from
last week, or last month. What services are they impacting, what went wrong
with these changes? The other post implementation review that should be looked
at is as a result of emergency changes. If we need an emergency fix this also should
also point us in a direction that shows where some issues lie. Particularly if
we are doing “routine” emergency fixes
Incident Post Mortems.
Critical incidents will happen from time to time, this is
a reality. However making sure that we learn something from all of these issues
is important. We should be asking the people who are in these reviews if we
identified what caused the issue and what we are doing to ensure it doesn’t happen
again. If we don’t know, or worse yet the issue was fixed by magic, we might
want to see if this is something that we can dig into further.
Looking at “the numbers” we should be able to ascertain
some basic form of trend analysis. Are we seeing an increase in the number of
incidents, requests or changes? If so why is that the case? If we are seeing an
increase in one of these there is a possibility that the others will see an
increase as well as I pointed out in a previous blog post “The
Yin and Yang of Incident and Change…”
Having a discussion on the flow of work within the IT
organization will also allow you to see what challenges each other are facing. In
some cases there are silos with the IT team which are preventing the whole to
understand the challenges the parts are facing. It is possible that an
infrastructure team is seeing an issue that could be addressed by someone’s
expertise or experience in the application support team or vice versa. Utilizing
the larger knowledge base will allow you to see things in a broader way.
Having similar discussions with your business will also
allow you to see what you in IT may not see through your current reporting
capability. There may be cases where apathy has prevented the business in
escalating an issue. Another example is that we may not truly understand a
particular business service we are providing and may be underplaying its
importance from a priority perspective. All these discussions are important and
should be had regularly. Whether you have a formalized role such as a business
relationship manager or not you need to understand the services which you
Having these tools in place will allow you as an IT organization
to build out your capability to make improvements on issues your business is
facing. Your business needs to have a strategic ally to allow them to achieve their
business objectives. Whether you call a process problem management or not
matter as much as the actions which are helping facilitate that success.
me on Twitter @ryanrogilvie
or connect with me on LinkedIn
Labels: BRM, Continual Service Improvement, ITIL, ITSM, Problem Management