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!
Chip Camden has been programming since 1978, and he's still not done. An independent consultant since 1991, Chip specializes in software development tools, languages, and migration to new technology. Besides writing for TechRepublic's IT Consultant blog, he also contributes to [Geeks Are Sexy] Technology News and his two personal blogs, Chip's Quips and Chip's Tips for Developers.