Being Good Enough

This month, Wired magazine has an article about products that are good enough to do the job but not great. The point of the article is that this is how these products can creep up on the leaders in the field until eventually the are capable of surpassing them.

The same applies to problem solutions. Often we are perfectionists, trying to anticipate every possible angle before implementing the solution. Sometimes this can delay implementation of a solution and result in lost opportunities. Often (except when safety is involved) getting a partial solution in place quickly is more important than addressing all the issues beforehand. You can then evaluate what the weaknesses are under operation and utilize an iterative process to optimize the system. Your supporting structures (management of change, document creation, document control, etc.) need to be efficient enough so that they aren't a drag on the process.

If your support functions are more taxing to complete than the solution itself then something is wrong. Often Quality organizations become enamored with lots of checks and balances and the whole process gets bogged down. Often these people aren't users of the process but only enforcers. If you start thinking to yourself that you know how to do something but don't want to cut through all the red tape to get it implemented, then something is seriously wrong. Both because good ideas may not get implemented and because people are tempted to take shortcuts without submitting the ideas to the proper review process. This can lead to unintended consequences.

Even our best laid plans can go awry. One needs to balance the desire for a "right the first time" solution with the inevitable refining process that occurs anytime you try something new. Continuous improvement works best when it is continuous. If it proceeds in fits and starts, then often it won't re-start.