The thesis is that the first step in solving a problem is stating it. It's hard to argue with that, but people do.
Here are all some ways that people have made stating a problem as difficult as possible.
- Complain that there are too many steps in the methodology. For example: (1) state the problem, (2) brainstorm solutions, (3) use the solution as the inception of a project, (4) elaborate the analysis, (5) design and implement and (6) transition for production use. Since this is more than two steps, it is too many.
- Complain that methodologies limit creativity/insight/flexibility/whatever. Refuse to pursue any structured approach.
- Simply refuse to define the problem without providing much of an explanation. Things like "That isn't the number one priority" are great ways to rephrase simple refusal as if it is merely a question of priorities. Everything that isn't priority one will never get done, and putting problem definition below #1 on the list of things do to damns it to eternal avoidance.
- Complain that it is hard to define a problem. For example, "It's easier to hack out a prototype than define the problem we are solving".
- Complain that there is no point to defining the problem. We can, for example, insist that there is no ROI on defining the problem, all the ROI accrues from solving the problem.
- Complain that defining the problem requires interaction. It's not clear exactly how this is "bad". It appears that problem solving (like programming) is a solitary experience: we discuss briefly with the users, then run away to our Fortress of Solitude to invent a solution which we briefly discussed. Unwillingly, we engage in weekly/monthly/quarterly progress meetings. The idea of negotiating over the context, problem, costs and values seems to be pointless, since it isn't the solutions, it's just talk.
- Complain that budgets are sacrosanct. It's not clear what this means. Perhaps this means that taking time to define the problem will derail an improper or ill-advised solution that's already in process. Note the sequence of events implied by this objection: (1) we're already "solving" the "problem", now you want us to (2) formally define the "problem"? That might invalidate the "solution", already in progress.
- Complain that problem definition requires people to admit that they made a mistake. I don't understand this at all, but some people are very, very sensitive to the possibility of problem definition being taken as an "attack" on someone who made a "mistake" which we now have to "fix". Okay. Can we move beyond the fear that there might be childish name calling? It's not like we actually have any name-calling; the objection is that recognition of a problem may be perceived as name-calling and finger-pointing.
- Complain that it's difficult because an individual (a single human being; one person) might wander from the original problem to other problems. With a committee, this is a very real issue. But for a single key user? If there isn't a problem that is bothering them... well... there isn't a problem. If they can't say "fix this and I'll be satisfied," that's an important cultural or organizational issue. Clearly, it isn't technical, and doesn't deserve much more than professional counseling.
- Conflate the solution with the problem and describe the solution.
I see three parallel activities as part of this concentrated avoidance effort: ignore it, evade it, and pervert it.
One ignores it by pretending a problem statement isn't required. This is the most blatant denial of the value. A specification of the solution will do. Lacking any definition of success, scope creep or dissatisfaction are inevitable.
One evades it by acknowledging that there may be some potential value, but assigning all other activities a higher priority. This is a more subtle denial of the value, but the effect is the same: the tacit assumption of a problem means unclear or divergent definitions of success, which leads to scope creep or dissatisfaction or both.
One perverts it by twisting around the meaning of "problem" to include solution-oriented concepts. In this case, we're urged to write very complex "problem" statements that include technology and business constraints "so they won't be forgotten" during the process of solving the problem. This is absurd. The technology constraints aren't part of the problem and they won't be forgotten unless the entire project team wins the lottery and leaves with no forwarding address.