The Townsend Report

Most of our clients are looking for off-the-shelf software to fulfill their needs for line of business solutions.   Their requests for proposals typically contain a long list of desired features, and we are asked to characterize whether the feature is "out of the box" or requires customization or custom programming.   Proposals are scored higher if they have more features listed as "out of the box" and as few as possible requiring custom development. I understand the motivation for this approach.   Custom development has fallen out of favor, and more "out of the box" features reduces time, cost, and risk for an implementation.  This approach is not sophisticated enough to lead to the best choice, however. Many features required in a line of business solution are inherently "custom" because organizations follow business rules and workflows that are quite specific for their industry and niche.  Companies strive to differentiate themselves from

In fashion, the way your clothes fit is more important than whether they are the latest style.   If they are too long, too short, too tight or too loose, you can't achieve the comfort and style you seek.  So it is with enterprise software.  When we see a request for proposals, it usually contains hundreds of detailed specifications for features, but only a cursory list of requirements for compatibility with enterprise architecture and integration with other systems. This feature-centric approach leads to poor software choices and increases the long term expense of integration and support.  If your organization has adopted standard software services for all departments, you should not keep re-purchasing the same features every time any department needs a new point solution.   Your organization can save money by standardizing on a database, reporting tools, email, and other shared services.   The way a solution fits with the rest of your architecture may be more important than

Many organizations are plagued by incompatible software solutions that proliferate in multiple departments.  These solutions are expensive to support because they may require different skills from developers and system administrators. The quality of data also suffers because records are updated in one department and not another. The result is a search for a single system that will rule them all. If this sounds familiar, it is because the desire for a monolithic and comprehensive software solution is timeless and universal.    The problem is that this quest is futile, and has been shown repeatedly to fail by large and small organizations. Politics is usually the reason that a universal solution fails, not technology.   Individual departments know their data much better than anyone else, and are justifiably reluctant to give up control. Change is also the archenemy of the monolithic solution.  It takes time to document and implement requirements, and these business needs are subjec