Deciding Whether to Buy a Software Package
or Develop Custom Software

I can think of few situations where you would not want to at least start out with "a package". Accept in rare circumstances you don't need to write a custom G/L, A/R A/P module, etc. So you obviously shop for a package that gives you the "best fit" for your overall business. I argue that this is your starting point. Here's why...

Usually you will find that no package will do exactly what you do now... at least I've never found one that does. The "packages" tout that they use "best practices" and ideally list several customers successfully using the package. The argument coming from the vendor and often from top management is that if you're currently doing something different you must be wrong and you should change your ways to conform with the package.

This is a valid argument at least for some modules. But step back from it. "Best practices" says who? Are any of the differences between what you do and the best practices implemented in the package positively differentiated yourself from your competition and one of the reasons your company has been successful and grown in the first place?

• Many times large software packages will offer entry level packages for smaller companies at a greatly reduced price. The notion is that the smaller company benefits from the features that the larger companies are offered.
  • A little off topic, but verify that the reduced price package does indeed have all of the more expensive packages features on a feature by feature basis. There may be some features that the salesman "forgot to mention" that are not included in the entry level package.
• Determine the licensing cost for additional users. The licensing cost will sometimes increase exponentially when there is modest increase in the number of users. The additional cost is for the additional licenses themselves and the annual maintenance cost.
• The fact that you need more user licenses is good if it means that your business is growing. But many companies essentially find themselves working for the software vendor because the profits derived from the increased business volume do not offset the additional cost of the software.
• The bottom line is know you current and expected future costs when you select software package.

Ask the software salesman to tell you the success rate for the successful implementation of packages sold. Expect the same response Rodney Dangerfield responded to his English teacher in the movie Back to School when asked to comment on the book The Great Gatesby saying "It was.... Great!". But seriously this is a tough one. And there is the issue of defining "successfully implemented" because having installed one or two modules out of 20 is not implemented.

The best source of this information is through users groups by attending their meetings or by visiting the users group's web site. Doing an Internet search for "problems XYZ package" and similar searches may be helpful.

Software vendor's revenue resulting from consulting and support often exceeds the revenue from software sales. It is not uncommon for companies to permanently assign offices to their software consultants.

If the software company is publicly traded this information is usually available. Things get more complicated when the software vendor is privately held. The best approach in the case of privately owned vendors is to talk to their customers. And this does not necessarily mean talking to the customers that they suggest. Sometimes asking the customers that the vendor does suggest about other companies using the package is helpful. Try to find users groups for the software where you might attend their meetings or review information posted on the Internet. Query the Internet directly for problems regarding the software package or the vendor.

You simply cannot be too careful when selecting a package. It is an expensive, long term commitment that will directly impact the future of your company.

Large packages are designed to fulfill the needs of a wide variety of industries. As such their database can be complex and consist of hundreds and often thousands of tables. Setups are complex and if mistakes are made the consequences may not appear for weeks or sometimes even months.

Trying to untangle the mess can be complicated and costly and some errors are never fully resolved. There are some major packages where the documentation providing the road map through the database maze is not only poor but is not even written in English.

I've personally witnessed a service company who replaced software that was functioning perfectly and supporting remarkable growth so that marketing could boast the company now uses a very big name software package. But the problem was that the old software package functioned very much like a helicopter performing a myriad of diverse functions demanded by very different customers. The "big name" package functioned like a Boeing 777 and could perform one function... the best practice for that function... extremely well. Sadly that "best practice" did not conform to the majority of the customers' needs. The company then proceeded to spend close to $20MM dollars trying to make the "big name" software function like a helicopter. Obviously a Boeing 777 can never be made to function like a helicopter... they failed... and they lost over half their customers. But they still have the "big name" software because it's too expensive to write off the loss.