The first step in problem-solving is to frame the problem (or define) that you want to solve.
To help you do so, you should set to answer only one question: the key question. A key question isn’t an isolated element. Instead, it is part of an introductory flow, complementing a situation and a complication (see, for instance, Minto, referenced below). This introductory flow also belongs to an environment, where you specify the key stakeholders for your problem and the elements out of scope, amongst other things. Therefore it is fundamental that you identify clearly which question you should solve and what its environment is.
One way of doing that—and ensuring that you are on the right track—is to summarize the elements that you know about your problem in a problem identification card.
Of course, an essential part of defining your problem is to define if you want to understand the root cause(s) of a situation (i.e. solve a why problem) or if you want to identify alternative ways to solve it. As a general rule, it is wise to only ask how if you know why.
Several tools can help you with the problem-definition process. First, you need to make extensive use of logic. This is true at every stage in the solution process, but especially at the beginning. You’ll also need to go deeper than appearances, understanding the implications—the “so what?”—of your problem and its environment. Also, you’ll want to practice this process extensively, enlisting others as much as possible to reinforce your thinking.
Remember that a solid problem definition is arguably the most overlooked step in problem solving. Ironically, it is the step that has the greatest return on investment, because it is a leadership step, rather than a management one. Just like you can’t win a race—even if you are the fastest runner in the world—if you don’t set to run in the right direction to begin with, the success of your entire problem resolution process depends on your ability to identify the right problem. So don’t overlook this step, and get it right. Resist biases, check your assumptions, reframe your problem if necessary, and don’t jump into developping issue trees too early. Instead, invest enough time here; it will pay off later.
Looking at an example might help, here is a case study.
Ackoff, Russell L. “The Art and Science of Mess Management.” Interfaces 11, no. 1 (1981): 20-26.
Arkes, Hal R and Peter Ayton. “The Sunk Cost and Concorde Effects: Are Humans Less Rational Than Lower Animals?” Psychological Bulletin 125, no. 5 (1999): 591.
Bardwell, Lisa V. “Problem-Framing: A Perspective on Environmental Problem-Solving.” Environmental Management 15, no. 5 (1991): 603-612.
Elstein, Arthur S and Alan Schwarz. “Evidence Base of Clinical Diagnosis: Clinical Problem Solving and Diagnostic Decision Making: Selective Review of the Cognitive Literature.” BMJ: British Medical Journal 324, no. 7339 (2002): 729.
Kahneman, Daniel. “Maps of Bounded Rationality: A Perspective on Intuitive Judgment and Choice.” Nobel prize lecture 8, (2002): 351-401.
Minto, Barbara. The Pyramid Principle: Logic in Writing and Thinking: Pearson Education, 2009.