How NOT to Buy an Enterprise Software Solution

I'll be writing a lot on this blog about buying software (since I used to sell complex business software solutions in my previous career). Here're my top ways not to shop for enterprise software:

1. Delegating to tech staff.  The fastest way to end up with an expensive set of useless software is to delegate any part of the decision-making process to your I.T. staff. The reason? I.T.'s priorities are totally distinct from those of your business users.  I.T. wants something easy to install and administer, and frequently gets suckered in by "cool" high-tech features that ordinary users will immediately eschew. It is tempting to delegate the shopping to I.T. for many reasons, such as a fear of being taken advantage of by the software salespeople. The proper role for I.T. is to sit in on all sales presentations and negotiations, and to have a right of veto. The veto should be used to prevent acquiring software that is totally incompatible with the network or other legacy software.
    
2. Relying on the Demo. There is NO way that you can learn anything useful from a demo other than getting an idea of the very best that the proposed software looks and feels in the hands of an experienced presenter. Even a full-day demonstration cannot possibly address how the software will work in your business when subjected to the particular requirements of the way your process works. Instead, you need to get a commitment in writing to meeting your specific needs.
   
3. Buying a New Software that Does the Things your Current Software DOESN'T Do. This is a common mistake. Even if your end-users are loudly and regularly complaining about the shortcomings of your legacy software, you should not yield to the temptation to invest in an expensive solution that merely provides the features your current software lacks. The problem is that the new software will fix the dozen existing problems, but will fail to provide one hundred features that your end-users take for granted that your current software already provides.  You need to catalog not only the few critical things your current software lacks but also the large number of things that it does well, and make sure the new software can meet the needs of both lists.