Back about a month ago while on a plane that was headed to Detroit I had an interesting chat with a guy named Rich. I forget many of the things he told me, but one of the things that I did remember was a strategy he had for problem solving. See, Rich’s job was a ‘creative manager’, which as he described it to me means that he organizes/manages project teams in a way such that the technical people (in his current job they are mostly electrical engineers) can focus on creatively solving problems. To this end he does several things such as cut through governmental red tape, take care of the logistics, plan meetings, etc. But those things are not what interested me, what I found interesting was the way he made the engineers approach a problem, that is, with SPRI.
Now I realize that there are umpteen million methods for breaking down the steps in problem solving most effectively. I am not claiming that Rich’s method is the best, or even that I am relating the method exactly as he explained it to me. What I am claiming is that I think it is simple and effective; the epitome of the KISS principle that I hold dear. Below I give a general overview of SPRI and later I will post a specific example of its use.
Statement; Problem; Resolution; Implementation
Statement
In order to plan your future wisely, it is necessary that you understand and appreciate your past.
-Jo Coudert
The first part of solving any problem is to accurately and completely describe and explore the situation. This generally starts by enumerating the end goal of the project in an almost idealistic or theoretical manner. Be specific — ill-defined goals lead to crappy solutions. At this point you shouldn’t hamper yourself with questions like ‘Can we actually do that?’. Instead you need to think to yourself ‘If I had unlimited resources, what would I want to accomplish?’. This is your chance to think BIG.
Once you have the end goals well-established you need to completely explore the current state of affairs in regards to the problem. That is, you need to do the footwork to figure out what has been done in the past. In academia this typically means doing long, tedious literature searching, but this approach is not the end-all by any means. For programming projects I typically search online forums, look for open-source project, and email/PM experts in the field. However you accomplish it, at the end of the day you should have a complete education of what has been tried in the past — this will stop you from trying to ‘reinvent the wheel’. A failure to do this will be just that, a failure, certainly not a good way to start.
Problem
We have met the enemy and they are ours.
-Oliver Hazard Perry
Here is where you need to identify exactly what is keeping you from your goals; it starts with identifying the obvious problem, but then you move on to the analysis, that is the breaking down of the problem into its most basic constituent parts, which is the most important part of solving any problem. This step typically involves some sort of abstraction, and as simple as many think it, it is frequently more subtle than you might think. There are usually many levels of abstraction for a given problem, and your goal is to find the correct level of abstraction. Too little abstraction and you probably haven’t gotten to the heart of the problem, and too much abstraction and you will probably end up with a vacuous problem statement.
I find it really amazing how this step can simplify the whole problem solving process; a previously impossible looking problem can generally be reduced to a series of small, very-manageable sub-problems that were not at all visible beforehand. Incidentally, these sub-problems are typically the ones that screw over people that don’t thoroughly analyze a problem before trying to work on the solution — you can’t solve a problem if you don’t know that it exists!
Resolution
A good plan is like a road map: it shows the final destination and usually the best way to get there.
-H. Stanley Judd
This step is where you decide on the methods/techniques you will use to solve the problem — aka, the planning phase. You ought to be able to bring together the initial research, the detailed problem statement, and your own set of skills to determine a path to a solution, or at least a path that will probably lead to a solution (remember that problem solving is frequently an iterative process). In experimental research this is typically where you decide what experiments you need to run. In programming this is where you’d decide what algorithms and paradigms to use. In any case, your resolution step should leave you with a clear and detailed road map of how to proceed. Without this road map you will be aimlessly guessing at solutions with only the smallest hope of success.
Occasionally you might find yourself at an impasse at this point. You think that you see the problem(s) clearly, but you can’t figure out how the hell to solve it; your idealistic goals meet reality. This is where you might have to either revise your original goals to be more attainable, or have another try at analyzing the problem. Thus from this step you might very well find yourself looping back to a previous step. This is OK, it’s the way problem solving works. Don’t get discouraged, get determined.
Implementation
No plan of operation extends with any certainty beyond the first contact with the main hostile force. Only the layman thinks that he can see in the course of the campaign the consequent execution of the original idea with all the details thought out in advance and adhered to until the very end.
-Helmuth von Moltke
Up until this point you shouldn’t have written a line of code, run a single experiment, or cut a piece of lumber. Here is where you finally get to do something! You take the plan that you made in the last step and enact it. Nothing more, and certainly nothing less. This is typically the easiest step of all, which is ironic because most novice problem solvers skip all of the previous steps and get stuck in the Implementation step for eternity.
This step, even more than the last can end up at an impasse. You might find out that your plan was incomplete in which case you will need to revise it, or you may find that the plan was utterly unfeasible in which case you might have to backtrack to any one of the previous steps. Again, this is OK, I swear that it’s just the way problem solving works. The more practice you have with problem-solving the less the backtracking will happen, but it will never go away completely.
Happy problem solving!