TechRepublic reader Francois Bezuidenhout asked about my policy on getting customers to change out the software they use. In Francois’ case, his client was using an antivirus package with which Francois had no experience, and the product was reporting apparent false positives. This package has a good reputation, so Francois thinks the problem is probably a configuration issue, but he has no idea where to look. He is much more familiar with other antivirus products, and wonders whether he should get the customer to switch. Would he be placing an unfair burden on his client to learn the new product for his own convenience, or would he be saving them time and money by making them easier to support?

I’ve run into similar situations when it comes to programming languages, tools, and standards. You’re not going to get your client to rewrite their existing VB6 application, even though future development would be more efficient and trouble-free in just about any other language except Whitespace. The cost of conversion is just too great. But you might be able to convince clients to try a different language for a new project, even though they’re more familiar with VB. It all depends on what they get in return.

Before you ask a client to change the software/tool/programming language they use, here are some questions to consider:

  • How much more productive will you be? Can you confidently say that using a different product will make you more valuable to your customer? If so, how can you measure that? Are you sure you’re not just making yourself comfortable?
  • Shouldn’t you learn what they’re already using? The more products you learn, the better consultant you’ll become. Should you invest some of your own time to come up to speed, or should you get the client to pay for your education? In my experience, if you put in a good faith effort on your own time to become familiarized with a product, the client will be willing to pay for your extra time spent using it as you learn the finer points. But make sure that your client understands and agrees to the arrangement. (Note: This question doesn’t apply if you already know the product, but you think it’s a bad fit.)
  • How much will changing products cost them? Although I prefer free solutions where available, even the cost of proprietary software licenses is usually negligible compared to the costs of implementing anything new. Consider not only the cost of training your client’s people, but also their reduced productivity as they ramp up on actually using the product. You should also acknowledge their investment in their existing solution, but beware of the sunk-cost fallacy.
  • What else will they gain from it? Will a different product make the client more productive in the long term? Does it provide demonstrably better features, performance, or compliance? Will the product prevent them from becoming obsolete? Will it enable them to attract better employees, or widen their potential hiring pool? Does it provide a bridge to opportunities they’ve never been able to consider before?

So, instead of answering Francois’ question, I posed over a dozen more. Hopefully they’ll help him figure out how he should advise his client.

The ultimate answer should be based on the net result of all of the answers to these questions. In the end, you are part of the customer’s business, and you have your own costs and benefits. Any change intended to improve your cost:benefit ratio to them must be weighed against other costs and benefits of making that change. The decision to change what they’re using should ultimately be theirs — but it’s your job to advise them on what decision to make.

Get weekly consulting tips in your inbox
TechRepublic’s IT Consultant newsletter, delivered each Monday, offers tips on how to attract customers, build your business, and increase your technical skills in order to get the job done. Automatically sign up today!