I have drawn upon Henri Bergson’s definition of intuition to make this point, but it is really something you might see every day if you are in any kind of problem-solving role. I have worked on a long series of organizational changes and software implementations, and it is clear to me that a “solution is a well-stated problem.”
And let’s for a moment understand what we mean by the word problem, because there are many ways we can hear that word, and the way we do will create different emotional responses, each of which will yield different results in the mind of the hearer. For our purposes, a problem is neither negative or positive, not the kind of problem one has when one has missed the bus and will be late for an important meeting, or if one doesn’t have enough money in one’s checking account to cover this month’s rent check. Not like that. What we mean by problem is the difference between where we are at the moment and where we want or need to be. For instance, if where I want to be is being able to play Twinkle, Twinkle, Little Star on the violin (something I have watched both my sons solve over different periods of time) then the problem is finding out how and what to practice, how to make time and motivate oneself to do so.
In a sense, a problem isn’t even a problem until it is well-defined and stated. Until then it is an amorphous something-or-other that may or may not really be an issue and arise out of the muck of countless ifs and maybes. Sometimes it will be a high-priority critical issue that comes up and is causing you or a client a major difficulty: a process is perhaps broken, and the results are misrepresenting what is actually occurring in the world. In banking software, this kind of thing is a real problem, and it thankfully does not occur that often. When it does, however, the solution is in a sense already well-defined, at least in part, as there is a well-defined expected result one is not getting. There may be a mystery as to how the software is generating the unexpected aberration, but at least there is a clear end-point in mind. It may take some work by business analysts and developers to drill down into the actual workflow and software processes, to better understand how those results are being generated, but once that is done, the problem then becomes well-stated, and the solution is defined as well.
Where things get a bit muddier, however, is when there isn’t yet a clear understanding of what the results are to be. This is a different kind of problem, in essence, not a problem in the same way as the above issue, but more of loose aspiration that still needs clarity. We arrive again at the point where we need to take a vague concept and transform it into percepts, and those percepts will be the material used to generate a well-stated problem, or objective.
Perhaps a client wants an entirely new process in the software, or wants to automate a manual process. This is where things get interesting, since creating an entirely new process, or automating a manual process, is an entirely different realm of problem from the critical issue, where a clearly defined working process goes awry and needs fixing. In the case of automating manual processes, one can’t just replicate each function a person does, since there are controls in place in the manual process, in order to eliminate or decrease the likelihood of human error, which would not make sense when creating a uniform mechanical process that isn’t smart enough to generate those types of errors. You also need to consider what points actually do require human intervention, for instance, where human judgment of some sort is requisite, and whether a process needs to be put on hold while someone makes a decision, and how that person will be appropriately informed so she can make that decision. There’s a lot to mull over, a lot to comb through and design.
But it’s the new and unexplored territory that gets most interesting. There may be a new business opportunity, or some strategy that someone wants you to put into place. Very often these are the most undefined and fuzzy of the types problems you will encounter, since there’s no functional model to rely on, only, as I said before, an aspiration. When working with this kind of problem, you are best to begin thinking like an artist. You start with a core idea, but you may not really know where you are going. You build it out, generate a number of interconnected ideas, eliminate redundancies, redesign, perhaps hit roadblocks and start over again. The result may not look anything like your starting point, and that’s because each step, each new idea, every interaction you are having with your client who is perhaps asking for this change, is giving you new feedback, changing your perspective as to what it is that needs to be done. It is more of an exploration than other types of solution work. And in this case, the stating of the problem is in itself an ongoing event, an adventure of sorts.