Problem Solving

Author: Laura Moorman

October 2009

Most IT organizations find themselves, at one time or another, beleaguered by a recurring problem whose root cause remains elusive. 

In the face of such problems, managers rely on their very best technical experts to analyze and resolve the issue. Yet sometimes it seems that even the most brilliant technicians cannot quite discover the root cause, even after months of analysis.

A few years ago, I found myself in the role of Problem Owner - a proverbial IT gumshoe, tasked with finding and resolving long-standing technical issues across an entire IT organization. My experiences working with diverse teams of DBAs, software engineers, and infrastructure experts revealed some interesting observations on problem solving and some ideas for managers trying to solve a recurring problem.

Get all the players talking to all the other players
Lack of organized communication may very well be the number one reason why problems stay around so long.

I was once asked to intervene with a problem that had, to date, taken down a critical reporting application four times. The application owner had tried to work out the issue with an infrastructure technician, and then with a security expert, but after several months no resolution had been found.

I got three players on a conference call to talk about the issue. The call played out like this: The application owner knew the result of the problem, but did not know the root cause or how to fix it. The infrastructure technician knew what was causing the problem, but didn’t have access to fix it. The security expert had the access to fix it, but didn’t know what needed to be fixed.

Getting the infrastructure technician and the security expert talking to each other was the key to solving the problem. Both had been individually engaged, and had tried to help, but were missing a key piece of the puzzle.

Assign an impartial third-party to own and manage the problem

It can be hard to find ownership of a problem amongst a group of technicians adamant that the problem is not with “their system”.  Engaging someone that is not directly related to the problem- the owner of an unrelated application, a trainer, or even a tester – to own the problem and facilitate the team can be helpful.  By having no stake in the problem except its resolution, this person has the priorities necessary to focus on the root cause.

Focus on the cause, not the effect
Problems often get lots of negative attention from customers, business owners, and management. No one wants to discover that, in fact, a defect in “their system” was the reason why the company lost money.  This stress can cause technicians who typically love to collaborate to become uncooperative. In such a case, it can be hard to get key facts to come to light.
Problem owners and managers who focus on finding the cause and rewarding the finders rather than stressing the effect and punishing the offenders have a better chance of building a cooperative and effective problem solving team.

Stress unity
At the end of the day, the entire IT organization is one team, despite its breakdown into silos and subteams. A problem in any application or subsystem is “our problem”, whether or not the cause of the issue lies within “my system”.

Make time for problem solving
Investigating problems can take a significant amount of time. Technicians often have to be exploratory, creative, and meticulous while sniffing out a problem. At the end of the day, a lot of this work will reveal nothing conclusive and can look like throwaway work.

In a world of increasingly smaller IT organizations with increasingly larger workloads, other priorities that produce obvious results often trump investigatory work. However, to resolve problems, legwork must be done, and must be given proper priority in order for problem solving teams to be successful.

Laura Moorman is an IT Business Analyst for WorkflowOne, a Dayton-based print and promotional products company.