What’s your problem?
Complex Problem Solving is THE skill we need in the coming years, at least that is what the World Economic Forum says. But what does Complex Problem Solving mean? Better, what does Problem Solving mean? Even better, what’s a problem and what’s a solution?
When looking for the meaning or the definition of something, I tend to go back to its origin. Blame it on the philosopher in me. “problem” goes back to the Ancient Greek “προβάλλω” (proballo) meaning something as “thrown before”. So, a problem is an obstacle thrown before something so you cannot go forward. It can be physical (big stone on the road) or verbal, such as an argument against what you were stating. “Problem” is also used in the sense of a given task (let’s say a mathematical problem for students). There is a lot more to be said here, but you get the general idea.
In everyday use, the word problem is used for any difficulty that needs to be resolved or a question that needs to be answered. There is an obstacle (a problem to be solved) that is in your way to move forward. There are other strict, contextual related definitions such as in ITIL where a problem refers to an (unknown) root cause. Within that context Complex Problem Solving and Root Cause Analysis are almost synonymous. I think that the ITIL definition is too strict and the definition of incident does not help that much either. It does not cover all the problems you’re facing in your organization, not even on the IT level.
The Greek definition (an obstacle) gives a broader perspective for a practical definition of “problem”, at least when thinking of solutions (removing the obstacle). I use the following definition. A problem is a “subject with a deviation”, in other words, something is wrong with something. I’ll explain.
“Subject” is “a person or thing that is being discussed, described, or dealt with”. Again, this goes back to the Greeks and Romans, from “Hypokeimenon” and “Subjectum”. “Subject”, is a physical thing including persons or a group of persons, organizations etc., but can also be non-physical such as ideas, hopes, or virtual servers. “Deviation” comes from the Latin “Deviare” meaning something as “away from the way”. Nowadays it is used as “the action of departing from an established course or accepted standard” or in statistics “the amount by which a single measurement differs from a fixed value such as the mean”. So, you have a certain way (towards a certain goal) and you move away from it, for instance because there is an obstacle on the road. In other words, there is a norm and you move away from reaching that norm. In this way a deviation can only be understood if you actually know the way, the norm or the expectation.
As we are trying to solve problems here, the more specific you get about the subject and the deviation, the more clear and distinct your problem becomes. And with a more specific problem, troubleshooting becomes easier. Let’s look at an example.
“Outlook is slow”. This is a problem. There is an obstacle on the road. You want to do something and the slow Outlook is an obstacle for moving forward at your desired pace of productivity. You recognize the subject (Outlook) and the deviation (slow). This is how a service desks around the world receive calls every day (“My Outlook is slow!”). But unfortunately, this problem statement (although it is subject + deviation) does not really help to solve the problem. It is too vague and it needs to be more specific. A vague problem leads to jumping to conclusions and solutions and in many cases you jump wrong.
What does the customer mean by “Outlook”, is it everything about Outlook, just the calendar or email, the startup process, what? Furthermore, what does “slow” mean? For instance, does starting up Outlook take longer than usual? Or does it take longer than promised? What norm is used (promised time or expected time) and what is the exact deviation (1 or 2 seconds, 30 minutes)?
I’m not stating that “Outlook is slow” is not a real problem. The customer actually is having the problem of a slow Outlook. But when trying to solve the problem, especially as problems become more complicated and complex, being more specific is the first step in solving the problem. And here you can be more specific about both the subject and the deviation. For instance, Outlook is slow, means starting up Outlook (subject) takes 5 minutes (deviation) and usually it is between 10 and 15 seconds (norm/expectation).
So far we have seen what a practical definition of “problem” is in solving it. It is a subject with a deviation and the more specific you get, the better you see the actual problem and cannot confuse it with something else. Clear and distinct problems are “easier” to solve. The definition of a problem as a subject with a deviation also helps to see what kind of solutions there are. I recognize 3…
First, let’s get back to those Romans. “Solution” comes from the word “Solvere” which means loosen, release or cast off, to make less tight or firm. Nowadays solution means: a means of solving a problem or dealing with a difficult situation, the correct answer to a puzzle, or products or services designed to meet a need. Recognize that “Correct answer” and “a need” are norms here. So, a solution is a means of reaching a norm. Or, when looking to the definition of a problem, solving a problem is getting rid of the deviation so the subject is at its norm. You can do that in 2 ways…
One way to solve a problem is to get rid of the obstacle, or to fix the deviation. When Outlook is slow, or better, if it takes 30 seconds (deviation) for an email to get out of my outbox (subject) instead of a maximum of 3 seconds (norm), the solution is to get it within the 3 second norm again. In this way, we removed an obstacle on our road.
Another way to solve the same problem is to move the norm (change the road around the obstacle). Just move the norm for outgoing mail to 30 seconds and you are within your norm again. Usually, this is not the first thing we think of, but it is a valid solution to any given problem. Of course, valid does not always mean desirable here :).
The last solution is a more academic one and as with all academic discussions we need to make it practical with an example. Let’s say you are a provider of remote desktops. You supply the remote desktops to several thousands of employees of your customer. Since the launch of the service, the employees have been complaining about very poor startup performance and they are very clear about it. From the moment they push the On-button, to the moment they can type the first word in Word it takes approximately 4 minutes. And that’s too long. Problem: startup sequence remote desktop (subject) takes 4 minutes (deviation).
The question here is, what’s the norm? The customer is very clear about that norm; it was even put into writing in the contract. Customer and supplier agreed upon an average of 1 minute of startup time. Now it seems we have a clear deviation from a clear norm, right?
Not exactly. Upon investigation, it seemed that the 1 minute norm was not based upon any technical specification, design or whatever. The norm was a “random” norm from the sales department, but technically that norm cannot be reached with the current setup. After testing, the startup sequence is not faster than 3,5 minutes. There was nothing to support the idea that the 1 minute norm could be reached. But, because it was put into writing it became a very real norm for the customer.
As the norm was never validated to be “real”, the problem itself has changed because the nature of the norm changed. It changed from a technical norm to an expectation based upon, well, nothing. And since the norm changed, the deviation changes as well. The first problem (technical) changed into another problem (a sales promise that cannot be kept). The first problem dissolved into another one and so the first problem disappeared...
End academic discussion :)
Of course, this is not THE solution to the problem for the customer. It is still the same norm and the same deviation for them. They were promised a startup within 1 minute and promises you have to keep. For the supplier, the norm was never real. They should have made sure they could deliver on their promise. To solve this problem, you need to change the deviation (solution 1: make sure you reach the agreed 1 minute norm) or change the norm (solution 2: agree upon a new norm) or both.