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.