It is the most dangerous word. Every developer in the world is terrified by it. In our software service industry, where client is king, it is like a stone in his hands which he can throw at the developer anytime and a developer always find themselves in tricky situation whether to dodge it, catch it or get hit by it. The word is Change Request and it often comes in a disguise of an obvious request.

Focussing on Request.. at first

You gave a release and the client comes back with a few requests for changes. If you start shouting that its a change, all hell is surely going to fall. The key is to be willing to listen to what client is saying, comprehend, understand and then decide on how to tackle it. If your first reaction is to dodge it, youre looking for trouble. You need to focus on the request first. Forget about the change.. for a moment at least.

Try to understand the clients request, the background of why the request is made, does it make any sense. There are chances that sometimes the request will not hold much good value for the product over a long term and you have a chance to explain this to client and handle the request with an explanation only. Take the pain to understand the client and then make him understand yourself.

If the request does make sense, holds value for the product, then the request is a Good Idea. Be ready to accept it as a good, valuable idea for the project. But does it hold value for the project at that very moment? Is it important for the product to implement it right now? If not, then you have a very good chance to pass the idea as a Nice to have feature, but in future. You win again, with a little discussion only.

If the request has an impact on upcoming implementation, then that has to be taken up. Be ready to accept the fact. But at the same time be ready to put some more thought on whether it should be taken as an in scope item or change request. If the change will make your upcoming work easier, accept the change and let client know that you are accepting his request for change Make it count. If you built something after taking client in confidence, but at the end you both realize that another approach might yield better results, you have a good chance to make client realize that it is a change request. So the key here is that you should keep clients in loop and take them in confidence in what you are building. Make them agree to you on what you are doing for them, how you are doing it for them. Let them believe that what you are doing is essentially what they want or better what they asked. This will help you win with change requests. There are chances client will say I did not want it this way in first place. In most cases, the fault is on developers side. Maintain open communication, take client approvals, show them what you want to do, what you are planning to do.

Beware of potholes

Another word which is as important as Change request is Implicit Requirement. Beware. Do not try to label an implicit requirement as a change request. Do not try to label a bug as a change request. You are pissing your client.

Handle technical and non-technical clients differently. A technical client is likely to understand your point of view easily. Be considerate with a non technical client. Try to interact with him at a business level. He is not interested in your technical jargons, limitations. He is just interested in what he wants. If he likes pink, thats what he needs. Dont tell him that you only have basic colours (RGB) in your palette and cant give him pink. Try to understand why he needs pink, try to make him understand pink is not good for his business. If he understands you, Hurray! If not, go find a better color palette for yourself.

Some clients are two step ahead of you, or at least they think so about themselves. They have a tendency to get more work out of you for the price they are paying. Be very very careful. It is better to part ways at the first available opportunity. You can not win with them.

So, work as closely as possible with your clients. Take their approvals. Be open to listen to them. Try to understand problem, possible solutions, urgency, impact and these will help you take a better call on how you should handle the stone.