You know the old joke: What's the difference between a software salesman and a used-car salesman? A used-car salesman knows when he's lying. Well, I'm going to tell you something that you've probably suspected: So does the software salesman. And if he doesn't know when he is lying, he definitely knows when he is stretching the truth.
The truth is, people buy software that's not ready for prime time more often than they'd like to admit. And managers who buy vapourware don't like to talk about it: Regardless of whatever half-truths, misrepresentations or lies the software vendors told, it's the IS department that appears incompetent.
The software-buying process can be intimidating. However, there are several things you can do (starting with your next software purchase) to increase your chances of a prudent investment. Let's begin with the request for proposal (RFP). RFP responses from software vendors can be like those gossip papers you see in the supermarket near the cashier -- a few facts with a liberal sprinkling of fiction. That's because salespeople answer questions positively in the first round to avoid being knocked out before they can demonstrate their software. As a buyer, you need to separate the facts from the fiction. Let vendors know that they can't put it in the proposal if it's not in the software. If they need to customise their software in order to fulfil the request, they must tell you. Also, features and functionality planned for future versions of the software should include time frames for their inclusion.
You've read the RFPs, selected the finalists and are ready for the software demos. How can you determine what is software and what is vapourware? Software salespeople set up demos to work the way they want: more important than knowing the functions and features to show, they know which to avoid. At one company's demonstration, the application used was basically a shell -- salespeople simply ignored the icons that didn't work.
There are a few things you can do to help determine if a demo is a real application. First, don't let the salespeople rush through critical features.
Stop and ask questions. Have them click on icons, do searches and run reports.
The key is to have the salespeople actually demonstrate features and functionality as opposed to describing them. Remember, a demo that works with one user -- the salesperson -- may not be scalable to hundreds of users.
Bring the vendor's RFP response to the software demo. I know of one company that pointed out to the vendor how the product described in the RFP differed from the actual application. Make the vendor accountable. And make sure that the version used to answer the RFP is the same version presented in the demo.
Watch out for the old bait-and-switch. You don't want to buy one version of the application and actually get another. Given a choice between demonstrating an old version or the next release, a software salesperson will typically show the update if it has more features and isn't too buggy. Fine for the salesperson, potentially bad for you if what you are seeing is vapourware. Ask: "Is this the version that is currently available?" You don't want to buy something you can't use right away.
If the salesperson demonstrates a new version of software, ask if it's an upgrade or a new application altogether. Software that's written in a different language from its predecessor is more than an upgrade -- it's a new application. And it may not have been sufficiently tested before shipment to you. Ask the salesperson for a technical document that clearly states the differences between the old and new versions. This request is not unusual.
Beware of customisations. Demos can be customised so much that you wouldn't recognise the real product. This is especially true if a vendor says it specialises in your vertical market. Ask, "Did you customise this demo?" and if the answer is yes, find out what specifically was customised. It's easy to hack together a demo that shows enough -- though limited -- functionality to suffice during the typical software demo.
Watch for Poker Faces
If a team from the vendor comes to demo the software, watch the interaction among the members, their facial expressions and body language. Do this especially after you ask a question. Did one team member look uneasy as the other explained that the application could easily handle 10,000 users? Don't be afraid to ask the salesperson if there is anything he wants to add.
Notice if team members contradict each other or if one person interrupts another when answering a question. An inexperienced salesperson may not know the company party line on a particular subject or may not know how to put the right spin on an answer. For example, instead of saying that the version runs on your platform but with great difficulty, you may simply be told that it runs on your platform.
You should pay special attention to the technical people in the team; they will usually give you more reliable answers because they are the ones who will suffer if you are misled. They're the ones dealing with your angry phone calls while the salesperson moves on to another sale. If team members contradict each other on functionality, this could be a warning sign of vapourware.
Truth or References
You've selected a vendor. It passed the RFP test. The demo was great. Now you are ready to check references. Remember, just because a salesperson gives you a reference doesn't mean that the reference is reliable. It is not uncommon for a vendor to give a company a discount on a purchase if it agrees to be a reference.
A salesperson will choose a reference that he has a good relationship with. The truth is that references do sugar-coat. This is understandable -- references are people too. Vendors and customers develop relationships. References may not want to say something negative about salespeople because they want to promote smooth relationships.
Don't trust client lists. Period. As many as half the clients on a list may no longer use the software, are unhappy, use limited functionality or are unwilling to be references. I have rarely seen an accurate client list. Always ask, "How many of your clients are actually using the system?" There is a difference between how many clients have purchased the software and how many have actually implemented it.
And don't ask for just three references, as most companies do. Ask the salesperson to give you a list of references for you to randomly call. Make sure that you ask for references with environments that closely match yours. If you are going to have 1000 users on your system, don't call a reference with 10 users.
Whenever possible, make an onsite visit to a current client. You need to see people using the software. You may find out that the reference uses only one module, limited functionality or a different version of the software altogether. At one company, a client with a character-based system was a reference for Windows prospects.
Talk directly to the users. They are more in touch with the performance issues and will usually tell you what they really like and dislike about the system.
They'll reveal more if you are sitting right there in front of them. Being onsite, you may see the system crash and find out that it's common to have to reboot several times a day. A salesperson may not reveal this in a phone call, but he can't deny it if you are there when it happens.
The bottom line is that buying software is like buying a used car: You don't know if you've bought a lemon until it's too late. However, if you keep in mind some of the tips I mentioned, you will decrease your chances of buying vapourware, becoming an unwitting beta site and watching your software investment evaporate.
Some questions to ask a vendor's references* How do you use the system?* How many simultaneous users do you have?* How is the performance when all of the users are on the system?* Is there anything about the system that you would change?Beware of1. A salesperson who doesn't call you back2. The work workaround3. Client name-dropping4. The application crashing during the demo5. A salesperson who is hesitant to give references