What's the problem?

Sitting in drizzly Seattle. Tomorrow is the NTC conference, but today is just a lazy day off for me. Thought I'd polish up and post this blog entry on problem solving that's been hanging around half written... One of the things I notice working with our users is that some IT folks are born problem solvers and troubleshooters, and some aren't. I often wonder if technical troubleshooting skills can be taught, and what the best way is to do that. I've also been thinking about this issue because, as I pulled together some marketing material for our NTC Science Fair exhibit, I noticed as I have before that when we ask our clients for "blurbs of praise" to use on our web site or other materials, they do not so much emphasize the features of the software as our ability to help them solve real problems that come up in their work. I realize we are talking about two kinds of problems here. One seems more creative - a user has a business problem and we use technology to devise a solution. The other seems more reactive - its just maintenance. A technical problem appears, and needs to be resolved. But the more I've looked at these issues, the more I realize there is a core to problem solving that applies across the board. And there is no clear line between the two. Donald Gause and Gerald Weinberg wrote a cute little book a while back ago that tries to teach problem solving. It's worth a read by anyone who earns their living by solving other people's problems. And that includes both consultants, and on-staff IT people who need to solve their user's problems. They start by warning that the professional problem solver often sets out trying to offer a solution without having identified what the problem really is, or who really has a problem. When the client is an organization, there may be many people waiting for the solution, but each actually has a slightly different problem. Which one do you solve? Shigeo Shingo is another writer who can change the way you approach problem solving. He was a Japanese expert in manufacturing efficiency and a top Toyota executive and had some radical approaches to problem solving. For example he thought it was just as easy to try to cut the time a six hour process takes to three hours than to five and half hours. If you ask a team to think about a more challenging solution, he always found, they think more creatively and ask more penetrating questions. Like Gause and Weinberg, he was also very big on helping people realize the danger of trying to solve a problem before they had identified it. One of his most remarkable stories: he was called in by a plant manager who complained that no matter what they did, a certain machine broke down every few days, stopping the line for hours. They'd repaired it and replaced it half a dozen times, but it just kept breaking down. Shingo asked the manager if the solution was worth a day of his own time. "Oh, I've already spent much more than a day on this." So Shingo asked him to devote the next day to sitting in a chair on the plant floor in front of the problem machine, and do nothing but watch it go through its paces without making any attempts to intervene. After staring at the machine as it repeated its few motions over and over again for four hours, the manager understood exactly why the machine always broke down and had the correct suggestion for a minor redesign that resolved the problem. Although many days had already been devoted to "solving this problem", almost no time had been spent trying to ascertain what the problem really was. Shingo's emhpasis on "just sitting" with your problem may seem to be a particularly Japanese approach, but we see it in other very practical guides to problem solving as well. Charles Kozeriok has a web site devoted to PC repair that empasizes mental state in technical troubleshooting. I have personally seen many times (and often with myself as the subject) the difference between a person in the right mental state and one who is not, in the ability to identify and correct system problems. It can easily be the difference between a problem that is fixed in minutes and one that languishes for hours or days. Key to this mental state is getting beyond the sense of urgency. Being in "panic mode" makes it extremely difficult for you to work on solving the problem, and in many cases the panic will turn out to be unwarranted anyway....Panicking can also lead you to jump to a solution to the perceived problem before you really understand it, which can make matters worse. So once you've calmed down, what next? Coming soon - Michael's Rules for Technical Troubleshooting. We'll see they focus almost entirely on the central issue we've talked about here - clarifying the problem. Tags: nptech, troubleshooting