Avoiding assumptions
Here's a true story about how to avoid a software disaster
by Dick Friedman
The story you are about to read is true, but the names have been changed to protect the guilty. The expensive problem occurred when employees and management of a multi-location distributor made some assumptions. Remember what happens when the word “assume” is parsed under poetic license: ass-u-me. Think of their mistakes as a list of things not to do when looking for a new system or Software as a Service (SaaS). There are other mistakes to avoid not described here.
Top principals of the company raised an alarm when bills for modifications (“mods”) to the selected software totaled 25% more than the license fee for the application software; that total is well into six figures, and climbing. The vendor had told them to assume modifications would be about 10% of the license fee.
Go back two years plus. The company had used its first system for almost three decades, so MIS and users assumed they could select a new system without encountering any problems. To paraphrase an ex-Secretary of Defense, they didn’t know what they didn’t know. They didn’t know systems other than their own, heavily customized one.
The search team created a skimpy list of needed and desired features, based on their old system. It was so skimpy that entire functional areas were described in less than 10 words; it was really an outline. The team assumed that all the systems they would investigate would have all the features not on their list.
Reading through the industry’s most widely read magazine, someone found a list of software packages. The search team assumed that every system on that list was specific to their industry. They also assumed that there were no other appropriate systems other than those on the list. Wrong. Had they done a little research they would have found a few more worth exploring.
They sent the skimpy list of desired features, along with some questions, to several vendors whose names were on the magazine’s list. But the team omitted some key questions because they assumed they could get that information later — which they forgot to do.
Using the skimpy list of system needs as the agenda, several vendors conducted demos. The team assumed vendors would know from the list which features and functions to address in detail. But the list was so general the vendors presented what they wanted to present, not what the distributor expected. As a result, some presentations were considered poor, and then the team made a classical mistake — they assumed a poor presentation meant the system was poor. They eliminated at least one system that would have been a better fit than the one selected. The skimpy list also resulted in demos that did not identify the need for costly modifications, although at least one vendor promised to make several mods for free.
The team eliminated one system with a better fit and higher cost, because they assumed the less expensive systems would provide the same functionality. (A close look at features and functions of the three finalists revealed that both eliminated systems would not need most mods required by the selected system).
The contract with the selected vendor did not list the mods the vendor promised to make for free. The team assumed the mods would be made for free, which happily they were, but it could have been otherwise. Although the vendor told the team to assume modifications would total about 10% of the license fee, no one attempted to identify the chargeable mods; obviously, no list of mods appears in the contract.
Shortly after the conversion and installation process began, the need for costly mods surfaced; many unexpected mods required unexpected extra, billable training. The principals were aware of the vendor’s assumption that modifications would cost about 10% of the license fee, so they didn’t pay attention to the bills, nor keep a running total until it was too late. They assumed the team would monitor the cost of mods, but the team was too busy preparing for the new system.
There have been so many modifications, with more coming, that it is questionable whether the distributor can use the vendor’s software upgrades without an expensive retrofitting for each upgrade. Maybe, for technical reasons, they couldn’t use upgrades at all.
A few brief lessons from this costly story. Define system needs in excruciating detail, and include features and functions that might be needed in the future. If there is some doubt about being able to create such a definition, seek professional help. Require that vendors address every requirement in the list of system needs. Read each vendor’s response to the needs definition, and identify problems and questions. Address the problems and questions before scheduling demos. Be cautious when comparing costs of different systems — some vendors include free modules for which others charge. In the contract, get specific performance guarantees, such as the cost for mods. Even if modifications are free, list them in the contract.
Dick Friedman is a recognized expert on systems and office and warehouse operations for fastener, tool, industrial and MRO distributors. But he does Not Sell computer systems. Based on more than 30 years of experience, he helps distributors prevent office and warehouse errors, often through quick, inexpensive changes. Dick is a contributing author to Industrial Supply, and consults with readers. Call (847) 256-3260 for a FREE consultation about preventing office and warehouse errors and increasing warehouse productivity.
This article originally appeared in the Sept./Oct. 2009 edition of Industrial Supply magazine. Copyright 2009, Direct Business Media, LLC.
INDUSTRIAL SUPPLY MAGAZINE
The November/December issue of Industrial Supply magazine features an in-depth cover story about Kimball Midwest. Plus, we're featuring articles by contributing writers Dirk Beveridge, Frank Hurtte, and Mike Marks, as well as interviews with numerous product and distribution industry experts.
