Having worked as a problem management analyst
I always understood that there was a point where you may dig for root cause and
still come up with seemingly nothing. It was because of this that I always like
the quote by the fictional character Mr. Spock “Once you have eliminated the
impossible, whatever remains however improbable, must be the truth.” That’s an
interesting thought and I will explain how it applies to problem.
One of the challenges with working with
problems is that for the most part IT may have a somewhat backwards perception
on the process which searches for root cause to eliminate incidents. In many
cases (but not always) IT values the work in which incident does to correct
issues. We have heard this all before, so I won’t beat that drum, at least not
today. The trouble is that there may be very little emphasis on what goes on
behind the scenes to permanently eradicate these incidents from happening in
the first place.
Some problem managers would beat themselves
up as they seem to get really close to figuring it out, but then seem to come
up short. While others become frustrated when they chase a wild goose so to speak
and end up not solving the problem either. So what’s a good problem manager to
do?
I look at it like this; I may not
know what the cause of the problem is, but I know what it isn't and that is
important. This might make me a “glass is half full” kind of practitioner.
The important thing I try to do is not keep these
findings locked away in a problem drawer somewhere. There was in some cases
considerable effort spent to find this information, but since no results were
realized it looks as though nothing was accomplished which is not the case.
That is why so often when management looks back on problem it seems as though
loads of effort is spent with little gain.
During the investigation of a problem I try to not
only track the findings in the problem record but share information with teams as
there may be unrealized value to them. Your organization may have regular
problem meetings in which the information is shared (if you don’t you may want
to consider starting). A key thing to remember when you are having these
review, you may have more interest in the investigation than the audience in
which you are sharing with. I once met a guy who said his problem reviews we
held monthly over a two hour session. There were quite a few yawns and
eventually less turn out over the course of time.
The key is to have a format and review what is
important to not only the meeting participants but your business outcomes as
well. There’s a pretty good chance that if your business is impacted your meeting
will have more merit. Another consideration is you likely have problems which
have a low priority and may not require review, so mention that they exist but
only address them as a side bar if someone requires it.
The list of review items could look like this:
·
Problem description
·
Impact to business
·
Related incidents since last discussion
(volume/durations)
·
Planned changes
·
Any findings even if they produced no results.
It should include a representative from a breadth
of teams from infrastructure, application support, service management, and
where applicable you can include business relationship managers or service
delivery teams.
This brief review will allow participants to
provide input even if your current problem analysis has hit a dead end. This discussion
point may also shed some light on other areas or even other problems teams are
facing which may relate to your other investigations.
The key is to keep it brief will allow the people
attending to get on with their day and spend more time helping to improve
service delivery rather than spending time reviewing what isn’t working.
Follow
me on Twitter @ryanrogilvie
or connect with me on LinkedIn
Labels: Incident Management, ITIL, ITSM, Problem Management, Service Management