IT Employment

To change or not to change clients' software

IT consultants should ask themselves these questions before advising clients to change the software/tool/programming language they use.
 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!

About

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 b...

5 comments
Sterling chip Camden
Sterling chip Camden

Trying to get a user to change anything is often difficult, even if it's clearly in their best interests. What are your experiences?

Neon Samurai
Neon Samurai

Be like water and take what slow small changes you can get. Massage the user's habits. Show them why the alternative is better. Each user has different attachments and motivations though so understand why they resist changing.

Sterling chip Camden
Sterling chip Camden

Good advice. Rapids and the sound of rushing waters signal the approaching falls. I don't try to rush my clients, but I often try to give them advance warnings about where they will want to be in five years technologically. It's worked out well, even when I was wrong, because it made them think about where they were going.

tbmay
tbmay

...but they have to pay me for the time I spend messaging their habits as I have to pay my own bills and if they DON'T pay for my time I have to find clients who will. This is the reality. If hand-holding is the expectation, then the contract needs to reflect it and the bill needs to be paid. You might say this is obvious but if you've never had a conflict over getting paid what you were owed, or even less than you were owed, you obviously are doing something much better than me and I'd love to know the trick. I get so many "quick questions"...translation...this should be so trivial I shouldn't be billed...it's not funny and often it isn't that trivial or someone didn't pay attention in training...which is often a key part of the project's success. Having said all that, it takes awhile to learn which clients to avoid. The wrong ones can end up COSTING you money and that is very obviously not why you're in business.

mark
mark

RE: You?re not going to get your client to rewrite their existing VB6 application... The cost of conversion is just too great. I disagree with this and here's why: VB had a good run; many companies put their IT dollars into building VB codes. But its time to "cash in" that code and bring that functionality to viable platform. You will be doing your clients a disservice if you do not help them take steps to stop running their business on VB. It takes some clear thinking to make the case for migration but the case is there and it is getting stronger than ever: 1) There is a cost of doing nothing. First: The tech world is changing: the Windows OS, third-party tools, component vendors, the development community, even user expectations continue to evolve and leave VB behind. Running key business apps on VB and the last century's ActiveX components is risky; it is only a matter of time before some environmental change causes an outdated, poorly supported VB app to fail and that could mean serious consequences in terms of system outages, corruption of data, and damage to your, or your client's customer relationships. OUCH! Second: there is an opportunity cost of not being able to take advantage of contemporary tools, languages, and operating environments. Chip's article explains that this second factor is a bit trickier to put a value on, but it in the case of VB versus newer tools the opportunity cost is real. 2) If you use a smart approach with the right tools (e.g. a tool-assisted rewrite) VB modernization efforts -- even huge ones -- can be very cost effective, low risk, and non-disruptive without sacrificing quality or control. The key to managing the cost is to use an approach that lets you capitalize on your VB investment. Rather than summarily declaring your VB codes worthless, check out the latest next generation code-re-engineering tools that will help you cash it in and bring the cost of conversion down. Do the right thing: upgrade your VB developers then upgrade your VB systems; before you find out the hard way that the cost of NOT converting is just too great.