One of the most frustrating aspects of problem solving is not knowing what the problem is. How can I fix this horrible, unwanted situation! This black box is staring at you and people would say “I don’t know what the problem is”. Of course not, as you’ve just started the investigation!
How should you know?
- Your colleague How often does it happen that in hindsight a colleague did know how to solve the issue? How come you didn’t know about it? Was it not documented in the system? Was it only captured on his internal hard drive? And why didn’t he tell you when you explained to him what was going on?
- The system The system comes up with a “perfect match”, or you thought you found the perfect match. The result provided had the most similarities to the situation you entered. In reality the perfect match was not so perfect after all and the solution provided took you totally off piste and made the situation even worse. The question arises – how well was your description of the problem and how precise was the documentation captured in the system?
- You Although you said you didn’t know, how come you should actually know?
If you don’t know, start to understand first.
Problem solving doesn’t start with knowing what the problem is. It actually starts with understanding. Good problem solvers are conscious about the difference between solving and understanding.. “Seek to understand before seeking to solve” is a principle derived from one of the 7 habits of effective people of Steven Covey and is one of the core concepts of KCS (defined by Consortium for Service Innovation, enabling knowledge management) .
Kepner-Tregoe defined this principle already in their studies in the 1950s. They designed the Situation Appraisal process for it. Getting a good understanding of an issue means you need to:
- Collect the facts – to make sure the starting point is right. The questions “What is exactly going on? What evidence do you have? What should be happening vs what is actually happening?” are giving you a powerful insight in the situation.
- Ask open questions – to make sure to you get all the issues from the customer’s perspective. Closed questions are dependent on what you know, …and that was exactly the issue, you don’t! Closed questions are often based on assumptions and can very easily lead to the rabithole.
- Ask for clarification – rather than concluding on your own, ask “What do you mean by?” and you will be surprised by the answer. As what is being said is often not what is being meant. And evenso, what did you get out of it?
- Separate issues – rather than lump things together. By structuring and organizing issues in separate buckets, they become easier to tackle and to prioritize. Because how sure are you that all these issues can be cured by the same medicine? If you think making it yourself easy by summarizing the separated issues in general terms, you are wrong. It is actually making it yourself extremely difficult to fix the issue. One size doesn’t fit all. Move away from container language and be as specific as possible, by splitting up different symptoms and facts.
- Listen objectively – with an open mind and both ears, leaving your “map of the world” at rest. We often listen to interrupt or are already busy in preparing the response. Listening with full attention isn’t that easy, but give it your best.
But will I get to know my problem?
By embracing “seek to understand before seek to solve” principle, or in KT terms by doing your Situation Appraisal right, you will notice that:
- The dialogue with your customer gets fluent
- Your customer is willing to offer more information because of your quality questions and structured approach
- You understand more about the situation, enabling you to ask for more specific help of your colleagues
- The search in the knowledge system becomes more specific and hits become more reliable
- The system, where all knowledge resides, becomes more meaningful as all people put in more precise information
- You will solve this issue!
- (And ..your customer satisfaction scores go up)
Problem solving starts with not knowing what the cause is. And it should be your aim to get a better understanding of what the problem exactly is, so you can solve it permanently.
An example from reality
Recently I coached an equipment engineer on a problem that was open for half a year. He had put down the problem description: I can’t operate the machine from the user interface and the read outs are too low. Two issues mentioned in one sentence, triggered by the word “and”.
Let’s separate them first, as how do you know that it is caused by the same cause? He didn’t know.
Understanding reality means to ask a question: “So how you know the read out is too low? What do you see? What is actually happening?”
“Uhm, well it has been a while, but I think…” and the engineer made up a story.
Later on he asked permission to go to the cleanroom. “Why do you want to go there” ,I asked, as I was afraid he would go and change something. “To get a better understanding of the problem”. 20 minutes later he came back with screenshots and all actual measurements of the screens and interfaces. Now he could start to understand the issue, before jumping to the solution of it. And he discovered he had more than 2 issues at hand.
It felt like going back and not moving forward. The starting point now is much better.