Words of wisdom on the DeSoto Syndrome by Edward Praytor C.D.P., C.C.P.

Published in Business Software Review, October 1987

This article discusses the problems that occur when an organization elects to heavily customize a software package and how to avoid this "DeSoto Syndrome".

I recently saw an old newsreel (circa early 1950s) that announced a solution to the pressing problem of parallel parking. You might have seen it yourself. These ingenious fellows had customized a 1953 DeSoto to turn all four wheels 90 degrees and drive sideways into the parking space. The enthusiastic announcer asserted that no intelligent driver could live without this capability.

I began to reflect on the number of otherwise intelligent system users who insist upon a similar approach to their information processing needs. They are attempting to drive their packages sideways toward obvious but economically marginal solutions that the original systems designers had addressed adequately, but in a different manner.

Let?s assume that you and I had decided in 1953 that our need to park in tight spaces absolutely called for a direct solution. We would probably have purchased a "stock" DeSoto from our local dealer and suggested that his shop modify it to drive sideways into the slot, as the recent newsreel had proven was possible. We would have failed to listen as Dan the Dealer explained a simple, though delicate, technique called parallel parking that would accomplish the same results.

We also wouldn?t understand (not being mechanics) how much the original design of the vehicle had to be changed to accomplish such a maneuver and that the vehicle?s warranty would probably be void as a result. The dealer, having done his ethical duty by advising against the modification, was then more than willing to accommodate our request - for a price.

Soon, however, we noticed that our DeSoto never seemed to drive well. Subsequent problems with the suspension systems required further expensive modifications to fix. When the manufacturer recalled the automobile for routine maintenance and repairs, we found that the "fixes" couldn?t be applied because our own vehicle didn?t resemble the base product.

Worse yet, a few years later, we discovered that the original mechanics who modified our DeSoto had moved to Alaska and no one was around to repair our unique vehicle.

We scrapped our wonderful DeSoto about five years before we intended, and then learned to parallel park.

The parallelism of this Tale of Woe with many large software package projects is often all too exact. In those cases where organizations elect to heavily customize a package and absorb the tailoring cost, the subsequent costs of maintaining the product are severely underestimated. In some cases, system performance is degraded so severely that the additional compensating manual procedures negate the anticipated benefits of the original modifications.

Heavily customized systems are generally more difficult to maintain that a similar system developed totally inhouse for several reasons.

· Future improvements to the base software (releases) conflict with customized code, making it impossible to stay "in sync" with the vendor?s product support program.

· Documentation of the "enhanced" system is difficult due to the requirement to merge the vendor?s documentation with documentation of enhancements. Maintenance of the documentation is difficult to control.

· Expertise in the total customized system is hard to acquire since the majority of the system code is still the package product. The vendors, however, are of little help since they are for the most part ineffective in supporting highly customized systems.

The ultimate hidden expense of an imprudently customized package is usually the premature retirement of an unmaintainable system that has severe functional limitations. Just like our unlucky DeSoto owners, the requirement to make a new purchase is seldom well received on the heels of significant expenses to maintain the old customized system.

This tendency to "tinker" on the part of software package buyers is perhaps the single largest source of dissatisfaction with packages today. Problems due to improper package enhancement and maintenance outweigh problems with poor quality software by a large margin.

To avoid our DeSoto syndrome, you might consider the following tactics.

· Spend time and money on your software search. Obtain "inside information" on the package and vendor capabilities from actual users in environments similar to your own. The closer the fit of the base system, the less you will need to "tinker."

· Weigh your selection toward the vendor with the most client-responsive enhancement program.

· Control the decisions to modify the base system through an objective third party or "mod panel" to carefully justify each modification.

· Spend time and money on development of technical tools and procedures to assist in the retrofit of modifications to new base system releases.

Careful control of customer modifications and a certain flexibility on the part of system users are the keys to long-term satisfaction with a software product. After all, if extensive modification was the answer, parallel parking would be a forgotten art.¨