Vendor Tricks when Buying Software Packages
Software Package Purchase
So you are going to purchase some software. There is no way a vendor is going to put one over you – right? ……Wrong!
How many software purchases do you make in a year? Perhaps two or three? How many software sales does the vendor make? Probably tens or hundreds. Who has the most experience? So what are the tricks that vendors play. Here are a few I have seen.
Wizz Bang Features
It may seem great that you can pick from a palette of 256 colours to configure your screen, and each screen can be a different colour. Do you really need it? Will it make the application more efficient, or will it prove a drain on the help desk. In one implementation where PC’s were being rolled out onto a factory floor, one smart IT person made the comment that the keyboards would need to be bigger. He said the gorillas on the factory floor used their fists to hit the keys.
One of the “gorillas” was smart enough to configure a screen to display black text on a black background. He then called the IT guy who had made the comment and watched for a few hours while he tried to work out why the monitor was blank. Vendors will show you some amazing features, but ask yourself if you will really use them. This is becoming particularly so in communication. It might be fun to see data downloaded to a PDA but will your organisation use it? |
Show you what I want you to see
If you put yourself in the place of a Vendor, he wants to present his or her product in the best light. This means showing you all the impressive features and not showing you the things that you might not like.
A vendor demonstrated how easy it was to customise screens during one demonstration I was involved in. You could drag fields around the screen and if you didn’t want to include that field, you could actually drag it off the screen.
It was some time into the selection process when we were looking at screens with their technical people we asked the question about adding new fields. The response was that it had to go back to the US as a request to modify the screen, and there was a six month backlog.
In doing a development, you need to brief the Vendor on what you are interested in seeing. By all means let the vendor show you what they want, but at the end of the demo, you should have covered your requirements as well as the vendors. If not, be suspicious.
Cheap Software – Expensive Implementation.
An implementation will cost you somewhere between twice, and ten times the cost of the software. If it is an ERP system, it is likely to be 10 times. If the vendor is to implement the software, they will sacrifice the price of the software and rake the money back on the implementation. I have seen many IT Managers look pleased with themselves for knocking 10% off the purchase price. The only person more pleased was the Vendor who could see many times the discount coming back in padded implementation charges.
Concurrent License v Named Users
In one purchase, we were well down the track with a Vendor when we discovered by chance their licensing was based on named users. The organisation had about 50 users of the system but only expected 10 to 15 users on the system at any time. They were thinking they would buy 20 licenses. The Vendor intended to sell one license to every user in the company so they were aiming to sell 50 licenses. The idea was to get the customer so keen on the package, by the time they found out about the named users, it would be too late to back out.
Help Desk
Do you have help desk support 24/7? Of course we do. Sounded straightforward enough until we found the help desk was in either America or Glasgow depending on the time of day. After testing out the support, we found trying to communicate with a thick Scottish accent was not too efficient. Added to this was the cost of international calls to a help desk.
Real References
Amazing as it may seem, I have had a significant vendor give false references. We had a condition that there were a minimum number of implementations in the country before a package was considered. A vendor listed around ten sites of which we found at least six had never heard of the vendor. When confronted, the only excuse was that the list had been prepared by a secretary who must have made a mistake.
References in Another Industry
Another situation with references is to tell the potential customer that their business is more aligned with someone in another industry so they should speak with a particular organisation when reference checking. “I know you are in the retail business and we do have a retail customer, however your business is more like someone in finance so you should talk to company X.” This should ring very loud warning bells. It is understandable if the person in the same industry does not want to talk to you for competitive reasons but if they are in the same industry, they will have many of the same issues.
In the end, there is no reason to stop you calling the IT Manager in the similar organisation and having lunch and a chat off the record. There is no reason you should ask the permission of the vendor before talking to their clients. If you were buying office supplies, would you ask the vendor before checking out the service with some of their customers?
Divide and Conquer
It is frustrating when a fair evaluation has been undertaken and a supplier is about to be eliminated and out of left field, the CEO, or Marketing Manager of someone senior says they should be reconsidered. Often the reason is that the vendor has bought someone who has influence in the organisation lunch, and told him or her, the process is discriminating against this vendor. Make it clear to all concerned that this is a tactic some vendors will use, and that all contact with the vendor should be through one person.
Getting on the list
Another similar tactic is that after a shortlist is developed, from somewhere up the corporate tree, comes a request to consider Company X who did not make the list. I have seen the golf partner of a director who happened to work for Company X, a new GM who has worked with Company X in another organisation, and even a person who had been promised a commission if he could get Company X on the shortlist.
Be sure you have fully documented why vendors are not considered. If not, it can be a major distraction to deal with such a suggestion from on high.
Research and Development Cutback
A good indication of the financial state of an organisation is the level of spending on R&D. If the vendor tells you that they have made major upgrades to their product over recent years and R&D spending is lower because they are consolidating their product, beware. It might mean the company is making cutbacks because they are suffering financially. R&D is usually the first to suffer.
Other Software
Always find out what other software is required. It can cost a significant proportion of the overall price of the software if you have to buy user licenses for other software. Vendors are often not forthcoming in explaining the additional licenses.
Maintenance Costs.
Assume the list price of a piece of software is $100k, but you buy it for $70k. Maintenance is quoted at 15% pa. What would you expect to pay next year for maintenance? Is it 15% of $70k? Is it 15% of $100k? Is it 15% of $100k plus 10% for inflation? Is it 15% of $150k because they have had a major price rise? I have seen vendors use all the above. Usually the details are buried in a contract.
Throwing Mud
Most vendors will not directly attack their competitors but are happy to create doubt. They might not say their competitor cannot deliver a particular piece of functionality, but will tell you how company X took twice as long as planned to implement the competitor “and I heard that they had to build functionality we have as standard!” Rumour and innuendo can be equally destructive. If this is the case, ring the company and ask them directly. Most often, you will get a straight answer.
You don’t want to ask the Vendor to sling mud at their competitors but you can ask the question as to what they can deliver that their competitors cannot match.
Getting past the Sales People
In many situations, the sales people have only a superficial understanding of the software. They rely on technical people to actually demonstrate and answer technical questions. It is always best to focus on the technical person in a presentation and direct questions to that person. The sales person is there to convince you to buy the software consequently they will tell you all the good points and try to gloss over the bad. The technical person is there to demonstrate what the package can and cannot do. They will have to install and support the software so they are more likely to foresee ongoing problems you might have. You will probably get a more realistic answer if you direct your questions to the technical person in a demonstration. The sales people will not like it, but persevere.
Software Package Jargon
Just because you don’t understand the jargon, does not mean you shouldn’t ask. Jargon is a way of communicating authority. If you know the jargon, you must be an expert.
Vendors will try to dazzle you with all the current (and invented) buzzwords. A good technique is for the lead IT person to say to the vendor, “For the benefit of some of the people who might not be familiar with the term anagatacanology, could you please take a moment to explain what it means.” If people are unclear after the explanation, ask that the term is not used.
Contract Surprises
You would think the vendor was keen to have the contract signed. Not necessarily. Once the commitment is made to purchase, the vendor may want to slip in a few surprises knowing the opposition is defeated. Make sure you get a copy of the contract before you make a decision and have your legal people review it for hidden nasties. These can be negotiated out while there is competition.
Not in the Contract.
Don’t rely on verbal assurances. Deal with vendors on the basis that if it is not in the contract, it does not exist. This is a real example I was told about. In purchasing software, an organisation was assured by the vendor that any customisation would be at the cost of the vendor. It was not in the contract.
Post contract the interpretation of “customisation” was the vendor would do the coding as long as the customer paid for a vendor representative to work with the customer and document how the software was to be modified. There was also a charge for testing the software, and in subsequent upgrades, there was an additional charge to fit the modifications to the new release. After implementation, it was estimated these changes cost the organisation 30% on top of the software purchase. So much for free customisation.
Swapping Technical Staff
During the evaluation period, you will probably deal with the best and brightest of the technical people. Who will you get to help with the implementation? I usually ask to work with the actual people who will be assigned to the implementation during the latter part of the selection process. In that way you can gauge the level of skill you will be dealing with during the implementation period. The nominated resources can be mentioned in the contract.
I learnt this lesson on a very difficult implementation when the support people assigned had less than a year with the vendor. In the end, it came down to a threat to cancel the implementation unless a specific technical person who had been at all the demonstrations, was assigned. The vendor complied but it was a difficult situation.
Conclusion on Software Selection
This may all sound like you are walking into a minefield with bare feet. I have focused on the worst cases, but they are all real. You might not strike all these tricks (and I could probably go on for a few more pages) in one selection process but you will probably strike some of them. If all the people on the team are briefed on what might happen, they are better prepared than if they have to work it out themselves.
At the end of the day, you want a relationship with the vendor where you are partners. It does not come by either side trying to win points against the other. The first step in developing the relationship is to understand games that might be played, and cut them off before the game starts. Hopefully these tips will help.
Copyright Project Perfect