What I have observed about problem solving during my now approaching 40 year career in Information Technology is that people are often trying to convince others of an approach without ever presenting a problem statement. I've seen people go directly to the solution. Sometimes those people have included me. OK, lots of times it was me. Now, there can be a variety of reasons why this happens. I may have assumed that everyone understands what the problem is (Kalsa, whose book I am currently reading, correctly points out that this is simply guessing.) Other times there may not actually have been a problem, I just had something to gain by the solution being implemented. Sometimes I was presented with a task, to solve an issue, and I just wanted to check that one off my list, so I didn't bother to invest the time to fully understand the problem, so how could I state it properly. More to the point, in each of these situations, how could I possibly arrive at the exact solution?
I'm currently reading a book about a sales process that has been around for awhile - Lets Get Real Or Lets Not Play The Demise of 20th Century Selling, Helping Customers Succeed by Mahan Kalsa, published by Franklin Covey July, 1999 - which may be the longest book title in the history of books. It is a wonderful book that lays out a strong case for its sales methodology. If you're looking for that sort of thing, I highly recommend it. I'd also affirm that this methodology can be quite powerful for any problem solving exercise.
Now, later in life, I've learned the power of a problem statement. Recently, I had an experience where introducing this concept proved to be an effective strategy in resolving conflict in a team setting and bringing clarity to the particular situation. What came about was that one faction on a small team had made a recommendation to make a pretty significant change to an event that had a successful 10 year run. The team was responsible for all aspects of the event; organization, promotion, execution, results. And they had done a great job! To some on the team, the recommendation to make this change seemed to make no sense - it was risky, it was expensive, and it was certainly unproven. Could the entire team support this recommendation? No! Why not? Because the entire team didn't understand what problem was being solved by adopting the recommendation - I'm not sure either side understood what the problem was or if there even was a problem. A problem statement had not been articulated. So, time for the team leader to convene a "lets-get-to-the-bottom-of-this-and-all-get-on-the-same-page" meeting. The leader did a decent job of introducing the skirmish - we've got these folks saying this, but these other folks aren't supportive, so lets talk about it. I had happened to be on the "what-are-you-thinking!" side of the debate, so when the floor was mine I simply asked that we back up a step, articulate what it was about the current event that was an issue, and what exactly is the problem that this solution attempts to address.
It's important to understand that using this process for discovering the problem, as introduced in Lets Get Real, will lead to the exact solution. In the example above, the recommendation was ultimately adopted and made perfect sense to everyone, but only after the leader articulated his vision for an outcome that couldn't possibly be attained without a change, and the team proceeded by unanimously adopting the recommendation. However, the primary point of this post is that by examining the problem statement, there may be an entirely different solution than what is being considered without an accurately stated problem statement.
The next time you feel like a solution is being proposed, make sure there is a clearly stated problem / issue / result (for all opportunities)... especially if you're the one proposing the solution. Oh, and to discover a very solid process for arriving at a clearly-defined opportunity, pick up Mahan Kalsa's book on the subject.