I recently participated in a Treasury seminar where the CIO of a bank urged the audience not to believe what software vendors tell them. This CIO really knew what she was talking about as she had previously worked in software sales.
Even though I sell software myself, I agree with her whole-heartedly. The only objective of many sales person is to break down your resistance and get you to buy his solution whether it actually meets your needs or not. If you are not paying close attention, a good sales person can talk you into buying something you should actually avoid like the plague.
A common example of this is the required “minor customisation” of a software package to exactly meet your needs. These customisations are often sold as small addenda to the solution, but they can end up transferring a great deal of currency from your account to the vendor’s account in the following ways:
1. Deployment is delayed by several months – keep in mind that every lost day also decreases your project ROI
2. You WILL get a hefty bill for the customisation – the software vendor is not doing you a favour; they are doing very good business (in fact, they sometimes offer an artificially low license price because they know they get guaranteed extra revenue from the customisation)
3. You need to constantly call the vendor’s help desk about the customisations; and, lo and behold, the support comes with a hefty fee
4. With the first version upgrade (or the next one, at the very least), you are informed that some more customisation is needed to ensure compatibility (now go back to point #2)
5. Finally you realise you have sunk so much money into the project that it is impossible to back out of it gracefully.
This is why you need to make a few things crystal clear before you let any sales person dazzle you with their verbal acrobatics.
First of all, carefully consider how large a project you are willing to commit to. Calculate your exact ROI target (and remember that time is money; you need to consider the savings you lose while the project drags on). Analyse your needs and consider your processes: in my experience it is almost always more efficient to make small changes to your internal processes than to try to change a third-party system to exactly match your existing processes.
And if you have a feeling that the sales person is not telling you the whole truth, you can check for some common warning signs.
The warning lights should turn on if the vendor cannot give you a fixed price for the deployment project but keeps mumbling about how difficult it is to give a precise figure because of customisations or some such other circumstance.
Another clear warning sign is a help desk service that is not free of charge. Quite often this means the help desk is jammed – and if the application works well, the help desk should not be jammed.
I have previously written about the importance of references when acquiring a solution from a new vendor. Just don’t let the vendor get off the hook too easily; instead use the procedure I have described in my previous blog entry.
We recently learned another good reference strategy from a Norwegian buyer: they asked for the name of a customer that had stopped using our product. This was, in my opinion, an excellent question. A former customer is not likely to give a sanitized version of their experiences, especially if they have gone through anything like the merry-go-round I described earlier.
In the same seminar, a representative of a different bank described how they had acquired a business critical solution under a very tight deadline. Because of a corporate acquisition the bank had to find and implement a new system for managing their loans portfolio in under a year (which is usually a mere blink of an eye for a bank). Because of the tight deadline, the bank had taken a Guerilla Treasurer approach and selected a SaaS (Software as a Service) based solution. I was happy – but not surprised – to hear they were very satisfied with the choice they had made.