Tuesday, March 20, 2007

March 20 - The Solutions to Problems

Problems largely get solved in two ways, by command or by consensus. The command method is the one most are probably familiar with. The traditional story, here, is that somebody sees a problem, sees a solution to the problem and sets about implementing the solution. Some of us might see Thomas Edison in this role, but almost all of us practice this type of problem solving all day long. A peculiar characteristic of this method is that the problem gets solved primarily for the solver and mainly by happenstance for other people. Some people may not see the solution as a solution at all, it is so bad. In a normal market, you may get several such solutions in competition. This is generally seen as inefficient (but maybe more efficient than the alternative.)

Solutions such as this are all around you. You may wonder why Verizon phones can not roam on Cingular networks. It is because they are both the product of command solutions and are competing against each other. The different floor-plans of houses represent this method. Any one type of restaurant could satisfy the nutritional requirements of a human, but there many different types of restaurants all competing. Inefficiency sure isn't all bad.

Consensus problem solving is very different. Consensus problem solving attempts to solve a problem for everybody. In this case, seeing a solution is not good enough, you have to see a solution that satisfies all people who have the problem. Potentially, you have to solve the problem for people who don't have it yet and therefore have a different set of requirements than anyone existing. Does this sound tough? Good it is. In the end you wind up with, not an excellent, but an adequate solution for everybody given a job well done.

Examples of this are all around you, too. Your electrical outlets are one such. The timber in your house another. Look at the sockets and bayonets of your light bulbs. Do they screw together? Why? They are all made by different companies who would gladly lock out their competitors with a proprietary and superior solution. It is because the adequate solution is actually superior and actually fosters more fair competition. When the consensus approach works, it works well.

This is not, by any means to say that he consensus approach is better. However, when a solution is likely to become commoditized. That is to say, when, in the long term, the solution will likely not compete on the basis of differentiation, the consensus approach is probably a better approach because it reduces monopolistic behavior and reduces the cost of implementing the solution.

I am involved in forming consensus solutions in my industry. I belong to a standards body seeking to describe a solution to a particular problem. Each of us in the committee has an idea of the problem and and idea of a solution and all of them are command type solutions. We are working to reconcile their incompatibilities and make the solution encompass all of our requirements. We are working to envision the requirements of our industry 10 years down the road so our work has continuing value. This is not easy.

I was asked the other day by a potential user of this standard why it is taking so long. We have been at it for a year and a half and, to others, it appears we have nothing to show. We can not even say we have made any decisions that people can work from. It was his assertion that a solution is "so simple." Moreover, he's right. "A" solution is "so simple". The command approach solves the problem in a matter of months, move on. But that would not satisfy all, or even most of the consumers of the standard.

I was stymied by his "taking so long" opinion. Having been on other standards bodies, I think we are rocketing along. It takes time to consider the scope of what is known and to consider what you can predict about what is unknown. It takes time to open your thoughts beyond your own command-based solution to the problem. It takes time to reconcile the differing opinions in a body of people. Even when you think you are done, you have to test your ideas against a larger body to see if they agree and then go back to the drawing board to address their issues or explain them away.

This time expenditure is a limitation. Even if we ratified one command solution over the others and went through the process of documenting and releasing it, years will pass. Progress due to the passage of time tends to reduce or even eliminate the value of a command solution. This is why people working on consensus solutions must take a long, broad view and be prepared to work for years. Moving too fast will result in a lesser product. To put it another, more traditional way, it isn't soup yet.

1 comment:

joeyblades said...

Of course, there's always the potential for a consensus-command-consensus hybrid...

For example (just hypothetical) consider a specialized programming language developed by concensus, but lacking suitable hardware and a market demand. Then along comes a commercial problem that this language seems well suited for. The language, is adopted and along the way some unforseen holes are filled in to complete the commercial (command) solution. Finally, as the language starts to catch on in other segments and other related applications, the command solution becomes the consensus solution once again, new additions and all...

Of course, that's just hypothetical. It could probably never happen in real life.