What's the Problem?

In the IT world we are sometimes enamored with a solution and try our best to implement it, regardless of the actual problem.  This is the infamous "solution looking for a problem" syndrome.  People who are particularly attached to a technological solution sometimes fail to understand that their solution, while perhaps elegant and sophisticated, just won't be effective in the long run.

There are many examples of this throughout history, but in no industry does this show up more than in the IT industry.  We geeks love our toys.  We love our toys so much that we think they can solve every problem.  Even problems we don't have.  We create components in which 80% of the code is never executed because no one uses that functionality.  We create processes that are large, cumbersome, and built to handle every possible scenario even though something smaller and faster would handle at least 80% of our work.  We put in checks, balances and counter balances in an effort to ensure that something, somewhere is "done right".

Although self monitoring is something which is very difficult to do, I think we all need to step back and look at things from a different perspective to see if we are actually solving a problem that needs solving.  The next time you are proposing a solution to someone step back and ask yourself "What problem am I trying to solve?"  Is this actually the problem?  Are you tackling a symptom instead of a problem?  Once you are convinced that you have the problem defined correctly, write it down on a piece of paper and then come up with a reason why you are trying to solve that problem.  Is this reason something that the organization would agree with?  Does it provide a net benefit to the organization?  (i.e. Does the cost of implementing the solution outweigh the benefits?) 

Lastly. take a look at your solution and see it it is actually trying to solve the problem for the reason you stated.  For straight forward technological problems the odds are pretty good that the solution matches the problem.  Once you start moving towards the fuzzier areas of standards, processes and procedures I am sure that you will find that quite often the problem, the reasons and the solution don't always match up.  If you aren't sure whether or not they match up, ask someone else to check your reasoning.

Problem definition and problem resolution are basic things, but they are sometimes hidden in the tempting glare of gradients, 3D combo boxes, AJAX and web services.  Put on your sunglasses and see if you can really see the problem.  Chances are you might surprise yourself.