Drawing the line between expertise and arguing with the client?

Question

I have a client who wants to scrap working, yet unstable software and the associated implementation and build it and some automation tasks from scratch.

I obviously disagree with his point and idea and suggest that the software needs to be modified to become stable, but where do I draw the line between arguing and being the expert here?

When does stating your point expressively get to the point where it could scare off or even anger the client? How should I approach the situation?

Edit: I do want to state this is not a question on if we should or should not rewrite software or if the client is or isn't right. That should be my judgement. I was asking about the strategy of approaching the client, which was answered. Thanks.

Answer 1

You should use paper or email.

You do your responsible duty in presenting the best (in your opinion) approach and solution, compare and contrast it with the client's desire, explaining the cost and time differential, opportunity cost(s), and risks involved, and deliver it to your client.

Then, if your client decides to pursue their path anyway, you will have been a proper steward of your client, and they have made an informed choice.

You then support the choice they made, or discontinue providing services to them. You DO NOT continue to oppose their decision once it's made.

Answer 2

Having been in this situation myself several times, your best bet is to point out the pros and the cons of both choices, advise on the course that you recommend, but then go with his decision. There could be a lot of reasons why your client wants to start over from scratch. Maybe it has a long history of bugginess and end users have lost confidence in it. Maybe there are issues that might come up with upgrading and the like down the line that he can't discuss with you but which he nevertheless should take into account. Maybe the solution was someone else's pet and he's disliked the way it worked from the start. Maybe he just has a bee in his bonnet about completely re-doing it.

The bottom line is, you generally want to think of yourself as a consultant in these situations. Helping the other party to make the most informed decision that they can is the scope of your job. Actually making that decision for them may not be and in many cases is not. In development in particular, there is rarely one absolutely correct way of going about anything, so why use political capital to try to get someone to do something they aren't going to want to do? As long as they know that you are reticent and the reasons for your reticence, you have done your due diligence.

Answer 3

Break things down in a simple costs/benefits analysis and make recommendations based on that analysis, but understand the final decision is your clients.

Also, quantify everything you present and demonstrate why your idea has merit.

That is the difference between arguing and demonstrating your expertise.

Answer 4

Some good answers here, but I think they all miss at least one point or two.

Your first step is to understand the client!

Ask questions until you really understand why he follows his approach and not yours or any other. It is almost always more complicated than "he doesn't understand software development". Maybe he had great success in the past. Maybe somebody else is pushing him in that direction. Maybe there are financial aspects involved you don't know about yet. Let him do the talking. You are to ask questions and learn. Only when you are on a level where you say: "Yes, with history and in his situation, I can see, why he wants his solution" you might have really understood him. This approach is based on the book "Difficult Conversations", which I highly recommend.

Then talk about your thoughts or ideas

You will be in a much better situation to find arguments that are relevant to your client. Again if he dismisses your arguments that you find impossible to argue about, find out why he thinks the argument is invalid, or not as important as his arguments. This will give you confidence, that he really understood what you are trying to say, although he might still disagree.

Then the client decides

He is paying the bill, so he is in charge of calling the final shots.

If you really have to put the discussion in writing

If you are afraid that things will turn bad, due to the decision of the client, consider putting your discussion in writing. While this might be important from a legal point of few, be aware that this kind of document has also social implications. Up to know you went out of your way to understand the client, which has a good chance of improving the relationship with the client. Don't damage it with a mail that sounds like black mailing. One approach I'd try is something a long the lines:

Just to make sure I got everything right: We discussed how to do X. I put forward approach A with these arguments. You decided we should go with approach B, because ...

Answer 5

Running a DEV team I have seen this over and over from client point of view. You do get paid by the client, so that should dictate the "strategy" of how you advise. This by itself may be quite a challenge and requires finesse and experience :O)

However, if the client is stubborn, keep in mind whatever you agree to be part of, will become your portfolio for the future. The by far best consultants ever working for me had a very strong backbone, and at certain times it was clear, "either this is what needs to be done, or you need a different kind of expert, not me".

It's risky, but if the client actually has some brains, this often shows integrity, and also works.

Answer 6

First, the client might be right. Even expert consultants are wrong often. There should actually be no need to erase totally all existing code. It's very likely that many procs can be retained. The client may easily agree that much may be salvaged, or refactored.

Next, is there evidence of 'instability'? If so, then perhaps the client's confidence in outside expertise is already strained. Unwavering opposition will strain whatever the current status is.

It's not clear what the current project covers nor the scope of it, so it's difficult to suggest a truly valid action. But I have had to insist to some customers that they were wrong.

A case that worked for me:

The big case that comes to mind was a regular and often recurring error message out of one of our network security products at one customer's site. They were in New Zealand; we were a few miles south of Seattle, WA. A few conference calls for remote support led me to realize that they had a minor TCP/IP configuration problem.

I recommended that it be changed, but the response was that it was correct as it was. The group on the call was mostly their 'security' group, so I asked if they would bring one of their networking admins into the call. The response was that it wasn't necessary because they already knew it was alright. After all, they had out-sourced the initial network configuration to "experts".

Inside, I was thinking, "Idiots." I was also furiously thinking how to get past this mess.

We closed the call with a basic agreement on how we'd proceed with resolution even though I knew it wouldn't help. During the rest of the day, I wondered how to convince them to make the configuration change. That got me thinking about how to detect that such a somewhat obscure change should be made before our products were ever installed.

I started coding a reasonably high-level TCP/IP configuration analyzer. It retrieved basic info about adapters, interfaces, IP addresses, etc., did a set of standard DNS APIs, checked existence of loopback/localhost, etc.

It also did a few extras like checking how aliases were associated with host names and some peripheral elements of the configuration. None of it exceptionally deep, but it did some general cross-referencing to ensure that a given interface was both active and had an IP address that matched a valid host name for the system. After grabbing configuration bits and doing the cross-referencing to ensure that all parts fit together properly and coherently, it not only printed what it found, but it also gave recommended changes when anything looked out of place.

A few days later, we sent it to them and asked them to run it. Of course, it found exactly what I expected and printed the same as I recommended during the last conference call.

They made the recommended change. The original "problem" with our product disappeared. And all was well from that moment on.

Why? Well, I don't really know.

But there was something extra-authoritative about seeing output from a fancy-shmancy "Networking Configuration Analysis" program that they ran themselves on their server. (Even though I wrote it...) It seemed to have sufficient expertise to convince them. Perhaps it helped that every detail of output exactly matched their configured values. At least it wasn't simply bogus.

Limited Conclusion:

Not your situation unfortunately. But it might indicate that you can find a way to appeal through some other avenue that leads to agreement. Other consultants perhaps? Any client staff that can be leveraged? Any analysis tools that give guidance?

Any chance the client is right? I've seen software that was better being rewritten than merely refactored. (I've written some in a 40+ year career, generally my first efforts in unfamiliar system environments.)

With more question detail a better answer might be possible. It's difficult at best, but it seems that the question boils down to whose 'opinion' is right. Metrics are possibly hard to come by.