Most of my projects begin with a series of interviews with the client leadership. I've found it's always best to secure first-hand knowledge of the client's objectives and, most importantly, the problems they want to have fixed. Often, their view of the problems differs from my view. Determining the real problem is critical to setting expectations and achieving the proper objectives.

I recall interviewing a director of customer service who stated the problem I was to address like this: "The phones just recently started ringing off the hook, I'm missing my ASA times, our customers are really upset when they call, my service reps are ready to quit, and the objective of the project is to justify hiring more service reps on the phones. The place is falling apart, and I want to get my boss off my back (his real objective). I need you to help me get approval to hire more people."

He had diagnosed the problem as too many phone calls and not enough people on the phones to handle the volume. When I asked why the clients were calling, his face went blank and he said, "I don't know." Since he had no knowledge as to why the phone calls had increased, he had misdiagnosed the problem. Adding more people without understanding the cause of the increased call volume was not going to solve the true problem.

After a quick "tick and tally" study of the incoming calls, we were able to categorize the reasons behind the calls. We soon found many were the result of poor processing that generated mistakes which, in turn, produced irate customers who called to complain. A secondary problem was a processing backlog that resulted in clients calling to check status, often several times. Once we discovered these two primary drivers of call activity, we were able to take action in the processing areas to reduce errors and eliminate the backlog, which resulted in a decrease in call activity. Most importantly, we got his boss off his back, and we didn't add staff in the customer service department.

I see this type of problem identification often. As a manager, I probably did the same thing. If the director had acted on his analysis and idea for a solution to the perceived problem, only part of the problem would have gone away. He may have met his objective of getting more people, but there still would have been quality issues, a continuing backlog, and irate customers; and his cost of operations would have increased. Not a very satisfying result.

Identifying the root cause of a problem is not always as easy as a tick and tally study. Often, it takes time to do the research necessary to conduct a proper analysis. That requires crisis management and the use of an interim plan until the analysis is completed and a plan of action developed. While potentially painful, a thorough analysis lays critical groundwork to proper corrective action.

A few questions to consider when conducting an analysis might be:

• Am I looking at the real problem or symptoms of the problem? (Water dripping onto my carpet is a symptom; a hole in the roof is a problem.)
• How many customers does this affect? (Don't accept "I think…," even from yourself. That is perception, not reality. Get the real number.)
• How frequently does this occur? (Daily is generally a much bigger problem than once a year.)
• What is causing the symptoms? (Analyze the process—not the people—for causes.)
• Have I arrived at a solution before knowing what the problem is? (It's easy to do, but usually doesn't solve the real problem.)

It is often very difficult to complete an analysis of a problem and develop a proper solution when you're in the midst of damage control. Reacting without understanding is usually expensive, time-consuming, and not very effective.

Remember, when your ceiling is dripping water, it may take more time and money to buy buckets than it will to find the hole in the roof and patch it.