How often do you end up looking at one problem, and find that to solve it you have to solve all the others that it is interconnected with at the same time? One of the reasons I have found dealing with performance problems interesting over time is that they tend to be like this. It is only relatively recently, however, that I have come across the idea that this is a general class of management problem that occurs in business. They have been studied under various titles (e.g “wicked” problems), but the common feature is complexity and an inability to have a single easy solution.Examples of the properties of such problems include:
- Not being quite sure what the root cause is – management approach, technology etc.
- Having no clear route to a complete solution, as distinct from a temporary work around.
- Having to “try it and see” to solve the problem and continually adjust approach depending on the results.
Why do I assert that performance problems are often in this category though? There tends to be a definite issue that you can point to, and you will know when it is “solved” because the system will be performing well. The reason is that usually the defined performance problem is, in effect, the proverbial tip of the iceberg. It may be possible to just solve that fairly easily, such as add more hardware. It is rarer, however, for this to be a complete solution as there is almost always implications and subtleties of stakeholder needs and expectations that this won’t address.
What to do then? There are wide range of solutions. One important step, however, can be to form some form of map of the problems, potential solutions and how they are related. There are various defined techniques but start with something simple:
- Write on sticky notes all of the symptoms you can think of. (e.g. Too slow a response time.)
- Write on a different set of notes all the solutions you can think of. (e.g. Buy more CPU.)
- Write on yet another set all of the constraints you can think of for solving the issues. (e.g. Budget)
- Group these together and draw lines between them to show relationships.
This is based on a technique called “Causal mapping”, for which there is support software available, though I f. The process tends to help clarify what really needs solving, and how you might go about solving it. The examples above are about performance problems, but the idea can work for a much wider range of issues. Try it, and let me know what you think and how you get on.
Sarquol Ltd 
Very interesting. I also like to consider the following questions related to sticky problems:
– to whom is it a problem?
– why is it a problem to them?
– will solving the problem cause another problem elsewhere?