October 18, 2013

Customers are always right, but shouldn't be made to pay a price of "being right"

What the customer asks you to do, is not necessarily what they want you to do

We all know the expression “the customer is always right”, well in many environments I’ve worked in that maxim is followed so strictly it becomes “do exactly what the customer tells you, and dont question it”.

I thought about this recently, when a customer asked one of our developers to change a Web page title from “..this..” to “..that..” it's obvious that the client understands the need for the change, and has given the developer the solution. He was able to put forward the solution because of his practical knowledge and experience of reading and changing text, and having made the assumption that it would be but a moment’s work. Luckily, the assumption was correct and nobody paid it any further attention.

If necessary, the developer could easily have deduced the underlying need that was implied in the given solution.

So when the customer asks a developer to “shift the intra page link so it’s about in the middle of the page” they are again giving a solution. But this time the underlying need is not so obvious and the developer is not able to design and develop a solution, because he is not in a position to know if the changes he makes will satisfy the customer's need. Worse still, any time spent on implementing the given solution is time potentially wasted, which ultimately costs the  client real money. Making the client pay the price for stating a solution and not a requirement seems a bit like a punishment.

When a customer provides a solution like this, where the underlying need is not apparent, it must be treated as a symptom of a requirement. At this stage, the developer should do nothing until he has discovered the underlying requirement, and that should usually done by picking up the phone (not email) and finding out why the change is needed.

Once the need has been established, the developer can think about developing a solution to that problem (and that, dear reader, is why they are called Solution Developers).

But there's more

As part of that same conversation, the time / resource cost of developing the solution has to be considered. It is for the customer to balance against the business need and benefit. The developer should provide an estimate of the amount of time and effort the change may involve (and the estimate can be wrong), so that the customer has the opportunity to decide if it is worth attempting, or not.

Try this out. You may find that trust and respect begin to develop.

Leave a Reply

Your email address will not be published.

The Future of Agile Leadership

Introduction The future of leadership is Agile There are many different types of leadership styles and not all work well in every situation. The most popular method, the "Command and Control" style which has been…

Business Agility Leadership Coaching (BALC) at HSBC

Business Agility Leadership Coaching (BALC) emerged as a consequence of asking leaders and managers across HSBC how they wanted to improve their agile leadership. Our proposed solution hit a sweet spot because we were 100%…

What does focussing on culture mean to XYZ Consulting?

We have some mid-tier consultants in at the moment who are "focussing on culture." Since we don't separate culture from delivering value to customers, I asked what that meant in practice. Apparently: "A generic scheme…

Visualising Progress using the Stand-up Game

We had a (brief) discussion about tracking progress as a team. I reacted against Jira because a) I dislike the user interface as it's a collaboration killer, and b) we aren't a software development or…
1 2 3 20
linkedin facebook pinterest youtube rss twitter instagram facebook-blank rss-blank linkedin-blank pinterest youtube twitter instagram