Problems

A problem arises when there is a new conflict of desire. I could be going along in my life and then something changes so that my desires are now in a conflict with my experience or it might be a longstanding conflict that I am just getting around to addressing. I might have developed some new goals or been given a new assignment or project. The goals by definition define some state of affairs that are desired and that do not already exist.

The first step in problem solving is to understand the problem. What are the goals? What do I mean by the language I am using to describe the problem? Is there a better way to describe the problem, better language? I need a problem statement. It should be clear from the problem statement what state of affairs would constitute a successful solution to the problem. The goals should be clearly listed and should be testable.

The second step is an exploration of the problem area. Is this a new problem or have others solved it before? How good were their solutions? What is the relevant knowledge and tools that apply to this situation? Are they practical for me in my circumstances? This step may involve talking to people who have solved similar problems, doing a literature survey, or doing some experimenting or prototyping to try out ideas. One danger here is paralysis by analysis. We need to set limits on how much exploring we should do. When does the problem need to be solved? How much money and time can I spend?

The third step is to enumerate alternatives based on the explorations that we have done and to compare them to the problem statement. How well do the alternatives meet the goals? Maybe we need to go back and change the problem statement because the goals are too ambitious. Sometimes it may be useful to list out all of the goals and to give them weights, say from one to ten. The tens are essential. The ones are nice to have but really optional. Then for each alternative, we estimate the probability of meeting the goal using a number between zero and one. We then multiply each probability times the corresponding weight and add up all the results. The alternative with the highest number wins. Of course, you may only rarely go to this level of detail and if you do you may still choose an alternative with a lower number, but this illustrates the sorts of tradeoffs you may need to consider.

The fourth step is to implement the chosen solution. As you implement the solution you may find that you need to go back and revisit any of the previous steps.

The final step is to evaluate the results of your implementation. Did it really solve the problem? Maybe you have learned new things in this implementation that can be applied to another iteration of problem solving. Or maybe your time is up and you have to either decide that you have not solved the problem or that this solution is good enough for now.

This may sound like a very formal process and in fact in engineering these steps may be formally defined with groups of people performing different roles, a formal paper trail, and gates between steps. But we also do this sort of thing everyday. We need to fix our kitchen faucet. We draw on existing knowledge or read up on how to do it. We consider alternatives. Then we pick one and try it out. If it works, OK. Otherwise, it may be time to call the plumber.

Notice the use of language, experience, and desire in this process. We experience a conflict. We use language to articulate the desires that need to be met. We draw on past experience or texts to come up with alternatives. We put the selected alternative into action. And in the end, we have been successful if language, experience, and desire are back in balance, at least in this particular area of concern.