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.