Enterprise software procurement done right can save companies millions

In my earlier career in corporate IT, I spent years involved in enterprise software evaluation and procurement. I later set up a software vendor and sold its products to large companies, and now, as an analyst, I get involved in software selection projects at client organizations. Consequently, I have been on both sides of the procurement fence. In my experience, enterprise software procurement is frequently very poorly conducted and much money is wasted, as we shall see. So, how do you do it right?

To begin with, it is important to have well-documented requirements for the software that you are considering purchasing.

I have often seen companies with undocumented or barely articulated reasons for purchasing new software; all too often, they are responding to some latest software fashion or a slick demo at a trade show that a senior manager was impressed by.

And if there is a real need, is there software already lying around that can satisfy the requirement? At one company where I worked, an audit revealed 27 different business intelligence packages in use -- was it really sensible to consider a 28th? Every new piece of software brings with it a new set of required skills, so deploy what is already in use elsewhere in the organisation where possible. Also, keep in mind that software applications can have a long life. I was recently asked by a former corporate colleague whether I remembered an application I had coded 25 years ago; it apparently was still running at the company.

How to evaluate software
Assuming that there is a real need and that no suitable alternative to a new purchase exists, how should we go about evaluating software? Best practice is to start by ranking the requirements you’ve documented with the software’s intended end users: which features are really important and which are nice to have? A set of functional requirements should have relative weighting scores drawn up before you start to look at products: vendors are skilled at showing you the features they want you to see, which may be cleverly presented but of little relevance to your needs.

[one] company handed over $2 million to a vendor because officials did not properly read a renewal clause in an old contract -- the clause meant that it owed the vendor nothing.

Lists of required features should be about priorities: what really matters, not a vast wish list. Every feature you include needs to be tested and scored as part of the software procurement process, so you can make yourself a rod for your own back by being comprehensive. In one procurement exercise I saw, the company had managed to draw up a list of almost a thousand desired features and was looking at 22 vendors; this was obviously not going to end well.

Once you have your prioritised set of features, draw up a plan of how you are going to test them in the products being evaluated. Many will require you to see the software in action, which should always be done using real data in your own environment. Vendor demos are carefully constructed to ensure no glitches -- do not assume that just because software works on a vendor demo database, it will actually work on your data.

The next step is to establish a shortlist of vendors; these days, the Internet can help, or you can talk to a trusted consultant who works in the particular technology field. As well as functionality, you need to consider technical things like platform support (e.g., does the software fit into your company’s IT infrastructure?) and of course commercial aspects such as price, contract terms and technical support arrangements. Approach a set of vendors that seem to meet the bill with the aim of filtering them down to a manageable list of three or four potential suppliers by submitting a request for information and perhaps having short initial meetings. At this point, invite the shortlisted vendors to test their software against your checklist.

In parallel, commence commercial negotiations with each vendor, but at no time give any indication that one is favoured or winning the evaluation. The price of enterprise software is almost always negotiable, and the amount you will be quoted by a vendor that thinks it is in a genuine competition will differ greatly from the price quoted when one is sure it has already won.

That point can make millions of pounds of difference to the final price, yet I have been amazed at how often companies have carelessly handed over this critical negotiating card. Remember also that you still need to have a working relationship with the chosen vendor after a deal is signed, and that money is not the only thing that may have value in such cases. For a small vendor, having a customer as an active reference with a public case study may be of great value -- and may result in a lower cost for you.

Keep track to avoid being ripped off
Companies often put a lot of effort into negotiating contracts, yet little into keeping track of them. In one case I am aware of, a company handed over $2 million to a vendor because officials did not properly read a renewal clause in an old contract -- the clause meant that it owed the vendor nothing. (The vendor, a big software developer, was acutely aware of this clause, incidentally, and was simply bluffing.)

In general, both vendors and buyers pay too much attention to the initial license price and too little to the annual maintenance fee (assuming a traditional perpetual license structure). Vendor salespeople are heavily driven by the value of the initial deal, as that affects their commissions, and are often relatively relaxed about maintenance payments, as that is in the future and probably not given much emphasis in their commission structure. This is something the buyer can exploit by paying a little more up front in return for reduced maintenance costs. I once negotiated a mere 5% annual maintenance fee on a very large enterprise software deal (usually it is 10% to 20% of the purchase price annually), and that software is still in use at the company two decades later.

Enterprise software procurement and contract management are skills that can save, or cost, a company millions of pounds. They may not be trendy, but paying careful attention to them can pay big dividends.

Andy Hayler is co-founder and CEO of analyst firm The Information Difference and a regular keynote speaker at international conferences on MDM, data governance and data quality. He is also a respected restaurant critic and author (see www.andyhayler.com).