Keeping the Process of Choosing a Solution Simple

Simplicity is underrated.  The best ideas are great precisely because they are simple.  I think the key is to be able to determine the level of complexity that is justified by any given problem. One does not need to build the roman aqueducts to water the garden.  I think this is something that anyone starting or implementing a big software project needs to keep repeating to themselves. It is up to the architect to execute a plan that is streamlined, efficient and sustainable.

There are software vendors out there offering solutions that are too complex for the problem at hand.  They attempt to solve all possible related problems and give themselves all possible functionality and flexibility. Then clients buy into someone selling them a toolkit that says it can do everything, which invariably means that it will do nothing particularly well. Clients devote large teams to the evaluation and implementation of such tools, customizing them to their own purposes. What ends up happening is that over half the allocated budget on such a project often goes to this time consuming planning. People think they are saving something by this approach, saying, “Well this way we only have to deal with one vendor and develop internal expertise in one thing.”  What one needs to keep in mind is that the complexity increases non-linearly with the number of things a tool is expected to do.  

In my experience, the better approach is incremental with well understood and easy to control milestones and functionalities.  Rank your problems, and then solve them individually, and in order.  Buy the best tool for each objective you wish to achieve. Reevaluation after each implementation gives you the chance to solve overlooked and hidden problems and give a superior end result.  For each problem make sure you are not spending more in time and money than the problem is worth.