Do you know the client is not "always" right?

Last updated by Chloe Lin [SSW] 6 days ago.See history

Clients come to us because of our experience and expertise as software consultants. Many of the problems faced by our clients we have seen, and solved, before. This means that, sometimes, the software consultants know best. But this is a delicate subject. You must be very competent to pull this card from your sleeve. It is easy to not only cause offence but also be plainly wrong. So before you speak make sure you've got the two fundamental aspects of this rule clearly sorted:

  1. Knowing when you know best (and knowing when you don't)
  2. Knowing how to persuade the client that your way is the best way (and knowing when you have failed)

Knowing when you know best

The expertise of a software consultant is likely to be in the technology underlying your clients business, not in their business model. If they're willing to pay for external consultants its highly likely their business model has been successful to date and it's wise that you leave that to them.

However, on some issues you should speak out firmly when you think the client is suggesting the wrong course of action. The following areas are most common:

  • Using old technology - e.g. .NET Framework instead of the latest .NET version
  • Wanting a non-scalable solution - this should speak for itself - the client is likely coming to you because their current solution has max'd out
  • Pushing for quick fixes when a better longer term fix is reasonable - e.g. hardcoding connection strings, using Boolean instead of Text when more options might arise down the track, fixing the size of text boxes instead of having them scale with the content.
  • Not thinking that UX matters
  • Trying to revert to a fixed price model when the agreement is time & materials

Knowing how to persuade the client that your way is the best way

If your client is not technically savvy you should be aware that an argument using technical language is unlikely to be persuasive. Argue your case using language that underscores your understanding of how your suggestion will improve their business, e.g. by future proofing the solution or allowing changes to be more easily implemented down the line.

As soon as you see the clients eyes glaze over, stop, it's likely you're bamboozling with techno-jargon. Rethink your argument and state it again.

If the point is arguable, once a client says no three times, don't push your luck too much. If you do concede don't forget to send an "as per our conversation" email to keep a record of the decision.

We open source. Powered by GitHub